Ähnlich wie die Azure Resource Manager Templates dient Azure Bicep zum Generieren deklarativer Konfigurationen nach dem Infrastructure-as-Code-Prinzip. Die Beschreibungssprache funktioniert laut Microsoft sogar deutlich einfacher.
Mit Bicep stellt Microsoft eine weitere so genannte domänenspezifische Sprache (Domain-specific Language, DSL) zur Verfügung. Diese verwendet eine deklarative Syntax zum Bereitstellen von Azure-Ressourcen, ähnlich wie es „Azure Resource Manager“-Vorlagen (ARM-Templates) tun.
So lässt sich auch in einer Bicep-Datei die Infrastruktur definieren, die in Azure bereitgestellt werden soll. Diese formal in JSON verpackte Datei lässt sich dann nicht nur zur initialen Bereitstellung der Infrastruktur, sondern über den gesamten Entwicklungslebenszyklus hinweg verwenden – auch um eine Infrastruktur beispielsweise wiederholt implementieren zu können.
So gesehen besteht also kein nennenswerter Unterschied zu ARM-Templates. Laut Microsoft stellt Bicep aber mit seiner sehr präzisen Syntax, der zuverlässige Typsicherheit und der Wiederverwendbarkeit von Code das im Vergleich zu ARM-Templates bessere Toolset zum Erstellen von Infrastructure-as-Code-Lösungen dar und benennt dazu eine Reihe von Vorteilen.
Vorteile von Bicep
Bicep ist vollständig quelloffen und damit kostenlos; es gibt auch keinerlei Premium-Features und trotzdem wird die Sprache vollumfänglich vom Microsoft-Support unterstützt. Bicep unterstützt sämtliche Ressourcentypen und API-Versionen, auch alle Vorschau- und allgemein verfügbaren Versionen für Azure-Dienste direkt. Sobald ein bestimmter Ressourcenanbieter neue Ressourcentypen und API-Versionen einführt, lassen sich diese in einer Bicep-Datei verwenden.
Im direkten Vergleich mit einem ARM-Template sind Bicep-Dateien präziser und einfacher lesbar. Dazu sind laut Microsoft keinerlei Vorkenntnisse über Programmiersprachen notwendig. Wer Bicep-Dateien mit Hilfe von VS Code erstellt, profitiert zudem von zahlreichen nützlichen Funktionen, weil VS Code umfassende Typsicherheit, IntelliSense und Syntaxvalidierung mitbringt.
Natürlich lassen sich Bicep-Projekte auch modular aufsetzen und die Bereitstellung mit Hilfe von Modulen in kleinere verwaltbare Teile runterbrechen. Module ermöglichen das Wiederverwenden von Code, was letztendlich die Entwicklung vereinfacht. Bicep ist zudem bestens in zahlreiche in Azure-Diensten wie Azure Policy, Vorlagenspezifikationen oder Azure Blueprints integriert.
Ein weiterer Vorteil ist, dass die Verwaltung von Status oder Statusdateien entfällt, weil sämtliche Statusänderungen direkt in Azure gespeichert werden. So können auch mehrere Benutzer zusammenarbeiten und sich immer darauf verlassen, dass ihre Updates wie erwartet verarbeitet werden. Dabei können sie mit Hilfe eines Was-wäre-wenn-Vorgangs auch vor der eigentlichen Bereitstellung der Vorlage jederzeit eine Vorschau der zu erwartenden Änderungen anzeigen.
Arbeiten mit Bicep
Um möglichst effizient mit Bicep arbeiten zu können, sollte man dafür sorgen, dass die Umgebung für das Entwickeln und Bereitstellen von Bicep-Dateien geeignet ist. Am besten eignet sich dazu Visual Studio Code mit der entsprechenden Bicep-Erweiterung. Diese bietet neben der prinzipiellen Sprachunterstützung automatische Vervollständigung für Ressourcen. Für die Integration genügt es, in den VS Code Extension nach „Bicep“ zu suchen und auf „Installieren“ zu klicken.
Ist die Entwicklungsumgebung eingerichtet, gilt es, die Bicep CLI für die Bereitstellungsumgebung zu installieren, wahlweise für Azure CLI oder Azure PowerShell. Die Schritte unterscheiden sich, sind aber in der Azure-Dokumentation gut erläutert. Bei der Azure-CLI wird mindestens die Version 2.20.0 benötigt, was sich mittels …
az –version
… leicht überprüfen lässt. Die Installation der Bicep-CLI erfolgt dann einfach mit …
az bicep install
…, das Aktualisieren einer bestehenden Version mittels:
az bicep update
Arbeiten mit VS Code
Zurück zu VS Code. Nachdem die Erweiterung für Bicep installiert wurde, können Sie eine neue Datei mit der Erweiterung „.bicep“ anlegen. Jetzt können Sie einfach zum „resources“-Abschnitt wechseln „res.:“ tippen und sich dann anhand der Autovervollständigung die zu erstellenden Azure-Ressource aussuchen, z. B. res-storage.
Bicep erstellt dann den erforderlichen Rumpf, danach fehlen Ihnen nur noch die zugehörigen Parameter-Definitionen. Dazu fügen Sie am Anfang des Dokuments den Abschnitt …
param name
… gefolgt von einem Leerzeichen ein, damit die Autovervollständigung die verfügbaren Typen anbietet, z. B. „string“.
Fehlt noch die Location. Diese können Sie entweder als eigenen Parameter definieren wie auch den Namen des Speicherkontos, oder Sie fügen im Ressourcen-Abschnitt folgendes ein:
location: resourceGroup().location