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 implémentations de zones d’atterrissage d’application et de plateforme, consultez Qu’est-ce qu’une zone d’atterrissage Azure ? dans le Framework d’adoption du cloud pour Azure.
Cet article décrit les options de déploiement pour les zones d’atterrissage de plateforme et d’application.
Choisir une approche de zone d’atterrissage de plateforme
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. Selon les personnalisations, l’architecture résultante peut ne pas être la même pour toutes les options de déploiement répertoriées ici. Les différences entre les options de déploiement de plateforme sont basées sur la façon dont elles utilisent différentes technologies, prennent différentes approches et sont personnalisées différemment.
Options de déploiement standard
Les options de déploiement standard traitent de l’utilisation classique d’Azure d’entreprise.
| Option de déploiement de zone d’atterrissage de 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 | Déploiement modulaire basé sur l’infrastructure en tant que code où chaque module Bicep encapsule une fonctionnalité principale 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 fournit un module d’orchestrateur Terraform et vous permet également de déployer chaque fonctionnalité de plateforme individuellement ou dans son ensemble. |
Variantes et spécialisations
Bien que les options de déploiement de plateforme standard traiter l’utilisation classique d’Azure d’entreprise, certaines options de déploiement 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ées aux organisations qui ont besoin de contrôles souverains avancés. |
Implémentations de 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 implémentations commencent par l’architecture conceptuelle zone d’atterrissage Azure et aident à concevoir des configurations spécifiques à votre stratégie d’adoption du cloud, à la topologie organisationnelle et aux résultats souhaités.
Stratégie d’entreprise en tant que code (EPAC) pour la gestion des stratégies
stratégie d’entreprise en tant que code (EPAC) est une autre méthode pour déployer, gérer et exploiter Azure Policy dans le patrimoine Azure de votre organisation. Vous pouvez utiliser EPAC au lieu des options de 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 le mieux pour les clients DevOps et d’infrastructure en tant que 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 aligné, commencez par voir Qui doit utiliser EPAC ?.
Remarque
Comparez le cycle de vie et la flexibilité des deux approches avant de décider de l’approche que vous utilisez à long terme. Commencez par évaluer la gestion de stratégie native fournie dans l’implémentation par défaut décrite dans les options de plateforme standard . Si cette implémentation ne semble pas idéale pour vos besoins de gouvernance, effectuez un MVP ou une preuve de concept à l’aide d’EPAC. Il est important de comparer les options, de valider et de confirmer votre choix avant d’implémenter une approche, car il s’agit d’un processus complexe pour modifier les méthodes de gouvernance des stratégies une fois établies.
Exploiter les zones d’atterrissage Azure
Après avoir déployé la zone d’atterrissage de la plateforme, vous devez l’utiliser et la gérer. Pour en savoir plus, consultez les instructions sur la façon de maintenir votre zone d’atterrissage Azure à jour.
Visualiseur de gouvernance Azure
visualiseur de gouvernance Azure est destiné à vous aider à obtenir une vue d’ensemble globale de votre implémentation de gouvernance Azure technique en connectant les points et en fournissant des rapports sophistiqués.
Distributeur d’abonnements
Une fois la zone d’atterrissage et la stratégie de gouvernance de la plateforme en place, l’étape suivante consiste à établir la cohérence sur la façon dont les abonnements sont créés et opérationnels 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. Elle permet aux équipes d’applications d’accéder à Azure dans une méthode cohérente et régie, ce qui garantit 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. Ensuite, passez en revue les modules infrastructure-as-code suivants, qui offrent une flexibilité pour répondre à vos besoins d’implémentation.
| 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. Elles peuvent être exécutées manuellement ou dans le cadre de l’automatisation. |
| Distributeur d’abonnement Terraform | Ces modules utilisent Terraform pour orchestrer le déploiement des zones d’atterrissage d’application 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 des zones d’atterrissage de plateforme ou être isolée de ces ressources centralisées. Les zones d’atterrissage d’application doivent être utilisées pour les applications gérées de manière centralisée, les charges de travail décentralisées détenues par les équipes d’applications et les plateformes d’hébergement gérées de manière centralisée, telles qu’Azure Kubernetes Service (AKS) qui peuvent héberger des applications pour plusieurs unités commerciales. À moins d’être forcés par des contraintes anormales, les abonnements de zone d’atterrissage d’application contiennent uniquement des ressources provenant d’une seule charge de travail ou d’une limite d’application logique, comme son cycle de vie ou sa classification de la criticité.
Les équipes de charge de travail communiquent les exigences de leur charge de travail par le biais d’un processus formel établi par l’équipe de plateforme. L'équipe de plateforme déploie généralement un abonnement vide inscrit avec toute la gouvernance requise. Un architecte de charge de travail conçoit ensuite une solution qui fonctionne dans les contraintes de cette zone d’atterrissage de l’application et tire parti des fonctionnalités de plateforme partagée (pare-feu et routage intermisis), le cas échéant.
Il est possible qu’un architecte puisse adapter une architecture de référence qui n’est pas spécifiquement conçue avec une zone d’atterrissage d’application à l’esprit. Toutefois, Microsoft Learn contient également des instructions sur les applications et la plateforme de données pour les équipes de charge de travail qui traitent spécifiquement les contextes de zone d’atterrissage de l’application. Les équipes de plateforme doivent être informées des instructions disponibles pour les équipes de charge de travail afin que l’équipe de plateforme puisse anticiper les types de charge de travail et les caractéristiques susceptibles d’être présents 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. |
| gestion des API Azure (APIM) | Recommandations et considérations éprouvées pour le déploiement d’une instance gestion des API interne dans le cadre d’une implémentation de référence. Le scénario utilise Azure Application Gateway pour fournir un contrôle d’entrée sécurisé et utiliser 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 Azure Container Apps décrit le chemin de conception stratégique et définit l’état technique cible pour le déploiement d’Azure Container Apps. Une équipe de charge de travail dédiée 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 conversation Azure OpenAI standard dans les zones d’atterrissage Azure pour utiliser des ressources partagées centralisées tout en respectant la gouvernance et l’efficacité des coûts, offrant des conseils pour les é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 | Approche architecturale pour préparer les zones d’atterrissage d’application pour un déploiement d’entreprise classique d’Azure Synapse Analytics. |
| Azure Virtual Desktop | Modèles ARM, Bicep et Terraform qui doivent être référencés lors de la conception de déploiements Azure Virtual Desktop, notamment la création de pools d’hôtes, de mise en réseau, de stockage, de supervision et de modules complémentaires. |
| Machines virtuelles Azure | Cette architecture étend les instructions de l’architecture de base des machines virtuelles Azure à une zone d’atterrissage d’application, avec des conseils sur la configuration de l’abonnement, la conformité des correctifs et d’autres problèmes de gouvernance organisationnelle. |
| Solution Azure VMware | Modèles ARM, Bicep et Terraform qui sont utiles lors de la conception de déploiements VMware, notamment le cloud privé Azure VMware Solution, la jump box, la mise en réseau, la supervision 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 d’implémentation de référence utilisées 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 zone d’atterrissage Azure. Fournit des recommandations pour créer des composants d’infrastructure tels que le calcul, la mise en réseau, le stockage, la supervision et la génération de systèmes SAP. |
Les charges de travail sont souvent une collection de différentes technologies et classifications. Nous vous recommandons de passer en revue les documents de référence connexes pour toutes les technologies de votre charge de travail. Par exemple, comprendre les instructions de la conversation Azure OpenAI et la gestion des API Azure est importante pour comprendre si votre scénario d’IA générative tirerait parti de l’ajout d’une passerelle d’API.