Azure Container Apps

Azure Container Apps (ACA) er en fullstendig administrert, serverløs tjeneste for kjøring av containere, bygget oppå Kubernetes og KEDA (Kubernetes Event-Driven Autoscaling). I motsetning til AKS administrerer De ikke kontrollplanet, nodepoolene eller Kubernetes-manifestene direkte. I stedet distribuerer De containere ved hjelp av en enkel CLI eller YAML-definisjon, mens Azure håndterer all orkestrering. ACA egner seg godt for mikrotjenester, API-bakender, hendelsesdrevne arbeidere og bakgrunnsjobber som må skaleres dynamisk, inkludert skalering til null.

Et Container Apps-miljø er den isolerte grensen som én eller flere Container Apps kjører innenfor. Alle apper i et miljø deler det samme virtuelle nettverket og Log Analytics-arbeidsområdet. Miljøer avgrenses til én region og én ressursgruppe. De kan distribuere flere miljøer for å isolere team eller stadier fra hverandre (produksjon kontra staging). Et miljø kan valgfritt VNet-injiseres i Deres eget virtuelle nettverk, slik at Container Apps og andre Azure-tjenester kan kommunisere privat uten å gå via det offentlige internett.

For å distribuere en Container App angir De containeravbildningen (fra Azure Container Registry eller et annet offentlig register), antall replikaer og miljøvariabler. Appen blir offentlig tilgjengelig via en automatisk generert HTTPS-URL hvis De aktiverer ekstern ingress. Ingress-konfigurasjonen omfatter målporten, trafikkfordeling ved blue-green-distribusjoner og om bare HTTP eller HTTPS skal tillates. ACA henter avbildningen på distribusjonstidspunktet, og miljøet må ha tillatelse til å hente den fra registeret.

Container Apps skalerer ved hjelp av KEDA-skalere som utløses basert på eksterne måledata. Innebygde KEDA-skalere omfatter: HTTP-trafikk (samtidige forespørsler per replika), Azure Service Bus-kødybde (ventende meldinger), Azure Storage Queue, Cron (tidsbasert) og CPU/Memory. Når måleverdien for skaleren faller til null og minReplicas er satt til 0, skalerer Container Apps til null — uten beregningskostnader før nye forespørsler kommer inn. Skalering til null er svært godt egnet for hendelsesdrevne arbeidere med sporadiske arbeidsbelastninger.

Dapr (Distributed Application Runtime) er en portabel, hendelsesdrevet runtime som forenkler utvikling av mikrotjenester. Container Apps har innebygd Dapr-integrasjon — De aktiverer den per app med ett enkelt flagg. Dapr tilbyr byggesteiner for: tjenestekall (med nytt forsøk og mTLS), pub/sub-meldingsutveksling (abstraherer Service Bus og Event Hubs), tilstandsadministrasjon (abstraherer Redis og Cosmos DB) og output bindings. Med Dapr kommuniserer mikrotjenester gjennom Dapr-sidecar-en uten å kjenne detaljene i den underliggende infrastrukturen.

Hver distribusjon til en Container App oppretter en ny revisjon. I modus for flere revisjoner kan De fordele trafikk mellom revisjoner ved blue-green- eller canary-distribusjoner. De kan for eksempel sende 10 % av trafikken til en ny revisjon og 90 % til den nåværende stabile revisjonen. Overvåk feilrater og ventetid for den nye revisjonen før De øker trafikkvekten til 100 %. Gamle revisjoner kan deaktiveres, men beholdes i historikken, slik at De umiddelbart kan rulle tilbake ved å flytte trafikkvekten tilbake.

Container Apps støtter to måter å injisere konfigurasjon på: miljøvariabler (for ikke-sensitive innstillinger, som funksjonsflagg eller API-URL-er) og hemmeligheter (for sensitive verdier, som tilkoblingsstrenger). Hemmeligheter lagres på Container App-nivået og refereres til av miljøvariabler eller Dapr-komponenter. For det sikreste oppsettet kan De referere til hemmeligheter fra Azure Key Vault ved hjelp av en managed identity, slik at hemmelighetsverdien hentes under kjøring og aldri lagres i Container Apps konfigurasjonsplan.

Container Apps Jobs utvider plattformen med støtte for arbeidsbelastninger som kjører til de fullføres – containere som starter, utfører arbeid og avsluttes. Jobber støtter tre utløsertyper: Manuell (utløses via API eller CLI), Planlagt (cron-uttrykk) og Hendelsesdrevet (KEDA scaler utløser hver kjøring). Jobber faktureres bare for den faktiske kjøringstiden og egner seg godt til satsvis behandling, rapportgenerering, databasemigreringer og ML-inferensprosesser som kjører med jevne mellomrom eller som svar på hendelser.

Container Apps sender systemlogger (plattformhendelser som opprettelse av revisioner og skalering) og konsolllogger (programmets stdout/stderr) til Log Analytics-arbeidsområdet som er knyttet til miljøet. Du kan spørre i logger med KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Innebygde Azure Monitor-metrikker omfatter antall replikaer, antall forespørsler, ventetid for forespørsler og CPU-/minneutnyttelse per replika – alt tilgjengelig i Azure-portalen uten ekstra konfigurasjon.

Valg av riktig Azure-plattform for containere: Container Apps passer best for mikrotjenester, hendelsesdrevne arbeidere og API-er når du ønsker fordelene ved Kubernetes uten å administrere klyngen – særlig når skalering til null er nyttig. AKS passer best når du trenger full kontroll over Kubernetes, egendefinerte operatorer eller bestemte nodekonfigurasjoner (GPU, mye minne). App Service passer best for tradisjonelle webapplikasjoner og API-er når utviklingsteamet foretrekker en enkel PaaS-modell uten administrasjonskostnadene ved containerhåndtering. Alle tre støtter containere; forskjellen handler om balansen mellom administrasjonskompleksitet og kontroll.

Container Apps støtter to ingress-moduser: Ekstern (offentlig tilgjengelig via et lastbalansert HTTPS-endepunkt med automatisk TLS) og Intern (bare tilgjengelig fra det samme Container Apps-miljøet eller fra ressurser med VNet-peering). Intern ingress brukes for backend-tjenester som aldri skal eksponeres mot internett. Apper kan kalle hverandre ved hjelp av det automatisk genererte interne DNS-navnet http://myapi i det samme miljøet. Dermed blir kommunikasjon mellom tjenester enkel, uten at du trenger å distribuere en API-gateway.

I denne leksjonen har du lært at Azure Container Apps tilbyr serverløs containerhosting bygget på Kubernetes og KEDA, uten at du trenger å administrere en klynge, at KEDA scalers muliggjør skalering til null basert på kødybde, HTTP-trafikk eller cron-planer, og at Dapr-integrasjon forenkler kommunikasjon mellom mikrotjenester og tilstandsadministrasjon. Neste steg er å sette alt sammen i en komplett ende-til-ende-arbeidsflyt for utviklere.