Dela via


Uppdatera och distribuera ändringar i Azure Container Apps

Ändringshantering kan vara en utmaning när du utvecklar containerbaserade program i molnet. I slutändan behöver du stöd för att spåra ändringar, säkerställa drifttid och ha mekanismer för att hantera smidiga återställningar.

Ändringshantering i Azure Container Apps drivs av revisioner, som är en ögonblicksbild av varje version av din containerapp.

Viktiga egenskaper för revisioner är:

  • Oföränderlig: När en revision har upprättats förblir den oföränderlig.

  • Version: Revisioner fungerar som en post för containerappens versioner och samlar in dess tillstånd i olika steg.

  • Automatiskt etablerad: När du distribuerar en containerapp för första gången skapas en första revision automatiskt.

  • Begränsade ändringar: Även om revisionerna förblir statiska kan ändringar i programomfattningen påverka alla revisioner, medan ändringar i revisionsomfattningen skapar en ny revision.

  • Historisk post: Som standard har du åtkomst till 100 inaktiva revisioner, men du kan justera det här tröskelvärdet manuellt.

  • Flera revisioner: Du kan köra flera revisioner samtidigt. Den här funktionen är särskilt fördelaktig när du behöver hantera olika versioner av appen samtidigt.

Livscykel

Varje revision genomgår specifika tillstånd, som påverkas av dess status och tillgänglighet. Under livscykeln genomgår en containerapp olika etablering, körning och inaktiv status.

Etableringsstatus

När du skapar en ny revision genomgår containerappen start- och beredskapskontroller. Under den här fasen fungerar etableringsstatusen som en guide för att spåra containerappens förlopp.

Status beskrivning
Etablerar Revisionen är i verifieringsprocessen.
Etablerad Revisionen har klarat alla kontroller.
Etableringen misslyckades Revisionen påträffade problem under verifieringen.

Kör status

När en containerapp har etablerats går en revision in i driftsfasen. Statusen som körs hjälper till att övervaka en containerapps hälsa och funktioner.

Status beskrivning
Etablerar Revisionen är i verifieringsprocessen.
Skala till 0 Noll repliker som körs och etablerar inga nya repliker. Containerappen kan skapa nya repliker om skalningsregler utlöses.
Aktiverar Noll repliker som körs, en replik etableras.
Aktiveringen misslyckades Det gick inte att etablera den första repliken.
Skalning/bearbetning In- eller utskalning sker. En eller flera repliker körs medan andra repliker etableras.
Körs En eller flera repliker körs. Det finns inga problem att rapportera.
Körs (högst) Det maximala antalet repliker (enligt skalningsreglerna för revisionen) körs. Det finns inga problem att rapportera.
Avetablering Revisionen övergår från aktiv till inaktiv och tar bort alla resurser som den har skapat.
Degraderad Minst en replik i revisionen är i ett feltillstånd. Visa information om körningstillstånd för specifika problem.
Misslyckades Kritiska fel orsakade att revisioner misslyckades. Körningstillståndet innehåller information. Vanliga orsaker är:
•Uppsägning
• Slutkod 137

Inaktiv status

Revisioner kan också ange ett inaktivt tillstånd. Dessa revisioner har inte etablerings- eller körningstillstånd. Azure Container Apps har dock en lista över dessa revisioner som omfattar upp till 100 inaktiva poster. Du kan aktivera en revision när som helst.

Ändra inaktiv revisionsgräns

Du kan använda parametern --max-inactive-revisions med containerapp create kommandona eller containerapp update för att styra antalet inaktiva revisioner som spåras av Container Apps.

Det här exemplet visar hur du skapar en ny containerapp som spårar 50 inaktiva revisioner:

az containerapp create --max-inactive-revisions 50

Revisionslägen

Azure Container Apps stöder två revisionslägen. Valet av läge avgör hur många revisioner av appen som är aktiva samtidigt.

Revisionslägen beskrivning Standard
Enstaka Nya revisioner etableras, aktiveras och skalas automatiskt till önskad storlek. När alla repliker körs enligt skalningsregeln omdirigeras trafiken från den gamla versionen till den nya. Om en uppdatering misslyckas pekar trafiken fortfarande på den gamla revisionen. Gamla revisioner avetableras automatiskt. Ja
Flera Du kan ha flera aktiva revisioner, dela trafik mellan revisioner och välja när du vill avetablera gamla revisioner. Den här kontrollnivån är användbar för att testa flera versioner av en app, blågrön testning eller ta full kontroll över appuppdateringar. Mer information finns i trafikdelning.

Etiketter

För containerappar med extern HTTP-trafik dirigerar etiketter trafik till specifika revisioner. En etikett innehåller en unik URL som du kan använda för att dirigera trafik till den revision som etiketten har tilldelats.

Om du vill växla trafik mellan revisioner kan du flytta etiketten från en revision till en annan.

  • Etiketter behåller samma URL när de flyttas från en revision till en annan.
  • En etikett kan endast tillämpas på en revision i taget.
  • Allokering för trafikdelning krävs inte för revisioner med etiketter.
  • Etiketter är mest användbara när appen är i flera revisionslägen.
  • Du kan aktivera etiketter, trafikdelning eller både och.

Etiketter är användbara för att testa nya revisioner. När du till exempel vill ge åtkomst till en uppsättning testanvändare kan du ge dem etikettens URL. När du sedan vill flytta användarna till en annan revision kan du flytta etiketten till den revisionen.

Etiketter fungerar oberoende av trafikdelning. Trafikdelning distribuerar trafik som går till containerappens program-URL till revisioner baserat på procentandelen trafik. När trafiken dirigeras till en etiketts URL dirigeras trafiken till en specifik revision.

Ett etikettnamn måste:

  • Består av alfanumeriska gemener eller bindestreck (-)
  • Börja med ett alfabetiskt tecken
  • Avsluta med ett alfanumeriskt tecken

Etiketter får inte:

  • Ha två bindestreck i följd (--)
  • Mer än 64 tecken

Du kan hantera etiketter från containerappens revisionshanteringssida i Azure-portalen.

Screenshot of Container Apps revision management.

Etikett-URL:en är tillgänglig i fönstret revisionsinformation.

Screenshot of Container Apps revision details.

Avbrottsfri distribution

I enstaka revisionsläge ser Container Apps till att din app inte upplever driftstopp när du skapar en ny revision. Den befintliga aktiva revisionen inaktiveras inte förrän den nya revisionen är klar.

Om ingress är aktiverat fortsätter den befintliga revisionen att ta emot 100 % av trafiken tills den nya revisionen är klar.

En ny revision anses vara klar när:

  • Revisionen har etablerats
  • Revisionen har skalats upp för att matcha det tidigare revisionsreplikantalet (med hänsyn till den nya revisionens minsta och högsta antal repliker)
  • Alla repliker har klarat sina start- och beredskapsavsökningar

I flera revisionslägen kan du styra när revisioner aktiveras eller inaktiveras och vilka revisioner som tar emot inkommande trafik. Om en trafikdelningsregel har konfigurerats med latestRevision inställd truepå växlar trafiken inte till den senaste revisionen förrän den är klar.

Arbeta med flera revisioner

Även om läget för enkel revision är standard kanske du vill ha fullständig kontroll över hur dina revisioner hanteras.

Med flera revisionslägen kan du hantera revisionen manuellt. Om du till exempel använder flera revisionslägen kan du bestämma exakt hur mycket trafik som allokeras till varje revision.

Trafikdelning

Följande diagram visar en containerapp med två revisioner.

Azure Container Apps: Traffic splitting among revisions

Det här scenariot förutsätter att containerappen är i följande tillstånd:

  • Ingress är aktiverat, vilket gör containerappen tillgänglig via HTTP eller TCP.
  • Den första revisionen distribuerades som revision 1.
  • När containern har uppdaterats aktiverades en ny revision som revision 2.
  • Regler för trafikdelning konfigureras så att Revision 1 tar emot 80 % av begärandena och Revision 2 tar emot de återstående 20 %.

Direkt revisionsåtkomst

I stället för att använda en routningsregel för att omdirigera trafik till en revision kanske du vill göra en revision tillgänglig för begäranden för en specifik URL. Med flera revisionslägen kan du skicka alla begäranden som kommer in till din domän till den senaste revisionen, medan begäranden om en äldre revision är tillgängliga via etiketter för direkt åtkomst.

Aktiveringstillstånd

I flera revisionslägen kan du aktivera eller inaktivera revisioner efter behov. Aktiva revisioner fungerar och kan hantera begäranden, medan inaktiva revisioner förblir vilande.

Container Apps debiteras inte för inaktiva revisioner. Det finns dock ett tak för det totala antalet tillgängliga revisioner, där de äldsta rensas när du överskrider antalet 100.

Ändringstyper

Ändringar i en containerapp omfattas av två kategorier: ändringar i revisionsomfattning eller programomfattning . Ändringar i revisionsomfattning utlöser en ny revision när du distribuerar din app, medan ändringar i programomfattningen inte gör det.

Ändringar i revisionsomfattning

En ny revision skapas när en containerapp uppdateras med ändringar i revisionsomfattningen . Ändringarna är begränsade till revisionen där de distribueras och påverkar inte andra revisioner.

En ändring av revisionsomfattningen är en ändring av parametrarna i properties.template avsnittet i resursmallen för containerappen.

Dessa parametrar omfattar:

  • Revisionssuffix
  • Containerkonfiguration och avbildningar
  • Skalningsregler för containerprogrammet

Ändringar i programomfattning

När du distribuerar en containerapp med programomfattningsändringar :

  • Ändringarna tillämpas globalt på alla revisioner.
  • En ny revision skapas inte.

Ändringar av programomfattning definieras som alla ändringar av parametrarna properties.configuration i avsnittet i resursmallen för containerappen.

Dessa parametrar omfattar:

Anpassa revisioner

Du kan anpassa revisionsnamnet och etiketterna så att de bättre överensstämmer med namngivningskonventionerna eller versionsstrategin.

Namnsuffix

Varje revision i Container Apps tilldelas en unik identifierare. Även om namn genereras automatiskt kan du anpassa revisionsnamnet.

Det typiska formatet för ett revisionsnamn är:

<CONTAINER_APP_NAME>-<REVISION_SUFFIX>

Om du till exempel har en containerapp med namnet album-api och bestämmer dig för revisionssuffixet first-revision blir det fullständiga revisionsnamnet album-api-first-revision.

Ett revisionssuffixnamn måste:

  • Består endast av alfanumeriska gemener eller bindestreck (-)
  • Börja med ett alfabetiskt tecken
  • Avsluta med ett alfanumeriskt tecken

Namn får inte ha:

  • Två bindestreck i följd (--)
  • Mer än 64 tecken

Du kan ange revisionssuffixet i ARM-mallen, via Azure CLI az containerapp create och az containerapp update kommandon eller när du skapar en revision via Azure-portalen.

Användningsfall

Följande är vanliga användningsfall för att använda revisioner i containerappar. Den här listan är inte en fullständig lista över syftet med eller funktionerna för att använda Container Apps-revisioner.

Versionshantering

Revisioner effektiviserar processen med att introducera nya versioner av din app. När du är redo att distribuera en uppdatering eller en ny funktion kan du skapa en ny revision utan att påverka den aktuella liveversionen. Den här metoden säkerställer en smidig övergång och minimerar störningar för slutanvändarna.

Återgå till tidigare versioner

Ibland måste du snabbt återgå till en tidigare, stabil version av appen. Du kan återställa till en tidigare revision av containerappen om det behövs.

A/B-testning

När du vill testa olika versioner av din app kan revisioner stödja A/B-testning. Du kan dirigera en delmängd av användarna till en ny revision, samla in feedback och fatta välgrundade beslut baserat på verkliga data.

Blågröna distributioner

Revisioner stöder den blågröna distributionsstrategin . Genom att ha två parallella revisioner (blå för liveversionen och grönt för den nya) kan du gradvis fasa in en ny revision. När du är säker på den nya versionens stabilitet och prestanda kan du växla trafik helt till den gröna miljön.

Nästa steg