Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen
Dieser Artikel beschreibt, wie Cloudplattform-Teams Schutzmaßnahmen implementieren können, um Anwendungsumgebungen in Azure-Zielzonen zu verwalten. Außerdem wird erläutert, wie verschiedene Anwendungsentwicklungsumgebungen mit ihrem Framework ausgerichtet werden. Ein wichtiger Aspekt beim Erstellen der richtigen Umgebung ist das Platzieren von Abonnements in den richtigen Verwaltungsgruppen.
Die Grundlage setzen
Entwicklungsteams erfordern die Möglichkeit, schnell durch Iterationen zu gehen, und Cloud-Governance- und Plattformteams müssen Organisationsrisiken, Compliance und Sicherheit im großen Maßstab verwalten. Sie können Anwendungsumgebungen ordnungsgemäß verwalten, indem Sie sich auf zwei wichtige Designprinzipien der Azure-Zielzone konzentrieren: richtliniengesteuerte Governance und Abonnementdemokratisierung. Diese Prinzipien stellen grundlegende Schutzmaßnahmen dar und beschreiben, wie Steuerelemente an Anwendungsteams delegiert werden können. Die Anwendungsteams verwenden Azure Well-Architected Framework-Anleitungen, um ihre Arbeitsauslastung zu planen. Sie stellen ihre eigenen Zielzonenressourcen bereit und verwalten sie, und das Plattformteam steuert die Ressourcen, indem sie Azure-Richtlinien zuweisen.
Es ist wichtig, Sandbox-Abonnements für halbgesteuerte Ressourcen bereitzustellen, damit Anwendungsteams mit Technologien und Funktionen experimentieren können.
Wenn Anwendungsbesitzer Abonnementverkauf oder andere Abonnementerstellungsprozesse verwenden, müssen sie wissen, wie Abonnements für mehrere Entwicklungsumgebungen angefordert werden können.
In diesem Artikel wird die Azure-Zielzone beschrieben, einschließlich der Verwaltungsgruppen, Richtlinien und der Architektur der gemeinsamen Plattform, sowie dem Workload oder der Anwendungszielzone.
Hinweis
Die Anleitung in diesem Artikel richtet sich nur an Workload- oder Anwendungszielzonen. Informationen zur Test- und Umgebungstrennung für die Azure-Zielzonenplattform selbst finden Sie unter Testansatz für Azure-Zielzonen, in dem der Canary-Ansatz beschrieben wird.
In der Praxis können Sie eine beliebige Anzahl und beliebe Typen der phasenweisen Umgebung verwenden. In diesem Artikel wird auf die folgenden phasenweisen Umgebungen verwiesen.
| Environment | Beschreibung | Verwaltungsgruppe |
|---|---|---|
| Sandbox | Die Umgebung, die für schnelle Innovation von Prototypen, aber nicht für produktionsgebundene Konfigurationen verwendet wird | Sandbox-Verwaltungsgruppe |
| Entwicklung | Die Umgebung, die zum Erstellen potenzieller Releasekandidaten verwendet wird | Archetype-Verwaltungsgruppe, z. B. Unternehmen oder Online |
| Test | Die Umgebung, die zum Durchführen von Tests verwendet wird, einschließlich Komponententests, Benutzerakzeptanztests und Tests zur Qualitätssicherung | Archetype-Verwaltungsgruppe, z. B. Unternehmen oder Online |
| Produktion | Die Umgebung, die verwendet wird, um Kunden einen Mehrwert zu bieten | Archetype-Verwaltungsgruppe, z. B. Unternehmen oder Online |
Weitere Informationen finden Sie in den Videos Umgang mit Entwicklung, Test- und Produktionsumgebungen für Anwendungsworkloads und Wie viele Abonnements sollte ich in Azure verwenden?
Umgebunen, Abonnements und Verwaltungsgruppen
Als Voraussetzung für diesen Abschnitt lesen Sie Entwurfsbereich der Ressourcenorganisation.
Sie müssen Ihre Abonnements ordnungsgemäß organisieren, wenn Sie Azure-Zielzonenpraktiken einführen. Im Idealfall sollte jede Anwendungsumgebung über ein eigenes Abonnement verfügen. Diese Methode stellt Sicherheits- und Richtlinienkontrollen bereit, die die Umgebungen isoliert halten. Sie beschränkt potenzielle Probleme auf eine Umgebung.
Separate Abonnements weisen die gleichen Richtlinien auf der Archetypebene auf. Bei Bedarf können Anwendungsbesitzer abonnementspezifische Richtlinien zuweisen, um anwendungs- und umgebungsspezifisches Verhalten zu erzwingen.
Einige Anwendungsarchitekturen erfordern, dass Dienste zwischen Umgebungen gemeinsam genutzt werden. Wenn dies der Fall ist, können Sie ein Einzelabonnement für mehrere Umgebungen verwenden. Es wird empfohlen, dass Workloadbesitzer mit Cloudplattformteams zusammenarbeiten, um festzustellen, ob ein Einzelabonnement für mehrere Umgebungen erforderlich ist.
Verwenden Sie ein Einzelabonnement mehrere Anwendungsumgebungen, wenn:
Die Umgebungen können nicht in ihren eigenen Abonnements isoliert werden.
Die Umgebungen verfügen über dieselben Teams, die funktionalen Rollen zugewiesen sind, z. B. Netzwerkbetreiber.
Die Umgebungen können dieselben Richtlinien verwenden.
Wenn sich ein Anwendungs- oder Dienst-Workload in einem einzigen Abonnement befinden muss und Sie Änderungen an den Richtlinien vornehmen müssen, die für jede Umgebung gelten, können Sie:
Erstellen Sie eine neue archetyporientierte Verwaltungsgruppe unter der Verwaltungsgruppe für Zielzonen. Weitere Informationen finden Sie im Abschnitt Hierarchie der Verwaltungsgruppen in diesem Artikel.
Verwenden Sie Sandboxabonnements für Entwicklungsaktivitäten. Sandboxes verfügen über einen weniger restriktiven Richtliniensatz.
Verwenden Sie Richtlinien, die auf Abonnementebene anstatt der Ebene der Verwaltungsgruppen angewendet werden. Fügen Sie Tags zu Ihren Richtliniendefinitionen hinzu, um sie zu filtern und Richtlinien auf die richtige Umgebung anzuwenden. Sie können Richtlinien auch bestimmten Ressourcengruppen zuweisen oder ausschließen.
Sie können Richtlinien während des Prozesses der Erstellung des Abonnements als Teil des Abonnementverkaufs zuweisen.
Bei Richtlinien, die Sie zur Kostenkontrolle implementieren, können Sie die Richtliniendefinition bei Bedarf auf Abonnementebene anwenden, soweit erforderlich. Oder Sie können den Besitzer der Zielzone für Kosten verantwortlich machen, was echte Autonomie bietet. Weitere Informationen finden Sie unter Plattformautomatisierung und DevOps.
Warnung
Im Gegensatz zu Richtlinien und Steuerelementen auf Ebene der Verwaltungsgruppen können abonnementbasierte Richtlinien und Tags von Einzelpersonen mit erhöhten Berechtigungen für das Abonnement geändert werden. Administratoren mit entsprechenden Rollen können diese Steuerelemente umgehen, indem sie Richtlinien ausschließen, Richtlinien ändern oder die Tags für Ressourcen ändern.
Daher sollten Sie keine Tags in den Definitionen von sicherheitsrelevanten Richtlinien anwenden. Weisen Sie außerdem keine Berechtigungen wie immer aktiv für die folgenden Aktionen zu:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
Sie können diese Aktionen mithilfe von Privileged Identity Management (PIM) steuern.
Verwaltungsgruppenhierarchie
Vermeiden Sie komplizierte Verwaltungsgruppenhierarchien. Sie können häufige Änderungen erfordern, ineffizient skalieren und keinen Mehrwert bieten. Um diese potenziellen Probleme zu vermeiden, sind Verwaltungsgruppen von Azure-Zielzonen an Archetypen ausgerichtet. Weitere Informationen finden Sie unter Verwaltungsgruppe und Abonnementorganisation.
Die Ausrichtung an Archetypen bedeutet, dass Verwaltungsgruppen nur für spezifische Workloadarchetypen erstellt werden. In der konzeptionellen Architektur verfügt die Verwaltungsgruppe fürZielzonen beispielsweise über die untergeordneten Verwaltungsgruppen Unternehmen und Online. Diese untergeordneten Verwaltungsgruppen richten sich an unterschiedliche Archetypmuster für die Workloads aus, die sie enthalten. Die untergeordneten Verwaltungsgruppen konzentrieren sich auf Anforderungen an die Hybridkonnektivität (VPN/Azure ExpressRoute), z. B. nur intern (unter Ausschluss von öffentlich zugänglichen Anwendungen und Diensten).
Mit Ausnahme von Sandbox-Abonnements sollten verschiedene Anwendungsumgebungen denselben Archetyp für die Bereitstellung verwenden. Auch wenn Umgebungen über mehrere Abonnements verteilt sind, werden sie innerhalb derselben einzelnen Verwaltungsgruppe (Unternehmen oder Online) basierend auf dem Archetyp der Verwaltungsgruppe und den Anforderungen gehalten.
Sie können Sandbox-Abonnements für die unstrukturierte Entwicklung verwenden, z. B. persönliche Labs oder für einen Workload, der keinen Archetyp hat. Ein Anwendungs- oder Dienstworkloadteam benutzt eine Sandbox-Verwaltungsgruppe, um verschiedene Azure-Dienste zu testen und zu ermitteln, was für ihre Anforderungen am besten funktioniert. Sobald sie über die Dienste entschieden haben, können sie eine Zielzone (am richtigen Workloadarchetyp ausgerichtete Verwaltungsgruppe in der Verwaltungsgruppenhierarchie für Zielzonen) für das Team bereitstellen.
Die Sandbox-Umgebungen können für bestimmte Anwendungen verwendet werden, oder ein Workloadteam kann sie für Experimente verwenden.
Weitere Informationen finden Sie unter:
- Verwaltungsgruppen.
- Entwurfsbereich der Ressourcenorganisation.
- Anpassen der Architektur der Azure-Zielzonen an die Anforderungen.
Herausforderungen im Zusammenhang mit der umgebungsbasierten Verwaltungsgruppe
Verwaltungsgruppen für Umgebungen innerhalb von Archetypen können zusätzlichen Verwaltungsaufwand verursachen und minimalen Wert bieten.
Die Zielzonen-Verwaltungsgruppe sollte universelle Richtlinien haben, die für die untergeordneten Verwaltungsgruppen Unternehmen und Online Schutzmaßnahmen erzwingen. Unternehmen und Online verfügen über einzigartige Richtlinien, um Unternehmensrichtlinien für öffentliche und private Workloads durchzusetzen.
Viele Organisationen erstellen separate Verwaltungsgruppen für SDLC-Umgebungen (Workload Software Development Lifecycle), um Umgebungsrichtlinien und -kontrollen zuzuweisen. In der Praxis schafft diese Methode mehr Herausforderungen für Arbeitsauslastungsteams, als gelöst werden. SDLC-Umgebungen sollten nicht über unterschiedliche Richtlinien verfügen, daher empfehlen wir keine separaten Verwaltungsgruppen.
Anwendungsbesitzer können die Topologie oder Ressourcenkonfiguration einer Workload ändern, um sie an Richtlinien in mehreren SDLC-Umgebungen auszurichten, durch die sie höhergestuft wird. Diese Methode erhöht das Risiko. Regeln, die für jede Umgebung spezifisch sind, können zu einer schlechten Erfahrung für Entwickler- und Qualitätssicherungsteams führen. Probleme können auch auftreten, wenn eine Anwendung über eine Reihe von Richtlinien als Schutzmaßnahmen verfügt, die in einer Umgebung funktionieren, und die Anwendung wird später in ihrem Höherstufungszyklus einer anderen Gruppe von Richtlinien unterworfen. Möglicherweise müssen Sie Anpassungen an einer Anwendung vornehmen, wenn sich Steuerelemente ändern.
Um diese zusätzliche Arbeit zu verhindern, können Sie einheitliche Richtlinien für die Höherstufung von Code in SDLC-Umgebungen erstellen. Sie sollten keine Richtlinien für jede einzelne Umgebung erstellen, sondern einen konsistenten Satz für alle Entwicklungsumgebungen ohne Sandbox-Umgebungen bereitstellen.
Stellen Sie sich z. B. vor, dass eine Organisation eine Richtlinie definiert, für die Speicherkonten mit bestimmten Firewallregeln konfiguriert werden müssen, um zu verhindern, dass ein Einstieg über öffentliche Netzwerke erfolgt. Stattdessen verwenden die Speicherkonten private Endpunkte innerhalb der Azure-Zielzonennetzwerke für die Kommunikation. Wenn die Entwicklungsumgebung keine solche Richtlinie hat, wird beim Testen der Workload keine Fehlkonfiguration des Speicherkontos gefunden, das den öffentlichen Zugriff zulässt. Die Testbereitstellungen funktionieren in der Entwicklungsumgebung und werden durchlaufen. Wenn die Lösung in eine andere Umgebung höhergestuft wird, die über die Speicherkontorichtlinie verfügt, schlägt die Bereitstellung aufgrund der erzwungenen Richtlinie fehl.
Daher muss das Anwendungsentwicklungsteam seine Bereitstellung und Architektur umarbeiten, nachdem bereits ein erheblicher Aufwand investiert wurde. In diesem Beispiel wird veranschaulicht, wie verschiedene Richtlinien in verschiedenen Umgebungen Probleme verursachen können.
Hinweis
Die folgende Gleichung veranschaulicht, warum Verwaltungsgruppen pro Umgebung und/oder Workload keine gute Skalierung ermöglichen: N Workloads x Z Verwaltungsgruppen = Gesamtanzahl der Verwaltungsgruppen.
Wenn eine Organisation über 30 Workloads verfügt, für die jeweils eine Verwaltungsgruppe und eine untergeordnete Verwaltungsgruppe für Entwicklungs-, Test- und Produktionsumgebungen erforderlich sind, bleibt die Organisation bei:
N = die Anzahl der Workloads/Apps = 30
Z = die Anzahl der Verwaltungsgruppen für die Workloads und Umgebungen (1 für die Workload + 3 für die Umgebungen) = 4
N (30) x Z (4) = 120 (Gesamtanzahl der Verwaltungsgruppen)
Es ist für Anwendungsbesitzer möglicherweise notwendig, dass Richtlinien bei mehreren Umgebungen unterschiedlich angewendet werden. Anwendungsbesitzer benötigen beispielsweise Sicherungskonfigurationen für Produktionsumgebungen, aber nicht für andere Umgebungen.
Einige Richtlinien können als Überwachungsrichtlinien auf Verwaltungsgruppenebene aktiviert werden. Anwendungsteams bestimmen, wie das Steuerelement implementiert wird. Diese Methode verhindert keine Bereitstellungen, schafft aber Bewusstsein und ermöglicht es Anwendungsteams, ihre individuellen Anforderungen zu verwalten. Sie können dann Richtlinien für Unterebenen erstellen oder diese Anforderungen als Codebereitstellungsmodule (IaC) in ihre Infrastruktur integrieren.
In diesem Modell der geteilten Verantwortung überprüft das Plattformteam Praktiken und das Anwendungsteam verwaltet die Implementierung. Dieses Modell kann die Flexibilität von Bereitstellungen verbessern.
Plattformbetreiber müssen zusammen mit dem Anwendungs- oder Dienstworkloadteam (Zielzonenbesitzer) die jeweiligen Anforderungen ermitteln. Die Plattformbetreiber können Abonnements basierend auf den Anwendungsanforderungen und -plänen bereitstellen. Die Plattformbetreiber können auch Produktlinien für verschiedene Workloads festlegen, damit sie Prozesse und Tools für die Abonnementerstellung basierend auf gemeinsamen Anforderungen von Anwendungs- oder Dienstworkloadteams erstellen können.
Szenario: VM-basierte Workloads (Virtual Machine)
Frühe Workloads in Azure-Zielzonen bestehen häufig aus Azure-VMs. Sie können diese Workloads in Azure bereitstellen oder aus vorhandenen Rechenzentren migrieren.
Anstatt VMs in mehreren Umgebungen in einem Einzelabonnement bereitzustellen, können Sie:
Abonnements für jede Anwendungsumgebung einrichtigen, und alle in derselben Archetyp-Verwaltungsgruppe platzieren.
Ein virtuelles Netzwerk für jede Anwendungsumgebung im entsprechenden Abonnement bereitstellen. Die Größe des virtuellen Netzwerks basierend auf der Größe der Anwendungsumgebung ermitteln.
Die VMs in ihrem entsprechenden Abonnement bereitstellen. VMs können bei Bedarf unterschiedliche SKUs und unterschiedliche Verfügbarkeitskonfigurationen für jede Umgebung verwenden.
Verschiedene Anwendungsumgebungsressourcen werden durch unterschiedliche Zugriffssteuerungen geschützt. Wenn Anwendungsentwickler Bereitstellungspipelines einrichten, kann die Identität jeder Pipeline auf die Umgebung beschränkt werden. Diese Konfiguration hilft dabei, die Umgebungen vor versehentlichen Bereitstellungen zu schützen.
Szenario: Azure App Service
Eine Workload mit Umgebungsabonnements, die App Service verwenden, kann Herausforderungen schaffen. Für Anwendungsentwickler ist es eine bewährte Methode für App Service, Bereitstellungsslots für die Verwaltung von Änderungen und Aktualisierungen der Web-App zu verwenden.
Dieses Feature kann jedoch nur für dieselbe App in einem App Service-Plan verwendet werden, der nur innerhalb eines Einzelabonnements verwendet werden kann. Wenn die Plattformbetreiber festlegen, dass die Anwendungsbesitzer separate Abonnements für Entwicklungs-, Test- und Produktionsumgebungen verwenden sollen, ist die Verwaltung des Anwendungsbereitstellungslebenszyklus möglicherweise schwieriger.
In diesem Beispiel ist die beste Option ein einzelnes Abonnement für die Anwendungs- oder Dienstworkload. Anwendungsbesitzer können Azure rollenbasierte Zugriffssteuerung (RBAC) mit PIM auf Ressourcengruppenebene für erhöhte Sicherheit verwenden.