Dela via

Rekommendationer för att använda infrastruktur som kod

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Operational Excellence:

OE:05 Förbered resurser och deras konfigurationer med hjälp av en standardiserad IaC-metod (infrastruktur som kod). Precis som med annan kod utformar du IaC med konsekventa format, lämplig modularisering och kvalitetssäkring. Föredrar en deklarativ metod när det är möjligt.

Den här guiden beskriver rekommendationerna för att använda IaC som standard för dina infrastrukturdistributioner. Med hjälp av IaC kan du integrera dina infrastrukturdistributioner och hantering i dina befintliga metoder för programvaruutveckling. Det ger en konsekvent standardmetod för utveckling och distribution för alla komponenter i din arbetsbelastning. Om du förlitar dig på manuella distributioner riskerar din arbetsbelastning inkonsekventa konfigurationer och potentiellt osäker design.

Definitioner

Period Definition
Deklarativa verktyg En kategori med verktyg som definierar sluttillståndet för en distribution och förlitar sig på systemet för att avgöra hur resurserna ska distribueras för att matcha det definierade sluttillståndet.
Oföränderlig infrastruktur En infrastruktur som är avsedd att ersättas med ny infrastruktur som kör den nya konfigurationen med varje distribution. Det får inte ändras på plats.
Imperativa verktyg En kategori med verktyg som visar de körningssteg som resulterar i önskat sluttillstånd.
Modul En abstraktionsenhet för att dela upp grupper av resurser för att förenkla komplexa distributioner.
Föränderlig infrastruktur En infrastruktur som är avsedd att ändras på plats. Distributioner ändrar konfigurationen av infrastrukturen i stället för att ersätta den med ny infrastruktur.

Viktiga designstrategier

Som beskrivs i leveranskedjan och standardiseringsverktyg och processguider bör du ha en strikt princip för att distribuera infrastrukturändringar (inklusive konfigurationsändringar) endast via kod. Du bör distribuera IaC via dina CI/CD-pipelines (kontinuerlig integrering och kontinuerlig leverans). Om du antar dessa principer tillämpas konsekvens i processer för alla IaC-distributioner, minimerar risken för konfigurationsavdrift i dina miljöer och säkerställer konsekvens i infrastrukturen i dina miljöer. Dessutom bör du standardisera dina IaC-utvecklings- och distributionsverktyg och -processer i en stilguide. Rekommendationer för formatguiden är:

Föredrar deklarativ framför imperativa verktyg

Deklarativa verktyg och deras associerade filer är ett bättre övergripande val för att distribuera och hantera IaC än imperativa verktyg. Deklarativa verktyg använder en enklare syntax för sina definitionsfiler och definierar endast det önskade tillståndet för miljön när distributionen är klar. Imperativa verktyg är beroende av att du definierar de steg som krävs för att komma till önskat sluttillstånd, så filerna kan vara mycket mer komplexa än deklarativa filer. Deklarativa definitionsfiler bidrar också till att minska den tekniska skulden för att upprätthålla imperativ kod, till exempel distributionsskript, som kan ackumuleras över tid.

Använda interna verktyg och branschstandardverktyg

Använd din molnplattforms interna verktyg och andra branschbeprövade verktyg som integreras internt i plattformen. Din molnplattform innehåller verktyg som gör det enkelt och enkelt att distribuera IaC. Dra nytta av dessa verktyg och andra verktyg från tredje part som har inbyggd integrering, till exempel Terraform, i stället för att utveckla dina egna lösningar. Inbyggda verktyg stöds av plattformen och innehåller inbyggda funktioner för de flesta av dina behov. De uppdateras kontinuerligt av plattformsleverantören, vilket gör dem mer användbara när plattformen utvecklas.

Kommentar

Tänk på att när molnleverantörer och tredjepartsutvecklare uppdaterar sina verktyg och API:er kan du riskera oväntade problem när du använder den senaste versionen i din arbetsbelastning. Kontrollera att du noggrant testar nya versioner av verktyg och API:er innan du börjar använda dem. På samma sätt bör du undvika att använda flaggan "senaste" när du anropar ett verktyg eller API i distributionskoden. Var medveten om att anropa den senaste kända bra versionen för din arbetsbelastning.

Använd rätt verktyg för uppgiften

Använd rätt verktyg för specifika uppgifter och infrastrukturtyper. Flera uppgifter utöver distributioner ingår i en infrastrukturlivscykel. Konfigurationen måste till exempel tillämpas och underhållas, och verktyget som du använder för skriptdistributioner, till exempel Bicep, kanske inte är det bästa verktyget för varje hanteringsåtgärd.

På samma sätt kan det krävas olika verktyg för att tillämpa önskad tillståndskonfiguration (DSC) för olika infrastrukturtyper. Det finns till exempel specifika verktyg som Ansible för att hantera DSC för virtuella datorer, medan Flux är ett bra verktyg för att hantera DSC i Kubernetes-kluster. PaaS-tjänster (Plattform som en tjänst) kan tillhandahålla olika verktyg för konfigurationshantering (till exempel Azure App Configuration) som kan hanteras via IaC. SaaS-tjänster (Programvara som en tjänst) kan vara mer begränsade eftersom de kontrolleras mer noggrant av plattformen.

Tänk på alla uppgifter och typer av infrastruktur som finns i omfånget för dina IaC-metoder och standardisera på verktyg som utför de jobb som du behöver dem att göra och kan integreras i dina utvecklings- och hanteringsmetoder.

Stöd för flera miljöer

Dina skript och mallar bör vara tillräckligt flexibla för att enkelt distribuera en mängd olika miljöer. Använd parametrar, variabler och konfigurationsfiler för att distribuera en standarduppsättning resurser som kan ändras för att distribuera valfri miljö i kodhöjningsstacken. Abstrakta inställningar som resursstorlek, antal, namn, platser att distribuera till och vissa konfigurationsinställningar. Var dock noga med att inte abstrahera för mycket. Det finns inställningar som kan abstraheras med en parameter eller variabel som kanske inte ändras under arbetsbelastningens livscykel, eller som kan ändras sällan. De borde inte abstraheras.

Kommentar

Undvik att använda olika IaC-tillgångar för olika miljöer. Du bör till exempel inte ha olika Terraform-filer för produktions- och testmiljöer. Alla miljöer bör använda en fil. Du kan ändra filen så att den distribueras till olika miljöer efter behov.

Använd rätt balans vid inkapsling av funktioner

Strategiisera och standardisera användningen av moduler. Precis som parametrar och variabler kan moduler göra dina infrastrukturdistributioner repeterbara. Tänk dock på hur du använder dem. En standardiserad abstraktionsstrategi hjälper till att säkerställa att moduler skapas för att uppfylla specifika, överenskomna mål. Använd moduler för att kapsla in komplexa konfigurationer eller kombinationer av resurser. Undvik moduler om du bara använder standardkonfigurationen för resursen. Dessutom bör du vara klok när du utvecklar nya moduler. Använd underhållsmoduler med öppen källkod när det är lämpligt, till exempel i meningslösa scenarier.

Manuella dokumentsteg

Dokumentera standarder för manuella steg. Det kan finnas steg som rör distribution och underhåll av infrastruktur som är specifika för din miljö och som kräver manuella åtgärder. Se till att de här stegen minimeras så mycket som möjligt och dokumenteras tydligt. I stilguiden och standardrutinerna standardiserar du manuella steg för att säkerställa att uppgifter utförs på ett säkert och konsekvent sätt.

Dokumentstandarder för att hantera överblivna resurser. Beroende på vilka verktyg du använder för konfigurationshantering och deras begränsningar kan det finnas tillfällen då en viss resurs inte längre behövs av din arbetsbelastning och dina IaC-verktyg inte kan ta bort resursen automatiskt. Anta till exempel att du flyttar från virtuella datorer till en PaaS-tjänst för någon funktion och att IaC-verktygen inte har någon logik för att ta bort de tillbakadragna resurserna. Dessa resurser kan bli överblivna om arbetsbelastningsteamet inte kommer ihåg att ta bort dem manuellt. Om du vill hantera dessa scenarier standardiserar du en strategi för att söka efter överblivna resurser och ta bort dem. Du måste också överväga hur du ska se till att dina mallar är uppdaterade. Utforska begränsningarna i IaC-verktygen för att förstå vad du kan behöva planera för i dessa situationer.

Överväg följande rekommendationer som gäller för användning av IaC för din arbetsbelastning.

Använda en metod i flera lager för IaC-pipelines

Använd en metod i flera lager för att justera dina IaC-pipelines i arbetsbelastningsstacken. Genom att dela upp dina IaC-pipelines i lager kan du hantera komplexa miljöer. Att distribuera dussintals eller hundratals resurser som ett monolitiskt paket är ineffektivt och kan leda till flera problem, till exempel brutna beroenden. Användningen av flera pipelines som är anpassade till lager som består av resurser vars distributionslivscykler eller faktorer som funktioner matchar varandra gör det enklare att hantera IaC-distributioner.

Kärninfrastruktur som nätverksresurser behöver sällan ändringar som är mer komplexa än konfigurationsuppdateringar, så dessa resurser bör utgöra en IaC-pipeline med låg touch . Du kan ha en eller flera IaC-pipelines med medelhög touch och hög touch för resurser, beroende på komplexiteten i din arbetsbelastning. Med hjälp av en Kubernetes-baserad programstack som exempel kan ett medium-touch-lager bestå av kluster, lagringsresurser och databastjänster. Högtryckslager består av de programcontainrar som uppdateras mycket ofta i ett kontinuerligt leveransläge.

Behandla IaC och programkod på samma sätt

Genom att behandla dina IaC-artefakter på samma sätt som dina programkodartefakter kan du använda samma stränghet för att hantera kod i alla pipelines. Dessutom bör IaC:s metoder för utveckling och distribution spegla programpraxis. Standarder för versionskontroll, förgrening, kodhöjning och kvalitet bör alla vara identiska. Överväg också att sammanställa dina IaC-tillgångar tillsammans med dina programkodtillgångar. Detta hjälper dig att se till att samma processer följs med varje distribution och hjälper dig att undvika problem som att oavsiktligt distribuera infrastrukturen före nödvändig programkod, eller vice versa.

Använda centraliserade standarder och resurser

Samarbeta med andra team i din organisation för standardisering och återanvändning. Stora organisationer kan ibland ha flera team som utvecklar och stöder arbetsbelastningar. Samarbete mellan team för att komma överens om standarder hjälper dig att återanvända bibliotek, mallar och moduler för att få effektivitet och konsekvens i arbetsbelastningsmiljöer. På samma sätt bör IaC-verktyg standardiseras i hela organisationen i den utsträckning det är praktiskt att göra det.

Framtvinga säkerhet i IaC-kod

Tillämpa principen "säkerhet som kod" för att säkerställa att säkerheten är en del av distributionspipelinen. Inkludera sårbarhetsgenomsökning och konfigurationshärdning som en del av IaC-utvecklingsprocessen. Sök igenom dina IaC-lagringsplatser efter nycklar och hemligheter som exponeras. En fördel med att använda IaC är att säkerhetsfokuserade teammedlemmar kan granska kod före distributionen för att säkerställa att konfigurationen som är godkänd för lansering av säkerhet faktiskt är det som distribueras till produktion. Detaljerad vägledning finns i Rekommendationer för att skydda en utvecklingslivscykel.

Testa rutin- och icke-rutinmässiga aktiviteter. Testa distributioner, konfigurationsuppdateringar och återställningsprocesser, inklusive processer för distributionsåterställning.

Anta en oföränderlig distributionsmodell

Valet mellan att distribuera föränderlig och oföränderlig infrastruktur beror på några faktorer. Om din arbetsbelastning är affärskritisk är det bäst att använda oföränderlig infrastruktur. På samma sätt kan det vara meningsfullt att använda oföränderlig infrastruktur om du har en mogen infrastrukturdesign som baseras på distributionsstämplar, eftersom du kan distribuera programkod och ny infrastruktur på ett tillförlitligt sätt. Omvänt kan det vara ett bättre val att använda föränderlig infrastruktur om dina säkra distributionsmetoder kräver att det bästa alternativet är att rulla vidare med distributioner när det uppstår problem med mildrande distribution. I det här fallet skulle du förmodligen uppdatera infrastrukturen på plats.

Att tänka på

Ökad specialisering: I vissa fall kommer introduktionen av nya språk i ditt arbetsbelastningsteam med en inlärningskurva, och leverantörslåsning kan göra det till ett dåligt val. Det krävs utbildning av dina teammedlemmar och analys av rätt verktyg baserat på molnleverantörernas verktygsstöd.

Ökad underhållsinsats: Kodbas och verktygsunderhåll krävs för att hålla din IaC-implementering aktuell och säker. Spåra din tekniska skuld korrekt och främja en kultur där en minskning av skulden belönas.

Ökad tid för konfigurationsändringar: Distribution av infrastruktur med hjälp av kommandoradsinstruktioner eller direkt från en portal kräver ingen kodningstid och/eller testning av artefakter. Minimera distributionstiden genom att följa rekommenderade metoder som kodgranskningar och kvalitetssäkringsmetoder.

Ökad komplexitet i modularisering: Om du använder fler moduler och parameterisering ökar tiden det tar att felsöka och dokumentera systemet och lägger till ett abstraktionslager. Balansera användningen av modularisering för att minska komplexiteten och undvika överteknik.

Azure-underlättande

Azure Resource Manager-mallar (ARM-mallar) och Bicep är Azure-inbyggda verktyg för att distribuera infrastruktur med deklarativ syntax. ARM-mallar skrivs i JSON, medan Bicep är ett domänspecifikt språk. Båda kan enkelt integreras i Azure-pipelines eller GitHub Actions CI/CD-pipelines.

Terraform är ett annat deklarativt IaC-verktyg som stöds fullt ut i Azure. Den kan användas för att distribuera och hantera infrastruktur och kan integreras i DIN CI/CD-pipeline.

Du kan använda Microsoft Defender för molnet för att identifiera felkonfigurationer i IaC.

Exempel

Se acceleratorarkitekturen för Azure Virtual Desktop-landningszonen och den associerade referensimplementeringen för ett exempel på en Virtual Desktop-implementering som kan distribueras via tillhandahållna Resource Manager-, Bicep- eller Terraform-filer.

Checklista för driftskvalitet

Se den fullständiga uppsättningen rekommendationer.

Checklista för driftskvalitet