El mòdul 9 va deixar una infraestructura reproduïble, governada i repartida en cinc comptes, i una frase incòmoda al final: la botiga de MercadoFresco continua vivint en instàncies EC2 que cal apedaçar, sobre una AMI que cal reconstruir cada vegada que canvia una dependència, i que triguen dos minuts a arrencar. El divendres a les 19:00, amb 900 comandes per hora, aquests dos minuts són exactament el temps que els clients passen esperant mentre l'ASG fa la seva feina.

Aquesta lliçó ataca el problema per l'arrel: substituir la màquina pel contenidor. Veuràs què és un contenidor i en què es diferencia de debò d'una màquina virtual, com es construeix la imatge de la botiga amb un Dockerfile seriós, on es guarda aquesta imatge (Amazon ECR) i qui l'executa (Amazon ECS). Al final tindràs la botiga i els treballadors de la cua de comandes contenidoritzats, amb la seva definició de tasca, el seu servei darrere de l'ALB que ja existeix i el seu autoescalat.

Avís de cost. Amazon ECS no costa res per si mateix: és un pla de control gratuït, i només pagues el còmput que executa les tasques —les instàncies EC2 en aquesta lliçó, Fargate a 10-02—. Amazon ECR cobra 0,10 USD per GB i mes d'emmagatzematge i la transferència de dades cap a fora de la regió; la capa gratuïta inclou 500 MB durant 12 mesos. L'escaneig bàsic és gratuït; l'escaneig millorat amb Amazon Inspector es cobra per imatge escanejada. Segueix tots els exercicis amb etiquetes correctes i esborra al final el que hagis creat. Totes les dades, comptes i identificadors són ficticis.

1. Els tres problemes que va deixar el mòdul 9
2. Què és un contenidor i en què es diferencia d'una màquina virtual
3. Imatge, capes, registre i contenidor en execució
4. El Dockerfile de la botiga de MercadoFresco
5. .dockerignore, mida i memòria cau de capes
6. Amazon ECR: el registre que substitueix les AMI
7. Etiquetatge, immutabilitat i cicle de vida de les imatges
8. Escaneig de vulnerabilitats: bàsic i millorat
9. Replicació, xifratge i política de repositori
10. Amazon ECS: clúster, definició de tasca, tasca i servei
11. Tipus de llançament, agent d'ECS i proveïdors de capacitat
12. La definició de tasca de la botiga, comentada
13. Rol d'execució de la tasca enfront del rol de la tasca
14. Mode de xarxa awsvpc i què implica
15. El servei: ALB, comprovacions d'estat i col·locació
16. Desplegaments: renovats, percentatges i interruptor de desplegament
17. Autoescalat del servei i descobriment amb Cloud Map
18. Observabilitat: Container Insights, registres i X-Ray
19. La migració de MercadoFresco
20. Cost i neteja
21. Errors habituals i consells
22. Exercicis
23. Conclusió

Convé anomenar-los amb precisió abans de resoldre'ls, perquè cadascun té una causa diferent i el contenidor els resol per camins diferents.

El contenidor no elimina el sistema operatiu del planeta —continua havent-hi un kernel a sota—, però canvia on viu la frontera entre allò que és teu i allò que és d'AWS. L'apedaçament del sistema operatiu base passa a ser una línia del Dockerfile i una reconstrucció de trenta segons, no una finestra de manteniment; amb Fargate (10-02), l'amfitrió deixa d'existir per a tu. L'AMI desapareix com a artefacte i el seu lloc l'ocupa la imatge, que es construeix a CodeBuild en dos minuts, es versiona per commit i es guarda en un registre. I l'arrencada deixa d'incloure l'arrencada d'una màquina: una tasca d'ECS sobre una instància existent arrenca en 5-15 segons, i sobre Fargate en 30-45 inclosa l'ENI. Enfront dels 120 segons actuals, és una altra categoria de resposta.

Un contenidor és un procés del sistema operatiu amfitrió a qui el kernel ha mentit sobre el món: veu el seu propi sistema de fitxers, la seva pròpia taula de processos, la seva pròpia xarxa i els seus propis límits de CPU i memòria. Aquesta mentida la construeixen dos mecanismes del kernel de Linux: els namespaces (aïllament del que es veu) i els cgroups (limitació del que es consumeix).

Una màquina virtual és una altra cosa: un hipervisor emula maquinari complet i a dins arrenca un kernel propi, amb el seu sistema d'arrencada, els seus serveis i el seu sistema de fitxers.

La diferència pràctica que més importa per a MercadoFresco és a dues files: arrencada i portabilitat. L'arrencada resol el pic dels divendres. La portabilitat resol la frase que el Luis repeteix des del mòdul 8: «a la meva màquina funciona». Amb una imatge, a la seva màquina funciona exactament el mateix que a producció, byte a byte, perquè és el mateix artefacte.

I un advertiment honest sobre l'aïllament, perquè el màrqueting sol ometre'l: els contenidors comparteixen el kernel de l'amfitrió. Una vulnerabilitat d'escapada de contenidor permet, en teoria, saltar d'un contenidor a un altre a la mateixa màquina. Per això AWS no executa contenidors de clients diferents al mateix kernel: Fargate (10-02) dona a cada tasca la seva pròpia frontera de virtualització lleugera. Per a MercadoFresco, on tots els contenidors són seus, el risc és acceptable; per a una plataforma multiinquilí, no ho seria.

Quatre paraules que es confonen contínuament i que convé fixar:

• Imatge: un artefacte de només lectura que conté el sistema de fitxers i les metadades necessàries per arrencar el procés. És immutable. S'identifica per un digest (sha256:...) i, opcionalment, per una o diverses etiquetes.
• Capa: una imatge no és un bloc monolític sinó una pila de capes, cadascuna amb les diferències que va introduir una instrucció del Dockerfile. Les capes es comparteixen entre imatges: si deu imatges fan servir python:3.12-slim, aquesta capa s'emmagatzema i es descarrega una sola vegada.
• Registre: el magatzem d'imatges. Amazon ECR és el registre gestionat d'AWS; Docker Hub és el registre públic més conegut.
• Contenidor: una imatge en execució, amb una capa d'escriptura efímera a sobre. En aturar el contenidor, aquesta capa desapareix.

La conseqüència operativa de les capes és enorme i defineix com s'escriu un Dockerfile: si una capa canvia, totes les de sota s'invaliden. Posar COPY . . abans de pip install significa que qualsevol canvi en qualsevol fitxer del projecte obliga a reinstal·lar totes les dependències. Posar primer el requirements.txt i després el codi significa que un canvi de codi reaprofita la capa de dependències i la construcció baixa de tres minuts a vint segons.

La botiga és una aplicació Python amb Gunicorn darrere de l'ALB. Aquest és el seu Dockerfile complet, amb construcció multietapa, usuari sense privilegis, versions fixades i un HEALTHCHECK coherent amb el /salud que fa servir tg-mercadofresco-tienda des del mòdul 3.

Cada decisió d'aquest fitxer respon a un problema concret:

• python:3.12.4-slim-bookworm amb versió completa, no python:3.12 ni python:latest. Una etiqueta flotant converteix una construcció reproduïble en una loteria: la mateixa ordre, executada dues setmanes després, produeix una altra imatge. És la disciplina del bloqueig d'aws-cdk-lib a 09-02. I slim en lloc de la imatge completa baixa d'~1,0 GB a ~130 MB: la diferència és documentació i utilitats que a producció són superfície d'atac, no funcionalitat.
• Multietapa. build-essential i libpq-dev pesen més de 300 MB i només calen per compilar. Amb dues etapes es queden a la primera. Una imatge de producció amb compilador és una imatge on un atacant pot compilar.
• --require-hashes amb un fitxer de bloqueig. Fixa no només la versió sinó el hash de cada roda descarregada. Protegeix de l'atac de substitució de paquet a l'índex.
• USER 10001 amb un UID numèric explícit. ECS i Kubernetes poden imposar «no executar com a root»; un UID numèric permet verificar la regla sense resoldre noms, i el --no-create-home --shell /usr/sbin/nologin evita que aquest usuari serveixi per a res més.
• HEALTHCHECK amb --start-period. Els 20 segons de gràcia eviten que el contenidor es marqui com a no sa mentre Gunicorn aixeca els seus processos fills. A ECS és complementari al del grup de destinació: el del contenidor decideix si ECS reinicia la tasca; el de l'ALB decideix si li envia trànsit.
• ENTRYPOINT + CMD separats. L'ENTRYPOINT fixa l'executable i el CMD els arguments per omissió, de manera que la definició de tasca pot sobreescriure només els arguments (command) sense canviar el binari.

El .dockerignore és el fitxer que més gent oblida i el que més problemes causa. Sense ell, COPY . . fica dins la imatge el directori .git complet —que pot pesar centenars de megues i conté l'historial, inclosos secrets esborrats—, l'entorn virtual local, la memòria cau de proves i els fitxers .env amb credencials de desenvolupament.

Al fitxer real va una entrada per línia; aquí s'agrupen per família. Regles de mida i memòria cau que s'apliquen en aquest ordre:

El punt que més sorprèn és el de «netejar a la mateixa capa». Com que cada capa guarda diferències, esborrar a la capa 7 un fitxer creat a la capa 5 no redueix la mida de la imatge: el fitxer continua a la capa 5 i es continua descarregant. Només desapareix de la vista. Un RUN apt-get install ... seguit d'un RUN rm -rf /var/lib/apt/lists/* en línia a part no estalvia res.

A CodeBuild (08-02), la memòria cau s'aprofita amb docker pull "$REPO:cache" || true seguit de docker build --cache-from "$REPO:cache" --build-arg BUILDKIT_INLINE_CACHE=1 ..., apuntant a la imatge anterior del registre. Amb aquest patró, la construcció de la botiga baixa d'uns 3 minuts a 35-50 segons quan només canvia el codi, que és el cas habitual.

Amazon Elastic Container Registry és el registre d'imatges gestionat d'AWS: privat per omissió, integrat amb IAM, amb xifratge en repòs, escaneig de vulnerabilitats, replicació i polítiques de cicle de vida. Ocupa exactament el lloc que ocupava l'AMI a l'arquitectura anterior, amb dues diferències: és regional però replicable, i la unitat de versió és el digest, no un identificador opac. MercadoFresco crea dos repositoris al compte d'eines 555566667777, que és on viu el pipeline des de 09-04:

El testimoni dura 12 hores i va associat al principal d'IAM que va fer la crida. A CodeBuild, la línia anterior és literalment la primera de la fase pre_build del buildspec.yml, i el rol del projecte de compilació necessita ecr:GetAuthorizationToken (que és a nivell de compte, amb Resource: "*") més els permisos d'escriptura sobre el repositori concret.

latest és una etiqueta com qualsevol altra: no significa «la més recent», només significa «la que algú va etiquetar així l'última vegada». I com a etiqueta de desplegament és directament perillosa:

MercadoFresco fa servir l'esquema que ja va introduir el mòdul 8: versió semàntica més SHA curt del commit, per exemple v1.6.0-a3f9c21. La versió semàntica la llegeix un humà; el SHA la lliga a un commit exacte del repositori mercadofresco-tienda. I a la definició de tasca que es desplega, no es fa servir l'etiqueta sinó el digest:

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

La raó és subtil però decisiva: una etiqueta és un punter mutable —encara que la immutabilitat la protegeixi dins del repositori, una fallada de configuració o una replicació mal feta poden desalinear-la—, mentre que el digest és el contingut. Desplegar per digest garanteix que allò que arrenca avui a producció és exactament allò que va passar les proves ahir a preproducció, bit a bit. L'etiqueta serveix perquè un humà trobi la imatge; el digest, perquè la màquina la desplegui.

Amb --image-tag-mutability IMMUTABLE, ECR rebutja qualsevol intent de reutilitzar una etiqueta ja existent. Això converteix un accident silenciós —sobreescriure v1.6.0-a3f9c21 amb un altre contingut— en un error de compilació visible.

L'altre control imprescindible és la política de cicle de vida. Sense ella, el repositori creix indefinidament: MercadoFresco desplega 4,8 vegades per setmana, amb imatges d'uns 220 MB, i sumant-hi les de les branques de característica el registre engreixa uns 6 GB a l'any per repositori. No són diners, però sí que és soroll i sí que complica les auditories.

Tres advertiments sobre aquestes polítiques, que són la font número u de sotracs amb ECR:

1. Les regles s'avaluen per prioritat i una imatge només l'afecta la primera que la selecciona. Una regla àmplia amb prioritat 1 anul·la tot el que vingui darrere.
2. L'expiració no comprova si la imatge s'està fent servir. ECR esborrarà la imatge que està executant producció si la regla la selecciona. Per això la regla 1 conserva deu versions publicades i no dues: cal cobrir el pitjor cas de reversió.
3. Es prova primer en sec. La consola ofereix una vista prèvia de la política sobre el contingut real del repositori; executar-la abans d'aplicar és obligatori.

ECR ofereix dos modes d'escaneig, i la diferència entre tots dos és més gran del que suggereix el nom.

Per a MercadoFresco importa la fila d'«abast»: la majoria de les vulnerabilitats reals de la botiga són a dependències de Python —una versió antiga d'una llibreria de serialització, per exemple—, i l'escaneig bàsic no les veu. La Marta activa l'escaneig millorat al compte d'eines i connecta el resultat a la porta de qualitat del pipeline:

La política acordada és pragmàtica i per això es compleix: CRITICAL bloqueja sempre; HIGH bloqueja excepte excepció documentada amb data de caducitat; MEDIUM i LOW generen un tiquet. Una política que bloqueja amb MEDIUM no sobreviu dues setmanes: algú la desactiva i llavors no en queda cap. L'escaneig continu té a més una propietat que el bàsic no pot donar: la imatge que avui és neta i demà no. Quan apareix una CVE nova que afecta una imatge ja desplegada, Inspector emet un esdeveniment a EventBridge i bus-mercadofresco (07-03) l'encamina cap a alertas-mercadofresco. Aquest avís és el substitut directe del cicle d'apedaçament de les instàncies.

La imatge es construeix al compte d'eines 555566667777 i s'executa a producció 111122223333, preproducció 222233334444 i desenvolupament 333344445555. Hi ha dues maneres de resoldre-ho:

MercadoFresco fa servir repositori central compartit per a desenvolupament i preproducció, i replicació cap a producció, perquè vol que un incident al compte d'eines no impedeixi que producció escali el divendres a la tarda.

La segona línia de destinació replica a més a eu-central-1, que és on MercadoFresco tindria el seu pla de recuperació si la regió principal fallés. La replicació és asíncrona i triga de segons a alguns minuts segons la mida; el pipeline ha d'esperar que la imatge existeixi a destinació abans de desplegar, amb un wait explícit.

La política de repositori autoritza els comptes de l'organització a descarregar, sense autoritzar ningú a pujar:

És el mateix patró de 09-04: aws:PrincipalOrgID en lloc d'una llista de comptes que caldria mantenir a mà. I la separació entre qui llegeix i qui escriu és la que converteix el pipeline en l'únic camí cap a producció. El xifratge amb alias/mercadofresco-datos (04-02) té una conseqüència que sorprèn: si la clau és del compte d'eines i producció ha de descarregar la imatge, la política de la clau KMS ha d'autoritzar els principals de producció a fer servir kms:Decrypt. És l'error clàssic de les claus gestionades pel client entre comptes: la política del repositori està bé i la descàrrega falla igualment, amb un missatge que parla d'accés denegat i no esmenta KMS.

Amazon Elastic Container Service és l'orquestrador de contenidors propi d'AWS. El seu model té quatre objectes i convé no confondre'ls mai:

La correspondència amb el que MercadoFresco ja té és gairebé un a un, i és la millor manera d'entendre ECS: el servei fa el que feia l'ASG, la definició de tasca fa el que feia la plantilla de llançament més l'AMI, i la tasca substitueix la instància. Les definicions de tasca són versionades i immutables: cada register-task-definition crea una revisió nova (mercadofresco-tienda:23) i les anteriors continuen existint. Revertir un desplegament és apuntar el servei a la revisió anterior, i això és un canvi d'un camp.

ECS executa les tasques de dues maneres, i l'elecció canvia molt més el dia a dia que l'arquitectura.

Al tipus de llançament EC2, cada instància executa l'agent d'ECS (amazon-ecs-agent), un contenidor que es registra al clúster, informa dels recursos disponibles i rep les ordres del pla de control; la manera correcta de crear aquestes instàncies és amb l'AMI optimitzada per a ECS, que ja porta l'agent i el runtime. Els proveïdors de capacitat són l'abstracció que evita gestionar l'escalat del clúster a mà. Un proveïdor de capacitat per a EC2 s'associa a un ASG i activa l'escalat gestionat: ECS calcula quantes instàncies calen per a les tasques pendents i ajusta la capacitat desitjada de l'ASG pel seu compte.

targetCapacity: 90 significa «mantén el clúster al 90 % d'ocupació»: deixa un 10 % de marge per absorbir una pujada sense esperar una instància nova. I managedTerminationProtection evita que l'ASG acabi una instància que encara executa tasques, la fallada més molesta del model EC2. Tot i així, aquest 2 min de la taula continua sent-hi en la pitjor situació: si no hi ha lloc, cal una instància, i una instància triga el que triga. És exactament el motiu pel qual MercadoFresco no es quedarà aquí i 10-02 existeix.

Aquesta és la definició completa de mercadofresco-tienda, amb secrets injectats, registres cap a CloudWatch i mode de xarxa awsvpc.

Els punts que cal entendre d'aquest JSON:

• CPU i memòria a dos nivells. El cpu i memory de la tasca són el total reservat; els de cada contenidor reparteixen aquest total. Amb Fargate, els valors de tasca són obligatoris i només admeten combinacions concretes (10-02); amb EC2 es poden ometre i llavors la reserva es fa només per contenidor.
• memoryReservation enfront de memory. memoryReservation és el mínim garantit que ECS fa servir per col·locar la tasca; memory és el límit dur: si el contenidor el supera, el kernel el mata amb OOM. Fixar només memory malgasta; fixar només memoryReservation deixa que un contenidor amb fuita es mengi la instància. Es posen tots dos.
• essential: true a la botiga i false al sidecar d'X-Ray. Si un contenidor essencial mor, ECS mata la tasca sencera i la reposa. El dimoni d'X-Ray no ha de tombar la botiga si cau.
• secrets en lloc d'environment per al que és sensible. L'agent d'ECS resol el valor a l'arrencada fent servir el rol d'execució i l'injecta com a variable d'entorn. Mai apareix a la definició de tasca, ni a la consola, ni a CloudTrail. La sintaxi :password:: selecciona una clau concreta del JSON del secret (04-03).
• mode: non-blocking als registres. És l'opció que evita la fallada més desagradable del controlador awslogs: si CloudWatch Logs va lent, en mode bloquejant l'aplicació s'atura esperant a escriure el seu registre. Amb non-blocking es perden línies en el pitjor cas, cosa infinitament millor que perdre comandes.
• readonlyRootFilesystem: true amb un volum per a /tmp. El sistema de fitxers de només lectura impedeix que un atacant escrigui binaris; el volum efímer dona el /tmp que Python necessita.
• stopTimeout: 30. Segons que ECS espera entre el SIGTERM i el SIGKILL. És el marge que té Gunicorn per acabar les peticions en curs durant un desplegament.

És la confusió número u de qui comença amb ECS, i produeix errors que semblen no tenir sentit: la tasca no arrenca però els permisos de l'aplicació estan bé, o la tasca arrenca i l'aplicació no pot llegir una cua.

I el rol de la tasca, que és el que fa servir el codi i per tant el que ha de ser mínim:

La regla mnemotècnica que evita el 90 % dels errors: el rol d'execució treballa per a AWS, el rol de tasca treballa per al teu codi. Si la fallada passa abans de veure ni un sol registre de l'aplicació, és el d'execució. Si la fallada apareix als registres de l'aplicació, és el de tasca.

Amb networkMode: awsvpc, cada tasca rep la seva pròpia interfície de xarxa elàstica (ENI) amb la seva pròpia IP privada dins de la VPC. Les conseqüències són concretes i totes rellevants per a MercadoFresco:

• Grups de seguretat per tasca. sg-mercadofresco-tienda s'aplica ara a la tasca, no a la instància. Dos serveis diferents a la mateixa instància poden tenir regles diferents, cosa impossible amb bridge.
• Sense conflictes de port. A bridge calia fer servir hostPort: 0 per a l'assignació dinàmica i el grup de destinació registrava instancia:port. Amb awsvpc, cada tasca escolta al seu propi 8080 i el grup de destinació és de tipus ip.
• La tasca consumeix una IP de la subxarxa. Amb snet-mercadofresco-app-a i -b de /20 hi ha adreces de sobres, però en subxarxes petites és un límit real que s'assoleix abans del que s'espera.
• Límit d'ENI per instància. Al tipus de llançament EC2, cada instància admet un nombre limitat d'ENI segons la seva mida. Sense l'ajust awsvpcTrunking activat (aws ecs put-account-setting-default --name awsvpcTrunking --value enabled), una m5.large només pot executar dues o tres tasques amb awsvpc, per molta CPU lliure que tingui. És un dels paranys més cars del model EC2.
• Sense accés al localhost de l'amfitrió. Els contenidors d'una mateixa tasca sí que es veuen entre ells per 127.0.0.1 —per això el sidecar d'X-Ray funciona amb AWS_XRAY_DAEMON_ADDRESS=127.0.0.1:2000—, però no veuen els contenidors d'altres tasques.

El servei és el que converteix la tasca en una cosa que es pot anomenar producció: manté el nombre desitjat, reposa el que mor, registra a l'ALB i gestiona els desplegaments.

Tres detalls que importen:

• --health-check-grace-period-seconds 60. És el període durant el qual el servei ignora l'estat del grup de destinació després d'arrencar una tasca. Sense ell, una aplicació que triga 40 segons a escalfar la memòria cau entra en un bucle infinit: l'ALB la marca com a no sana, ECS la mata, n'arrenca una altra, i així indefinidament. És l'error més frustrant de tots perquè no dona cap pista.
• Grup de destinació de tipus ip. Obligatori amb awsvpc. Si tg-mercadofresco-tienda es va crear al mòdul 3 amb tipus instance, cal crear un grup de destinació nou: el tipus no es pot canviar.
• Estratègies de col·locació (només amb tipus de llançament EC2, no s'apliquen a Fargate):

Per a la botiga, spread per AZ i després per instància. Per als treballadors de la cua, que són tolerants a fallades, binpack per memòria estalvia instàncies.

El desplegament per omissió d'ECS és l'actualització renovada (ECS rolling update). El servei arrenca tasques amb la revisió nova, espera que estiguin sanes al grup de destinació, drena i atura les velles, i repeteix. Els dos paràmetres que el governen són:

• minimumHealthyPercent: percentatge del desiredCount que ha de continuar sa durant el desplegament.
• maximumPercent: percentatge màxim que pot estar en execució alhora.

MercadoFresco fa servir 100 / 200 a producció i 50 / 100 a desenvolupament, on el cost importa més que la disponibilitat. Amb 100 / 200 i una arrencada de tasca de 15 segons, un desplegament complet de quatre tasques acaba en poc més d'un minut, enfront dels vuit o nou de l'ASG amb instàncies.

L'interruptor de desplegament és la xarxa de seguretat. Amb enable: true, ECS compta les fallades consecutives d'arrencada de tasca; en superar el llindar —calculat a partir del desiredCount, amb un mínim de 10— declara el desplegament fallit. Amb rollback: true, a més reverteix automàticament a l'última revisió que sí que funcionava.

Això substitueix, en el cas més freqüent, l'alarma manual: si la imatge nova té un error de configuració que impedeix arrencar, el desplegament s'atura i es reverteix sol. El que l'interruptor de desplegament no detecta és una imatge que arrenca bé i respon malament: per a això calen les alarmes de CloudWatch associades al desplegament, amb alarmNames a la configuració, i el blue/green. El desplegament blue/green amb CodeDeploy (08-03) és l'altra opció: es canvia el controlador de desplegament a CODE_DEPLOY, i CodeDeploy aixeca el conjunt verd complet a tg-mercadofresco-verde, permet provar-lo per un port de proves i desplaça el trànsit de cop o en canari. És el que MercadoFresco integra al pipeline a 10-02, quan el servei ja sigui sobre Fargate.

L'autoescalat d'ECS el proporciona Application Auto Scaling, el mateix servei que escala Aurora Serverless o DynamoDB. Es registra el servei com a destinació escalable i se li associa una política.

L'elecció de mètrica no és indiferent:

Per a la botiga, ALBRequestCountPerTarget amb destinació 120 és millor que la CPU per una raó de temps: el trànsit puja abans que la CPU, així que escalar per peticions avança la reacció entre 30 i 60 segons. I els refredaments són asimètrics a propòsit: 30 segons per créixer, 300 per decréixer. Créixer tard costa comandes; decréixer aviat costa una oscil·lació. Per als treballadors, la mètrica correcta és la profunditat de la cua dividida entre el nombre de tasques —el «retard per tasca» de 07-01—, calculada com a mètrica matemàtica de CloudWatch i feta servir en una política de seguiment de destinació personalitzada.

Quan un servei necessita cridar-ne un altre sense passar per l'ALB, la pregunta és com en troba la IP, que canvia amb cada tasca. AWS Cloud Map ho resol amb DNS: ECS registra i desregistra automàticament cada tasca en un espai de noms privat (aws servicediscovery create-private-dns-namespace --name interno.mercadofresco --vpc vpc-mercadofresco). Amb el servei configurat amb serviceRegistries, la botiga arriba a l'inventari a inventario.interno.mercadofresco i el DNS retorna les IP de les tasques sanes. Les alternatives són:

MercadoFresco encara no necessita això perquè la botiga és un monòlit darrere de l'ALB i tota la resta va per cues (mòdul 7). Quan la botiga es divideixi, ECS Service Connect serà l'opció preferible: dona mètriques per crida entre serveis sense instrumentar el codi.

Tot el del mòdul 5 continua valent, amb tres ajustos:

• Container Insights s'activa a nivell de clúster (aws ecs update-cluster-settings --cluster ecs-mercadofresco --settings name=containerInsights,value=enhanced) i publica mètriques de CPU, memòria, xarxa i disc per servei i per tasca a l'espai de noms ECS/ContainerInsights. Sense ell, CloudWatch només dona CPUUtilization i MemoryUtilization a nivell de servei, cosa que no basta per diagnosticar quin contenidor consumeix.

• Els registres van al grup /ecs/mercadofresco-tienda amb un flux per tasca. La conseqüència pràctica: com que les tasques són efímeres i es reposen constantment, l'única manera raonable de cercar és CloudWatch Logs Insights (05-01), no obrir fluxos a mà. I la retenció cal fixar-la explícitament: amb awslogs-create-group: true, el grup es crea sense caducitat i guarda per sempre.

• X-Ray funciona amb el sidecar de l'exemple. L'SDK de l'aplicació envia els segments per UDP a 127.0.0.1:2000, el dimoni els agrupa i els puja. L'alternativa moderna és l'AWS Distro for OpenTelemetry com a sidecar, que a més de traces recull mètriques. En tots dos casos, el rol de tasca —no el d'execució— necessita xray:PutTraceSegments.

Les mètriques noves que la Marta afegeix al tauler mercadofresco-produccion:

L'exitCode: 137 mereix una nota: és 128 + 9, és a dir, SIGKILL. A ECS gairebé sempre significa OOM: el contenidor va superar la seva memory i el kernel el va matar. El símptoma és una tasca que reapareix cada pocs minuts sense que els registres de l'aplicació diguin res, perquè no hi va haver temps d'escriure res.

El pla de la Marta separa el que es contenidoritzarà ara, el que es contenidoritzarà després i el que no es toca mai.

Els passos, en l'ordre en què redueixen risc:

1. Escriure el Dockerfile i executar-lo en local. Abans de tocar AWS, la imatge ha d'arrencar i respondre 200 a /salud al portàtil del Luis.
2. Crear els repositoris d'ECR amb immutabilitat, escaneig millorat i cicle de vida, i afegir la fase de construcció d'imatge al projecte build-mercadofresco-tienda.
3. Crear el clúster ecs-mercadofresco a desenvolupament, amb un proveïdor de capacitat sobre un ASG petit d'instàncies amb l'AMI optimitzada per a ECS.
4. Registrar la definició de tasca i llançar una tasca solta amb run-task. Aquí apareixen els errors de rol d'execució, secrets i grups de seguretat, i aquí és on han d'aparèixer.
5. Crear el grup de destinació de tipus ip i el servei a desenvolupament, i validar amb les proves de fum del projecte build-mercadofresco-humo (08-02).
6. Repetir a preproducció amb la càrrega sintètica del divendres, mesurant temps d'arrencada de tasca i comparant-lo amb els 120 segons actuals.
7. A producció, convivència: el mateix ALB amb dos grups de destinació i un repartiment ponderat —90 % a l'ASG, 10 % al servei d'ECS—, pujant el pes al llarg de dues setmanes.
8. Retirar l'ASG i l'AMI quan el servei porti dues setmanes al 100 % sense incidents, i esborrar la plantilla de llançament del CDK en un PR que en deixi constància.

El pas 7 és el que fa que això sigui una migració i no un salt de fe. Amb el repartiment ponderat de l'ALB (03-03), un problema al servei d'ECS afecta el 10 % de les peticions durant el temps que es trigui a posar el pes a zero, que són segons.

ECS no costa res. El pla de control, les definicions de tasca, els serveis i els desplegaments són gratuïts. El que es paga amb el tipus de llançament EC2 és exactament el que ja es pagava: les instàncies, els seus volums EBS i la transferència de dades.

La comparació honesta per a MercadoFresco, amb la botiga contenidoritzada sobre les mateixes instàncies:

L'estalvi d'aquesta lliçó no ve d'ECS sinó de la densitat: els treballadors tenien el seu propi ASG amb les seves pròpies instàncies, moltes vegades ocioses, i en un clúster compartit s'empaqueten amb la botiga. L'estalvi gran —eliminar la capacitat ociosa per complet— arriba amb Fargate a 10-02, i l'anàlisi fina de costos, al mòdul 11. La neteja, en aquest ordre estricte:

El pas 4 és l'únic imprescindible des del punt de vista econòmic: esborrar el clúster d'ECS no esborra les instàncies EC2, que continuen facturant alegrement sense res a executar. És el residu més car d'aquesta lliçó.

Error: fer servir latest a la definició de tasca. Produeix desplegaments no reproduïbles i reversions impossibles. Consell: etiqueta amb v1.6.0-a3f9c21 i desplega per digest; que el pipeline sigui l'únic que decideix quin digest va a cada entorn.

Error: confondre el rol d'execució amb el de tasca. Mitja hora perduda per cada incident. Consell: si la tasca no arriba a arrencar, mira el rol d'execució; si l'aplicació falla cridant AWS, el de tasca. Els missatges CannotPullContainerError i ResourceInitializationError són sempre del d'execució.

Error: no fixar --health-check-grace-period-seconds. L'aplicació triga a escalfar-se, l'ALB la mata, ECS la reposa, bucle infinit. Consell: mesura el temps real fins al primer 200 a /salud i posa'n el doble.

Error: COPY . . sense .dockerignore. Fica .git complet i fitxers .env dins la imatge. Consell: el .dockerignore s'escriu abans que el Dockerfile, no després.

Error: capes en mal ordre. COPY . . abans de pip install invalida la memòria cau a cada commit. Consell: del que menys canvia al que més: base, sistema, dependències, codi.

Error: contenidor com a root amb sistema de fitxers escrivible. És innecessari i converteix qualsevol fallada de l'aplicació en escriptura de binaris. Consell: USER numèric, readonlyRootFilesystem: true i un volum efímer per a /tmp.

Error: oblidar el límit d'ENI amb awsvpc. Una m5.large executa dues tasques i el clúster escala «sense motiu». Consell: activa awsvpcTrunking a nivell de compte abans de dimensionar res.

Error: awslogs en mode bloquejant. Un retard de CloudWatch Logs frena l'aplicació. Consell: mode: non-blocking amb max-buffer-size explícit a tots els serveis amb trànsit d'usuari.

Error: política de cicle de vida agressiva. Esborra la imatge a la qual calia revertir. Consell: conserva almenys deu versions publicades i prova la política en sec abans d'aplicar-la.

Consell: activa l'interruptor de desplegament amb reversió a tots els serveis des del primer dia. No té cost i converteix un desplegament trencat en un incident de tres minuts que es resol sol.

Consell: fixa la retenció dels grups de registres d'ECS. Amb awslogs-create-group el grup neix sense caducitat, i amb tasques efímeres el volum de registres creix més de pressa del que ningú espera.

Consell: etiqueta les tasques amb propagateTags: SERVICE. És l'única manera que les cinc etiquetes obligatòries arribin a la tasca i que el mòdul 11 pugui repartir costos.

Consell: mantén la definició de tasca al CDK. L'ecs.FargateTaskDefinition o ecs.Ec2TaskDefinition de 09-02 genera rols amb permisos mínims automàticament amb els mètodes grant*, inclosos els de KMS que gairebé ningú no recorda.

Escriu el Dockerfile complet del component de treballadors de MercadoFresco, que consumeix cola-mercadofresco-pedidos, escriu a Aurora i publica al tema mercadofresco-pedido-confirmado. És una aplicació Python sense servidor HTTP: no exposa ports i no pot fer servir un HEALTHCHECK basat en curl. Resol (a) com fas la comprovació d'estat sense HTTP i per què ECS la necessita igualment; (b) què canvia respecte al Dockerfile de la botiga quant a etapes, usuari i .dockerignore; (c) com gestiones l'apagada ordenada quan ECS envia SIGTERM enmig del processament d'un missatge; i (d) quin stopTimeout hi poses i amb quina relació respecte al temps de visibilitat de la cua.

El Luis registra la definició de tasca de la botiga i llança el servei a desenvolupament. Cap tasca no arriba a l'estat RUNNING. A la consola apareixen, en diferents intents, aquests tres motius d'aturada:

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 tasca arriba a RUNNING, però el servei la mata als 90 segons i n'arrenca una altra, indefinidament.

Per a cadascun: diagnostica la causa exacta, indica on ho comprovaries, i dona la correcció concreta. Per al tercer, explica a més per què el desired count no s'estabilitza mai i quines dues configuracions diferents podrien estar causant-ho.

MercadoFresco desplega 4,8 vegades per setmana a producció, manté entre 6 i 10 branques de característica vives alhora i necessita poder revertir fins a quatre versions enrere a producció. Compliment exigeix poder demostrar, per a qualsevol dia dels últims 12 mesos, quina imatge exacta hi havia a producció. Dissenya (a) l'esquema complet d'etiquetatge d'imatges, incloent-hi quines etiquetes porta una imatge de branca i quines una de producció; (b) la política de cicle de vida completa en JSON, amb les seves prioritats; (c) com satisfàs el requisit de compliment de 12 mesos sense guardar 250 imatges; i (d) quin risc concret tindria posar la regla d'imatges sense etiqueta amb prioritat 1.

Solució 1

(a) La comprovació sense HTTP. El bucle de sondeig escriu /tmp/latido amb la marca de temps després de cada cicle de ReceiveMessage, i trabajadores.salud retorna error si el fitxer té més de 90 segons. ECS la necessita igualment perquè un treballador penjat no mor: es queda esperant en un sòcol, deixa de consumir la cua i el servei no se n'assabenta. Sense comprovació d'estat, aquest treballador zombi compta com a capacitat sana i la cua creix amb quatre tasques «vives». Amb el HEALTHCHECK, ECS el mata i el reposa. Com que readonlyRootFilesystem estarà actiu, /tmp ha d'anar muntat com a volum efímer.

(b) Què canvia respecte a la botiga. L'estructura multietapa és idèntica —és el patró, no l'aplicació—. No hi ha EXPOSE ni portMappings perquè ningú no crida el treballador. No cal curl, cosa que permet una imatge encara més petita i una superfície d'atac menor: el HEALTHCHECK fa servir el mateix Python. L'UID és diferent (10002) per higiene, perquè els processos siguin distingibles a l'amfitrió. I el .dockerignore és el mateix, amb una addició important: el directori de dades de prova amb missatges d'exemple, que pot contenir dades que semblen reals i no han de viatjar dins una imatge.

(c) Apagada ordenada. El procés registra un gestor de SIGTERM que activa una bandera; el bucle principal la comprova abans de demanar el missatge següent, no enmig del processament. El missatge en curs s'acaba i s'esborra de la cua amb DeleteMessage; després el procés surt amb codi 0. Si el missatge no es pot acabar a temps, no s'esborra: en expirar el temps de visibilitat tornarà a la cua i un altre treballador el processarà, i d'aquí la importància de la idempotència amb mercadofresco-idempotencia (07-05). L'error que cal evitar és esborrar el missatge en rebre'l: llavors el SIGKILL el perd per sempre.

(d) stopTimeout i visibilitat. El processament d'una comanda triga com a màxim uns 20 segons, així que stopTimeout: 30 dona prou marge. La relació amb el temps de visibilitat de la cua és la clau: el temps de visibilitat ha de ser més gran que stopTimeout més el temps de processament, perquè un missatge interromput no reaparegui mentre el treballador antic encara l'està acabant i un segon treballador el processi en paral·lel. Amb processament de 20 s i stopTimeout de 30 s, un temps de visibilitat de 180 s és folgat i correcte. El màxim d'ECS per a stopTimeout és 120 segons, cosa que a més obliga que cap processament individual duri més que això.

Solució 2

Motiu 1: CannotPullContainerError — permisos del rol d'execució o xarxa. Hi ha tres causes possibles i es distingeixen ràpid. La primera, que el rol d'execució no tingui els permisos d'ECR (GetAuthorizationToken, BatchGetImage, GetDownloadUrlForLayer); es comprova a CloudTrail (05-03) buscant AccessDenied sobre ecr: amb el principal del rol. La segona, que la política del repositori al compte d'eines no autoritzi el compte de desenvolupament: és creuat i calen les dues polítiques, la del rol i la del repositori. La tercera, i la que produeix aquest missatge enganyós exacte, és de xarxa: les tasques són a snet-mercadofresco-app-a sense ruta cap a ECR, perquè el NAT està caigut o perquè no hi ha punts d'enllaç de VPC. Es distingeix mirant si el missatge arriba després d'un temps d'espera llarg (xarxa) o immediat (permisos). Correcció: els permisos de la política d'execució més els punts d'enllaç d'ecr.api, ecr.dkr i el d'S3 —les capes es descarreguen d'S3, i aquest és el que tothom oblida—.

Motiu 2: ResourceInitializationError ... unable to retrieve secret from asm. És inequívoc: el rol d'execució no pot llegir mercadofresco/produccion/rds/mfadmin. Dues causes, i cal revisar-les totes dues: falta secretsmanager:GetSecretValue sobre l'ARN del secret, o falta kms:Decrypt sobre alias/mercadofresco-datos, perquè el secret està xifrat amb una clau gestionada pel client (04-02) i llegir el secret exigeix desxifrar-lo. La segona és la que més s'oblida, i el missatge d'error no esmenta KMS. Es comprova a CloudTrail amb l'esdeveniment GetSecretValue fallit. Correcció: afegir tots dos permisos al rol d'execució —no al de tasca, que és l'error següent que cometrà el Luis— i verificar que la política de la clau KMS inclogui el rol com a usuari.

Motiu 3: el bucle infinit d'arrencada i mort. La tasca arriba a RUNNING, després mor. Dues configuracions poden causar-ho:

• El període de gràcia de la comprovació d'estat. Si l'aplicació triga 60 segons a respondre 200 a /salud —connexió a Aurora, precàrrega de catàleg des d'ElastiCache— i el grup de destinació la declara no sana abans, el servei la desregistra i la mata. ECS la reposa, i el cicle es repeteix. Correcció: --health-check-grace-period-seconds al doble del temps mesurat, i revisar el llindar del grup de destinació (HealthyThresholdCount, Interval, Timeout).
• El grup de seguretat. Si sg-mercadofresco-tienda no permet l'entrada des de sg-mercadofresco-alb al port 8080 —i no al 80, que és el que estava configurat quan la destinació era la instància—, la comprovació de l'ALB no passa mai. Amb awsvpc, el SG s'aplica a la tasca i el port és el del contenidor, no un port dinàmic de l'amfitrió.

Per què el desired count no s'estabilitza mai: perquè el servei no distingeix entre «la tasca va morir» i «la tasca no va arribar mai a estar sana». Reposa indefinidament, consumint quota d'execució i omplint el registre d'esdeveniments. I és exactament l'escenari per al qual existeix l'interruptor de desplegament: amb enable: true i rollback: true, després del llindar de fallades consecutives el desplegament es declara fallit i es reverteix, en lloc de girar en va durant hores. Si el Luis l'hagués activat, el diagnòstic hauria arribat com un esdeveniment de desplegament fallit en lloc de com un tauler que no s'estabilitza.

Solució 3

(a) Esquema d'etiquetatge. Cada imatge porta diverses etiquetes, perquè una etiqueta és un punter i se'n poden posar diverses al mateix digest:

L'etiqueta cache no pot conviure amb IMMUTABLE, així que va en un repositori diferent —mercadofresco/tienda-cache— amb immutabilitat desactivada i cicle de vida de tres dies. És el matís que es descobreix en aplicar la immutabilitat i trencar la construcció.

(b) Política de cicle de vida.

Les prioritats van de deu en deu per poder intercalar regles després sense renumerar-ho tot, que és la mateixa disciplina de les regles de WAF (04-05). Dotze versions publicades cobreixen amb folgança les quatre reversions exigides i unes dues setmanes i mitja de desplegaments.

(c) El requisit de compliment de 12 mesos. No es resol guardant imatges, es resol guardant evidència. Compliment no necessita poder executar la imatge de fa onze mesos; necessita poder demostrar quina imatge estava desplegada. Tres fonts ho donen sense cost d'emmagatzematge:

• CloudTrail (05-03) registra cada RegisterTaskDefinition i UpdateService amb el digest exacte i qui ho va fer; amb el rastre d'organització al compte de seguretat i S3 amb Object Lock, l'evidència és immutable i consultable amb Athena.
• El repositori Git mercadofresco-tienda conserva el commit i l'imatge.json de l'artefacte de cada execució del pipeline.
• AWS Config (05-04) manté l'històric de configuració del servei d'ECS.

Si a més calgués poder reconstruir una imatge antiga, la resposta és reconstruir-la des del commit amb el Dockerfile reproduïble —versions fixades i hashes—, no guardar-la.

(d) El risc de posar la regla d'imatges sense etiqueta amb prioritat 1. Seria catastròfic per com avalua ECR: una imatge només l'afecta la primera regla que la selecciona, i una regla d'untagged amb prioritat 1 s'avalua abans que totes. Quan una imatge publicada perd la seva etiqueta —perquè una altra imatge la reutilitza, o durant una replicació, o en retirar una etiqueta v1.6.0 a mà—, passa a ser untagged i la regla 1 l'esborra en 24 hores, fins i tot si és la que està executant producció. Les regles d'untagged van sempre al final, amb la prioritat més alta, i només després que les regles específiques hagin tingut la seva oportunitat de retenir el que importa.

MercadoFresco ja no desplega màquines: desplega imatges. Aquesta lliçó ha substituït els tres artefactes que feien mal —l'AMI, el cicle d'apedaçament i l'arrencada de dos minuts— per un Dockerfile de quaranta línies, un registre i un orquestrador.

Tens clar què és un contenidor de debò: namespaces i cgroups sobre un kernel compartit, no una màquina virtual petita, amb el que això implica en arrencada (segons enfront de minuts), en mida (megues enfront de gigues), en densitat i en portabilitat —el mateix artefacte al portàtil del Luis i a producció, byte a byte—, i amb l'advertiment honest sobre l'aïllament que el màrqueting sol ometre. Tens el Dockerfile de la botiga amb construcció multietapa que deixa els compiladors fora, usuari 10001 sense privilegis, versions fixades amb hashes, HEALTHCHECK coherent amb /salud i l'ordre de capes que converteix una construcció de tres minuts en una de quaranta segons. I el .dockerignore que s'escriu abans que el Dockerfile, no després d'haver ficat .git dins una imatge.

Tens Amazon ECR amb mercadofresco/tienda i mercadofresco/trabajadores: autenticació per testimoni temporal, immutabilitat d'etiquetes, l'esquema v1.6.0-a3f9c21 que lliga cada imatge a un commit, i la regla que cal interioritzar —l'etiqueta serveix perquè un humà trobi la imatge; el digest, perquè la màquina la desplegui—. Amb les polítiques de cicle de vida i els seus tres paranys, l'escaneig millorat d'Inspector que sí que veu les dependències de Python i avisa quan una imatge ja desplegada deixa de ser neta, la replicació des del compte d'eines 555566667777 cap a producció, i el xifratge amb alias/mercadofresco-datos que exigeix recordar-se de la política de la clau.

I tens Amazon ECS: clúster ecs-mercadofresco, la definició de tasca mercadofresco-tienda amb secrets injectats des de Secrets Manager i Parameter Store, registres no bloquejants, sidecar d'X-Ray i awsvpc amb grup de seguretat per tasca; el servei svc-mercadofresco-tienda darrere de tg-mercadofresco-tienda amb període de gràcia, desplegament 100/200 i interruptor de desplegament amb reversió automàtica; l'autoescalat per ALBRequestCountPerTarget amb refredaments asimètrics; i la distinció que estalvia mitja hora a cada incident: el rol d'execució treballa per a AWS, el rol de tasca treballa per al teu codi.

Però queda un residu, i es veu a la taula de proveïdors de capacitat. Sota el clúster continuen existint instàncies EC2: cal triar-ne la mida, mantenir-ne l'AMI optimitzada per a ECS, vigilar que l'escalat gestionat no es quedi curt i acceptar que, quan no hi ha lloc per a una tasca nova, cal una instància nova i una instància triga dos minuts a arrencar. És el mateix número del qual fugíem. L'hem amagat darrere d'un proveïdor de capacitat, no l'hem eliminat. I continua havent-hi capacitat ociosa que es paga: dues instàncies enceses a les quatre de la matinada d'un dimarts.

A 10-02, «AWS Fargate», les instàncies desapareixen. Sense AMI que mantenir, sense clúster que escalar, sense empaquetatge de tasques en màquines, sense capacitat ociosa: es declara quanta CPU i quanta memòria necessita cada tasca i AWS hi posa la resta. Veuràs les combinacions vàlides de recursos, l'estalvi real de Graviton, com es depura sense SSH amb ECS Exec, els punts d'enllaç de VPC que eviten pagar el NAT, l'escalat programat per al divendres a les 17:00, i Fargate Spot per als treballadors de la cua. I la comparativa honesta entre Fargate, EC2 i Lambda, amb la decisió raonada de MercadoFresco per a cada component.