La modularisation de la gestion de vos modèles d’Azure Resource Manager (modèles ARM) vous permet de réduire la répétition, de modéliser les meilleures pratiques dans le développement d’infrastructure et d’avoir des déploiements standard cohérents.
Un exemple de cas d'utilisation pour la mise en œuvre de ce type de modularisation est le déploiement de machines virtuelles en utilisant la métaphore de la taille des t-shirts. Supposons que vous avez déployé des dizaines ou des centaines de machines virtuelles. Ces déploiements utilisent la version 1.0.0 de vos modèles et ont une taille moyenne standard d’une série plus ancienne. La transition vers une nouvelle série peut nécessiter une brève interruption de service si vous déployez simplement de nouveaux modèles. Toutefois, en créant la version 1.5.0 et en utilisant la modularisation, vous pouvez déployer de nouvelles infrastructures avec la norme mise à jour tout en conservant l’ancienne infrastructure dans un état déployable. En disposant d'anciennes versions de l'infrastructure, vos équipes chargées des produits et des applications disposent d'une bonne configuration connue sur laquelle elles peuvent s'appuyer pour passer à la nouvelle version au fur et à mesure qu'elles en ont le temps.
Superposition de couches de référentiels : exemple pour les entreprises
Les raisons pour lesquelles vous pouvez avoir une préférence marquée pour l'emplacement de vos modèles, leur mise à jour, etc. sont de deux ordres : la création de branches et les ressources internes.
Création de branches. Cet exemple de scénario facilite les modèles de création de branchements Git qui prennent en charge Gitflow et le flux GitHub. Pour plus d’informations sur Gitflow, consultez Utilisation de git-flow pour automatiser votre flux de travail de création de branche Git, un billet de blog de Jeff Kreeftmeijer. Pour plus d’informations sur le flux GitHub, consultez Flux GitHub dans la documentation GitHub.
Ressources internes. La deuxième concerne les ressources internes, qui intègre les pratiques collaboratives du développement logiciel open source au développement interne. Dans ce scénario, vous pouvez partager en toute confiance différents modèles et code source de module sans nécessairement vous soucier des autorisations pour les modèles de déploiement eux-mêmes. Pour plus d’informations sur le développement de ressources internes, consultez An introduction to innersource sur GitHub,
Bicep est un langage déclaratif permettant de déployer des ressources Azure. Le code réutilisable de Bicep peut utiliser Azure Container Registry comme registre privé pour l’hébergement de modèles ARM versionnés. En utilisant Container Registry de cette façon, votre entreprise peut avoir un processus d’intégration continue et de livraison continue (CI/CD) pour l’infrastructure. Vous pouvez exécuter des tests unitaires et d’intégration dans le cadre du processus CI, et le registre de conteneurs peut recevoir des modules après leur génération. Les équipes d’applications peuvent continuer à utiliser des versions antérieures jusqu’à ce qu’elles soient prêtes à être mises à niveau, ou à effectuer des mise à jour pour tirer parti des fonctionnalités dans les versions plus récentes des modèles.
En plus de cette utilisation de registre de conteneur, vous pouvez combiner ce modèle avec quelque chose comme Modules vérifiés Azure. Votre implémentation pourrait utiliser le registre public ou, mieux encore, surveiller les référentiels publics et extraire les modifications dans votre registre privé pour les utiliser ultérieurement. L’extraction de modifications dans votre propre registre de conteneurs vous permet d’exécuter des tests sur des modules publics tout en vous assurant qu’ils ne sont pas utilisés en production tant que les pratiques de qualité et de sécurité ne sont pas incorporées.
Calques
Le modèle proposé dans cet exemple de scénario est celui qui est empilé. Les couches plus proches du haut de la pile ont des déploiements et des déploiements plus fréquents qui sont plus personnalisés. Le code Bicep fournit des déploiements cohérents. Équipes de développement, travaillant dans les couches pour leurs contributions, génération à partir des services et de l’infrastructure fournis dans les couches ci-dessous. Rien dans une couche inférieure ne doit s’appuyer sur les ressources d’une couche située au-dessus. De la couche 0 à 3, vous trouvez des bibliothèques globales, une infrastructure globale (services partagés globaux), une plateforme de produits (services partagés) et des applications.
Ce modèle crée une autonomie avec l’alignement, ce qui signifie disposer des éléments suivants :
Outils courants pour la facilité d’entreprise. Par exemple, tout le monde utilise git pour le contrôle de code source et tout le monde utilise GitHub Actions pour CI/CD. Cependant, nous n'allons pas trop loin. Par exemple, nous ne mandatons pas que toutes les équipes utilisent Bicep ; elles peuvent utiliser Terraform, les modèles ARM et d’autres outils.
Possibilité de partager les meilleures pratiques. Ils peuvent prendre la forme de modèles ARM, d’images stables ou d’extraits de code. Les meilleures pratiques peuvent également être des documentations sur des techniques spécifiques. Par exemple, comment faire pivoter des clés dans votre environnement et comment tester du code.
Certains services se déplacent vers le bas dans la pile. Par exemple, une équipe d’application peut initialement développer un modèle pour déployer un cluster Kubernetes, qui est ensuite extrait dans la plateforme de produits en tant que service partagé. Ce modèle devient si utile qu'il est intégré à la bibliothèque d’échantillons.
Couche 0 - Bibliothèque globale
La couche inférieure est la bibliothèque globale, qui est un référentiel de tidbits utiles qui ne sont pas déployés en production. Du point de vue du contrôle d’accès, l’accès en lecture doit être fourni à toute personne de l’entreprise qui le demande. Pour les modifications, suggestions, et ainsi de suite, votre Cloud Center of Excellence (CCoE) approuve les PR et gère un backlog comme s’il s’agissait d’un autre produit.
La couche 0 ne doit pas contenir ce qui suit :
- Modèles déployés en production.
- Configurations spécifiques aux secrets ou à l’environnement.
La couche 0 doit contenir ce qui suit :
- Extraits de code (en Python, C#, etc.).
- Exemples Azure Policy.
- Modèles ARM, modèles Bicep ou fichiers Terraform qui peuvent être utilisés comme exemples.
Voici un exemple d’architecture permettant d’écrire un déploiement pour une application à trois niveaux sans aucune information spécifique à l’environnement. Cet exemple d’architecture peut inclure des balises, des réseaux, des groupes de sécurité réseau, et ainsi de suite. L’abandon d’informations spécifiques pour l’environnement est utile, car tout ne peut pas être ou doit être placé dans un module. Essayer de le faire peut entraîner une définition excessive de paramètres.
De plus, la couche 0 peut lier à d’autres sources d’exemple de code connues, telles que le Registre Terraform ou les modules de ressources Azure). Si votre organisation adopte du code ou un modèle provenant d’une de ces sources, nous vous recommandons d’extraire le code ou le modèle dans votre propre couche 0 au lieu d’extraire directement des sources publiques. En s’appuyant sur votre couche 0, vous pouvez écrire vos propres tests, ajustements et configurations de sécurité. En ne s’appuyant pas sur des sources publiques, vous réduisez le risque d’avoir recours à quelque chose qui pourrait être supprimé de façon inattendue.
Pour être considérés comme un bon exemple de code, vos modèles et modules doivent suivre les bonnes pratiques de développement, notamment la validation d’entrée pour la sécurité et pour les exigences organisationnelles. Pour maintenir ce niveau de rigueur, vous devez ajouter des stratégies à la branche principale pour exiger des demandes d’extraction (PR) et des révisions de code pour les modifications proposées qui entraîneraient des modifications dans le registre de conteneurs principal s’ils sont fusionnés.
La couche 0 alimente Azure Pipelines ou GitHub Actions pour créer automatiquement des artefacts versionnés dans Azure Container Registry. Vous pouvez générer l’automatisation des messages de validation Git pour implémenter le contrôle de version sémantique des artefacts. Pour que cela fonctionne correctement, vous devez disposer d’une norme de nommage déterministe, telle que <service>.bicep, afin de rendre l’automatisation gérable au fil du temps. Avec les stratégies de branche appropriées, vous pouvez également ajouter des tests d’intégration comme prérequis pour les révisions de code. Vous pouvez l’instrumenter à l’aide d’outils comme Pester.
Avec ces stratégies et protections en place, le registre de conteneurs peut être la source de confiance pour tous les modules d’infrastructure de l’entreprise prêts à être utilisés. Vous devez envisager de normaliser les journaux des modifications, ainsi que les index des exemples de code disponibles, pour permettre la découverte de ce code. Le code inconnu n’est pas utilisé !
Couche 1 - Infrastructure globale : services partagés globalement
La couche 1 est le référentiel de vos constructions de zone d’atterrissage Azure. Bien que Microsoft fournisse des modèles pour le déploiement de zones d’atterrissage Azure, vous souhaitez modifier certains composants et fournir un fichier de paramètres. Cela est analogue à la façon dont vous extrayez les dépôts de registre et de modules publics dans la couche 0, comme décrit précédemment.
Azure Container Registry est une partie essentielle de cette architecture. Même si votre entreprise n’a pas de plan d’utilisation de conteneurs, vous devez déployer Container Registry pour réussir le contrôle de version des modèles Bicep. Container Registry offre une flexibilité et une réutilisation significatives pour vos modules tout en fournissant un contrôle de sécurité et d’accès de niveau entreprise.
La couche 1 doit contenir les éléments suivants :
- Affectations de stratégie et définitions appliquées au niveau du groupe d’administration ou de l’abonnement. Ces stratégies doivent correspondre à vos exigences de gouvernance d’entreprise.
- Modèles pour l’infrastructure réseau principale, comme ExpressRoute, VPN, WAN virtuel et réseaux virtuels (partagés ou hub).
- DNS.
- Surveillance principale (analytique des journaux d'activité).
- Registre de conteneurs d’entreprise.
Vous devez configurer la protection de branche pour restreindre la possibilité d’envoyer des modifications à ce référentiel. Restreindre l’approbation des PR d’autres développeurs aux membres de la CCoE ou de la gouvernance cloud. Les contributeurs à cette couche sont principalement membres de groupes qui sont historiquement associés aux composants de cette couche. Par exemple, l’équipe de mise en réseau génère les modèles du réseau, l’équipe d’opérations configure la surveillance, et ainsi de suite. Toutefois, vous devez accorder un accès en lecture seule aux personnes qui le demandent, car vous souhaitez permettre aux développeurs d’autres groupes de suggérer des modifications aux infrastructures principales. Ils peuvent contribuer à des améliorations bien que vous ne puissiez pas fusionner leurs modifications sans approbation et test.
Ces fichiers doivent consommer les modules de votre registre de conteneurs pour les composants standard. Toutefois, vous disposez également d’un fichier Bicep ou d’une série de fichiers Bicep personnalisés pour l’implémentation de zones d’atterrissage Azure ou d’une structure de gouvernance similaire dans votre entreprise.
Couche 2 - Plateforme de produits : services partagés
Vous pouvez envisager la couche 2, plateforme de produits, en tant que services partagés pour une ligne de produits ou une unité commerciale particulière. Ces composants ne sont pas universels au sein de l’organisation, mais ils sont destinés à répondre à un besoin d’entreprise particulier. Il s’agirait d’une couche appropriée pour un réseau virtuel qui est un homologue avec le hub dans l’infrastructure globale de couche 1. Un coffre de clés constitue un autre exemple de composant pour cette couche. Le coffre de clés peut stocker des secrets partagés dans un compte de stockage ou une base de données partagée par les différentes applications de cette plateforme.
La couche 2 doit contenir ce qui suit :
- Affectations de stratégie appliquées à un abonnement ou à un groupe de ressources pour répondre aux exigences spécifiques au produit.
- Modèles ARM pour les coffres de clés, l’analytique des journaux d’activité, une base de données SQL (si plusieurs applications au sein du produit utilisent la base de données) et Azure Kubernetes Service.
Vous devez implémenter des autorisations qui limitent la possibilité d’envoyer des modifications à ce référentiel. Comme les autres couches, vous devez utiliser la protection de branche pour vous assurer qu’un responsable de produit ou un propriétaire peut approuver les PR d’autres développeurs. Il n’existe pas de règles fixes sur l’accès en lecture à la plateforme de produits, mais au minimum, les développeurs de l’une des équipes d’application doivent avoir accès en lecture pour pouvoir suggérer des modifications. Étant donné que la couche 2 peut contenir une architecture propriétaire ou des informations similaires, vous pouvez choisir de restreindre l’accès à ceux de l’organisation qui utilisent la plateforme. Toutefois, si c’est le cas, vous devez vous assurer que vous créez un processus de récolte de bonnes pratiques et d’extraits de code à partir de ce référentiel pour partager avec la bibliothèque globale, Couche 0.
Couche 3 - Application
La Couche 3, couche application, inclut les composants basés sur la plateforme de produits. Ces composants fournissent les fonctionnalités que l’entreprise demande. Par exemple, pour une plateforme de diffusion en continu, une application peut fournir la fonction de recherche alors qu’une autre application fournit des recommandations.
La couche 3 doit contenir les éléments suivants :
- Code d’application en C#, Python, et ainsi de suite.
- Infrastructure pour les composants individuels (c’est-à-dire uniquement utilisés dans cette application) : fonctions, Azure Container Instances, Event Hubs.
Les autorisations sont restreintes pour la capacité de pousser des changements vers ce référentiel. Vous devez utiliser la protection de branche pour permettre à un membre de l’équipe de cette application d’approuver une PR effectuée par un autre membre de l’équipe. Les membres de l’équipe ne doivent pas être autorisés à approuver leurs propres modifications. Étant donné que cette couche peut contenir une architecture propriétaire, une logique métier ou des informations similaires, vous pouvez choisir de restreindre l’accès aux utilisateurs de l’organisation qui créent cette application. Toutefois, si c’est le cas, vous devez également créer un processus de récolte de bonnes pratiques et d’extraits de code de cette couche à partager avec la bibliothèque globale, Couche 0.
Points communs entre couches
Bien que cet article décrive certains détails spécifiques pour chaque couche, il existe également certaines qualités communes à considérer pour toutes les couches.
Votre infrastructure doit fonctionner comme s’il s’agissait d’une application. Cela signifie que vous devez avoir un processus d’intégration continue (CI) dans lequel de nouvelles fonctionnalités sont testées entièrement, avec des tests unitaires, des tests d'acceptation de build et des tests d’intégration. Vous devez fusionner uniquement du code qui passe ces tests dans la branche de mise en production principale.
Vous devez également vous assurer que vous avez mis en place des stratégies de branche pour empêcher les individus de contourner le processus, même par opportunisme. Si votre processus CI est considéré comme un obstacle, cela signifie que vous avez contracté une dette technique qui doit être traitée. Cela ne signifie pas que vous devez supprimer les stratégies et les protections.
Enfin, bien que vous n’ayez peut-être pas d’index sur tous les référentiels et le code au sein d’eux, votre organisation doit développer un processus permettant aux individus de demander l’accès aux référentiels. Certaines règles peuvent être entièrement automatisées. Par exemple, vous pouvez implémenter une règle qui accorde un accès en lecture, sans examen, à un contributeur qui fait partie de l'équipe produit pour toute application de ce produit. Ces règles peuvent souvent être implémentées avec des attributions de rôles basées sur un groupe et basées sur des groupes dans vos environnements. La configuration de ce type d’accès doit aider à faciliter l’approvisionnement interne et les connaissances organisationnelles.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
- Tim Sullivan | Architecte de solution cloud senior
Autres contributeurs :
- Gary Moore | Programmeur/rédacteur
Étapes suivantes
- Zone de conception : automatisation de la plateforme et le DevOps
- Structures d’équipe matures
- Qu’est-ce que l’infrastructure en tant que code ?
- Azure/ResourceModules : ce référentiel inclut une plateforme CI et une collection de modules Bicep matures et organisés. La plateforme prend en charge Azure Resource Manager et Bicep ; vous pouvez utiliser ses fonctionnalité avec des actions GitHub et Azure Pipelines.
- Créer un registre privé pour le module Bicep