Hören Sie auf, mit ARM-Vorlagen zu ringen, arbeiten Sie an Ihrem Bizeps

Die Erstellung von Ressourcen in der Azure-Cloud kann auf viele Arten erfolgen. Wenn Sie Azure schon einmal genutzt haben, haben Sie mit Sicherheit eine Ressource über das Portal unter portal.azure.com erstellt. Neben diesem Portal können Sie auch PowerShell oder die Azure CLI verwenden. Wenn Sie Ihre Infrastruktur von einer Anwendung aus verwalten möchten, können Sie mit einem SDK arbeiten und z.B. eine Ressource mit C# erstellen. Schließlich gibt es auch die Möglichkeit, Ressourcen mithilfe von Vorlagen zu verwalten. ARM-Vorlagen gibt es schon seit geraumer Zeit, und jetzt haben Sie eine neue Option: Bicep! Bicep zielt darauf ab, die Verwaltung Ihrer Infrastruktur auf deklarative Weise viel einfacher zu machen, als es mit ARM-Vorlagen der Fall war. ARM-Vorlagen werden in JSON geschrieben und sind daher schwieriger zu schreiben und zu lesen und viel größer. Außerdem ist es recht schwierig, ARM-Vorlagen in mehrere Module aufzuteilen, um wartbare und wiederverwendbare Vorlagen zu erstellen. Bicep ist eine domänenspezifische Sprache (DSL), die all diese Probleme für uns lösen soll!

Alle verschiedenen Optionen, die Sie für die Verwaltung der Infrastruktur in Azure haben, haben eines gemeinsam: Sie verwenden den darunter liegenden Azure Resource Manager. Das folgende Diagramm zeigt die verschiedenen Optionen in Bezug auf den Azure Resource Manager:

Die erste Zeile im Diagramm zeigt Ihnen die verschiedenen Optionen, die wir gerade erwähnt haben: das Portal, Azure CLI, PowerShell, SDKs und Vorlagen. In der zweiten Zeile sehen Sie den Azure Resource Manager. Das ist der Dienst in Azure, mit dem Sie Ressourcen bereitstellen und verwalten können. Die eigentliche Arbeit der Erstellung von Ressourcen wird an einen Ressourcenanbieter delegiert. Es gibt zum Beispiel einen Ressourcenanbieter für alles, was mit virtuellen Maschinen zu tun hat, und einen weiteren für alles, was mit Web Apps zu tun hat.

Mit Ausnahme des Portals können Sie mit all diesen Optionen Ihre Infrastruktur mit Infrastructure as Code-Verfahren in einem beschreibenden Modell erstellen und verwalten. Wie beim Quellcode Ihrer Anwendungen erhalten Sie die gleichen Vorteile wie Versionierung, Prüfbarkeit, Nachvollziehbarkeit und Wiederholbarkeit, indem Sie ihn in der Versionskontrolle speichern und über eine Bereitstellungspipeline bereitstellen.

Erstellen Sie Ihre erste Ressource

Da Sie nun wissen, wo Sie Bicep in der Azure-Provisioning-Landschaft platzieren können, lassen Sie uns mit der Erstellung einer einfachen Ressource mit Bicep beginnen. Bevor Sie beginnen können, müssen Sie ein paar Tools installieren:

• Installieren Sie Visual Studio Code(Visual Studio Code herunterladen)
• Installieren Sie die Bicep-Erweiterung für Visual Studio: 'ms-azuretools.vscode-bicep'(Bicep-Erweiterung für Visual Studio)
• Installieren Sie die Azure CLI(Azure CLI Installationsanleitung)

Wir werden zum Beispiel ein Speicherkonto in Azure mit Bicep erstellen. Öffnen Sie Visual Studio Code und erstellen Sie eine neue Datei namens "storageAccount.bicep". Beginnen Sie innerhalb dieser Datei mit der Eingabe von "stor". Sie werden sehen, dass die Erweiterung Ihnen sofort beim Schreiben der Vorlagen hilft, indem sie Ihnen ein paar Schnipsel präsentiert.

Drücken Sie Enter und das Snippet wird eingefügt. Es sieht wie im folgenden Beispiel aus:

resource storageaccount 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: 'name'
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

Das Snippet beginnt mit dem Schlüsselwort resource und zeigt damit an, dass Sie eine Ressource erstellen möchten. Als nächstes folgt der Name der Bereitstellung, gefolgt von dem Ressourcentyp und der Version. Innerhalb der geschweiften Klammern finden Sie die Details der Ressource wie Name, Speicherort und SKU.

Sie haben zwar noch nicht die Maus oder die Tastatur berührt, aber Sie werden sehen, dass der Editor den Einsatznamen ausgewählt hat und Sie diesen Wert ändern können. Wenn Sie die Tabulatortaste drücken, gelangen Sie automatisch zu jeder Eigenschaft, die Sie bearbeiten können. Auch das ist ein schöner Vorteil der Erweiterung. Beachten Sie, dass die Erweiterung auch die verfügbaren Optionen für die Eigenschaften mit einem festen Satz von Optionen auflistet, wie z.B. die "Art" des Speicherkontos. Das erspart Ihnen das lästige Nachschlagen und Tippfehler.

Wenn Sie die Eigenschaften bearbeitet haben, sieht Ihre Speicherressource wie in diesem Beispiel aus:

resource stg 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: 'mystorageaccount'
  location: resourceGroup().location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

Der Name des Speicherkontos ist derzeit fest kodiert. Das ist nicht ideal, da Sie diese Vorlage für mehrere Umgebungen verwenden möchten, z. B. für Test- und Produktionsumgebungen. Die Microsoft-Namenskonvention empfiehlt, dass der Name dies widerspiegelt. In Bicep können Sie einen Parameter verwenden, um Werte, wie die Umgebung, zur Laufzeit bereitzustellen.

Definieren Sie einen Parameter wie folgt:

param env string = 'test'

Sie beginnen mit dem Schlüsselwort 'param', gefolgt von seinem Namen. Als nächstes definieren Sie den Typ, in diesem Beispiel eine Zeichenkette. Andere Optionen sind Integer, Bool, Array oder Objekt. Optional können Sie einen Standardwert wie 'test' im obigen Beispiel festlegen. Dasselbe können Sie für die Eigenschaft Standort des Speicherkontos tun oder eine Funktion wie im vorherigen Beispiel verwenden, um den Standort aus der Ressourcengruppe, in der es sich befindet, zu ermitteln.

Neben Parametern können wir auch Variablen für Werte verwenden, die Sie in Ihren Vorlagen wiederverwenden möchten, die aber nicht zur Laufzeit bereitgestellt werden. Das Erstellen einer Variablen, die den Namen des Speicherkontos enthält, sieht folgendermaßen aus:

var storageAccountName = 'stordemo${env}'

Beachten Sie, wie Sie die String-Interpolation verwenden können, um 'stordemo' mit dem Parameter 'env' in der Variablen zu kombinieren. Das Ergebnis der Verwendung beider Parameter und einer Variablen sehen Sie unten:

param env string = 'test'
param location string = 'westeurope'

var storageAccountName = 'stordemo${env}'

resource stg 'Microsoft.Storage/storageAccounts@2021-04-01' = {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Standard_LRS'
  }
}

Eine weitere interessante Funktion, die Sie hinzufügen können, ist die Verwendung des Schlüsselworts output. Damit können Sie z.B. die URL des Blob-Endpunkts auf dem Speicherkonto zurückgeben. Die Definition eines Outputs sieht wie folgt aus:

output blobEndpoint string = stg.properties.primaryEndpoints.blob

Die Definition einer Ausgabe ist ähnlich wie die Definition eines Parameters. Es wird das Schlüsselwort output verwendet und ihm wird ein Name gegeben: 'blobEndpoint'. Sie legen den Typ fest und geben dann einen Wert an. Beachten Sie, wie Sie den Namen des Deployments und die Punktschreibweise verwenden können, um die Eigenschaften einer Ressource zu erhalten.

Deployment

Nachdem Sie nun die erste Ressource geschrieben haben, können wir sie in Azure bereitstellen. Das Lustige daran ist, dass Azure selbst Bicep überhaupt nicht kennt. Azure versteht die guten alten ARM-Vorlagen, so dass Ihre Bicep-Vorlage in eine ARM-Vorlage umgewandelt und in Azure bereitgestellt wird. Sie können diese Transpilierung selbst vornehmen, aber die Azure CLI unterstützt auch die direkte Bereitstellung einer Bicep-Datei und übernimmt die Transpilierung für Sie. Lassen Sie uns die Transpilierung durchführen, um das Ergebnis mit der Azure CLI zu sehen. Ausführen:

az bicep build -f storageAccount.bicep

Die Ausgabe ist die folgende ARM-Vorlage:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {
    "_generator": {
      "name": "bicep",
      "version": "0.4.1008.15138",
      "templateHash": "7691361711088743744"
    }
  },
  "parameters": {
    "env": {
      "type": "string",
      "defaultValue": "tst"
    },
    "location": {
      "type": "string",
      "defaultValue": "westeurope"
    }
  },
  "functions": [],
  "variables": {
    "storageAccountName": "[format('stordemo{0}', parameters('env'))]"
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2021-04-01",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "kind": "StorageV2",
      "sku": {
        "name": "Standard_LRS"
      }
    }
  ],
  "outputs": {
    "blobEndpoint": {
      "type": "string",
      "value": "[reference(resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))).primaryEndpoints.blob]"
    }
  }
}

Sie sehen sofort, dass die ARM-Vorlage fast dreimal so groß ist wie das Bicep-Pendant! Sie werden wahrscheinlich auch zustimmen, dass die Bicep-Version viel besser lesbar ist als das JSON in dieser ARM-Vorlage. Das sind nur einige der Vorteile, die die Verwendung von Bicep gegenüber ARM-Vorlagen bietet.

Wir werden die Azure CLI für die Bereitstellung verwenden. Zunächst müssen Sie sich anmelden und mit den folgenden Befehlen das richtige Abonnement auswählen:

az login
az account set -s 

Da jede Ressource in Azure in einer Ressourcengruppe lebt, müssen Sie diese zunächst erstellen. Später werden wir sehen, wie Sie eine solche mit Bicep erstellen. Verwenden Sie vorerst die Azure CLI:

az group create -l westeurope -n rg-bicepdemo-test

Jetzt, wo Ihre Ressourcengruppe fertig ist, können Sie die Vorlage mit dem folgenden Befehl bereitstellen:

az deployment group create --resource-group rg-bicepdemo-test --template-file storageAccount.bicep

Wenn Sie keine Werte für die Parameter angeben, werden die Standardwerte der Vorlage verwendet. Der folgende Befehl zeigt, wie Sie bei der Bereitstellung der Vorlage einen Parameter angeben. Die Übergabe von Parametern ermöglicht es Ihnen, die Vorlage wiederzuverwenden und mehrere Umgebungen anzusteuern.

az deployment group create --resource-group rg-bicepdemo-test 
    --template-file storageAccount.bicep  
    --parameters '{ "env": { "value": "prod" } }'

Öffnen Sie nun das Azure-Portal und überprüfen Sie, ob das Speicherkonto erstellt wurde.

Modularisieren Sie Ihre Bicep-Vorlage

Wenn Sie der Datei, die wir gerade erstellt haben, weiterhin Ressourcen hinzufügen, wird sie immer größer werden. Schließlich wird es immer schwieriger, sie zu lesen und zu pflegen, und es wird immer schwieriger, die Vorlage wiederzuverwenden. Zum Glück gibt es in Bicep das Konzept der Module. Mit Modulen können Sie Ihre Vorlage in kleinere, wiederverwendbare Teile aufteilen. Die Vorlage, die Sie gerade erstellt haben, ist ein hervorragendes Beispiel dafür, was in einem Modul enthalten sein kann. Lassen Sie uns nun die Ressourcengruppe, die Sie manuell mit der Azure CLI erstellt haben, mit Bicep erstellen und sehen, wie wir die Speicherkonto-Vorlage als Modul verwenden können. Beginnen Sie damit, eine neue Datei mit dem Namen "main.bicep" zu erstellen, und fügen Sie das folgende Snippet in die Datei "main.bicep" ein, um die Ressourcengruppe zu erstellen:

param env string = 'test'
param location string = 'westeurope'

resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: 'rg-bicepdemo-${env}'
  location: location
}

Das obige Snippet erstellt eine Ressourcengruppe, deren Bereitstellung 'rg' genannt wird. Nachdem Sie das getan haben, werden Sie feststellen, dass VS Code einen Fehler für die oben genannte neue Ressource anzeigt. Standardmäßig wird eine Bicep-Vorlage im Rahmen einer Ressourcengruppe bereitgestellt. Wie Sie vielleicht wissen, gibt es in Azure verschiedene Ebenen, auf denen wir Ressourcen bereitstellen können. Wir nennen diese die Bereitstellungsbereiche. Auf der obersten Ebene haben Sie Ihren Azure Tenant. Dieser kann eine oder mehrere Verwaltungsgruppen enthalten. Diese können ein oder mehrere Abonnements enthalten, und jedes Abonnement kann eine oder mehrere Ressourcengruppen enthalten. Die Ressourcengruppen schließlich enthalten die eigentlichen Ressourcen wie virtuelle Maschinen, eine Web-App oder ein Speicherkonto. Diese Hierarchie ermöglicht es Ihnen, Ihre Ressourcen auf strukturierte Weise zu gruppieren und zu verwalten und ist in der folgenden Abbildung dargestellt.

Sie erhalten die obige Fehlermeldung, da Sie keine Ressourcengruppe innerhalb einer Ressourcengruppe erstellen können; der Einsatzbereich ist falsch. Eine Ressourcengruppe muss im Bereich des Abonnements bereitgestellt werden. Fügen Sie daher die folgende Zeile am Anfang der Datei "main.bicep" hinzu:

targetScope = 'subscription'

Der Fehler sollte verschwinden. Um die Speicherkontodatei als Modul zu verwenden, verwenden Sie das Schlüsselwort "module" anstelle des Schlüsselworts "resource". Sie geben dem Modul einen Namen, wie Sie es bei der Verwendung des Schlüsselworts 'resource' tun. Anstatt einen Typ anzugeben, referenzieren Sie nun das soeben erstellte Modul über seinen Pfad. Beginnen Sie unterhalb der Ressourcengruppe mit der Eingabe von 'module stg', und VS Code sollte Ihnen alle verfügbaren Module anzeigen:

Wählen Sie das storageAccount.bicep. Geben Sie '= ' ein und wählen Sie dann die Option 'required-properties' in der Dropdown-Liste.

Das generierte Snippet sieht wie folgt aus:

module stg 'storageAccount.bicep' = {
  scope: rg
  name: 'storage'
}

In der ersten Zeile dieses Moduls finden Sie 'scope'. Hier legen Sie fest, in welchem Bereich dieses Modul bereitgestellt werden soll. Denken Sie daran, dass die Vorlage "main.bicep" auf den Abonnementbereich abzielt, ein Speicherkonto aber nur innerhalb einer Ressourcengruppe bereitgestellt werden kann. Mit der Eigenschaft scope können Sie dies festlegen. Dazu verwenden Sie einfach den Namen der Ressourcengruppe, die Sie zuvor deklariert haben, wie folgt:

module stg 'storageAccount.bicep' = {
  scope: rg 
  name: 'storage'
}

Denken Sie daran, dass das Speicherkonto auch zwei Parameter hat. Sie wurden nicht hinzugefügt, als Sie das Modul mit der Option 'required-properties' erstellt haben, da sie einen Standardwert haben. Sie können ihnen einen Wert übergeben, indem Sie params im Modul wie folgt angeben:

module stg 'storageAccount.bicep' = {
  scope: rg
  name: 'storage'
  params: {
    env: 'prod'
  }
}

Die Bereitstellung dieser Vorlage unterscheidet sich geringfügig von der vorherigen Bereitstellung von storageAccount.bicep. Da wir jetzt auf den Abonnementbereich abzielen, müssen Sie diesen im Befehl angeben. Der Befehl lautet nun wie folgt:

az deployment sub create --template-file main.bicep -l westeurope

Beachten Sie, dass Sie anstelle von group nun sub verwenden, um den unterschiedlichen Einsatzbereich anzugeben. Wenn Sie den Befehl ausführen, sollte er erfolgreich sein, und das Ergebnis in Azure sollte dasselbe sein, da die Ressourcengruppe und das Speicherkonto bereits existieren.

In diesem Artikel haben Sie gelernt, wie einfach der Einstieg in Bicep ist, um Ihre erste Ressource zu erstellen und bereitzustellen. Sie haben auch erfahren, wie Sie ein Modul erstellen, um kleine, wiederverwendbare und wartbare Bicep-Vorlagen zu erstellen. Wenn Sie mehr darüber erfahren möchten, wie Sie diese Module in Ihrem Unternehmen gemeinsam nutzen können, sollten Sie sich den Artikel '' von Erick Segaar an anderer Stelle in diesem Magazin ansehen.

Möchten Sie mehr über Infrastructure as Code auf Azure erfahren? Erwin hat zusammen mit zwei Freunden ein Buch darüber geschrieben! Darin geht es um ARM-Vorlagen und natürlich um Bicep. Es zeigt, wie Sie diese Vorlagen mithilfe von Azure DevOps oder GitHub Actions bereitstellen, spricht über die gemeinsame Nutzung von Vorlagen im gesamten Unternehmen, wie Sie Ihre Azure-Umgebung mithilfe von Azure Policy verwalten und vieles mehr. Erfahren Sie mehr und kaufen Sie das Buch unter Azure Infrastructure as Code.

Infrastruktur als Code mit Bicep

Heutzutage ist es sehr üblich, dass wir unsere Software vollautomatisch in verschiedenen Umgebungen einsetzen. Das ist zum Standard geworden. Bei der Infrastruktur, auf der diese Anwendungen laufen, ob in der Cloud oder vor Ort, scheint das weniger der Fall zu sein. Die Infrastruktur wird häufig manuell erstellt und gewartet, und das wird in wettbewerbsintensiven Märkten oder stark regulierten Umgebungen schnell zum Problem. Ohne Automatisierung kommt es im Laufe der Zeit zu einem Abdriften der Umgebung. Jede Umgebung wird etwas anders konfiguriert und kann nicht automatisch reproduziert werden. Diese Inkonsistenzen zwischen den Umgebungen führen zu Problemen bei der Anwendungsbereitstellung, verursachen Ausfälle und machen es sehr schwer, Fehler zu finden, da sich jede Umgebung ein wenig anders verhält. Infrastructure as Code (IaC) kann helfen, solche Probleme zu lösen. Es ist die Verwaltung der Infrastruktur in einem deskriptiven Modell, das die gleichen Versions- und und Bereitstellungsprinzipien wie sie DevOps-Teams für Quellcode verwenden. Die Infrastruktur ist in gut dokumentierten, lesbaren Sprachen geschrieben. Sie ist leicht zu überprüfen und zu überdenken. Insbesondere in Cloud-Umgebungen ermöglicht dies den Teams, schnell zu iterieren und ihre Änderungen schnell und zuverlässig bereitzustellen. Es gibt den Teams die Möglichkeit, eine völlig neue und separate Umgebung für einfache und isolierte Tests zu schaffen, die sie in Minutenschnelle auf- und abbauen können.

Es gibt verschiedene Tools zur Erstellung von Infrastrukturen mit IaC. Letztes Jahr hat Microsoft ein weiteres angekündigt: Bicep. Es ist der Nachfolger der ARM-Vorlagen und hat viele Vorteile. ARM-Vorlagen sind in JSON geschrieben. Das macht sie schwer zu schreiben, zu lesen und somit auch zu pflegen. Sie neigen dazu, recht schnell sehr groß zu werden, und es ist schwierig, sie zur Wiederverwendung in mehrere Dateien aufzuteilen.

Bicep hingegen ist eine domänenspezifische Sprache (DSL), die leicht zu erlernen, zu schreiben und zu lesen ist. Die Aufteilung von Vorlagen in Module ist sehr einfach und ermöglicht die Erstellung von wiederverwendbaren Komponenten und einer wartbaren Infrastruktur. Die Bereitstellung ist mit branchenüblichen Tools einfach, und der Support ist in den Standard-Supportplänen für Azure enthalten.