Antes de empezar: conoce el proyecto original en el artículo phpVirtualBox: gestiona VirtualBox desde el navegador.
En esta serie: Parte 1: phpVirtualBox, Echo y Vue · Parte 2: IA y OpenSpec · Parte 3: implementación y pruebas
Serie phpVirtualBox en Go — parte 3 de 3. Después de analizar phpVirtualBox y organizar la migración con IA y OpenSpec, llega el momento de definir cómo implementar y validar el nuevo panel. El objetivo no es lanzar una reescrita completa de golpe: es construir una secuencia de entregas verificables.
Entrega 1: demostrar la distribución, sin tocar VMs
Empieza con un servicio Echo, una ruta de salud y una página Vue que consulta esa ruta. Compila el frontend e incorpora su salida usando go:embed. En esta etapa, el panel no necesita conocer ninguna máquina virtual: la pregunta es si la API y la interfaz funcionan en el artefacto distribuido.
Echo dispone de un ejemplo oficial de recursos incrustados, y la documentación del paquete embed describe cómo se incluyen los archivos en la compilación. Las rutas son relativas al paquete; no planee incrustar archivos de directorios superiores con ../. Genere los archivos de Vue antes de compilar Go.
Código Vue → build do frontend → web/dist
↓
Código Go + Echo + go:embed → executável do painelCriterio de aceptación: copie solo el ejecutable a una carpeta vacía, inícielo en el loopback y compruebe la página, los archivos JavaScript y la ruta de salud. Detenga el servidor de desarrollo del frontend antes de esta prueba. Esto demuestra la distribución del panel, pero todavía no demuestra la integración con VirtualBox.
No incruste archivos de entorno, credenciales ni bases de datos. Esos elementos deben permanecer externos al binario. Si la interfaz usa rutas de aplicación, defina el tratamiento de rutas del frontend sin convertir errores de /api/ en una página HTML con estado de éxito.
Entrega 2: seguridad y contratos antes del host real
Antes de liberar el panel a otras personas, implemente autenticación, sesión, expiración y autorización. La autenticación identifica al usuario; la autorización decide a qué máquinas y acciones puede acceder. Un usuario autenticado no debe obtener acceso automático a todos los hosts.
La API debe distinguir entre entrada inválida, falta de autenticación, falta de permiso y fallo del servicio externo. No envíe mensajes SOAP completos ni rutas sensibles al navegador. Registre los detalles técnicos de forma saneada en el servidor y devuelva errores que la interfaz pueda presentar.
Para el laboratorio inicial, configure el servicio en la dirección de loopback y use credenciales de prueba. El diseño de producción debe explicitar transporte protegido, configuración externa, gestión de secretos y política de acceso.
Entrega 3: inventario real en modo de solo lectura
Implemente un adaptador dedicado a la integración. La capa HTTP no debe conocer cada detalle de SOAP: llama a un servicio de inventario que devuelve la representación de máquina definida en la especificación. Esto permite probar reglas sin un host real y, por separado, probar el adaptador contra VirtualBox.
Compara los resultados con un conjunto controlado de máquinas: una apagada, una en ejecución y, cuando sea posible, estados adicionales que tu contrato se comprometa a soportar. Registra qué versiones y escenarios se verificaron realmente. No uses la expresión “compatible con todas las versiones” para una prueba realizada en un único entorno.
La prueba de solo lectura debe confirmar que la consulta no dispara comandos de modificación. No basta con que la interfaz oculte botones: esa restricción debe existir en el backend. Limita también el número de consultas y define un tiempo de espera para no agotar las conexiones cuando un host no esté disponible.
Una matriz de pruebas para acompanhar las entregas
| Capa | Qué comprobar | Evidencia esperada |
|---|---|---|
| Distribución | API y Vue fuera del árbol de código | Ejecutable funcionando sin servidor Node |
| Contrato HTTP | Autenticación, campos y errores | Pruebas automatizadas por escenario |
| Adaptador | Respuestas, fallos y timeout SOAP | Fixtures saneados y pruebas de integración |
| Interfaz | Carga, vacío y fallo | Pruebas de navegación e inspección visual |
| Operaciones | Estado inicial, resultado y recuperación | Ejecución en VMs descartables |
| Despliegue | Reinicio y retorno a la versión anterior | Procedimiento reproducido en el laboratorio |
Los mocks ayudan a repetir fallos difíciles de provocar, pero no prueban la compatibilidad con el servicio real. Las pruebas de integración ayudan a validar la comunicación, pero no sustituyen a las pruebas de autorización. Cada capa responde a una pregunta diferente.
Entrega 4: operaciones con seguridad
Con la lectura validada, crearía cambios diferenciados para iniciar máquinas, solicitar el apagado, supervisar operaciones y, por último, administrar recursos más delicados. Solicitar el apagado desde el sistema invitado no equivale a cortar la energía de la VM; la interfaz y los permisos deben diferenciar esas operaciones.
Las operaciones prolongadas merecen un modelo de tareas explícito: identificador, estado, inicio, resultado y error. Tras un timeout, el backend debe consultar el estado real antes de volver a intentarlo. Repetir una operación de forma automática puede duplicar trabajo o producir un efecto inesperado.
- Iniciar y apagar: validar el estado actual, los permisos y el seguimiento.
- Snapshots: tratar la creación, la eliminación y la restauración como acciones distintas.
- Discos: diferenciar entre eliminar un enlace y borrar el archivo físico.
- Múltiples hosts: limitar los fallos y los permisos por destino.
- Auditoría: registrar el actor, el objetivo y el resultado, sin registrar credenciales.
Antes de permitir la escritura, añade protección contra CSRF cuando haya autenticación basada en cookies, autorización por objeto y confirmación clara para operaciones destructivas. El laboratorio debe utilizar máquinas virtuales desechables. Una instantánea no sustituye a una estrategia de copias de seguridad y restauración probada.
Licencia e implantación: dos etapas que no pueden quedar para el final
El archivo de licencia de phpVirtualBox indica GNU GPL versión 3. Reescribirlo en otro lenguaje no es motivo para ignorar la licencia del código, de los recursos visuales o de las dependencias utilizadas. Registra el origen del material reutilizado y evalúa las obligaciones aplicables antes de distribuir el nuevo proyecto. Licencia del proyecto original.
En la puesta en producción, mantén la posibilidad de volver al panel anterior, pero no dejes dos controladores ejecutando cambios concurrentes sobre la misma máquina. Comienza con consultas, compara los resultados y libera las operaciones de forma progresiva. Si la necesidad es cambiar de hipervisor, eso es otro trabajo: la guía de ova2xva trata la conversión de máquinas a XCP-ng, no la sustitución de la interfaz de gestión de VirtualBox.
Conclusión de la serie: distribuir es sencillo; operar exige evidencia
Como proyecto de ingeniería, la propuesta tiene sentido si resuelve un problema concreto: distribución más sencilla, mejor interfaz, API clara y mantenimiento predecible. phpVirtualBox ofrece una referencia valiosa, pero el nuevo panel necesitará ganarse la confianza con pruebas y compatibilidad, no solo con un lenguaje diferente.
El primer hito debería ser pequeño y demostrable: un ejecutable con Echo y Vue incorporado, autenticación e inventario real de máquinas virtuales en modo de solo lectura. La IA y OpenSpec pueden acelerar el camino hacia él, siempre que las tareas sean verificables y nadie confunda código generado con integración validada.
En esta serie: Parte 1: phpVirtualBox, Echo y Vue · Parte 2: IA y OpenSpec · Parte 3: implementación y pruebas