Wat is infrastructuur als code?

10 minuten

U wordt gevraagd om te evalueren of infrastructuur als code een waardevolle benadering kan zijn voor het inrichten van resources in uw bedrijf. U bekijkt de beschikbare opties voor implementatie, waaronder:

Azure Portal
Azure-CLI
Azure PowerShell
Azure Resource Manager-sjablonen (JSON en Bicep)

U zoekt een herhaalbare optie en u moet beslissen welke technologie u moet gebruiken om uw Azure-infrastructuur te implementeren.

In deze les leert u hoe en waarom infrastructuur als code u kan helpen uw Azure-infrastructuur op een geautomatiseerde en herhaalbare manier te implementeren.

Azure CLI-opdrachten worden gebruikt om concepten te illustreren. Meer informatie over het gebruik van opdrachten voor het implementeren van resources in andere modules van het Bicep-leertraject.

Infrastructuur definiëren als code

Uw bedrijf ontwerpt nieuw speelgoed voor release op de markt, en de meeste nieuwe speelgoed vereisen na aankoop enkele assembly's. Het ontwerpteam van het bedrijf maakt instructiehandleidingen die bij elk speelgoed moeten worden opgenomen. Elke handleiding bevat details over het correct samenstellen van het speelgoed.

U kunt infrastructuur beschouwen als code als de instructiehandleiding voor uw infrastructuur. De handleiding bevat details over de eindconfiguratie van uw resources en hoe u deze configuratiestatus bereikt.

Infrastructuur als code is het proces van het automatiseren van uw infrastructuurinrichting. Het maakt gebruik van een beschrijvende coderingstaal en versiebeheersysteem dat vergelijkbaar is met wat wordt gebruikt voor broncode. Wanneer u een toepassing maakt, genereert de broncode hetzelfde resultaat telkens wanneer u deze compileert. Op een vergelijkbare manier worden implementaties van infrastructuur als code geautomatiseerd, consistent en herhaalbaar. Infrastructuur als code kan de implementaties van uw infrastructuurbronnen automatiseren, zoals virtuele netwerken, virtuele machines, toepassingen en opslag.

Diagram met de infrastructuur als codeproces met behulp van een opslagplaats voor broncode met een sjabloon waarmee Azure-resources worden geïmplementeerd.

Als u de instructiehandleiding voor het nieuwe speelgoed terugroept, zijn er meerdere manieren om de handleiding te schrijven. Een optie is om elke stap van het buildproces te beschrijven. Een andere optie is om een geëxplodeerd beeld weer te geven van de stukken en onderdelen die nodig zijn om het speelgoed te monteren. Verderop in deze les leert u meer over de verschillen tussen imperatieve en declaratieve code en hoe deze betrekking hebben op de instructiehandleidingen van uw bedrijf.

Waarom infrastructuur gebruiken als code?

Het gebruik van een infrastructuur als codebenadering biedt veel voordelen voor het inrichten van resources. Met infrastructuur als code kunt u het volgende doen:

Vergroot het vertrouwen in uw implementaties.
Meerdere omgevingen beheren.
Beter inzicht krijgen in uw cloudresources.

Verhoog het vertrouwen

Een van de voordelen van het gebruik van infrastructuur als code is het vertrouwensniveau dat u krijgt in uw implementaties van verbeteringen in consistentie en beveiliging.

Integratie met huidige processen: als uw organisatie al gebruikmaakt van standaardprocedures voor softwareontwikkeling, kunt u dezelfde processen gebruiken voor uw infrastructuurimplementaties. Peerbeoordelingen kunnen bijvoorbeeld helpen bij het detecteren van problemen in configuraties die mogelijk moeilijk te detecteren zijn bij het aanbrengen van handmatige wijzigingen.
Consistentie: Door een infrastructuur als codebenadering te gebruiken, kan uw team goed gevestigde processen volgen om de infrastructuur te implementeren. Door deze processen te volgen, verschuift de verantwoordelijkheid van een kleine groep personen naar uw automatiseringsproces en -hulpprogramma's. Infrastructuur als code helpt bij het verminderen van menselijke fouten bij het inrichten van resources en het garanderen van consistente implementaties.
Geautomatiseerd scannen: U kunt configuraties voor infrastructuur als code scannen met geautomatiseerde hulpprogramma's die kunnen controleren op fouten in de code. Geautomatiseerde hulpprogramma's kunnen ook voorgestelde wijzigingen bekijken om ervoor te zorgen dat beveiligings- en prestatieprocedures worden gevolgd.
Geheimbeheer: veel oplossingen vereisen geheimen, zoals verbindingsreeks s, versleutelingssleutels, clientgeheimen en certificaten. In Azure is een Azure Key Vault de service die wordt gebruikt om deze geheimen veilig op te slaan. Veel hulpprogramma's voor infrastructuur als code kunnen worden geïntegreerd met Key Vault om veilig toegang te krijgen tot deze geheimen tijdens de implementatie.
Toegangsbeheer: Met implementaties van infrastructuur als code hebt u de mogelijkheid om beheerde identiteiten of serviceaccounts te gebruiken om het inrichten van resources te automatiseren. Dit proces zorgt ervoor dat alleen deze identiteiten uw cloudresources kunnen wijzigen. Het helpt ook onjuiste configuraties te voorkomen die zijn geïmplementeerd in productie. Indien nodig kunt u dit proces overschrijven met behulp van een account voor toegang voor noodgevallen (ook wel een break glass-account genoemd) of met behulp van de functie Privileged Identity Management van Microsoft Entra ID.
Vermijd configuratiedrift: Idempotentie is een term die vaak wordt gekoppeld aan infrastructuur als code. Wanneer een bewerking idempotent is, betekent dit dat het hetzelfde resultaat biedt telkens wanneer u deze uitvoert. Als u hulpprogramma's kiest die idempotente bewerkingen gebruiken, kunt u configuratiedrift voorkomen.

Als voorbeeld van idempotentie kunt u de volgende Azure CLI-opdracht overwegen. Met de opdracht maakt u een Azure-resourcegroep met de naam storage-resource-group in de regio VS - oost.

az group create \
  --name storage-resource-group \
  --location eastus

Als u deze opdracht een tweede keer uitvoert, ontvangt u exact dezelfde uitvoer omdat deze Azure CLI-opdracht is ontworpen om idempotent te zijn. U ontvangt geen foutmelding of een dubbele resourcegroep.

Wanneer u infrastructuur als code gebruikt, kunt u uw omgeving opnieuw implementeren bij elke release van uw oplossing. Deze releases kunnen kleine configuratiewijzigingen of zelfs belangrijke updates bevatten. Dit proces voorkomt configuratiedrift. Als een onbedoelde wijziging in een resource wordt aangebracht, kan deze worden gecorrigeerd door de configuratie opnieuw te implementeren. Door deze aanpak te volgen, documenteert u uw omgeving met behulp van code.

Meerdere omgevingen beheren

Veel organisaties onderhouden meerdere toepassingsomgevingen. De ontwikkelaars in uw speelgoedbedrijf hebben mogelijk meerdere versies van toepassingscode gefaseerd in een opslagplaats voor release in verschillende omgevingen. De omgevingen kunnen ontwikkeling, testen en productie omvatten. Sommige organisaties onderhouden meerdere productieomgevingen voor toepassingen die wereldwijd worden gedistribueerd. Andere organisaties, zoals onafhankelijke softwareleveranciers (ISV's), onderhouden meerdere tenantomgevingen voor hun klanten.

Hier volgen enkele van de belangrijkste manieren waarop infrastructuur als code u kan helpen bij het beheren van uw omgevingen:

Nieuwe omgevingen inrichten: een van de belangrijkste voordelen van cloud-computing is de mogelijkheid om te schalen. Infrastructuur als code kan u helpen bij het schalen naar meerdere exemplaren van uw toepassing. Deze exemplaren kunnen helpen tijdens tijden van verhoogde belasting of u kunt ze implementeren voor gebruikers in andere gebieden van de wereld. Deze flexibiliteit kan ook nuttig zijn wanneer u uw toepassing test, zoals tijdens penetratietests, belastingstests en fouttests. Met een goed gedefinieerde codebasis kunt u deze nieuwe omgevingen dynamisch op een consistente manier inrichten.
Niet-productieomgevingen: Een veelvoorkomend probleem dat organisaties tegenkomen, is differentiatie tussen productie- en niet-productieomgevingen. Wanneer u resources handmatig in afzonderlijke omgevingen inricht, is het mogelijk dat de eindconfiguraties niet overeenkomen. Een voorbeeld is wanneer u een nieuwe functie implementeert in een niet-productieomgeving die verschilt van de productieomgeving. Het is mogelijk dat de nieuwe functie niet werkt zoals verwacht in de productieomgeving vanwege de verschillen tussen de twee omgevingen. Het gebruik van infrastructuur als code kan helpen deze problemen te minimaliseren. U kunt voor elke omgeving dezelfde configuratiebestanden gebruiken, maar verschillende invoerparameters opgeven om uniek te zijn.
Herstel na noodgevallen: in sommige gevallen kan infrastructuur als code worden gebruikt als onderdeel van het noodherstelplan van een organisatie. Mogelijk moet u uw omgeving in een andere regio opnieuw maken vanwege een servicestoring. Door infrastructuur als code te gebruiken, kunt u snel een nieuwe instantie inrichten om een failover uit te voeren in plaats van alles handmatig te implementeren en opnieuw te configureren.

Beter inzicht krijgen in uw cloudresources

Infrastructuur als code kan u helpen de status van uw cloudresources beter te begrijpen:

Audittrail: wijzigingen in uw configuraties voor infrastructuur als code worden op dezelfde manier beheerd als de broncode van uw toepassing. Deze wijzigingen worden bijgehouden in uw hulpprogramma's, zoals met de versiegeschiedenis van Git. Dit audittrail betekent dat u de details van elke wijziging, wie de wijziging heeft aangebracht, en wanneer de wijziging is aangebracht, kunt bekijken.
Documentatie: U kunt veel configuraties voor infrastructuur als code gebruiken om metagegevens toe te voegen, zoals opmerkingen, waarin het doel van de code in uw configuratie wordt beschreven. Als uw organisatie al een codedocumentatieproces volgt, kunt u overwegen om dezelfde procedures met uw infrastructuurcode te gebruiken.
Geïntegreerd systeem: Wanneer een ontwikkelaar aan een nieuwe functie werkt, moeten ze vaak wijzigingen aanbrengen in toepassingscode en infrastructuurcode. Wanneer u een gemeenschappelijk systeem gebruikt, kan uw organisatie de relatie tussen uw toepassingen en uw infrastructuur beter begrijpen.
Beter inzicht in de cloudinfrastructuur: wanneer u Azure Portal gebruikt om resources in te richten, worden veel van de processen vanuit de weergave geabstraheerd. Infrastructuur als code kan helpen een beter inzicht te krijgen in de werking van Azure en het oplossen van problemen die zich kunnen voordoen. Wanneer u bijvoorbeeld een virtuele machine maakt met behulp van Azure Portal, worden sommige gemaakte resources vanuit de weergave geabstraheerd. Beheerde schijven en netwerkinterfacekaarten worden achter de schermen geïmplementeerd. Wanneer u dezelfde virtuele machine implementeert met infrastructuur als code, hebt u volledige controle over alle resources die worden gemaakt.

Imperatieve en declaratieve code

U kunt op verschillende manieren een instructiehandleiding schrijven voor nieuwe speelgoedassembly. Wanneer u de implementatie van services en infrastructuur automatiseert, kunt u twee benaderingen gebruiken: imperatief en declaratief.

Met imperatieve code voert u een reeks opdrachten uit, in een specifieke volgorde, om een eindconfiguratie te bereiken. Dit proces definieert wat de code moet uitvoeren en definieert hoe de taak moet worden uitgevoerd. De imperatieve benadering is als een stapsgewijze instructiehandleiding.
Met declaratieve code geeft u alleen de eindconfiguratie op. De code definieert niet hoe de taak moet worden uitgevoerd. De declaratieve benadering is net als de instructiehandleiding voor uitgeploffende weergaven.

Wanneer u kiest tussen het gebruik van een imperatieve benadering en een declaratieve benadering voor het inrichten van resources, moet u rekening houden met de hulpprogramma's die mogelijk al in uw organisatie worden gebruikt. Denk ook na over welke benadering uw eigen vaardigheden kunnen overeenkomen.

Imperatieve code

In Azure wordt een imperatieve codebenadering programmatisch uitgevoerd met behulp van een scripttaal zoals Bash of Azure PowerShell. De scripts voeren een reeks stappen uit om uw resources te maken, te wijzigen en zelfs te verwijderen.

In dit voorbeeld ziet u twee Azure CLI-opdrachten waarmee een resourcegroep en een opslagaccount worden gemaakt.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

Met de eerste opdracht maakt u een resourcegroep met de naam storage-resource-group in de regio VS - oost. Met de tweede opdracht maakt u een opslagaccount met de naam mystorageaccount in de storage-resource-group resourcegroep die in de eerste opdracht is gemaakt. Met de tweede opdracht worden ook bepaalde eigenschappen voor het opslagaccount geconfigureerd, waaronder het type opslagaccount en de bijbehorende toegangslaag.

U kunt een imperatieve benadering gebruiken om het inrichten van resources volledig te automatiseren, maar de benadering heeft enkele nadelen. Naarmate uw architectuur verder wordt ontwikkeld, kunnen scripts complex worden om te beheren. Opdrachten kunnen worden bijgewerkt of afgeschaft, waarvoor beoordelingen van bestaande scripts vereist zijn.

Declaratieve code

In Azure wordt een declaratieve codebenadering uitgevoerd met behulp van sjablonen. Er zijn veel soorten sjablonen beschikbaar voor gebruik, waaronder:

JSON
Bicep
Ansible, door RedHat
Terraform, door HashiCorp

Notitie

Deze module is gericht op het gebruik van Bicep-sjablonen.

Bekijk het volgende voorbeeld van een Bicep-sjabloon waarmee een opslagaccount wordt geconfigureerd. De configuratie van het opslagaccount komt overeen met het Azure CLI-voorbeeld.

resource storageAccount 'Microsoft.Storage/storageAccounts@2203-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

In de sectie Resources wordt de configuratie van het opslagaccount gedefinieerd. Deze sectie bevat de naam, locatie en eigenschappen van het opslagaccount, met inbegrip van de SKU en het type account.

U ziet mogelijk dat de Bicep-sjabloon niet opgeeft hoe het opslagaccount moet worden geïmplementeerd. Hiermee geeft u alleen op hoe het opslagaccount eruit moet zien. De werkelijke stappen die achter de schermen worden uitgevoerd om dit opslagaccount te maken of om het bij te werken zodat deze overeenkomt met de specificatie, blijven ongewijzigd zodat Azure kan beslissen.