Implementatie en testen voor bedrijfskritieke workloads in Azure

De implementatie en het testen van de bedrijfskritieke omgeving is een cruciaal onderdeel van de algehele referentiearchitectuur. De afzonderlijke toepassingsstempels worden geïmplementeerd met infrastructuur als code uit een opslagplaats voor broncode. Updates voor de infrastructuur en de toepassing bovenaan moeten worden geïmplementeerd zonder downtime voor de toepassing. Een DevOps-pijplijn voor continue integratie wordt aanbevolen om de broncode op te halen uit de opslagplaats en de afzonderlijke stempels in Azure te implementeren.

Implementatie en updates vormen het centrale proces in de architectuur. Infrastructuur- en toepassingsgerelateerde updates moeten worden geïmplementeerd op volledig onafhankelijke stempels. Alleen de onderdelen van de globale infrastructuur in de architectuur worden gedeeld via de stempels. Bestaande stempels in de infrastructuur worden niet aangeraakt. Infrastructuurupdates worden alleen geïmplementeerd op deze nieuwe stempels. Op dezelfde manier wordt de nieuwe toepassingsversie alleen geïmplementeerd op deze nieuwe stempels.

De nieuwe stempels worden toegevoegd aan Azure Front Door. Verkeer wordt geleidelijk verplaatst naar de nieuwe stempels. Wanneer wordt vastgesteld dat het verkeer van de nieuwe stempels zonder uitgifte wordt geleverd, worden de vorige stempels verwijderd.

Penetratie, chaos en stresstests worden aanbevolen voor de geïmplementeerde omgeving. Proactief testen van de infrastructuur detecteert zwakke punten en hoe de geïmplementeerde toepassing zich gedraagt als er een fout optreedt.

Implementatie

De implementatie van de infrastructuur in de referentiearchitectuur is afhankelijk van de volgende processen en onderdelen:

• DevOps : de broncode van GitHub en pijplijnen voor de infrastructuur.

• Geen downtime-updates : updates en upgrades worden geïmplementeerd in de omgeving zonder downtime voor de geïmplementeerde toepassing.

• Omgevingen: kortlevende en permanente omgevingen die worden gebruikt voor de architectuur.

• Gedeelde en toegewezen resources : Azure-resources die zijn toegewezen en gedeeld met de stempels en de algehele infrastructuur.

Zie Implementatie en testen voor bedrijfskritieke workloads in Azure voor meer informatie : ontwerpoverwegingen

Implementatie: DevOps

De DevOps-onderdelen bieden de broncodeopslagplaats en CI/CD-pijplijnen voor de implementatie van de infrastructuur en updates. GitHub en Azure Pipelines zijn gekozen als de onderdelen.

• GitHub : bevat de broncodeopslagplaatsen voor de toepassing en infrastructuur.

• Azure Pipelines : de pijplijnen die door de architectuur worden gebruikt voor alle build-, test- en releasetaken.

Een extra onderdeel in het ontwerp dat voor de implementatie wordt gebruikt, zijn buildagents. Door Microsoft gehoste buildagents worden gebruikt als onderdeel van Azure Pipelines om de infrastructuur en updates te implementeren. Het gebruik van door Microsoft gehoste buildagents verwijdert de beheerlast voor ontwikkelaars om de buildagent te onderhouden en bij te werken.

Zie Wat is Azure DevOps Services? voor meer informatie over Azure Pipelines.

Zie Implementatie en testen voor bedrijfskritieke workloads in Azure voor meer informatie: Implementaties van infrastructuur als code

Implementatie: Geen downtime-updates

De updatestrategie zonder downtime in de referentiearchitectuur is essentieel voor de algemene bedrijfskritieke toepassing. De methodologie voor vervanging in plaats van de postzegels te upgraden zorgt voor een nieuwe installatie van de toepassing in een infrastructuurstempel. De referentiearchitectuur maakt gebruik van een blauw/groene benadering en maakt afzonderlijke test- en ontwikkelomgevingen mogelijk.

Er zijn twee hoofdonderdelen van de referentiearchitectuur:

• Infrastructuur : Azure-services en -resources. Geïmplementeerd met Terraform en de bijbehorende configuratie.

• Toepassing : de gehoste service of toepassing die gebruikers bedient. Op basis van Docker-containers en npm-ingebouwde artefacten in HTML en JavaScript voor de gebruikersinterface van de toepassing met één pagina (SPA).

In veel systemen wordt ervan uitgegaan dat toepassingsupdates vaker worden uitgevoerd dan infrastructuurupdates. Als gevolg hiervan worden verschillende updateprocedures ontwikkeld voor elk. Met een openbare cloudinfrastructuur kunnen wijzigingen sneller plaatsvinden. Er is één implementatieproces gekozen voor toepassingsupdates en infrastructuurupdates. Eén benadering zorgt ervoor dat infrastructuur- en toepassingsupdates altijd gesynchroniseerd zijn. Met deze methode kunt u het volgende doen:

• Eén consistent proces : minder kans op fouten als infrastructuur- en toepassingsupdates samen worden gecombineerd in een release, opzettelijk of niet.

• Hiermee schakelt u Blue/Green-implementatie in: elke update wordt geïmplementeerd met behulp van een geleidelijke migratie van verkeer naar de nieuwe release.

• Eenvoudigere implementatie en foutopsporing van de toepassing : het volledige stempel host nooit meerdere versies van de toepassing naast elkaar.

• Eenvoudig terugdraaien : verkeer kan worden teruggezet naar de stempels waarop de vorige versie wordt uitgevoerd als er fouten of problemen zijn opgetreden.

• Verwijdering van handmatige wijzigingen en configuratiedrift : elke omgeving is een nieuwe implementatie.

Zie Implementatie en testen voor bedrijfskritieke workloads in Azure voor meer informatie : Kortstondige blauw/groene implementaties

Vertakkingsstrategie

De basis van de updatestrategie is het gebruik van vertakkingen in de Git-opslagplaats. De referentiearchitectuur maakt gebruik van drie typen vertakkingen:

Vertakking	Beschrijving
feature/* en fix/*	De toegangspunten voor elke wijziging. Deze vertakkingen worden gemaakt door ontwikkelaars en moeten een beschrijvende naam krijgen, zoals feature/catalog-update of fix/worker-timeout-bug. Wanneer wijzigingen gereed zijn om te worden samengevoegd, wordt er een pull-aanvraag (PR) voor de main vertakking gemaakt. Elke pull-aanvraag moet worden goedgekeurd door ten minste één revisor. Met beperkte uitzonderingen moet elke wijziging die wordt voorgesteld in een pull-aanvraag, worden uitgevoerd via de end-to-end-validatiepijplijn (E2E). De E2E-pijplijn moet door ontwikkelaars worden gebruikt om wijzigingen in een volledige omgeving te testen en fouten op te sporen.
main	De continu bewegende en stabiele tak. Meestal gebruikt voor integratietests. Wijzigingen worden main alleen aangebracht via pull-aanvragen. Een vertakkingsbeleid verbiedt directe schrijfbewerkingen. Nachtreleases in de permanente integration (int) omgeving worden automatisch uitgevoerd vanuit de main vertakking. De main vertakking wordt als stabiel beschouwd. Het moet veilig zijn om ervan uit te gaan dat op elk gewenst moment een release kan worden gemaakt.
release/*	Release-vertakkingen worden alleen gemaakt op basis van de main vertakking. De vertakkingen volgen de indeling release/2021.7.X. Vertakkingsbeleid wordt gebruikt zodat alleen beheerders van opslagplaatsen vertakkingen mogen maken release/* . Alleen deze vertakkingen worden gebruikt om in de prod omgeving te implementeren.

Zie Implementatie en testen voor bedrijfskritieke workloads in Azure voor meer informatie : Vertakkingsstrategie

Hotfixes

Wanneer een hotfix dringend is vereist vanwege een bug of ander probleem en het normale releaseproces niet kan doorlopen, is er een hotfix-pad beschikbaar. Essentiële beveiligingsupdates en oplossingen voor de gebruikerservaring die niet zijn gedetecteerd tijdens de eerste test, worden beschouwd als geldige voorbeelden van hotfixes.

De hotfix moet worden gemaakt in een nieuwe fix vertakking en vervolgens worden samengevoegd main met een reguliere pull-aanvraag. In plaats van een nieuwe releasebranch te maken, wordt de hotfix 'cherry-picked' in een bestaande releasebranch. Deze vertakking is al geïmplementeerd in de prod omgeving. De CI/CD-pijplijn die oorspronkelijk de releasebranch heeft geïmplementeerd met alle tests, wordt opnieuw uitgevoerd en implementeert nu de hotfix als onderdeel van de pijplijn.

Om grote problemen te voorkomen, is het belangrijk dat de hotfix enkele geïsoleerde doorvoeringen bevat die eenvoudig kunnen worden gekozen en geïntegreerd in de releasevertakking. Als geïsoleerde doorvoeringen niet kunnen worden gekozen om te integreren in de releasebranch, is het een indicatie dat de wijziging niet in aanmerking komt als hotfix. De wijziging moet worden geïmplementeerd als een volledige nieuwe release en mogelijk gecombineerd met een terugdraaiactie naar een voormalige stabiele versie totdat de nieuwe release kan worden geïmplementeerd.

Implementatie: Omgevingen

De referentiearchitectuur maakt gebruik van twee soorten omgevingen voor de infrastructuur:

• Korte levensduur : de E2E-validatiepijplijn wordt gebruikt om kortdurende omgevingen te implementeren. Kortlevende omgevingen worden gebruikt voor pure validatie- of foutopsporingsomgevingen voor ontwikkelaars. Validatieomgevingen kunnen worden gemaakt vanuit de feature/* vertakking, onderworpen aan tests en vervolgens vernietigd als alle tests zijn geslaagd. Foutopsporingsomgevingen worden op dezelfde manier geïmplementeerd als validatie, maar worden niet onmiddellijk vernietigd. Deze omgevingen mogen niet langer dan een paar dagen bestaan en moeten worden verwijderd wanneer de bijbehorende pull-aanvraag van de functiebranch wordt samengevoegd.

• Permanent - In de permanente omgevingen zijn integration (int) er en production (prod) versies. Deze omgevingen leven continu en worden niet vernietigd. De omgevingen maken gebruik van vaste domeinnamen, zoals int.mission-critical.app. In een echte implementatie van de referentiearchitectuur moet een staging (pre-prod) omgeving worden toegevoegd. De staging omgeving wordt gebruikt voor het implementeren en valideren release van vertakkingen met hetzelfde updateproces als prod (Blue/Green-implementatie).

  • Integratie (int): de int versie wordt 's nachts vanuit de main vertakking geïmplementeerd met hetzelfde proces als prod. De overschakeling van verkeer is sneller dan de vorige release-eenheid. In plaats van het verkeer geleidelijk over te schakelen over meerdere dagen, zoals in prod, wordt het proces int binnen een paar minuten of uren voltooid. Deze snellere overstap zorgt ervoor dat de bijgewerkte omgeving de volgende ochtend gereed is. Oude stempels worden automatisch verwijderd als alle tests in de pijplijn zijn geslaagd.

  • Productie (prod): de prod versie wordt alleen geïmplementeerd vanuit release/* vertakkingen. De verkeersoverschakeling maakt gebruik van gedetailleerdere stappen. Er is een handmatige goedkeuringspoort tussen elke stap. Elke release maakt nieuwe regionale stempels en implementeert de nieuwe toepassingsversie op de stempels. Bestaande stempels worden niet in het proces aangeraakt. De belangrijkste overweging prod hiervoor is dat het 'altijd aan' moet zijn. Geplande of ongeplande downtime mag nooit plaatsvinden. De enige uitzondering hierop zijn fundamentele wijzigingen in de databaselaag. Mogelijk is er een gepland onderhoudsvenster nodig.

Implementatie: Gedeelde en toegewezen resources

De permanente omgevingen (int en prod) binnen de referentiearchitectuur hebben verschillende typen resources, afhankelijk van of ze worden gedeeld met de volledige infrastructuur of toegewezen aan een afzonderlijke stempel. Resources kunnen worden toegewezen aan een bepaalde release en bestaan alleen totdat de volgende release-eenheid is overgenomen.

Release-eenheden

Een release-eenheid is verschillende regionale stempels per specifieke releaseversie. Stempels bevatten alle resources die niet worden gedeeld met de andere stempels. Dit zijn virtuele netwerken, Azure Kubernetes Service-cluster, Event Hubs en Azure Key Vault. Azure Cosmos DB en ACR worden geconfigureerd met Terraform-gegevensbronnen.

Wereldwijd gedeelde resources

Alle resources die worden gedeeld tussen release-eenheden, worden gedefinieerd in een onafhankelijke Terraform-sjabloon. Deze resources zijn Front Door, Azure Cosmos DB, Container Registry (ACR) en de Log Analytics-werkruimten en andere bewakingsgerelateerde resources. Deze resources worden geïmplementeerd voordat de eerste regionale stempel van een release-eenheid wordt geïmplementeerd. Naar de resources wordt verwezen in de Terraform-sjablonen voor de stempels.

Front Door

Front Door is een wereldwijd gedeelde resource tussen stempels, maar de configuratie is iets anders dan de andere globale resources. Front Door moet opnieuw worden geconfigureerd nadat een nieuwe stempel is geïmplementeerd. Front Door moet opnieuw worden geconfigureerd om het verkeer geleidelijk over te schakelen naar de nieuwe stempels.

De back-endconfiguratie van Front Door kan niet rechtstreeks worden gedefinieerd in de Terraform-sjabloon. De configuratie wordt ingevoegd met Terraform-variabelen. De variabelewaarden worden samengesteld voordat de Terraform-implementatie wordt gestart.

De configuratie van afzonderlijke onderdelen voor de Front Door-implementatie wordt gedefinieerd als:

• Front-end : sessieaffiniteit is geconfigureerd om ervoor te zorgen dat gebruikers tijdens één sessie niet schakelen tussen verschillende ui-versies.

• Origins : Front Door is geconfigureerd met twee soorten oorsprongsgroepen :

  1. Een oorsprongsgroep voor statische opslag die de gebruikersinterface dient. De groep bevat de websiteopslagaccounts van alle actieve release-eenheden. Verschillende gewichten kunnen worden toegewezen aan de oorsprongen van verschillende release-eenheden om het verkeer geleidelijk naar een nieuwere eenheid te verplaatsen. Aan elke oorsprong van een release-eenheid moet hetzelfde gewicht zijn toegewezen.

  2. Een oorsprongsgroep voor de API, die wordt gehost op AKS. Als er release-eenheden met verschillende API-versies zijn, bestaat er voor elke release-eenheid een API-oorspronggroep. Als alle release-eenheden dezelfde compatibele API bieden, worden alle origins toegevoegd aan dezelfde groep en verschillende gewichten toegewezen.

• Routeringsregels : er zijn twee typen routeringsregels:

  1. Een routeringsregel voor de gebruikersinterface die is gekoppeld aan de oorspronkelijke groep van de gebruikersinterface.

  2. Een routeringsregel voor elke API die momenteel wordt ondersteund door de oorsprongen. Bijvoorbeeld: /api/1.0/* en /api/2.0/*.

  Als een release een nieuwe versie van de back-end-API's introduceert, worden de wijzigingen weergegeven in de gebruikersinterface die wordt geïmplementeerd als onderdeel van de release. Een specifieke release van de gebruikersinterface roept altijd een specifieke versie van de API-URL aan. Gebruikers die worden geleverd door een gebruikersinterfaceversie, gebruiken automatisch de respectieve back-end-API. Er zijn specifieke routeringsregels nodig voor verschillende exemplaren van de API-versie. Deze regels zijn gekoppeld aan de bijbehorende oorsprongsgroepen. Als er geen nieuwe API is geïntroduceerd, worden alle API-gerelateerde routeringsregels gekoppeld aan de groep met één oorsprong. In dit geval maakt het niet uit of een gebruiker de gebruikersinterface van een andere release dan de API gebruikt.

Implementatie: implementatieproces

Een blauw/groen implementatie is het doel van het implementatieproces. Er wordt een nieuwe release van een release/* vertakking geïmplementeerd in de prod omgeving. Gebruikersverkeer wordt geleidelijk verplaatst naar de stempels voor de nieuwe release.

Als eerste stap in het implementatieproces van een nieuwe versie wordt de infrastructuur voor de nieuwe release-eenheid geïmplementeerd met Terraform. Door de implementatiepijplijn voor de infrastructuur uit te voeren, wordt de nieuwe infrastructuur geïmplementeerd vanuit een geselecteerde releasebranch. Parallel aan het inrichten van de infrastructuur worden de containerinstallatiekopieën gebouwd of geïmporteerd en naar het wereldwijd gedeelde containerregister (ACR) gepusht. Wanneer de vorige processen zijn voltooid, wordt de toepassing geïmplementeerd op de stempels. Vanuit het oogpunt van implementatie is het één pijplijn met meerdere afhankelijke fasen. Dezelfde pijplijn kan opnieuw worden uitgevoerd voor hotfix-implementaties.

Nadat de nieuwe release-eenheid is geïmplementeerd en gevalideerd, wordt deze toegevoegd aan Front Door om gebruikersverkeer te ontvangen.

Een switch/parameter die onderscheid maakt tussen releases die wel en geen nieuwe API-versie introduceren, moet worden gepland. Op basis van of de release een nieuwe API-versie introduceert, moet er een nieuwe origin-groep met de API-back-ends worden gemaakt. U kunt ook nieuwe API-back-ends toevoegen aan een bestaande oorspronkelijke groep. Nieuwe UI-opslagaccounts worden toegevoegd aan de bijbehorende bestaande oorspronkelijke groep. Gewichten voor nieuwe oorsprongen moeten worden ingesteld op basis van de gewenste verkeerssplitsing. Er moet een nieuwe routeringsregel worden gemaakt die overeenkomt met de juiste oorsprongsgroep.

Als onderdeel van de toevoeging van de nieuwe release-eenheid moeten de gewichten van de nieuwe oorsprong worden ingesteld op het gewenste minimale gebruikersverkeer. Als er geen problemen worden gedetecteerd, moet de hoeveelheid gebruikersverkeer gedurende een bepaalde periode worden verhoogd naar de nieuwe oorspronkelijke groep. Als u de gewichtsparameters wilt aanpassen, moeten dezelfde implementatiestappen opnieuw worden uitgevoerd met de gewenste waarden.

Teardown van release-eenheid

Als onderdeel van de implementatiepijplijn voor een release-eenheid is er een vernietigingsfase die alle stempels verwijdert zodra een release-eenheid niet meer nodig is. Al het verkeer wordt verplaatst naar een nieuwe versie van de release. Deze fase omvat het verwijderen van release-eenheidsverwijzingen van Front Door. Deze verwijdering is essentieel om de release van een nieuwe versie op een latere datum mogelijk te maken. Front Door moet verwijzen naar één release-eenheid om in de toekomst voorbereid te zijn op de volgende release.

Controlelijsten

Als onderdeel van het releaseritme moet er een controlelijst vóór en na de release worden gebruikt. Het volgende voorbeeld is van items die minimaal in een controlelijst moeten staan.

• Controlelijst vóór release : controleer het volgende voordat u een release start:

  • Zorg ervoor dat de meest recente status van de main vertakking is geïmplementeerd en getest in de int omgeving.

  • Werk het changelog-bestand bij via een pull-aanvraag voor de main vertakking.

  • Maak een release/ vertakking van de main vertakking.

• Controlelijst na release - Voordat oude stempels worden vernietigd en hun verwijzingen uit Front Door worden verwijderd, controleert u of:

  • Clusters ontvangen geen binnenkomend verkeer meer.

  • Event Hubs en andere berichtenwachtrijen bevatten geen niet-verwerkte berichten.

Implementatie: Beperkingen en risico's van de updatestrategie

De updatestrategie die in deze referentiearchitectuur wordt beschreven, heeft enkele beperkingen en risico's die moeten worden vermeld:

• Hogere kosten: bij het vrijgeven van updates zijn veel van de infrastructuuronderdelen twee keer actief voor de releaseperiode.

• Front Door-complexiteit: het updateproces in Front Door is complex om te implementeren en te onderhouden. De mogelijkheid om effectieve blauw/groene implementaties zonder downtime uit te voeren, is afhankelijk van het goed werken.

• Kleine wijzigingen tijdrovend: het updateproces resulteert in een langer releaseproces voor kleine wijzigingen. Deze beperking kan gedeeltelijk worden verzacht met het hotfixproces dat in de vorige sectie wordt beschreven.

Implementatie: Compatibiliteitsoverwegingen voor toepassingsgegevens doorsturen

De updatestrategie kan ondersteuning bieden voor meerdere versies van een API en werkonderdelen die gelijktijdig worden uitgevoerd. Omdat Azure Cosmos DB wordt gedeeld tussen twee of meer versies, is het mogelijk dat gegevenselementen die door één versie zijn gewijzigd, mogelijk niet altijd overeenkomen met de versie van de API of werkrollen die deze gebruiken. De API-lagen en -werkrollen moeten het ontwerp voor compatibiliteit vooruit implementeren. In eerdere versies van de API of werkrolonderdelen worden gegevens verwerkt die zijn ingevoegd door een latere API- of worker-onderdeelversie. Het negeert delen die het niet begrijpt.

Testen

De referentiearchitectuur bevat verschillende tests die in verschillende fasen in de test-implementatie worden gebruikt.

Deze tests omvatten:

• Eenheidstests: deze tests valideren dat de bedrijfslogica van de toepassing werkt zoals verwacht. De referentiearchitectuur bevat een voorbeeldsuite met eenheidstests die automatisch worden uitgevoerd voordat elke container wordt gebouwd door Azure Pipelines. Als een test mislukt, stopt de pijplijn. Bouwen en implementeren gaat niet verder.

• Belastingstests: deze tests helpen bij het evalueren van de capaciteit, schaalbaarheid en mogelijke knelpunten voor een bepaalde workload of stack. De referentie-implementatie bevat een generator voor gebruikersbelasting om synthetische belastingpatronen te maken die kunnen worden gebruikt om echt verkeer te simuleren. De loadgenerator kan ook onafhankelijk van de referentie-implementatie worden gebruikt.

• Betrouwbaarheidstests: deze tests bepalen of de infrastructuur en workload beschikbaar zijn en werken zoals verwacht. Betrouwbaarheidstests worden uitgevoerd als onderdeel van elke implementatie.

• UI-tests: deze tests valideren dat de gebruikersinterface is geïmplementeerd en werkt zoals verwacht. De huidige implementatie legt alleen schermopnamen van verschillende pagina's vast na de implementatie zonder daadwerkelijk testen.

• Mislukte injectietests: deze tests kunnen worden geautomatiseerd of handmatig worden uitgevoerd. Geautomatiseerd testen in de architectuur integreert Azure Chaos Studio als onderdeel van de implementatiepijplijnen.

Zie Implementatie en testen voor bedrijfskritieke workloads in Azure voor meer informatie : Continue validatie en testen

Testen: Frameworks

De online referentie implementatie bestaande testmogelijkheden en frameworks waar mogelijk.

Framework	Testen	Beschrijving
Nunit	Eenheid	Dit framework wordt gebruikt voor het testen van het .NET Core-gedeelte van de implementatie. Eenheidstests worden automatisch uitgevoerd door Azure Pipelines vóór container-builds.
JMeter met Azure Load Testing	Laden	Azure Load Testing is een beheerde service die wordt gebruikt voor het uitvoeren van Apache JMeter-belastingtestdefinities .
Locust	Laden	Locust is een opensource-framework voor belastingstests dat is geschreven in Python.
Toneelschrijver	Gebruikersinterface en rook	Playwright is een open source Node.js bibliotheek voor het automatiseren van Chromium, Firefox en WebKit met één API. De Playwright-testdefinitie kan ook onafhankelijk van de referentie-implementatie worden gebruikt.
Azure Chaos Studio	Foutinjectie	De referentie-implementatie maakt gebruik van Azure Chaos Studio als een optionele stap in de E2E-validatiepijplijn om fouten in te voeren voor tolerantievalidatie.

Testen: Testen van foutinjectie en Chaos Engineering

Gedistribueerde toepassingen moeten tolerant zijn voor service- en onderdeelstoringen. Testen van foutinjectie (ook wel foutinjectie of Chaos Engineering genoemd) is de praktijk van het onderwerpen van toepassingen en services aan echte stress en fouten.

Tolerantie is een eigenschap van een volledig systeem en het injecteren van fouten helpt bij het vinden van problemen in de toepassing. Door deze problemen op te lossen, kunt u de tolerantie van toepassingen valideren in onbetrouwbare omstandigheden, ontbrekende afhankelijkheden en andere fouten.

Handmatige en automatische tests kunnen worden uitgevoerd op basis van de infrastructuur om fouten en problemen in de implementatie te vinden.

Automatisch

De referentiearchitectuur integreert Azure Chaos Studio om een set Azure Chaos Studio-experimenten te implementeren en uit te voeren om verschillende fouten op stempelniveau te injecteren. Chaos-experimenten kunnen worden uitgevoerd als een optioneel onderdeel van de E2E-implementatiepijplijn. Wanneer de tests worden uitgevoerd, wordt de optionele belastingstest altijd parallel uitgevoerd. De belastingstest wordt gebruikt om de belasting van het cluster te maken om het effect van de geïnjecteerde fouten te valideren.

Handmatig

Handmatig testen van foutinjectie moet worden uitgevoerd in een E2E-validatieomgeving. Deze omgeving zorgt voor volledige representatieve tests zonder risico op interferentie van andere omgevingen. De meeste fouten die met de tests zijn gegenereerd, kunnen rechtstreeks worden waargenomen in de weergave metrische gegevens van Application Insights Live. De resterende fouten zijn beschikbaar in de weergave Fouten en de bijbehorende logboektabellen. Voor andere fouten is diepere foutopsporing vereist, zoals het gebruik van kubectl het gedrag in AKS.

Twee voorbeelden van mislukte injectietests die worden uitgevoerd op basis van de referentiearchitectuur zijn:

• Foutinjectie op basis van DNS: een testcase die meerdere problemen kan simuleren. DNS-omzettingsfouten vanwege de fout van een DNS-server of Azure DNS. Testen op basis van DNS kan helpen bij het simuleren van algemene verbindingsproblemen tussen een client en een service, bijvoorbeeld wanneer de BackgroundProcessor geen verbinding kan maken met de Event Hubs.

  In scenario's met één host kunt u het lokale hosts bestand wijzigen om DNS-omzetting te overschrijven. In een grotere omgeving met meerdere dynamische servers, zoals AKS, is een hosts bestand niet haalbaar. Azure Privé-DNS Zones kunnen worden gebruikt als alternatief voor het testen van foutscenario's.

  Azure Event Hubs en Azure Cosmos DB zijn twee van de Azure-services die worden gebruikt in de referentie-implementatie die kunnen worden gebruikt voor het injecteren van DNS-fouten. Dns-omzetting van Event Hubs kan worden gemanipuleerd met een Azure Privé-DNS-zone die is gekoppeld aan het virtuele netwerk van een van de stempels. Azure Cosmos DB is een wereldwijd gerepliceerde service met specifieke regionale eindpunten. Manipulatie van de DNS-records voor deze eindpunten kan een fout voor een specifieke regio simuleren en de failover van clients testen.

• Firewallblokkering : de meeste Azure-services ondersteunen firewalltoegangsbeperkingen op basis van virtuele netwerken en/of IP-adressen. In de referentie-infrastructuur worden deze beperkingen gebruikt om de toegang tot Azure Cosmos DB of Event Hubs te beperken. Een eenvoudige procedure is het verwijderen van bestaande regels voor toestaan of het toevoegen van nieuwe blokregels . Met deze procedure kunnen onjuiste configuraties van firewalls of servicestoringen worden gesimuleerd.

  De volgende voorbeeldservices in de referentie-implementatie kunnen worden getest met een firewalltest:

  Service	Resultaat
  Sleutelkluis	Wanneer de toegang tot Key Vault wordt geblokkeerd, is het meest directe effect het mislukken van nieuwe pods om te spawn. Het CSI-stuurprogramma van Key Vault dat geheimen ophaalt bij het opstarten van pods, kan de taken niet uitvoeren en voorkomt dat de pod wordt gestart. Bijbehorende foutberichten kunnen worden waargenomen met kubectl describe po CatalogService-deploy-my-new-pod -n workload. Bestaande pods blijven werken, hoewel hetzelfde foutbericht wordt waargenomen. Het foutbericht wordt gegenereerd door de resultaten van de periodieke updatecontrole voor geheimen. Hoewel deze niet is getest, wordt ervan uitgegaan dat het uitvoeren van een implementatie niet werkt terwijl Key Vault niet toegankelijk is. Terraform- en Azure CLI-taken in de pijplijnuitvoering doen aanvragen naar Key Vault.
  Event Hubs	Wanneer de toegang tot Event Hubs wordt geblokkeerd, mislukken nieuwe berichten die worden verzonden door de CatalogService en HealthService. Het ophalen van berichten door BackgroundProcess mislukt langzaam, met een totale fout binnen een paar minuten.
  Azure Cosmos DB	Als u het bestaande firewallbeleid voor een virtueel netwerk verwijdert, mislukt de Health Service met minimale vertraging. Met deze procedure wordt alleen een specifiek geval gesimuleerd, een volledige Azure Cosmos DB-storing. De meeste foutgevallen die zich op regionaal niveau voordoen, moeten automatisch worden verzacht door transparante failover van de client naar een andere Azure Cosmos DB-regio. Het testen van op DNS gebaseerde foutinjectie die eerder is beschreven, is een zinvollere test voor Azure Cosmos DB.
  Containerregister (ACR)	Wanneer de toegang tot ACR wordt geblokkeerd, blijft het maken van nieuwe pods die eerder op een AKS-knooppunt zijn opgehaald en in de cache zijn opgeslagen, verder werken. Het maken werkt nog steeds vanwege de k8s-implementatievlagpullPolicy=IfNotPresent. Knooppunten die een installatiekopie niet hebben opgehaald en in de cache hebben opgeslagen voordat het blok geen nieuwe pod kan maken en onmiddellijk mislukt met ErrImagePull fouten. kubectl describe pod geeft het bijbehorende 403 Forbidden bericht weer.
  AKS-toegangsbeheerobject load balancer	De wijziging van de regels voor inkomend verkeer voor HTTP(S)(poorten 80 en 443) in de door AKS beheerde netwerkbeveiligingsgroep (NSG) om het gebruikers- of statustestverkeer te weigeren , kan het cluster niet bereiken. De test van deze fout is moeilijk om de hoofdoorzaak vast te stellen, die is gesimuleerd als blokkering tussen het netwerkpad van Front Door en een regionale stempel. Front Door detecteert deze fout onmiddellijk en haalt de zegel uit de draaiing.