Overwegingen bij de implementatie van DevOps
Wanneer u Azure-resources, toepassingscode en configuratie-instellingen inrichten en bijwerken, kunt u met een herhaalbaar en voorspelbaar proces fouten en downtime voorkomen. We raden geautomatiseerde processen aan voor implementatie die u op aanvraag kunt uitvoeren en opnieuw kunt uitvoeren als er iets mislukt. Nadat uw implementatieprocessen probleemloos worden uitgevoerd, kunnen deze op die manier worden behouden in de procesdocumentatie.
Automation
Als u resources op aanvraag wilt activeren, oplossingen snel wilt implementeren, menselijke fouten wilt minimaliseren en consistente en herhaalbare resultaten wilt produceren, moet u implementaties en updates automatiseren.
Zoveel mogelijk processen automatiseren
De meest betrouwbare implementatieprocessen zijn geautomatiseerd en idempotent, dat — wil zeggen herhaalbaar om dezelfde resultaten te produceren.
- Als u het inrichten van Azure-resources wilt automatiseren, kunt u Terraform, Ansible, Chef, Puppet, Azure PowerShell, Azure CLIof Azure Resource Manager gebruiken.
- Als u VM's wilt configureren, kunt u cloud-init (voor Linux-VM's) of Azure Automation State Configuration (DSC) gebruiken.
- Als u de implementatie van toepassingen wilt automatiseren, kunt u Azure DevOps Services, Jenkinsof andere CI/CD-oplossingen gebruiken.
Maak als best practice opslagplaats met gecategoriseerde automatiseringsscripts voor snelle toegang, gedocumenteerd met uitleg over parameters en voorbeelden van scriptgebruik. Houd deze documentatie synchroon met uw Azure-implementaties en wijs een primaire persoon aan om de opslagplaats te beheren.
Automatiseringsscripts kunnen ook resources op aanvraag activeren voor herstel na noodherstel.
Implementatie- en onderhoudstaken automatiseren en testen
Gedistribueerde toepassingen bestaan uit meerdere onderdelen die moeten samenwerken. Implementatie moet profiteren van bewezen mechanismen, zoals scripts, die de configuratie kunnen bijwerken en valideren en het implementatieproces kunnen automatiseren. Test alle processen volledig om ervoor te zorgen dat fouten geen extra downtime veroorzaken.
Implementatiebeveiligingsmaatregelen implementeren
Alle implementatiehulpprogramma's moeten beveiligingsbeperkingen bevatten om de geïmplementeerde toepassing te beveiligen. Definieer en dwing implementatiebeleid zorgvuldig af en minimaliseer de noodzaak van menselijke tussenkomst.
Releaseproces
Een van de uitdagingen bij het automatiseren van de implementatie is de cut-over zelf, waarbij software van de laatste testfase naar de live-productiefase wordt overgenomen. Meestal moet u dit snel doen om downtime te minimaliseren. De blauw-groene implementatiebenadering doet dit door ervoor te zorgen dat u twee productieomgevingen hebt, die zo identiek mogelijk zijn.
Releaseproces voor documenten
Zonder gedetailleerde documentatie over het releaseproces kan een operator een slechte update implementeren of de instellingen voor uw toepassing onjuist configureren. Definieer en documenteer uw releaseproces duidelijk en zorg ervoor dat het beschikbaar is voor uw gehele team.
Uw workloads faseer
Implementatie in verschillende fasen en het uitvoeren van tests/validaties in elke fase voordat u verder gaat met de volgende, zorgt voor een frictievrije productie-implementatie.
Met een goed gebruik van faserings- en productieomgevingen kunt u updates naar de productieomgeving pushen op een zeer gecontroleerde manier en onderbrekingen van onverwachte implementatieproblemen minimaliseren.
- Blauw-groene implementatie omvat het implementeren van een update in een productieomgeving die is gescheiden van de live-toepassing. Nadat u de implementatie hebt gevalideerd, schakelt u de verkeersroutering om naar de bijgewerkte versie. Een manier om dit te doen, is door de staging-slots te gebruiken die beschikbaar zijn in Azure App Service implementatie te faseren voordat u deze naar productie verplaatst.
- Canary-releases zijn vergelijkbaar met blauw-groene implementaties. In plaats van al het verkeer over te schakelen naar de bijgewerkte toepassing, routeert u slechts een klein deel van het verkeer naar de nieuwe implementatie. Als er een probleem is, keert u terug naar de oude implementatie. Zo niet, dan routeer dan geleidelijk meer verkeer naar de nieuwe versie. Als u een canary-Azure App Service, kunt u de functie Testen in productie gebruiken om een Canary-release te beheren.
Testomgevingen
Als ontwikkel- en testomgevingen niet overeenkomen met de productieomgeving, is het moeilijk om problemen te testen en te diagnosticeren. Houd ontwikkel- en testomgevingen daarom zo dicht mogelijk bij de productieomgeving. Zorg ervoor dat testgegevens consistent zijn met de gegevens die in productie worden gebruikt, zelfs als het om voorbeeldgegevens gaat en niet om echte productiegegevens (om privacy- of nalevingsredenen). Plan het genereren en anoniem maken van voorbeeldtestgegevens.
Logboekregistratie en bewaking
Als u zoveel mogelijk versiespecifieke informatie wilt vastleggen, implementeert u een robuuste strategie voor logboekregistratie. Als u gefaseerd implementatietechnieken gebruikt, wordt er meer dan één versie van uw toepassing in productie uitgevoerd. Als er een probleem optreedt, bepaalt u welke versie de oorzaak is.
Overwegingen voor hoge beschikbaarheid
Een toepassing die afhankelijk is van één exemplaar van een service, maakt een Single Point of Failure. Als u de tolerantie en schaalbaarheid wilt verbeteren, moet u meerdere exemplaren inrichten.
- Selecteer Azure App Serviceeen abonnement App Service meerdere exemplaren biedt.
- Voor Azure Cloud Servicesconfigureert u elk van uw rollen voor het gebruik van meerdere exemplaren.
- Voor Azure Virtual Machineszorgt u ervoor dat uw architectuur meer dan één VM bevat en dat elke VM is opgenomen in een beschikbaarheidsset.
Overweeg implementatie in meerdere regio's
We raden u aan alle toepassingen en toepassingsservices, behalve de minst kritieke, in meerdere regio's te implementeren. Als uw toepassing is geïmplementeerd in één regio, is de toepassing in het zeldzame geval dat de hele regio niet meer beschikbaar is, ook niet beschikbaar. Als u ervoor kiest om te implementeren in één regio, kunt u overwegen om u voor te bereiden op het opnieuw implementeren naar een secundaire regio als reactie op een onverwachte fout.
Opnieuw in een secundaire regio
Als u toepassingen en databases in één primaire regio zonder replicatie hebt uitgevoerd, is het mogelijk dat uw herstelstrategie opnieuw moet worden uitgevoerd in een andere regio. Deze oplossing is betaalbaar, maar het meest geschikt voor niet-kritieke toepassingen die langere hersteltijden kunnen tolereren. Als u voor deze strategie kiest, automatiseert u het herdeploymentproces zo veel mogelijk en nemen we scenario's voor opnieuw ontwikkelen op in uw noodresponstests.
Als u uw herploymentproces wilt automatiseren, kunt u overwegenom Azure Site Recovery .