Gruppieren verwandter Ressourcen mithilfe von Modulen

  • 6 Minuten

Sie haben mit der Verwendung von Bicep-Vorlagen für die letzten Produkteinführungen begonnen, die erfolgreich waren. Da Sie Ihre Ressourcen in einer Vorlagendatei deklariert haben, können Sie die Ressourcen schnell für neues Spielzeug bereitstellen, ohne Ressourcen manuell im Azure-Portal 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. Anschließend können Sie in der Bicep-Hauptvorlage 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 ein einzelnes Bicep-Modul in vielen Bicep-Vorlagen verwenden.

Außerdem müssen Sie häufig Ausgaben von den Bicep-Modulen und -Vorlagen 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-Vorlagen manuell bereitstellen, oder eine Art automatisierter Releaseprozess kann sie bereitstellen. In beiden Fällen müssen häufig einige Daten aus der Vorlage an die Personen oder den Prozess zurückgesendet werden, die bzw. der die Vorlagenbereitstellung durchführt.

Im Folgenden finden Sie einige Beispielszenarien, in denen Sie möglicherweise Informationen aus der Vorlagenbereitstellung benötigen:

  • Sie erstellen eine Bicep-Vorlage, die eine VM bereitstellt, und Sie benötigen die öffentliche IP-Adresse, damit Sie über SSH eine Verbindung mit dem Computer herstellen können.
  • Sie erstellen eine Bicep-Vorlage, die eine Reihe von Parametern entgegennimmt, z. B. einen Umgebungsnamen und einen Anwendungsnamen. Die Vorlage verwendet einen Ausdruck, um einer Azure App Service-App, die sie bereitstellt, einen Namen zu geben. Sie müssen den Namen der App ausgeben, die von der Vorlage bereitgestellt wurde, damit Sie diese in einer Bereitstellungspipeline zum Veröffentlichen der Binärdateien der Anwendung verwenden können.

Für diese Szenarien können Sie Ausgaben verwenden. Um in einer Bicep-Vorlage eine Ausgabe zu definieren, verwenden Sie das Schlüsselwort output 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 eine Person die Vorlage bereitstellt, enthalten die Ausgabewerte den von Ihnen angegebenen Namen, sodass sie 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 Variable erstellen, der in den Ressourcen Ihrer Vorlage verwendet werden soll, und Sie dann auch den Wert der Variable 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.

Achtung

Erstellen Sie keine Ausgaben für Geheimniswerte wie Verbindungszeichenfolgen oder Schlüssel. Jede Person mit Zugriff auf Ihre Ressourcengruppe kann Ausgaben aus Vorlagen 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 dann zu einer Vorlage zusammengesetzt werden können. Jede Bicep-Vorlage kann selbst von einer anderen Vorlage als Modul verwendet werden. Sie haben in diesem Lernmodul Bicep-Vorlagen erstellt. Das bedeutet, dass Sie bereits Dateien erstellt haben, die als Bicep-Module verwendet werden können.

Angenommen, Sie verfügen über eine Bicep-Vorlage, mit der Anwendungs-, Datenbank- und Netzwerkressourcen für Lösung A bereitgestellt werden. Diese Vorlage können Sie etwa in drei Module aufteilen, von denen jedes auf einen eigenen Satz von Ressourcen ausgerichtet ist. Als Bonus können Sie die Module jetzt auch in anderen Vorlagen für andere Lösungen wiederverwenden. Wenn Sie also eine Vorlage für Lösung B entwickeln, die ähnliche Netzwerkanforderungen wie die Lösung A hat, können Sie das Netzwerkmodul wiederverwenden.

Diagramm einer Vorlage für Lösung A mit Verweisen auf drei Module: Anwendung, Datenbank und Netzwerk. Das Netzwerkmodul wird dann in einer anderen Vorlage für Lösung B wiederverwendet.

Wenn die Vorlage einen Verweis auf eine Moduldatei enthalten soll, verwenden Sie das Schlüsselwort module. 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 in anderen Teilen der Vorlage auf die Ausgaben des Moduls verweisen.
  • modules/mymodule.bicep ist der Pfad zur Moduldatei (relativ zur Vorlagendatei). 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 für jedes Modul in der Vorlagendatei eine separate Bereitstellung erstellt wird. 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 Vorlage festlegen, können Sie Ausdrücke, Vorlagenparameter, Variablen, Eigenschaften der in der Vorlage bereitgestellten Ressourcen und Ausgaben von anderen Modulen verwenden. 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:

  • Jedes 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.

  • Module sollten klare und sinnvolle Parameter und Ausgaben aufweisen: Behalten Sie den Zweck des Moduls im Blick. Überlegen Sie, ob das Modul Parameterwerte bearbeiten soll oder die übergeordnete Vorlage dies umsetzen und dann einen einzelnen Wert an das Modul übergeben soll. Bedenken Sie auch die Ausgaben, die ein Modul zurückgeben soll, und stellen Sie sicher, dass sie für die Vorlagen nützlich sind, die das Modul verwenden.

  • Jedes Modul sollte so eigenständig wie möglich sein: Wenn ein Modul einen Teil eines Moduls mithilfe einer Variable definieren muss, sollte die Variable im Allgemeinen in der Moduldatei und nicht in der übergeordneten Vorlage enthalten sein.

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