Migrieren von Azure-Ressourcen und JSON-ARM-Vorlagen für die Verwendung von Bicep

Die Definition Ihrer Azure-Ressourcen in Bicep bietet eine Reihe von Vorteilen, z. B. einfachere Syntax, Modularisierung, automatische Abhängigkeitsverwaltung, Typvalidierung mit IntelliSense sowie eine verbesserte Erfahrung bei der Dokumenterstellung.

Bei der Migration vorhandener Azure Resource Manager-JSON-Vorlagen (ARM-Vorlagen) zu Bicep wird empfohlen, den folgenden fünfstufigen Workflow zu verwenden:

Der erste Schritt im Prozess besteht im Erfassen einer anfänglichen Darstellung Ihrer Azure-Ressourcen. Anschließend dekompilieren Sie bei Bedarf die JSON-Datei in eine Anfangsversion einer Bicep-Datei, die Sie durch Umgestalten verbessern. Wenn Sie über eine Arbeitsdatei verfügen, testen und stellen Sie bereit. Dazu verwenden Sie einen Ablauf, der das Risiko erheblicher Änderungen an Ihrer Azure-Umgebung möglichst gering hält.

In diesem Artikel wird dieser empfohlene Workflow zusammengefasst. Weitere Anleitungen finden Sie im Learn-Modul Migrieren von Azure-Ressourcen und JSON-ARM-Vorlagen für die Verwendung von Bicep.

Phase 1: Konvertieren

In der Konvertierungsphase der Migration Ihrer Ressourcen zu Bicep besteht das Ziel darin, eine anfängliche Darstellung Ihrer Azure-Ressourcen zu erfassen. Die Bicep-Datei, die Sie in dieser Phase erstellen, ist nicht vollständig und kann noch nicht verwendet werden. Die Datei bietet Ihnen jedoch einen Ausgangspunkt für Ihre Migration.

Die Konvertierungsphase besteht aus zwei Schritten, die Sie nacheinander ausführen:

1. Erfassen Sie eine Darstellung Ihrer Azure-Ressourcen. Wenn Sie über eine vorhandene JSON-Vorlage verfügen, die Sie in Bicep konvertieren, ist der erste Schritt einfach– Sie verfügen bereits über Ihre Quellvorlage. Wenn Sie Azure-Ressourcen konvertieren, die über das Portal oder ein anderes Tool bereitgestellt wurden, müssen Sie die Ressourcendefinitionen erfassen. Sie können eine JSON-Darstellung Ihrer Ressourcen über das Azure-Portal, mit der Azure CLI oder mithilfe von Azure PowerShell-Cmdlets erfassen, um einzelne Ressourcen, mehrere Ressourcen und ganze Ressourcengruppen zu exportieren. Sie können den Insert Resource-Befehl in Visual Studio Code verwenden, um eine Bicep-Darstellung Ihrer Azure-Ressource zu importieren.

2. Konvertieren Sie die JSON-Darstellung bei Bedarf in Bicep. Verwenden Sie dazu den Befehl decompile. Die Bicep-Tools enthalten den Befehl decompile zum Konvertieren von Vorlagen. Sie können den Befehl decompile in Visual Studio Code mit der Bicep-Erweiterung, der Azure CLI oder über die Bicep-CLI aufrufen. Der Dekompilierungsprozess ist ein bestmöglicher Prozess und garantiert keine vollständige Zuordnung von JSON zu Bicep. Möglicherweise müssen Sie die generierte Bicep-Datei überarbeiten, um die bewährten Methoden Ihrer Vorlage zu erfüllen, bevor Sie die Datei zum Bereitstellen von Ressourcen verwenden.

Hinweis

Sie können eine Ressource importieren, indem Sie die Visual Studio Code-Befehlspalette öffnen. Drücken Sie STRG+UMSCHALT+P unter Windows und Linux oder ⌘+UMSCHALT+P unter macOS.

In Visual Studio Code können Sie JSON-Code als Bicep einfügen. Weitere Informationen finden Sie unter Befehl zum Einfügen von JSON als Bicep.

Phase 2: Migrieren

In der Migrationsphase der Migration Ihrer Ressourcen zu Bicep besteht das Ziel darin, den ersten Entwurf Ihrer bereitstellbaren Bicep-Datei zu erstellen und sicherzustellen, dass sie alle Azure-Ressourcen definiert, die sich im Geltungsbereich der Migration befinden.

Die Migrationsphase besteht aus drei Schritten, die Sie nacheinander ausführen:

1. Erstellen einer neuen leeren Bicep-Datei. Es ist eine bewährte Methode, eine ganz neue Bicep-Datei zu erstellen. Die in der Konvertierungsphase erstellte Datei ist ein Referenzpunkt, den Sie sich ansehen können, aber Sie sollten die Datei nicht als endgültig betrachten oder in diesem Zustand bereitstellen.

2. Kopieren der jeweiligen Ressourcen aus der dekompilierten Vorlage. Kopieren Sie jede Ressource einzeln aus der konvertierten Bicep-Datei in die neue Bicep-Datei. Dieser Prozess hilft Ihnen, alle Probleme auf Basis der einzelnen Ressourcen zu lösen und Verwirrung zu vermeiden, wenn Ihre Vorlage an Umfang zunimmt.

3. Identifizieren und Neuerstellen fehlender Ressourcen. Nicht alle Azure-Ressourcentypen können über das Azure-Portal, die Azure CLI oder Azure PowerShell exportiert werden. Beispielsweise werden Erweiterungen für virtuelle Computer wie DependencyAgentWindows und MMAExtension (Microsoft Monitoring Agent) als Ressourcentypen für den Export nicht unterstützt. Alle nicht exportierten Ressourcen (z. B. VM-Erweiterungen) müssen Sie in der neuen Bicep-Datei neu erstellen. Sie können Ressourcen mithilfe einer Reihe unterschiedlicher Tools und Ansätze neu erstellen, einschließlich Azure-Ressourcen-Explorer, der Referenzdokumentation zu Bicep-und ARM-Vorlagen und der Website mit Azure-Schnellstartvorlagen.

Phase 3: Refactoring

In der Umgestaltungsphase der Migration Ihrer Ressourcen zu Bicep besteht das Ziel in der Verbesserung der Qualität Ihres Bicep-Codes. Diese Verbesserungen können Änderungen umfassen wie das Hinzufügen von Codekommentaren, die die Vorlage in Einklang mit Ihren Vorlagenstandards bringen.

Die Bereitstellungsphase besteht aus acht Schritten, die Sie in beliebiger Reihenfolge ausführen können:

1. Überprüfen der Ressourcen-API-Versionen. Wenn Sie Azure-Ressourcen exportieren, verfügt die exportierte Vorlage möglicherweise nicht über die neueste API-Version für einen Ressourcentyp. Wenn sie bestimmte Eigenschaften für zukünftige Bereitstellungen benötigen, aktualisieren Sie die API auf die entsprechende Version. Es ist eine bewährte Methode, die API-Versionen für jede exportierte Ressource zu überprüfen.

2. Überprüfen der Lintervorschläge in der neuen Bicep-Datei. Wenn Sie die Bicep-Erweiterung für Visual Studio Code verwenden, um Bicep-Dateien zu erstellen, wird der Bicep-Linter automatisch ausgeführt und hebt dabei Vorschläge und Fehler in Ihrem Code hervor. Viele der Vorschläge und Fehler enthalten eine Option für eine schnelle Korrektur des Problems. Überprüfen Sie diese Empfehlungen, und passen Sie Ihre Bicep-Datei an.

3. Überarbeiten von Parametern, Variablen und symbolischen Namen. Die Namen von Parametern und Variablen sowie symbolische Namen, die vom Decompiler generiert werden, entsprechen möglicherweise nicht Ihrer Standardnamenskonvention. Überprüfen Sie die generierten Namen, und nehmen Sie bei Bedarf Anpassungen vor.

4. Vereinfachen von Ausdrücken. Der Dekompilierungsprozess nutzt möglicherweise nicht alle Features von Bicep. Überprüfen Sie alle bei der Konvertierung generierten Ausdrücke, und vereinfachen Sie sie. Die dekompilierte Vorlage kann z. B. eine concat() oder format() -Funktion enthalten, die mithilfe von Zeichenfolgeninterpolation vereinfacht werden kann. Überprüfen Sie alle Lintervorschläge, und nehmen Sie bei Bedarf Anpassungen vor.

5. Überprüfen von untergeordneten und Erweiterungsressourcen. Es gibt mehrere Möglichkeiten in Bicep, um untergeordnete Ressourcen und Erweiterungsressourcen zu deklarieren, einschließlich der Verkettung der Namen Ihrer Ressourcen mithilfe des Schlüsselworts parent und geschachtelter Ressourcen. Überprüfen Sie diese Ressourcen nach der Dekompilierung, und stellen Sie sicher, dass die Struktur Ihren Standards entspricht. Stellen Sie beispielsweise sicher, dass Sie keine Zeichenfolgenverkettung verwenden, um untergeordnete Ressourcennamen zu erstellen. Sie sollten die parent-Eigenschaft oder eine geschachtelte Ressource verwenden. Auf ähnliche Weise kann auf Subnetze entweder als Eigenschaften eines virtuellen Netzwerks oder als separate Ressource verwiesen werden.

6. Modularisieren. Wenn Sie eine Vorlage konvertieren, die über viele Ressourcen verfügt, sollten Sie der Einfachheit halber erwägen, die einzelnen Ressourcentypen in Module aufzuteilen. Bicep-Module tragen dazu bei, die Komplexität Ihrer Bereitstellungen zu reduzieren, und erhöhen die Wiederverwendbarkeit Ihres Bicep-Codes.

   Hinweis

   Es ist möglich, Ihre JSON-Vorlagen als Module in einer Bicep-Bereitstellung zu verwenden. Bicep hat die Möglichkeit, JSON-Module zu erkennen und auf diese ähnlich zu verweisen, wie Sie Bicep-Module verwenden.

7. Fügen Sie Kommentare und Beschreibungen hinzu. Guter Bicep-Code ist selbstdokumentierend. Mit Bicep können Sie Ihrem Code Kommentare und @description() Attribute hinzufügen, mit denen Sie Ihre Infrastruktur dokumentieren können. Bicep unterstützt sowohl einzeilige Kommentare mit einer //-Zeichenfolge als auch mehrzeilige Kommentare, die mit /* beginnen und mit */ enden. Sie können Kommentare zu bestimmten Zeilen in Ihrem Code und für Codeabschnitte eingeben.

8. Befolgen bewährter Methoden für Bicep. Stellen Sie sicher, dass Ihre Bicep-Datei die Standardempfehlungen befolgt. Lesen Sie das Referenzdokument Bewährte Methoden für Bicep, um alle Informationen zu erhalten, die Sie möglicherweise noch nicht kennen.

Phase 4: Testen

In der Testphase der Migration Ihrer Ressourcen zu Bicep besteht das Ziel darin, die Integrität Ihrer migrierten Vorlagen zu überprüfen und eine Testbereitstellung durchzuführen.

Die Testphase besteht aus zwei Schritten, die Sie nacheinander ausführen.

1. Ausführen des Was-wäre-wenn-Vorgangs der ARM-Vorlagenbereitstellung. Um die konvertierten Vorlagen vor der Bereitstellung zu überprüfen, können Sie den Azure Resource Manager-Was-wäre-wenn-Vorgang der Vorlagenbereitstellung verwenden. Dabei wird der aktuelle Zustand Ihrer Umgebung mit dem gewünschten Zustand verglichen, der in der Vorlage definiert ist. Das Tool gibt die Liste der Änderungen aus, die auftreten, ohne die Änderungen auf Ihre Umgebung anzuwenden. Sie können Was-wäre-wenn sowohl mit inkrementellen als auch mit vollständigen Bereitstellungen verwenden. Auch wenn Sie ihre Vorlage im inkrementellen Modus bereitstellen möchten, empfiehlt es sich, Ihren Was-wäre-wenn-Vorgang im vollständigen Modus auszuführen.

2. Ausführen einer Testbereitstellung. Bevor Sie Ihre konvertierte Bicep-Vorlage in der Produktion verwenden, sollten Sie mehrere Testbereitstellungen ausführen. Wenn Sie über mehrere Umgebungen (Produktion, Entwicklung, Test) verfügen, sollten Sie versuchen, Ihre Vorlage zunächst in einer Ihrer Nicht-Produktionsumgebungen bereitzustellen. Vergleichen Sie nach der Bereitstellung die ursprünglichen Ressourcen mit den neuen Ressourcenbereitstellungen hinsichtlich ihrer Konsistenz.

Phase 5: Bereitstellen

In der Bereitstellungsphase der Migration Ihrer Ressourcen zu Bicep besteht das Ziel darin, Ihre endgültige Bicep-Datei in der Produktion bereitzustellen.

Die Bereitstellungsphase besteht aus vier Schritten, die Sie in der folgenden Reihenfolge ausführen:

1. Vorbereiten eines Rollbackplans. Die Möglichkeit zur Wiederherstellung nach einer fehlerhaften Bereitstellung ist entscheidend. Entwickeln Sie eine Rollbackstrategie für den Fall, dass Breaking Changes in Ihren Umgebungen eingeführt werden. Erfassen Sie die Ressourcentypen, die bereitgestellt werden, z. B. virtuelle Computer, Web-Apps und Datenbanken. Die Datenebene jeder Ressource sollte ebenfalls berücksichtigt werden. Haben Sie eine Möglichkeit, einen virtuellen Computer und seine Daten wiederherzustellen? Haben Sie eine Methode, um eine Datenbank nach Löschung wiederherzustellen? Mit einem gut entwickelten Rollbackplan können Sie die Downtime gering halten, falls bei einer Bereitstellung Probleme auftreten.

2. Ausführen des Was-wäre-wenn-Vorgangs für die Produktion. Bevor Sie Ihre endgültige Bicep-Datei in der Produktion bereitstellen, führen Sie den Was-wäre-wenn-Vorgang für Ihre Produktionsumgebung aus, stellen Sie sicher, dass Sie Produktionsparameterwerte verwenden, und erwägen Sie, die Ergebnisse zu dokumentieren.

3. Manuelle Bereitstellung. Wenn Sie die konvertierte Vorlage in einer Pipeline verwenden möchten, z. B. in Azure DevOps oder GitHub Actions, sollten Sie die Bereitstellung zuerst auf Ihrem lokalen Computer ausführen. Es ist besser, die Funktionalität der Vorlage zu testen, bevor Sie sie in Ihre Produktionspipeline integrieren. Auf diese Weise können Sie schnell reagieren, wenn ein Problem vorliegt.

4. Ausführen von Feuerproben. Nach Abschluss Ihrer Bereitstellung sollten Sie eine Reihe von Buildakzeptanztest (smoke tests) ausführen, um sicherzustellen, dass Ihre Anwendung oder Workload ordnungsgemäß funktioniert. Testen Sie beispielsweise, ob auf Ihre Web-App über normale Zugriffskanäle wie das öffentliche Internet oder über ein Unternehmens-VPN zugegriffen werden kann. Versuchen Sie für Datenbanken, eine Datenbankverbindung herzustellen und eine Reihe von Abfragen auszuführen. Melden Sie sich bei VMs an, und stellen Sie sicher, dass alle Dienste aktiv sind und ausgeführt werden.

Nächste Schritte

Weitere Informationen zum Bicep-Decompiler finden Sie unter Dekompilieren von ARM-Vorlagen-JSON-Code in Bicep.