Desplegar aplicaciones de forma fluida es una habilidad clave en el panorama actual de ingeniería de software y DevOps. En este artículo explico cómo desplegar una aplicación Flask usando GitHub Actions, Docker Hub y AWS ECS, describo la estructura del repositorio y detallo los pasos para crear una canalización CI CD totalmente automatizada que publique actualizaciones directamente en ECS.
Sobre Q2BSTUDIO: Somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad, servicios cloud aws y azure y soluciones de inteligencia de negocio. Si necesita un producto adaptado a sus necesidades visite desarrollo de aplicaciones y software multiplataforma o conozca nuestras ofertas de nube en servicios cloud AWS y Azure. Ofrecemos además integración de IA para empresas, agentes IA y soluciones con Power BI para inteligencia de negocio.
Resumen del flujo de trabajo a alto nivel: usted escribe y commitea el código en GitHub; GitHub Actions construye una imagen Docker y la publica en Docker Hub; a continuación se actualiza el servicio en AWS ECS para forzar un nuevo despliegue; ECS extrae la imagen desde Docker Hub y ejecuta la aplicación en la nube; finalmente su aplicación queda accesible vía URL o IP pública.
Requisitos previos: repositorio con la app Flask en GitHub; cuenta y repositorio en Docker Hub; cuenta AWS; conocimientos básicos de Docker; claves y secretos para GitHub Actions: DOCKERHUB_USERNAME, DOCKERHUB_TOKEN, AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY.
Permisos y roles en AWS: para que ECS pueda descargar imágenes y escribir logs en CloudWatch necesita dos permisos principales y un role de ejecución. En lugar de pegar las políticas en JSON aquí le recomiendo crear dos políticas en IAM mediante la consola: una que permita obtener token de ECR, comprobar capas y descargar imágenes, y otra que permita crear grupos y streams de logs y poner eventos de logs. Luego crea un role con una trust policy que permita a ecs-tasks.amazonaws.com asumir el role y adjunta las dos políticas previas. Nombre sugerido para el role: ECSExecutionRole. Estas acciones aseguran que las tareas puedan tirar de imágenes y registrar información para monitorización y depuración.
Conceptos clave de ECS: task definition es la plantilla que define la imagen, recursos, variables de entorno y puertos; una task es la instancia en ejecución; un service mantiene el número deseado de tareas; un cluster agrupa recursos y puede usar EC2 o Fargate. Recomendación práctica: utilizar Fargate para evitar gestionar infraestructura, seleccionar una familia de task definition coherente con el proyecto, asignar 1 vCPU y 2 GB de memoria si la app es ligera y asociar el role de ejecución creado.
Opciones de cómputo en el servicio ECS: puede usar la estrategia de capacity provider para combinar FARGATE y FARGATE_SPOT o elegir un launch type simple. Platform version puede quedar en LATEST salvo que necesite características concretas de versiones anteriores. Configure redes VPC y subnets, y habilite Container Insights para observabilidad avanzada con CloudWatch.
Estructura típica del repositorio: Dockerfile, docker-compose.yml, archivo cicd.yml para GitHub Actions y un archivo .env con variables de entorno. Describo a continuación lo esencial de cada uno sin reproducir fragmentos literales de configuración.
Dockerfile: base python 3.10 slim para ligereza; instalar dependencias del sistema necesarias, copiar requirements y ejecutar pip install sin cache; copiar el código de la aplicación; establecer variables de entorno para PYTHONPATH y la entrada de Flask; exponer el puerto 5000 y lanzar el servidor en 0.0.0.0 puerto 5000 para que sea accesible desde fuera del contenedor. Este diseño garantiza consistencia entre entornos y permite escalar con contenedores.
docker compose: define un servicio web que construye la imagen localmente, recoge variables sensibles desde .env, mapea el puerto 5000 del contenedor al host y monta el código para facilitar desarrollo. En producción no es necesario montar volúmenes pero el compose es útil para pruebas locales y conectividad entre servicios como bases de datos.
GitHub Actions workflow: un flujo clásico consta de dos jobs principales. Job build: chequea el código, construye la imagen Docker y hace login en Docker Hub usando secretos del repositorio para publicar la imagen. Job deploy: depende de build y configura credenciales AWS usando los secretos correspondientes, y ejecuta el comando AWS CLI para actualizar el servicio ECS y forzar un nuevo despliegue. Este patrón asegura despliegues automáticos al hacer push a la rama principal.
Variables y secretos: cree un archivo .env con DATABASE_URL, OPENAI_API_KEY, SECRET_KEY, POSTGRES_USER, POSTGRES_PASSWORD y POSTGRES_DB para pruebas locales. En GitHub configure secretos de Actions para DOCKERHUB_USERNAME, DOCKERHUB_TOKEN, AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY. Mantener secretos fuera del repositorio es fundamental para seguridad.
Comandos útiles: clonar el repositorio con git clone https://github.com/21toffy/docker-ecs-deployment-test.git y entrar en el directorio con cd docker-ecs-deployment-test. Para construir y etiquetar localmente use docker build -t nombre_imagen:tag . y para subir a Docker Hub use docker push nombre_imagen:tag. Para forzar un redeploy desde la CI use aws ecs update-service --cluster nombre_cluster --service nombre_servicio --force-new-deployment con las credenciales AWS configuradas en el runner.
Buenas prácticas de seguridad y operación: limite permisos en IAM al principio y aplique el principio de menor privilegio; rote las credenciales periódicamente; habilite CloudWatch y Container Insights para alertas; use variables de entorno y secretos gestionados por GitHub Actions o AWS Secrets Manager; para cargas sensibles considere el uso de repositorios privados en AWS ECR en lugar de Docker Hub.
Beneficios de esta canalización: centraliza el control de versiones en GitHub, empaqueta la aplicación con Docker para reproducibilidad, almacena imágenes en Docker Hub para despliegue continuo y automatiza el proceso con GitHub Actions reduciendo errores humanos y acelerando entregas. Es una base escalable compatible con IA para empresas, agentes IA y procesos de business intelligence con Power BI, que se integran fácilmente en pipelines de despliegue y monitorización.
Servicios complementarios y oferta de Q2BSTUDIO: si busca desarrollar soluciones más avanzadas a medida, integrar modelos de inteligencia artificial, proteger sus aplicaciones con estrategias de ciberseguridad o explotar datos con Power BI y servicios de inteligencia de negocio, en Q2BSTUDIO ofrecemos consultoría y desarrollo completo. Podemos ayudar a automatizar procesos, desplegar en AWS o Azure y diseñar arquitecturas seguras y escalables.
Conclusión: con una estructura clara de repositorio, roles y políticas IAM adecuadas, un workflow de GitHub Actions que construya y publique imágenes y una configuración correcta de ECS, puede disponer de un pipeline CI CD robusto para desplegar aplicaciones Flask en la nube de forma automática. Para proyectos a medida y soporte en todo el ciclo de vida del software, contacte con nosotros y aproveche nuestra experiencia en aplicaciones a medida, inteligencia artificial, ciberseguridad y servicios cloud.
