Partager via

Recommandations pour l’utilisation de l’infrastructure en tant que code

  • Article

S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :

OE :05 Préparez les ressources et leurs configurations en tirant parti d’une approche standardisée d’infrastructure as code (IaC). 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 d’IaC comme standard pour vos déploiements d’infrastructure. L’utilisation de IaC vous permet d’intégrer vos déploiements et gestion d’infrastructure dans vos pratiques de développement de logiciels existantes. Il fournit une méthodologie cohérente et standard pour le développement et le déploiement pour tous les composants de votre charge de travail. L’utilisation de déploiements manuels met votre charge de travail à risque de configurations incohérentes et de 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 s’appuient sur le système pour déterminer comment déployer les ressources pour correspondre à l’état final défini.
Infrastructure immuable Infrastructure destinée à être remplacée par une nouvelle infrastructure qui exécute la nouvelle configuration avec chaque déploiement. Il ne doit pas être changé en place.
Outils impératifs Catégorie d’outils qui répertorient les étapes d’exécution qui entraînent l’état final souhaité.
Module Unité d’abstraction permettant de diviser les groupes de ressources pour simplifier les déploiements complexes.
Infrastructure mutable Infrastructure destinée à être modifiée. 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 la chaîne d’approvisionnement et les guides de normalisation des outils et des processus, vous devez disposer d’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 normaliser vos outils et processus de développement et de déploiement IaC dans un guide de style. Les recommandations pour votre guide de style sont les suivantes :

Préférer les outils déclaratifs par rapport aux outils impératifs

Les outils déclaratifs et leurs fichiers associés constituent un meilleur choix global pour déployer et gérer 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 requises pour accéder à 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 du maintien du code impératif, comme les scripts de déploiement, qui peuvent s’accumuler au fil du temps.

Utiliser des outils natifs et standard

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 d’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 mis à jour en continu par le fournisseur de plateforme, ce qui les rend plus utiles à mesure que la plateforme évolue.

Remarque

N’oubliez pas 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 d’outils et d’API avant de les adopter. De même, évitez d’utiliser l’indicateur « latest » lors de l’appel sur un outil ou une API dans votre code de déploiement. Soyez intentionnel d’appeler la dernière version correcte connue pour votre charge de travail.

Utiliser l’outil approprié pour la tâche

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 un cycle de vie d’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 des 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 le cadre de vos pratiques iaC et standardisez les outils qui effectuent les tâches dont vous avez besoin et peuvent être intégrés à vos pratiques de développement et de gestion.

Prise en charge de plusieurs environnements

Vos scripts et modèles doivent être suffisamment flexibles pour déployer facilement un large éventail d’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 de code. Paramètres abstraits tels que la taille des ressources, le nombre, le nom, les emplacements à déployer et certains paramètres de configuration. Soyez prudent de ne pas trop abstractionr, cependant. Il existe des paramètres qui peuvent être extraits avec un paramètre ou une variable qui peut 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.

Remarque

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

Utilisez l’équilibre approprié lors de l’encapsulation des fonctionnalités

Stratégiser et normaliser l’utilisation des modules. Comme les paramètres et les variables, les modules peuvent rendre vos déploiements d’infrastructure reproductibles. Soyez réfléchi, cependant, sur 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 ou combinaisons complexes 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 les modules open source gérés le cas échéant, dans, par exemple, des scénarios non sensibles.

Étapes manuelles du document

Normes de document pour les étapes manuelles. Il peut y avoir des étapes liées au déploiement et à la maintenance de l’infrastructure particulière à 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 les procédures d’exploitation standard, normalisez les étapes manuelles pour vous assurer que les tâches sont effectuées en toute sécurité et de manière cohérente.

Normes de document 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 par votre charge de travail et que vos outils IaC ne peuvent 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 supprimées. Ces ressources peuvent devenir orphelines si l’équipe de charge de travail ne se souvient pas de les supprimer manuellement. Pour gérer ces scénarios, normalisez une stratégie pour rechercher des ressources orphelines et les supprimer. Vous devez également envisager comment vous assurer que vos modèles sont à jour. Recherchez les limitations de vos outils IaC pour comprendre ce que vous devrez peut-être planifier dans ces situations.

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

Utiliser une approche en couches pour les pipelines IaC

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

L’infrastructure principale comme les ressources réseau nécessite rarement des 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 tactiles et tactiles moyen pour les ressources, en fonction de la complexité de votre charge de travail. À l’aide d’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’applications qui sont mis à jour très fréquemment en mode de livraison continue.

Traiter le code IaC et l’application identiques

Traiter vos artefacts IaC comme vos artefacts de code d’application vous permet d’appliquer la même rigueur pour gérer du code sur tous les pipelines. De plus, les pratiques de développement et de déploiement IaC doivent mettre en miroir les pratiques d’application. Les normes de contrôle de version, de branchement, de promotion du code et de qualité doivent toutes être identiques. Envisagez également de traiter vos ressources IaC avec vos ressources de code d’application. Cela permet de s’assurer que les mêmes processus sont suivis avec chaque déploiement et vous permettent d’éviter des problèmes tels que le déploiement par inadvertance de l’infrastructure avant le code d’application nécessaire, ou inversement.

Utiliser des normes et des ressources centralisées

Collaborez avec d’autres équipes de votre organisation pour la normalisation et la réutilisation. Les grandes organisations peuvent parfois avoir plusieurs équipes développant et prenant en charge des charges de travail. La collaboration entre les équipes pour s’entendre sur les normes vous permet de réutiliser des bibliothèques, des modèles et des modules pour améliorer l’efficacité et la cohérence dans les environnements de charge de travail. De même, les outils IaC doivent être normalisés au sein de l’organisation dans la mesure où cela est pratique.

Appliquer la sécurité dans le code IaC

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 pour rechercher les clés et les secrets exposés. L’un des avantages de l’utilisation de 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 garantir que la configuration approuvée pour la mise en production par la sécurité est en fait ce qui est déployé 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 courantes et non courantes. Tester les déploiements, les mises à jour de configuration et les processus de récupération, y compris les processus de restauration de déploiement.

Adopter un modèle de déploiement 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 disposez d’une conception d’infrastructure mature basée sur des tampons de déploiement, l’utilisation d’une infrastructure immuable peut être logique, 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 déterminent que la progression vers l’avant avec les déploiements lorsque des problèmes de déploiement mitigables se produisent est l’option préférée. Dans ce cas, vous mettez probablement à jour l’infrastructure en place.

À propos de l’installation

Spécialisation accrue : Dans certains cas, l’introduction de nouvelles langues dans votre équipe de charge de travail est fournie avec une courbe d’apprentissage, et le verrouillage du fournisseur peut en faire un mauvais choix. La formation des membres de votre équipe et l’analyse de l’outil approprié en fonction de la prise en charge des outils de vos fournisseurs de cloud est nécessaire.

Effort de maintenance accru : la maintenance de la base de code et des outils est nécessaire pour maintenir votre implémentation IaC actuelle et sécurisée. Suivez correctement votre dette technique et favorisez 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 pas de 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 plus 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. Équilibrez l’utilisation de la modularisation pour réduire la complexité et éviter le sur-ingénierie.

Facilitation Azure

Les modèles Azure Resource Manager (modèles ARM) et Bicep sont des outils natifs Azure pour déployer 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 dans des pipelines CI/CD GitHub Actions.

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 pour découvrir des configurations incorrectes dans IaC.

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 Virtual Desktop qui peut être déployée via des fichiers Resource Manager, Bicep ou Terraform fournis.

Liste de contrôle d’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle d’excellence opérationnelle