A vm-motor-disponibilidad-dev hi viu el component més incòmode de Contoso Airlines. El motor de disponibilitat calcula, per a un origen, una destinació i una data, quines places queden lliures i a quina tarifa; és un servei petit, sense estat, que l'API de Disponibilitat invoca milers de vegades al dia. Però està desplegat a mà sobre una màquina virtual que la Marta Ríos pedaça cada mes, que ningú no sap recrear des de zero i la versió de temps d'execució de la qual ningú no gosa tocar perquè «funciona». En producció el problema es va tapar multiplicant instàncies a vmss-api-disponibilidad-pro, cosa que no el resol: només el multiplica.

Aquesta lliçó converteix aquest motor en un contenidor: una unitat autocontinguda que inclou el codi i tot el que necessita per executar-se, que es construeix una vegada, es desa amb versió en un registre i s'executa igual al portàtil d'en Diego Salas, a l'agent de la canalització i en producció. Després el publicaràs a l'Azure Container Registry i el portaràs a Azure Container Apps, l'opció que dona a Contoso la major part del valor de l'orquestració sense el cost d'operar un clúster.

1. Contenidor davant de màquina virtual
2. Imatge, capes, contenidor i registre
3. El Dockerfile del motor de disponibilitat
4. Construir i provar en local
5. Azure Container Registry
6. El panorama de serveis de contenidors d'Azure
7. Azure Container Apps en detall
8. Desplegar ca-motor-disponibilidad
9. Azure Container Instances per a tasques puntuals
10. Errors Comuns i Consells
11. Exercicis
12. Conclusió

Una màquina virtual virtualitza maquinari: cadascuna porta el seu propi sistema operatiu complet. Un contenidor virtualitza el sistema operatiu: comparteix el nucli de l'amfitrió i aïlla només el sistema de fitxers, la xarxa i els processos. La diferència de pes no és un detall tècnic, és el que canvia la manera de treballar.

El motor de disponibilitat és el candidat perfecte per quatre raons concretes: no té estat (cada petició es resol amb la base de dades i una memòria cau reconstruïble), arrenca ràpid, la seva càrrega és molt irregular —pics en obrir la venda de places, gairebé res de matinada— i la seva dependència problemàtica és el temps d'execució, exactament allò que un contenidor congela. El que no migraries tan alegrement són les bases de dades amb estat o el sistema heretat de tripulacions, que exigeix accés a maquinari específic.

Quatre conceptes i la relació entre ells:

• Imatge: plantilla immutable de només lectura amb el sistema de fitxers i les metadades d'arrencada. No s'executa; és el motlle.
• Capa: cada instrucció del Dockerfile produeix una capa apilada sobre l'anterior. Les capes s'emmagatzemen a la memòria cau i es comparteixen: si deu imatges parteixen de la mateixa base, aquesta base es descarrega una vegada.
• Contenidor: una instància en execució d'una imatge, amb una capa d'escriptura efímera a sobre. En eliminar-lo, aquesta capa desapareix.
• Registre: el magatzem d'imatges. Docker Hub és el públic; acrcontosopro.azurecr.io és el privat de Contoso, que ja coneixes del mòdul 5 com a registre de mòduls Bicep.

Que les capes es guardin a la memòria cau té una conseqüència pràctica enorme: ordena el Dockerfile del que menys canvia al que més canvia. Si copies el codi font abans de restaurar les dependències, qualsevol canvi d'una línia invalida la memòria cau de la restauració i cada compilació triga minuts de més.

Un Dockerfile és la recepta declarativa de la imatge. Aquesta és la del motor, amb construcció en diverses etapes, usuari no root i imatge base petita:

Línia a línia, el que importa:

• FROM ... AS compilacion obre la primera etapa amb el SDK complet (uns 800 MB): compiladors, eines i tot el necessari per construir. Res d'això no arribarà a producció.
• COPY dels .csproj abans que del codi és l'optimització de memòria cau de què parlava l'apartat anterior. Mentre no canviïn les dependències, dotnet restore se salta.
• FROM ... AS final obre la segona etapa partint de zero: només el temps d'execució d'ASP.NET sobre Alpine, uns 110 MB. La variant alpine fa servir una distribució mínima; si el teu codi depèn de biblioteques natives de glibc, fes servir -jammy en el seu lloc.
• adduser + USER motor és la línia que més vegades falta als Dockerfile reals. Per defecte un contenidor s'executa com a root, i una vulnerabilitat de l'aplicació es converteix en root dins del contenidor. Defender for Cloud ho marcarà; fes-ho des del principi.
• COPY --from=compilacion porta només el resultat publicat de la primera etapa. El codi font, el SDK i les dependències de compilació es queden fora: menys pes i moltíssima menys superfície d'atac.
• ENTRYPOINT defineix el procés principal. Quan aquest procés acaba, el contenidor acaba.

Al costat del Dockerfile hi va un .dockerignore amb bin/, obj/, .git/ i **/appsettings.Development.json. Aquesta última línia no és cosmètica: impedeix que un fitxer de configuració local amb credencials acabi dins de la imatge.

--rm elimina el contenidor en aturar-lo, per no acumular restes. -e injecta configuració per variable d'entorn, que és com es configura un contenidor: no fiquis mai la configuració dins de la imatge, perquè aleshores necessitaries una imatge diferent per entorn i perdries la garantia de «construir una vegada, desplegar moltes» del mòdul 5.

Un registre privat és obligatori tan bon punt la imatge conté codi propi. Contoso ja té acrcontosopro:

Contoso tria Premium per dos motius que no són de capacitat: el punt privat, perquè les imatges no viatgin per Internet, i la replicació geogràfica cap a North Europe, perquè el pla de recuperació no depengui d'una sola regió.

az acr build puja el context, construeix a Azure i deixa la imatge al registre. No cal tenir Docker instal·lat, cosa que resol de cop el problema dels agents de canalització:

L'etiqueta latest és una comoditat perillosa: és mutable, així que dos desplegaments «de latest» poden ser coses diferents i la reversió deixa de ser reproduïble. La convenció de Contoso: etiquetar sempre amb l'identificador de la compilació (motor-disponibilidad:$(Build.BuildId)), que és immutable i rastrejable fins a la confirmació exacta, i afegir latest només com a comoditat per al desenvolupament local.

ACR porta un admin user deshabilitat per defecte. Deixa'l deshabilitat. És una credencial compartida, no traçable i no rotable a la pràctica. El correcte és assignar el rol AcrPull a la identitat administrada que consumeix les imatges i AcrPush a la connexió de servei que les publica:

• Defender for Cloud (04-05) analitza cada imatge en publicar-la i de manera contínua les que estan en execució, amb el seu pla de contenidors. Troba bases desactualitzades i paquets vulnerables; la seva sortida és una llista de feina real, no un adorn.
• Replicació geogràfica: az acr replication create --registry acrcontosopro --location northeurope. La imatge es descarrega des de la rèplica més propera amb el mateix nom d'amfitrió.
• Retenció: sense política, el registre creix sense fre i es paga per GB. az acr config retention update --registry acrcontosopro --status enabled --days 30 --type UntaggedManifests neteja els manifestos sense etiqueta. Completa-ho amb una tasca programada que purgui etiquetes antigues, protegint sempre les de producció.

Aquesta és la pregunta que tothom fa i que convé contestar abans de triar:

El criteri en una frase: comença per Container Apps i puja a AKS només quan tinguis una necessitat concreta que Container Apps no cobreixi, no per si de cas. Contoso porta el motor a Container Apps i reservarà AKS per a la plataforma d'operacions de vol (06-02), que sí que la té.

Container Apps és Kubernetes per sota, però no el veus: no hi ha nodes que dimensionar ni versions de clúster que actualitzar.

• Entorn (cae-contoso-pro): el límit d'aïllament. Totes les aplicacions d'un entorn comparteixen xarxa virtual i espai de treball de Log Analytics, i es criden entre elles pel nom intern.
• Aplicació: un microservei, amb la seva imatge, els seus recursos i les seves regles d'escalat.
• Revisió: cada canvi de la imatge o de la configuració crea una revisió immutable. En pots mantenir diverses actives alhora.
• Divisió del trànsit: reparteix percentatges entre revisions. Aquí hi ha el desplegament canari, i és la versió de gra fi de les ranures que vas fer servir a 05-04.

L'escalat es defineix amb regles KEDA, que mesuren alguna cosa real —peticions per segon, longitud d'una cua, una mètrica personalitzada— en lloc de només la CPU:

Amb --min-replicas 0 l'aplicació escala a zero i deixa de facturar quan no hi ha trànsit: ideal per a ca-motor-disponibilidad en desenvolupament. El preu és l'arrencada en fred d'uns segons a la primera petició, inacceptable a la ruta de compra de producció. Per això Contoso deixa min-replicas 1 en producció i 0 en desenvolupament.

• Xarxa virtual: l'entorn s'integra a snet-integracion-app (10.20.5.0/24), i des d'allà les aplicacions arriben a pe-sql-reservas i pe-kv-contoso sense sortir a Internet.
• Ingrés: --ingress external publica un nom amb certificat TLS gestionat i renovat sol; --ingress internal deixa l'aplicació accessible només dins de l'entorn, que és el correcte per al motor, el client únic del qual és l'API de Disponibilitat. Per a un domini propi, az containerapp hostname add més un certificat gestionat.
• Secrets: es declaren a nivell d'aplicació i poden referenciar kv-contoso-pro, resolent-se amb la identitat administrada. Res de cadenes de connexió en variables d'entorn planes.
• Identitat administrada: s'assigna id-contoso-api-pro i amb ella es descarrega la imatge d'ACR i s'accedeix a db-reservas, sense cap clau. És exactament el patró de 04-02.

Fixa't en --registry-identity: la descàrrega de la imatge l'autoritza la identitat, no una contrasenya. I en keyvaultref:, que fa que el secret no estigui mai escrit al recurs, només la referència.

Actualitzar des de la canalització de 05-04 és una etapa més, amb la seva aprovació d'entorn:

La connexió de servei sc-contoso-pro amb federació d'identitat no porta secrets, i el sufix de revisió fa que cada compilació sigui identificable i reversible: tornar el 100 % a la revisió anterior és una única ordre.

ACI executa un contenidor sense orquestrador ni escalat, i factura per segon de CPU i memòria. Encaixa on Container Apps sobra: una migració de dades que s'executa una vegada, un treball per lots nocturn.

--restart-policy Never és el que el converteix en un treball: s'executa, acaba i no torna a arrencar. Elimina'l després amb az container delete, perquè un contenidor aturat continua reservant recursos i facturant.

• Executar com a root. És la fallada més repetida i la que Defender for Cloud assenyalarà. Afegeix sempre l'usuari sense privilegis.
• Copiar el codi abans de restaurar dependències. Invalida la memòria cau a cada compilació i multiplica els temps per deu.
• Desplegar latest en producció. Etiqueta mutable: no saps què hi ha corrent i la reversió no és reproduïble. Fes servir l'identificador de compilació.
• Habilitar l'usuari administrador d'ACR «només per provar». Es queda per sempre. Identitat administrada des del primer dia.
• Ficar secrets a la imatge. Queden a les capes i qualsevol amb accés al registre els extreu amb docker history. Van a Key Vault.
• No posar límits de CPU i memòria, o posar-los a l'atzar. A Container Apps el parell CPU/memòria té combinacions vàlides concretes (0.5 vCPU amb 1 Gi, 1 vCPU amb 2 Gi); comprova-ho abans de desplegar.
• Consell: defineix /salud com a sonda de disponibilitat i d'estat. Sense elles, la plataforma envia trànsit a rèpliques que encara no estan llestes. I a rg-contoso-reservas-dev, --min-replicas 0: una aplicació de desenvolupament sense trànsit ha de costar zero.
• Consell: no publiquis la imatge des del portàtil. Si només la canalització té AcrPush, el que hi ha al registre és sempre traçable a una confirmació.

Exercici 1. En Diego ha escrit aquest Dockerfile per a l'API de Disponibilitat:

1. Enumera quatre problemes.
2. Reescriu-lo aplicant les bones pràctiques de la lliçó.
3. Per què eliminar la línia ENV d'una versió posterior no resol la filtració?

Exercici 2. Contoso vol desplegar el motor en desenvolupament amb el mínim cost possible, sabent que es fa servir a ràfegues durant la jornada laboral i gens a la nit.

1. Escriu l'az containerapp create per a ca-motor-disponibilidad-dev a rg-contoso-reservas-dev, amb les etiquetes del projecte secundari «Contoso Millas».
2. Justifica les rèpliques mínima i màxima i explica quina contrapartida acceptes.
3. Quina regla d'escalat KEDA faries servir si el motor s'alimentés d'una cua en lloc d'HTTP?

Exercici 3. Tria el servei per a cada cas i justifica'l en una frase: (a) un procés que converteix a PDF els informes de puntualitat, s'executa a les 3:00 i triga 20 minuts; (b) el nou servei de recomanació de seients, amb trànsit impredictible i necessitat de canari; (c) app-contoso-reservas-pro, que ja funciona a App Service i només vol passar a imatge; (d) la plataforma d'operacions de vol, amb dotze microserveis, malles de servei i operadors propis.

Solució 1:

1. (a) Imatge final basada en el SDK: uns 800 MB davant de 110 MB, amb compiladors i codi font inclosos en producció. (b) S'executa com a root. (c) Un secret incrustat amb ENV. (d) COPY . . abans de restore destrueix la memòria cau de capes, i a més sense .dockerignore es copien bin/, obj/ i .git/.
2. La solució és l'estructura de l'apartat 3: etapa compilacion amb el SDK, còpia dels .csproj, dotnet restore, còpia de la resta i publish; etapa final sobre aspnet:8.0-alpine, creació d'usuari, USER, COPY --from=compilacion i ENTRYPOINT. La clau va fora: secret de Container Apps amb keyvaultref: a kv-contoso-pro.
3. Perquè les imatges són capes apilades i immutables: la capa que conté la clau continua existint al registre dins de totes les etiquetes anteriors, i es llegeix amb docker history. Cal purgar aquestes etiquetes del registre i rotar la clau, donant-la per compromesa.

Solució 2:

1. La mateixa ordre de l'apartat 8 substituint el grup per rg-contoso-reservas-dev, l'entorn per un de desenvolupament, la imatge per l'etiqueta corresponent, --min-replicas 0 --max-replicas 3, --cpu 0.25 --memory 0.5Gi, la identitat i el magatzem de desenvolupament kv-contoso-dev, i les etiquetes entorno=desarrollo proyecto=contoso-millas centro-coste=CC-2077 [email protected].
2. Mínim 0 perquè a la nit no hi ha trànsit i una aplicació de desenvolupament aturada ha de costar zero; màxim 3 perquè les ràfegues són de proves, no de producció, i un sostre baix evita que un bucle infinit en una prova dispari la factura. La contrapartida és l'arrencada en fred: la primera petició després d'una estona d'inactivitat trigarà uns segons. En desenvolupament és assumible; en producció no ho seria.
3. Una regla de tipus azure-queue apuntant a la cua de stoperacionescontosopro, amb una longitud objectiu per rèplica (per exemple 20 missatges). És l'escalador que fa de debò interessant KEDA: escala per feina pendent, no per CPU, que és un senyal que arriba tard.

Solució 3: (a) Container Instances: tasca que comença, acaba i no necessita orquestració ni ingrés. (b) Container Apps: escalat per trànsit, escala a zero fora d'hora punta i divisió del trànsit entre revisions llesta per al canari. (c) App Service per a contenidors: conserva ranures, escalat i configuració coneguts canviant només l'empaquetatge, amb un cost de migració gairebé nul. (d) AKS: només allà tens operadors, malles de servei i control complet del pla de dades, i l'equip ho justifica.

Has convertit el problema heretat de Contoso en una unitat moderna. Distingeixes contenidor de màquina virtual i saps per què el motor de disponibilitat —sense estat, d'arrencada ràpida, amb càrrega irregular i lligat al seu temps d'execució— era el candidat ideal. Entens imatge, capa, contenidor i registre, i per què l'ordre de les instruccions del Dockerfile decideix el temps de les teves compilacions. Has escrit aquest Dockerfile amb diverses etapes, usuari no root i imatge base petita, l'has provat en local i has après que la configuració entra per variables d'entorn perquè la imatge sigui la mateixa a tots els entorns.

A l'Azure Container Registry saps triar nivell, construir sense Docker local amb az acr build, versionar amb l'identificador de compilació en lloc de latest, autenticar amb identitat administrada deixant l'usuari administrador deshabilitat, analitzar vulnerabilitats amb Defender for Cloud i controlar el creixement amb replicació i retenció. Tens el mapa dels quatre serveis de contenidors i el criteri per triar: començar pel simple i pujar només amb motiu. I has desplegat ca-motor-disponibilidad a Container Apps amb el seu entorn cae-contoso-pro integrat a snet-integracion-app, ingrés intern, secrets per referència a kv-contoso-pro, identitat administrada, escalat KEDA i revisions amb divisió del trànsit actualitzades des de la canalització del mòdul 5. La màquina virtual vm-motor-disponibilidad-dev es pot apagar.

Container Apps cobreix el cas de Contoso amb molt poc esforç, i aquí hi ha la seva gràcia. Però té un sostre: quan necessites controlar la programació dels pods, instal·lar operadors, aplicar malles de servei, definir polítiques de xarxa fines o portar càrregues amb requisits de maquinari concrets, l'abstracció se't queda petita. Aquest és el punt on l'equip d'operacions de vol de Contoso es troba ara mateix. A la lliçó següent, Azure Kubernetes Service, baixaràs una capa: veuràs què gestiona AKS i què continua sent teu, muntaràs aks-contoso-operaciones i aprendràs l'imprescindible de Kubernetes per operar-lo amb criteri, incloent-hi allò que gairebé ningú no explica al principi, que és quant costa de debò i com evitar que es dispari.