Azure Container Apps

Azure Container Apps (ACA) is een volledig beheerde serverloze service voor het hosten van containers, gebouwd boven op Kubernetes en KEDA (Kubernetes Event-Driven Autoscaling). In tegenstelling tot AKS beheer je niet rechtstreeks het besturingsvlak, de nodegroepen of Kubernetes-manifesten. In plaats daarvan implementeer je containers met een eenvoudige CLI- of YAML-definitie en regelt Azure alle orkestratie. ACA is ideaal voor microservices, API-achterliggende systemen, gebeurtenisgestuurde werkers en taken voor achtergrondverwerking die dynamisch moeten kunnen schalen, inclusief schalen naar nul.

Een Container Apps-omgeving is de geïsoleerde grens waarbinnen een of meer Container Apps worden uitgevoerd. Alle apps in een omgeving delen hetzelfde virtuele netwerk en dezelfde Log Analytics-werkruimte. Omgevingen zijn gekoppeld aan een regio en een resourcegroep. Je kunt meerdere omgevingen implementeren om teams of fasen van elkaar te isoleren (productie versus testomgeving). Een omgeving kan optioneel in je eigen virtuele netwerk worden geïnjecteerd via VNet, zodat privécommunicatie tussen Container Apps en andere Azure-services mogelijk is zonder het openbare internet te gebruiken.

Om een Container App te implementeren, geef je de containerimage (uit Azure Container Registry of een openbaar register), het aantal replica's en omgevingsvariabelen op. De app is openbaar toegankelijk via een automatisch gegenereerde HTTPS-URL als je externe inkomende toegang inschakelt. De configuratie voor inkomende toegang bevat de doelpoort, de verdeling van verkeer voor blue-green-implementaties en de keuze om alleen HTTP of HTTPS toe te staan. ACA haalt de image op tijdens de implementatie; de omgeving moet toegangsrechten hebben om uit het register te lezen.

Container Apps schaalt met KEDA-schalers die worden geactiveerd op basis van externe metrieken. Ingebouwde KEDA-scalers zijn onder andere: HTTP-verkeer (gelijktijdige aanvragen per replica), Azure Service Bus-wachtrijdiepte (wachtende berichten), Azure Storage Queue, Cron (op tijd gebaseerd) en CPU/geheugen. Wanneer de metriek van de scaler naar nul daalt en minReplicas is ingesteld op 0, schaalt Container Apps naar nul — er zijn geen compute-kosten totdat nieuwe aanvragen binnenkomen. Schalen naar nul is uitstekend voor gebeurtenisgestuurde werkers met onregelmatige workloads.

Dapr (Distributed Application Runtime) is een draagbare, gebeurtenisgestuurde runtime die het bouwen van microservices vereenvoudigt. Container Apps heeft ingebouwde Dapr-integratie — je schakelt deze per app in met één vlag. Dapr biedt bouwstenen voor: serviceaanroepen (met nieuwe pogingen en mTLS), publish-subscribe-berichtencommunicatie (waarbij Service Bus en Event Hubs worden geabstraheerd), statusbeheer (waarbij Redis en Cosmos DB worden geabstraheerd) en uitvoerbindingen. Met Dapr communiceren microservices via de Dapr-sidecar zonder dat ze de details van de onderliggende infrastructuur hoeven te kennen.

Elke implementatie naar een Container App maakt een nieuwe revisie. In de modus voor meerdere revisies kun je verkeer verdelen over revisies voor blue-green- of canary-implementaties. Je kunt bijvoorbeeld 10% van het verkeer naar een nieuwe revisie sturen en 90% naar de huidige stabiele revisie. Bewaak foutpercentages en latentie op de nieuwe revisie voordat je het verkeersgewicht verhoogt naar 100%. Oude revisies kunnen worden gedeactiveerd maar blijven in de geschiedenis behouden, zodat je direct kunt terugdraaien door het verkeersgewicht terug te verschuiven.

Container Apps ondersteunt twee manieren om configuratie toe te voegen: omgevingsvariabelen (voor niet-gevoelige configuratie, zoals functievlaggen of API-URL's) en geheimen (voor gevoelige waarden, zoals verbindingsreeksen). Geheimen worden opgeslagen op het niveau van de Container App en via omgevingsvariabelen of Dapr-componenten gebruikt. Verwijs voor de veiligste configuratie met een beheerde identiteit naar geheimen uit Azure Key Vault, zodat de geheime waarde tijdens runtime wordt opgehaald en nooit in het configuratievlak van de Container App wordt opgeslagen.

Container Apps Jobs breidt het platform uit met ondersteuning voor workloads die tot voltooiing worden uitgevoerd: containers die starten, werk uitvoeren en afsluiten. Taken ondersteunen drie activeringstypen: Handmatig (geactiveerd via API of CLI), Gepland (cron-expressie) en Gebeurtenisgestuurd (de KEDA-scaler activeert elke uitvoering). U betaalt voor taken alleen gedurende de daadwerkelijke uitvoeringstijd. Ze zijn ideaal voor batchverwerking, het genereren van rapporten, databasemigraties en ML-inferentiepijplijnen die periodiek of als reactie op gebeurtenissen worden uitgevoerd.

Container Apps stuurt systeemlogboeken (platformgebeurtenissen zoals het maken van revisies en schalen) en consolelogboeken (de stdout/stderr van je toepassing) naar de Log Analytics-werkruimte die aan de omgeving is gekoppeld. Zoek logboeken op met KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Ingebouwde Azure Monitor-metingen omvatten het aantal replica's, het aantal aanvragen, de latentietijd van aanvragen en het CPU-/geheugengebruik per replica. Ze zijn allemaal zonder extra configuratie beschikbaar in de Azure-portal.

Het juiste Azure-platform voor containers kiezen: Container Apps is het meest geschikt voor microservices, gebeurtenisgestuurde werkers en API's wanneer je de voordelen van Kubernetes wilt zonder het cluster te beheren, vooral wanneer schalen naar nul waardevol is. AKS is het meest geschikt wanneer je volledige controle over Kubernetes, aangepaste operators of specifieke nodeconfiguraties nodig hebt, zoals GPU's of veel geheugen. App Service is het meest geschikt voor traditionele webtoepassingen en API's wanneer het ontwikkelteam de voorkeur geeft aan een eenvoudig PaaS-model zonder de extra beheeroverhead van containers. Alle drie ondersteunen containers; het verschil zit in de complexiteit van het beheer tegenover de mate van controle.

Container Apps ondersteunt twee modi voor inkomend verkeer: Extern (publiek bereikbaar via een HTTPS-eindpunt met taakverdeling en automatische TLS) en Intern (alleen bereikbaar vanuit dezelfde Container Apps-omgeving of vanaf resources die via een VNet-peering zijn verbonden). Interne toegang wordt gebruikt voor backendservices die nooit aan het internet mogen worden blootgesteld. Apps kunnen elkaar binnen dezelfde omgeving aanroepen met de automatisch gegenereerde interne DNS-naam http://myapi. Zo is eenvoudige communicatie tussen services mogelijk zonder een API-gateway te implementeren.

In deze les heb je geleerd dat Azure Container Apps serverloze hosting van containers biedt, gebouwd op Kubernetes en KEDA, zonder dat je een cluster hoeft te beheren; dat KEDA-scalers schalen naar nul mogelijk maken op basis van de lengte van een wachtrij, HTTP-verkeer of cron-schema's; en dat Dapr-integratie communicatie tussen microservices en het beheer van status vereenvoudigt. Hierna verbinden we alles tot een volledige ontwikkelworkflow van begin tot eind.