Wijzigingen bijwerken en implementeren in Azure Container Apps
Wijzigingsbeheer kan lastig zijn bij het ontwikkelen van containertoepassingen in de cloud. Uiteindelijk hebt u de ondersteuning nodig om wijzigingen bij te houden, de uptime te garanderen en mechanismen te hebben voor het afhandelen van vloeiende terugdraaiacties.
Wijzigingsbeheer in Azure Container Apps wordt mogelijk gemaakt door revisies. Dit is een momentopname van elke versie van uw container-app.
Belangrijke kenmerken van revisies zijn:
Onveranderbaar: Na de vaststelling blijft een revisie onveranderbaar.
Versiebeheer: Revisies fungeren als een record van de versies van de container-app, waarbij de status ervan in verschillende fasen wordt vastgelegd.
Automatisch ingericht: wanneer u een container-app voor de eerste keer implementeert, wordt automatisch een eerste revisie gemaakt.
Wijzigingen in bereik: terwijl revisies statisch blijven, kunnen wijzigingen in het toepassingsbereik van invloed zijn op alle revisies, terwijl wijzigingen in revisiebereik een nieuwe revisie maken.
Historische record: standaard hebt u toegang tot 100 inactieve revisies, maar u kunt deze drempelwaarde handmatig aanpassen.
Meerdere revisies: u kunt meerdere revisies tegelijk uitvoeren. Deze functie is vooral nuttig wanneer u verschillende versies van uw app tegelijk moet beheren.
Levenscyclus
Elke revisie ondergaat specifieke statussen, beïnvloed door de status en beschikbaarheid. Tijdens de levenscyclus doorloopt een container-app verschillende inrichting, uitvoering en een inactieve status.
Inrichtingsstatus
Wanneer u een nieuwe revisie maakt, ondergaat de container-app opstart- en gereedheidscontroles. Tijdens deze fase fungeert de inrichtingsstatus als richtlijn voor het bijhouden van de voortgang van de container-app.
| -Status | Beschrijving |
|---|---|
| Inrichting | De revisie bevindt zich in het verificatieproces. |
| Ingericht | De revisie heeft alle controles doorstaan. |
| Inrichting mislukt | Tijdens de verificatie zijn problemen opgetreden tijdens de revisie. |
Status wordt uitgevoerd
Nadat een container-app is ingericht, wordt de operationele fase van een revisie gestart. De actieve status helpt bij het bewaken van de status en functionaliteit van een container-app.
| -Status | Beschrijving |
|---|---|
| Inrichting | De revisie bevindt zich in het verificatieproces. |
| Schalen naar 0 | Nul actieve replica's en geen nieuwe replica's inrichten. De container-app kan nieuwe replica's maken als er schaalregels worden geactiveerd. |
| Activering | Nul actieve replica's, één replica die wordt ingericht. |
| Activering is mislukt | De eerste replica kan niet worden ingericht. |
| Schalen/verwerken | In- of uitschalen vindt plaats. Een of meer replica's worden uitgevoerd, terwijl andere replica's worden ingericht. |
| Wordt uitgevoerd | Een of meer replica's worden uitgevoerd. Er zijn geen problemen om te melden. |
| Wordt uitgevoerd (maximaal) | Het maximum aantal replica's (volgens de schaalregels van de revisie) wordt uitgevoerd. Er zijn geen problemen om te melden. |
| Inrichting ongedaan maken | De revisie gaat over van actief naar inactief en verwijdert alle resources die er zijn gemaakt. |
| Verminderd beschikbaar | Ten minste één replica in de revisie heeft de status Mislukt. Bekijk de details van de uitvoeringsstatus voor specifieke problemen. |
| Mislukt | Kritieke fouten hebben ertoe geleid dat revisies mislukken. De actieve status bevat details. Veelvoorkomende oorzaken zijn onder andere: •Beëindiging • Afsluitcode 137 |
Inactieve status
Revisies kunnen ook een inactieve status invoeren. Deze revisies hebben geen inrichtings- of actieve statussen. Azure Container Apps onderhoudt echter een lijst met deze revisies, met maximaal 100 inactieve vermeldingen. U kunt een revisie op elk gewenst moment activeren.
Inactieve revisielimiet wijzigen
U kunt de --max-inactive-revisions parameter gebruiken met de containerapp create of containerapp update opdrachten om het aantal inactieve revisies te beheren dat door Container Apps wordt bijgehouden.
In dit voorbeeld ziet u hoe u een nieuwe container-app maakt waarmee 50 inactieve revisies worden bijgehouden:
az containerapp create --max-inactive-revisions 50
Revisiemodi
Azure Container Apps ondersteunt twee revisiemodi. Uw keuze in de modus bepaalt hoeveel revisies van uw app tegelijkertijd actief zijn.
| Revisiemodi | Beschrijving | Standaard |
|---|---|---|
| Eén | Nieuwe revisies worden automatisch ingericht, geactiveerd en geschaald naar de gewenste grootte. Zodra alle replica's worden uitgevoerd zoals gedefinieerd door de schaalregel, wordt verkeer van de oude versie naar de nieuwe afgeleid. Als een update mislukt, blijft verkeer naar de oude revisie wijzen. Oude revisies worden automatisch ongedaan gemaakt. | Ja |
| Meer | U kunt meerdere actieve revisies hebben, verkeer splitsen tussen revisies en kiezen wanneer u oude revisies ongedaan wilt maken. Dit controleniveau is handig voor het testen van meerdere versies van een app, blauwgroen testen of het volledig beheren van app-updates. Raadpleeg het splitsen van verkeer voor meer informatie. |
Etiketten
Labels voor container-apps met extern HTTP-verkeer leiden verkeer naar specifieke revisies. Een label biedt een unieke URL die u kunt gebruiken om verkeer te routeren naar de revisie waaraan het label is toegewezen.
Als u wilt schakelen tussen revisies, kunt u het label van de ene revisie naar de andere verplaatsen.
- Labels behouden dezelfde URL wanneer ze van de ene revisie naar de andere worden verplaatst.
- Een label kan slechts op één revisie tegelijk worden toegepast.
- Toewijzing voor het splitsen van verkeer is niet vereist voor revisies met labels.
- Labels zijn het handigst wanneer de app zich in meerdere revisiemodus bevindt.
- U kunt labels, verkeer splitsen of beide inschakelen.
Labels zijn handig voor het testen van nieuwe revisies. Als u bijvoorbeeld toegang wilt geven tot een set testgebruikers, kunt u hen de URL van het label geven. Wanneer u uw gebruikers vervolgens naar een andere revisie wilt verplaatsen, kunt u het label naar die revisie verplaatsen.
Labels werken onafhankelijk van het splitsen van verkeer. Verkeer splitsen verdeelt verkeer naar de toepassings-URL van de container-app naar revisies op basis van het percentage verkeer. Wanneer verkeer wordt omgeleid naar de URL van een label, wordt het verkeer doorgestuurd naar één specifieke revisie.
Een labelnaam moet:
- Bestaan uit alfanumerieke tekens in kleine letters of streepjes (
-) - Beginnen met een alfabetisch teken
- Eindigen met een alfanumerieke teken
Labels mogen niet:
- Twee opeenvolgende streepjes (
--) hebben - Meer dan 64 tekens bevatten
U kunt labels beheren vanaf de pagina Revisiebeheer van uw container-app in Azure Portal.
De label-URL is beschikbaar in het revisiedetailsvenster.
Implementeren met nul uitvaltijd
In de modus voor één revisie zorgt Container Apps ervoor dat uw app geen downtime ondervindt bij het maken van een nieuwe revisie. De bestaande actieve revisie wordt pas gedeactiveerd als de nieuwe revisie gereed is.
Als inkomend verkeer is ingeschakeld, blijft de bestaande revisie 100% van het verkeer ontvangen totdat de nieuwe revisie gereed is.
Een nieuwe revisie wordt als gereed beschouwd wanneer:
- De revisie is ingericht
- De revisie is opgeschaald zodat deze overeenkomt met het aantal replica's van de vorige revisies (met inachtneming van het minimale en maximale aantal replica's van de nieuwe revisie)
- Alle replica's hebben hun opstart- en gereedheidstests doorstaan
In meerdere revisiemodus kunt u bepalen wanneer revisies worden geactiveerd of gedeactiveerd en welke revisies inkomend verkeer ontvangen. Als een regel voor het splitsen van verkeer is geconfigureerd met latestRevision ingesteld trueop, schakelt verkeer pas over naar de meest recente revisie als deze gereed is.
Werken met meerdere revisies
Hoewel de modus voor één revisie de standaardinstelling is, wilt u soms volledige controle hebben over de manier waarop uw revisies worden beheerd.
Meerdere revisiemodus biedt u de flexibiliteit om uw revisie handmatig te beheren. Als u bijvoorbeeld meerdere revisiemodus gebruikt, kunt u bepalen hoeveel verkeer aan elke revisie wordt toegewezen.
Opsplitsen van verkeer
In het volgende diagram ziet u een container-app met twee revisies.
In dit scenario wordt ervan uitgegaan dat de container-app de volgende status heeft:
- Inkomend verkeer is ingeschakeld, waardoor de container-app beschikbaar is via HTTP of TCP.
- De eerste revisie is geïmplementeerd als revisie 1.
- Nadat de container is bijgewerkt, is een nieuwe revisie geactiveerd als Revisie 2.
- Regels voor het splitsen van verkeer worden zo geconfigureerd dat Revisie 1 80% van de aanvragen ontvangt en Revisie 2 de resterende 20% ontvangt.
Directe revisietoegang
In plaats van een routeringsregel te gebruiken om verkeer om te leiden naar een revisie, wilt u mogelijk een revisie beschikbaar maken voor aanvragen voor een specifieke URL. Met meerdere revisiemodus kunt u alle aanvragen naar uw domein verzenden naar de meest recente revisie, terwijl aanvragen voor een oudere revisie beschikbaar zijn via labels voor directe toegang.
Activeringsstatus
In meerdere revisiemodus kunt u indien nodig revisies activeren of deactiveren. Actieve revisies zijn operationeel en kunnen aanvragen verwerken, terwijl inactieve revisies inactief blijven.
Container Apps brengt geen kosten in rekening voor inactieve revisies. Er is echter een limiet voor het totale aantal beschikbare revisies, waarbij de oudste worden opgeschoond zodra u het aantal van 100 overschrijdt.
Wijzigingstypen
Wijzigingen in een container-app vallen onder twee categorieën: wijzigingen in revisiebereik of toepassingsbereik . Wijzigingen in revisiebereik activeren een nieuwe revisie wanneer u uw app implementeert, terwijl wijzigingen in toepassingsbereik niet.
Wijzigingen in revisiebereik
Er wordt een nieuwe revisie gemaakt wanneer een container-app wordt bijgewerkt met wijzigingen in het revisiebereik . De wijzigingen zijn beperkt tot de revisie waarin ze worden geïmplementeerd en hebben geen invloed op andere revisies.
Een wijziging in het revisiebereik is elke wijziging in de parameters in de properties.template sectie van de resourcesjabloon voor de container-app.
Deze parameters omvatten:
- Revisieachtervoegsel
- Containerconfiguratie en installatiekopieën
- Regels schalen voor de containertoepassing
Wijzigingen in het toepassingsbereik
Wanneer u een container-app implementeert met wijzigingen in het toepassingsbereik :
- De wijzigingen worden globaal toegepast op alle revisies.
- Er wordt geen nieuwe revisie gemaakt.
Wijzigingen in toepassingsbereik worden gedefinieerd als elke wijziging in de parameters in de properties.configuration sectie van de resourcesjabloon van de container-app.
Deze parameters omvatten:
- Geheime waarden (revisies moeten opnieuw worden gestart voordat een container nieuwe geheime waarden herkent)
- Revisiemodus
- Configuratie voor inkomend verkeer, waaronder:
- Inkomend verkeer in- of uitschakelen
- Regels voor het splitsen van verkeer
- Etiketten
- Referenties voor privécontainerregisters
- Dapr-instellingen
Revisies aanpassen
U kunt de revisienaam en labels aanpassen zodat deze beter aansluiten bij uw naamconventies of versiebeheerstrategie.
Achtervoegsel naam
Aan elke revisie in Container Apps wordt een unieke id toegewezen. Terwijl namen automatisch worden gegenereerd, kunt u de revisienaam aanpassen.
De gebruikelijke indeling voor een revisienaam is:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Als u bijvoorbeeld een container-app hebt met de naam album-api en besluit over het revisieachtervoegsel first-revision, wordt de volledige revisienaam album-api-first-revision.
De naam van een revisieachtervoegsel moet:
- Bestaan alleen uit alfanumerieke tekens of streepjes in kleine letters (
-) - Beginnen met een alfabetisch teken
- Eindigen met een alfanumerieke teken
Namen mogen niet het volgende hebben:
- Twee opeenvolgende streepjes (
--) - Meer dan 64 tekens bevatten
U kunt het revisieachtervoegsel instellen in de ARM-sjabloon, via de Azure CLI az containerapp create en az containerapp update opdrachten, of wanneer u een revisie maakt via Azure Portal.
Gebruiksgevallen
Hier volgen veelvoorkomende gebruiksvoorbeelden voor het gebruik van revisies in container-apps. Deze lijst is geen volledige lijst met het doel of de mogelijkheden van het gebruik van Container Apps-revisies.
Releasebeheer
Revisies stroomlijnen het proces van het introduceren van nieuwe versies van uw app. Wanneer u klaar bent om een update of een nieuwe functie uit te rollen, kunt u een nieuwe revisie maken zonder dat dit van invloed is op de huidige liveversie. Deze aanpak zorgt voor een soepele overgang en minimaliseert onderbrekingen voor eindgebruikers.
Terugkeren naar eerdere versies
Soms moet u snel terugkeren naar een eerdere, stabiele versie van uw app. U kunt zo nodig terugkeren naar een eerdere revisie van uw container-app.
A/B-tests
Als u verschillende versies van uw app wilt testen, kunnen revisies ondersteuning bieden voor A/B-tests. U kunt een subset van uw gebruikers doorsturen naar een nieuwe revisie, feedback verzamelen en weloverwogen beslissingen nemen op basis van echte gegevens.
Blauw-groene implementaties
Revisies ondersteunen de blauwgroene implementatiestrategie . Door twee parallelle revisies (blauw voor de liveversie en groen voor de nieuwe versie) te hebben, kunt u geleidelijk aan een nieuwe revisie fasen. Zodra u zeker bent van de stabiliteit en prestaties van de nieuwe versie, kunt u verkeer volledig overschakelen naar de groene omgeving.