Dela via

Använda infrastruktur som kod för att uppdatera Azure-landningszoner

  • Artikel

I den här artikeln beskrivs fördelarna med att använda infrastruktur som kod (IaC) för att uppdatera Azure-landningszoner. Organisationer måste uppdatera sina landningszoner när de fungerar för att säkerställa att konfigurationerna är korrekta och svarar på behovet av ändringar.

IaC kan hantera hela livscykeln och det är utmärkt att hantera de resurser som den distribuerar. Organisationer bör planera att distribuera sina Azure-landningszoner med IaC. Det kräver planering för att justera befintliga icke-IaC-resurser med IaC-resurser som backas upp med tillståndshantering. Du måste mappa befintliga resurser till önskat tillstånd.

Mer information finns i Håll din Azure-landningszon uppdaterad.

Så här fungerar infrastruktur som kod

IaC refererar till praxis och verktyg för att hantera livscykeln för infrastrukturresurser med hjälp av maskinläsbara definitionsfiler. Definitionen för infrastrukturen skrivs, versionshanteras, distribueras via pipelines och blir sedan en del av distributionen för arbetsbelastningar.

IaC-teknikerna är deklarativa, vilket innebär att när IaC körs ställer den in konfigurationen på det som beskrivs i koden, oavsett dess aktuella tillstånd. När du konfigurerar infrastruktur via skript, till exempel Azure CLI eller Azure PowerShell, är de absolut nödvändiga. Imperativa skript utför en uppsättning åtgärder, och resultatet beror på det aktuella tillståndet plus tillståndet efter åtgärderna.

Så om du har en infrastruktur som koddefinition för en Azure-resurs kan du köra den definitionen så ofta du vill, och den skapar bara en ändring om:

  • Definitionen ändras för att lägga till nya resurser, ta bort resurser som tidigare distribuerats eller ändrar resurser som tidigare har distribuerats.
  • Den distribuerade resursen avviker från konfigurationen för att återställa konfigurationen till den definierade.

Du kan använda IaC för att återställa tillståndet genom att ta bort resurser som inte längre behövs och hantera resursernas livscykel genom många ändringar.

Kommentar

Den specifika mekaniken för att ta bort resurser med IaC varierar. Azure Bicep kräver till exempel att en complete distributionstyp används för att åtgärda resurser utanför omfånget. Det här kommandot fungerar bara i specifika omfång. För Terraform har resurser ett lifecycle metaargument som innehåller instruktioner för hur Terraform ska hantera resurser.

För Azure-landningszoner finns det två huvudsakliga alternativ för infrastruktur som kod:

  • Azure Bicep, som är ett domänspecifikt språk som används för att distribuera Microsofts utvecklade Azure-resurser. Mer information finns i Designöverväganden för Azure-landningszoner – Bicep-moduler.
  • Terraform, en produkt som produceras av Hashicorp, för att distribuera infrastruktur till molnet och lokalt. Terraform har specifika Microsoft-producerade resursprovidrar för distribution av Azure-resurser. Mer information finns i Azure-landningszoner – Designöverväganden för Terraform-modulen.

Fördelarna med att uppdatera ALZ med infrastruktur som kod

Följande fördelar beskriver varför du bör använda infrastruktur som kod för att göra dina uppdateringar i landningszonen.

Minska arbetet

Det krävs mindre arbete för att använda infrastruktur som kod för att utföra uppdateringar jämfört med att göra manuella ändringar. IaC-distributionen hjälper dig att besvara följande frågor:

  • Hur konfigureras resurser i dag?
  • Hur kommer den att konfigureras av den här uppdateringen?
  • Vilka ändringar kommer att göras för att anpassa den till den här uppdateringen?

När en infrastruktur som kodverktygsuppsättning körs kan den skapa en jämförelse eller "differentiell" avläsning av ändringarna. Granska den här avläsningen innan du checkar in ändringar i miljön.

Verktygsuppsättningen kan kompilera informationen för ändringen i stället för en operatör eller en tekniker.

Reduce-fel

På grund av distributionernas programmatiska karaktär minskar infrastrukturen som kod mänskliga fel när den gör ändringar. Den ändrar bara vad som har definierats och har förhandsgranskningsalternativ, så det minskar avbrott som orsakas av misslyckade eller ofullständiga ändringar. Det har också förbättrade testalternativ.

Versionskontroll och historik

Infrastruktur som koddistributioner backas upp av en definitionsfil, så du kan använda källkontroll för att hantera versionerna av dina definitioner. Beroende på vilken IaC-metod du använder kan du referera till distributionerna i Azure for Bicep eller tillståndsfilen för Terraform för att granska historiken för tidigare distributioner.

När du använder källkontrollmetoder skapas en ny gren av din IaC för att lägga till ändringar och revisioner. Grenens historik i källkontrollsystemet samlar in iterationer och ändringar. Du kan använda den för att distribuera ändringar till en testmiljö tills du är redo att sammanfoga och distribuera ändringarna till produktion. Mer information finns i Testmetod för Azure-landningszoner. Under den här cykeln samlar distributionsposterna in den version som används och de resurser som distribueras, vilket ger en mycket synlig historik.

Använd dessa testmetoder med Bicep i allmänna testsyften. Med dessa metoder kan du utföra testning innan du distribuerar koden och du kan testa i icke-produktionsmiljöer från din gren.

Testa miljöer

IaC-distributioner kan upprepas, så du kan använda samma definition för att distribuera en andra (eller flera) miljö baserat på distributionen. Den här metoden är värdefull för att testa ändringar.

Om du till exempel vill ersätta Azure Firewall med premium-SKU:n kan du distribuera en testmiljö och verifiera ändringarna utan att ändra produktionen.

Fånga konfigurationsavvikelser

IaC är ett unikt alternativ för att fånga konfigurationsavvikelser under uppdateringar. Distributionen fångar upp ändringar i definitionsfilen och visar instanser där resurskonfigurationen skiljer sig från definitionen.

Uppdateringar av landningszoner med IaC kan hjälpa dig att fånga den här konfigurationsavvikelsen och göra så att du kan uppdatera koden på rätt sätt, åtgärda dessa felkonfigurationer via uppdateringen eller åtgärda dem på ett annat sätt.

När du gör en ändring av resurser via portalen, CLI eller en icke-IaC-metod implementeras ändringen. Nästa gång du kör en distribution via IaC flaggas jämförelsen mellan det koddefinierade tillståndet och det faktiska tillståndet i portalen med hjälp av what-if- eller planfunktioner. Använd den här metoden för att identifiera om en miljö ändras utanför kodfilen.

När feljusteringen har identifierats kan du köra IaC för att försöka justera distributionen med definitionen. Använd den här metoden för att identifiera problem och åtgärda scenarier beroende på typen av problem, körningens natur och hur ändringarna gjordes. Terraform försöker till exempel återställa baslinjen till resurser som den har distribuerat och en Complete lägesdistribution i Bicep tar bort resurser i en resursgrupp som inte ingår i definitionen. Dessa verktyg identifierar och reparerar konfigurationsavvikelser, men de kanske inte åtgärdar alla problem.

Mer information finns i Out-of-band-ändringar och Identifiera och hantera drift med Terraform.

Ändringar som definieras i portalen är besvärliga att implementera tillbaka till IaC. Du måste uppdatera koden så att den matchar det aktuella tillståndet, vilket ofta innebär att granska varje resursändring och uppdatera dess parametrar så att de matchar konfigurationen "som är".

Om du använder IaC för att hantera din landningszon eller andra resurser bör du bara göra ändringar utanför IaC som en del av en nödsituation. Vidta försiktighetsåtgärder med konton som har åtkomst till att göra ändringar direkt, till exempel Privileged Identity Management.

Granska allmänna automatiserings- och säkerhetsrutiner i följande artiklar:

Nästa steg

Utforska en introduktion till IaC-verktygen i följande artiklar: