De Flask Local a Producción con Gunicorn y PostgreSQL - Episodio 17

Flask funciona perfecto en local, pero

¿Cómo llevarlo a producción sin que todo explote?

En este post te cuento cómo usar Gunicorn para que tu app sea estable y escalable, y los errores que encontré en el camino. 🚀🔥

🚀 Flask en Local Funciona, pero… ¿y en Producción?

Correr Flask en local es fácil: python app.py y todo funciona.

Pero  claro, en producción la historia es diferente.

Es decir, no puedes simplemente lanzar la app con Flask en un servidor y esperar que escale.

Aquí entra en juego Gunicorn.

Si estás en esta fase, seguramente te estarás preguntando:

¿Cómo hago que mi aplicación Flask pase de mi portátil a un entorno de producción con PostgreSQL?

Tranquilo, aquí te cuento cómo lo hice, con todos los errores y soluciones que encontré en el camino. 🚀

🔍 Problema: Flask Solo Corría en Local

Antes de meternos en detalles, ¿qué es Gunicorn y por qué lo necesitamos?

🔹 ¿Qué es Gunicorn y por qué lo usamos?

Gunicorn (Green Unicorn) es un servidor WSGI diseñado para ejecutar aplicaciones web en Python, como Flask y Django, en un entorno de producción.

Su trabajo es actuar como un intermediario entre la aplicación y los clientes, permitiendo manejar múltiples solicitudes al mismo tiempo.

🔹 ¿Por qué no usar el servidor de desarrollo de Flask?

• Flask incorpora un servidor de prueba, pero no está diseñado para producción.
• No maneja múltiples conexiones concurrentes de manera eficiente.
• No tiene funciones de seguridad avanzadas para manejar tráfico real.

En pocas palabras, Gunicorn convierte tu aplicación Flask en un servicio robusto y escalable, listo para producción.

Por eso, para que es el estándar en despliegues de aplicaciones Python en servidores.

Flask funciona genial en local con el servidor de desarrollo, pero no está diseñado para producción.

Gunicorn Servidor WSGI

Así que necesitaba un servidor que pudiera:

✅ Manejar múltiples peticiones concurrentes.

✅ Integrarse con PostgreSQL sin bloqueos.

✅ Funcionar como un servicio que pueda iniciarse automáticamente con el sistema.

Después de investigar, encontré que la mejor opción era Gunicorn, un servidor WSGI ligero y potente para ejecutar aplicaciones Flask en producción.

Qué es un servidor WSGI

WSGI (Web Server Gateway Interface) es el estándar que permite que las aplicaciones web en Python, como Flask y Django, se comuniquen con un servidor web (como Gunicorn o uWSGI).

📌 ¿Por qué es importante WSGI?

Imagina que tu aplicación Flask es un restaurante y el servidor web (Nginx, Apache, etc.) es el mesero que toma pedidos.

En ese caso, WSGI actúa como el intérprete entre ambos:

• El servidor web recibe una solicitud HTTP (un cliente pidiendo comida).
• WSGI traduce esa solicitud y se la pasa a Flask (el chef que prepara el pedido).
• Una vez Flask genera la respuesta, WSGI la envía de vuelta al servidor web, que se la entrega al usuario.

⚡ Sin WSGI, Flask no puede hablar con el servidor web.

Por eso Gunicorn es tan útil.

Es decir, es un servidor WSGI que permite que Flask maneje múltiples solicitudes al mismo tiempo de forma eficiente.

Y ya sabes que en producción, no puedes depender del servidor de desarrollo de Flask, porque no está diseñado para manejar tráfico real.

En resumen:
WSGI es la conexión que permite que tu aplicación Flask reciba y responda peticiones en un entorno de producción. 🚀

❌ Errores Encontrados al Desplegar Flask en Producción

🔴 Flask se ejecuta, pero no responde

La primera vez que ejecuté Gunicorn, la aplicación parecía estar corriendo, pero al intentar acceder, el navegador se quedaba cargando eternamente.

Sin logs de error evidentes, fue frustrante.

¿El problema?

Gunicorn estaba escuchando en localhost en vez de una IP accesible.

🔴 Gunicorn se cerraba sin motivo aparente

Cada cierto tiempo, Gunicorn dejaba de funcionar sin explicación.

Por lo que revisando logs, descubrí que el servicio no estaba configurado para reiniciarse automáticamente al fallar.

🔴 Firewall bloqueando las conexiones

Después de muchos intentos fallidos, descubrí que el firewall estaba bloqueando el puerto de Gunicorn.

Así que con un simple ajuste en las reglas se solucionó el problema.

🛠️ Adaptando app.py para Gunicorn

La primera tarea fue asegurarme de que app.py estuviera listo para Gunicorn.

O sea, si en local ejecutaba:

python app.py

Para producción con Gunicorn, la ejecución cambia a:

gunicorn -w 4 -b 0.0.0.0:AQUÍ_VA_EL_PUERTO app:app

🔹 ¿Qué significa esto?

• -w 4: Usa 4 workers para manejar peticiones concurrentes.
• -b 0.0.0.0:AQUÍ_VA_EL_PUERTO: Expone la app en un puerto seguro.
• app:app: Indica que la aplicación está definida en app.py.

Después de esto, ya podía correr Flask con Gunicorn en producción.

Pero aún faltaba algo…

🔧 Instalación de Gunicorn y Configuración del Servicio

Para que Gunicorn se ejecute automáticamente, creé un servicio en systemd:

1️⃣ Instalación de Gunicorn

pip install gunicorn

2️⃣ Creación del servicio en /etc/systemd/system/gunicorn.service

[Unit]
Description=Gunicorn service for Flask app
After=network.target

[Service]
User=www-data
Group=www-data
WorkingDirectory=/var/www/mi_saas
ExecStart=/usr/local/bin/gunicorn -w 4 -b 0.0.0.0:AQUÍ_VA_EL_PUERTO app:app
Restart=always

[Install]
WantedBy=multi-user.target

3️⃣ Activar el servicio

sudo systemctl daemon-reload
sudo systemctl enable gunicorn
sudo systemctl start gunicorn

4️⃣ Verificar que Gunicorn está corriendo

systemctl status gunicorn

Si todo salió bien, Gunicorn ya estaba corriendo en producción. 🎉

🔥 Configuración del Firewall y Prueba de Acceso

Después de iniciar Gunicorn, aún no podía acceder a la app desde el navegador.

El problema: el firewall estaba bloqueando el puerto seguro.

Solución:

sudo ufw allow AQUÍ_VA_EL_PUERTO
sudo ufw enable

Ahora sí, al acceder a http://mi-servidor:AQUÍ_VA_EL_PUERTO, la aplicación Flask estaba funcionando en producción.

💡 Aprendizajes del Proceso

🔹 Flask en local no es igual a Flask en producción

El servidor de desarrollo de Flask no está diseñado para producción.

Por eso, Gunicorn es la mejor opción para servir Flask de forma estable y escalable.

🔹 Configurar un servicio con systemd evita problemas

Sin un servicio que maneje Gunicorn, el proceso se cerrará al reiniciar el servidor.

Por eso, configurarlo en systemd evita que tengas que iniciarlo manualmente.

🔹 Revisa siempre el firewall

El firewall puede ser tu mejor aliado o tu peor enemigo.

A mí, me paso que me bloqueó el acceso a la app hasta que configuré correctamente las reglas.

🔹 No asumas que todo funcionará a la primera

Cada servidor es diferente, y lo que funciona en un entorno puede fallar en otro.

Y como bien sabes, yo soy un experto en que no funcione a la primera para luego resolverlo.

Por eso, prueba, revisa logs y ajusta la configuración.

🚀 Próximos Pasos

Ahora que Flask funciona en producción con Gunicorn, el siguiente paso es configurar un proxy inverso con Nginx para mejorar la seguridad y el rendimiento. 🔥

➡️ ¿Has desplegado Flask en producción? Cuéntame cómo fue tu experiencia.

 

Si quieres conocer otros artículos parecidos a De Flask Local a Producción con Gunicorn y PostgreSQL - Episodio 17 puedes visitar la categoría Proyecto-IA.