Deploy sin dolor: Guía paso a paso para montar tu app en producción con Docker y Nginx

MusicFan

Hace semanas que vengo peleando con el deploy de mi aplicación Flask + React. Cada tutorial que encuentro omite pasos clave o asume que ya tenés configurado un VPS. Quiero compartirles mi guía práctica que armé después de mucho prueba y error, con Docker Compose, Nginx como reverse proxy y SSL con Let's Encrypt. Incluye el docker-compose.yml, el nginx.conf y los comandos exactos. El objetivo es que cualquiera pueda tener su app en producción en menos de una hora. ¿Qué les parece? ¿Alguna sugerencia para mejorarla? Dejo el primer bloque:

# docker-compose.yml version: '3.8' services: backend: build: ./backend ports: - "5000:5000" frontend: build: ./frontend ports: - "3000:3000" nginx: image: nginx:alpine volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf ports: - "80:80" - "443:443"

Luego sigue el nginx.conf y el script para certbot. ¿Creen que falta algo? Por ejemplo, manejo de variables de entorno o bases de datos.

Indie

Buena iniciativa. Pero ojo: estás exponiendo los puertos de backend y frontend directamente, cuando Nginx ya hace de proxy. Con que Nginx tenga los puertos mapeados basta; los demás servicios pueden estar en una red interna. Así evitas riesgos de seguridad. Ejemplo:

services: backend: expose: - "5000" networks: - internal nginx: ports: - "80:80" - "443:443" networks: - internal

Además, falta el volumen para los certificados SSL persistente.

MusicFan

¡Excelente observación! Toda la razón, no debería exponer backend y frontend al host. Lo corrijo en la guía. Lo del volumen de SSL también lo había omitido, gracias. ¿Y sobre la base de datos? ¿Recomiendas meterla en el compose o usar un servicio externo como Railway para no complicar?

Urban

Para proyectos pequeños, meter PostgreSQL en el mismo compose con un volumen dedicado está bien. Así todo reproducible. Pero ojo con las contraseñas: usa variables de entorno con un .env y no las hardcodees. Ejemplo de servicio db:

db: image: postgres:15 environment: POSTGRES_PASSWORD: ${DB_PASSWORD} volumes: - pgdata:/var/lib/postgresql/data volumes: pgdata:

Si usas Railway, pierdes portabilidad. Mejor mantenerlo local.

Watercolor

Está bien la guía, pero falta el paso de hardening. Por ejemplo, desactivar el acceso root por SSH, usar un usuario no privilegiado para ejecutar Docker, y limitar recursos con deploy.resources en compose. También recomendaría usar docker-compose up -d --build en vez de solo up -d para forzar rebuild si hay cambios. ¿Incluiste eso?

MusicFan

Buen punto lo del hardening, lo agrego en una sección aparte. Lo de --build lo doy por sentado, pero mejor explicitarlo. ¡Gracias! Otra duda: ¿usan watchtower para actualizar automáticamente los contenedores o prefieren hacerlo manual? Yo le tengo desconfianza a las actualizaciones automáticas.

TechReview

Watchtower puede ser peligroso si no testeás las imágenes antes. Prefiero un pipeline CI/CD que haga build, test y deploy controlado. En producción, nada automático sin supervisión. Por cierto, en tu nginx.conf falta la parte de redirigir HTTP a HTTPS. Algo como:

server { listen 80; server_name example.com; return 301 https://$server_name$request_uri; }

Y luego el bloque SSL. Eso es esencial.

Developer

Muy completo el post. Solo añadir que para entornos con poco presupuesto, podés usar un VPS de 1GB de RAM y aún así correr todo con Alpine y optimizaciones. También recomiendo mirar Traefik como alternativa a Nginx, que maneja SSL automáticamente. Pero si ya tenés Nginx configurado, no lo cambies.

OpenSource

Lo de Watchtower es un tema. Prefiero un cron que haga pull y reinicie solo si hay cambios en el tag, pero sin borrar la versión anterior. Así si algo falla, vuelvo atrás rápido. Respecto al VPS de 1GB, con Alpine va bien, pero ojo con los logs: si no los rotás, te llenan el disco. Usá logrotate o montá un volumen separado. Por cierto, ¿alguien probó Docker compose con perfiles para separar servicios de desarrollo y producción? Es útil para no tener que mantener dos archivos.

Eco

Los perfiles de Compose están bien para entornos pequeños, pero en serio prefiero usar docker-compose.override.yml para dev y mantener el base limpio para prod. Así evitas conflictos de perfiles cuando alguien olvida el flag --profile. Sobre los logs, coincido: logrotate en el host es lo mínimo. Pero si usás el driver json-file por defecto, configurá max-size y max-file en el daemon.json. Y ojo con los volúmenes separados: si montás un bind mount para logs, asegurate de que el user del contenedor tenga permisos, o te vas a pegar con errores de escritura.

World

Sobre los perfiles de Compose, totalmente de acuerdo en que el override es más limpio que los perfiles. De hecho, en un proyecto con varios entornos, terminamos usando docker-compose -f docker-compose.yml -f docker-compose.prod.yml y un script que valida que no falten variables de entorno. Así evitamos sorpresas.

Respecto a los logs, un truco que me salvó: usar --log-opt mode=non-blocking en el daemon.json para evitar que el contenedor se cuelgue si el driver de logs va lento. Y combinarlo con max-size/max-file, claro. ¿Alguien ha probado Fluentd o Loki para centralizar logs en lugar de logrotate local? En un cluster pequeño, Loki con Promtail es ligero y permite búsquedas rápidas sin saturar el disco.