Azure Container Apps

Azure Container Apps (ACA) är en fullständigt hanterad serverless-tjänst för containerhosting som bygger på Kubernetes och KEDA (Kubernetes Event-Driven Autoscaling). Till skillnad från AKS behöver du inte hantera kontrollplanet, nodpoolerna eller Kubernetes-manifest direkt. I stället distribuerar du containrar med ett enkelt CLI-kommando eller en YAML-definition, och Azure hanterar all orkestrering. ACA passar bra för mikrotjänster, API-bakändar, händelsestyrda arbetare och bakgrundsjobb som behöver skalas dynamiskt, inklusive skalning till noll.

En Container Apps-miljö är den isolerade gräns inom vilken en eller flera Container Apps körs. Alla appar i en miljö delar samma virtuella nätverk och Log Analytics-arbetsyta. Miljöer omfattar en region och en resursgrupp. Du kan distribuera flera miljöer för isolering mellan team eller stadier (produktion kontra staging). En miljö kan valfritt injiceras i ett VNet i ditt eget virtuella nätverk, så att Container Apps och andra Azure-tjänster kan kommunicera privat utan att gå via det offentliga internet.

För att distribuera en Container App anger du containeravbildningen (från Azure Container Registry eller valfritt offentligt register), antalet repliker och miljövariablerna. Appen blir offentligt tillgänglig via en automatiskt genererad HTTPS-URL om du aktiverar extern ingress. Ingress-konfigurationen omfattar målporten, trafikfördelning för blue-green-distributioner och om endast HTTP eller HTTPS ska tillåtas. ACA hämtar avbildningen vid distributionen, och miljön måste ha behörighet att hämta från registret.

Container Apps skalar med hjälp av KEDA-skalare som utlöses av externa mått. Inbyggda KEDA-skalare omfattar: HTTP-trafik (samtidiga begäranden per replik), Azure Service Bus-ködjup (väntande meddelanden), Azure Storage Queue, Cron (tidsbaserad) och CPU/Memory. När skalarmåttet sjunker till noll och minReplicas är inställt på 0 skalar Container Apps till noll — utan beräkningskostnad tills nya begäranden anländer. Skalning till noll är utmärkt för händelsestyrda arbetare med sporadiska arbetsbelastningar.

Dapr (Distributed Application Runtime) är en portabel, händelsestyrd runtime som förenklar utvecklingen av mikrotjänster. Container Apps har inbyggd Dapr-integrering — du aktiverar den per app med en enda flagga. Dapr tillhandahåller byggblock för: tjänsteanrop (med återförsök och mTLS), pub/sub-meddelanden (abstraherar Service Bus och Event Hubs), tillståndshantering (abstraherar Redis och Cosmos DB) samt utdatabindningar. Med Dapr kommunicerar mikrotjänster via Dapr-sidecar utan att känna till detaljerna i den underliggande infrastrukturen.

Varje distribution till en Container App skapar en ny revision. I läget flera revisioner kan du fördela trafiken mellan revisioner för blue-green- eller canary-distributioner. Du kan till exempel skicka 10 % av trafiken till en ny revision och 90 % till den aktuella stabila revisionen. Övervaka felfrekvenser och svarstider för den nya revisionen innan du ökar dess trafikandel till 100 %. Gamla revisioner kan inaktiveras men behålls i historiken, vilket gör det möjligt att omedelbart återställa genom att flytta trafikandelen tillbaka.

Container Apps stöder två sätt att injicera konfiguration: miljövariabler (för icke-känslig konfiguration som funktionsflaggor eller API-URL:er) och hemligheter (för känsliga värden som anslutningssträngar). Hemligheter lagras på Container App-nivå och refereras till av miljövariabler eller Dapr-komponenter. För den säkraste konfigurationen refererar du till hemligheter från Azure Key Vault med hjälp av en hanterad identitet, så att hemligheten hämtas vid körning och aldrig lagras i Container Apps konfigurationsplan.

Container Apps Jobs utökar plattformen med stöd för arbetsbelastningar som körs till slutförande – containrar som startar, utför sitt arbete och avslutas. Jobs stöder tre utlösartyper: Manuell (utlöses via API eller CLI), Schemalagd (cron-uttryck) och Händelsestyrd (KEDA-skalaren utlöser varje körning). Jobs debiteras endast för den faktiska körningstiden och passar utmärkt för batchbearbetning, rapportgenerering, databasmigreringar och ML-inferenspipelines som körs regelbundet eller som svar på händelser.

Container Apps skickar systemloggar (plattformshändelser som skapande av revisioner och skalning) och konsolloggar (programmets stdout/stderr) till den Log Analytics-arbetsyta som är kopplad till miljön. Fråga loggar med KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Inbyggda Azure Monitor-mätvärden omfattar antal repliker, antal begäranden, svarstid för begäranden samt CPU- och minnesanvändning per replik – allt tillgängligt i Azure-portalen utan ytterligare konfiguration.

Välj rätt Azure-plattform för containrar: Container Apps passar bäst för mikrotjänster, händelsestyrda arbetare och API:er när ni vill ha Kubernetes-fördelar utan att hantera klustret – särskilt när skalning till noll är värdefull. AKS passar bäst när ni behöver full kontroll över Kubernetes, anpassade operatorer eller specifika nodkonfigurationer (GPU, mycket minne). App Service passar bäst för traditionella webbprogram och API:er när utvecklingsteamet föredrar en enkel PaaS-modell utan den administrativa overhead som containerhantering medför. Alla tre stöder containrar; skillnaden handlar om komplexitet i hanteringen kontra graden av kontroll.

Container Apps stöder två ingresslägen: Extern (nåbar offentligt via en lastbalanserad HTTPS-slutpunkt med automatisk TLS) och Intern (endast nåbar från samma Container Apps-miljö eller från resurser med VNet-peering). Intern ingress används för backendtjänster som aldrig ska exponeras mot internet. Appar kan anropa varandra med det automatiskt genererade interna DNS-namnet http://myapi i samma miljö, vilket möjliggör enkel kommunikation mellan tjänster utan att en API-gateway behöver distribueras.

I den här lektionen har ni lärt er att Azure Container Apps tillhandahåller serverlös containerhosting som bygger på Kubernetes och KEDA utan klusterhantering, att KEDA-skalare möjliggör skalning till noll baserat på ködjup, HTTP-trafik eller cron-scheman, samt att Dapr-integrering förenklar kommunikation mellan mikrotjänster och tillståndshantering. Härnäst kopplar vi ihop allt till ett komplett utvecklararbetsflöde från början till slut.