Nach links schieben mit Bizeps

Gesegnete Vorlagen

Es ist eine gute Praxis, einige Bausteine von gesegneten Vorlagen für die Infrastruktur in vielen Organisationen anzubieten. Ein Cloud Competence Center of Excellence bietet diese Vorlagen in der Regel an. Durch die Art der Kontrolle liegt der Schwerpunkt in erster Linie auf den Bereichen Sicherheit, Architektur und Governance, Engineering Enablement und Operational Excellence. [ Das bedeutet, dass es einfach ist, die gesegneten Vorlagen zu verwenden, und dass keine Fragen gestellt werden. Wenn Sie von den gesegneten Vorlagen abweichen möchten, müssen Sie dies erklären und einen Prüfungsausschuss durchlaufen. Die Vorlagen werden in der Form gesegnet, die die beteiligten Parteien bereits für die Verwendung genehmigt haben. Viele Teams werden in der Lage sein, ihre Lösungen auf der Grundlage dieser Vorlagen zu erstellen.

Die Verwaltung von Änderungen an den gesegneten Vorlagen kann eine kleine Herausforderung sein. Wie patchen wir sie bei einer Sicherheitslücke effizient auf allen Ressourcen? Was ist, wenn ein Produktteam zum nächsten Projekt übergegangen ist und das vorherige Projekt nicht mehr aktiv unterstützt? Woher sollen die Teams wissen, ob sie ihre Infrastruktur ändern oder neu bereitstellen müssen? Die Effektivität steht und fällt mit der Bequemlichkeit, mit der sich die Teams an die Vorgaben halten können. Wie einfach ist es, die Teams zu erreichen, die Ihre Vorlage verwenden, und wie einfach ist es, die Vorlage zu ändern und neu zu implementieren.

In diesem Artikel erfahren Sie, warum Sie Ihre gesegneten Vorlagen weiterverwenden oder ganz einfach in Bicep-Dateien konvertieren und von deren Vorteilen profitieren können. Für weitere Informationen über die allgemeine Verwendung von Bicep sollten Sie den Artikel "" von Erwin Staal in derselben Zeitschrift lesen.

Mit den modularen Verbesserungen, die in Bicep v0.4.1008 eingeführt wurden, um die Bicep-Registrierung zu unterstützen, können Sie die Unterstützung von gesegneten Vorlagen für Ihre Kunden verbessern und eine Validierung zur Kompilierzeit durchführen, um vollständige CI/CD-Szenarien für Ihre IAC (Infrastructure As Code) zu unterstützen. Schauen wir uns an, wie sich dies auf die Benutzerfreundlichkeit und den Lebenszyklus von Blessed Templates auswirkt.

Basic Bizeps Einsatz

Um zu verstehen, welchen Wert die Verwendung einer Bicep-Registrierung für Ihre Vorlagen hat, müssen wir zunächst verstehen, wie die Dinge ohne Vorlagen funktionieren, wie im folgenden Diagramm dargestellt.

 

Abbildung 1. Grundlegender Einsatz des Bizeps

Eine relativ standardmäßige CI/CD-Pipeline für die Infrastruktur, die in Bicep geschrieben wurde und bei der Sie keine Vorlagen verwenden:

1. Ein Ingenieur nimmt eine Änderung an einer Bicep-Datei in Git vor
2. Wenn Sie die Änderung pushen, wird automatisch eine Pipeline ausgelöst
3. Der erste Schritt in der Pipeline besteht darin, die Bicep-Vorlage in eine ARM-Vorlage zu transpilieren und diese als unveränderliches Artefakt zur späteren Verwendung zu speichern
4. Stellen Sie das Artefakt mit umgebungsspezifischen Parametern in einer Azure -ResourceGroup, -Subscription, -Tenant oder -Management Gruppe bereit.

Die Bereitstellung ist nichts anderes als die Ausführung eines az CLI-Befehls unter Verwendung der Argumente "Bereitstellungsgruppe" mit der transpilierten Bicep-Vorlagendatei, die mit dem Schalter --template-file übergeben wird, wie in der folgenden Powershell gezeigt.

Abbildung 2. Bicep für eine Ressourcengruppe bereitstellen

Vorlagen verwenden

Die Verwendung von Vorlagen hilft Ihnen, bereits erstellte Definitionen wiederzuverwenden. Wenn Sie einen Webdienst bereitstellen, möchten Sie immer Anwendungseinblicke mit einem Log-Analyse-Arbeitsbereich bereitstellen. Mithilfe von Vorlagen können Sie dies auf verschiedene Weise tun, zum Beispiel durch Verweise;

• einen (lokalen) Ordner im selben Projekt
• ein Speicherkonto in Azure
• eine vorlagenspezifische Ressource in Azure
• ein Modul in der Bicep-Registratur

Vorlagen-Spezifikation

Bevor es die Möglichkeit gab, Bicep-Vorlagen in eine Bicep-Registrierung zu verschieben, war die bevorzugte Methode zur gemeinsamen Nutzung Ihrer Vorlagen die Veröffentlichung der ARM-Vorlage in einer Template-Spec-Ressource. Unten sehen Sie eine solche Template-Spec-Ressource in Azure.

Abbildung 3. Beispiel für eine Vorlage für eine Ressource

Beachten Sie, wie dies RBAC (ein Verbraucher benötigt nur Lesezugriff), Versionierung und sogar die Versionsdokumentation nutzen kann, wenn Sie sich eine bestimmte Version ansehen. Eine Vorlagenspezifikation wird wie folgt über die CLI veröffentlicht:

Abbildung 4. Vorlagenspezifikation veröffentlichen

Eine andere Bicep-Datei kann dann diese Template-Spec-Resource verwenden, indem sie den Typ "Microsoft.Resources/deployments" mit einer "templateLink"-Eigenschaft verwendet, die auf die Template-Spec-Resource mit einer bestimmten Version verweist, wie unten gezeigt:

Abbildung 5. Einen Vorlagenlink verwenden

Der Vorlagenlink beschreibt einen vollständigen URI, einschließlich des Namens und der Version der gewünschten Ressource.

Im Vergleich zu unserer Basic Bicep Pipeline hilft Ihnen die Verwendung der "Template Specs" bereits dabei, eine gesegnete Vorlagenstruktur mit semantischer Versionierung und Release-Dokumentation zusammen mit Ihrer Vorlagendefinition zu erreichen. Die Template Specs verändern bereits den CI/CD-Flow, indem sie die gesegnete Vorlage während der Bereitstellung verwenden.

Abbildung 6. Bicep mit Hilfe von Vorlagenspezifikationen bereitstellen

Um die Wartung, Genehmigung und Verfügbarkeit kümmert sich ein separates Team, das die Möglichkeit hat, neue Vorlagen und Versionen zu veröffentlichen. Die Kunden haben nur Leserechte auf die Vorlagenspezifikation und können sie bei der Bereitstellung ihrer Ressourcen verwenden.

Die Verwendung der Template-spec als URI-Referenz, wie in Abbildung 3 gezeigt, ist etwas ungeschickt. Da es keine IntelliSense-Funktion für die Template-spec gibt, müssen Sie die Namen der Parameter kennen, um sie zu übergeben. Das Gleiche gilt für die Ausgabe der Vorlagenspezifikation. Sie müssen auch den Namen des Parameters kennen, um ihn abrufen zu können. Wir können dies verbessern, indem wir ein Modul anstelle einer Ressource verwenden. Ein Modul kann auf eine lokale Datei oder eine Vorlagenspezifikation verweisen. Um eine Vorlagenspezifikation zu verwenden, verwenden Sie das folgende Format:

module <symbolic-name>'ts/<alias>:<template-spec-name>:<version>' = {

Wenn Sie sich die Vorlage unten ansehen, sehen Sie keinen direkten Verweis auf ein Abonnement mehr:

Abbildung 7. Verwendung des Moduls template-spec

Der Verweis wird in eine Konfigurationsdatei abstrahiert, wodurch Ihre Definitionen besser lesbar und einfacher zu pflegen sind.

Abbildung 8. Konfigurieren Sie bicepconfig.json für template-spec

Sie legen die Konfigurationsdatei mit dem Namen "bicepconfig.json" im Stammverzeichnis Ihres Projekts ab. Hier können Sie die "ts" "Template Spec" definieren. Der Alias lautet in diesem Beispiel 'BlessedTemplates'. Ein weiterer Vorteil des Modulansatzes ist, dass Bicep den Link erkennt, die Definition in den lokalen Benutzerordner herunterlädt und während der Entwicklung IntelliSense zur Verfügung stellt. Die Verwendung von Parametern oder Ausgaben der Ressource wird dadurch wesentlich einfacher.

Die Verwendung von "Template Specs" birgt einige Nachteile:

• Bei der Verwendung von Vorlagenspezifikationen referenzieren Sie diese über einen Link. Dies führt dazu, dass die Validierung zum Zeitpunkt der Bereitstellung erfolgt und nicht zum Zeitpunkt der Erstellung, was ein wenig spät ist.
• Der Inhalt der Vorlagenspezifikation ist auf der Client-Seite nicht bekannt. Wenn Sie sich die ARM-Vorlage ansehen, sehen Sie nur den Verweis auf die Template-Spezifikation, nicht aber die verschachtelten Ressourcen der Spezifikation. In unserem Beispiel mit den Webdiensten würden Sie nur einen Verweis auf eine Webdienstvorlage sehen und nicht wissen, dass auch ein Anwendungseinblick und ein Arbeitsbereich für die Protokollanalyse bereitgestellt werden.

Bizeps-Register

Mit den modularen Verbesserungen, die in Bicep v0.4.1008 eingeführt wurden, können wir jetzt eine Bicep-Modulregistrierung verwenden. Diese Verbesserung ermöglicht es uns, Bicep-Module in einer Azure Container Registry zu veröffentlichen, wie im folgenden Befehl gezeigt.

az acr login --name mybicepsharedregistry.azurecr.io
bicep publish StorageAccount.bicep --target
br:mybicepsharedregistry.azurecr.io/bicep/modules/storage:0.1

Zunächst müssen Sie sich bei der Azure Container Registry anmelden und die Bicep-Datei veröffentlichen. Als Nächstes fügen Sie die Konfiguration zur bicepconfig.json hinzu und verweisen auf das Modul, wie Sie es bei der Vorlagenspezifikation getan haben. Diesmal verwenden Sie das Schlüsselwort "br". Dieses Schlüsselwort hilft Bicep zu verstehen, dass es die Module aus der bicep-Registry abrufen kann und ermöglicht so IntelliSense und die Validierung während der Kompilierung.

Abbildung 9. Konfigurieren Sie bicepconfig.json für bicep-registry

Abbildung 10. Bicep-Registrierungsmodul verwenden

Ein weiterer wesentlicher Vorteil gegenüber der Template-Spec ist, dass Sie bei der Umsetzung der Bicep-Datei in ein ARM-Template verschachtelte Templates anstelle eines Links zum Template erhalten. Eine verschachtelte Vorlage erklärt, welche Ressourcen geändert werden. Im Gegensatz dazu verweist ein Link zu einer Vorlage nur auf eine Vorlagenspezifikation, was es schwieriger macht zu verstehen, was passiert, wenn Sie ein Artefakt für die Genehmigung der Bereitstellung überprüfen. Der erste Screenshot unten zeigt zum Beispiel die Verwendung einer Vorlagenspezifikation, der zweite die Verwendung eines Moduls in der Bicep-Registrierung.

Abbildung 11. Template-spec in einem ARM-Template, das nur Ressourcen/Einsatz zeigt

Abbildung 12. Verwendung der Bicep-Registrierung in einer ARM-Vorlage, Anzeige der Ressource/Einrichtung mit allen verwendeten untergeordneten Ressourcen

Nach links schieben

Wenn Sie entweder die Template-Spec- oder die Bicep-Registrierung verwenden, erhalten Sie die ShiftLeft [2] Fähigkeit der Validierung zur Kompilierzeit anstelle der Validierung zur Bereitstellungszeit, wie unten gezeigt.

Da Bicep die ARM-Vorlagen und die Bicep-Dateien in den Ordner des lokalen Benutzers herunterlädt, erfolgt die Validierung während der Kompilierung. Die Validierung während der Kompilierung hilft Ihnen dabei, Ihre Pipeline im Build-Schritt zum Scheitern zu bringen, bevor Sie das unveränderliche Artefakt erstellen, das Sie in Ihren Umgebungen bereitstellen möchten.

Automatisierung der Abhängigkeit von Renovierungsbotschaften

Eine der Fragen, die wir uns zu Beginn dieses Artikels gestellt haben, war, wie wir Änderungen an unseren gesegneten Vorlagen verwalten und unsere Kunden in die Lage versetzen, Änderungen zu erkennen, die sie schnell bereitstellen müssen. Wir können einen Abhängigkeitsmanager wie Renovate-bot verwenden, um neue Versionen anhand von semantisch versionierten Template-Spezifikationen oder Bicep-Registrierungen zu erkennen.

Durch die Implementierung des Renovate-Bots wird der folgende Ablauf ermöglicht:

1. Renovate-bot durchsucht die Repositories des Unternehmens nach veralteten Abhängigkeiten
2. Renovate-bot sendet eine Pull-Anfrage an die Repositories, die die gesegneten Vorlagen verwenden, und ermöglicht es Ihren Kunden, die Pull-Anfrage zu genehmigen oder automatisch zu genehmigen und sicher und konform zu bleiben.
3. Die Genehmigung löst automatisch Ihre CI/CD-Pipeline aus und rollt die neuen Vorlagen in ihrer Umgebung aus.

Renovate-bot konfigurieren

Um den Renovate-bot zu nutzen, folgen Sie den Richtlinien der Website [3]. Renovate-bot kann in branchenübliche CI/CD-Tools integriert werden und läuft in einer gehosteten oder vor Ort installierten Umgebung. Der einfachste Weg, dies zu ermöglichen, ist die Installation als Service in Ihrem GitHub-Konto.

Als Team, das die gesegneten Vorlagen verwaltet, möchten Sie, dass Renovate-bot die veröffentlichten Änderungen aufgreift. Um diese Änderungen aufzugreifen, können Sie ein Beispiel wie unten gezeigt verwenden.

Um immer eine gültige Version zu haben, macht dieses Skript folgendes:

1. Holen Sie sich die aktuelle Version aus dem letzten Bicep-Registrierungsmanifest
2. Erhöhen Sie die Nebenversion, um eine neue, unbenutzte Version zu erstellen.
3. Veröffentlichen Sie den Bicep mit der aktualisierten Version in der Registrierung
4. Erstellen Sie ein GitHub-Tag für das aktuelle SHA [4], das zur Ausführung des Builds verwendet wird.

Jetzt, wo wir die Veröffentlichung in GitHub markiert haben, können wir die Renovate-Manager [5] verwenden, um eine Überschreibung für Bicep-Dateien zu konfigurieren. Renovate-Manager sind wie Paketmanager. Diese Manager wissen für eine bestimmte Ressource (z.B. Docker, Dotnet, Golang usw.), wie sie die neueste veröffentlichte Version ermitteln und mit der im Repository verwendeten Version vergleichen können. Da es keinen speziellen Manager für Bicep gibt, müssen wir unseren eigenen mit Hilfe des generischen Regex-Managers konfigurieren.

Abbildung 16. Renovate regex-manager Konfiguration

Um die Verwendung des Regex-Managers zu konfigurieren, ändern wir die renovate.json und fügen einen "regexManagers" hinzu:

1. Konfiguration, um alle *.bicep-Dateien abzugleichen. Diese Konfiguration schränkt die Konfiguration dieses Managers so ein, dass er nur in den .bicep-Dateien sucht und nicht in anderen Dateien, die Sie eingerichtet haben.
2. Definieren Sie Ihren regulären Ausdruck "matchStrings". Diese Konfiguration sucht nach der semantischen Versionierung in der Annotation "br:****". Eine reguläre Ausdrucksgruppe 'currentValue' wird die gefundene Version enthalten.
3. Konfigurieren Sie das "datasourceTemplate", damit der Regexmanager den 'currentValue' mit GitHub-Tags vergleichen kann. GitHub-tags ist eine bekannte Datenquelle [6] für renovate-bot
4. Konfigurieren Sie das GitHub-Repository für die Suche nach dem Tag in "depNameTemplate".

Das Ergebnis ist ein automatischer Pull Request, wenn eine neue gesegnete Vorlage in einem fremden Repository veröffentlicht wird.

Abbildung 17. Pull Request von Renovate

Fazit

Viele Organisationen haben bereits gesegnete Vorlagen, und ihr Erfolg hängt von der Benutzerfreundlichkeit ab. Die gesegneten Vorlagen sollten für die Organisation von Vorteil sein, um sicherzustellen, dass alle Verbraucher auf sichere und konforme Weise arbeiten. Die Verbraucher sollten sich auf den von den gesegneten Vorlagen angebotenen Service verlassen, um ihre Abhängigkeiten zu aktualisieren und die Konformität automatisch aufrechtzuerhalten. Die Nutzung dieses Dienstes sollte nicht schwer sein. Es sollte ein goldener Weg sein, der technische Fähigkeiten ermöglicht, anstatt sie einzuschränken.

Mitnehmen

• Mit Bicep können Sie die bestehenden, genehmigten Vorlagen weiter verwenden.
• Sie können IntelliSense nutzen, indem Sie bicep-configuration verwenden
• Die Verwendung von Bicep-Registrierungen ermöglicht Ihnen eine Validierung zur Kompilierzeit (die eigentlich eine Transpilierzeit ist)
• Verwenden Sie Container Registry statt Template Specs, um eine explizitere transpilierte ARM-Vorlage zu haben.
• Unterstützen Sie alle Repositories mit automatischen Abhängigkeitsupdates für Ihre gesegneten Vorlagen mit Hilfe von Pull Requests, die von renovate-bot erstellt wurden.

Die Umstellung auf die Cloud kann eine holprige Reise sein, diesich sogar verschlimmern kann wenn Sie eine DevOps-Arbeitsweise einführen. Die Credo "Sie bauen es, Sie betreiben es" wird den Teams viel Freiheit geben. Um die Kontrolle zu behalten von Cloud-Ressourcen, sehen wir viele Unternehmen, die Richtlinien, Quality Gates, und Genehmigungsverfahren. Diese Prozesse brauchen Zeit und frustrieren oft das DevOps-Team, die schnell vorankommen wollen.

Das ist der Punkt die kommt das Konzept der gesegneten Vorlagen zum Tragen. Mit gesegneten Vorlagen können Sie den DevOps-Teams sagen: Wenn Sie diese Vorlage verwenden, müssen Sie nicht alle Gates passieren, denn wir wissen, dass diese Vorlage standardmäßig sicher und konform ist. Die DevOps-Teams haben immer noch die Kontrolle, wenn Bereitstellung von die Vorlage; sie sind nicht von anderen Teams für Genehmigungen oder Gates abhängig, so dass sie können trotzdem schnell gehen.

Bicep verfügt jetzt über ein Register, in dem Sie Ihre Daten speichern können. Ihre gesegnete Vorlagen. Die DevOps Team kann diese Registry klonen und die Vorlagen verwenden um die Infrastruktur schnell bereitzustellen.

Aber was passiert, wenn sich eine der Vorlagen ändert? Durch die Änderung wird eine neue Version in der Registrierung erstellt. Was ist, wenn Änderungen in den gesegneten Vorlagen auch eine Änderung in den Anwendungen erfordern, die diese Vorlage verwenden, um zu funktionieren. Wenn Sie Tools wie Renovate, können Sie automatisch machen eine Pull-Anfrage für jedes Team stellen, das das Repository geklont hatDiese Pull-Anfrage enthält Versionshinweise und eine Erklärung, was geändert wurde. Darüber hinaus scannt Renovate die Organisation und erkennt die Repositories, die Ihre Vorlage verwenden und auf welcher Version sie sich befinden. Sie müssen keine E-Mails verschicken, um die Teams zur Aktualisierung aufzufordern, sondern sich nur an der Art und Weise orientieren, wie sie bereits arbeiten und beitragen. Also auch mit einer neuen Version, haben die Teams immer noch die Kontrolle über die Umsetzung der Änderungen.

Gesegnete Vorlagen sind eine Möglichkeit, die Kontrolle zu behalten, ohne die DevOps-Teams zu frustrieren und trotzdem sicher und konform zu sein. Bicep bietet jetzt Unterstützung für die Verwendung von Blessed-Vorlagen.

 

Referenzen:

[1] Erfüllen-oder-Erklären/ [2] Die Fähigkeit, Fehler früher in Ihrem Entwicklungszyklus zu finden [3] Renovate von Mend.io [4] "SHA" steht für Simple Hashing Algorithm. Die Prüfsumme ist das Ergebnis der Kombination aller Änderungen im Commit und der Eingabe in einen Algorithmus, der diese 40-Zeichen-Strings erzeugt. Eine Prüfsumme identifiziert einen Commit eindeutig. [5] Manager [6] Datenquellen