Déployer des zones d’atterrissage Azure
Cet article décrit les options disponibles pour déployer des zones d’atterrissage de plateforme et d’application. Les zones d’atterrissage de plateforme fournissent des services centralisés utilisés par les charges de travail. Les zones d’atterrissage d’application sont des environnements déployés pour les charges de travail elles-mêmes.
Important
Pour plus d'informations sur les définitions et les mises en œuvre des zones d'atterrissage des plateformes et des applications, voir Qu'est-ce qu'une zone d'atterrissage Azure ? dans le cadre d'adoption du cloud pour Azure.
Cet article traite des options de déploiement pour les zones d'atterrissage de plateforme et d'application.
Choisissez une approche de zone d'atterrissage de plate-forme
Les options de déploiement de plateforme suivantes fournissent une approche d'opinion pour déployer et exploiter l'architecture conceptuelle de la zone d'atterrissage Azure, telle que détaillée dans le framework d'adoption du cloud. En fonction des personnalisations, l'architecture résultante peut ne pas être la même pour toutes les options de déploiement énumérées ici. Les différences entre les options de déploiement de la plate-forme sont basées sur la façon dont elles utilisent différentes technologies, adoptent différentes approches et sont personnalisées différemment.
Options de déploiement standard
Les options de déploiement standard correspondent à l'utilisation typique d'Azure par les entreprises.
| Option de déploiement de la zone d'atterrissage de la plateforme Azure | Description |
|---|---|
| Déploiement du portail Azure | Un déploiement basé sur le portail Azure qui fournit une implémentation complète de l'architecture conceptuelle de la zone d'atterrissage Azure, ainsi que des configurations avec opinion pour les composants clés, tels que les groupes de gestion et les stratégies. |
| Déploiement Bicep | Un déploiement modulaire, basé sur l'infrastructure en tant que code, où chaque module Bicep encapsule une capacité essentielle de l'architecture conceptuelle de la zone d'atterrissage Azure. Bien que les modules puissent être déployés individuellement, la conception propose l’utilisation de modules d’orchestrateur pour encapsuler la complexité du déploiement de différentes topologies avec les modules. Le déploiement Bicep prend en charge le cloud public Azure, les régions Azure China 21Vianet et les clouds du gouvernement américain Azure. |
| Déploiement Terraform | Ce déploiement basé sur l’infrastructure en tant que code à l’aide de modules vérifiés Azure pour les zones d’atterrissage de plateforme offre un moyen personnalisable de déployer ALZ avec Terraform. |
Variantes et spécialisations
Alors que les options de déploiement de la plateforme standard répondent à l'utilisation typique d'Azure par les entreprises, il existe des options de déploiement qui se concentrent sur des spécialisations spécifiques.
| Option de déploiement | Description |
|---|---|
| Zone d’atterrissage souveraine | La zone d'atterrissage souveraine est une variante des zones d'atterrissage Azure destinée aux organisations qui ont besoin de contrôles souverains avancés. |
Implémentations partenaires
Les programmes de partenaires tels que Azure Migrate et Modernize peuvent vous aider à concevoir et à mettre en œuvre votre zone d'atterrissage de plateforme spécifique aux besoins de votre organisation. Ces mises en œuvre commencent par l'architecture conceptuelle de la zone d'atterrissage Azure et aident à concevoir des configurations spécifiques à votre stratégie d'adoption du cloud, à la topologie de votre organisation et aux résultats souhaités.
Enterprise policy as code (EPAC) pour la gestion des stratégies
La stratégie d'entreprise en tant que code (EPAC) est une méthode alternative pour déployer, gérer et exploiter Azure Policy sur l'ensemble du parc Azure de votre organisation. Vous pouvez utiliser l'APEC au lieu des options de la plateforme standard pour gérer les stratégies dans un environnement de zones d'atterrissage Azure. Pour plus d’informations sur l’approche d’intégration, consultez Intégrer EPAC aux zones d’atterrissage Azure.
La stratégie d'entreprise en tant que code convient mieux aux clients DevOps et infrastructure-as-code plus avancés et plus matures. Toutefois, les clients de toute taille peuvent utiliser EPAC s’ils le souhaitent après l’avoir évalué. Pour vous assurer que vous êtes dans la bonne voie, consultez d'abord la rubrique Qui doit utiliser l'APEC ?
Remarque
Comparez le cycle de vie et la flexibilité des deux approches avant de décider de celle que vous utiliserez à long terme. Commencez par évaluer la gestion native des stratégies fournie dans l'implémentation par défaut décrite dans les options de la plateforme standard. Si cette mise en œuvre ne semble pas idéale pour vos besoins en matière de gouvernance, réalisez un MVP ou une preuve de concept à l'aide de l'APEC. Il est important de comparer les options, de valider et de confirmer votre choix avant de mettre en œuvre une approche, car c'est un processus complexe que de changer les méthodes de gouvernance des stratégies une fois qu'elles sont établies.
Exploiter les zones d’atterrissage Azure
Après avoir déployé la zone d'atterrissage de la plateforme, vous devez l'exploiter et la maintenir. Pour en savoir plus, consultez les instructions sur la façon de maintenir votre zone d’atterrissage Azure à jour.
Visualiseur de gouvernance Azure
Azure governance visualizer est destiné à vous aider à obtenir une vue d'ensemble sur votre mise en œuvre technique de la gouvernance Azure en connectant les points et en fournissant des rapports sophistiqués.
Distributeur d’abonnements
Une fois la zone d'atterrissage de la plateforme et la stratégie de gouvernance en place, l'étape suivante consiste à établir une cohérence sur la façon dont les abonnements sont créés et opérationnalisés pour les propriétaires de charge de travail. La démocratisation des abonnements est un principe de conception des zones d’atterrissage Azure qui utilise les abonnements comme unités de gestion et de mise à l’échelle. Cette approche accélère les migrations d’applications et le développement de nouvelles applications.
La norme de vente d'abonnements standardise le processus que les équipes de plateforme utilisent pour permettre aux équipes de charge de travail de demander des abonnements, ainsi que de déployer et gérer ces abonnements. Cela permet aux équipes d'application d'accéder à Azure selon une méthode cohérente et gouvernée, en s'assurant que la collecte des exigences est terminée.
Il est également courant pour les organisations d'avoir plusieurs styles différents d'abonnements qui peuvent être vendus dans leur locataire, souvent appelés « lignes de produits » dans l'industrie. Voir Établir des lignes de produits communes pour la vente d'abonnements pour connaître les « lignes de produits » recommandées pour votre organisation.
Pour commencer, suivez les conseils de mise en œuvre de la rubrique Conseils de mise en œuvre de la distribution automatique d'abonnements. Passez ensuite en revue les modules d'infrastructure en tant que code suivants, qui offrent la souplesse nécessaire pour répondre à vos besoins de mise en œuvre.
| Option de déploiement | Description |
|---|---|
| Distributeur d’abonnements Bicep | Les modules Bicep de gestion d'abonnement sont conçus pour orchestrer le déploiement des zones d’atterrissage pour chaque application en fonction de la configuration de la charge de travail. Ils peuvent être exécutés manuellement ou dans le cadre d'une automatisation. |
| Distributeur d’abonnement Terraform | Ces modules utilisent Terraform pour orchestrer le déploiement des zones d'atterrissage des applications individuelles. |
Architectures de zones de réception d'applications
Les zones d'atterrissage des applications consistent en un ou plusieurs abonnements qui sont déployés en tant que destinations approuvées pour les ressources d'une charge de travail appartenant à l'équipe d'application. Une charge de travail peut tirer parti des services déployés dans les zones d'atterrissage de la plateforme ou être isolée de ces ressources centralisées. Les zones d'atterrissage des applications devraient être utilisées pour les applications gérées de manière centralisée, les charges de travail décentralisées appartenant à des équipes d'application et les plateformes d'hébergement gérées de manière centralisée, comme Azure Kubernetes Service (AKS), qui pourraient héberger des applications pour plusieurs unités métier À moins d'être contraints par des contraintes anormales, les abonnements à la zone d'atterrissage des applications ne contiennent que des ressources provenant d'une seule charge de travail ou d'une seule frontière logique d'application, comme son cycle de vie ou sa classification de criticité
Les équipes chargées des charges de travail communiquent les exigences de leur charge de travail par le biais d'un processus formel établi par l'équipe chargée de la plate-forme. L'équipe de plateforme déploie généralement un abonnement vide inscrit avec toute la gouvernance requise. L'architecte de la charge de travail conçoit ensuite une solution qui respecte les contraintes de la zone d'atterrissage de l'application et tire parti des fonctions de la plate-forme partagée (telles que les pare-feu et le routage entre les sites), lorsque cela est possible.
Il est possible qu'un architecte adapte une architecture de référence qui n'est pas spécifiquement conçue avec une zone d'atterrissage d'application à l'esprit. Cependant, Microsoft Learn contient également des conseils sur les plateformes d'applications et de données à l'intention des équipes chargées du travail, qui traitent spécifiquement des contextes de zone d'atterrissage des applications. Les équipes chargées des plates-formes doivent être informées des conseils disponibles pour les équipes chargées de la charge de travail afin qu'elles puissent anticiper les types de charge de travail et les caractéristiques susceptibles d'être présentes dans l'organisation.
| Architecture de zone d'accueil d'application | Description |
|---|---|
| Environnement Azure App Service | Recommandations et considérations éprouvées à travers les cas d'utilisation des environnements multitenant et App Service avec une mise en œuvre de référence. |
| Azure API Management (APIM) | Recommandations et considérations éprouvées pour le déploiement d'une instance interne de gestion des API dans le cadre d'une mise en œuvre de référence. Le scénario utilise Azure Application Gateway pour fournir un contrôle d'entrée sécurisé et utilise Azure Functions comme back-end. |
| Azure Arc pour les scénarios hybrides et multiclouds. | Serveurs avec Azure Arc, Kubernetes et SQL Managed Instance avec Azure Arc. |
| Azure Container Apps | Ce guide sur les Container Apps d'Azure présente le chemin de conception stratégique et définit l'état technique cible pour le déploiement des Container Apps d'Azure. Une équipe dédiée à la charge de travail possède et exploite cette plateforme. |
| Azure Data Factory | Découvrez comment prendre un lakehouse traditionnel en médaillon et l'héberger au sein d'une zone d'atterrissage d'application. |
| Charge de travail pour le chat Azure OpenAI | Décrit comment intégrer une application de chat Azure OpenAI typique au sein des zones d'atterrissage Azure pour utiliser des ressources partagées centralisées tout en respectant la gouvernance et la rentabilité, en offrant des conseils aux équipes de charge de travail sur le déploiement et la gestion. |
| Azure Kubernetes Service (AKS) | Des conseils et des modèles d'infrastructure en tant que code connexes qui représentent le chemin de conception stratégique et l'état technique cible pour un déploiement AKS fonctionnant au sein d'une zone d'atterrissage d'application. |
| Azure Red Hat OpenShift | Une collection d’open source de modèles Terraform qui représentent un déploiement Azure Red Hat OpenShift (ARO) optimal composé de ressources Azure et Red Hat. |
| Azure Synapse Analytics | Une approche architecturale pour préparer les zones d'atterrissage des applications pour un déploiement d'entreprise typique d'Azure Synapse Analytics. |
| Azure Virtual Desktop | Modèles ARM, Bicep et Terraform à référencer lors de la conception de déploiements d'Azure Virtual Desktop, y compris la création de pools d'hôtes, la mise en réseau, le stockage, la surveillance et les modules complémentaires. |
| Machines virtuelles Azure | Cette architecture étend les conseils de l'architecture de base des machines virtuelles (VM) Azure à une zone d'atterrissage des applications, avec des conseils sur la configuration des abonnements, la conformité des patches et d'autres préoccupations de gouvernance organisationnelle. |
| Solution Azure VMware | Modèles ARM, Bicep et Terraform utiles lors de la conception de déploiements VMware, notamment le cloud privé Azure VMware Solution, la boîte de saut, la mise en réseau, la surveillance et les modules complémentaires. |
| Citrix sur Azure | Les instructions de conception pour le Cloud Adoption Framework pour Citrix Cloud dans une zone d’atterrissage Azure à l’échelle de l’entreprise couvrent de nombreux domaines de conception. |
| Red Hat Enterprise Linux (RHEL) sur Azure | La zone d'atterrissage pour Red Hat Enterprise Linux (RHEL) sur Azure est une collection open source de conseils architecturaux et de recommandations de mise en œuvre de référence utilisés pour concevoir des charges de travail basées sur RHEL sur Microsoft Azure. |
| Charges de travail de calcul haute performance (HPC) | Solution de cluster HPC de bout en bout dans Azure qui utilise des outils tels que Terraform, Ansible et Packer. Il aborde les meilleures pratiques de la zone d'atterrissage Azure, notamment la mise en œuvre de l'identité, l'accès à la boîte de saut et l'autoscale. |
| Charges de travail critiques | Traite de la manière dont une charge de travail classée comme critique doit être conçue pour s'exécuter dans une zone d'atterrissage d'application. |
| Charges de travail SAP | Fournit des conseils et des recommandations pour les charges de travail SAP alignées sur les meilleures pratiques de la zone d'atterrissage Azure. Fournit des recommandations pour créer des composants d'infrastructure comme le calcul, la mise en réseau, le stockage, la surveillance et la construction de systèmes SAP. |
Les charges de travail sont souvent un ensemble de technologies et de classifications diverses. Nous vous recommandons d'examiner les documents de référence relatifs à toutes les technologies de votre charge de travail. Par exemple, il est important de comprendre les conseils du chat Azure OpenAI et de l'Azure API Management pour savoir si votre scénario d'IA générative bénéficierait de l'ajout d'une passerelle API.