Delen via

Aanbevelingen voor het gebruik van infrastructuur als code

  • Artikel

Is van toepassing op deze controlelijst voor Azure Well-Architected Framework Operational Excellence:

OE:05 Bereid resources en hun configuraties voor met behulp van een gestandaardiseerde IaC-benadering (Infrastructure as Code). Net als bij andere code ontwerpt u IaC met consistente stijlen, passende modularisatie en kwaliteitscontrole. Geef indien mogelijk de voorkeur aan een declaratieve benadering.

In deze handleiding worden de aanbevelingen voor het gebruik van IaC beschreven als de standaard voor uw infrastructuurimplementaties. Met IaC kunt u uw infrastructuurimplementaties en -beheer integreren in uw bestaande procedures voor softwareontwikkeling. Het biedt een consistente, standaardmethodologie voor ontwikkeling en implementatie voor alle onderdelen van uw workload. Als u vertrouwt op handmatige implementaties, loopt uw workload het risico op inconsistente configuraties en mogelijk onveilig ontwerp.

Definities

Termijn Definitie
Declaratieve hulpprogramma's Een categorie hulpprogramma's die de eindstatus van een implementatie definiëren en afhankelijk zijn van het systeem om te bepalen hoe de resources moeten worden geïmplementeerd die overeenkomen met de gedefinieerde eindstatus.
Onveranderbare infrastructuur Een infrastructuur die is bedoeld om te worden vervangen door een nieuwe infrastructuur die de nieuwe configuratie uitvoert bij elke implementatie. Het mag niet worden gewijzigd.
Imperatieve hulpprogramma's Een categorie hulpprogramma's waarin de uitvoeringsstappen worden vermeld die resulteren in de gewenste eindstatus.
Module Een abstractieeenheid voor het verdelen van groepen resources om complexe implementaties te vereenvoudigen.
Onveranderbare infrastructuur Een infrastructuur die moet worden gewijzigd. Implementaties wijzigen de configuratie van de infrastructuur in plaats van deze te vervangen door een nieuwe infrastructuur.

Belangrijke ontwerpstrategieën

Zoals besproken in de toeleveringsketen en het standaardiseren van hulpprogramma's en processenhandleidingen , moet u een strikt beleid hebben voor het implementeren van infrastructuurwijzigingen (inclusief configuratiewijzigingen) alleen via code. U moet IaC implementeren via uw CI/CD-pijplijnen (continue integratie en continue levering). Door deze beleidsregels te gebruiken, wordt consistentie in processen afgedwongen voor alle IaC-implementaties, wordt het risico op configuratiedrift in uw omgevingen geminimaliseerd en wordt de consistentie van de infrastructuur in uw omgevingen gegarandeerd. Daarnaast moet u uw IaC-ontwikkel- en implementatiehulpprogramma's en -processen standaardiseren in een stijlhandleiding. Aanbevelingen voor uw stijlgids zijn:

De voorkeur geven aan declaratieve over imperatieve hulpprogramma's

Declaratieve hulpprogramma's en de bijbehorende bestanden zijn een betere algemene keuze voor het implementeren en beheren van IaC dan imperatieve hulpprogramma's. Declaratieve hulpprogramma's gebruiken een eenvoudigere syntaxis voor hun definitiebestanden, waarbij alleen de gewenste status van de omgeving wordt gedefinieerd nadat de implementatie is voltooid. Imperatieve hulpprogramma's zijn afhankelijk van het definiëren van de stappen die nodig zijn om de gewenste eindstatus te bereiken, zodat de bestanden veel complexer kunnen zijn dan declaratieve bestanden. Declaratieve definitiebestanden helpen ook bij het verminderen van de technische schuld van het onderhouden van imperatieve code, zoals implementatiescripts, die na verloop van tijd kunnen worden opgebouwd.

Systeemeigen en industriestandaard hulpprogramma's gebruiken

Gebruik de systeemeigen hulpprogramma's van uw cloudplatform en andere bewezen hulpprogramma's die systeemeigen zijn geïntegreerd in het platform. Uw cloudplatform biedt hulpprogramma's waarmee u IaC eenvoudig en eenvoudig kunt implementeren. Profiteer van deze hulpprogramma's en andere hulpprogramma's van derden die systeemeigen integratie hebben, zoals Terraform, in plaats van uw eigen oplossingen te ontwikkelen. Systeemeigen hulpprogramma's worden ondersteund door het platform en bevatten ingebouwde functionaliteit voor de meeste van uw behoeften. Ze worden continu bijgewerkt door de platformprovider, waardoor ze nuttiger worden naarmate het platform zich ontwikkelt.

Notitie

Houd er rekening mee dat als cloudproviders en externe ontwikkelaars hun hulpprogramma's en API's bijwerken, u het risico kunt lopen op onverwachte problemen bij het gebruik van de nieuwste versie in uw workload. Zorg ervoor dat u nieuwe versies van hulpprogramma's en API's grondig test voordat u ze gaat gebruiken. Vermijd ook het gebruik van de vlag 'nieuwste' bij het aanroepen van een hulpprogramma of API in uw implementatiecode. Wees bewust van het aanroepen van de meest recente bekende goede versie voor uw workload.

Het juiste hulpprogramma voor de taak gebruiken

Gebruik de juiste hulpprogramma's voor specifieke taken en infrastructuurtypen. Meerdere taken, buiten implementaties, zijn betrokken bij een levenscyclus van de infrastructuur. Configuratie moet bijvoorbeeld worden toegepast en onderhouden, en het hulpprogramma dat u gebruikt voor scriptimplementaties, zoals Bicep, is mogelijk niet het beste hulpprogramma voor elke beheerbewerking.

Op dezelfde manier kan het toepassen van de gewenste statusconfiguratie (DSC) voor verschillende infrastructuurtypen verschillende hulpprogramma's vereisen. Er zijn bijvoorbeeld specifieke hulpprogramma's zoals Ansible voor het beheren van DSC voor VM's, terwijl Flux een goed hulpmiddel is voor het beheren van DSC op Kubernetes-clusters. PaaS-services (Platform as a Service) bieden mogelijk verschillende hulpprogramma's voor configuratiebeheer (zoals Azure-app Configuratie) die kunnen worden verwerkt via IaC. SaaS-services (Software as a Service) zijn mogelijk beperkter omdat ze nauwer worden beheerd door het platform.

Denk na over alle taken en typen infrastructuur die binnen het bereik van uw IaC-procedures vallen en standaardiseren op hulpprogramma's die de taken uitvoeren die u nodig hebt en kunnen worden geïntegreerd in uw ontwikkel- en beheerprocedures.

Ondersteuning voor meerdere omgevingen

Uw scripts en sjablonen moeten flexibel genoeg zijn om eenvoudig verschillende omgevingen te implementeren. Gebruik parameters, variabelen en configuratiebestanden om een standaardset resources te implementeren die kunnen worden gewijzigd om elke omgeving in uw codepromotiestack te implementeren. Abstracte instellingen, zoals resourcegrootte, aantal, naam, locaties om in te implementeren en enkele configuratie-instellingen. Wees voorzichtig om niet te veel te abstraheren, maar. Er zijn instellingen die kunnen worden geabstraheerd met een parameter of variabele die mogelijk niet daadwerkelijk worden gewijzigd tijdens de levenscyclus van de workload, of die zelden kunnen worden gewijzigd. Ze mogen niet worden geabstraheerd.

Notitie

Vermijd het gebruik van verschillende IaC-assets voor verschillende omgevingen. U moet bijvoorbeeld geen andere Terraform-bestanden hebben voor productie- en testomgevingen. Alle omgevingen moeten één bestand gebruiken. U kunt dat bestand naar behoefte bewerken om in verschillende omgevingen te implementeren.

Gebruik de juiste balans bij het inkapselen van functionaliteit

Strategiseren en standaardiseren over het gebruik van modules. Net als parameters en variabelen kunnen modules uw infrastructuurimplementaties herhalen. Wees echter attent over hoe u ze gebruikt. Een gestandaardiseerde abstractiestrategie helpt ervoor te zorgen dat modules worden gebouwd om te voldoen aan specifieke, overeengekomen doelstellingen. Gebruik modules om complexe configuraties of combinaties van resources in te kapselen. Vermijd modules als u alleen de standaardconfiguratie van de resource gebruikt. Bovendien moet u goed zijn bij het ontwikkelen van nieuwe modules. Gebruik onderhouden opensource-modules, indien van toepassing, in bijvoorbeeld niet-gevoelige scenario's.

Handmatige stappen voor documenten

Documentstandaarden voor handmatige stappen. Er kunnen stappen zijn met betrekking tot het implementeren en onderhouden van infrastructuur die specifiek zijn voor uw omgeving en waarvoor handmatige interventie is vereist. Zorg ervoor dat deze stappen zoveel mogelijk worden geminimaliseerd en duidelijk gedocumenteerd. In uw stijlgids en standaardbedrijfsprocedures kunt u handmatige stappen standaardiseren om ervoor te zorgen dat taken veilig en consistent worden uitgevoerd.

Documenteer standaarden voor het verwerken van zwevende resources. Afhankelijk van de hulpprogramma's die u gebruikt voor configuratiebeheer en hun beperkingen, kan het voorkomen dat een bepaalde resource niet meer nodig is voor uw workload en uw IaC-hulpprogramma's de resource niet automatisch kunnen verwijderen. Stel dat u voor een bepaalde functie overstapt van VM's naar een PaaS-service en dat de IaC-hulpprogramma's geen logica hebben om de buiten gebruik gestelde resources te verwijderen. Deze resources kunnen zwevend worden als het workloadteam deze niet meer handmatig verwijdert. Als u deze scenario's wilt afhandelen, standaardiseert u een strategie om te scannen op zwevende resources en deze te verwijderen. U moet ook overwegen hoe u ervoor moet zorgen dat uw sjablonen up-to-date zijn. Onderzoek de beperkingen van uw IaC-hulpprogramma's om inzicht te hebben in wat u mogelijk moet plannen in deze situaties.

Houd rekening met de volgende aanbevelingen die van toepassing zijn op het gebruik van IaC voor uw workload.

Een gelaagde benadering gebruiken voor IaC-pijplijnen

Gebruik een gelaagde benadering om uw IaC-pijplijnen in de workloadstack uit te lijnen. Door uw IaC-pijplijnen te scheiden in lagen, kunt u complexe omgevingen beheren. Het implementeren van tientallen of honderden resources als een monolithisch pakket is inefficiënt en kan meerdere problemen veroorzaken, zoals verbroken afhankelijkheden. Het gebruik van meerdere pijplijnen die zijn afgestemd op lagen die bestaan uit resources waarvan de levenscyclus van de implementatie of factoren zoals functionaliteit nauw overeenkomen, maakt het beheren van IaC-implementaties eenvoudiger.

Kerninfrastructuur zoals netwerkresources heeft zelden wijzigingen nodig die complexer zijn dan configuratie-updates, dus deze resources moeten een IaC-pijplijn met weinig aanraakscherm vormen. Mogelijk hebt u een of meer middelgrote en high-touch IaC-pijplijnen voor resources, afhankelijk van de complexiteit van uw workload. Met behulp van een op Kubernetes gebaseerde toepassingsstack als voorbeeld kan een middelmatige touch-laag bestaan uit de clusters, opslagbronnen en databaseservices. High-touch lagen zouden bestaan uit de toepassingscontainers die zeer vaak worden bijgewerkt in een continue leveringsmodus.

IaC en toepassingscode hetzelfde behandelen

Als u uw IaC-artefacten op dezelfde wijze behandelt als uw toepassingscodeartefacten, kunt u dezelfde rigor toepassen voor het beheren van code in alle pijplijnen. Bovendien moeten de ontwikkel- en implementatieprocedures van IaC de toepassingsprocedures spiegelen. Standaarden voor versiebeheer, vertakking, codepromotie en kwaliteit moeten allemaal identiek zijn. Overweeg ook om uw IaC-assets samen met uw toepassingscodeassets samen te voegen. Als u dit doet, zorgt u ervoor dat dezelfde processen worden gevolgd bij elke implementatie en kunt u problemen voorkomen, zoals onbedoelde implementatie van infrastructuur vóór de benodigde toepassingscode, of omgekeerd.

Gecentraliseerde standaarden en resources gebruiken

Werk samen met andere teams in uw organisatie voor standaardisatie en herbruikbaarheid. Grote organisaties kunnen soms meerdere teams hebben die workloads ontwikkelen en ondersteunen. Samenwerking tussen teams om akkoord te gaan met standaarden helpt u bibliotheken, sjablonen en modules opnieuw te gebruiken om efficiëntie en consistentie in workloadomgevingen te verkrijgen. Op dezelfde manier moeten IaC-hulpprogramma's in de hele organisatie worden gestandaardiseerd voor zover dit praktisch is.

Beveiliging afdwingen in IaC-code

Pas het principe 'beveiliging als code' toe om ervoor te zorgen dat beveiliging deel uitmaakt van de implementatiepijplijn. Neem het scannen en configureren van beveiligingsproblemen op als onderdeel van het IaC-ontwikkelingsproces. Scan uw IaC-opslagplaatsen op sleutels en geheimen die beschikbaar zijn. Een voordeel van het gebruik van IaC is dat beveiligingsgerichte teamleden code kunnen controleren vóór de implementatie om ervoor te zorgen dat de configuratie die is goedgekeurd voor release door beveiliging, daadwerkelijk is wat er in productie is geïmplementeerd. Zie Aanbevelingen voor het beveiligen van een ontwikkelingslevenscyclus voor gedetailleerde richtlijnen.

Test routine en niet-routine activiteiten. Test implementaties, configuratie-updates en herstelprocessen, inclusief implementatie-terugdraaiprocessen.

Een onveranderbaar implementatiemodel aannemen

De keuze tussen het implementeren van een onveranderbare versus onveranderbare infrastructuur is afhankelijk van een paar factoren. Als uw workload bedrijfskritiek is, kunt u het beste onveranderbare infrastructuur gebruiken. En als u een volwassen infrastructuurontwerp hebt dat is gebaseerd op implementatiestempels, kan het zinvol zijn om onveranderbare infrastructuur te gebruiken, omdat u toepassingscode en nieuwe infrastructuur betrouwbaar kunt implementeren. Omgekeerd kan het gebruik van onveranderbare infrastructuur een betere keuze zijn als uw veilige implementatieprocedures dicteren dat implementaties worden geïmplementeerd wanneer er zich problemen voordoen met implementaties de voorkeursoptie is. In dit geval zou u de infrastructuur waarschijnlijk bijwerken.

Overwegingen

Meer specialisatie: in sommige gevallen wordt het introduceren van nieuwe talen in uw workloadteam geleverd met een leercurve en kan de vergrendeling van de leverancier een slechte keuze maken. Het trainen van uw teamleden en het analyseren van het juiste hulpprogramma op basis van de ondersteuning voor hulpprogramma's van uw cloudproviders is vereist.

Verhoogde onderhoudswerkzaamheden: onderhoud van codebasis en hulpprogramma's is vereist om uw IaC-implementatie actueel en veilig te houden. Houd uw technische schuld goed bij en bevordert een cultuur waarin de schuldvermindering wordt beloond.

Meer tijd voor configuratiewijzigingen: het implementeren van de infrastructuur met behulp van opdrachtregelinstructies of rechtstreeks vanuit een portal vereist geen coderingstijd en/of testartefacten. Minimaliseer de implementatietijd door aanbevolen procedures te volgen, zoals codebeoordelingen en procedures voor kwaliteitscontrole.

Verhoogde complexiteit van modularisatie: Het gebruik van meer modules en parameterisatie verhoogt de tijd die nodig is om fouten op te sporen en het systeem te documenteren en voegt een abstractielaag toe. Balanceer het gebruik van modularisatie om complexiteit te verminderen en over-engineering te voorkomen.

Azure-facilitering

Azure Resource Manager-sjablonen (ARM-sjablonen) en Bicep zijn systeemeigen Azure-hulpprogramma's voor het implementeren van infrastructuur met behulp van declaratieve syntaxis. ARM-sjablonen worden geschreven in JSON, terwijl Bicep een domeinspecifieke taal is. Beide kunnen eenvoudig worden geïntegreerd in Azure-pijplijnen of GitHub Actions CI/CD-pijplijnen.

Terraform is een ander declaratief IaC-hulpprogramma dat volledig wordt ondersteund in Azure. Het kan worden gebruikt voor het implementeren en beheren van infrastructuur en kan worden geïntegreerd in uw CI/CD-pijplijn.

U kunt Microsoft Defender voor Cloud gebruiken om onjuiste configuraties in IaC te detecteren.

Opmerking

Zie de architectuur van de azure Virtual Desktop-landingszoneversneller en de bijbehorende referentie-implementatie voor een voorbeeld van een Virtual Desktop-implementatie die kan worden geïmplementeerd via opgegeven Resource Manager-, Bicep- of Terraform-bestanden.

Controlelijst voor operationele uitmuntendheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor operationele uitmuntendheid