Projekt Bicep, die ARM-DSL von Microsoft

*Aktualisierter Beitrag mit den neuesten verfügbaren Nachrichten

Was ist das Projekt Bicep?

Bicep ist die DSL (Domain Specific Language) zur deklarativen Bereitstellung von Azure-Ressourcen. Sie zielt darauf ab, die Erfahrung zu vereinfachen, die wir derzeit mit ARM-Templates für die Bereitstellung von Azure-Ressourcen machen, mit einer saubereren Syntax, Modularität und Wiederverwendbarkeit.

Es bietet eine transparente Abstraktion über ARM-Templates (wir wissen, dass ARM-Templates nicht die am einfachsten zu erstellenden sind), alle Dinge, die wir bisher (und in Zukunft) mit ARM-Templates machen können, können mit Bicep gemacht werden (mit Ausnahme von bekannten Einschränkungen, von denen Microsoft erwartet, dass sie in weiteren Versionen gelöst werden). Es ist jedoch für den Produktionseinsatz bereit. Mit Hilfe von Bicep und einigen der in diesem Beitrag vorgestellten Werkzeuge ist es nun viel einfacher, ARM-Vorlagen zu erstellen.

Daher wollte ich eine einfache Einführung machen, weil ich es nützlich finde, etwas über diese neue DSL, ihre Einfachheit und ihre Funktionen gegenüber herkömmlichen ARM-Templates zur Bereitstellung von Azure-Ressourcen zu erfahren. Sie wird es Entwicklern ermöglichen, ARM-Vorlagen schneller und einfacher als je zuvor zu erstellen.

Warum sollte ich mich für Bicep interessieren?

Es gibt bereits Alternativen wie Terraform, Pulumi, und andere IaC-Angebote, um die Komplexität von ARM-Templates zu vermeiden… Nun, ich möchte zugeben, dass ich Terraform für Azure in einigen Projekten verwendet habe und sehr zufrieden damit bin, seine Azure-Provider sind wirklich großartig, aber in einigen Fällen, mit neuen Azure-Funktionen, Produkten oder Konfigurationen, müssen wir darauf warten, dass der Provider diese Änderungen implementiert (oder sie sind in absehbarer Zeit nicht verfügbar, wie die Azure Portal Integration). Die Verwendung des „AzAPI Provider“ anstelle des „AzureRM Provider“ löst die Wartezeit, bis der Provider die Unterstützung für die neuesten Änderungen in Azure implementiert. Wenn wir den „AzAPI Provider“ verwenden, nutzen wir dieselbe API, die Bicep für die Bereitstellung von Ressourcen verwendet. Dennoch müssen wir uns mit dem Terraform-Status auseinandersetzen, ohne Azure Portal-Integration und ohne einige Integrationsfunktionen wie Azure Policies.

Stattdessen ist Bicep seit der Version 0.3 in allen Azure Support Plänen enthalten. Da es direkt in Standard-ARM-Template-JSON-Dateien kompiliert wird und von Microsoft unterstützt und gesichert wird, sollten alle neuen Funktionen, Produkte und Konfigurationen sofort verfügbar sein (was sehr beruhigend ist), ebenso wie eine großartige Azure-Portal-Integration und eine bessere Integration.

Azure Resource Manager Architekturschema (Auszug aus „Project Bicep Demo at Ignite 2020 by Mark Russinovich“)

Meiner Meinung nach ist es für Entwickler, die Ressourcen auf Azure bereitstellen, einen Versuch wert. Es ist jedoch wichtig zu betonen, dass es keinen Grund gibt, auf Bicep umzusteigen, wenn Sie bereits Terraform oder einen anderen IaC-Anbieter verwenden, da die Anbieter sich sehr bemühen, dass sie gut mit Azure zusammenarbeiten, und Microsoft selbst unterstützt diese Bemühungen. Die Realität ist, dass es so viele Projekte gibt, die ARM-Templates verwenden, und Microsoft versucht, die Verwaltung zu vereinfachen und sein eigenes Tooling bereitzustellen, um mit IaC zu beginnen (ohne von dritten Quellen abhängig zu sein).

Bicep vs. Terraform

Was sind die Unterschiede zwischen Bicep und Terraform? Beides sind zwei führende IaC (Infrastructure as Code) Angebote. Was die Infrastruktur, die Integration und die Benutzerfreundlichkeit angeht, haben beide sehr benutzerfreundliche Funktionen, was sie in einigen Aspekten sehr ähnlich macht. Ein wichtiges Konzept, das man kennen sollte, ist, dass es bei der Verwendung von Bicep im Vergleich zu Terraform keine wichtigen Benutzerfreundlichkeitsmerkmale gibt.

Ihre Infrastruktur und Integrationsfunktionen erleichtern Entwicklern die Implementierung von IaC-Lösungen. Die einzige wichtige Entscheidung, die Sie treffen müssen, ist die, ob Sie mehr als einen Cloud-Anbieter nutzen wollen (oder ob Ihre Infrastruktur aus einer Multi-/Hybrid-Cloud-Umgebung bestehen wird). Wenn ja, dann ist Terraform am besten für Sie geeignet, da Bicep ausschließlich für Azure-Ressourcen gedacht ist.

Bei einem detaillierteren Vergleich gibt es einige wichtige Unterschiede, die wir kennen sollten:

In Bezug auf die Integration und die Infrastruktur

• State und Backend: Beides ist eine gewünschte Zustandskonfiguration (DSC). Allerdings speichert Terraform Status- und Konfigurationsinformationen, Bicep hingegen nicht. Diese Informationen werden von Terraform verwendet und können in einer lokalen Datei oder remote (zum Beispiel in einem Azure Storage Container) gespeichert werden. Bicep hingegen setzt auf eine inkrementelle Bereitstellung.
• Infrastrukturziele: Bicep ist Azure-spezifisch und nicht für die Arbeit mit anderen Cloud-Diensten ausgelegt. Mit Terraform können wir mit verschiedenen Cloud-Diensten arbeiten: AWS, Azure, Google Cloud… und die Liste geht weiter.
• Tooling: Terraform verwendet seine eigene CLI, während Bicep in die Azure CLI integriert ist (mit az bicep und az deployment). Beachten Sie, dass Bicep auch als separates CLI-Tool verwendet werden kann.
• Verarbeitung: Mit Bicep erfolgt die Verarbeitung innerhalb der Kerninfrastruktur von Azure auf der Service-Seite. Mit Terraform erfolgt die Verarbeitung innerhalb des Terraform-Clients, was keine Aufrufe an Azure beinhaltet, um die erforderlichen Änderungen zu bestimmen (unter Verwendung des gespeicherten Status).
• Authentifizierung: Bicep verwendet ein Autorisierungs-Token, das während der Anfrage zur Übermittlung einer Datei oder Vorlage bereitgestellt wird. Terraform hingegen authentifiziert sich auf der Grundlage von Provider-Anmeldeinformationen (Azure CLI, Service Principal oder verwaltete Identitäten).
• Auf Azure: Bicep bietet eine bessere Integration mit Azure-Funktionen, wie z.B. Azure Policy, die zuvor ausgewertet werden, um festzustellen, ob eine Ressource durch eine Policy verweigert wird und das Deployment fehlschlägt. In diesem speziellen Fall wird Terraform beim Deployment der Ressource fehlschlagen.
  • Portalintegration: Einer der Hauptvorteile bei der Arbeit mit Bicep in Azure ist die Möglichkeit, Portalaktionen zu automatisieren. Sie können das Azure-Portal nutzen, um Vorlagen zu exportieren und später zu verwenden, was uns hilft, zu verstehen, wie man es mit Bicep (und allen seinen möglichen Parametern) macht. Terraform bietet nicht die gleiche Portalintegration wie Bicep. Dennoch können wir mit anderen Tools wie Azure Terrafy eine bestehende Azure-Infrastruktur unter Terraform-Verwaltung stellen.
• Out-of-band-Änderungen: Wenn Sie Änderungen an der Infrastruktur außerhalb des Kontextes des Tools vornehmen, müssen Sie diese mit Bicep und dem ARM-Vorlagencode abstimmen (um zu vermeiden, dass diese Änderungen beim nächsten Einsatz überschrieben werden). Im Falle von Terraform müssen Sie diese Änderungen in den Terraform-Status importieren und die Terraform-bezogenen Dateien aktualisieren (was manchmal mühsam sein kann).
• Cloud-Frameworks: Bicep vereinfacht den Prozess für die Bereitstellung von Landing Zones mit einem Portal, das auf ARM-Vorlagen und Landing-Zone-Implementierung basiert. Terraform verwendet ein Enterprise-Scale-Landing-Zones-Modul für die Bereitstellung, Verwaltung und den Betrieb mit Azure.

Benutzerfreundlichkeit

• Sprache: Bicep und Terraform sind einfach zu verwendende, domänenspezifische Sprachen (DSL). Beide haben ähnliche Schlüsselwörter und Konzepte wie Parametrisierung, Multi-File-Projekte, externe Module… Terraform bietet jedoch eine integrierte Funktionalisierung für bestimmte Aufgaben. Beide sind deklarative Sprachen und bieten Sprachhilfen zur Vereinfachung von Kodierungsaufgaben. Außerdem kann die Code-Erstellung mit Hilfe von Erweiterungen für die IDE Ihrer Wahl (z. B. bieten beide Add-ins für Visual Studio Code) sehr angenehm sein.
• Module: Sowohl Bicep als auch Terraform unterstützen das Konzept der Module, mit denen Sie wiederverwendbare Komponenten aus Ihrem Code erstellen können.
• Lebenszyklus der Bereitstellung: Sowohl Bicep als auch Terraform ermöglichen es, die Konfiguration vor der Bereitstellung zu validieren und dann die gewünschten Änderungen anzuwenden (mit Terraform Plan oder Bicep What-if Operation). Terraform bietet jedoch mehr Flexibilität, um alle entfernten Objekte zu zerstören, die von einer bestimmten Konfiguration verwaltet werden.
• Einstieg: Der Einstieg in Bicep oder Terraform ist einfach und unkompliziert: Beide bieten Ressourcen, die Ihnen helfen. Für Bicep können Sie Microsoft Learn und die Dokumentation in Microsoft Docs nutzen. Im Falle von Terraform können Sie HashiCorp Learn und die Dokumentation in Terraform docs einsehen.
• Azur Azure: Bicep hat einen klaren Vorteil gegenüber Terraform, wenn es um Azure und die Konfiguration von Azure-Ressourcen geht. Bicep ist stärker in die Azure-Dienste integriert und unterstützt sofort neue Azure-Funktionen. Mit Terraform haben wir zwei Hauptanbieter, mit denen Benutzer Azure verwalten können:
  • AzureRM: eine stabile Erfahrung für Azure-Dienste, mit einer kleinen Verzögerung bei neuen Azure-Funktionen.
  • AzAPI: eine Schicht über den Azure ARM REST APIs, die sofortige Unterstützung für Azure-Funktionen ermöglicht.
• Community und Support: Beide Communities bieten ein hohes Maß an Engagement und Support.
  • Für Bicep gibt es Bicep-Dokumentation auf den Microsoft Docs und die Möglichkeit, den Bicep-Quellcode auszuchecken und Bugs zu melden.
  • Für Terraform gibt es Terraform-Dokumentation in den Microsoft Docs, die Möglichkeit, Provider-Quellcode auszuchecken und Bugs zu melden, Antworten auf Terraform-Kernfragen und Terraform-Provider-bezogene Fragen zu erhalten.

Berücksichtigen Sie die vorstehenden Konzepte (und Ihre Infrastrukturanforderungen und -präferenzen), um die beste Wahl für Ihr Unternehmen zu treffen.

Einstieg mit Project Bicep

Die ersten Schritte sind sehr einfach. Wir benötigen nur das Azure CLI. Es liegt an Ihnen, andere Tools zu installieren (CLI, die VS-Code-Erweiterung, etc.). Der Prozess für diese Tools ist einfach und in ihrem Repository dokumentiert. Beachten Sie, dass es auch ein Bicep PowerShell Modul gibt, wenn wir einen großartigen Wrapper für die Bicep CLI in PowerShell haben wollen.

Der nächste Schritt ist, sich mit Bicep und seiner Syntax vertraut zu machen. Ein guter Startpunkt ist das offizielle Tutorial. Es gibt auch großartige Ressourcen, um Bicep auszuprobieren, wie den Bicep Playground und das Visual Studio Code Devcontainer/Codespaces repo.

Nach diesem Prozess und nachdem wir eine Weile gespielt haben, sollten wir bereit sein, es zu benutzen und unsere Azure Deployment Templates zu erleichtern.

Projekt Bicep Schema (Auszug aus „Project Bicep Demo at Ignite 2020 by Mark Russinovich“)

Interpretiert man das obige Schema, wäre der Prozess so einfach wie:

bicep build my-deployment.bicep # Nur dieser zusätzliche Schritt

az deployment group create my-deployment.json

Aber wir können diesen zusätzlichen Schritt überspringen! Denn sowohl Az CLI (2.20.0+) als auch das PowerShell Az Modul (v5.6.0+) haben Bicep Unterstützung eingebaut:

az deployment group create my-deployment.bicep

Mit Bicep vereinfachen wir den Prozess der Erstellung von ARM-Vorlagen erheblich und erhalten viele Vorteile. Einer davon, den ich sehr interessant finde, ist die Möglichkeit, separate Bicep-Dateien zu erstellen, um eine einzige ARM-Datei zu generieren, also die Modularitätsfunktion.

Werfen wir einen kurzen Blick auf die Unterschiede zwischen einer Bicep- und einer ARM-Datei (die gleichwertig sind), von einer einfachen Schnellstartvorlage aus dem Azure Repo:

Deployment einer einfachen SQL-Datenbank in nur der Hälfte der Zeilen viel lesbarer (Links: Bicep. Rechts: ARM)

Sieht einfach aus und ist es auch, aber…

Wie konvertiert man ARM-Vorlagen in das Bicep-Format?

Es gibt zwei verschiedene Ansätze:

• Es gibt ein Cheat-Sheet zum Vergleich der ARM-Vorlagensyntax und der nativen Bicep-Entsprechung. Dieses Dokument sollte es uns ermöglichen, bestehende ARM-Templates in das Bicep-Äquivalent zu konvertieren und damit zu beginnen, sie zu vereinfachen und ihre Funktionen zu nutzen.
• Die ‚decompile‘ Option, die in der Bicep CLI verfügbar ist. Diese Option ist wirklich großartig und funktioniert normalerweise sehr gut. Da es keine garantierte Konvertierung von JSON nach Bicep gibt, kann die Dekompilierung fehlschlagen, oder es können Fehler/Warnungen in der generierten Bicep-Datei zurückbleiben, die behoben werden müssen. Es ist jedoch der einfachste Weg, Bicep-Dateien aus unseren ARM-Dateien zu erhalten. Es ist so einfach wie das Ausführen von: bicep decompile my-arm-template.json oder az bicep decompile my-arm-template.json.

Dennoch ist es wichtig zu betonen, dass, da Bicep zu ARM-Templates kompiliert, wir auch Bicep und ARM-Templates gleichzeitig existieren lassen könnten und die Templates inkrementell konvertieren oder die alten als Standard-ARM-Templates belassen könnten (je nach Wunsch des Entwicklers).

Der Ansatz in unserem Deployment-Prozess wird fast derselbe sein, da wir nur einen zusätzlichen Schritt in unserem Deployment-Prozess einführen: die Kompilierung von Bicep-Dateien in ihr JSON-ARM-Template-Äquivalent, bevor wir die ARM-Templates deployen.

Unterstützung von Bicep in unseren Continuous Deployment Pipelines

Da es sich bei Bicep „nur“ um ein Tool handelt, könnten wir die Kompilierung von Bicep-Dateien in fast jeder Umgebung leicht implementieren. Ein einfacher und generischer Ansatz wäre es, das Binary von den GitHub-Releases herunterzuladen und das Binary mit unseren Bicep-Dateien in JSON auszuführen. Dies ist jedoch, wie bereits erwähnt, mit den neueren Versionen von Azure CLI und dem PowerShell Az-Modul überhaupt nicht mehr notwendig.

Während es einfach ist, diesen generischen Ansatz zu implementieren, fangen die Community und Microsoft selbst an, uns die notwendigen Erweiterungen, Pakete und Aktionen zur Verfügung zu stellen, um das Bicep-Tooling (wenn wir es brauchen) in unsere Pipelines einzubinden.

Azure DevOps Pipelines

Für Azure DevOps Pipelines habe ich bereits einige Aufgaben implementiert, um den Prozess für Bicep zu abstrahieren und zu vereinfachen, die in der README des offiziellen Projekts oder auf dem Visual Studio Marketplace zu finden sind.

Wer jedoch keine Erweiterungen von Drittanbietern in seine Azure DevOps-Organisation einbinden möchte, kann eine eigene Pipeline erstellen (und das Tooling selbst herunterladen).

GitHub Actions

Es gibt eine von der Community entwickelte GitHub Action, um Bicep in unseren Deployment-Prozess einzubinden, wenn wir GitHub Actions verwenden. Wie im Abschnitt Azure DevOps Pipelines erwähnt, können wir unsere eigene Action implementieren (indem wir das Tooling selbst herunterladen).

Andere CI/CD-Umgebungen

Bicep ist nur eine Binärdatei, die plattformübergreifend laufen kann. Daher denke ich, dass es heutzutage in jeder CI/CD-Umgebung kein Problem wäre, einen zusätzlichen Schritt zur Handhabung von ‚.bicep‘-Dateien einzuführen. Beachten Sie, dass dies nur für die Bereitstellung überhaupt nicht notwendig ist.

Es wäre nur eine ausführbare Datei, die bei jedem Lauf heruntergeladen oder in unserer Umgebung gespeichert werden könnte, die wir gegen eine Reihe von ‚.bicep‘-Dateien ausführen müssen.

Es gibt wirklich keinen Grund, sich mit Microsoft Bicep anzufreunden…

Es gibt noch viel mehr zu entdecken (und es werden noch weitere Funktionen hinzukommen!), aber vorerst möchten wir Ihnen diese Reihe erster Konzepte vorstellen, damit Sie testen können, was Project Bicep zu bieten hat.