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.

fullscreen
# 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.