Infrastructuur als code

Artikel
05/23/2023

Infrastructure as Code (IaC) is een belangrijke DevOps-praktijk waarbij infrastructuur, zoals netwerken, rekenservices, databases, opslag en verbindingstopologie, in een beschrijvend model worden beheerd. Met IaC kunnen teams sneller en met meer vertrouwen wijzigingen ontwikkelen en vrijgeven. Voordelen van IaC zijn onder andere:

Meer vertrouwen in implementaties
Mogelijkheid om meerdere omgevingen te beheren
Beter inzicht in de status van de infrastructuur

Zie Herhaalbare infrastructuur voor meer informatie over de voordelen van het gebruik van infrastructuur als code.

Hulpprogramma's

Er zijn twee benaderingen die u kunt gebruiken bij het implementeren van infrastructuur als code.

Imperatieve infrastructuur als code omvat het schrijven van scripts in talen zoals Bash of PowerShell. U geeft expliciet opdrachten op die worden uitgevoerd om een gewenst resultaat te produceren. Wanneer u imperatieve implementaties gebruikt, is het aan u om de volgorde van afhankelijkheden, foutbeheer en resource-updates te beheren.
Declaratieve infrastructuur als code omvat het schrijven van een definitie die definieert hoe uw omgeving eruit moet zien. In deze definitie geeft u een gewenst resultaat op in plaats van hoe u dit wilt bereiken. De tooling onderzoekt hoe u het resultaat kunt laten plaatsvinden door uw huidige status te inspecteren, deze te vergelijken met uw doelstatus en vervolgens de verschillen toe te passen.

ARM-sjablonen

Bekijk informatie over Azure Resource Manager-sjablonen (ARM-sjablonen).

Bicep

Bicep is een domeinspecifieke taal (DSL) die declaratieve syntaxis gebruikt om Azure-resources te implementeren. In Bicep-bestanden definieert u de infrastructuur die u wilt implementeren en de bijbehorende eigenschappen. In vergelijking met ARM-sjablonen zijn Bicep-bestanden gemakkelijker te lezen en te schrijven voor niet-ontwikkelaars omdat ze een beknopte syntaxis gebruiken.

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

Bekijk informatie over Terraform.

Azure CLI

Bekijk informatie over Azure CLI.

Infrastructuur als codemodules

Een van de doelstellingen van het gebruik van code voor het implementeren van infrastructuur is het voorkomen van duplicatie van werk of het maken van meerdere sjablonen voor dezelfde of vergelijkbare doeleinden. Infrastructuurmodules moeten herbruikbaar en flexibel zijn en een duidelijk doel hebben.

Modules zijn onafhankelijke bestanden, die meestal een set resources bevatten die samen moeten worden geïmplementeerd. Met modules kunt u complexe sjablonen opsplitsen in kleinere, beter beheerbare sets code. U kunt ervoor zorgen dat elke module is gericht op een specifieke taak en dat alle modules herbruikbaar zijn voor meerdere implementaties en workloads.

Bicep-modules

Met Bicep kunt u modules maken en aanroepen. Zodra modules zijn gemaakt, kunnen ze worden gebruikt vanuit elke andere Bicep-sjabloon. Een Bicep-module van hoge kwaliteit moet meerdere gerelateerde resources definiëren. Wanneer u bijvoorbeeld een Azure-functie definieert, implementeert u doorgaans een bepaalde toepassing, een hostingabonnement voor die toepassing en een opslagaccount voor de metagegevens van die toepassing. Deze onderdelen zijn afzonderlijk gedefinieerd, maar vormen een logische groepering van resources, dus u kunt overwegen om ze samen als een module te definiëren.

Bicep-modules worden vaak gebruikt:

Parameters voor het accepteren van waarden uit een aanroepende module.
Uitvoerwaarden om resultaten te retourneren naar een aanroepende module.
Resources voor het definiëren van een of meer infrastructuurobjecten die door een module moeten worden beheerd.

Bicep-modules publiceren

U hebt verschillende opties voor het publiceren en delen van Bicep-modules.

Openbaar register: Het openbare moduleregister wordt gehost in een Microsoft Container Registry (MCR). De broncode en de modules die het bevat, worden opgeslagen in GitHub.
Privéregister: U kunt Azure Container Registry gebruiken om modules te publiceren naar een persoonlijk register. Zie Bicep en GitHub Actions voor informatie over het publiceren van modules naar een register in een CI/CD-pijplijn, of desgewenst Bicep en Azure Pipelines.
Sjabloonspecificatie: U kunt sjabloonspecificaties gebruiken om Bicep-modules te publiceren. Sjabloonspecificaties zijn bedoeld als volledige sjablonen, maar Met Bicep kunt u sjabloonspecificaties gebruiken om modules te implementeren.
Versiebeheersysteem: U kunt modules rechtstreeks laden vanuit hulpprogramma's voor versiebeheer, zoals GitHub of Azure DevOps.

Terraform-modules

Met Terraform kunt u modules maken en aanroepen. Elke Terraform-configuratie heeft ten minste één module, ook wel de hoofdmodule genoemd, die bestaat uit resources die zijn gedefinieerd in .tf bestanden in uw hoofdwerkmap. Elke module kan andere modules aanroepen, zodat u onderliggende modules kunt opnemen in uw hoofdconfiguratiebestand. Modules kunnen ook meerdere keren binnen dezelfde configuratie of vanuit verschillende configuraties worden aangeroepen.

Modules worden gedefinieerd met dezelfde concepten voor de configuratietaal. Ze gebruiken meestal:

Invoervariabelen om waarden van een aanroepende module te accepteren.
Uitvoerwaarden om resultaten te retourneren naar een aanroepende module.
Resources voor het definiëren van een of meer infrastructuurobjecten die door een module moeten worden beheerd.

Terraform-modules publiceren

U hebt verschillende opties voor het publiceren en delen van Terraform-modules:

Openbaar register: HashiCorp heeft een eigen Terraform-moduleregister waarmee gebruikers deelbare Terraform-modules kunnen genereren. Er zijn momenteel verschillende Azure-modules gepubliceerd in het Terraform-moduleregister.
Privéregister: U kunt Terraform-modules naadloos publiceren naar een privéopslagplaats zoals Terraform Cloud Private Registry of Azure Container Registry.
Versiebeheersysteem: U kunt privémodules rechtstreeks laden vanuit hulpprogramma's voor versiebeheer, zoals GitHub. Zie Terraform-modulebronnen voor meer informatie over ondersteunde bronnen.

Overwegingen bij het ontwerpen

Overweeg het gebruik van IaC bij het implementeren van landingszoneresources in Azure. IaC realiseert implementatieoptimalisatie volledig, vermindert de configuratie-inspanning en automatiseert de implementaties van de hele omgeving.
Bepaal of u een imperatieve of declaratieve IaC-benadering moet gebruiken.
- Als u een imperatieve benadering gebruikt, vermeldt u expliciet de opdrachten die moeten worden uitgevoerd en die het gewenste resultaat opleveren.
- Als u een declaratieve benadering gebruikt, geeft u het gewenste resultaat op in plaats van hoe u dit wilt doen.
Overweeg implementatiebereiken. Een goed begrip hebben van Azure-beheerniveaus en -hiërarchie. Elke IaC-implementatie moet het bereik kennen waarin Azure-resources worden geïmplementeerd.
Bepaal of u een systeemeigen Azure-hulpprogramma of een niet-systeemeigen IaC-hulpprogramma van Azure moet gebruiken. Enkele punten om in overweging te nemen:
- Systeemeigen Azure-hulpprogramma's zoals Azure CLI, ARM-sjablonen en Bicep worden volledig ondersteund door Microsoft, waardoor de nieuwe functies sneller kunnen worden geïntegreerd.
- Met niet-systeemeigen hulpprogramma's zoals Terraform kunt u de infrastructuur als code beheren voor meerdere cloudproviders, zoals AWS of GCP. Het kan echter enige tijd duren voordat nieuwe Azure-functies zijn opgenomen in niet-systeemeigen functies. Als uw organisatie meerdere clouds heeft of als uw organisatie al terraform gebruikt en goed thuis is, kunt u terraform gebruiken om Azure-landingszones te implementeren.
Omdat u met modules complexe sjablonen in kleinere codesets kunt opsplitsen, kunt u overwegen om IaC-modules te gebruiken voor resources die vaak samen worden geïmplementeerd. U kunt ervoor zorgen dat elke module is gericht op een specifieke taak en herbruikbaar is voor meerdere implementaties en workloads.
Overweeg een publicatiestrategie voor IaC-modules te gebruiken door te kiezen tussen openbare registers, privéregisters of een versiebeheersysteem zoals een Git-opslagplaats.
Overweeg het gebruik van een CI/CD-pijplijn voor IaC-implementaties. Een pijplijn dwingt het herbruikbare proces af dat u hebt ingesteld om de kwaliteit van uw implementaties en Azure-omgeving te garanderen.

Ontwerpaanbeveling

Een IaC-benadering gebruiken voor het implementeren, beheren, beheren en ondersteunen van implementaties van Azure-landingszones.
Gebruik systeemeigen Azure-hulpprogramma's voor IaC in de volgende scenario's:
- U wilt alleen systeemeigen Azure-hulpprogramma's gebruiken. Uw organisatie heeft mogelijk eerder arm- of Bicep-sjabloonimplementatie-ervaring.
- Uw organisatie wil onmiddellijke ondersteuning voor alle preview- en GA-versies van Azure-services.
Gebruik niet-systeemeigen hulpprogramma's voor IaC in de volgende scenario's:
- Uw organisatie gebruikt momenteel Terraform om infrastructuur te implementeren in andere clouds, zoals AWS of GCP.
- Uw organisatie hoeft niet onmiddellijk ondersteuning te hebben voor alle preview- en GA-versies van Azure-services.
Gebruik herbruikbare IaC-modules om repetitief werk te voorkomen. U kunt modules in uw organisatie delen om meerdere projecten of workloads te implementeren en minder complexe code te beheren.
Publiceer en gebruik IaC-modules uit openbare registers in de volgende scenario's:
- U wilt modules gebruiken voor Azure Landing Zone die al zijn gepubliceerd naar openbare registers. Zie Terraform-module voor Azure-landingszones voor meer informatie.
- U wilt modules gebruiken die worden onderhouden, bijgewerkt en ondersteund door Microsoft, Terraform of andere moduleproviders.
  - Controleer de ondersteuningsverklaring van elke moduleprovider die u evalueert.
Publiceer en gebruik IaC-modules uit privéregisters of versiebeheersystemen in de volgende scenario's:
- U wilt uw eigen modules maken op basis van de vereisten van uw organisatie.
- U wilt volledige controle hebben over alle functies en nieuwe versies van modules onderhouden, bijwerken en publiceren.
Gebruik een CI/CD-pijplijn om IaC-artefacten te implementeren en de kwaliteit van uw implementatie en Azure-omgevingen te garanderen.

Delen via