Recommandations relatives à l’utilisation de l’infrastructure en tant que code

  • Article

S’applique à cette recommandation de liste de contrôle d’excellence opérationnelle Azure Well-Architected Framework :

OE :05 Préparez les ressources et leurs configurations à l’aide d’une approche IaC (Infrastructure as code) standardisée. Comme d’autres codes, concevez IaC avec des styles cohérents, une modularisation appropriée et une assurance qualité. Préférez une approche déclarative lorsque cela est possible.

Ce guide décrit les recommandations relatives à l’utilisation de l’IaC comme norme pour vos déploiements d’infrastructure. L’utilisation de l’IaC vous permet d’intégrer vos déploiements et votre gestion d’infrastructure à vos pratiques de développement logiciel existantes. Il fournit une méthodologie standard cohérente pour le développement et le déploiement de tous les composants de votre charge de travail. L’utilisation de déploiements manuels expose votre charge de travail à des configurations incohérentes et à une conception potentiellement non sécurisée.

Définitions

Terme Définition
Outils déclaratifs Catégorie d’outils qui définissent l’état final d’un déploiement et qui s’appuient sur le système pour déterminer comment déployer les ressources pour qu’elles correspondent à l’état final défini.
Infrastructure immuable Infrastructure destinée à être remplacée par une nouvelle infrastructure qui exécute la nouvelle configuration à chaque déploiement. Il ne doit pas être modifié en place.
Outils impératifs Catégorie d’outils qui répertorie les étapes d’exécution qui aboutissent à l’état final souhaité.
Module Unité d’abstraction permettant de diviser des groupes de ressources afin de simplifier les déploiements complexes.
Infrastructure mutable Infrastructure destinée à être modifiée en place. Les déploiements modifient la configuration de l’infrastructure plutôt que de la remplacer par une nouvelle infrastructure.

Stratégies de conception

Comme indiqué dans les guides d’outils et de processus de chaîne logistique et de normalisation, vous devez avoir une stratégie stricte de déploiement des modifications d’infrastructure (y compris les modifications de configuration) uniquement par le biais du code. Vous devez déployer IaC via vos pipelines d’intégration continue et de livraison continue (CI/CD). L’adoption de ces stratégies applique la cohérence des processus pour tous les déploiements IaC, réduit le risque de dérive de configuration entre vos environnements et garantit la cohérence de l’infrastructure entre vos environnements. En outre, vous devez standardiser vos outils et processus de développement et de déploiement IaC dans un guide de style. Les recommandations relatives à votre guide de style sont les suivantes :

Préférez les outils déclaratifs aux outils impératifs. Les outils déclaratifs et leurs fichiers associés constituent un meilleur choix global pour le déploiement et la gestion de l’IaC que les outils impératifs. Les outils déclaratifs utilisent une syntaxe plus simple pour leurs fichiers de définition, définissant uniquement l’état souhaité de l’environnement une fois le déploiement terminé. Les outils impératifs dépendent de la définition des étapes nécessaires pour atteindre l’état final souhaité, de sorte que les fichiers peuvent être beaucoup plus complexes que les fichiers déclaratifs. Les fichiers de définition déclaratifs aident également à réduire la dette technique de la maintenance du code impératif, comme les scripts de déploiement, qui peut s’accumuler au fil du temps.

Utilisez les outils natifs de votre plateforme cloud et d’autres outils éprouvés par le secteur qui s’intègrent en mode natif à la plateforme. Votre plateforme cloud fournit des outils pour faciliter et simplifier le déploiement de l’IaC. Tirez parti de ces outils et d’autres outils tiers qui ont une intégration native, comme Terraform, plutôt que de développer vos propres solutions. Les outils natifs sont pris en charge par la plateforme et incluent des fonctionnalités intégrées pour la plupart de vos besoins. Ils sont continuellement mis à jour par le fournisseur de plateforme, ce qui les rend plus utiles à mesure que la plateforme évolue.

Notes

Gardez à l’esprit que lorsque les fournisseurs de cloud et les développeurs tiers mettent à jour leurs outils et API, vous pouvez exécuter le risque de problèmes imprévus lors de l’utilisation de la dernière version de votre charge de travail. Veillez à tester minutieusement les nouvelles versions des outils et des API avant de les adopter. De même, évitez d’utiliser l’indicateur « dernier » lors de l’appel d’un outil ou d’une API dans votre code de déploiement. Soyez intentionnel lors de l’appel de la dernière version correcte connue pour votre charge de travail.

Utilisez les outils appropriés pour des tâches et des types d’infrastructure spécifiques. Plusieurs tâches, au-delà des déploiements, sont impliquées dans le cycle de vie d’une infrastructure. La configuration doit être appliquée et gérée, par exemple, et l’outil que vous utilisez pour scripter des déploiements, comme Bicep, peut ne pas être le meilleur outil pour chaque opération de gestion.

De même, l’application de la configuration d’état souhaité (DSC) pour différents types d’infrastructure peut nécessiter différents outils. Par exemple, il existe des outils spécifiques comme Ansible pour la gestion de DSC pour les machines virtuelles, tandis que Flux est un bon outil pour gérer DSC sur les clusters Kubernetes. Les services PaaS (Platform as a Service) peuvent fournir différents outils pour la gestion de la configuration (comme Azure App Configuration) qui peuvent être gérés via IaC. Les services SaaS (Software as a Service) peuvent être plus limités, car ils sont plus étroitement contrôlés par la plateforme.

Réfléchissez à toutes les tâches et types d’infrastructure qui sont dans l’étendue de vos pratiques IaC et standardisez les outils qui effectuent les tâches dont vous avez besoin et qui peuvent être intégrés à vos pratiques de développement et de gestion.

Vos scripts et modèles doivent être suffisamment flexibles pour déployer facilement divers environnements. Utilisez des paramètres, des variables et des fichiers de configuration pour déployer un ensemble standard de ressources qui peuvent être modifiées pour déployer n’importe quel environnement dans votre pile de promotion du code. Paramètres abstraits tels que la taille de la ressource, le nombre, le nom, les emplacements dans 5000 et certains paramètres de configuration. Attention toutefois à ne pas trop abstraire. Il existe des paramètres qui peuvent être extraits avec un paramètre ou une variable qui peuvent ne pas réellement changer au cours du cycle de vie de la charge de travail, ou qui peuvent changer rarement. Ils ne devraient pas être abstraits.

Notes

Évitez d’utiliser différentes ressources IaC pour différents environnements. Vous ne devez pas avoir différents fichiers Terraform pour les environnements de production et de test, par exemple. Tous les environnements doivent utiliser un seul fichier. Vous pouvez manipuler ce fichier pour le déployer dans différents environnements en fonction des besoins.

Élaborer des stratégies et normaliser l’utilisation des modules. Comme les paramètres et les variables, les modules peuvent rendre vos déploiements d’infrastructure reproductibles. Soyez toutefois attentif à la façon dont vous les utilisez. Une stratégie d’abstraction standardisée permet de s’assurer que les modules sont conçus pour répondre à des objectifs spécifiques et convenus. Utilisez des modules pour encapsuler des configurations complexes ou des combinaisons de ressources. Évitez les modules si vous utilisez uniquement la configuration par défaut de la ressource. En outre, soyez judicieux dans le développement de nouveaux modules. Utilisez des modules open source gérés le cas échéant, par exemple dans des scénarios non sensibles.

Normes de document pour les étapes manuelles. Il peut y avoir des étapes liées au déploiement et à la maintenance de l’infrastructure qui sont spécifiques à votre environnement et qui nécessitent une intervention manuelle. Assurez-vous que ces étapes sont réduites autant que possible et clairement documentées. Dans votre guide de style et vos procédures d’exploitation standard, normalisez les étapes manuelles pour vous assurer que les tâches sont exécutées de manière sécurisée et cohérente.

Documenter les normes pour gérer les ressources orphelines. Selon les outils que vous utilisez pour la gestion de la configuration et leurs limitations, il peut arriver qu’une ressource particulière ne soit plus nécessaire à votre charge de travail et que vos outils IaC ne puissent pas supprimer automatiquement la ressource. Par exemple, supposons que vous passez de machines virtuelles à un service PaaS pour une fonction, et que les outils IaC n’ont pas de logique pour supprimer les ressources mises hors service. Ces ressources peuvent devenir orphelines si l’équipe de charge de travail ne se rappelle pas de les supprimer manuellement. Pour gérer ces scénarios, standardisez une stratégie pour rechercher les ressources orphelines et les supprimer. Vous devez également réfléchir à la façon de vous assurer que vos modèles sont à jour. Recherchez les limitations de vos outils IaC pour comprendre ce que vous pourriez avoir besoin de planifier dans ces situations.

Autres stratégies IaC

Tenez compte des recommandations suivantes qui s’appliquent à l’utilisation de l’IaC pour votre charge de travail :

Utilisez une approche en couches pour aligner vos pipelines IaC dans la pile de charge de travail. La séparation de vos pipelines IaC en couches vous aide à gérer les environnements complexes. Le déploiement de dizaines ou de centaines de ressources en tant que package monolithique est inefficace et peut entraîner plusieurs problèmes, tels que des dépendances rompues. L’utilisation de plusieurs pipelines alignés sur des couches composées de ressources dont les cycles de vie de déploiement ou les facteurs tels que les fonctionnalités correspondent étroitement rend la gestion des déploiements IaC plus facile.

L’infrastructure de base, comme les ressources réseau, a rarement besoin de modifications plus complexes que les mises à jour de configuration, de sorte que ces ressources doivent créer un pipeline IaC faiblement tactile . Vous pouvez avoir un ou plusieurs pipelines IaC tactile moyen et tactile élevé pour les ressources, en fonction de la complexité de votre charge de travail. En utilisant une pile d’applications basée sur Kubernetes comme exemple, une couche tactile moyenne peut être composée des clusters, des ressources de stockage et des services de base de données. Les couches tactiles élevées sont composées des conteneurs d’application qui sont mis à jour très fréquemment en mode de livraison continue.

Traitez votre IaC et votre code d’application de la même façon. Le fait de traiter vos artefacts IaC de la même manière que les artefacts de code de votre application vous permet d’appliquer la même rigueur de gestion du code sur tous les pipelines. En outre, les pratiques de développement et de déploiement IaC doivent miroir pratiques d’application. Les normes relatives au contrôle de version, à la branchement, à la promotion du code et à la qualité doivent toutes être identiques. Envisagez également de regrouper vos ressources IaC avec vos ressources de code d’application. Cela permet de s’assurer que les mêmes processus sont suivis à chaque déploiement et d’éviter des problèmes tels que le déploiement par inadvertance de l’infrastructure avant le code d’application nécessaire, ou vice versa.

Collaborez avec d’autres équipes de votre organization pour la standardisation et la réutilisation. Les grandes organisations peuvent parfois avoir plusieurs équipes qui développent et supportent des charges de travail. La collaboration entre les équipes pour s’entendre sur des normes vous permet de réutiliser les bibliothèques, les modèles et les modules pour gagner en efficacité et en cohérence dans les environnements de charge de travail. De même, les outils iaC devraient être standardisés dans l’ensemble des organization dans la mesure où cela est pratique.

Appliquez le principe de « sécurité en tant que code » pour vous assurer que la sécurité fait partie du pipeline de déploiement. Incluez l’analyse des vulnérabilités et le renforcement de la configuration dans le cadre du processus de développement IaC. Analysez vos dépôts IaC à la recherche de clés et de secrets exposés. L’un des avantages de l’iaC est que les membres de l’équipe axée sur la sécurité peuvent passer en revue le code avant le déploiement pour s’assurer que la configuration approuvée pour la mise en production par la sécurité est bien celle déployée en production. Pour obtenir des conseils détaillés, consultez Recommandations pour la sécurisation d’un cycle de vie de développement.

Tester les activités de routine et non routinière. Tester les déploiements, les mises à jour de configuration et les processus de récupération, y compris les processus de déploiement-restauration.

Infrastructure mutable et immuable

Le choix entre le déploiement d’une infrastructure mutable et immuable dépend de quelques facteurs. Si votre charge de travail est critique pour l’entreprise, il est préférable d’utiliser une infrastructure immuable. De même, si vous avez une conception d’infrastructure mature basée sur des empreintes de déploiement, l’utilisation d’une infrastructure immuable peut être utile, car vous pouvez déployer du code d’application et une nouvelle infrastructure de manière fiable. À l’inverse, l’utilisation d’une infrastructure mutable peut être un meilleur choix si vos pratiques de déploiement sécurisées dictent que l’option préférée est de passer à l’avant avec les déploiements lorsque des problèmes de déploiement mitigables surviennent. Dans ce cas, vous mettez probablement à jour l’infrastructure en place.

Considérations

Spécialisation accrue : Dans certains cas, l’introduction de nouveaux langages dans votre équipe de charge de travail s’accompagne d’une courbe d’apprentissage, et le verrouillage du fournisseur peut en faire un mauvais choix. Il est nécessaire de former les membres de votre équipe et d’analyser l’outil approprié en fonction de la prise en charge des outils de vos fournisseurs de cloud.

Effort de maintenance accru : La maintenance de la base de code et des outils est nécessaire pour maintenir votre implémentation IaC à jour et sécurisée. Suivez correctement votre dette technique et encouragez une culture où la réduction de la dette est récompensée.

Temps accru pour les modifications de configuration : Le déploiement de l’infrastructure à l’aide d’instructions de ligne de commande ou directement à partir d’un portail ne nécessite aucun temps de codage et/ou de test d’artefacts. Réduisez le temps de déploiement en suivant les pratiques recommandées, telles que les révisions de code et les pratiques d’assurance qualité.

Complexité accrue de la modularisation : L’utilisation de davantage de modules et de paramétrage augmente le temps nécessaire pour déboguer et documenter le système et ajoute une couche d’abstraction. Équilibrer l’utilisation de la modularisation pour réduire la complexité et éviter la sur-ingénierie.

Animation Azure

Les modèles Azure Resource Manager (modèles ARM) et Bicep sont des outils natifs Azure pour le déploiement de l’infrastructure à l’aide de la syntaxe déclarative. Les modèles ARM sont écrits en JSON, tandis que Bicep est un langage spécifique au domaine. Les deux peuvent facilement être intégrés dans des pipelines Azure ou GitHub Actions des pipelines CI/CD.

Terraform est un autre outil IaC déclaratif entièrement pris en charge dans Azure. Il peut être utilisé pour déployer et gérer l’infrastructure, et peut être intégré à votre pipeline CI/CD.

Vous pouvez utiliser Microsoft Defender pour le cloud afin de détecter des configurations incorrectes dans IaC.

Alignement organisationnel

Cloud Adoption Framework fournit des conseils aux équipes centrales sur la façon de standardiser l’infrastructure en tant que code dans les équipes de charge de travail du organization.

Pour plus d’informations, consultez Infrastructure as Code dans le Cloud Adoption Framework.

Exemple

Consultez l’architecture de l’accélérateur de zone d’atterrissage Azure Virtual Desktop et l’implémentation de référence associée pour obtenir un exemple d’implémentation de Virtual Desktop qui peut être déployée via des fichiers Resource Manager, Bicep ou Terraform fournis.

Liste de contrôle de l’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de l’excellence opérationnelle