Planen Ihrer Umgebungen

Abgeschlossen

Ihr Azure-Bestand besteht aus vielen Komponenten, darunter die grundlegende Konfiguration, unternehmensweite Ressourcen und Einstellungen sowie Anwendungsworkloads. Wahrscheinlich haben Sie Ihren Datenbestand auch auf mehrere Umgebungen verteilt, die jeweils einem anderen Zweck dienen.

In dieser Lerneinheit lernen Sie die Vorteile der konsistenten Verwendung von Code für Ihre gesamte Bereitstellung und Konfiguration kennen. Anschließend werden Sie sich überlegen, welche Kontroll- und Automatisierungsebenen Sie in jeder Ihrer Umgebungen anwenden können. Außerdem erfahren Sie, wie Ihre Änderungen die einzelnen Phasen des Bereitstellungsprozesses durchlaufen und welche Kontrollmechanismen und Arten von Governance Sie zur Unterstützung Ihrer gewählten Bereitstellungsstrategie benötigen.

Definieren Ihrer Infrastruktur als Code

Die Bereitstellung und Konfiguration von Azure umfasst weit mehr als Anwendungen, virtuelle Computer, Speicherdienste und Netzwerke. Beispielsweise ist jedes der folgenden Elemente eine Form der Konfiguration mit entsprechenden Azure-Ressourcen:

• Organisieren Ihrer Ressourcen durch Erstellen von Ressourcengruppen, Abonnements und Verwaltungsgruppen
• Steuern, wie Ihre anderen Ressourcen konfiguriert werden sollen, indem Sie Azure Policy-Definitionen, Initiativen und Zuweisungen definieren und anwenden
• Zuweisen von Rollen, um Benutzer*innen, Gruppen und Workloadidentitäten den Zugriff auf Azure-Ressourcen zu ermöglichen
• Konfigurieren der Überwachung (einschließlich Warnungen), um Ihre Azure-Ressourcen zu beobachten und sicherzustellen, dass sie sich erwartungsgemäß verhalten

Wenn Sie zum ersten Mal damit beginnen, Ihre Infrastruktur als Code zu definieren, wissen Sie möglicherweise nicht, welche Elemente Sie in Ihren Vorlagen oder Definitionen definieren können. Mit zunehmender Vertrautheit mit der Automatisierung ist es jedoch eine bewährte Vorgehensweise, alles als Code zu definieren, was Ihre Umgebung betrifft. Auf diese Weise können Sie einen konsistenten, getesteten und genehmigten Prozess für alle Ihrer Azure-Konfiguration verwenden. Und da der Code in einem Git-Repository mit einer Versionsangabe versehen und nachverfolgt wird, können Sie überprüfen, wie sich Ihre Azure-Umgebung im Laufe der Zeit verändert hat. Sie können das Git-Repository verwenden, um den Verlauf jeder Änderung nachzuverfolgen.

Nehmen wir z. B. an, Sie müssen Ihre Azure Monitor-Warnungen konfigurieren. Auf den ersten Blick könnten Sie meinen, dass die Verwendung der Automatisierung für die Bereitstellung von Warnungen nicht sinnvoll ist. Warnungen sind jedoch ein wichtiger Bestandteil Ihrer Azure-Konfiguration. Wenn eine Warnung nicht ordnungsgemäß erstellt wird, verpassen Sie möglicherweise Benachrichtigungen über kritische Produktionsprobleme. Durch die Definition Ihrer Warnungen im Code:

• Ihre Teammitglieder können die Warnungen und deren Konfiguration überprüfen.
• Sie können die Warnungen zunächst in Nichtproduktionsumgebungen bereitstellen, um sie zu testen.
• Änderungen an Ihrer Azure-Konfiguration können vollständig nachverfolgt werden.

Umgebungen

Wenn Sie planen, Ihre Infrastruktur automatisch bereitzustellen, ist es hilfreich, die Umgebungen aufzulisten, die Sie verwenden möchten. In vielen Organisationen gibt es eine Vielzahl von Umgebungstypen, die jeweils unterschiedliche Merkmale aufweisen. Zum Beispiel:

• In einigen Umgebungen wird Produktionscode ausgeführt, während in anderen Umgebungen Nichtproduktionsversionen desselben Codes (möglicherweise mit anderen Konfigurationen) ausgeführt werden.
• Manche Umgebungen sind langlebig und sollen nie gelöscht werden. Andere sind kurzlebig, d. h. sie werden automatisch erstellt und zerstört, wenn sie nicht mehr gebraucht werden.
• Einige Umgebungen werden von Ihrem Infrastruktur- oder Softwareentwicklungsteam genutzt. Andere werden von Ihrem Sicherheitsteam oder sogar von Ihrem Vertriebsteam verwendet, wenn es potenziellen Kunden ein Produkt vorführen muss.

Überlegen Sie, welche Umgebungen Ihr Spielwarenunternehmen für Ihre Website nutzen könnte:

Wenn Sie Änderungen an Ihrer Anwendung oder Ihrer Infrastruktur vornehmen und committen, stellt Ihre Pipeline die Änderungen in einer Reihe von Nichtproduktionsumgebungen bereit: Entwicklung, Test und Staging. Sie können auch manuelle Genehmigungsschritte an bestimmten Punkten vorsehen, damit bestimmte Teammitglieder die Konfiguration überprüfen oder das Pipelineprotokoll einsehen können, bevor die Bereitstellung fortgesetzt wird. Anschließend stellt die Pipeline Ihre Änderungen in der Produktionsumgebung bereit.

Zusätzlich zu diesen Umgebungen hat Ihr Vertriebsteam seine eigene Demoumgebung, die es für Kundengespräche nutzt. Das Vertriebsteam verwendet eine Kopie der Produktionsumgebung, um seine Demoumgebung zu erstellen. Ihre Sicherheits- und Testteams erstellen gelegentlich temporäre Kopien der Produktionsumgebung für Penetrationstests bzw. Leistungstests.

Auch Ihr Entwicklungsteam verfügt über eigene Umgebungen. Es gibt Sandbox-Instanzen, die Mitglieder des Entwicklungsteams nutzen können, wenn sie neue Funktionen erkunden oder mit Azure-Diensten experimentieren. Das Entwicklungsteam erstellt außerdem PR-Überprüfungsumgebungen für jeden GitHub-Pull Request, den es überprüft und zusammenführt.

Kontrollierte Umgebungen

In einigen dieser Umgebungen ist es sinnvoll, einen formalen Prozess zur Überprüfung und Anwendung von Änderungen vorzuschreiben. Umgebungen dieses Typs werden als kontrollierte Umgebungen bezeichnet. Die Produktionsumgebung sollte immer kontrolliert werden. Es empfiehlt sich auch, die Kontrollmechanismen auch auf einige der Nichtproduktionsumgebungen anzuwenden. Auf diese Weise können Sie sicherstellen, dass alle Einschränkungen, die die Kontrollmechanismen mit sich bringen, gut verstanden und vor der Bereitstellung in der Produktionsumgebung getestet werden.

Im Gegensatz dazu gibt es in unkontrollierten Umgebungen nicht viele oder gar keine formellen Kontrollen. Sie können den gleichen Code und eine ähnliche Konfiguration wie Ihre anderen Umgebungen aufweisen, aber sie erlauben mehr Experimente und Ad-hoc-Konfigurationsänderungen. In einer unkontrollierten Umgebung können Benutzer die Konfiguration über das Azure-Portal oder durch direkte Ausführung von Azure CLI-/Azure PowerShell-Befehlen ändern. Möglicherweise können sie auch Ressourcen erstellen, ohne das von der Organisation genehmigte Verfahren anzuwenden. Änderungen, die in unkontrollierten Umgebungen vorgenommen werden, müssen im Code erfasst werden, bevor sie in kontrollierten Umgebungen wie der Produktionsumgebung angewendet werden können.

Hinweis

Manchmal kann eine Umgebung tatsächlich mehrere physische Umgebungen oder Bereitstellungen repräsentieren. Wenn Sie beispielsweise kurzlebige Umgebungen für die Überprüfung von Pull Requests erstellen, können mehrere separate Umgebungen gleichzeitig aktiv sein, da Ihr Team mehrere Pull Requests geöffnet hat. Für die Planung Ihrer Umgebungen können Sie sie jedoch als gleichwertig betrachten, da sie die gleichen Merkmale und Kontrollen aufweisen.

Nach einigen Diskussionen mit Ihrem Team legen Sie fest, welche Umgebungen kontrolliert und welche unkontrolliert sind. Sie entscheiden auch, wer Besitzer der jeweiligen Umgebung ist.

Umgebungsname	BESCHREIBUNG	Besitzer	Lebensdauer	Steuerungsebene
Entwicklung	Integriert Änderungen von mehreren Entwicklern in eine einzelne Umgebung.	Betriebsteam	Langlebig	Kontrolliert
Testen	Eine Umgebung zum Ausführen manueller und automatisierter Tests für Änderungen.	Betriebsteam	Langlebig	Kontrolliert
Staging	Dies ist die endgültige Nichtproduktionsumgebung, in der Änderungen vor der Übernahme in die Produktionsumgebung bereitgestellt werden (mit einer produktionsähnlichen Konfiguration).	Betriebsteam	Langlebig	Kontrolliert
Bereitstellung	Führt Ihre Produktionsworkloads aus.	Betriebsteam	Langlebig	Kontrolliert
Demo	Wird vom Vertriebsteam verwendet, um das Produkt neuen Kunden vorzustellen.	Vertriebsteam	Langlebig	Unkontrolliert
Leistungstests	Dynamisch erstellt als Duplikat der Produktionsumgebung für die Ausführung von Leistungs- und Belastungstests, und dann gelöscht, wenn die Tests abgeschlossen sind.	Testteam	Kurzlebig	Unkontrolliert
Penetrationstests	Dynamisch erstellt als Duplikat der Produktionsumgebung für die Ausführung von Penetrations- und Sicherheitstests, und dann gelöscht, wenn die Tests abgeschlossen sind.	Sicherheitsteam	Kurzlebig	Unkontrolliert
PR-Überprüfungen	Diese Umgebung wird dynamisch für jeden Pull Request erstellt, den ein Teammitglied zur Änderung der Anwendung oder Infrastruktur erstellt. Die Umgebung wird gelöscht, wenn der Pull Request geschlossen wird.	Entwicklungsteam	Kurzlebig	Unkontrolliert
Sandboxes für die Entwicklung	Von Mitgliedern des Entwicklungsteams zum Experimentieren oder Erkunden erstellt und dann gelöscht, wenn sie nicht mehr benötigt werden.	Entwicklungsteam	Kurzlebig	Unkontrolliert

Die vorherige Liste von Umgebungen ist nur ein Beispiel. In Ihrem eigenen Unternehmen müssen Sie entscheiden, welche Umgebungen Sie verwenden, wie lange diese bestehen sollen und welches Maß an Kontrolle jede Umgebung benötigt.

Tipp

Das Linten, Testen und Überprüfen Ihres Infrastrukturcodes ist viel einfacher, wenn Sie diese Prozesse bereits in einer frühen Phase der Bereitstellung anwenden, anstatt sie erst später hinzuzufügen und eine Menge fehlerhaften Code korrigieren zu müssen.

Ebenso ist es viel einfacher, mit Sicherheitskontrollen zu arbeiten, wenn sie von Anfang an vorhanden sind und auch auf einige Ihrer Nicht-Produktionsumgebungen angewendet werden. Auf diese Weise gewöhnt sich Ihr Team an die Arbeit in einer kontrollierten Umgebung.

Während der gesamten Lernpfade haben wir einige dieser Konzepte schrittweise eingeführt. Es ist oft eine gute Idee, diese Elemente so früh wie möglich in den Bereitstellungsprozess aufzunehmen.

Isolation der einzelnen Umgebungen

Es ist wichtig, die einzelnen Umgebungen voneinander zu trennen und sie so weit wie möglich eigenständig zu halten. Die Verwendung dedizierter Azure-Abonnements für jede Umgebung kann hilfreich sein, aber Sie müssen trotzdem darauf achten, dass Ihre Umgebungen getrennt bleiben.

Vermeiden Sie Verbindungen von einer Umgebung zur anderen. Nehmen Sie beispielsweise kein Peering für das virtuelle Netzwerk einer Produktionsumgebung mit dem virtuellen Netzwerk einer Nichtproduktionsumgebung vor. Andernfalls kann es leicht passieren, dass jemand versehentlich Produktionsdaten in einer Nichtproduktionsumgebung ändert oder vertrauliche Produktionsdaten an eine Nichtproduktionsumgebung weitergibt.

Überprüfungen und Gates

Im Laufe des Bereitstellungsprozesses sollte eine Reihe von Überprüfungen durchgeführt werden, um Ihre Konfidenz hinsichtlich der Bereitstellung zu erhöhen. Sie müssen die Überprüfungen ermitteln, die für jede Ihrer Umgebungen, die Ihre Bereitstellungen durchlaufen, sinnvoll sind.

Zu den Überprüfungen der Infrastruktur gehören häufig:

• Code Reviews
• Bereitstellung Ihres überprüften Codes in kurzlebigen Umgebungen und Ausführung automatisierter oder manueller Tests in diesen Umgebungen.
• Linten
• Preflight-Überprüfung
• Manuelle Tests
• Manuelle Genehmigung
• Automatisierte Funktionstests
• Automatisierte Buildüberprüfungstests
• Warten auf Integritätssignale aus einer vorherigen Umgebung, bevor zur nächsten Umgebung übergegangen wird.

Einige dieser Prüfungen können Sie im Rahmen Ihres Bereitstellungsprozesses mehrfach durchführen, z. B. für jede kontrollierte Umgebung.

Tipp

Wenn Sie Ihren Bereitstellungsprozess entwerfen, listen Sie alle Schritte auf, die Sie durchführen müssen, egal wie klein oder offensichtlich sie sind. Seien Sie so detailliert wie möglich. Vielleicht werden Sie nicht gleich alles automatisieren, aber diese Vorgehensweise wird Ihnen helfen, eine Blaupause für Ihre zukünftigen automatisierten Bereitstellungsprozesse zu erstellen.

Ein Gate ist eine automatisierte oder manuelle Überprüfung, die erfolgreich sein muss, damit die Bereitstellung fortgesetzt werden kann.

Benutzereingriff

Es ist ratsam, so viele Überprüfungen wie möglich während des Code Reviews und der Bereitstellungsprozesse zu automatisieren. Es kann jedoch sein, dass Ihr Unternehmen eine manuelle Genehmigung für die Bereitstellung in der Produktionsumgebung oder anderen kontrollierten Umgebungen benötigt.

Wenn Sie manuelle Genehmigungsgates für Bereitstellungen verwenden, beachten Sie die folgenden empfohlenen Vorgehensweisen:

• Legen Sie eindeutig fest, wer eine Bereitstellung genehmigen darf. Verwenden Sie Microsoft Entra-Gruppen, um genehmigende Personen zu definieren, anstatt einzelne Benutzer anzugeben. Sie können die Liste der Genehmigenden in Zukunft problemlos ändern.
• Sorgen Sie für einen Prozess für Notfallbereitstellungen. Planen Sie, wer eine Bereitstellung genehmigen kann, wenn die normalen genehmigenden Personen nicht verfügbar sind. Eine Notfallbereitstellung muss vielleicht mitten in der Nacht oder während der Urlaubszeit erfolgen.
• Beschränken Sie den menschlichen Eingriff auf die Genehmigung oder Ablehnung einer Bereitstellung. Vermeiden Sie es, dass Mitarbeiter einen der Bereitstellungsvorgänge ausführen müssen, es sei denn, es gibt einen Schritt, den Sie nicht automatisieren können.

Governance

Azure bietet Tools und Funktionen, die Sie bei der Verwaltung Ihrer Umgebung unterstützen, darunter:

• Azure Policy, um Ressourcen zu erkennen, die auf eine Art und Weise konfiguriert wurden, die nicht mit den Anforderungen Ihres Unternehmens übereinstimmt. So kann auch verhindert werden, dass Ressourcen auf eine Art und Weise erstellt oder neu konfiguriert werden, wodurch diese nicht mehr konform sind.
• Sperren, um zu verhindern, dass wichtige Ressourcen geändert oder gelöscht werden.
• Verwaltungsgruppen, die Ihnen helfen, Ihre Azure-Abonnements zu organisieren und rollenbasierte Zugriffssteuerung und Richtlinien in Ihren Umgebungen einheitlich zu konfigurieren.
• Azure Monitor, um Metriken und Protokolle Ihrer Ressourcen aufzuzeichnen, sie in Dashboards darzustellen und Sie automatisch zu alarmieren, wenn sie von Ihren erwarteten Werten abweichen.

Ziehen Sie beim Aufbau Ihres Azure-Bestands die Verwendung von Azure-Zielzonen in Betracht. Durch die Verwendung einer Zielzone können Sie von Anfang an Governance in Ihre Umgebung integrieren. Viele Zielzonen enthalten vorgefertigte Bicep- und Terraform-Dateien, die Sie bei der Konfiguration Ihrer Umgebung unterstützen. Links zu weiteren Informationen finden Sie in der Zusammenfassung.