Rekommendationer för att använda infrastruktur som kod
Gäller för den här rekommendationen om checklista för driftseffektivitet i Azure Well-Architected Framework:
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. Prioritera 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 programutvecklingsmetoder. Den 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 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 (kontinuerlig integrering och kontinuerlig leverans). Genom att använda 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 verktyg och processer för utveckling och distribution av IaC i en stilguide. Rekommendationer för stilguiden är:
Föredrar deklarativ 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 underhålla imperativ kod, till exempel distributionsskript, som kan ackumuleras över tid.
Använd din molnplattforms inbyggda 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. Se till att du noggrant testar nya versioner av verktyg och API:er innan du börjar använda dem. Undvik på samma sätt att använda flaggan "senaste" när du anropar på ett verktyg eller API i distributionskoden. Var avsiktlig med att anropa den senaste fungerande 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 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 på 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 är striktare kontrollerade 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 kodbefordringsstacken. 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 faktiskt ändras under arbetsbelastningens livscykel, eller som kan ändras sällan. De bör 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. Var dock omtänksam om 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ålls moduler 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 standardprocedurerna standardiserar du manuella steg för att säkerställa att aktiviteter 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 när 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 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. Gå igenom begränsningarna i dina 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 i 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 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å arbetsbelastningens komplexitet. 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 noggrannhet för att hantera kod i alla pipelines. Dessutom bör IaC:s utvecklings- och distributionsmetoder spegla programpraxis. Standarder för versionskontroll, förgrening, kodhöjning och kvalitet bör 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.
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.
Relaterade länkar
- Vad är infrastruktur som kod (IaC)?
- Företagsinfrastruktur som kod med Bicep och Azure Container Registry
- Identifiera felkonfigurationer i IaC
- Rekommendationer för att utforma en leveranskedja för arbetsbelastningsutveckling
- Rekommendationer för standardisering av verktyg och processer
- Rekommendationer för att skydda en utvecklingslivscykel
- Rekommendationer för att använda säkra distributionsmetoder
- Mönster för distributionsstämplar
- Azure Resource Manager-mallar (ARM-mallar)
- Bicep
- Azure-pipelines
- GitHub Actions
- Terraform
Checklista för utmärkt drift
Se den fullständiga uppsättningen rekommendationer.