Ya tienes tus imágenes guardadas en ECR (subcapítulo 17.2). Ahora llega el momento de ejecutarlas: poner tus contenedores a funcionar en producción, escalarlos y mantenerlos sanos. Para eso AWS ofrece ECS (Elastic Container Service), su servicio para orquestar contenedores. En este subcapítulo entenderás sus conceptos clave y una decisión importante: Fargate o EC2.

Ejecutar un contenedor en tu portátil es fácil (docker run). Pero en producción necesitas mucho más:

• Ejecutar muchos contenedores repartidos en varios servidores.
• Reiniciarlos automáticamente si se caen.
• Escalarlos según la demanda (más copias en hora punta).
• Repartir el tráfico entre ellos (con un balanceador, Capítulo 13).

Hacer todo esto a mano sería inviable. Un orquestador de contenedores lo automatiza. ECS es el orquestador de AWS.

Analogía: un orquestador es como el director de una orquesta. Los músicos son los contenedores; el director se asegura de que toquen en armonía, que entre quien tiene que entrar, que si uno falla otro lo cubra, y que el conjunto suene bien. Tú das la partitura (la configuración) y el director (ECS) coordina todo.

Una task definition es la «receta» de cómo ejecutar tu contenedor: qué imagen usar (de ECR), cuánta CPU y memoria necesita, qué puertos abre, qué variables de entorno tiene, etc. Es un plano que describe cómo debe correr tu aplicación.

Una task es una task definition en ejecución: una instancia viva de tu contenedor (o grupo de contenedores) corriendo según esa receta. Es a ECS lo que el contenedor era a la imagen.

Un service se encarga de mantener en marcha el número de tareas que quieres y de conectarlas con un balanceador. Le dices «quiero siempre 3 copias de mi API corriendo», y el service se asegura de que así sea: si una se cae, arranca otra; si quieres escalar, añade más.

¿Te suena? Es el mismo concepto que el Auto Scaling Group del Capítulo 13, pero para contenedores en vez de instancias EC2. El service mantiene el número deseado de tareas y las repara. Y, como con el ASG, se integra con un balanceador de carga para repartir el tráfico entre las tareas.

ECS necesita máquinas donde ejecutar los contenedores. Aquí tienes dos modos, y elegir bien es importante:

En el modo EC2, tú gestionas un grupo de instancias EC2 (Capítulo 4) donde ECS coloca los contenedores. Tienes control total sobre esos servidores (tipo de instancia, configuración), pero también la responsabilidad de gestionarlos: parchearlos, escalarlos, mantenerlos.

En el modo Fargate, AWS pone y gestiona los servidores por ti. Tú solo dices «ejecuta esta tarea con esta CPU y memoria», y Fargate se encarga de todo lo demás. No ves ni gestionas ninguna instancia EC2: es serverless para contenedores.

Conexión con el Capítulo 14: Fargate es a los contenedores lo que Lambda es a las funciones: en ambos, AWS oculta y gestiona los servidores. Te olvidas de la infraestructura y solo te ocupas de tu aplicación.

Recomendación para empezar: usa Fargate. Te quita el peso de gestionar servidores y te dejas de complicaciones. El modo EC2 tiene sentido cuando creces mucho, tienes cargas muy constantes (donde puede salir más barato) o necesitas un control especial sobre los servidores. Para la mayoría de equipos, Fargate es la opción por defecto hoy en día.

Juntando los tres subcapítulos de contenedores hasta ahora:

• ECS (Elastic Container Service) es el orquestador de contenedores de AWS: ejecuta, repara, escala y reparte el tráfico de tus contenedores automáticamente (el «director de orquesta»).
• Task Definition: la «receta» de cómo ejecutar tu contenedor (imagen, CPU, memoria, puertos). Task: una receta en ejecución. Service: mantiene el número deseado de tareas, las repara y escala (como un Auto Scaling Group, pero para contenedores).
• Dos modos de ejecución: EC2 (tú gestionas los servidores, más control y esfuerzo) y Fargate (AWS gestiona los servidores, serverless para contenedores, mínimo esfuerzo).
• Fargate es Lambda para contenedores: olvídate de los servidores. Es la opción recomendada para empezar; EC2 tiene sentido a gran escala constante o con necesidades de control especiales.

En el último subcapítulo del capítulo (y de la Parte IV) veremos la alternativa más potente y compleja: EKS (Kubernetes en AWS), y cuándo merece la pena frente a ECS.