Despliega con seguridad tu proyecto en Elastic Beanstalk usando Python y Flask. Aquí verás cómo crear el entorno, realizar el primer deployment, adaptar tu código a WSGI (clave: renombrar a application.py y añadir application = app), y configurar escalado con load balancer, monitoreo y rollback. Todo directo, sin rodeos y listo para producción.
¿Cómo crear y desplegar una aplicación en Elastic Beanstalk?
Para iniciar, entra a la consola, abre All Services si está colapsado y ve a Elastic Beanstalk. Crea una nueva aplicación: asigna nombre, elige plataforma y arranca con la aplicación de ejemplo para que el entorno provisionado funcione de inmediato.
Da clic en crear aplicación: se aprovisiona un Elastic Load Balancer, una instancia con Python y la red asociada.
Observa eventos: verás cuándo se actualiza el ambiente y cuándo termina el deployment de la nueva versión.
Usa la URL generada: primero apunta a la app por defecto y luego servirá tu zip con el código.
Puertos y seguridad: se abren 80 para HTTP y 443 para HTTPS; antes trabajaste en 5000.
¿Qué plataformas y versiones puedes elegir?
Puedes seleccionar entre múltiples plataformas preconfiguradas: Docker, Java Enterprise con Tomcat, .NET en Windows con IIS, Go o Python. En el ejemplo se usa Python 3.6 sobre Elastic Beanstalk para una app con Flask.
¿Cómo empaquetar y mover versiones entre ambientes?
Sube un zip con tu código para cada deployment. Esto permite operar con ambientes de desarrollo, test y producción, y colaborar con QA de forma ordenada.
Sube el zip a desarrollo: valida con tu equipo o amigo de QA.
Promueve la versión: de desarrollo a test y luego a producción.
Si algo falla: aplica rollback en minutos.
¿Qué cambios de código exige WSGI y Beanstalk?
La clave está en cumplir el estándar WSGI: Elastic Beanstalk busca un archivo llamado exactamente application.py que exponga un objeto application. Si no existe, marca incompatibilidad con WSGI aunque el resto esté correcto.
Cambia el nombre: de app.py a application.py.
Expón el objeto WSGI: añade application = app.
Crea la carpeta .evextensions: ahí defines la configuración de Flask para que el entrypoint sea application.py.
¿Cómo adaptar app.py a application.py?
El código es el mismo: solo cambia el nombre del archivo y añade la referencia WSGI.
# application.py (antes era app.py)# ... código existente de Flask ...application = app # línea clave para Elastic Beanstalk y WSGI
Sigue usando Flask y tus rutas.
No cambia la lógica: solo el nombre del archivo y la exposición de application.
¿Qué hace la carpeta .evextensions?
Contiene la configuración para que Elastic Beanstalk conozca la app WSGI de Flask: ahí se indica que el archivo de entrada es application.py. Sin esto, no se ejecuta correctamente.
¿Cómo escalar, monitorear y recuperar versiones en Elastic Beanstalk?
Desde la configuración del ambiente puedes pasar de single instance a load balanced. El servicio crea por ti el load balancer, más instancias, permisos y conexiones, manteniendo la misma URL.
¿Cómo configurar un load balancer y autoescalado?
Define capacidad mínima y máxima, y las políticas para crecer o reducir según demanda.
Cambia a entorno balanceado: confirma el cambio y la consola hará el aprovisionamiento.
Reglas de escalado: por utilización de CPU, ancho de banda, latencia o salud del servidor.
Incrementos personalizados: escala de 1 a 5, 10 o 15 instancias si esperas picos fuertes.
Control de crecimiento: ajusta cuánto crece y decrece según tu tráfico.
¿Qué monitoreo y logs tienes disponibles?
Consulta salud, número de instancias, tiempo en ejecución y estado general. Activa métricas extendidas para más detalle.
Métricas: uso de CPU, red entrante y saliente, y más si habilitas métricas extra.
Logs y salud: solicita logs y revisa si las instancias están en ok o rotas.
Parámetros del ambiente: tipo de máquina micro, monitoreo cada cinco minutos y almacenamiento de ocho gigas.
¿Cómo hacer rollback rápido?
La consola guarda versiones históricas: puedes volver atrás si un deployment falla.
Historial de versiones: conserva hasta mil versiones por aplicación y ambiente.
Reversión inmediata: selecciona la versión anterior y despliega de nuevo.
Verificación: revisa la URL tras el rollback y confirma que todo responde.
Además, podrás asignar un alias más claro con Route 53 y explorar almacenamiento en S3 y Glacier para tu código o archivos estáticos en las siguientes prácticas.
¿Te quedó alguna duda sobre el cambio a application.py, el escalado con load balancer o el rollback? Comparte tus preguntas y cuéntame qué parte te gustaría profundizar.
