Qu’est-ce que l’infrastructure en tant que code ?

  • 10 minutes

Vous êtes invité à évaluer si l’infrastructure en tant que code peut être une approche intéressante de l’approvisionnement des ressources au niveau de votre entreprise. Vous examinez les options disponibles pour le déploiement, notamment :

  • Portail Azure
  • Azure CLI
  • Azure PowerShell
  • Modèles Azure Resource Manager (JSON et Bicep)

Vous recherchez une option reproductible et vous devez choisir la technologie à utiliser pour déployer votre infrastructure Azure.

Dans cette unité, découvrez comment et pourquoi l’infrastructure en tant que code peut vous aider à déployer votre infrastructure Azure de façon automatisée et reproductible.

Des commandes Azure CLI sont utilisées pour illustrer les concepts. Apprenez-en davantage sur l’utilisation de commandes pour déployer des ressources dans d’autres modules du parcours d’apprentissage de Bicep.

Définition de l’infrastructure en tant que code

Votre entreprise conçoit de nouveaux jouets en vue d’une mise sur le marché et la plupart des nouveaux jouets requièrent un assembly après achat. L’équipe de conception de la société crée des manuels d’instructions à joindre à chaque jouet. Chaque manuel fournit des détails sur la manière d’assembler correctement le jouet.

Vous pouvez considérer l’infrastructure en tant que code comme le manuel d’instructions de votre infrastructure. Le manuel détaille la configuration finale de vos ressources et comment atteindre cet état de configuration.

L’infrastructure en tant que code est le processus d’automatisation de l’approvisionnement de votre infrastructure. Elle utilise un langage de codage descriptif et un système de contrôle de version similaire à celui utilisé pour le code source. Lorsque vous créez une application, votre code source génère le même résultat chaque fois que vous le compilez. De la même façon, les déploiements de l’infrastructure en tant que code sont automatisés, cohérents et reproductibles. L’infrastructure en tant que code peut automatiser les déploiements de vos ressources d’infrastructure, telles que les réseaux virtuels, les machines virtuelles, les applications et le stockage.

Diagramme montrant l’infrastructure en tant que processus de code utilisant un référentiel de code source avec un modèle qui déploie des ressources Azure.

En repensant au manuel d’instructions du nouveau jouet, il existe plusieurs façons d’écrire le manuel d’instructions. L’une des options consiste à détailler chaque étape du processus de génération. Une autre option consiste à afficher une vue éclatée des éléments et des pièces nécessaires pour assembler le jouet. Plus loin dans cette unité, découvrez les différences entre le code impératif et le code déclaratif et la façon dont ils sont liés aux manuels d’instructions de votre entreprise.

Pourquoi utiliser l’infrastructure en tant que code ?

L’adoption d’une approche d’infrastructure en tant que code offre de nombreux avantages à l’approvisionnement des ressources. Grâce à l’infrastructure en tant que code, vous pouvez :

  • augmenter la confiance dans vos déploiements
  • gérer plusieurs environnements
  • mieux comprendre vos ressources cloud

Augmenter la confiance

L’un des avantages de l’utilisation de l’infrastructure en tant que code est le niveau de confiance que vous obtenez dans vos déploiements grâce à des améliorations de la cohérence et de la sécurité.

  • Intégration aux processus actuels : Si votre organisation utilise déjà des pratiques de développement logiciel standard, vous pouvez adopter les mêmes processus pour vos déploiements d’infrastructure. Par exemple, les évaluations par les pairs peuvent aider à détecter des problèmes dans les configurations qui peuvent être difficiles à détecter lors des modifications manuelles.

  • Cohérence : l’adoption d’une approche d’infrastructure en tant que code aide votre équipe à suivre les processus bien établis pour déployer l’infrastructure. En suivant ces processus, la responsabilité passe d’un petit groupe de personnes à votre processus d’automatisation et à vos outils. L’infrastructure en tant que code permet de réduire les erreurs humaines dans l’approvisionnement des ressources et de garantir des déploiements cohérents.

  • Analyse automatisée : Vous pouvez analyser les configurations d’infrastructure en tant que code avec des outils automatisés qui peuvent rechercher des erreurs dans le code. Les outils automatisés peuvent également passer en revue des modifications proposées pour vérifier que les pratiques de sécurité et de niveau de performance sont respectées.

  • Gestion des secrets : de nombreuses solutions requièrent des secrets, comme des chaînes de connexion, des clés de chiffrement, des secrets client et des certificats. Dans Azure, Azure Key Vault est le service utilisé pour stocker ces secrets en toute sécurité. De nombreux outils d’infrastructure en tant que code peuvent s’intégrer à Key Vault pour accéder à ces secrets de façon sécurisée lors du déploiement.

  • Contrôle d’accès : Avec les déploiements d’infrastructure en tant que code, vous avez la possibilité d’utiliser des identités managées ou des comptes de service pour automatiser le provisionnement des ressources. Ce processus garantit que seules ces identités peuvent modifier vos ressources cloud. Cela permet également d’éviter que des configurations incorrectes soient déployées en production. Si nécessaire, vous pouvez remplacer ce processus à l’aide d’un compte d’accès d’urgence (souvent appelé compte de secours) ou en utilisant la fonctionnalité Microsoft Entra Privileged Identity Management.

  • Éviter la dérive de configuration : Idempotence est un terme fréquemment associé à l’infrastructure en tant que code. Lorsqu’une opération est idempotente, cela signifie qu’elle fournit le même résultat chaque fois que vous l’exécutez. Si vous choisissez des outils qui utilisent des opérations idempotentes, vous pouvez éviter la dérive de la configuration.

En guise d’exemple d’idempotence, considérez la commande Azure CLI suivante. La commande crée un groupe de ressources Azure nommé storage-resource-group dans la région USA Est.

az group create \
  --name storage-resource-group \
  --location eastus

Si vous exécutez cette commande une deuxième fois, vous recevez exactement la même sortie, car cette commande Azure CLI a été conçue pour être idempotente. Vous n’obtiendrez pas d’erreur ou de groupe de ressources en double.

Lorsque vous utilisez l’infrastructure en tant que code, vous pouvez redéployer votre environnement à chaque version de votre solution. Ces versions peuvent incorporer de petites modifications de configuration ou même des mises à jour importantes. Ce processus permet d’éviter la dérive de la configuration. Si une modification accidentelle est apportée à une ressource, elle peut être corrigée en redéployant la configuration. En suivant cette approche, vous documentez votre environnement à l’aide du code.

Gérer plusieurs environnements

De nombreuses organisations gèrent plusieurs environnements d’application. Il est possible que les développeurs de votre société de jouets aient plusieurs versions intermédiaires du code de l’application dans un référentiel à mettre en production dans différents environnements. Ces environnements comprennent le développement, les tests et la production. Certaines organisations gèrent plusieurs environnements de production pour les applications qui sont distribuées dans le monde entier. D’autres organisations, comme les éditeurs de logiciels indépendants (ISV), gèrent les environnements multilocataires pour leurs clients.

Voici quelques-unes des principales façons dont l’infrastructure en tant que code peut vous aider à gérer vos environnements :

  • Configurer de nouveaux environnements : l’un des principaux avantages du cloud computing est la possibilité de mettre à l’échelle. L’infrastructure en tant que code peut vous aider à mettre à l’échelle plusieurs instances de votre application. Ces instances peuvent vous aider lors de l’augmentation de la charge ou vous pouvez les déployer pour les utilisateurs dans d’autres régions du monde. Cette agilité peut également être avantageuse lorsque vous testez votre application, par exemple lors de tests de pénétration, de tests de charge et de tests de bogues. Avec une base de code bien définie, vous pouvez approvisionner dynamiquement ces nouveaux environnements de manière cohérente.

  • Environnements hors production : Un problème courant rencontré par les organisations est la différenciation entre les environnements de production et hors production. Lorsque vous approvisionnez manuellement des ressources dans des environnements distincts, il est possible que les configurations finales ne correspondent pas. C’est le cas, par exemple, lorsque vous déployez une nouvelle fonctionnalité dans un environnement hors production qui diffère de l’environnement de production. Il est possible que la nouvelle fonctionnalité ne s’exécute pas comme prévu dans l’environnement de production en raison des différences entre les deux environnements. L’utilisation de l’infrastructure en tant que code peut aider à réduire ces problèmes. Vous pouvez utiliser les mêmes fichiers config pour chaque environnement, mais fournir différents paramètres d’entrée pour créer un caractère unique.

  • Récupération d’urgence : dans certains cas, l’infrastructure en tant que code peut être utilisée dans le cadre du plan de récupération d’urgence d’une organisation. Par exemple, vous devrez peut-être recréer votre environnement dans une autre région en raison d’une panne de service. En utilisant l’infrastructure en tant que code, vous pouvez rapidement approvisionner une nouvelle instance pour basculer au lieu de déployer et tout reconfigurer manuellement.

Mieux comprendre vos ressources cloud

L'infrastructure en tant que code peut également vous aider à mieux comprendre l'état de vos ressources cloud :

  • Piste d’audit : Les versions des changements de vos configurations d’infrastructure en tant que code sont contrôlées de la même façon que le code source de votre application. Ces modifications sont suivies dans vos outils, comme avec l’historique des versions de Git. Ce suivi d’audit signifie que vous pouvez examiner les détails de chaque modification, qui a apporté la modification et quand la modification a été apportée.

  • Documentation : Vous pouvez utiliser de nombreuses configurations d’infrastructure en tant que code pour ajouter des métadonnées, telles que des commentaires, qui décrivent l’objectif du code dans votre configuration. Si votre organisation suit déjà un processus de documentation de code, envisagez d’adopter ces mêmes procédures avec votre code d’infrastructure.

  • Système unifié : de nombreuses fois, quand un développeur travaille sur une nouvelle fonctionnalité, il doit apporter des modifications au code d’application et au code d’infrastructure. Lorsque vous utilisez un système commun, votre organisation peut mieux comprendre la relation entre vos applications et votre infrastructure.

  • Meilleure compréhension de l’infrastructure cloud : lorsque vous utilisez le Portail Azure pour configurer des ressources, un grand nombre des processus sont extraits de l’affichage. L’infrastructure en tant que code peut vous aider à mieux comprendre le fonctionnement d’Azure et à résoudre les problèmes qui peuvent survenir. Par exemple, lorsque vous créez une machine virtuelle à l’aide du Portail Azure, certaines ressources créées sont extraites de l’affichage. Les disques managés et les cartes d’interface réseau sont déployés en arrière-plan. Lorsque vous déployez la même machine virtuelle à l’aide de l’infrastructure en tant que code, vous disposez d’un contrôle total sur toutes les ressources qui sont créées.

Code impératif et code déclaratif

Vous pouvez écrire un manuel d’instructions pour un nouvel assembly jouet de différentes façons. Pour automatiser le déploiement de services et d’une infrastructure, vous pouvez utiliser deux approches différentes : impérative et déclarative.

  • Avec le code impératif, vous exécutez une séquence de commandes, dans un ordre spécifique, pour atteindre une configuration finale. Ce processus définit ce que le code doit accomplir et comment accomplir la tâche. L’approche impérative est semblable à un manuel d’instructions pas à pas.

  • Avec le code déclaratif, vous spécifiez uniquement la configuration finale. Le code ne définit pas comment accomplir la tâche. L’approche déclarative est semblable au manuel d’instructions d’une vue éclatée.

Lorsque vous choisissez d’utiliser une approche impérative et une approche déclarative de l’approvisionnement des ressources, prenez en compte les outils qui peuvent déjà être utilisés dans votre organisation. Envisagez également l’approche qui peut correspondre à vos propres compétences.

Code impératif

Dans Azure, une approche de code impérative est effectuée par programme à l’aide d’un langage de script tel que Bash ou Azure PowerShell. Les scripts exécutent une série d’étapes permettant de créer, de modifier et même de supprimer vos ressources.

Cet exemple montre deux commandes Azure CLI qui créent un groupe de ressources et un compte de stockage.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

La première commande crée un groupe de ressources Azure nommé storage-resource-group dans la région USA Est. La deuxième commande crée un compte de stockage nommé mystorageaccount dans le groupe de ressources storage-resource-group, qui a été créé dans la première commande. La deuxième commande configure également certaines propriétés pour le compte de stockage, notamment le type de compte de stockage et son niveau d’accès.

Vous pouvez utiliser une approche impérative pour automatiser entièrement l’approvisionnement des ressources, mais l’approche présente quelques inconvénients. À mesure que votre architecture arrive à maturité, les scripts peuvent devenir complexes à gérer. Les commandes peuvent être mises à jour ou déconseillées, ce qui nécessite une révision des scripts existants.

Code déclaratif

Dans Azure, une approche de code déclaratif est obtenue à l’aide de modèles. De nombreux types de modèles peuvent être utilisés, notamment :

  • JSON
  • Bicep
  • Ansible, par RedHat
  • Terraform, par HashiCorp

Notes

Ce module se concentre sur l’utilisation des modèles Bicep.

Jetez un coup d’œil à l’exemple suivant d’un modèle Bicep qui configure un compte de stockage. La configuration du compte de stockage correspond à l’exemple de Azure CLI.

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

La section des ressources définit la configuration du compte de stockage. Cette section contient le nom, l’emplacement et les propriétés du compte de stockage, y compris sa référence et le type de compte.

Vous remarquerez peut-être que le modèle Bicep ne spécifie pas le mode de déploiement du compte de stockage. Il spécifie uniquement ce à quoi doit ressembler le compte de stockage. Nous laissons à Azure le soin de décider des étapes réelles à effectuer en arrière-plan pour créer ce compte de stockage ou pour le mettre à jour pour qu’il corresponde à la spécification.