El módulo 9 dejó una infraestructura reproducible, gobernada y repartida en cinco cuentas, y una frase incómoda al final: la tienda de MercadoFresco sigue viviendo en instancias EC2 que hay que parchear, sobre una AMI que hay que reconstruir cada vez que cambia una dependencia, y que tardan dos minutos en arrancar. El viernes a las 19:00, con 900 pedidos por hora, esos dos minutos son exactamente el tiempo que los clientes pasan esperando mientras el ASG hace su trabajo.

Esta lección ataca el problema por la raíz: sustituir la máquina por el contenedor. Verás qué es un contenedor y en qué se diferencia de verdad de una máquina virtual, cómo se construye la imagen de la tienda con un Dockerfile serio, dónde se guarda esa imagen (Amazon ECR) y quién la ejecuta (Amazon ECS). Al final tendrás la tienda y los trabajadores de la cola de pedidos contenerizados, con su definición de tarea, su servicio detrás del ALB que ya existe y su autoescalado.

Aviso de coste. Amazon ECS no cuesta nada por sí mismo: es un plano de control gratuito, y pagas únicamente el cómputo que ejecuta las tareas —las instancias EC2 en esta lección, Fargate en 10-02—. Amazon ECR cobra 0,10 USD por GB y mes de almacenamiento y la transferencia de datos hacia fuera de la región; la capa gratuita incluye 500 MB durante 12 meses. El escaneo básico es gratuito; el escaneo mejorado con Amazon Inspector se cobra por imagen escaneada. Sigue todos los ejercicios con etiquetas correctas y borra al final lo que hayas creado. Todos los datos, cuentas e identificadores son ficticios.

1. Los tres problemas que dejó el módulo 9
2. Qué es un contenedor y en qué se diferencia de una máquina virtual
3. Imagen, capas, registro y contenedor en ejecución
4. El Dockerfile de la tienda de MercadoFresco
5. .dockerignore, tamaño y caché de capas
6. Amazon ECR: el registro que sustituye a las AMI
7. Etiquetado, inmutabilidad y ciclo de vida de las imágenes
8. Escaneo de vulnerabilidades: básico y mejorado
9. Replicación, cifrado y política de repositorio
10. Amazon ECS: clúster, definición de tarea, tarea y servicio
11. Tipos de lanzamiento, agente de ECS y proveedores de capacidad
12. La definición de tarea de la tienda, comentada
13. Rol de ejecución de la tarea frente a rol de la tarea
14. Modo de red awsvpc y qué implica
15. El servicio: ALB, comprobaciones de estado y colocación
16. Despliegues: rolling, porcentajes y circuit breaker
17. Autoescalado del servicio y descubrimiento con Cloud Map
18. Observabilidad: Container Insights, registros y X-Ray
19. La migración de MercadoFresco
20. Coste y limpieza
21. Errores comunes y consejos
22. Ejercicios
23. Conclusión

Conviene nombrarlos con precisión antes de resolverlos, porque cada uno tiene una causa distinta y el contenedor los resuelve por caminos distintos.

El contenedor no elimina el sistema operativo del planeta —sigue habiendo un kernel debajo—, pero cambia dónde vive la frontera entre lo tuyo y lo de AWS. El parcheo del sistema operativo base pasa a ser una línea del Dockerfile y una reconstrucción de treinta segundos, no una ventana de mantenimiento; con Fargate (10-02), el anfitrión deja de existir para ti. La AMI desaparece como artefacto y su lugar lo ocupa la imagen, que se construye en CodeBuild en dos minutos, se versiona por commit y se guarda en un registro. Y el arranque deja de incluir el arranque de una máquina: una tarea de ECS sobre una instancia existente arranca en 5-15 segundos, y sobre Fargate en 30-45 incluida la ENI. Frente a los 120 segundos actuales, es otra categoría de respuesta.

Un contenedor es un proceso del sistema operativo anfitrión al que el kernel le ha mentido sobre el mundo: ve su propio sistema de archivos, su propia tabla de procesos, su propia red y sus propios límites de CPU y memoria. Esa mentira la construyen dos mecanismos del kernel de Linux: los namespaces (aislamiento de lo que se ve) y los cgroups (limitación de lo que se consume).

Una máquina virtual es otra cosa: un hipervisor emula hardware completo y dentro arranca un kernel propio, con su sistema de arranque, sus servicios y su sistema de archivos.

La diferencia práctica que más importa para MercadoFresco está en dos filas: arranque y portabilidad. El arranque resuelve el pico de los viernes. La portabilidad resuelve la frase que Luis repite desde el módulo 8: «en mi máquina funciona». Con una imagen, en su máquina funciona exactamente lo mismo que en producción, byte a byte, porque es el mismo artefacto.

Y una advertencia honesta sobre el aislamiento, porque el marketing la suele omitir: los contenedores comparten el kernel del anfitrión. Una vulnerabilidad de escape de contenedor permite, en teoría, saltar de un contenedor a otro en la misma máquina. Por eso AWS no ejecuta contenedores de clientes distintos en el mismo kernel: Fargate (10-02) da a cada tarea su propia frontera de virtualización ligera. Para MercadoFresco, donde todos los contenedores son suyos, el riesgo es aceptable; para una plataforma multiinquilino, no lo sería.

Cuatro palabras que se confunden todo el rato y que conviene fijar:

• Imagen: un artefacto de solo lectura que contiene el sistema de archivos y los metadatos necesarios para arrancar el proceso. Es inmutable. Se identifica por un digest (sha256:...) y, opcionalmente, por una o varias etiquetas.
• Capa: una imagen no es un bloque monolítico sino una pila de capas, cada una con las diferencias que introdujo una instrucción del Dockerfile. Las capas se comparten entre imágenes: si diez imágenes usan python:3.12-slim, esa capa se almacena y se descarga una sola vez.
• Registro: el almacén de imágenes. Amazon ECR es el registro gestionado de AWS; Docker Hub es el registro público más conocido.
• Contenedor: una imagen en ejecución, con una capa de escritura efímera encima. Al parar el contenedor, esa capa desaparece.

La consecuencia operativa de las capas es enorme y define cómo se escribe un Dockerfile: si una capa cambia, todas las de abajo se invalidan. Poner COPY . . antes de pip install significa que cualquier cambio en cualquier fichero del proyecto obliga a reinstalar todas las dependencias. Poner primero el requirements.txt y después el código significa que un cambio de código reutiliza la capa de dependencias y la construcción baja de tres minutos a veinte segundos.

La tienda es una aplicación Python con Gunicorn detrás del ALB. Este es su Dockerfile completo, con construcción multietapa, usuario sin privilegios, versiones fijadas y un HEALTHCHECK coherente con el /salud que usa tg-mercadofresco-tienda desde el módulo 3.

Cada decisión de ese fichero responde a un problema concreto:

• python:3.12.4-slim-bookworm con versión completa, no python:3.12 ni python:latest. Una etiqueta flotante convierte una construcción reproducible en una lotería: la misma orden, ejecutada dos semanas después, produce otra imagen. Es la disciplina del bloqueo de aws-cdk-lib en 09-02. Y slim en lugar de la imagen completa baja de ~1,0 GB a ~130 MB: la diferencia es documentación y utilidades que en producción son superficie de ataque, no funcionalidad.
• Multietapa. build-essential y libpq-dev pesan más de 300 MB y solo hacen falta para compilar. Con dos etapas se quedan en la primera. Una imagen de producción con compilador es una imagen en la que un atacante puede compilar.
• --require-hashes con un fichero de bloqueo. Fija no solo la versión sino el hash de cada rueda descargada. Protege del ataque de sustitución de paquete en el índice.
• USER 10001 con un UID numérico explícito. ECS y Kubernetes pueden imponer «no ejecutar como root»; un UID numérico permite verificar la regla sin resolver nombres, y el --no-create-home --shell /usr/sbin/nologin evita que ese usuario sirva para nada más.
• HEALTHCHECK con --start-period. Los 20 segundos de gracia evitan que el contenedor se marque como no sano mientras Gunicorn levanta sus procesos hijos. En ECS es complementario al del grupo de destino: el del contenedor decide si ECS reinicia la tarea; el del ALB decide si le manda tráfico.
• ENTRYPOINT + CMD separados. El ENTRYPOINT fija el ejecutable y el CMD los argumentos por omisión, de modo que la definición de tarea puede sobrescribir solo los argumentos (command) sin cambiar el binario.

El .dockerignore es el fichero que más gente olvida y el que más problemas causa. Sin él, COPY . . mete en la imagen el directorio .git completo —que puede pesar cientos de megas y contiene el historial, incluidos secretos borrados—, el entorno virtual local, la caché de pruebas y los ficheros .env con credenciales de desarrollo.

En el fichero real va una entrada por línea; aquí se agrupan por familia. Reglas de tamaño y caché que se aplican en este orden:

El punto que más sorprende es el de «limpiar en la misma capa». Como cada capa guarda diferencias, borrar en la capa 7 un fichero creado en la capa 5 no reduce el tamaño de la imagen: el fichero sigue en la capa 5 y sigue descargándose. Solo desaparece de la vista. Un RUN apt-get install ... seguido de un RUN rm -rf /var/lib/apt/lists/* en línea aparte no ahorra nada.

En CodeBuild (08-02), la caché se aprovecha con docker pull "$REPO:cache" || true seguido de docker build --cache-from "$REPO:cache" --build-arg BUILDKIT_INLINE_CACHE=1 ..., apuntando a la imagen anterior del registro. Con este patrón, la construcción de la tienda baja de unos 3 minutos a 35-50 segundos cuando solo cambia el código, que es el caso habitual.

Amazon Elastic Container Registry es el registro de imágenes gestionado de AWS: privado por omisión, integrado con IAM, con cifrado en reposo, escaneo de vulnerabilidades, replicación y políticas de ciclo de vida. Ocupa exactamente el lugar que ocupaba la AMI en la arquitectura anterior, con dos diferencias: es regional pero replicable, y la unidad de versión es el digest, no un identificador opaco. MercadoFresco crea dos repositorios en la cuenta de herramientas 555566667777, que es donde vive el pipeline desde 09-04:

El token dura 12 horas y va asociado al principal de IAM que hizo la llamada. En CodeBuild, la línea anterior es literalmente la primera de la fase pre_build del buildspec.yml, y el rol del proyecto de compilación necesita ecr:GetAuthorizationToken (que es a nivel de cuenta, con Resource: "*") más los permisos de escritura sobre el repositorio concreto.

latest es una etiqueta como cualquier otra: no significa «la más reciente», solo significa «la que alguien etiquetó así la última vez». Y como etiqueta de despliegue es directamente peligrosa:

MercadoFresco usa el esquema que ya introdujo el módulo 8: versión semántica más SHA corto del commit, por ejemplo v1.6.0-a3f9c21. La versión semántica la lee un humano; el SHA la ata a un commit exacto del repositorio mercadofresco-tienda. Y en la definición de tarea que se despliega, no se usa la etiqueta sino el digest:

555566667777.dkr.ecr.eu-west-1.amazonaws.com/mercadofresco/tienda@sha256:9c1e...f4a2

La razón es sutil pero decisiva: una etiqueta es un puntero mutable —aunque la inmutabilidad la proteja dentro del repositorio, un fallo de configuración o una replicación mal hecha pueden desalinearla—, mientras que el digest es el contenido. Desplegar por digest garantiza que lo que arranca hoy en producción es exactamente lo que pasó las pruebas ayer en preproducción, bit a bit. La etiqueta sirve para que un humano encuentre la imagen; el digest, para que la máquina la despliegue.

Con --image-tag-mutability IMMUTABLE, ECR rechaza cualquier intento de reutilizar una etiqueta ya existente. Eso convierte un accidente silencioso —sobrescribir v1.6.0-a3f9c21 con otro contenido— en un error de compilación visible.

El otro control imprescindible es la política de ciclo de vida. Sin ella, el repositorio crece indefinidamente: MercadoFresco despliega 4,8 veces por semana, con imágenes de unos 220 MB, y sumando las de las ramas de característica el registro engorda unos 6 GB al año por repositorio. No es dinero, pero sí es ruido y sí complica las auditorías.

Tres advertencias sobre estas políticas, que son la fuente número uno de sustos con ECR:

1. Las reglas se evalúan por prioridad y una imagen solo la afecta la primera que la selecciona. Una regla amplia con prioridad 1 anula todo lo que venga detrás.
2. La expiración no comprueba si la imagen está en uso. ECR borrará la imagen que está ejecutando producción si la regla la selecciona. Por eso la regla 1 conserva diez versiones publicadas y no dos: hay que cubrir el peor caso de reversión.
3. Se prueba primero en seco. La consola ofrece una vista previa de la política sobre el contenido real del repositorio; ejecutarla antes de aplicar es obligatorio.

ECR ofrece dos modos de escaneo, y la diferencia entre ambos es mayor de lo que sugiere el nombre.

Para MercadoFresco importa la fila de «alcance»: la mayoría de las vulnerabilidades reales de la tienda están en dependencias de Python —una versión antigua de una librería de serialización, por ejemplo—, y el escaneo básico no las ve. Marta activa el escaneo mejorado en la cuenta de herramientas y conecta el resultado a la puerta de calidad del pipeline:

La política acordada es pragmática y por eso se cumple: CRITICAL bloquea siempre; HIGH bloquea salvo excepción documentada con fecha de caducidad; MEDIUM y LOW generan un ticket. Una política que bloquea con MEDIUM no sobrevive dos semanas: alguien la desactiva y entonces no queda ninguna. El escaneo continuo tiene además una propiedad que el básico no puede dar: la imagen que hoy está limpia y mañana no. Cuando aparece una CVE nueva que afecta a una imagen ya desplegada, Inspector emite un evento a EventBridge y bus-mercadofresco (07-03) lo enruta a alertas-mercadofresco. Ese aviso es el sustituto directo del ciclo de parcheo de las instancias.

La imagen se construye en la cuenta de herramientas 555566667777 y se ejecuta en producción 111122223333, preproducción 222233334444 y desarrollo 333344445555. Hay dos formas de resolverlo:

MercadoFresco usa repositorio central compartido para desarrollo y preproducción, y replicación hacia producción, porque quiere que un incidente en la cuenta de herramientas no impida que producción escale el viernes por la tarde.

La segunda línea de destino replica además a eu-central-1, que es donde MercadoFresco tendría su plan de recuperación si la región principal fallara. La replicación es asíncrona y tarda de segundos a algunos minutos según el tamaño; el pipeline debe esperar a que la imagen exista en destino antes de desplegar, con un wait explícito.

La política de repositorio autoriza a las cuentas de la organización a descargar, sin autorizar a nadie a subir:

Es el mismo patrón de 09-04: aws:PrincipalOrgID en lugar de una lista de cuentas que habría que mantener a mano. Y la separación entre quién lee y quién escribe es la que convierte al pipeline en el único camino hacia producción. El cifrado con alias/mercadofresco-datos (04-02) tiene una consecuencia que sorprende: si la clave es de la cuenta de herramientas y producción debe descargar la imagen, la política de la clave KMS debe autorizar a los principales de producción a usar kms:Decrypt. Es el error clásico de las claves gestionadas por el cliente entre cuentas: la política del repositorio está bien y la descarga falla igualmente, con un mensaje que habla de acceso denegado y no menciona KMS.

Amazon Elastic Container Service es el orquestador de contenedores propio de AWS. Su modelo tiene cuatro objetos y conviene no confundirlos nunca:

La correspondencia con lo que MercadoFresco ya tiene es casi uno a uno, y es la mejor forma de entender ECS: el servicio hace lo que hacía el ASG, la definición de tarea hace lo que hacía la plantilla de lanzamiento más la AMI, y la tarea sustituye a la instancia. Las definiciones de tarea son versionadas e inmutables: cada register-task-definition crea una revisión nueva (mercadofresco-tienda:23) y las anteriores siguen existiendo. Revertir un despliegue es apuntar el servicio a la revisión anterior, y eso es un cambio de un campo.

ECS ejecuta las tareas de dos maneras, y la elección cambia mucho más el día a día que la arquitectura.

En el tipo de lanzamiento EC2, cada instancia ejecuta el agente de ECS (amazon-ecs-agent), un contenedor que se registra en el clúster, informa de los recursos disponibles y recibe las órdenes del plano de control; la forma correcta de crear esas instancias es con la AMI optimizada para ECS, que ya lleva el agente y el runtime. Los proveedores de capacidad son la abstracción que evita gestionar el escalado del clúster a mano. Un proveedor de capacidad para EC2 se asocia a un ASG y activa el escalado gestionado: ECS calcula cuántas instancias hacen falta para las tareas pendientes y ajusta la capacidad deseada del ASG por sí mismo.

targetCapacity: 90 significa «mantén el clúster al 90 % de ocupación»: deja un 10 % de holgura para absorber una subida sin esperar a una instancia nueva. Y managedTerminationProtection evita que el ASG termine una instancia que aún ejecuta tareas, el fallo más molesto del modelo EC2. Aun así, ese 2 min de la tabla sigue ahí en la peor situación: si no hay hueco, hace falta una instancia, y una instancia tarda lo que tarda. Es exactamente el motivo por el que MercadoFresco no se quedará aquí y 10-02 existe.

Esta es la definición completa de mercadofresco-tienda, con secretos inyectados, registros hacia CloudWatch y modo de red awsvpc.

Los puntos que hay que entender de ese JSON:

• CPU y memoria a dos niveles. El cpu y memory de la tarea son el total reservado; los de cada contenedor reparten ese total. Con Fargate, los valores de tarea son obligatorios y solo admiten combinaciones concretas (10-02); con EC2 pueden omitirse y entonces la reserva se hace solo por contenedor.
• memoryReservation frente a memory. memoryReservation es el mínimo garantizado que ECS usa para colocar la tarea; memory es el límite duro: si el contenedor lo supera, el kernel lo mata con OOM. Fijar solo memory desperdicia; fijar solo memoryReservation deja que un contenedor con fuga se coma la instancia. Se ponen los dos.
• essential: true en la tienda y false en el sidecar de X-Ray. Si un contenedor esencial muere, ECS mata la tarea entera y la repone. El demonio de X-Ray no debe tumbar la tienda si se cae.
• secrets en lugar de environment para lo sensible. El agente de ECS resuelve el valor en el arranque usando el rol de ejecución y lo inyecta como variable de entorno. Nunca aparece en la definición de tarea, ni en la consola, ni en CloudTrail. La sintaxis :password:: selecciona una clave concreta del JSON del secreto (04-03).
• mode: non-blocking en los registros. Es la opción que evita el fallo más desagradable del controlador awslogs: si CloudWatch Logs va lento, en modo bloqueante la aplicación se para esperando a escribir su log. Con non-blocking se pierden líneas en el peor caso, que es infinitamente mejor que perder pedidos.
• readonlyRootFilesystem: true con un volumen para /tmp. El sistema de archivos de solo lectura impide que un atacante escriba binarios; el volumen efímero da el /tmp que Python necesita.
• stopTimeout: 30. Segundos que ECS espera entre el SIGTERM y el SIGKILL. Es el margen que tiene Gunicorn para terminar las peticiones en curso durante un despliegue.

Es la confusión número uno de quien empieza con ECS, y produce errores que parecen no tener sentido: la tarea no arranca pero los permisos de la aplicación están bien, o la tarea arranca y la aplicación no puede leer una cola.

Y el rol de la tarea, que es el que usa el código y por tanto el que debe ser mínimo:

La regla mnemotécnica que evita el 90 % de los errores: el rol de ejecución trabaja para AWS, el rol de tarea trabaja para tu código. Si el fallo ocurre antes de ver un solo log de la aplicación, es el de ejecución. Si el fallo aparece en los logs de la aplicación, es el de tarea.

Con networkMode: awsvpc, cada tarea recibe su propia interfaz de red elástica (ENI) con su propia IP privada dentro de la VPC. Las consecuencias son concretas y todas relevantes para MercadoFresco:

• Grupos de seguridad por tarea. sg-mercadofresco-tienda se aplica ahora a la tarea, no a la instancia. Dos servicios distintos en la misma instancia pueden tener reglas distintas, cosa imposible con bridge.
• Sin conflictos de puerto. En bridge había que usar hostPort: 0 para asignación dinámica y el grupo de destino registraba instancia:puerto. Con awsvpc, cada tarea escucha en su propio 8080 y el grupo de destino es de tipo ip.
• La tarea consume una IP de la subred. Con snet-mercadofresco-app-a y -b de /20 hay direcciones de sobra, pero en subredes pequeñas es un límite real que se alcanza antes de lo esperado.
• Límite de ENI por instancia. En el tipo de lanzamiento EC2, cada instancia soporta un número limitado de ENI según su tamaño. Sin el ajuste awsvpcTrunking activado (aws ecs put-account-setting-default --name awsvpcTrunking --value enabled), una m5.large solo puede ejecutar dos o tres tareas con awsvpc, por mucha CPU libre que tenga. Es una de las trampas más caras del modelo EC2.
• Sin acceso al localhost del anfitrión. Los contenedores de una misma tarea sí se ven entre sí por 127.0.0.1 —por eso el sidecar de X-Ray funciona con AWS_XRAY_DAEMON_ADDRESS=127.0.0.1:2000—, pero no ven a los contenedores de otras tareas.

El servicio es lo que convierte la tarea en algo que se puede llamar producción: mantiene el número deseado, repone lo que muere, registra en el ALB y gestiona los despliegues.

Tres detalles que importan:

• --health-check-grace-period-seconds 60. Es el período durante el cual el servicio ignora el estado del grupo de destino tras arrancar una tarea. Sin él, una aplicación que tarda 40 segundos en calentar la caché entra en un bucle infinito: el ALB la marca como no sana, ECS la mata, arranca otra, y así indefinidamente. Es el error más frustrante de todos porque no da ninguna pista.
• Grupo de destino de tipo ip. Obligatorio con awsvpc. Si tg-mercadofresco-tienda se creó en el módulo 3 con tipo instance, hay que crear un grupo de destino nuevo: el tipo no se puede cambiar.
• Estrategias de colocación (solo con tipo de lanzamiento EC2, no aplican en Fargate):

Para la tienda, spread por AZ y luego por instancia. Para los trabajadores de la cola, que son tolerantes a fallos, binpack por memoria ahorra instancias.

El despliegue por omisión de ECS es la actualización renovada (ECS rolling update). El servicio arranca tareas con la revisión nueva, espera a que estén sanas en el grupo de destino, drena y para las viejas, y repite. Los dos parámetros que lo gobiernan son:

• minimumHealthyPercent: porcentaje del desiredCount que debe seguir sano durante el despliegue.
• maximumPercent: porcentaje máximo que puede estar en ejecución a la vez.

MercadoFresco usa 100 / 200 en producción y 50 / 100 en desarrollo, donde el coste importa más que la disponibilidad. Con 100 / 200 y un arranque de tarea de 15 segundos, un despliegue completo de cuatro tareas termina en poco más de un minuto, frente a los ocho o nueve del ASG con instancias.

El circuit breaker de despliegue es la red de seguridad. Con enable: true, ECS cuenta los fallos consecutivos de arranque de tarea; al superar el umbral —calculado a partir del desiredCount, con un mínimo de 10— declara el despliegue fallido. Con rollback: true, además revierte automáticamente a la última revisión que sí funcionó.

Esto sustituye, en el caso más frecuente, a la alarma manual: si la imagen nueva tiene un error de configuración que impide arrancar, el despliegue se para y se revierte solo. Lo que el circuit breaker no detecta es una imagen que arranca bien y responde mal: para eso hacen falta las alarmas de CloudWatch asociadas al despliegue, con alarmNames en la configuración, y el blue/green. El despliegue blue/green con CodeDeploy (08-03) es la otra opción: se cambia el controlador de despliegue a CODE_DEPLOY, y CodeDeploy levanta el conjunto verde completo en tg-mercadofresco-verde, permite probarlo por un puerto de pruebas y desplaza el tráfico de golpe o en canario. Es lo que MercadoFresco integra en el pipeline en 10-02, cuando el servicio ya esté sobre Fargate.

El autoescalado de ECS lo proporciona Application Auto Scaling, el mismo servicio que escala Aurora Serverless o DynamoDB. Se registra el servicio como destino escalable y se le asocia una política.

La elección de métrica no es indiferente:

Para la tienda, ALBRequestCountPerTarget con destino 120 es mejor que la CPU por una razón de tiempo: el tráfico sube antes que la CPU, así que escalar por peticiones adelanta la reacción entre 30 y 60 segundos. Y los enfriamientos son asimétricos a propósito: 30 segundos para crecer, 300 para decrecer. Crecer tarde cuesta pedidos; decrecer pronto cuesta una oscilación. Para los trabajadores, la métrica correcta es la profundidad de la cola dividida entre el número de tareas —el «backlog por tarea» de 07-01—, calculada como métrica matemática de CloudWatch y usada en una política de seguimiento de destino personalizada.

Cuando un servicio necesita llamar a otro sin pasar por el ALB, la pregunta es cómo encuentra su IP, que cambia con cada tarea. AWS Cloud Map lo resuelve con DNS: ECS registra y desregistra automáticamente cada tarea en un espacio de nombres privado (aws servicediscovery create-private-dns-namespace --name interno.mercadofresco --vpc vpc-mercadofresco). Con el servicio configurado con serviceRegistries, la tienda alcanza al inventario en inventario.interno.mercadofresco y el DNS devuelve las IP de las tareas sanas. Las alternativas son:

MercadoFresco no necesita esto todavía porque la tienda es un monolito detrás del ALB y todo lo demás va por colas (módulo 7). Cuando la tienda se divida, ECS Service Connect será la opción preferible: da métricas por llamada entre servicios sin instrumentar el código.

Todo lo del módulo 5 sigue valiendo, con tres ajustes:

• Container Insights se activa a nivel de clúster (aws ecs update-cluster-settings --cluster ecs-mercadofresco --settings name=containerInsights,value=enhanced) y publica métricas de CPU, memoria, red y disco por servicio y por tarea en el espacio de nombres ECS/ContainerInsights. Sin él, CloudWatch solo da CPUUtilization y MemoryUtilization a nivel de servicio, que no basta para diagnosticar qué contenedor consume.

• Los registros van al grupo /ecs/mercadofresco-tienda con un flujo por tarea. La consecuencia práctica: como las tareas son efímeras y se reponen constantemente, la única forma razonable de buscar es CloudWatch Logs Insights (05-01), no abrir flujos a mano. Y la retención hay que fijarla explícitamente: con awslogs-create-group: true, el grupo se crea sin caducidad y guarda para siempre.

• X-Ray funciona con el sidecar del ejemplo. El SDK de la aplicación envía los segmentos por UDP a 127.0.0.1:2000, el demonio los agrupa y los sube. La alternativa moderna es el AWS Distro for OpenTelemetry como sidecar, que además de trazas recoge métricas. En ambos casos, el rol de tarea —no el de ejecución— necesita xray:PutTraceSegments.

Las métricas nuevas que Marta añade al panel mercadofresco-produccion:

El exitCode: 137 merece una nota: es 128 + 9, es decir, SIGKILL. En ECS casi siempre significa OOM: el contenedor superó su memory y el kernel lo mató. El síntoma es una tarea que reaparece cada pocos minutos sin que los logs de la aplicación digan nada, porque no hubo tiempo de escribir nada.

El plan de Marta separa lo que se contenerizará ahora, lo que se contenerizará después y lo que no se toca nunca.

Los pasos, en el orden en que reducen riesgo:

1. Escribir el Dockerfile y ejecutarlo en local. Antes de tocar AWS, la imagen debe arrancar y responder 200 en /salud en el portátil de Luis.
2. Crear los repositorios de ECR con inmutabilidad, escaneo mejorado y ciclo de vida, y añadir la fase de construcción de imagen al proyecto build-mercadofresco-tienda.
3. Crear el clúster ecs-mercadofresco en desarrollo, con un proveedor de capacidad sobre un ASG pequeño de instancias con la AMI optimizada para ECS.
4. Registrar la definición de tarea y lanzar una tarea suelta con run-task. Aquí aparecen los errores de rol de ejecución, secretos y grupos de seguridad, y aquí es donde deben aparecer.
5. Crear el grupo de destino de tipo ip y el servicio en desarrollo, y validar con las pruebas de humo del proyecto build-mercadofresco-humo (08-02).
6. Repetir en preproducción con la carga sintética del viernes, midiendo tiempo de arranque de tarea y comparándolo con los 120 segundos actuales.
7. En producción, convivencia: el mismo ALB con dos grupos de destino y un reparto ponderado —90 % al ASG, 10 % al servicio de ECS—, subiendo el peso a lo largo de dos semanas.
8. Retirar el ASG y la AMI cuando el servicio lleve dos semanas al 100 % sin incidentes, y borrar la plantilla de lanzamiento del CDK en un PR que deja constancia.

El paso 7 es el que hace que esto sea una migración y no un salto de fe. Con el reparto ponderado del ALB (03-03), un problema en el servicio de ECS afecta al 10 % de las peticiones durante el tiempo que se tarde en poner el peso a cero, que son segundos.

ECS no cuesta nada. El plano de control, las definiciones de tarea, los servicios y los despliegues son gratuitos. Lo que se paga con el tipo de lanzamiento EC2 es exactamente lo que ya se pagaba: las instancias, sus volúmenes EBS y la transferencia de datos.

La comparación honesta para MercadoFresco, con la tienda contenerizada sobre las mismas instancias:

El ahorro de esta lección no viene de ECS sino de la densidad: los trabajadores tenían su propio ASG con sus propias instancias, muchas veces ociosas, y en un clúster compartido se empaquetan con la tienda. El ahorro grande —eliminar la capacidad ociosa por completo— llega con Fargate en 10-02, y el análisis fino de costes, en el módulo 11. La limpieza, en este orden estricto:

El paso 4 es el único imprescindible desde el punto de vista económico: borrar el clúster de ECS no borra las instancias EC2, que siguen facturando alegremente sin nada que ejecutar. Es el residuo más caro de esta lección.

Error: usar latest en la definición de tarea. Produce despliegues no reproducibles y reversiones imposibles. Consejo: etiqueta con v1.6.0-a3f9c21 y despliega por digest; que el pipeline sea el único que decide qué digest va a cada entorno.

Error: confundir el rol de ejecución con el de tarea. Media hora perdida por cada incidente. Consejo: si la tarea no llega a arrancar, mira el rol de ejecución; si la aplicación falla llamando a AWS, el de tarea. Los mensajes CannotPullContainerError y ResourceInitializationError son siempre del de ejecución.

Error: no fijar --health-check-grace-period-seconds. La aplicación tarda en calentar, el ALB la mata, ECS la repone, bucle infinito. Consejo: mide el tiempo real hasta el primer 200 en /salud y pon el doble.

Error: COPY . . sin .dockerignore. Mete .git completo y ficheros .env en la imagen. Consejo: el .dockerignore se escribe antes que el Dockerfile, no después.

Error: capas en mal orden. COPY . . antes de pip install invalida la caché en cada commit. Consejo: de lo que menos cambia a lo que más: base, sistema, dependencias, código.

Error: contenedor como root con sistema de archivos escribible. Es innecesario y convierte cualquier fallo de la aplicación en escritura de binarios. Consejo: USER numérico, readonlyRootFilesystem: true y un volumen efímero para /tmp.

Error: olvidar el límite de ENI con awsvpc. Una m5.large ejecuta dos tareas y el clúster escala «sin motivo». Consejo: activa awsvpcTrunking a nivel de cuenta antes de dimensionar nada.

Error: awslogs en modo bloqueante. Un retraso de CloudWatch Logs frena la aplicación. Consejo: mode: non-blocking con max-buffer-size explícito en todos los servicios con tráfico de usuario.

Error: política de ciclo de vida agresiva. Borra la imagen a la que había que revertir. Consejo: conserva al menos diez versiones publicadas y prueba la política en seco antes de aplicarla.

Consejo: activa el circuit breaker con reversión en todos los servicios desde el primer día. No tiene coste y convierte un despliegue roto en un incidente de tres minutos que se resuelve solo.

Consejo: fija la retención de los grupos de registros de ECS. Con awslogs-create-group el grupo nace sin caducidad, y con tareas efímeras el volumen de logs crece más rápido de lo que nadie espera.

Consejo: etiqueta las tareas con propagateTags: SERVICE. Es la única forma de que las cinco etiquetas obligatorias lleguen a la tarea y de que el módulo 11 pueda repartir costes.

Consejo: mantén la definición de tarea en el CDK. El ecs.FargateTaskDefinition o ecs.Ec2TaskDefinition de 09-02 genera roles con permisos mínimos automáticamente con los métodos grant*, incluidos los de KMS que casi nadie recuerda.

Escribe el Dockerfile completo del componente de trabajadores de MercadoFresco, que consume cola-mercadofresco-pedidos, escribe en Aurora y publica en el tema mercadofresco-pedido-confirmado. Es una aplicación Python sin servidor HTTP: no expone puertos y no puede usar un HEALTHCHECK basado en curl. Resuelve (a) cómo haces la comprobación de estado sin HTTP y por qué ECS la necesita igualmente; (b) qué cambia respecto al Dockerfile de la tienda en cuanto a etapas, usuario y .dockerignore; (c) cómo gestionas el apagado ordenado cuando ECS envía SIGTERM en mitad del procesamiento de un mensaje; y (d) qué stopTimeout pones y con qué relación respecto al tiempo de visibilidad de la cola.

Luis registra la definición de tarea de la tienda y lanza el servicio en desarrollo. Ninguna tarea llega a estado RUNNING. En la consola aparecen, en distintos intentos, estos tres motivos de parada:

1. CannotPullContainerError: pull access denied for 555566667777.dkr.ecr.eu-west-1.amazonaws.com/mercadofresco/tienda, repository does not exist or may require 'docker login'
2. ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secret from asm: AccessDeniedException
3. La tarea llega a RUNNING, pero el servicio la mata a los 90 segundos y arranca otra, indefinidamente.

Para cada uno: diagnostica la causa exacta, indica dónde lo comprobarías, y da la corrección concreta. Para el tercero, explica además por qué el desired count nunca se estabiliza y qué dos configuraciones distintas podrían estar causándolo.

MercadoFresco despliega 4,8 veces por semana a producción, mantiene entre 6 y 10 ramas de característica vivas a la vez y necesita poder revertir hasta cuatro versiones atrás en producción. Cumplimiento exige poder demostrar, para cualquier día de los últimos 12 meses, qué imagen exacta estaba en producción. Diseña (a) el esquema completo de etiquetado de imágenes, incluyendo qué etiquetas lleva una imagen de rama y cuáles una de producción; (b) la política de ciclo de vida completa en JSON, con sus prioridades; (c) cómo satisfaces el requisito de cumplimiento de 12 meses sin guardar 250 imágenes; y (d) qué riesgo concreto tendría poner la regla de imágenes sin etiqueta con prioridad 1.

Solución 1

(a) La comprobación sin HTTP. El bucle de sondeo escribe /tmp/latido con la marca de tiempo tras cada ciclo de ReceiveMessage, y trabajadores.salud devuelve error si el fichero tiene más de 90 segundos. ECS la necesita igualmente porque un trabajador colgado no muere: se queda esperando en un socket, deja de consumir la cola y el servicio no se entera. Sin comprobación de estado, ese trabajador zombi cuenta como capacidad sana y la cola crece con cuatro tareas «vivas». Con el HEALTHCHECK, ECS lo mata y lo repone. Como readonlyRootFilesystem estará activo, /tmp debe ir montado como volumen efímero.

(b) Qué cambia respecto a la tienda. La estructura multietapa es idéntica —es el patrón, no la aplicación—. No hay EXPOSE ni portMappings porque nadie llama al trabajador. No hace falta curl, lo que permite una imagen aún más pequeña y una superficie de ataque menor: el HEALTHCHECK usa el propio Python. El UID es distinto (10002) por higiene, para que los procesos sean distinguibles en el anfitrión. Y el .dockerignore es el mismo, con una adición importante: el directorio de datos de prueba con mensajes de ejemplo, que puede contener datos que parecen reales y no deben viajar en una imagen.

(c) Apagado ordenado. El proceso registra un manejador de SIGTERM que activa una bandera; el bucle principal la comprueba antes de pedir el siguiente mensaje, no en mitad del procesamiento. El mensaje en curso se termina y se borra de la cola con DeleteMessage; después el proceso sale con código 0. Si el mensaje no se puede terminar a tiempo, no se borra: al expirar el tiempo de visibilidad volverá a la cola y otro trabajador lo procesará, y de ahí la importancia de la idempotencia con mercadofresco-idempotencia (07-05). El error a evitar es borrar el mensaje al recibirlo: entonces el SIGKILL lo pierde para siempre.

(d) stopTimeout y visibilidad. El procesamiento de un pedido tarda como máximo unos 20 segundos, así que stopTimeout: 30 da margen suficiente. La relación con el tiempo de visibilidad de la cola es la clave: el tiempo de visibilidad debe ser mayor que stopTimeout más el tiempo de procesamiento, para que un mensaje interrumpido no reaparezca mientras el trabajador antiguo aún lo está terminando y un segundo trabajador lo procese en paralelo. Con procesamiento de 20 s y stopTimeout de 30 s, un tiempo de visibilidad de 180 s es holgado y correcto. El máximo de ECS para stopTimeout es 120 segundos, lo que además obliga a que ningún procesamiento individual dure más que eso.

Solución 2

Motivo 1: CannotPullContainerError — permisos del rol de ejecución o red. Hay tres causas posibles y se distinguen rápido. La primera, que el rol de ejecución no tenga los permisos de ECR (GetAuthorizationToken, BatchGetImage, GetDownloadUrlForLayer); se comprueba en CloudTrail (05-03) buscando AccessDenied sobre ecr: con el principal del rol. La segunda, que la política del repositorio en la cuenta de herramientas no autorice a la cuenta de desarrollo: es cruzado y hacen falta las dos políticas, la del rol y la del repositorio. La tercera, y la que produce este mensaje engañoso exacto, es de red: las tareas están en snet-mercadofresco-app-a sin ruta hacia ECR, porque el NAT está caído o porque no hay endpoints de VPC. Se distingue mirando si el mensaje llega tras un tiempo de espera largo (red) o inmediato (permisos). Corrección: los permisos de la política de ejecución más los endpoints de ecr.api, ecr.dkr y el de S3 —las capas se descargan de S3, y ese es el que todo el mundo olvida—.

Motivo 2: ResourceInitializationError ... unable to retrieve secret from asm. Es inequívoco: el rol de ejecución no puede leer mercadofresco/produccion/rds/mfadmin. Dos causas, y hay que revisar las dos: falta secretsmanager:GetSecretValue sobre el ARN del secreto, o falta kms:Decrypt sobre alias/mercadofresco-datos, porque el secreto está cifrado con una clave gestionada por el cliente (04-02) y leer el secreto exige descifrarlo. La segunda es la que más se olvida, y el mensaje de error no menciona KMS. Se comprueba en CloudTrail con el evento GetSecretValue fallido. Corrección: añadir ambos permisos al rol de ejecución —no al de tarea, que es el error siguiente que cometerá Luis— y verificar que la política de la clave KMS incluya al rol como usuario.

Motivo 3: el bucle infinito de arranque y muerte. La tarea llega a RUNNING, luego muere. Dos configuraciones pueden causarlo:

• El período de gracia de la comprobación de estado. Si la aplicación tarda 60 segundos en responder 200 en /salud —conexión a Aurora, precarga de catálogo desde ElastiCache— y el grupo de destino la declara no sana antes, el servicio la desregistra y la mata. ECS repone, y el ciclo se repite. Corrección: --health-check-grace-period-seconds al doble del tiempo medido, y revisar el umbral del grupo de destino (HealthyThresholdCount, Interval, Timeout).
• El grupo de seguridad. Si sg-mercadofresco-tienda no permite la entrada desde sg-mercadofresco-alb en el puerto 8080 —y no en el 80, que es lo que estaba configurado cuando el destino era la instancia—, la comprobación del ALB nunca pasa. Con awsvpc, el SG se aplica a la tarea y el puerto es el del contenedor, no un puerto dinámico del anfitrión.

Por qué el desired count nunca se estabiliza: porque el servicio no distingue entre «la tarea murió» y «la tarea nunca llegó a estar sana». Repone indefinidamente, consumiendo cuota de ejecución y llenando el registro de eventos. Y es exactamente el escenario para el que existe el circuit breaker de despliegue: con enable: true y rollback: true, tras el umbral de fallos consecutivos el despliegue se declara fallido y se revierte, en lugar de girar en vacío durante horas. Si Luis lo hubiera activado, el diagnóstico habría llegado como un evento de despliegue fallido en lugar de como un panel que no se estabiliza.

Solución 3

(a) Esquema de etiquetado. Cada imagen lleva varias etiquetas, porque una etiqueta es un puntero y se pueden poner varios al mismo digest:

La etiqueta cache no puede convivir con IMMUTABLE, así que va en un repositorio distinto —mercadofresco/tienda-cache— con inmutabilidad desactivada y ciclo de vida de tres días. Es el matiz que se descubre al aplicar la inmutabilidad y romper la construcción.

(b) Política de ciclo de vida.

Las prioridades van de diez en diez para poder intercalar reglas después sin renumerar todo, que es la misma disciplina de las reglas de WAF (04-05). Doce versiones publicadas cubren con holgura las cuatro reversiones exigidas y unas dos semanas y media de despliegues.

(c) El requisito de cumplimiento de 12 meses. No se resuelve guardando imágenes, se resuelve guardando evidencia. Cumplimiento no necesita poder ejecutar la imagen de hace once meses; necesita poder demostrar qué imagen estaba desplegada. Tres fuentes lo dan sin coste de almacenamiento:

• CloudTrail (05-03) registra cada RegisterTaskDefinition y UpdateService con el digest exacto y quién lo hizo; con el trail de organización en la cuenta de seguridad y S3 con Object Lock, la evidencia es inmutable y consultable con Athena.
• El repositorio Git mercadofresco-tienda conserva el commit y el imagen.json del artefacto de cada ejecución del pipeline.
• AWS Config (05-04) mantiene el histórico de configuración del servicio de ECS.

Si además hiciera falta poder reconstruir una imagen antigua, la respuesta es reconstruirla desde el commit con el Dockerfile reproducible —versiones fijadas y hashes—, no guardarla.

(d) El riesgo de poner la regla de imágenes sin etiqueta con prioridad 1. Sería catastrófico por cómo evalúa ECR: una imagen solo la afecta la primera regla que la selecciona, y una regla de untagged con prioridad 1 se evalúa antes que todas. Cuando una imagen publicada pierde su etiqueta —porque otra imagen la reutiliza, o durante una replicación, o al retirar una etiqueta v1.6.0 a mano—, pasa a ser untagged y la regla 1 la borra en 24 horas, incluso si es la que está ejecutando producción. Las reglas de untagged van siempre al final, con la prioridad más alta, y solo después de que las reglas específicas hayan tenido su oportunidad de retener lo que importa.

MercadoFresco ya no despliega máquinas: despliega imágenes. Esta lección ha sustituido los tres artefactos que dolían —la AMI, el ciclo de parcheo y el arranque de dos minutos— por un Dockerfile de cuarenta líneas, un registro y un orquestador.

Tienes claro qué es un contenedor de verdad: namespaces y cgroups sobre un kernel compartido, no una máquina virtual pequeña, con lo que eso implica en arranque (segundos frente a minutos), en tamaño (megas frente a gigas), en densidad y en portabilidad —el mismo artefacto en el portátil de Luis y en producción, byte a byte—, y con la advertencia honesta sobre el aislamiento que el marketing suele omitir. Tienes el Dockerfile de la tienda con construcción multietapa que deja los compiladores fuera, usuario 10001 sin privilegios, versiones fijadas con hashes, HEALTHCHECK coherente con /salud y el orden de capas que convierte una construcción de tres minutos en una de cuarenta segundos. Y el .dockerignore que se escribe antes que el Dockerfile, no después de haber metido .git en una imagen.

Tienes Amazon ECR con mercadofresco/tienda y mercadofresco/trabajadores: autenticación por token temporal, inmutabilidad de etiquetas, el esquema v1.6.0-a3f9c21 que ata cada imagen a un commit, y la regla que hay que interiorizar —la etiqueta sirve para que un humano encuentre la imagen; el digest, para que la máquina la despliegue—. Con las políticas de ciclo de vida y sus tres trampas, el escaneo mejorado de Inspector que sí ve las dependencias de Python y avisa cuando una imagen ya desplegada deja de estar limpia, la replicación desde la cuenta de herramientas 555566667777 hacia producción, y el cifrado con alias/mercadofresco-datos que exige acordarse de la política de la clave.

Y tienes Amazon ECS: clúster ecs-mercadofresco, la definición de tarea mercadofresco-tienda con secretos inyectados desde Secrets Manager y Parameter Store, registros no bloqueantes, sidecar de X-Ray y awsvpc con grupo de seguridad por tarea; el servicio svc-mercadofresco-tienda detrás de tg-mercadofresco-tienda con período de gracia, despliegue 100/200 y circuit breaker con reversión automática; el autoescalado por ALBRequestCountPerTarget con enfriamientos asimétricos; y la distinción que ahorra media hora en cada incidente: el rol de ejecución trabaja para AWS, el rol de tarea trabaja para tu código.

Pero queda un residuo, y se ve en la tabla de proveedores de capacidad. Debajo del clúster siguen existiendo instancias EC2: hay que elegir su tamaño, mantener su AMI optimizada para ECS, vigilar que el escalado gestionado no se quede corto y aceptar que, cuando no hay hueco para una tarea nueva, hace falta una instancia nueva y una instancia tarda dos minutos en arrancar. Es el mismo número del que huíamos. Lo hemos escondido detrás de un proveedor de capacidad, no lo hemos eliminado. Y sigue habiendo capacidad ociosa que se paga: dos instancias encendidas a las cuatro de la mañana de un martes.

En 10-02, «AWS Fargate», las instancias desaparecen. Sin AMI que mantener, sin clúster que escalar, sin empaquetado de tareas en máquinas, sin capacidad ociosa: se declara cuánta CPU y cuánta memoria necesita cada tarea y AWS pone el resto. Verás las combinaciones válidas de recursos, el ahorro real de Graviton, cómo se depura sin SSH con ECS Exec, los endpoints de VPC que evitan pagar el NAT, el escalado programado para el viernes a las 17:00, y Fargate Spot para los trabajadores de la cola. Y la comparativa honesta entre Fargate, EC2 y Lambda, con la decisión razonada de MercadoFresco para cada componente.