Gruppieren verwandter Ressourcen mithilfe von Modulen

Abgeschlossen

Sie haben begonnen, Bicep-Dateien für einige aktuelle Produktstarts zu verwenden, und sie waren erfolgreich. Da Sie Ihre Ressourcen in einer Datei deklariert haben, können Sie die Ressourcen für neue Toy-Starts schnell bereitstellen, ohne ressourcen im Azure-Portal manuell konfigurieren zu müssen.

Der Leiter der IT-Abteilung hat erkannt, dass Ihr Bicep-Code immer komplexer wird und eine wachsende Anzahl von Ressourcen definiert. Er hat Sie daher gefragt, ob Sie den Code modularisieren können. Sie können einzelne Bicep-Dateien, sogenannte Module, für unterschiedliche Teile Ihrer Bereitstellung erstellen. Die Hauptdatei "Bicep" kann auf diese Module verweisen. Im Hintergrund werden die Module für die Bereitstellung in eine einzelne JSON-Vorlage transpiliert.

Module sind auch eine Möglichkeit, Bicep-Code noch besser wiederverwendbar zu machen. Sie können über ein einzelnes Bicep-Modul verfügen, das viele andere Bicep-Dateien verwenden.

Sie müssen auch häufig Ausgaben von den Bicep-Modulen und -Dateien ausgeben. Ausgaben stellen eine Möglichkeit für Ihren Bicep-Code dar, Daten an die Personen oder das Tool zurückzugeben, die bzw. das die Bereitstellung gestartet hat. Als Erstes sehen Sie sich Ausgaben an.

Hinweis

Die Befehle in dieser Lerneinheit dienen der Veranschaulichung der Konzepte. Führen Sie die Befehle jetzt noch nicht aus. Sie können das Erlernte in Kürze üben.

Ausgaben

Ein Mensch kann Bicep-Dateien manuell bereitstellen oder eine Art automatisierter Veröffentlichungsprozess kann sie bereitstellen. In beiden Fällen ist es üblich, dass einige Daten aus der Datei an die verantwortliche Person oder Stelle für die Ausführung der Dateibereitstellung zurückgesendet werden müssen.

Im Folgenden finden Sie einige Beispielszenarien, in denen Sie Möglicherweise Informationen aus der Bicep-Dateibereitstellung abrufen müssen:

  • Sie erstellen eine Bicep-Datei, die eine virtuelle Maschine bereitstellt, und Sie müssen die öffentliche IP-Adresse abrufen, um per SSH auf die Maschine zugreifen zu können.
  • Sie erstellen eine Bicep-Datei, die eine Reihe von Parametern akzeptiert, z. B. einen Umgebungsnamen und einen Anwendungsnamen. Die Datei verwendet einen Ausdruck, um eine Von ihr bereitgestellte Azure App Service-App zu benennen. Sie müssen den Namen der App ausgeben, den die Datei bereitgestellt hat, damit Sie sie in einer Bereitstellungspipeline verwenden können, um die Binärdateien der Anwendung zu veröffentlichen.

Für diese Szenarien können Sie Ausgaben verwenden. Um eine Ausgabe in einer Bicep-Datei zu definieren, verwenden Sie das output Schlüsselwort wie folgt:

output appServiceAppName string = appServiceAppName

Die Ausgabedefinition enthält einige wichtige Elemente:

  • Das Schlüsselwort output teilt Bicep mit, dass Sie eine Ausgabe definieren.
  • appServiceAppName ist der Name der Ausgabe. Wenn jemand die Bicep-Datei erfolgreich bereitstellt, enthalten die Ausgabewerte den von Ihnen angegebenen Namen, damit er auf die erwarteten Werte zugreifen kann.
  • string ist der Ausgabetyp. Bicep-Ausgaben unterstützen die gleichen Typen wie Parameter.
  • Für jede Ausgabe muss ein Wert angegeben werden. Im Gegensatz zu Parametern müssen Ausgaben immer Werte aufweisen. Ausgabewerte können Ausdrücke, Verweise auf Parameter oder Variablen sowie Eigenschaften von Ressourcen sein, die in der Datei bereitgestellt werden.

Tipp

Ausgaben können die gleichen Namen wie Variablen und Parameter verwenden. Diese Konvention kann hilfreich sein, wenn Sie einen komplexen Ausdruck innerhalb einer Variablen erstellen, der in den Ressourcen der Bicep-Datei verwendet wird, und Sie den Wert der Variablen auch als Ausgabe verfügbar machen müssen.

Dies ist ein weiteres Beispiel für eine Ausgabe. Hier wird der Wert auf den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) einer öffentlichen IP-Adressressource festgelegt.

output ipFqdn string = publicIPAddress.properties.dnsSettings.fqdn

Tipp

Versuchen Sie, Ressourceneigenschaften als Ausgaben zu verwenden, anstatt Annahmen zum Verhalten von Ressourcen zu treffen. Wenn Sie beispielsweise eine Ausgabe für die URL einer App Service-App benötigen, verwenden Sie die defaultHostName-Eigenschaft der App, anstatt selbst eine Zeichenfolge für die URL zu erstellen. Manchmal sind diese Annahmen nicht in allen Umgebungen zutreffend, oder die Funktionsweise von Ressourcen wird geändert. Daher ist es sicherer, wenn die Ressource Ihnen ihre eigenen Eigenschaften mitteilt.

Vorsicht

Erstellen Sie keine Ausgaben für Geheimniswerte wie Verbindungszeichenfolgen oder Schlüssel. Jeder Benutzer mit Zugriff auf Ihre Ressourcengruppe kann Ausgaben aus Bicep-Dateien lesen. Es gibt andere Ansätze, mit denen Sie Zugriff auf Ressourceneigenschaften von Geheimnissen erhalten können. Diese werden in einem späteren Modul behandelt.

Definieren eines Moduls

Mit Bicep-Modulen können Sie Ihren Bicep-Code organisieren und wiederverwenden, indem Sie kleinere Einheiten erstellen, die in einer Bicep-Datei zusammengesetzt werden können. Jede Bicep-Datei kann als Modul von einer anderen Vorlage verwendet werden. In diesem Lernmodul haben Sie Bicep-Dateien erstellt. Das bedeutet, dass Sie bereits Dateien erstellt haben, die als Bicep-Module verwendet werden können.

Stellen Sie sich vor, Sie haben eine Bicep-Datei, die Anwendungs-, Datenbank- und Netzwerkressourcen für Lösung A bereitstellt. Sie können diese Bicep-Datei in drei Module aufteilen, von denen jeder auf seine eigenen Ressourcengruppen konzentriert ist. Als Bonus können Sie die Module jetzt auch in anderen Vorlagen für andere Lösungen wiederverwenden. Wenn Sie also eine Datei für Lösung B entwickeln, die ähnliche Netzwerkanforderungen wie lösung A aufweist, können Sie das Netzwerkmodul wiederverwenden.

Diagramm, das eine Bicep-Datei für Lösung A zeigt, die auf drei Module verweist: Anwendung, Datenbank und Netzwerk. Das Netzwerkmodul wird dann in einer anderen Bicep-Datei für Lösung B wiederverwendet.

Wenn die Bicep-Datei einen Verweis auf eine Moduldatei enthalten soll, verwenden Sie das module Schlüsselwort. Eine Moduldefinition ähnelt einer Ressourcendeklaration, aber anstelle eines Ressourcentyps und einer API-Version verwenden Sie den Dateinamen des Moduls:

module myModule 'modules/mymodule.bicep' = {
  name: 'MyModule'
  params: {
    ___location: ___location
  }
}

Sehen Sie sich einige wichtige Teile dieser Moduldefinition genauer an:

  • Das Schlüsselwort module teilt Bicep mit, dass Sie eine andere Bicep-Datei als Modul verwenden möchten.
  • Wie für Ressourcen ist auch für Module ein symbolischer Name wie myModule erforderlich. Sie verwenden den symbolischen Namen, wenn Sie auf die Ausgaben des Moduls in anderen Teilen der Bicep-Datei verweisen.
  • modules/mymodule.bicep ist der Pfad zur Modul-Bicep-Datei relativ zur Datei. Denken Sie daran, dass eine Moduldatei lediglich eine reguläre Bicep-Datei ist.
  • Genau wie Bei Ressourcen ist die name-Eigenschaft obligatorisch. Azure verwendet den Modulnamen, da er eine separate Bereitstellung für jedes Modul in der Bicep-Datei erstellt. Diese Bereitstellungen weisen Namen auf, mit denen Sie sie identifizieren können.
  • Mithilfe des Schlüsselworts params können Sie beliebige Parameter des Moduls angeben. Wenn Sie die Werte der einzelnen Parameter in der Bicep-Datei festlegen, können Sie Ausdrücke, Dateiparameter, Variablen, Eigenschaften von Ressourcen verwenden, die in der Datei bereitgestellt werden, und Ausgaben aus anderen Modulen. Bicep erkennt automatisch die Abhängigkeiten zwischen den Ressourcen.

Module und Ausgaben

Genau wie Vorlagen können auch Bicep-Module Ausgaben definieren. Es ist üblich, Module innerhalb einer Vorlage zu verketten. In diesem Fall kann die Ausgabe eines Moduls ein Parameter eines anderen Moduls sein. Durch die kombinierte Verwendung von Modulen und Ausgaben können Sie leistungsstarke und wiederverwendbare Bicep-Dateien erstellen.

Entwerfen von Modulen

Ein gutes Bicep-Modul hält einige wichtigen Prinzipien ein:

  • Ein Modul sollte einen eindeutigen Zweck haben. Sie können ein Modul dazu verwenden, alle Ressourcen zu definieren, die mit einem bestimmten Teil Ihrer Lösung zusammenhängen. Oder Sie können ein Modul erstellen, das alle Ressourcen zum Überwachen Ihrer Anwendung enthält. Sie können auch ein Modul verwenden, um einen Satz von zusammengehörigen Ressourcen zu definieren, z. B. alle Ihre Datenbankserver und Datenbanken.

  • Verwenden Sie nicht für jede Ressource ein eigenes Modul. Sie sollten nicht für jede Ressource, die Sie bereitstellen, ein eigenes Modul erstellen. Wenn Sie über eine Ressource mit vielen komplexen Eigenschaften verfügen, kann es sinnvoll sein, diese Ressource in ein eigenes Modul zu setzen, aber im Allgemeinen ist es besser, dass Module mehrere Ressourcen kombinieren.

  • Ein Modul sollte klare und sinnvolle Parameter und Ausgaben aufweisen. Behalten Sie den Zweck des Moduls im Blick. Überlegen Sie, ob das Modul Parameterwerte bearbeiten soll oder ob die übergeordnete Bicep-Datei dies behandeln soll, und übergeben Sie dann einen einzelnen Wert an das Modul. Denken Sie auch an die Ausgaben, die ein Modul zurückgeben sollte, und stellen Sie sicher, dass sie für die Bicep-Dateien nützlich sind, die das Modul verwenden.

  • Ein Modul sollte so eigenständig wie möglich sein. Wenn ein Modul eine Variable verwenden muss, um einen Teil eines Moduls zu definieren, sollte die Variable in der Modul-Bicep-Datei und nicht in der übergeordneten Bicep-Datei enthalten sein.

  • Ein Modul sollte keine Geheimnisse ausgeben. Erstellen Sie wie bei Vorlagen keine Modulausgaben mit Geheimniswerten wie Verbindungszeichenfolgen oder Schlüsseln.