Planifier vos environnements

Effectué

Votre patrimoine Azure a de nombreux composants, notamment une configuration de base, des ressources et des paramètres à l’échelle de l’organisation ainsi que des charges de travail d’application. Par ailleurs, votre patrimoine est probablement réparti sur plusieurs environnements, chacun avec des objectifs différents.

Dans cette unité, vous découvrez les avantages liés à l’utilisation systématique de code pour l’ensemble de votre déploiement et de votre configuration. Ensuite, vous examinez les niveaux de contrôle et d’automatisation que vous pouvez appliquer à chacun de vos environnements. Vous examinez aussi la progression de vos modifications à chaque étape du processus de déploiement, ainsi que les contrôles et les types de gouvernance nécessaires pour prendre en charge la stratégie de déploiement que vous avez choisie.

Définir votre infrastructure en tant que code

Le déploiement et la configuration d’Azure vont bien au-delà des applications, des machines virtuelles, des services de stockage et des réseaux. Par exemple, chacun des éléments suivants est une forme de configuration, avec les ressources Azure correspondantes :

• Organiser vos ressources en créant des groupes de ressources, des abonnements et des groupes d’administration.
• Contrôler la façon dont vos autres ressources doivent être configurées, en définissant et en appliquant des définitions, des initiatives et des affectations d’Azure Policy.
• Attribuer des rôles pour autoriser des utilisateurs, des groupes et des identités de charge de travail à accéder aux ressources Azure.
• Configurer le monitoring, y compris des alertes, pour observer vos ressources Azure et vérifier qu’elles se comportent comme prévu.

Quand vous commencez à définir votre infrastructure en tant que code, vous ne connaissez peut-être pas tous les éléments qui peuvent être définis dans vos modèles ou vos définitions. Mais à mesure que votre utilisation de l’automatisation arrive à maturité, il est recommandé de définir tout ce qui concerne votre environnement sous forme de code. En procédant ainsi, vous pouvez utiliser un processus cohérent, testé et approuvé pour la totalité de votre configuration Azure. Et comme le code est versionné et suivi dans un dépôt Git, vous pouvez examiner l’évolution de votre environnement Azure au fil du temps. Vous pouvez utiliser le dépôt Git pour suivre l’historique de chaque modification.

Par exemple, supposons que vous devez configurer des alertes Azure Monitor. Au début, vous pensez peut-être que l’utilisation de l’automatisation pour déployer des alertes est dépourvue de sens. Toutefois, les alertes constituent une partie importante de votre configuration Azure. Si une alerte n’est pas créée correctement, vous risquez de manquer des notifications concernant des problèmes de production critiques. En définissant vos alertes dans le code :

• Les membres de votre équipe peuvent passer en revue les alertes et leur configuration.
• Vous pouvez déployer les alertes sur des environnements hors production pour pouvoir les tester.
• Vous disposez d’un suivi complet des modifications apportées à votre configuration Azure.

Environnements

Si vous envisagez de déployer votre infrastructure automatiquement, il est utile de lister les environnements que vous prévoyez d’utiliser. De nombreuses organisations ont différents types d’environnements, chacun avec des caractéristiques différentes. Par exemple :

• Certains environnements exécutent du code de production, tandis que d’autres exécutent des versions hors production du même code, peut-être avec des configurations différentes.
• Certains environnements sont de longue durée et ne sont jamais destinés à être supprimés. D’autres sont éphémères, c’est-à-dire qu’ils sont créés automatiquement et détruits quand ils ne sont plus utilisés.
• Certains environnements peuvent être utilisés par votre infrastructure ou votre équipe de développement de logiciels. D’autres sont utilisés par votre équipe de sécurité, ou même par votre équipe commerciale quand elle doit faire la démonstration d’un produit à des clients potentiels.

Considérez les environnements que votre entreprise de jouets peut utiliser pour votre site web :

Quand vous apportez des modifications à votre application ou à votre infrastructure et que vous les commitez, votre pipeline déploie vos modifications dans une série d’environnements hors production : développement, test et préproduction. Vous pouvez également mettre en place des étapes d’approbation manuelles à certains endroits afin que certains membres de l’équipe puissent vérifier la configuration ou consulter le journal du pipeline avant que le déploiement ne se poursuive. Votre pipeline déploie ensuite vos modifications dans votre environnement de production.

En plus de ces environnements, votre équipe commerciale a son propre environnement de démonstration qu’elle utilise pour communiquer avec les clients. L’équipe commerciale prend une copie de l’environnement de production pour créer son environnement de démonstration. Vos équipes de sécurité et de test créent parfois des copies temporaires de l’environnement de production pour réaliser des tests d’intrusion et des tests de performance, respectivement.

Votre équipe de développement a également ses propres environnements. Elle met à la disposition de ses membres des bacs à sable qui permettent d’explorer de nouvelles fonctionnalités ou de tester les services Azure. L’équipe de développement crée également des environnements de revue de demande de tirage pour chaque demande de tirage GitHub qu’elle examine et fusionne.

Environnements contrôlés

Dans certains de ces environnements, il est logique d’exiger un processus formel pour passer en revue et appliquer les modifications. Les environnements de ce type sont appelés environnements contrôlés. L’environnement de production doit toujours être contrôlé. C’est une bonne pratique que d’appliquer des contrôles aussi à certains des environnements hors production. En procédant ainsi, vous pouvez garantir que toutes les restrictions imposées par les contrôles sont bien comprises et testées avant le déploiement en production.

En revanche, les environnements non contrôlés n’ont pas beaucoup de contrôles formels, voire aucun. Ils peuvent avoir le même code et une configuration similaire à vos autres environnements, mais ils permettent d’effectuer davantage d’expérimentations et de changements de configuration ad hoc. Dans un environnement non contrôlé, les utilisateurs peuvent être autorisés à modifier la configuration en utilisant le portail Azure ou en exécutant directement des commandes Azure CLI/Azure PowerShell. Ils peuvent également être en mesure de créer des ressources sans utiliser le processus approuvé de l’organisation. Les modifications apportées dans les environnements non contrôlés doivent être capturées dans le code avant qu’elles ne soient appliquées à des environnements contrôlés comme l’environnement de production.

Notes

Parfois, un environnement peut en fait représenter plusieurs environnements physiques ou déploiements. Par exemple, quand vous créez des environnements éphémères pour des révisions de demande de tirage, plusieurs environnements distincts peuvent être actifs en même temps si votre équipe a plusieurs demandes de tirage ouvertes. Toutefois, pour planifier vos environnements, vous pouvez les considérer comme équivalents puisqu’ils ont les mêmes caractéristiques et contrôles.

Après quelques discussions avec votre équipe, vous désignez les environnements contrôlés et non contrôlés. Vous décidez également à qui appartient chaque environnement.

Nom de l’environnement	Description	Propriétaire	Durée de vie	Niveau de contrôle
Développement	Intègre les modifications de plusieurs développeurs dans un seul environnement.	Équipe en charge des opérations	Longue durée de vie	Contrôlée
Test	Environnement permettant d’exécuter des tests manuels et automatisés sur les modifications.	Équipe en charge des opérations	Longue durée de vie	Contrôlée
Staging	L’environnement hors production final où les modifications sont déployées avant la mise en production, avec une configuration de type production.	Équipe en charge des opérations	Longue durée de vie	Contrôlée
Production	Exécute vos charges de travail de production.	Équipe en charge des opérations	Longue durée de vie	Contrôlée
Démonstration	Utilisé par l’équipe commerciale pour présenter le produit à de nouveaux clients.	Équipe commerciale	Longue durée de vie	Non contrôlé
Tests de performances	Créé dynamiquement en tant que doublon de l’environnement de production pour l’exécution de tests de performances et de contraintes, puis supprimé une fois les tests terminés.	Équipe de test	Courte durée de vie	Non contrôlé
Test d’intrusion	Créé dynamiquement en tant que doublon de l’environnement de production pour exécuter des tests de pénétration et de sécurité, puis supprimé une fois les tests terminés.	Équipe de sécurité	Courte durée de vie	Non contrôlé
Revues des PR	Créé dynamiquement pour chaque demande de tirage créée par un membre de l’équipe pour modifier l’application ou l’infrastructure. L’environnement est supprimé quand la demande de tirage est fermée.	Équipe de développement	Courte durée de vie	Non contrôlé
Bacs à sable de développement	Créé par les membres de l’équipe de développement pour expérimenter ou explorer, puis supprimé lorsqu’il n’est plus nécessaire.	Équipe de développement	Courte durée de vie	Non contrôlé

La liste précédente d’environnements n’est qu’un exemple. Dans votre organisation, vous devez choisir les environnements que vous utilisez, leur durée de vie et le niveau de contrôle dont chacun a besoin.

Conseil

Les processus de linting, de test et de révision de votre code d’infrastructure sont beaucoup plus faciles à faire au début de vos déploiements au lieu de les ajouter par la suite et d’avoir à corriger de nombreux segments de code défectueux.

De même, il est beaucoup plus facile d’utiliser des contrôles de sécurité lorsqu’ils sont présents dès le départ et appliqués à certains de vos environnements hors production. De cette façon, votre équipe est habituée à travailler dans un environnement contrôlé.

Tout au long des parcours d’apprentissage, nous avons introduit progressivement certains de ces concepts. Il est souvent judicieux d’ajouter ces éléments à votre processus de déploiement dès que possible.

Isolation de chaque environnement

Il est important de séparer chacun de vos environnements et de les rendre autonomes dans la mesure du possible. L’utilisation d’abonnements Azure dédiés pour chaque environnement peut vous aider à y parvenir, mais vous devez toujours veiller à séparer vos environnements.

Évitez de vous connecter d’un environnement à un autre. Par exemple, n’appairez pas le réseau virtuel d’un environnement de production au réseau virtuel d’un environnement hors production. Sinon, quelqu’un peut facilement modifier par accident les données de production depuis un environnement hors production ou divulguer des données de production sensibles sur un environnement hors production.

Vérifications et portes

À mesure que votre processus de déploiement se poursuit, il doit exécuter une série de vérifications pour augmenter votre confiance dans le déploiement. Vous devez déterminer les vérifications qui sont pertinentes pour chacun des environnements dans lesquels vos déploiements transitent.

Parmi les vérifications d’infrastructure, citons les suivantes :

• Revues de code.
• Déploiement de votre code en révision sur des environnements éphémères, et exécution de tests automatisés ou manuels sur les environnements.
• Linting.
• Validation préliminaire.
• Tests manuels.
• Approbation manuelle.
• Tests fonctionnels automatisés.
• Tests de détection de fumée automatisés.
• Attente des signaux d’intégrité d’un environnement précédent avant de passer à l’environnement suivant.

Vous pouvez exécuter certaines de ces vérifications plusieurs fois dans votre processus de déploiement, par exemple pour chaque environnement contrôlé.

Conseil

Quand vous concevez votre processus de déploiement, listez toutes les étapes que vous devez effectuer, aussi petites ou évidentes soient-elles. Indiquez le plus de détails possible. Vous ne choisirez peut-être pas de tout automatiser au début, mais suivre cette pratique vous aidera à créer un plan pour vos processus de déploiement automatisés à l’avenir.

Une porte est une vérification automatisée ou manuelle qui doit réussir pour que le déploiement continue.

Intervention manuelle

Il est judicieux d’automatiser autant de vérifications que possible pendant vos processus de revue et de déploiement de code. Toutefois, votre organisation peut nécessiter une approbation manuelle pour le déploiement en production ou dans d’autres environnements contrôlés.

Si vous utilisez des portes d’approbation manuelles pour les déploiements, appliquez les pratiques recommandées suivantes :

• Définissez clairement qui est autorisé à approuver un déploiement. Utilisez des groupes Microsoft Entra pour définir des approbateurs au lieu de spécifier des utilisateurs individuels. Vous pouvez facilement modifier la liste des approbateurs à l’avenir.
• Disposer d’un processus pour les déploiements d’urgence. Déterminez qui peut approuver un déploiement si les approbateurs normaux ne sont pas disponibles. Un déploiement d’urgence peut avoir lieu au milieu de la nuit ou pendant des vacances.
• Limitez l’intervention humaine à l’approbation ou au rejet d’un déploiement. Évitez de demander à des utilisateurs humains d’exécuter une opération de déploiement, sauf s’il y a une étape que vous ne pouvez pas automatiser.

Gouvernance

Azure fournit des outils et des fonctionnalités pour vous aider à régir votre environnement, notamment :

• Azure Policy, pour détecter les ressources qui ont été configurées d’une manière qui ne correspond pas aux exigences de votre organisation. Il peut aussi empêcher la création ou la reconfiguration des ressources d’une façon qui les rend non conformes.
• Des verrous, pour empêcher les changements ou la suppression de ressources importantes.
• Des groupes d’administration, pour vous aider à organiser vos abonnements Azure, et à configurer le contrôle d’accès en fonction du rôle et les stratégies de manière cohérente dans vos environnements.
• Azure Monitor, pour enregistrer les métriques et les journaux de vos ressources, les présenter dans des tableaux de bord et vous avertir automatiquement en cas d’écart par rapport aux valeurs attendues.

Quand vous générez votre patrimoine Azure, envisagez d’utiliser des zones d’atterrissage Azure. Une zone d’atterrissage vous permet d’intégrer la gouvernance dans votre environnement dès le départ. De nombreuses zones d’atterrissage incluent des fichiers Bicep et Terraform prédéfinis pour vous aider à configurer votre environnement. Nous proposons des liens vers des informations supplémentaires dans le résumé.