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örbereda 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 IaC kan du integrera dina infrastrukturdistributioner och hantering i dina befintliga metoder för programvaruutveckling. Den tillhandahåller en konsekvent standardmetodik för utveckling och distribution för alla komponenter i din arbetsbelastning. Om du förlitar dig på manuella distributioner riskerar arbetsbelastningen 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 så att de matchar 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 (continuous integration and continuous delivery). Om du antar dessa principer tillämpas konsekvens i processer för alla IaC-distributioner, minimerar risken för konfigurationsavvikelser 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 formatguide. Rekommendationer för stilguiden är:

Föredra deklarativa framför imperativa verktyg. Deklarativa verktyg och deras associerade filer är ett bättre övergripande alternativ 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 har slutförts. 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ä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 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.

Anteckning

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 testar nya versioner av verktyg och API:er noggrant 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 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 det verktyg 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 strikt 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.

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.

Anteckning

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.

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. Var dessutom 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.

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.

Dokumentera standarder 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 automatiskt kan ta bort resursen. Anta till exempel att du flyttar från virtuella datorer till en PaaS-tjänst för någon funktion och att IaC-verktyget inte har 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 ditt IaC-verktyg för att förstå vad du kan behöva planera för i dessa situationer.

Andra IaC-strategier

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

Använd en metod med flera lager för att justera dina IaC-pipelines i arbetsbelastningsstacken. Genom att separera 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 justerade med lager som består av resurser vars distributionslivscykler eller faktorer som funktioner nära matchar 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. Om du till exempel använder en Kubernetes-baserad programstack kan ett medium-touch-lager bestå av kluster, lagringsresurser och databastjänster. Högtryckslager skulle bestå av de programcontainrar som uppdateras mycket ofta i ett kontinuerligt leveransläge.

Behandla din 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-utveckling och distributionsmetoder spegla programpraxis. Standarder för versionskontroll, förgrening, kodhöjning och kvalitet bör alla vara identiska. Överväg också att samla dina IaC-tillgångar tillsammans med dina programkodtillgångar. På så sätt ser du till att samma processer följs vid varje distribution och hjälper dig att undvika problem som att oavsiktligt distribuera infrastruktur före nödvändig programkod eller tvärtom.

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 som det är praktiskt att göra det.

Använd 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 har godkänts för frisläppning av säkerhet faktiskt är vad som distribueras till produktion. Detaljerad vägledning finns i Rekommendationer för att skydda en utvecklingslivscykel.

Testa rutin- och icke-rutinaktiviteter. Testa distributioner, konfigurationsuppdateringar och återställningsprocesser, inklusive distributionsåterställningsprocesser.

Föränderlig kontra oföränderlig infrastruktur

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. Om du har en mogen infrastrukturdesign som baseras på distributionsstämplar kan det vara bra att använda oföränderlig infrastruktur, 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 föreskriver att det bästa alternativet är att fortsätta med distributioner när det uppstår problem med minimerad distribution. I det här fallet skulle du förmodligen uppdatera infrastrukturen på plats.

Överväganden

Ökad specialisering: I vissa fall kommer introduktionen av nya språk i arbetsbelastningsteamet med en inlärningskurva, och leverantörslåsning kan göra det till ett dåligt val. Du måste träna dina teammedlemmar och analysera rätt verktyg baserat på molnleverantörernas verktygssupport.

Ökat underhållsarbete: Kodbas och verktygsunderhåll krävs för att hålla IaC-implementeringen aktuell och säker. Korrekt spåra din tekniska skuld och främja en kultur där minska 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 för 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 hjälp av 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.

Organisatorisk anpassning

Cloud Adoption Framework ger vägledning för centrala team om hur man standardiserade infrastrukturen som kod i organisationens arbetsbelastningsteam.

Mer information finns i Infrastruktur som kod i Cloud Adoption Framework.

Exempel

Se azure virtual desktop-acceleratorns arkitektur och tillhörande referensimplementering för ett exempel på en Virtual Desktop-implementering som kan distribueras via tillhandahållna Resource Manager-, Bicep- eller Terraform-filer.

Checklista för utmärkt drift

Se den fullständiga uppsättningen rekommendationer.

Checklista för utmärkt drift