Azure Container Apps

Azure Container Apps (ACA) er en fuldt administreret serverless-containerværtsservice, der er bygget oven på Kubernetes og KEDA (Kubernetes-hændelsesdrevet autoskalering). I modsætning til AKS administrerer du ikke kontrolplanet, nodepuljerne eller Kubernetes-manifesterne direkte. I stedet udruller du containere ved hjælp af en enkel CLI eller YAML-definition, og Azure håndterer al orkestrering. ACA er ideel til mikrotjenester, API-backends, hændelsesdrevne arbejdere og baggrundsbehandlingsjob, der skal kunne skaleres dynamisk, herunder skalering til nul.

Et Container Apps-miljø er den isolerede grænse, som én eller flere Container Apps kører inden for. Alle apps i et miljø deler det samme virtuelle netværk og Log Analytics-arbejdsområde. Miljøer er afgrænset til en region og en ressourcegruppe. Du kan udrulle flere miljøer for at isolere teams eller faser (produktion kontra test). Et miljø kan valgfrit være VNet-injiceret i dit eget virtuelle netværk, så Container Apps og andre Azure-services kan kommunikere privat uden at gå via det offentlige internet.

Hvis du vil udrulle en Container App, angiver du containerafbildningen (fra Azure Container Registry eller et offentligt register), antallet af replikaer og miljøvariabler. Appen er offentligt tilgængelig via en automatisk genereret HTTPS-URL, hvis du aktiverer ekstern ingress. Ingress-konfigurationen omfatter målporten, trafikfordelingen ved blue-green-udrulninger samt, om kun HTTP eller HTTPS skal tillades. ACA henter afbildningen på udrulningstidspunktet; miljøet skal have tilladelse til at hente fra registret.

Container Apps skalerer ved hjælp af KEDA-skalere, der udløses baseret på eksterne målepunkter. Indbyggede KEDA-skalere omfatter: HTTP-trafik (samtidige anmodninger pr. replika), Azure Service Bus-kødybde (ventende meddelelser), Azure Storage Queue, Cron (tidsbaseret) samt CPU/hukommelse. Når skalerens målepunkt falder til nul, og minReplicas er angivet til 0, skalerer Container Apps til nul — uden beregningsomkostninger, indtil nye anmodninger ankommer. Skalering til nul er fremragende til hændelsesdrevne arbejdere med sporadiske arbejdsbelastninger.

Dapr (Distributed Application Runtime) er en portabel, hændelsesdrevet runtime, der gør det enklere at bygge mikrotjenester. Container Apps har indbygget Dapr-integration — du aktiverer den pr. app med et enkelt flag. Dapr leverer byggesten til: servicekald (med gentagelse og mTLS), publicering/abonnement-meddelelser (som abstraherer Service Bus og Event Hubs), tilstandsadministration (som abstraherer Redis og Cosmos DB) samt outputbindinger. Med Dapr kommunikerer mikrotjenester gennem Dapr-sidecar'en uden at kende detaljerne om den underliggende infrastruktur.

Hver udrulning til en Container App opretter en ny revision. I tilstand med flere revisioner kan du fordele trafik mellem revisioner til blue-green- eller canary-udrulninger. Du kan f.eks. sende 10 % af trafikken til en ny revision og 90 % til den aktuelle stabile revision. Overvåg fejlprocenter og svartid på den nye revision, før du øger dens trafikvægt til 100 %. Gamle revisioner kan deaktiveres, men bevares i historikken, så du straks kan rulle tilbage ved at flytte trafikvægten tilbage.

Container Apps understøtter to måder at indsætte konfiguration på: miljøvariabler (til ikke-følsom konfiguration som funktionsflag eller API-URL'er) og hemmeligheder (til følsomme værdier som forbindelsesstrenge). Hemmeligheder gemmes på Container App-niveauet og refereres via miljøvariabler eller Dapr-komponenter. Den sikreste opsætning er at referere til hemmeligheder fra Azure Key Vault ved hjælp af en administreret identitet, så hemmelighedens værdi hentes under kørsel og aldrig gemmes i Container App'ens konfigurationsplan.

Container Apps Jobs udvider platformen med understøttelse af arbejdsbelastninger, der kører til afslutning — containere, der starter, udfører arbejde og afslutter. Jobs understøtter tre udløsningstyper: Manuel (udløses via API eller CLI), Planlagt (cron-udtryk) og Hændelsesdrevet (KEDA-skaleren udløser hver kørsel). Der faktureres kun for den faktiske køretid, og Jobs er velegnede til batchbehandling, rapportgenerering, databasemigreringer og ML-inferenspipelines, der kører med jævne mellemrum eller som reaktion på hændelser.

Container Apps sender systemlogge (platformshændelser som oprettelse af revisioner og skalering) og konsollogge (din applikations stdout/stderr) til det Log Analytics-arbejdsområde, der er knyttet til miljøet. Forespørg i logge med KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Indbyggede Azure Monitor-målinger omfatter antal replikaer, antal forespørgsler, forespørgselsforsinkelse samt CPU- og hukommelsesudnyttelse pr. replika — alt sammen tilgængeligt i Azure-portalen uden yderligere konfiguration.

Valg af den rigtige Azure-containerplatform: Container Apps er bedst til mikrotjenester, hændelsesdrevne arbejdere og API'er, hvor du ønsker fordelene ved Kubernetes uden at administrere klyngen — især når skalering til nul er værdifuld. AKS er bedst, når du har brug for fuld Kubernetes-kontrol, brugerdefinerede operatorer eller specifikke nodekonfigurationer (GPU, meget hukommelse). App Service er bedst til traditionelle webapplikationer og API'er, hvor udviklingsteamet foretrækker en enkel PaaS-model uden den ekstra administrationsbyrde ved containere. Alle tre understøtter containere; forskellen er balancen mellem administrationskompleksitet og kontrol.

Container Apps understøtter to tilstande for indgående trafik: Ekstern (offentligt tilgængelig via et HTTPS-slutpunkt med belastningsfordeling og automatisk TLS) og Intern (kan kun nås fra det samme Container Apps-miljø eller fra ressourcer med VNet-peering). Intern indgående trafik bruges til backendtjenester, der aldrig må eksponeres på internettet. Apps kan kalde hinanden ved hjælp af det automatisk genererede interne DNS-navn http://myapi i det samme miljø, så enkel kommunikation mellem tjenester er mulig uden at implementere en API-gateway.

I denne lektion lærte du, at Azure Container Apps leverer serverløs containerhosting, der er bygget på Kubernetes og KEDA, uden administration af klynger; at KEDA-skalere muliggør skalering til nul baseret på kølængde, HTTP-trafik eller cron-planer; og at Dapr-integration forenkler kommunikation mellem mikrotjenester og administration af tilstand. I næste afsnit samler vi det hele i en komplet udviklerarbejdsgang fra start til slut.