Dela via

Infrastruktur som kod

  • Artikel

Infrastruktur som kod (IaC) är en viktig DevOps-metod som omfattar hantering av infrastruktur, till exempel nätverk, beräkningstjänster, databaser, lagring och anslutningstopologi, i en beskrivande modell. Med IaC kan team utveckla och släppa ändringar snabbare och med större tillförsikt. Fördelarna med IaC är:

  • Ökat förtroende för distributioner
  • Möjlighet att hantera flera miljöer
  • Bättre förståelse för infrastrukturens tillstånd

Mer information om fördelarna med att använda infrastruktur som kod finns i Repeterbar infrastruktur.

Verktyg

Det finns två metoder som du kan använda när du implementerar infrastruktur som kod.

  • Imperativ infrastruktur som kod innebär att skriva skript på språk som Bash eller PowerShell. Du anger uttryckligen kommandon som körs för att skapa ett önskat resultat. När du använder imperativa distributioner är det upp till dig att hantera sekvensen med beroenden, felkontroll och resursuppdateringar.
  • Deklarativ infrastruktur som kod innebär att skriva en definition som definierar hur du vill att din miljö ska se ut. I den här definitionen anger du ett önskat resultat snarare än hur du vill att det ska uppnås. Verktygen beskriver hur du får resultatet att ske genom att inspektera ditt aktuella tillstånd, jämföra det med måltillståndet och sedan tillämpa skillnaderna.

ARM-mallar

Granska information om Azure Resource Manager-mallar (ARM-mallar).

Bicep

Bicep är ett domänspecifikt språk (DSL) som använder deklarativ syntax för att distribuera Azure-resurser. I Bicep-filer definierar du den infrastruktur som du tänker distribuera och dess egenskaper. Jämfört med ARM-mallar är Bicep-filer enklare att läsa och skriva för en målgrupp som inte är utvecklare eftersom de använder en koncis syntax.

param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
  }
}

Terraform

Granska information om Terraform.

Azure CLI

Granska information om Azure CLI.

Infrastruktur som kodmoduler

Ett av målen med att använda kod för att distribuera infrastrukturen är att undvika att duplicera arbete eller skapa flera mallar för samma eller liknande ändamål. Infrastrukturmoduler bör vara återanvändbara och flexibla och ha ett tydligt syfte.

Moduler är oberoende filer som vanligtvis innehåller en uppsättning resurser som ska distribueras tillsammans. Med moduler kan du dela upp komplexa mallar i mindre, mer hanterbara koduppsättningar. Du kan se till att varje modul fokuserar på en specifik uppgift och att alla moduler kan återanvändas för flera distributioner och arbetsbelastningar.

Bicep-moduler

Med Bicep kan du skapa och anropa moduler. När moduler har skapats kan de användas från valfri annan Bicep-mall. En Bicep-modul av hög kvalitet bör definiera flera relaterade resurser. När du till exempel definierar en Azure-funktion distribuerar du vanligtvis ett visst program, en värdplan för programmet och ett lagringskonto för programmets metadata. Dessa komponenter definieras separat, men de utgör en logisk gruppering av resurser, så du bör överväga att definiera dem tillsammans som en modul.

Bicep-moduler används ofta:

  • Parametrar för att acceptera värden från en anropande modul.
  • Utdatavärden för att returnera resultat till en anropande modul.
  • Resurser för att definiera ett eller flera infrastrukturobjekt för en modul som ska hanteras.

Publicera Bicep-moduler

Du har flera alternativ för att publicera och dela Bicep-moduler.

  • Offentligt register: Det offentliga modulregistret finns i ett Microsoft-containerregister (MCR). Källkoden och modulerna som den innehåller lagras i GitHub.
  • Privat register: Du kan använda Azure Container Registry för att publicera moduler till ett privat register. Information om hur du publicerar moduler till ett register i en CI/CD-pipeline finns i Bicep och GitHub Actions, eller om du vill, Bicep och Azure Pipelines.
  • Mallspecifikation: Du kan använda mallspecifikationer för att publicera Bicep-moduler. Mallspecifikationer är avsedda att vara fullständiga mallar, men med Bicep kan du använda mallspecifikationer för att distribuera moduler.
  • Versionskontrollsystem: Du kan läsa in moduler direkt från versionskontrollverktyg som GitHub eller Azure DevOps.

Terraform-moduler

Med Terraform kan du skapa och anropa moduler. Varje Terraform-konfiguration har minst en modul, så kallad rotmodul, som består av resurser som definierats i .tf filer i huvudarbetskatalogen. Varje modul kan anropa andra moduler, vilket gör att du kan inkludera underordnade moduler i huvudkonfigurationsfilen. Moduler kan också anropas flera gånger i samma konfiguration eller från olika konfigurationer.

Moduler definieras med alla samma konfigurationsspråkbegrepp. De används oftast:

  • Indatavariabler för att acceptera värden från en anropande modul.
  • Utdatavärden för att returnera resultat till en anropande modul.
  • Resurser för att definiera ett eller flera infrastrukturobjekt för en modul som ska hanteras.

Publicera Terraform-moduler

Du har flera alternativ för att publicera och dela Terraform-moduler:

  • Offentligt register: HashiCorp har ett eget Terraform-modulregister som gör det möjligt för användare att generera delbara Terraform-moduler. Det finns för närvarande flera Azure-moduler publicerade i Terraform Module Registry.
  • Privat register: Du kan sömlöst publicera Terraform-moduler till en privat lagringsplats som Terraform Cloud Private Registry eller Azure Container Registry.
  • Versionskontrollsystem: Du kan läsa in privata moduler direkt från versionskontrollverktyg som GitHub. Information om källor som stöds finns i Terraform-modulkällor.

Designöverväganden

  • Överväg att använda IaC när du distribuerar landningszonresurser till Azure. IaC inser helt distributionsoptimering, minskar konfigurationsarbetet och automatiserar hela miljöns distributioner.

  • Avgör om du ska använda en imperativ eller deklarativ IaC-metod.

    • Om du använder en imperativ metod anger du uttryckligen kommandon som ska köras som ger önskat resultat.

    • Om du använder en deklarativ metod anger du önskat resultat i stället för hur du vill att det ska göras.

  • Överväg distributionsomfång. Ha en god förståelse för Azures hanteringsnivåer och hierarki. Varje IaC-distribution måste känna till omfånget för distribution av Azure-resurser.

  • Avgör om du ska använda ett internt Azure-verktyg eller ett icke-inbyggt IaC-verktyg i Azure. Några saker att tänka på:

    • Inbyggda Azure-verktyg som Azure CLI, ARM-mallar och Bicep stöds fullt ut av Microsoft, vilket gör att deras nya funktioner kan integreras snabbare.

    • Med icke-inbyggda verktyg som Terraform kan du hantera infrastruktur som kod för flera molnleverantörer som AWS eller GCP. Nya Azure-funktioner kan dock ta lite tid att inkludera i icke-inbyggda. Om din organisation är multimoln eller om din organisation redan använder och är väl insatt i Terraform bör du överväga att använda Terraform för att distribuera Azure-landningszoner.

  • Eftersom moduler gör att du kan dela in komplexa mallar i mindre koduppsättningar bör du överväga att använda IaC-moduler för resurser som ofta distribueras tillsammans. Du kan se till att varje modul fokuserar på en viss uppgift och kan återanvändas för flera distributioner och arbetsbelastningar.

  • Överväg att använda en publiceringsstrategi för IaC-moduler genom att välja mellan offentliga register, privata register eller ett versionskontrollsystem som en Git-lagringsplats.

  • Överväg att använda en CI/CD-pipeline för IaC-distributioner. En pipeline framtvingar den återanvändbara process som du anger för att säkerställa kvaliteten på dina distributioner och Azure-miljön.

Designrekommendationer

  • Anta en IaC-metod för att distribuera, hantera, styra och stödja distributioner av Azure-landningszoner.

  • Använd inbyggda Azure-verktyg för IaC i följande scenarier:

    • Du vill bara använda inbyggda Azure-verktyg. Din organisation kan ha tidigare distribution av ARM- eller Bicep-mallar.

    • Din organisation vill ha omedelbart stöd för alla förhandsversioner och GA-versioner av Azure-tjänster.

  • Använd icke-interna verktyg för IaC i följande scenarier:

    • Din organisation använder för närvarande Terraform för att distribuera infrastruktur till andra moln som AWS eller GCP.

    • Din organisation behöver inte ha omedelbar support för alla förhandsversioner och GA-versioner av Azure-tjänster.

  • Använd återanvändbara IaC-moduler för att undvika repetitivt arbete. Du kan dela moduler i organisationen för att distribuera flera projekt eller arbetsbelastningar och hantera mindre komplex kod.

  • Publicera och använda IaC-moduler från offentliga register i följande scenarier:

    • Du vill använda moduler för Azure Landing Zone som redan har publicerats till offentliga register. Mer information finns i Terraform-modulen Azure-landningszoner.

    • Du vill använda moduler som underhålls, uppdateras och stöds av Microsoft, Terraform eller andra modulleverantörer.

      • Kontrollera att du kontrollerar supportutdraget från valfri modulprovider som du utvärderar.

  • Publicera och använda IaC-moduler från privata register eller versionskontrollsystem i följande scenarier:

    • Du vill skapa egna moduler baserat på organisationens krav.

    • Du vill ha fullständig kontroll över alla funktioner och underhålla, uppdatera och publicera nya versioner av moduler.

  • Använd en CI/CD-pipeline för att distribuera IaC-artefakter och säkerställa kvaliteten på distributionen och Azure-miljöerna.