Veröffentlichen eines Moduls in einer privaten Registrierung

  • 4 Minuten

Sie wissen nun, was Bicep-Registrierungen sind und wie sie beim Freigeben von Modulen in Ihrer Organisation hilfreich sein können. In dieser Lerneinheit erfahren Sie, wie Sie ein Modul in einer privaten Registrierung veröffentlichen.

Modulpfade

Wenn Sie in der Vergangenheit mit Modulen gearbeitet haben, haben Sie wahrscheinlich den Dateipfad des Moduls verwendet, um in Ihren Vorlagen darauf zu verweisen. Wenn Sie mit Modulen und privaten Registrierungen arbeiten, müssen Sie einen anderen Modulpfad verwenden, damit Bicep weiß, wie das Modul in Ihrer Registrierung zu finden ist.

Hier sehen Sie einen Beispielpfad für ein Modul in einer privaten Azure-Containerregistrierung:

Diagramm der Syntax für einen Modulpfad

Der Pfad enthält vier Segmente:

  • Schema: Bicep unterstützt mehrere Modultypen, die als Schemas bezeichnet werden. Wenn Sie mit Bicep-Registrierungen arbeiten, lautet das Schema br.
  • Registrierung: Der Name der Registrierung, die das zu verwendende Modul enthält. Im Beispiel oben lautet der Registrierungsname toycompany.azurecr.io. Dies ist der Name der Containerregistrierung.
  • Modulbezeichner: Der vollständige Pfad zum Modul innerhalb der Registrierung.
  • Tag: Tags stellen in der Regel Versionen von Modulen dar, da für ein einzelnes Modul mehrere Versionen veröffentlicht werden können. Weitere Informationen zu Tags und Versionen finden Sie im nächsten Abschnitt.

Wenn Sie Ihren eigenen Modulbezeichner veröffentlichen, verwenden Sie eine aussagekräftige Bezeichnung, die den Zweck des Moduls angibt. Sie können optional Namespaces nutzen und zur Unterscheidung der einzelnen Namensteile Schrägstriche (/) verwenden. Azure Container Registry und Bicep verstehen jedoch keine Hierarchie. Sie behandeln den Modulbezeichner als einzelnen Wert.

Tags und Versionen

Ein Tag stellt die Version eines Moduls dar. Für ein einzelnes Modul in einer Registrierung kann es mehrere Versionen geben. Alle Versionen verwenden einen Modulbezeichner, jedoch unterschiedliche Tags. Wenn Sie ein Modul verwenden, müssen Sie mithilfe eines Tags die Version angeben, die Sie verwenden möchten, damit Bicep weiß, welche Moduldatei abgerufen werden soll.

Es ist eine gute Idee, die Versionsverwaltung Ihrer Module sorgfältig zu planen. Zwei wichtige Entscheidungen, die Sie treffen müssen, sind das Versionsschema und die Versionsrichtlinie, die Sie verwenden möchten.

Versionsverwaltungsschemas

Ihr Versionsschema bestimmt, wie Sie Versionsnummern generieren. Zu den gängigen Versionsschemas gehören:

  • Einfache ganze Zahlen können als Versionsnummern verwendet werden. Ihre erste Version kann z. B. 1 heißen, Ihre zweite Version 2 usw. Alternativ können Sie auch jeder Versionsnummer ein Präfix voranstellen, z. B. v1 und v2.
  • Datumsangaben geben ebenfalls gute Versionsnummern ab. Wenn Sie beispielsweise die erste Version Ihres Moduls am 16. Januar 2022 veröffentlichen, können Sie die Version 2022-01-16 nennen (im Format jjjj-mm-tt). Wenn Sie eine weitere Version am 3. März veröffentlichen, können Sie sie 2022-03-03 nennen.
  • Als semantische Versionsverwaltung bezeichnet man ein Versionssystem, das häufig für Software verwendet wird, wobei eine einzelne Versionsnummer mehrere Teile enthält. Jeder Teil kommuniziert unterschiedliche Informationen zur Art der Änderung.

Sie können zwar ein beliebiges Versionsschema verwenden, es empfiehlt sich aber, etwas zu wählen, das in einer sinnvollen Reihenfolge sortiert werden kann. Zahlen und Datumsangaben sind häufig eine gute Wahl.

Hinweis

Azure Container Registry speichert das Datum, an dem die einzelnen Tags erstellt werden. Selbst wenn Sie keine datumsbasierte Versionsverwaltung verwenden, stehen Ihnen diese Informationen zur Verfügung.

Versionsrichtlinien

Mit Modulen haben Sie die Flexibilität, zu entscheiden, wann eine neue Version erstellt oder eine vorhandene Version aktualisiert werden soll. Beispielsweise können Sie sich effektiv gegen jede Versionsverwaltung entscheiden, indem Sie eine einzelne Version erstellen und veröffentlichen, die den Namen latest trägt. Jedes Mal, wenn Sie Ihr Modul ändern müssen, aktualisieren Sie einfach diese Version. Diese Vorgehensweise funktioniert zwar, sie ist aber kein gutes Verfahren.

Hingegen ist es wahrscheinlich auch nicht klug, bei jeder kleinen Änderung eines vorhandenen Moduls, die keinen Einfluss auf die Verwendungsweise hat, eine neue Version zu erstellen. Sie müssten die neue Versionsnummer dann an alle Benutzer kommunizieren, die mit dem Modul arbeiten.

Dagegen funktioniert diese Versionsrichtlinie in vielen Fällen gut:

  • Jedes Mal, wenn Sie wesentliche Änderungen an einem Modul vornehmen, erstellen Sie eine neue Version. Zu wichtigen Änderungen zählt alles, das für die Benutzer des Moduls einen entscheidenden Beitrag leisten kann. Beispiele hierfür sind das Hinzufügen einer weiteren Ressource zum Modul oder das Ändern der Eigenschaften einer Ressource.
  • Bei allen kleinen Änderungen an einem Modul, sogenannten Hotfixes, aktualisieren Sie die vorhandene Version des Moduls.
  • Löschen Sie alte Versionen, wenn sie nicht mehr relevant sind oder wenn Sie nicht möchten, dass sie von jemandem verwendet werden.

Tipp

Denken Sie dabei an die Benutzer Ihres Moduls, und überlegen Sie, was diese erwarten. Wenn ein Benutzer Ihr Modul mehrmals verwendet und ein bestimmtes Ergebnis erzielt hat, ist er möglicherweise überrascht, wenn er nach einem Hotfix ein anderes Ergebnis erhält. Versuchen Sie, Überraschungen für Ihre Benutzer zu vermeiden.

Veröffentlichen Ihres Moduls

Wenn Sie ein Bicep-Modul erstellen und freigeben möchten, erstellen Sie die Bicep-Datei wie gewohnt. Anschließend veröffentlichen Sie die Datei mit dem Befehl bicep publish in einer Registrierung. Beim Veröffentlichen müssen Sie den Modulpfad angeben, in dem das Modul gespeichert werden soll:

az bicep publish \
   --file module.bicep \
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

bicep publish module.bicep `
   --target 'br:toycompany.azurecr.io/mymodules/modulename:moduleversion'

Beim Veröffentlichungsvorgang werden dieselben Überprüfungsschritte ausgeführt, die auch beim Erstellen oder Bereitstellen einer Bicep-Datei erfolgen. Diese Schritte umfassen:

  • Überprüfen des Codes auf mögliche syntaktische Fehler
  • Überprüfen der angegebenen Ressourcendefinitionen auf Gültigkeit
  • Ausführen des Bicep-Linters zum Überprüfen des Codes anhand einer Reihe von Qualitätsprüfungen

Wenn die Überprüfungsschritte erfolgreich sind, wird das Modul in Ihrer Registrierung veröffentlicht.