Déployer des zones d’atterrissage Azure

Cet article décrit les options disponibles pour vous aider à déployer des zones d’atterrissage de plateforme et d’application. Les zones d’atterrissage de plateforme fournissent des services centralisés que les charges de travail utilisent. Les zones d’atterrissage d’application sont des environnements déployés pour les charges de travail elles-mêmes.

Importante

Pour plus d’informations sur les définitions et les implémentations des zones d’atterrissage de plateforme et des zones d’atterrissage d’application, consultez Qu’est-ce qu’une zone d’atterrissage Azure ?.

Choisissez une approche de zone d'atterrissage de plate-forme

Les options de déploiement de plateforme suivantes fournissent une approche avisée pour déployer et exploiter l’architecture conceptuelle de la zone d’atterrissage Azure , comme décrit dans le Cloud Adoption Framework pour Azure. L’architecture résultante peut varier en fonction des personnalisations. Il peut donc ne pas être identique pour toutes les options de déploiement répertoriées dans cet article. Les différences entre les options de déploiement de plateforme sont basées sur leur utilisation de différentes technologies, approches et personnalisations.

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	Descriptif	Clouds publics d'Azure	Clouds souverains Azure (US Government, 21Vianet, et ainsi de suite.)
Déploiement du portail Azure	Le déploiement basé sur le portail Azure fournit une implémentation complète de l’architecture conceptuelle de la zone d’atterrissage Azure et des configurations avisées pour les composants clés, tels que les groupes d’administration et les stratégies.	Soutenu	Non pris en charge. Les ressources individuelles peuvent être déployées avec le portail Azure, mais pas dans le cadre d'une expérience de portail unifiée et guidée.
Déploiement Bicep	Déploiement modulaire basé sur l’infrastructure en tant que code (IaC), où chaque module Bicep encapsule une fonctionnalité principale de l’architecture conceptuelle de la zone d’atterrissage Azure. Ces modules peuvent être déployés individuellement, mais la conception vous recommande d’utiliser des modules orchestrator pour encapsuler la complexité du déploiement de différentes topologies avec les modules.	Soutenu	Prise en charge, mais nécessite une modification. Consultez la section déploiements de cloud souverain Azure .
Déploiement Terraform	Un déploiement basé sur IaC qui utilise des modules vérifiés par Azure pour les zones d’atterrissage de plateforme et fournit un moyen personnalisable de déployer des zones d’atterrissage Azure avec Terraform.	Soutenu	Prise en charge, mais nécessite une modification. Consultez la section déploiements de cloud souverain Azure .

Déploiements de cloud souverain Azure

Les trois options de déploiement sont prises en charge pour les offres de cloud public, global et commercial Azure. Si vous devez effectuer un déploiement dans d’autres clouds Azure, tels qu’Azure Government ou Microsoft Azure gérés par 21Vianet, les ressources de déploiement nécessitent des modifications de configuration manuelles par votre équipe de plateforme. Seules les options de déploiement Bicep &Terraform peuvent être modifiées pour gérer ces modifications requises.

• Définitions, initiatives et affectations Azure Policy : toutes les stratégies Azure ne sont pas disponibles dans tous les clouds. Vous devez donc supprimer les stratégies non prises en charge avant le déploiement.
• Versions d’API pour certaines ressources : certaines versions d’API peuvent ne pas exister dans certains clouds. Vous devez donc ajuster les versions de l’API de ressources avant le déploiement
• Disponibilité des ressources : certaines ressources peuvent ne pas exister dans certains clouds, par exemple les plans de protection DDoS ne sont pas disponibles dans Azure en Chine. Vous devez les supprimer avant le déploiement.

L’architecture de la zone d’atterrissage Azure est toujours valide et prise en charge dans tous les clouds Azure. Toutefois, le déploiement de cette architecture n’est pas fourni dans une solution automatisée qui fonctionne sur tous les clouds. Si vous souhaitez voir la prise en charge du déploiement automatisé pour ces clouds, demandez la fonctionnalité.

Variantes et spécialisations

Les options de déploiement de plateforme standard traitent de l’utilisation classique d’Azure d’entreprise, mais certaines options de déploiement se concentrent sur des spécialisations spécifiques. Par exemple, une zone d’atterrissage souveraine est une variante de la zone d’atterrissage Azure conçue pour les organisations qui nécessitent des contrôles souverains avancés.

Implémentations partenaires

Les programmes partenaires tels qu’Azure Migrate et Moderniser peuvent vous aider à concevoir et à implémenter une zone d’atterrissage de plateforme spécifique aux besoins de votre organisation. Ces implémentations commencent par l’architecture conceptuelle de la zone d’atterrissage Azure et les configurations de conception 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 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 EPAC au lieu des options de plateforme standard pour gérer les stratégies dans un environnement de zone d’atterrissage Azure. Pour plus d’informations sur l’approche d’intégration, consultez Intégrer EPAC aux zones d’atterrissage Azure.

EPAC est mieux adapté aux clients DevOps et IaC plus avancés. Toutefois, les organisations de n’importe quelle échelle peuvent utiliser EPAC après l’avoir évaluée. Pour plus d’informations, consultez Qui doit utiliser EPAC ?.

Remarque

Comparez le cycle de vie et la flexibilité des deux approches avant de décider de l’approche à utiliser à long terme. Commencez par évaluer la gestion des stratégies natives dans l’implémentation par défaut. Si cette implémentation ne répond pas à 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 vos résultats et de confirmer votre choix avant d’implémenter une approche, car il est difficile de modifier les méthodes de gouvernance des stratégies après les avoir é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 plus d’informations, consultez Maintenir votre zone d’atterrissage Azure à jour.

Visualiseur de gouvernance Azure

Le visualiseur de gouvernance Azure peut vous aider à obtenir une vue d’ensemble holistique 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 une 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 des abonnements en tant qu’unités de gestion et d’échelle. Cette approche accélère les migrations d’applications et le développement de nouvelles applications.

La vente d’abonnements normalise le processus utilisé par les équipes de plateforme pour les équipes de charge de travail afin de demander aux abonnements et aux équipes de plateforme de déployer et de régir ces abonnements. Elle permet aux équipes d’applications d’accéder à Azure de manière cohérente et régie, ce qui permet de s’assurer que la collecte des exigences est terminée.

Les organisations ont souvent différents styles d’abonnements qui peuvent être vendés dans leur locataire, communément appelés lignes de produits. Pour plus d’informations, voir Établir des lignes de produits d’abonnement communes.

Pour commencer, suivez les instructions d’implémentation de la vente de l’abonnement. Passez ensuite en revue les modules IaC suivants, qui offrent une flexibilité pour répondre à vos besoins d’implémentation.

Option de déploiement	Descriptif
Distributeur d’abonnements Bicep	Les modules Bicep pour la gestion des abonnements sont conçus pour orchestrer le déploiement des zones d’accueil d’applications individuelles en fonction de la configuration de chaque charge de travail. Elles peuvent être effectuées manuellement ou dans le cadre du processus d’automatisation.
Distributeur d’abonnement Terraform	Les 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 d’application sont des zones désignées dans un ou plusieurs abonnements, en particulier configurées comme destinations approuvées pour les ressources que les équipes d’application gèrent pour une charge de travail spécifique. Une charge de travail peut tirer parti des services dans les zones d’atterrissage de plateforme ou rester isolée de ces ressources centralisées. Utilisez des zones d’atterrissage d’application pour les applications gérées de manière centralisée, les charges de travail décentralisées dont les équipes d’applications possèdent et les plateformes d’hébergement gérées de manière centralisée, telles qu’Azure Kubernetes Service (AKS) qui pourraient héberger des applications pour plusieurs unités commerciales. À moins d’être limités par des circonstances inhabituelles, les abonnements de zone d’atterrissage d’application incluent généralement 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. Ensuite, un architecte de charge de travail conçoit une solution qui fonctionne dans les contraintes de cette zone d’atterrissage d’application et tire parti des fonctionnalités de plateforme partagée, telles que les pare-feu et le routage intersite, quand c’est pratique.

Il est possible pour un architecte d’adapter une architecture de référence qui n’est pas conçue spécifiquement 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. Tenez compte des instructions fournies aux é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 au sein de l’organisation.

Architecture de zone d'accueil d'application	Descriptif
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	Recommandations et considérations éprouvées pour déployer 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 vous aider à 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.	Conseils pour les serveurs, Kubernetes et Azure SQL Managed Instance activés par Azure Arc.
Azure Container Apps	Conseils qui décrivent le chemin de conception stratégique et définissent l’état technique cible pour le déploiement de Container Apps. Une équipe de charge de travail dédiée possède et exploite cette plateforme.
Azure Data Factory.	Conseils sur l’hébergement d’un medallion lakehouse au sein d’une application landing zone.
Charge de travail de chat Azure AI Foundry	Conseils sur l’intégration d’une architecture de conversation Azure AI Foundry classique 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. Il fournit des conseils aux équipes de charge de travail sur le déploiement et la gestion.
AKS	Conseils et modèles IaC associés qui représentent le chemin de conception stratégique et l’état technique cible d’un déploiement AKS qui s’exécute dans 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 Azure Resource Manager (ARM), Bicep et Terraform que vous devez référencer lorsque vous concevez des déploiements Azure Virtual Desktop, qui incluent 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	Architecture qui étend les instructions de l’architecture de base des machines virtuelles à une zone d'accueil d'application. Il fournit 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 que vous pouvez utiliser pour concevoir des déploiements Azure VMware Solution. Ces déploiements incluent le cloud privé Azure VMware Solution, la zone de rebond, la mise en réseau, la surveillance et les modules complémentaires.
Citrix sur Azure	Recommandations en matière de conception pour le cadre d'adoption du Cloud pour Citrix Cloud dans une zone d’atterrissage à l’échelle de l'entreprise Azure, comprenant de nombreux domaines de conception.
Red Hat Enterprise Linux (RHEL) sur Azure	Collection open source de recommandations architecturales et recommandations d’implémentation de référence que vous pouvez utiliser 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 traite des meilleures pratiques de zone d’atterrissage Azure, notamment l’implémentation d’identité, l’accès à la zone de rebond et la mise à l’échelle automatique.
Charges de travail critiques	Explique comment concevoir une charge de travail stratégique à 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 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 se composent souvent de différentes technologies et classifications. Nous vous recommandons de consulter les documents de référence connexes pour toutes les technologies de votre charge de travail. Par exemple, la compréhension des instructions de la conversation Azure OpenAI et de la gestion des API est essentielle pour déterminer si votre scénario d’IA générative peut tirer parti de l’incorporation d’une passerelle d’API.

Étape suivante

• Concevez votre solution de distributeur d'abonnements