Laboratorio multicloud local con Proxmox y Floci

Resumen del proyecto

Este proyecto consistió en montar un laboratorio multicloud local sobre una máquina virtual en Proxmox. El objetivo era tener un entorno reutilizable para practicar servicios de AWS, Azure y Google Cloud sin depender de cuentas reales, sin consumir recursos de proveedores cloud y sin riesgo de costes inesperados durante las pruebas.

La solución se apoyó en una VM llamada cloud-lab, Ubuntu Server, Docker Engine, Docker Compose y los runtimes de Floci para AWS, Azure y Google Cloud. Encima de esos runtimes se añadió Floci UI junto con Floci API para consultar los servicios desde una interfaz web.

Necesidad

Para aprender cloud de forma práctica no basta con leer documentación. Hace falta crear recursos, probar comandos, romper configuraciones y repetir escenarios.

El problema es que hacerlo directamente en AWS, Azure o Google Cloud implica varias limitaciones:

Riesgo de costes si se dejan recursos encendidos.
Gestión de credenciales reales.
Dependencia de conectividad externa.
Menos libertad para hacer pruebas destructivas.
Mayor fricción para practicar desde cero varias veces.

Con este laboratorio se buscó crear una base local que permitiera practicar con servicios cloud simulados desde la red LAN.

Arquitectura implementada

La arquitectura final quedó organizada en una VM dedicada dentro de Proxmox:

Proxmox VE
└── VM cloud-lab
    ├── Ubuntu Server
    ├── Docker Engine
    ├── Docker Compose
    ├── Red Docker floci_shared
    ├── Floci AWS
    ├── Floci Azure
    ├── Floci GCP
    ├── Floci API
    └── Floci UI

La VM se configuró con recursos suficientes para ejecutar varios contenedores al mismo tiempo y dejar margen para futuras ampliaciones. La red se mantuvo por DHCP dentro de Ubuntu, pero con una reserva fija en el router para que la IP de acceso no cambiara.

Decisiones técnicas

Se eligió Proxmox como base porque permite aislar el laboratorio en una VM, tomar snapshots antes de cambios importantes y ajustar recursos sin afectar al resto del servidor.

Ubuntu Server se usó sin interfaz gráfica para reducir consumo y mantener el entorno limpio. Docker Compose se utilizó para separar cada runtime en su propio directorio y poder levantar, detener o revisar servicios de forma independiente.

La red Docker floci_shared fue una parte clave del diseño. Permite que Floci UI y Floci API hablen con los runtimes existentes por nombre de contenedor, sin depender de IPs internas de Docker.

También se configuró AWS CLI con un perfil dedicado llamado floci usando credenciales ficticias. Esto evita mezclar el laboratorio con credenciales reales de AWS.

Implementación

El montaje se dividió en varias fases:

Preparación de la VM en Proxmox.
Instalación de Ubuntu Server y OpenSSH.
Instalación y validación de QEMU Guest Agent.
Configuración de red mediante DHCP con reserva en el router.
Instalación de Docker Engine y Docker Compose.
Creación de la red Docker compartida.
Despliegue de Floci AWS.
Instalación y configuración de AWS CLI.
Despliegue de Floci Azure.
Despliegue de Floci GCP.
Despliegue de Floci API y Floci UI.
Validación de acceso desde otros equipos de la LAN.

Cada fase se validó antes de continuar con la siguiente para evitar arrastrar errores de red, permisos o contenedores.

Servicios desplegados

El laboratorio quedó compuesto por los siguientes servicios:

Servicio	Función
Floci AWS	Emulación local de servicios AWS
Floci Azure	Emulación local de servicios Azure
Floci GCP	Emulación local de servicios Google Cloud
Floci API	Capa de API usada por la interfaz
Floci UI	Interfaz web para consultar los proveedores
AWS CLI	Cliente de línea de comandos para probar AWS local

Los puertos publicados hacia la LAN se dejaron como valores controlados del laboratorio. En una instalación nueva pueden cambiarse si alguno ya está ocupado.

Validaciones realizadas

Se validó que Docker estuviera activo, que los contenedores quedaran en estado healthy y que los endpoints de salud respondieran correctamente.

También se probó AWS CLI contra el endpoint local de Floci AWS:

aws --endpoint-url=http://localhost:14566 s3api list-buckets --profile floci

Después se creó un bucket de prueba para confirmar que la CLI estaba interactuando con el runtime local:

aws --endpoint-url=http://localhost:14566 s3 mb s3://laboratorio-floci --profile floci

Por último, se comprobó la API de Floci UI para los tres proveedores. El resultado esperado fue que cada runtime apareciera como reachable.

Resultado final

El resultado fue un laboratorio multicloud local funcional, accesible desde la red LAN y preparado para practicar servicios cloud sin usar infraestructura real.

Estado final:

VM dedicada en Proxmox funcionando correctamente.
Ubuntu Server accesible por SSH.
QEMU Guest Agent activo.
Docker Engine y Docker Compose operativos.
Floci AWS, Azure y GCP levantados.
Floci UI disponible desde navegador.
AWS CLI funcionando contra el entorno local.
Red Docker compartida entre los componentes.

Incidencia detectada

Durante las pruebas se detectó una incidencia visual en Floci UI: la barra superior puede mostrar un estado de no conectado aunque el backend responda correctamente.

En este caso no se consideró un fallo funcional porque:

Los contenedores estaban en estado healthy.
Los endpoints de salud respondían.
La API devolvía runtime: "reachable".
Los recursos podían consultarse desde la interfaz.
AWS CLI funcionaba contra el endpoint local.

La conclusión fue tratarlo como un problema visual de la interfaz, no como una avería del laboratorio.

Seguridad aplicada

El laboratorio se planteó como entorno local, no como servicio público. Por eso se aplicaron varias medidas básicas:

No usar credenciales reales de AWS, Azure ni Google Cloud.
No publicar los puertos directamente a Internet.
Mantener el acceso limitado a LAN o VPN.
No documentar IPs internas reales, MAC, usuarios, UUID ni identificadores sensibles.
Usar credenciales ficticias para el perfil floci.
Recordar que pertenecer al grupo docker concede privilegios elevados.
Realizar snapshots antes de pruebas importantes.

Próximas mejoras

La base ya queda preparada para ampliar el laboratorio con herramientas y ejercicios más avanzados:

Azure CLI.
Google Cloud CLI.
Terraform u OpenTofu.
Kubernetes con kubectl.
Ansible.
Pipelines CI/CD.
Ejercicios prácticos de IAM, redes, almacenamiento, colas, funciones y bases de datos.

Manual relacionado

El paso a paso completo de instalación y validación está documentado en el manual relacionado de este proyecto.