Bereitstellen von Azure-Zielzonen
In diesem Artikel werden die Optionen erläutert, die Ihnen zur Bereitstellung von Plattform- und Anwendungszielzonen zur Verfügung stehen. Plattformzielzonen stellen zentralisierte Dienste bereit, die von Workloads verwendet werden. Anwendungszielzonen sind Umgebungen, die für die Workloads selbst bereitgestellt werden.
Wichtig
Weitere Informationen zu Plattform- und Anwendungslandzonendefinitionen und -implementierungen finden Sie unter Was ist eine Azure-Zielzone? im Cloud Adoption Framework für Azure.
In diesem Artikel werden die Bereitstellungsoptionen für Plattform- und Anwendungszielzonen behandelt.
Auswählen eines Ansatzes für Plattformzielzonen
Die folgenden Optionen für die Plattformbereitstellung bieten einen zielgerichteten Ansatz für Bereitstellung und Betrieb der konzeptionellen Azure-Zielzonenarchitektur, wie im Cloud Adoption Framework beschrieben. Je nach Anpassungen ist die resultierende Architektur für alle hier aufgeführten Bereitstellungsoptionen möglicherweise nicht identisch. Die Unterschiede zwischen den Plattformbereitstellungsoptionen basieren darauf, wie sie unterschiedliche Technologien verwenden, verschiedene Ansätze ergreifen und unterschiedlich angepasst werden.
Optionen für die Standardbereitstellung
Standardbereitstellungsoptionen beziehen sich auf die typische Azure-Nutzung des Unternehmens.
| Bereitstellungsoption für Zielzonen der Azure-Plattform | BESCHREIBUNG |
|---|---|
| Azure-Portal-Bereitstellung | Eine auf dem Azure-Portal basierende Bereitstellung, die eine vollständige Implementierung der konzeptionellen Azure-Zielzonenarchitektur mit zielgerichteten Konfigurationen für wichtige Komponenten wie Verwaltungsgruppen und -richtlinien bietet. |
| Bicep-Bereitstellung | Eine modulare, auf Infrastructure-as-Code basierende Bereitstellung, bei der jedes Bicep-Modul eine Kernfunktion der konzeptionellen Azure-Zielzonenarchitektur kapselt. Während die Module einzeln bereitgestellt werden können, schlägt der Entwurf die Verwendung von Orchestratormodulen vor, um die Komplexität der Bereitstellung verschiedener Topologien mit den Modulen zu kapseln. Die Bicep-Bereitstellung unterstützt die öffentliche Azure-Cloud, Azure China 21Vianet-Regionen und Azure US Government-Clouds. |
| Terraform-Bereitstellung | Diese auf Infrastructure-as-Code basierende Bereitstellung stellt ein Terraform-Orchestratormodul zur Verfügung und ermöglicht Ihnen auch, jede Plattformfunktion einzeln oder als Ganzes bereitzustellen. |
Varianten und Spezialisierungen
Während die Standardplattform-Bereitstellungsoptionen die unternehmensspezifische Azure-Nutzung abdecken, gibt es einige Bereitstellungsoptionen, die sich auf bestimmte Spezialisierungen konzentrieren.
| Bereitstellungsoption | BESCHREIBUNG |
|---|---|
| Souveräne Landezone | Die souveräne Landezone ist eine Variante der Azure-Landezonen, die für Organisationen vorgesehen sind, die erweiterte souveräne Kontrollen benötigen. |
Partnerimplementierungen
Partnerprogramme wie Azure Migrate and Modernize helfen Ihnen dabei, Ihre Plattformzielzone speziell an die Anforderungen Ihrer Organisation anzupassen und entsprechend zu implementieren. Diese Implementierungen beginnen mit der konzeptionellen Architektur der Azure-Zielzone und helfen Ihnen bei der Gestaltung von Konfigurationen, die speziell auf Ihre Cloud-Einführungsstrategie, die organisatorische Topologie und die angestrebten Ergebnisse abgestimmt sind.
Enterprise Policy as Code (EPAC) für die Richtlinienverwaltung
Enterprise Policy as Code (EPAC) ist eine alternative Methode zum Bereitstellen, Verwalten und Betreiben von Azure Policy im gesamten Azure-Bestand Ihrer Organisation. Sie können EPAC anstelle der Standardplattformoptionen verwenden, um die Richtlinien in einer Azure-Zielzonenumgebung zu verwalten. Weitere Informationen zum Integrationsansatz finden Sie unter Integrating EPAC with Azure Landing Zones (Integrieren von EPAN in Azure-Zielzonen).
Unternehmensrichtlinien als Code eignen sich am besten für fortgeschrittene und ausgereiftere Kunden von DevOps und Infrastruktur als Code. EPAC kann jedoch bei Bedarf und nach entsprechender Auswertung von Kundenunternehmen jeder Größenordnung verwendet werden. Lesen Sie zuerst Wer sollte EPAC verwenden?, um zu ermitteln, ob diese Option für Sie geeignet ist.
Hinweis
Vergleichen Sie den Lebenszyklus und die Flexibilität der beiden Ansätze, bevor Sie entscheiden, welchen Ansatz Sie langfristig verwenden. Beginnen Sie mit der Auswertung der nativen Richtlinienverwaltung, die in der unter Standardplattformoptionen beschriebenen Standardimplementierung bereitgestellt wird. Wenn diese Implementierung nicht so aussieht, als wäre sie ideal für Ihre Governanceanforderungen, führen Sie eine MVP oder einen Machbarkeitsnachweis mithilfe von EPAC durch. Es ist wichtig, dass Sie Optionen vergleichen, validieren und bestätigen, bevor Sie einen Ansatz implementieren, da es ein komplexer Prozess ist, Governance-Methoden für Richtlinien zu ändern, sobald sie etabliert sind.
Betreiben von Azure-Zielzonen
Nachdem Sie die Plattformlandungszone bereitgestellt haben, müssen Sie sie betreiben und verwalten. Weitere Informationen finden Sie in den Anleitungen unter Sicherstellen, dass Ihre Azure-Zielzone auf dem neuesten Stand ist.
Azure Governance-Schnellansicht
Azure Governance Visualizer soll Ihnen helfen, einen ganzheitlichen Überblick über Ihre technische Azure-Governanceimplementierung zu erhalten, indem Sie die Punkte verbinden und anspruchsvolle Berichte bereitstellen.
Abonnementverkauf
Nachdem die Zielzone und Governancestrategie der Plattform eingerichtet wurden, muss als Nächstes Konsistenz hinsichtlich der Erstellung und Inbetriebnahme von Abonnements für Workloadbesitzende gewährleistet werden. Die Demokratisierung von Abonnements ist ein Entwurfsprinzip von Azure-Zielzonen mit Abonnements als Verwaltungs- und Skalierungseinheiten. Dieser Ansatz beschleunigt Anwendungsmigrationen und die Entwicklung neuer Anwendungen.
Abonnementverkauf standardisiert den Prozess, den Plattformteams verwenden, damit Workloadteams Abonnements anfordern und Plattformteams diese Abonnements bereitstellen und verwalten können. Es ermöglicht Anwendungsteams, Zugriff auf Azure in konsistenter und geregelter Weise zu erhalten, um sicherzustellen, dass die Anforderungserhebung abgeschlossen ist.
Außerdem verfügen Organisationen häufig über mehrere verschiedene Arten von Abonnements, die ihren Mandanten angeboten werden können und in der Branche häufig als „Produktlinien“ bezeichnet werden. Weitere Informationen zu empfohlenen „Produktlinien“ für Ihre Organisation finden Sie unter Einrichten gemeinsamer Produktlinien für Abonnementverkauf.
Befolgen Sie zunächst den Implementierungsleitfaden unter Implementierungsleitfaden für den Abonnementverkauf. Überprüfen Sie dann die folgenden Infrastruktur-as-Code-Module, die Flexibilität bieten, um Ihren Implementierungsanforderungen gerecht zu werden.
| Bereitstellungsoption | BESCHREIBUNG |
|---|---|
| Bicep-Modul für Abonnementverkauf | Die Bicep-Module für den Abonnementverkauf sind so konzipiert, dass sie die Bereitstellung der einzelnen Anwendungszielzonen basierend auf der jeweiligen Workloadkonfiguration orchestrieren. Sie können manuell oder als Teil der Automatisierung ausgeführt werden. |
| Terraform-Modul für Abonnementverkauf | Diese Module orchestrieren die Bereitstellung der einzelnen Anwendungszielzonen mithilfe von Terraform. |
Architekturen von Anwendungszielzonen
Anwendungszielzonen bestehen aus mindestens einem Abonnement, das als genehmigtes Ziel für Ressourcen einer Workload bereitgestellt wird, die Anwendungsteams gehören. Eine Workload kann von in Plattformzielzonen bereitgestellten Diensten profitieren oder von diesen zentralen Ressourcen isoliert werden. Die Anwendungslandezonen sollten für zentral verwaltete Anwendungen, dezentrale Workloads im Besitz von Anwendungsteams und zentral verwaltete Hostingplattformen wie Azure Kubernetes Service (AKS) verwendet werden, die Anwendungen für mehrere Geschäftseinheiten hosten können. Außer bei ungewöhnlichen Einschränkungen enthalten Abonnements von Anwendungszielzonen nur Ressourcen aus einer einzigen Workload oder logischen Anwendungsgrenze, z. B. ihrem Lebenszyklus oder ihrer Kritikalitätsklassifizierung.
Workload-Teams kommunizieren die Anforderungen ihrer Workload über einen formalen Prozess, der vom Plattformteam eingerichtet wurde. Das Plattformteam stellt im Allgemeinen ein leeres Abonnement bereit, das in alle erforderlichen Governancerichtlinien eingebunden ist. Ein Workload-Architekt entwirft dann eine Lösung, die innerhalb der Einschränkungen dieser Anwendungs-Zielzone funktioniert und dabei gemeinsame Plattformfunktionen wie Firewalls und standortübergreifendes Routing nutzt, wo dies praktisch ist.
Es ist möglich, dass ein Architekt eine Referenzarchitektur anpassen kann, die nicht speziell für eine Anwendungslandungszone konzipiert ist. Microsoft Learn enthält jedoch auch Leitfäden zu Anwendungs- und Datenplattformen für Workloadteams, die sich speziell auf Kontexte von Anwendungszielzonen beziehen. Plattformteams sollten sich der Anleitung bewusst sein, die für Arbeitsauslastungsteams verfügbar ist, damit das Plattformteam die Arbeitsauslastungstypen und Merkmale antizipieren kann, die in der Organisation vorhanden sein könnten.
| Architektur von Anwendungszielzonen | BESCHREIBUNG |
|---|---|
| Azure App Service-Umgebung | Bewährte Empfehlungen und Überlegungen zu mehrinstanzenfähigen Anwendungsfällen und App Service-Umgebungsanwendungsfällen mit einer Referenzimplementierung |
| Azure API Management (APIM) | Bewährte Empfehlungen und Überlegungen für die Bereitstellung einer internen API-Verwaltungsinstanz als Teil einer Referenzimplementierung. Das Szenario verwendet das Azure-Anwendungsgateway, um eine sichere Zugriffssteuerung bereitzustellen und verwendet Azure Functions als Back-End. |
| Azure Arc für Hybrid- und Multicloudszenarien | Server mit Azure Arc-Unterstützung, Kubernetes und Azure Arc-fähiges SQL Managed Instance. |
| Azure Container Apps | Dieser Leitfaden für Azure-Container-Apps beschreibt den strategischen Entwurfspfad und definiert den technischen Zielzustand für die Bereitstellung von Azure-Container-Apps. Ein dediziertes Workloadteam besitzt und betreibt diese Plattform. |
| Azure Data Factory | Erfahren Sie, wie Sie ein traditionelles Medallion Lakehouse in einer Anwendungszielzone hosten. |
| Azure OpenAI-Chatworkload | Beschreibt, wie eine typische Azure OpenAI-Chatanwendung in Azure-Zielzonen integriert wird, um zentralisierte, gemeinsame Ressourcen zu nutzen sowie gleichzeitig Governance- und Kosteneffizienzstandards einzuhalten, und bietet Workloadteams Leitfäden zur Bereitstellung und Verwaltung. |
| Azure Kubernetes Service (AKS) | Leitfaden und zugehörige Infrastructure-as-Code-Vorlagen, die den strategischen Entwurfspfad und technischen Zielzustand für eine AKS-Bereitstellung darstellen, die in einer Anwendungszielzone ausgeführt wird |
| Azure Red Hat OpenShift | Eine Open-Source-Sammlung von Terraform-Vorlagen für eine optimale Azure Red Hat OpenShift-Bereitstellung (ARO), die Azure- und Red Hat-Ressourcen umfasst. |
| Azure Synapse Analytics | Ein architekturbezogener Ansatz zum Vorbereiten von Anwendungszielzonen für eine typische Unternehmensbereitstellung von Azure Synapse Analytics |
| Azure Virtual Desktop | ARM-, Bicep- und Terraform-Vorlagen, auf die beim Entwerfen von Azure Virtual Desktop-Bereitstellungen verwiesen werden sollte, z. B für das Erstellen von Hostpools, Netzwerktechnologie, Speicher, Überwachung und Add-Ons |
| Azure Virtual Machines | Diese Architektur erweitert den Leitfaden von der Baselinearchitektur virtueller Azure-Computer (VMs) auf eine Anwendungszielzone und enthält Anleitungen zur Einrichtung von Abonnements, zur Patchkonformität und zu sonstigen Aspekten der Organisationsgovernance. |
| Azure-VMware-Lösung | ARM-, Bicep- und Terraform-Vorlagen, die nützlich beim Entwerfen von VMware-Bereitstellungen sind, z. B. für private Clouds für Azure-VMware-Lösung, Jumpboxes, Netzwerke, Überwachung sowie Add-Ons |
| Citrix auf Azure | Die Designrichtlinien für das Cloud Adoption Framework für Citrix Cloud in einer Azure-Zielzone im Unternehmensmaßstab viele Designbereiche ab. |
| Red Hat Enterprise Linux (RHEL) auf Azure | Die Zielzone für Red Hat Enterprise Linux (RHEL) in Azure ist eine Open-Source-Sammlung von Architekturanleitungen und Referenzimplementierungsempfehlungen, die zum Entwerfen von RHEL-basierten Workloads in Microsoft Azure verwendet werden. |
| HPC-Workloads (High Performance Computing) | Eine lückenlose HPC-Clusterlösung in Azure, die Tools wie Terraform, Ansible und Packer verwendet. Sie bietet bewährte Methoden für Azure-Zielzonen, u. a. für die Implementierung von Identitäten, Jumpboxzugriff und Autoskalierung. |
| Unternehmenskritische Workloads | Erklärt, wie eine als unternehmenskritisch klassifizierte Workload für die Ausführung in einer Anwendungszielzone konzipiert werden sollte. |
| SAP-Workloads | Bietet Leitfäden und Empfehlungen für SAP-Workloads, die bewährten Verfahren für Azure-Zielzonen entsprechen. Erstellt Empfehlungen für die Entwicklung von Infrastrukturkomponenten wie Rechnerkapazität, Netzwerke, Speicher, Überwachung und die Erstellung von SAP-Systemen. |
Workloads sind häufig eine Sammlung verschiedener Technologien und Klassifizierungen. Es wird empfohlen, relevante Referenzmaterialien für alle Technologien in Ihrer Workload zu überprüfen. Beispielsweise ist es wichtig, die Anleitungen aus dem Azure OpenAI-Chat und der Azure API-Verwaltung zu verstehen, ob Ihr generatives KI-Szenario vom Hinzufügen eines API-Gateways profitieren würde.