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.
Etikett-URL:en är tillgänglig i fönstret revisionsinformation.
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.
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:
- Hemliga värden (revisioner måste startas om innan en container identifierar nya hemliga värden)
- Revisionsläge
- Ingresskonfiguration, inklusive:
- Aktivera eller inaktivera ingress
- Regler för trafikdelning
- Etiketter
- Autentiseringsuppgifter för privata containerregister
- Dapr-inställningar
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.