Al hablar de despliegue despliegue a producción en Docker nos referimos al proceso de trasladar nuestra arquitectura de contenedores a un servidor remoto y público.
Has hecho tu trabajo. Tienes tu docker-compose.yml impecable. Haces docker compose up -d, abres tu navegador en localhost:8080 y tu aplicación brilla en todo su esplendor… en tu ordenador.
¿Y ahora qué? ¿Cómo hago para que mis clientes o el resto del mundo puedan entrar a mi-proyecto.com y ver esto? ¿Tengo que instalar Docker allí? ¿Cómo paso mi código fuente o mi base de datos al servidor?
Pasar de “Localhost” a “Internet” suele dar mucho vértigo. Pero, precisamente, la tecnología de contenedores hace que sea el despliegue más limpio, predecible y profesional que existe (para eso nos metimos en este jaleo!).
Hoy vamos a aprender a preparar un servidor en la nube, la estrategia para transferir nuestro proyecto 👇.
El Servidor: Tu nueva casa en la nube (VPS)
Para que tu aplicación esté en internet 24/7, necesitas un ordenador que nunca se apague. La forma más barata y profesional de hacer esto es alquilar un VPS (Virtual Private Server).
Un VPS no es más que un trozo de un servidor gigante en la nube. Proveedores como Hetzner, DigitalOcean o OVH te alquilan uno por unos 4€ o 5€ al mes.
Al contratarlo, eliges un sistema operativo (por ejemplo Ubuntu Server) y el proveedor te dará dos cosas:
- Una Dirección IP pública (ej.
198.51.100.xxx). - Una contraseña (o clave SSH) para el usuario
root.
Abre tu terminal y conéctate a tu servidor remoto usando SSH:
¡Felicidades! Ya estás dentro del ordenador que alojará tu proyecto.
Preparando el terreno: Docker en el servidor
El servidor viene completamente vacío. La ventaja de usar contenedores es que solo necesitas instalar una única cosa en tu servidor: Docker.
Se acabó el instalar PHP, Node, bases de datos o pelearse con dependencias en el servidor. Ejecutas el script oficial de instalación de Docker para Linux, y listo:
curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
Tu servidor ya está listo para entender cualquier docker-compose.yml que le lances.
¿Cómo llevo mi proyecto allí?
Ahora lo “dificil” (que no es dificil). Tienes tu código en tu portátil… ¿cómo lo subes? Existen tres grandes estrategias, desde la más básica hasta la más paranoica con la privacidad:
Subes tu código a un repositorio privado de GitHub o GitLab. Entras a tu servidor por SSH, clonas el repositorio y construyes la imagen allí mismo.
En el servidor: Solo subes el archivo docker-compose.yml. Al hacer docker compose up, el servidor descarga la imagen compilada.
git clone https://github.com/tu-usuario/tu-repo.git
cd tu-repo
docker compose up -d --build
✅Pros: Muy fácil de entender.
❌Contras: El servidor consume mucha CPU compilando, y tu código fuente reside físicamente en el servidor público (riesgo de seguridad si te hackean).
En lugar de enviar tu código fuente al servidor, lo compilas en tu ordenador y subes la imagen ya terminada a un registro de terceros (como Docker Hub).
En tu ordenador: Construyes y subes.
docker build -t tu-usuario/mi-app:v1 .
docker push tu-usuario/mi-app:v1
En el servidor: Solo subes el archivo docker-compose.yml. Al hacer docker compose up, el servidor descarga la imagen compilada.
✅Pros: Cero código fuente expuesto, el servidor no sufre compilando.
❌Contras: Dependes de una empresa externa para alojar tus imágenes.
Si no te gusta depender de terceros (y haces bien), Docker te permite “empaquetar” una imagen compilada en un archivo comprimido estándar, enviarla por tu cuenta y cargarla en el servidor. Cero dependencias externas.
En tu ordenador: Construyes la imagen y la exportas a un archivo .tar.
docker build -t mi-app:v1 .
docker save -o mi-app-v1.tar mi-app:v1
Transferencia: Envías el archivo directamente a tu servidor mediante el comando scp (Secure Copy).
scp mi-app-v1.tar [email protected]:/root/
En el servidor: Cargas el archivo de vuelta al motor de Docker.
docker load -i mi-app-v1.tar
✅Pros: Privacidad absoluta. No necesitas internet en el servidor para descargar imágenes, ideal para entornos de alta seguridad (air-gapped).
❌Contras: Tienes que subir manualmente un archivo pesado cada vez que actualices.
Probablemente el flujo más habitual es subir el código a un repositorio (Github, Gitlab, Azure Devops) y que ellos compilen el código y manden la imagen a un Docker Hub.
No deja de ser el caso 2, pero en lugar de tu ordenador, es un servicio externo el que compila la app (y con una dependencia más 😉).
El Proxy Inverso: Dominio y HTTPS Automático
Tu contenedor ya está corriendo en el servidor en un puerto (ej. 8080). Si vas a la IP http://198.51.100.xxx:8080, verás tu web.
Pero tú quieres que la gente entre a midominio.com con seguridad HTTPS… Para esto usamos la pieza final: El Proxy Inverso.
Herramientas como Traefik o Nginx Proxy Manager (que se instalan como otro contenedor Docker más) se colocan como “porteros” de tu servidor.
Escuchan en los puertos oficiales de internet (80 y 443). Cuando alguien entra a midominio.com, el Proxy Inverso recibe la petición, va a la autoridad certificadora (Let’s Encrypt), consigue un certificado SSL gratuito automáticamente, y redirige el tráfico hacia tu contenedor en el puerto 8080.
