Das Modularisieren der Verwaltung Ihrer Azure Resource Manager (ARM)-Vorlagen ermöglicht es Ihnen, Wiederholungen zu reduzieren, Modelle für bewährte Methoden der Infrastrukturentwicklung zu erstellen und konsistente Standardbereitstellungen zu gewährleisten.
Ein Anwendungsfall für die Implementierung dieser Art der Modularisierung ist die Bereitstellung von VMs unter Verwendung der Metapher von T-Shirt-Größen. Angenommen, Sie haben Dutzende oder Hunderte von VMs bereitgestellt. Diese Bereitstellungen verwenden Version 1.0.0 Ihrer Vorlagen und verfügen über die Standardgröße Mittel einer älteren Serie. Wenn Sie einfach neue Vorlagen bereitstellen, ist der Übergang zu einer neuen Serie u. U. nicht ohne einen kurzen Dienstausfall möglich. Wenn Sie jedoch Version 1.5.0 erstellen und die Modularisierung nutzen, können Sie die neue Infrastruktur mit dem aktualisierten Standard bereitstellen und gleichzeitig einen bereitstellbaren Zustand der alten Infrastruktur aufrechterhalten. Durch die Verfügbarkeit alter Versionen der Infrastruktur steht Ihren Produkt- und Anwendungsteams eine bekanntermaßen funktionierende Konfiguration zur Verfügung, auf die sie sich beim Upgrade auf die neue Version stützen können.
Die Ebenen von Repositorys: Ein Beispiel für Unternehmen
Möglicherweise möchten Sie aus bestimmten Gründen genau festlegen, wo Ihre Vorlagen gespeichert werden, wie sie aktualisiert werden usw. In diesem Zusammenhang müssen zwei wichtige Faktoren berücksichtigt werden: Branchen (Verzweigung) und Inner Sourcing.
Branchen. In diesem Beispielszenario können Git-Branchmodelle verwendet werden, die Gitflow und GitHub-Flow unterstützen. Weitere Informationen zu Gitflow finden Sie im Blogbeitrag zur Verwendung von Gitflow zum Automatisieren des Git-Branchingworkflows von Jeff Kreeftmeijer. Weitere Informationen zum GitHub-Flow finden Sie in der GitHub-Dokumentation unter GitHub-Flow.
Inner Sourcing. Der zweite Faktor ist Inner Sourcing, d. h. die Verwendung der auf Zusammenarbeit beruhenden Methoden der Open-Source-Softwareentwicklung bei der internen Entwicklung. In einem solchen Szenario können Sie unterschiedliche Vorlagen und Modulquellcode sicher freigeben, ohne sich um die Berechtigungen für die Bereitstellungsmodelle selbst zu kümmern. Weitere Informationen zur Inner-Source-Entwicklung finden Sie in der Einführung in Inner Source auf GitHub.
Bicep ist eine deklarative Sprache für die Bereitstellung von Azure-Ressourcen. Beim wiederverwendbaren Code von Bicep kann Azure Container Registry als private Registrierung zum Hosten von ARM-Vorlagen mit Versionsangabe verwendet werden. Wenn Sie Container Registry auf diese Weise verwenden, kann Ihr Unternehmen einen Continuous Integration und Continuous Delivery (CI/CD)-Prozess für Infrastruktur implementieren. Sie können im Rahmen des CI-Prozesses Integrations- und Komponententests ausführen, und die Containerregistrierung kann Module empfangen, nachdem diese erfolgreich erstellt wurden. App-Teams können, bis sie für das Upgrade bereit sind, weiterhin ältere Versionen verwenden oder ihre Vorlagen aktualisieren, um Features der neueren Vorlagenversionen zu nutzen.
Zusätzlich zu dieser Verwendung von Container Registry können Sie das Modell mit Komponenten wie Azure Verified Modules kombinieren. Sie können für Ihre Implementierung die öffentliche Registrierung nutzen oder vorzugsweise die öffentlichen Repositorys überwachen und Änderungen zur weiteren Verwendung in Ihre private Registrierung pullen. Durch das Pullen von Änderungen in Ihre eigene Containerregistrierung können Sie Tests mit öffentlichen Modulen ausführen und gleichzeitig sicherstellen, dass diese erst nach dem Integrieren von Qualitäts- und Sicherheitsmaßnahmen in der Produktion verwendet werden.
Ebenen
In diesem Beispielszenario wird ein gestapeltes Modell vorgeschlagen. Ebenen im oberen Teil des Stapels enthalten Bereitstellungen, die häufiger durchgeführt werden, und maßgeschneiderte Bereitstellungen. Bicep-Code bietet konsistente Bereitstellungen. Entwicklerteams, die in den Ebenen für ihre Beiträge arbeiten, nutzen die Dienste und Infrastruktur in den darunter befindlichen Ebenen. Inhalte in einer niedrigeren Ebene sollten niemals von Ressourcen in einer übergeordneten Ebene abhängig sein. Die Ebenen 0 bis 3 sind die globale Bibliothek, die globale Infrastruktur (global freigegebene Dienste), die Produktplattform (gemeinsame Dienste) und Anwendungen.
Dieses Modell sorgt für koordinierte Autonomie, was Folgendes bedeutet:
Es gibt gemeinsame Tools, die Vorgänge im Unternehmen vereinfachen. Beispielsweise verwenden alle Git für die Quellcodeverwaltung und GitHub Actions für CI/CD. Wir übertreiben es jedoch nicht. Wir schreiben beispielsweise nicht vor, dass alle Teams Bicep verwenden müssen. Sie können mit Terraform, ARM-Vorlagen und anderen Tools arbeiten.
Es ist möglich, bewährte Methoden zu teilen, z. B. in Form von ARM-Vorlagen, Golden Images oder Codeausschnitten. Bei bewährten Methoden kann es sich auch um eine Dokumentation bestimmter Techniken handeln. Ein Beispiel hierfür wäre eine Dokumentation, die beschreibt, wie Schlüssel in Ihrer Umgebung rotiert werden und wie Code getestet wird.
Einige Dienste werden im Stapel nach unten verschoben. Beispielsweise kann ein App-Team zunächst eine Vorlage für die Bereitstellung eines Kubernetes-Clusters entwickeln, die später als gemeinsamer Dienst in die Produktplattform gepullt wird. Diese Vorlage kann sich dann als so nützlich erweisen, dass sie in die Bibliothek mit Beispielen gepullt wird.
Ebene 0: Globale Bibliothek
Die unterste Ebene ist die globale Bibliothek, ein Repository nützlicher Informationen und Inhalte, die nicht in der Produktion bereitgestellt werden. Aus Sicht der Zugriffssteuerung sollte allen Benutzern im Unternehmen, die Lesezugriff anfordern, diese Berechtigung gewährt werden. Ihr Cloudkompetenzzentrum (Cloud Center of Excellence,CCoE) genehmigt wie bei jedem anderen Produkt Pull Requests (PRs) für Änderungen, Vorschläge usw. und verwaltet einen Backlog.
Ebene 0 sollte Folgendes nicht enthalten:
- Vorlagen, die in der Produktion bereitgestellt werden
- Geheimnisse oder umgebungsspezifische Konfigurationen
Ebene 0 sollte Folgendes enthalten:
- Codeausschnitte (in Python, C# usw.)
- Azure Policy-Beispiele
- ARM-Vorlagen, Bicep-Vorlagen oder Terraform-Dateien, die als Beispiele verwendet werden können
Ein Beispiel hierfür ist eine Beispielarchitektur, die beschreibt, wie Ihr Unternehmen eine Bereitstellung für eine Anwendung mit drei Ebenen erstellt, aber keine umgebungsspezifischen Informationen enthält. Diese Beispielarchitektur kann Tags, Netzwerke, Netzwerksicherheitsgruppen usw. enthalten. Das Auslassen spezifischer Informationen für die Umgebung ist hilfreich, da ein Modul nicht alles enthalten darf oder muss. Dies kann andernfalls zu einer Überparameterisierung führen.
Darüber hinaus könnte Ebene 0 mit anderen bekannten legitimen Quellen von Beispielcode verknüpft werden, z. B. mit der Terraform-Registrierung oder Azure Resource Modules. Falls Ihre Organisation Code oder Muster aus einer dieser Quellen verwendet, empfehlen wir, diese nicht direkt aus den öffentlichen Quellen, sondern in Ihre eigene Ebene 0 zu pullen. Unter Verwendung Ihrer Ebene 0 können Sie eigene Tests, Anpassungen und Sicherheitskonfigurationen schreiben. Wenn Sie sich nicht auf öffentliche Quellen verlassen, verringern Sie das Risiko, von Code und anderen Inhalten abhängig zu sein, die unerwartet gelöscht werden könnten.
Damit sie als guter Beispielcode angesehen werden können, müssen Ihre Vorlagen und Module den bewährten Entwicklungsmethoden entsprechen, einschließlich der Überprüfung von Eingaben im Hinblick auf sicherheits- und organisationsspezifische Anforderungen. Um dieses Maß an Genauigkeit und Sorgfalt aufrechtzuerhalten, sollten Sie dem Mainbranch Richtlinien hinzufügen, die PRs und Code Reviews für Änderungsvorschläge erzwingen, die bei der Zusammenführung dazu führen würden, dass Änderungen in die Hauptcontainerregistrierung gelangen.
Die Inhalte der Ebene 0 werden Azure Pipelines oder GitHub Actions zugeführt, um automatisch Artefakte mit Versionsangabe in Azure Container Registry zu erstellen. Sie können Git-Commitnachrichten automatisieren, um eine semantische Versionsverwaltung der Artefakte zu implementieren. Damit dies korrekt funktioniert und die Automatisierung im Laufe der Zeit verwaltet werden kann, benötigen Sie einen deterministischen Benennungsstandard, z. B. „<service.>bicep“. Mit den richtigen Branchrichtlinien können Sie auch Integrationstests als Voraussetzung für Code Reviews hinzufügen. Diesen Prozess können Sie mit Tools wie Pester instrumentieren.
Mit Richtlinien und Schutzmaßnahmen dieser Art kann die Containerregistrierung als zuverlässige Quelle für alle einsatzbereiten Infrastrukturmodule im Unternehmen dienen. Erwägen Sie die Standardisierung von Änderungsprotokollen sowie Indizes der verfügbaren Codebeispiele, damit dieser Code auffindbar ist. Unbekannter Code ist ungenutzter Code!
Ebene 1: Globale Infrastruktur – global freigegebene Dienste
Ebene 1 ist das Repository für Ihre Azure-Zielzonenkonstrukte. Microsoft stellt Vorlagen für die Bereitstellung von Azure-Zielzonen bereit, Sie möchten jedoch wahrscheinlich bestimmte Komponenten ändern und eine Parameterdatei angeben. Dies ist vergleichbar mit der Art und Weise, wie Sie öffentliche Registrierungs- und Modulrepositorys in Ebene 0 pullen (siehe oben).
Azure Container Registry ist ein wichtiger Bestandteil dieser Architektur. Selbst wenn Ihr Unternehmen nicht plant, Container zu verwenden, müssen Sie Container Registry für die erfolgreiche Versionsverwaltung von Bicep-Vorlagen bereitstellen. Container Registry ermöglicht eine beträchtliche Flexibilität und Wiederverwendbarkeit Ihrer Module und bietet Sicherheit sowie Zugriffssteuerung auf Unternehmensniveau.
Ebene 1 sollte Folgendes enthalten:
- Richtlinienzuweisungen und -definitionen, die auf der Ebene der Verwaltungsgruppe oder des Abonnements angewendet werden. Diese Richtlinien müssen den Governanceanforderungen Ihres Unternehmens entsprechen.
- Vorlagen für die Kernnetzwerkinfrastruktur, z. B. ExpressRoute, VPNs, Virtual WAN und virtuelle Netzwerke (freigegeben oder Hub).
- DNS
- Grundlegende Überwachung (Protokollanalyse).
- Containerregistrierung für Unternehmen.
Schränken Sie die Möglichkeit, Änderungen an dieses Repository zu pushen, durch entsprechende Konfiguration des Branchschutzes ein. Beschränken Sie die Genehmigung von PRs anderer Entwickler auf Mitglieder von CCoE oder Cloudgovernance. Mitwirkende dieser Ebene sind in erster Linie Mitglieder von Gruppen, die historisch mit den Komponenten in dieser Ebene in Verbindung stehen. Das Netzwerkteam erstellt beispielsweise die Vorlagen für das Netzwerk, das Betriebsteam konfiguriert die Überwachung usw. Benutzern, die Lesezugriff anfordern, sollten Sie diese Berechtigung jedoch gewähren, da Entwickler aus anderen Gruppen in der Lage sein sollen, Änderungen an den Kerninfrastrukturen vorzuschlagen. Sie können Verbesserungen beisteuern, ohne dass ihre Änderungen ohne vorherige Genehmigung und Tests zusammengeführt werden.
Diese Dateien sollten die Module in Ihrer Containerregistrierung für Standardkomponenten nutzen. Sie werden jedoch auch mindestens eine Bicep-Datei haben, die für die Implementierung von Azure-Zielzonen Ihres Unternehmens oder eine ähnliche Governancestruktur angepasst ist.
Ebene 2: Produktplattform – gemeinsame Dienste
Sie können sich Ebene 2, die Produktplattform, als gemeinsame Dienste für eine bestimmte Produktgruppe oder eine bestimmte Geschäftseinheit vorstellen. Diese Komponenten sind nicht universell in der gesamten Organisation einsetzbar, erfüllen aber eine bestimmte geschäftliche Anforderung. Dies wäre eine geeignete Ebene für ein virtuelles Netzwerk, das eine Peeringverbindung mit dem Hub in Ebene 1, der globalen Infrastruktur, herstellt. Ein Schlüsseltresor ist eine weitere Beispielkomponente für diese Ebene. Im Schlüsseltresor können gemeinsame geheime Schlüssel für ein Speicherkonto oder eine Datenbank gespeichert werden, die von den verschiedenen Anwendungen innerhalb dieser Plattform gemeinsam genutzt wird.
Ebene 2 sollte Folgendes enthalten:
- Richtlinienzuweisungen, die auf ein Abonnement oder eine Ressourcengruppe angewendet werden, um produktspezifische Anforderungen zu erfüllen
- ARM-Vorlagen für Schlüsseltresore, Protokollanalyse, eine SQL-Datenbank (wenn verschiedene Anwendungen innerhalb des Produkts die Datenbank verwenden) und Azure Kubernetes Service.
Sie sollten Berechtigungen implementieren, die die Möglichkeit zum Pushen von Änderungen an dieses Repository einschränken. Wie bei den anderen Ebenen sollten Sie mithilfe des Branchschutzes sicherstellen, dass ein Produktleiter oder -besitzer PRs von anderen Entwicklern genehmigen kann. Es gibt keine festen Regeln für den Lesezugriff auf die Produktplattform, Sie sollten aber zumindest den Entwicklern jedes Anwendungsteams Lesezugriff gewähren, damit sie Änderungen vorschlagen können. Da Ebene 2 proprietäre Architektur oder ähnliche Informationen enthalten kann, können Sie den Zugriff ggf. auf diejenigen Benutzer in der Organisation beschränken, die die Plattform verwenden. In diesem Fall sollten Sie jedoch einen Prozess einrichten, mit dem Sie bewährte Methoden und Codeausschnitte aus diesem Repository sammeln, die für die globale Bibliothek (Ebene 0) freigegeben werden sollen.
Ebene 3: Anwendung
Ebene 3, die Anwendungsebene, umfasst die Komponenten, die auf der Produktplattform basieren. Diese Komponenten liefern die vom Unternehmen angeforderten Funktionen. Für eine Streamingplattform könnte beispielsweise eine App die Suchfunktion bereitstellen und eine andere App Empfehlungen.
Ebene 3 sollte Folgendes enthalten:
- Anwendungscode in C#, Python usw.
- Infrastruktur für einzelne Komponenten (die nur in dieser Anwendung verwendet werden): Funktionen, Azure Container Instances, Event Hubs
Berechtigungen zum Pushen von Änderungen an dieses Repository werden beschränkt. Sie sollten den Branchschutz verwenden, um einem Teammitglied dieser Anwendung das Genehmigen von PRs anderer Teammitglieder zu ermöglichen. Teammitglieder sollten nicht in der Lage sein, ihre eigenen Änderungen zu genehmigen. Da diese Ebene proprietäre Architektur, Geschäftslogik oder ähnliche Informationen enthalten kann, können Sie den Zugriff ggf. auf diejenigen Benutzer in der Organisation beschränken, die diese Anwendung erstellen. In diesem Fall sollten Sie jedoch einen Prozess einrichten, mit dem Sie bewährte Methoden und Codeausschnitte dieser Ebene sammeln, die für die globale Bibliothek (Ebene 0) freigegeben werden sollen.
Gemeinsamkeiten der Ebenen
Neben den in diesem Artikel beschriebenen spezifischen Details für die einzelnen Ebene gibt es auch einige Eigenschaften, die für alle Ebenen gelten und ebenfalls berücksichtigt werden sollten.
Ihre Infrastruktur sollte wie eine Anwendung funktionieren. Dies bedeutet, dass Sie über einen Continuous Integration (CI)-Prozess verfügen sollten, in dem neue Features mit Komponententests, Buildakzeptanztests und Integrationstests vollständig getestet werden. Nur Code, der diese Tests besteht, sollte im Hauptreleasebranch zusammengeführt werden.
Außerdem sollten Sie mithilfe von Branchrichtlinien sicherstellen, dass der Prozess nicht von Benutzern umgangen werden kann, selbst wenn dies zweckmäßig erscheint. Wenn Ihr CI-Prozess als Impediment betrachtet wird, weist dies auf das Vorhandensein technischer Schulden hin, die beseitigt werden müssen. Es bedeutet nicht, dass Sie die Richtlinien und Schutzmaßnahmen entfernen müssen.
Als letzten Schritt sollte Ihre Organisation, auch wenn Sie vielleicht nicht über einen Index aller Repositorys und des darin enthaltenen Codes verfügen, einen Prozess entwickeln, mit dem Benutzer Zugriff auf Repositorys anfordern können. Bestimmte Regeln können vollständig automatisiert werden. Sie können beispielsweise eine Regel implementieren, die einem Mitwirkenden im Produktteam für eine zum Produkt gehörige Anwendung ohne Überprüfung Lesezugriff gewährt. Solche Regeln können häufig mit gruppenbasierten Mitgliedschaften und gruppenbasierten Rollenzuweisungen in Ihren Umgebungen implementiert werden. Die Konfiguration eines Zugriffs dieser Art sollte dazu beitragen, Inner Sourcing und das Wissen innerhalb der Organisation zu fördern.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Tim Sullivan | Senior Cloud Solution Architect
Andere Mitwirkende:
- Gary Moore | Programmierer/Autor
Nächste Schritte
- Entwurfsbereich: Plattformautomatisierung und DevOps
- Ausgereifte Teamstrukturen
- Was ist „Infrastructure-as-Code“?
- Azure/ResourceModules: Dieses Repository enthält eine CI-Plattform und eine Sammlung von ausgereiften und kuratierten Bicep-Modulen. Die Plattform unterstützt sowohl Azure Resource Manager als auch Bicep, und Sie können die Features der Plattform mit GitHub Actions und Azure Pipelines verwenden.
- Erstellen einer privaten Registrierung für das Bicep-Modul