Aanbevelingen voor het gebruik van infrastructuur als code

  • Artikel

Van toepassing op deze aanbeveling voor de controlelijst voor operationele uitmuntendheid van Azure Well-Architected Framework:

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

In deze handleiding worden de aanbevelingen beschreven voor het gebruik van IaC als standaard voor uw infrastructuurimplementaties. Met behulp van 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 zodat deze overeenkomen met de gedefinieerde eindstatus.
Onveranderbare infrastructuur Een infrastructuur die is bedoeld om te worden vervangen door een nieuwe infrastructuur die de nieuwe configuratie bij elke implementatie uitvoert. Het mag niet ter plaatse worden gewijzigd.
Imperatieve hulpprogramma's Een categorie hulpprogramma's waarin de uitvoeringsstappen worden vermeld die resulteren in de gewenste eindstatus.
Module Een abstractie-eenheid voor het verdelen van groepen resources om complexe implementaties te vereenvoudigen.
Veranderlijke 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 handleidingen voor de toeleveringsketen en het standaardiseren van hulpprogramma's en processen , moet u een strikt beleid hebben om alleen wijzigingen in de infrastructuur (inclusief configuratiewijzigingen) te implementeren via code. U moet IaC implementeren via uw CI/CD-pijplijnen (continue integratie en continue levering). Als u dit beleid toepast, dwingt u consistentie af in processen voor alle IaC-implementaties, minimaliseert u het risico van configuratiedrift in uw omgevingen en zorgt u voor infrastructuurconsistentie in uw omgevingen. Daarnaast moet u uw IaC-ontwikkel- en implementatiehulpprogramma's en -processen standaardiseren in een stijlhandleiding. Aanbevelingen voor uw stijlgids zijn onder andere:

Geef de voorkeur aan declaratieve boven 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 schulden van het onderhouden van imperatieve code, zoals implementatiescripts, die in de loop van de tijd kunnen toenemen.

Gebruik de systeemeigen hulpprogramma's van uw cloudplatform en andere bewezen hulpprogramma's die systeemeigen in het platform zijn geïntegreerd. Uw cloudplatform biedt hulpprogramma's om de implementatie van IaC eenvoudig en eenvoudig te maken. 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 voortdurend bijgewerkt door de platformprovider, waardoor ze nuttiger worden naarmate het platform zich ontwikkelt.

Notitie

Houd er rekening mee dat wanneer cloudproviders en externe ontwikkelaars hun hulpprogramma's en API's bijwerken, u het risico loopt op onverwachte problemen wanneer u de nieuwste versie in uw workload gebruikt. Zorg ervoor dat u nieuwe versies van hulpprogramma's en API's grondig test voordat u deze in gebruik neemt. Vermijd ook het gebruik van de vlag 'nieuwste' bij het aanroepen van een hulpprogramma of API in uw implementatiecode. Wees voorzichtig met het aanroepen van de meest recente bekende goede versie voor uw workload.

Gebruik de juiste hulpprogramma's voor specifieke taken en infrastructuurtypen. Meerdere taken, naast implementaties, zijn betrokken bij de levenscyclus van een infrastructuur. De 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 voor het toepassen van DSC (Desired State Configuration) voor verschillende infrastructuurtypen verschillende hulpprogramma's nodig zijn. Er zijn bijvoorbeeld specifieke hulpprogramma's zoals Ansible voor het beheren van DSC voor VM's, terwijl Flux een goed hulpprogramma 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 Configuration) 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 standaardiseer hulpprogramma's die de taken uitvoeren die u nodig hebt en die kunnen worden geïntegreerd in uw ontwikkel- en beheerprocedures.

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 kan 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. Pas echter op dat u niet te veel abstract maakt. Er zijn instellingen die kunnen worden geabstraheerd met een parameter of variabele die mogelijk niet daadwerkelijk worden gewijzigd in de loop van de levenscyclus van de workload, of die mogelijk zelden worden gewijzigd. Ze mogen niet worden geabstraheerd.

Notitie

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

Het gebruik van modules strategiseren en standaardiseren. Net als parameters en variabelen kunnen modules ervoor zorgen dat uw infrastructuurimplementaties herhaalbaar zijn. Denk echter goed na 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. Wees bovendien verstandig bij het ontwikkelen van nieuwe modules. Gebruik onderhouden opensource-modules indien van toepassing, bijvoorbeeld in niet-gevoelige scenario's.

Documenteer standaarden 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 vereist is. Zorg ervoor dat deze stappen zoveel mogelijk worden geminimaliseerd en duidelijk worden gedocumenteerd. In uw stijlgids en standaardprocedures 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, kunnen er momenten zijn waarop 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 raken als het workloadteam niet meer weet om ze handmatig te verwijderen. 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 kunt zorgen dat uw sjablonen up-to-date zijn. Onderzoek de beperkingen van uw IaC-hulpprogramma's om te begrijpen wat u in deze situaties moet plannen.

Andere IaC-strategieën

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

Gebruik een gelaagde benadering om uw IaC-pijplijnen binnen de workloadstack uit te lijnen. Door uw IaC-pijplijnen in lagen te scheiden, 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 uitgelijnd met lagen die bestaan uit resources waarvan de implementatielevenscycli of factoren zoals functionaliteit nauw overeenkomen, maakt het beheren van IaC-implementaties eenvoudiger.

Kerninfrastructuur, zoals netwerkresources, heeft zelden complexere wijzigingen nodig dan configuratie-updates , dus deze resources moeten een IaC-pijplijn met weinig touch vormen. Mogelijk hebt u een of meer IaC-pijplijnen met gemiddelde aanraking en hoge aanraakfunctionaliteit voor resources, afhankelijk van de complexiteit van uw workload. Als u bijvoorbeeld een op Kubernetes gebaseerde toepassingsstack gebruikt, kan één laag voor middelgrote aanrakingen bestaan uit de clusters, opslagresources en databaseservices. High-touch-lagen zouden bestaan uit de toepassingscontainers die zeer vaak worden bijgewerkt in een continue leveringsmodus.

Behandel uw IaC en toepassingscode op dezelfde wijze. Als u uw IaC-artefacten op dezelfde manier behandelt als uw toepassingscodeartefacten, kunt u dezelfde striktheid toepassen voor het beheren van code in alle pijplijnen. Bovendien moeten de ontwikkel- en implementatieprocedures van IaC de toepassingspraktijken weerspiegelen. Standaarden voor versiebeheer, vertakking, codepromotie en kwaliteit moeten allemaal identiek zijn. Overweeg ook om uw IaC-assets samen met uw toepassingscodeassets te combineren. Dit helpt ervoor te zorgen dat dezelfde processen worden gevolgd bij elke implementatie en helpt u problemen te voorkomen, zoals het per ongeluk implementeren van infrastructuur vóór de benodigde toepassingscode, of omgekeerd.

Werk samen met andere teams in uw organisatie voor standaardisatie en herbruikbaarheid. Grote organisaties kunnen soms meerdere teams hebben die workloads ontwikkelen en ondersteunen. Door samen te werken tussen teams om het eens te worden over standaarden, kunt u bibliotheken, sjablonen en modules hergebruiken om efficiëntie en consistentie in workloadomgevingen te verbeteren. Op dezelfde manier moeten IaC-hulpprogramma's in de hele organisatie worden gestandaardiseerd, zodat dit praktisch is.

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

Test routine- en niet-routineactiviteiten. Testimplementaties, configuratie-updates en herstelprocessen, inclusief implementatie-terugdraaiprocessen.

Veranderlijke versus onveranderbare infrastructuur

De keuze tussen het implementeren van veranderlijke en onveranderbare infrastructuur is afhankelijk van een aantal factoren. Als uw workload bedrijfskritiek is, kunt u het beste een onveranderbare infrastructuur gebruiken. Als u een volwassen infrastructuurontwerp hebt dat is gebaseerd op implementatiestempels, kan het gebruik van onveranderbare infrastructuur zinvol zijn, omdat u toepassingscode en nieuwe infrastructuur betrouwbaar kunt implementeren. Omgekeerd kan het gebruik van veranderlijke infrastructuur een betere keuze zijn als uw veilige implementatieprocedures dicteren dat doorschakelen met implementaties wanneer zich implementatieproblemen voordoen de voorkeur heeft. In dit geval werkt u waarschijnlijk de infrastructuur bij.

Overwegingen

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

Verhoogde onderhoudsinspanning: Onderhoud van de 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 het verminderen van schulden wordt beloond.

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

Verhoogde complexiteit van modularisatie: Het gebruik van meer modules en parameterisering 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 de 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 zijn 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 for Cloud gebruiken om onjuiste configuraties in IaC te detecteren.

Voorbeeld

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