Infrastructuur als code

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Cloudeigen systemen omarmen microservices, containers en modern systeemontwerp om snelheid en flexibiliteit te bereiken. Ze bieden geautomatiseerde build- en releasefasen om consistente en kwaliteitscode te garanderen. Maar dat is slechts een deel van het verhaal. Hoe richt u de cloudomgevingen in waarop deze systemen worden uitgevoerd?

Moderne cloudtoepassingen omarmen de algemeen geaccepteerde praktijk van Infrastructure as Code, of IaC. Met IaC automatiseert u platforminrichting. U past in wezen software-engineeringprocedures toe, zoals testen en versiebeheer op uw DevOps-procedures. Uw infrastructuur en implementaties zijn geautomatiseerd, consistent en herhaalbaar. Net zoals continue levering het traditionele model van handmatige implementaties geautomatiseerd, ontwikkelt Infrastructure as Code (IaC) hoe toepassingsomgevingen worden beheerd.

Met hulpprogramma's zoals Azure Resource Manager (ARM), Terraform en de Azure CLI (Opdrachtregelinterface) kunt u declaratief scripts uitvoeren voor de cloudinfrastructuur die u nodig hebt.

Azure Resource Manager-sjablonen

ARM staat voor Azure Resource Manager. Het is een API-inrichtingsengine die is ingebouwd in Azure en wordt weergegeven als een API-service. Met ARM kunt u de resources in een enkele, gecoördineerde bewerking implementeren, bijwerken, verwijderen en beheren. U geeft de engine een op JSON gebaseerde sjabloon op waarmee de resources worden opgegeven die u nodig hebt en de configuratie ervan. ARM organiseert de implementatie automatisch in de juiste volgorde die afhankelijkheden respecteert. De motor zorgt voor idempotentie. Als er al een gewenste resource bestaat met dezelfde configuratie, wordt het inrichten genegeerd.

Azure Resource Manager-sjablonen zijn een op JSON gebaseerde taal voor het definiëren van verschillende resources in Azure. Het basisschema ziet er ongeveer uit als afbeelding 10-14.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "",
  "apiProfile": "",
  "parameters": {  },
  "variables": {  },
  "functions": [  ],
  "resources": [  ],
  "outputs": {  }
}

Afbeelding 10-14 - Het schema voor een Resource Manager-sjabloon

In deze sjabloon kan een opslagcontainer in de sectie resources als volgt worden gedefinieerd:

"resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "apiVersion": "2018-07-01",
      "sku": {
        "name": "[parameters('storageAccountType')]"
      },
      "kind": "StorageV2",
      "properties": {}
    }
  ],

Afbeelding 10-15 - Een voorbeeld van een opslagaccount dat is gedefinieerd in een Resource Manager-sjabloon

Een ARM-sjabloon kan worden geparameteriseerd met dynamische omgevings- en configuratiegegevens. Hierdoor kan het opnieuw worden gebruikt om verschillende omgevingen te definiëren, zoals ontwikkeling, QA of productie. Normaal gesproken maakt de sjabloon alle resources binnen één Azure-resourcegroep. Het is mogelijk om meerdere resourcegroepen in één Resource Manager-sjabloon te definiëren, indien nodig. U kunt alle resources in een omgeving verwijderen door de resourcegroep zelf te verwijderen. Kostenanalyse kan ook worden uitgevoerd op het niveau van de resourcegroep, zodat u snel kunt controleren hoeveel elke omgeving kost.

Er zijn veel voorbeelden van ARM-sjablonen beschikbaar in het Azure Quickstart Templates-project op GitHub. Ze kunnen helpen bij het maken van een nieuwe sjabloon of het wijzigen van een bestaande sjabloon.

Resource Manager-sjablonen kunnen op veel manieren worden uitgevoerd. Misschien is de eenvoudigste manier om ze gewoon in Azure Portal te plakken. Voor experimentele implementaties kan deze methode snel zijn. Ze kunnen ook worden uitgevoerd als onderdeel van een build- of releaseproces in Azure DevOps. Er zijn taken die gebruikmaken van verbindingen in Azure om de sjablonen uit te voeren. Wijzigingen in Resource Manager-sjablonen worden incrementeel toegepast, wat betekent dat voor het toevoegen van een nieuwe resource alleen het toevoegen aan de sjabloon nodig is. Met de hulpprogramma's worden de verschillen tussen de huidige resources en de resources die in de sjabloon zijn gedefinieerd, afgestemd. Resources worden vervolgens gemaakt of gewijzigd, zodat ze overeenkomen met wat in de sjabloon is gedefinieerd.

Terraform

Cloudeigen toepassingen worden vaak gebouwd om te worden cloud agnostic. Dit betekent dat de toepassing niet nauw is gekoppeld aan een bepaalde cloudleverancier en kan worden geïmplementeerd in elke openbare cloud.

Terraform is een commercieel sjabloonprogramma waarmee cloudeigen toepassingen kunnen worden ingericht voor alle belangrijke cloudspelers: Azure, Google Cloud Platform, AWS en AliCloud. In plaats van JSON te gebruiken als sjabloondefinitietaal, wordt de iets terse HCL (Hashicorp Configuration Language) gebruikt.

Een voorbeeld van een Terraform-bestand dat hetzelfde doet als de vorige Resource Manager-sjabloon (afbeelding 10-15) wordt weergegeven in afbeelding 10-16:

provider "azurerm" {
  version = "=1.28.0"
}

resource "azurerm_resource_group" "testrg" {
  name     = "production"
  location = "West US"
}

resource "azurerm_storage_account" "testsa" {
  name                     = "${var.storageAccountName}"
  resource_group_name      = "${azurerm_resource_group.testrg.name}"
  location                 = "${var.region}"
  account_tier             = "${var.tier}"
  account_replication_type = "${var.replicationType}"

}

Afbeelding 10-16 - Een voorbeeld van een Resource Manager-sjabloon

Terraform biedt ook intuïtieve foutberichten voor probleemsjablonen. Er is ook een handige validatietaak die kan worden gebruikt in de buildfase om sjabloonfouten vroeg te ondervangen.

Net als bij Resource Manager-sjablonen zijn opdrachtregelprogramma's beschikbaar voor het implementeren van Terraform-sjablonen. Er zijn ook door de community gemaakte taken in Azure Pipelines waarmee Terraform-sjablonen kunnen worden gevalideerd en toegepast.

Soms leveren Terraform- en ARM-sjablonen zinvolle waarden op, zoals een verbindingsreeks naar een zojuist gemaakte database. Deze informatie kan worden vastgelegd in de build-pijplijn en worden gebruikt in volgende taken.

Azure CLI-scripts en -taken

Ten slotte kunt u Azure CLI gebruiken om uw cloudinfrastructuur declaratief te scripten. Azure CLI-scripts kunnen worden gemaakt, gevonden en gedeeld om bijna elke Azure-resource in te richten en te configureren. De CLI is eenvoudig te gebruiken met een zachte leercurve. Scripts worden uitgevoerd in PowerShell of Bash. Ze zijn ook eenvoudig om fouten op te sporen, met name in vergelijking met ARM-sjablonen.

Azure CLI-scripts werken goed wanneer u uw infrastructuur wilt afbreken en opnieuw wilt implementeren. Het bijwerken van een bestaande omgeving kan lastig zijn. Veel CLI-opdrachten zijn niet idempotent. Dit betekent dat ze de resource telkens opnieuw maken wanneer ze worden uitgevoerd, zelfs als de resource al bestaat. Het is altijd mogelijk om code toe te voegen die controleert op het bestaan van elke resource voordat u deze maakt. Maar als u dit doet, kan uw script worden opgeblazen en moeilijk te beheren.

Deze scripts kunnen ook worden ingesloten in Azure DevOps-pijplijnen als Azure CLI tasks. Als u de pijplijn uitvoert, wordt het script aangeroepen.

Afbeelding 10-17 toont een YAML-fragment met de versie van Azure CLI en de details van het abonnement. Let op hoe Azure CLI-opdrachten zijn opgenomen in een inlinescript.

- task: AzureCLI@2
  displayName: Azure CLI
  inputs:
    azureSubscription: <Name of the Azure Resource Manager service connection>
    scriptType: ps
    scriptLocation: inlineScript
    inlineScript: |
      az --version
      az account show

Afbeelding 10-17 - Azure CLI-script

In het artikel What is Infrastructure as Code, Author Sam Guckenheimer beschrijft hoe"Teams die IaC implementeren stabiele omgevingen snel en op schaal kan leveren. Teams vermijden handmatige configuratie van omgevingen en dwing consistentie af door de gewenste status van hun omgevingen weer te geven via code. Implementaties van infrastructuur met IaC zijn herhaalbaar en voorkomen dat er runtimeproblemen ontstaan door configuratieverschuivingen of ontbrekende afhankelijkheden. DevOps-teams kunnen samenwerken met een geïntegreerde set procedures en hulpprogramma's om toepassingen en hun ondersteunende infrastructuur snel, betrouwbaar en op schaal te leveren."

VorigeVolgende