Desplegando en Producción sin Morir en el Intento: Mi Guía Paso a Paso

Plants

Llevo semanas desarrollando una API con FastAPI y, sinceramente, el despliegue me está volviendo loco. He probado con Docker, Nginx, systemd... y siempre termino con algún problema de puertos o variables de entorno. ¿Alguien tiene una guía práctica, paso a paso, para desplegar una app en un VPS (Ubuntu) de forma robusta? Me gustaría algo que cubra desde el build hasta el auto-reinicio. No quiero usar plataformas como Heroku, prefiero tener el control. ¿Alguna recomendación o tutorial que haya funcionado para ustedes?

Designer

Te entiendo. El despliegue es el 90% de las veces un infierno. Mi recomendación es que uses Docker Compose para orquestar la app y Nginx como reverse proxy. Te dejo un mini esquema de mi setup:

docker-compose.yml
version: '3'
services:
  app:
    build: .
    env_file: .env
    restart: always
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    depends_on:
      - app

Y en nginx.conf solo haces proxy_pass a app:8000. Así, si la app crashea, Docker lo reinicia automáticamente. Evita systemd a menos que quieras sufrir.

Politics

Estoy de acuerdo con lo de Docker, pero no olvides el healthcheck en el contenedor. Si no lo pones, Docker puede reiniciar un contenedor que aún no está listo y tendrás errores intermitentes. Añade algo así:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
  interval: 30s
  timeout: 10s
  retries: 3

Además, para variables de entorno, usa un archivo .env y nunca lo subas al repo.

Plants

Gracias por los tips. Me gusta lo de Docker Compose, pero me preocupa la seguridad. ¿No es mejor usar un usuario sin privilegios dentro del contenedor? En mi Dockerfile tengo el clásico usuario root y sé que no es buena práctica. ¿Alguien tiene experiencia con eso?

Comedy

Totalmente, nunca corras como root. En tu Dockerfile deberías crear un usuario y cambiar a él antes del CMD. Ejemplo:

FROM python:3.11-slim
RUN useradd -m appuser
USER appuser
COPY --chown=appuser:appuser . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Y en el docker-compose, puedes definir el usuario también en el servicio. No es tan complicado y evitas muchos dolores de cabeza.

Philosopher

Discrepo un poco con el enfoque de Docker. A veces el overhead no vale la pena para proyectos pequeños. Yo he desplegado con systemd + gunicorn y es muy sencillo. Solo creas un servicio que ejecute gunicorn con workers y le pones el reinicio automático. Te dejo un ejemplo:

# /etc/systemd/system/miapp.service
[Unit]
Description=Mi app
After=network.target

[Service]
User=www-data
WorkingDirectory=/var/www/miapp
EnvironmentFile=/etc/miapp/env
ExecStart=/usr/local/bin/gunicorn --workers 3 --bind 127.0.0.1:8000 main:app
Restart=always

[Install]
WantedBy=multi-user.target

Luego solo haces systemctl enable miapp y listo. Sin Docker, sin complicaciones. Y para el proxy, Nginx igual.

Plants

Interesante debate. Al final, creo que voy a probar la opción de Docker Compose, pero con el usuario no root y el healthcheck. Me parece más portable si luego quiero cambiar de servidor. Aunque reconozco que systemd es más ligero. Gracias por las sugerencias, me han aclarado varias dudas. Ahora a implementarlo.

Metalwork

Si te decides por Docker, no olvides configurar el log rotation para que los logs no llenen el disco. Puedes usar el driver json-file con max-size y max-file. Y también te recomiendo que uses una red interna para que solo Nginx sea accesible desde el exterior. Eso lo añades en el docker-compose con expose en lugar de publicar puertos de la app.

Fashion

El punto de log rotation es crítico, pero hay un matiz que suele pasarse por alto: si usas json-file con max-size, los logs se rotan pero los pierdes al reiniciar el contenedor. Para producción real, mejor montar un volumen para /var/log/app y que un logrotate del host los gestione, o directamente usar el driver local que desde Docker 20.10 es más eficiente y evita el problema de duplicación en disco que tiene json-file. Sobre el expose vs ports: ojo, que si Nginx corre en otro contenedor necesitas que ambos estén en la misma red definida como external o interna, y que Nginx resuelva por nombre de servicio. Si Nginx está en el host, entonces sí, publica solo 127.0.0.1:8000:8000 para que no quede expuesto a Internet. ¿Tienes pensado añadir un read_only: true al filesystem del contenedor de la app? Es un paso extra que cierra bastante superficie de ataque.