Qu'est-ce qu'Infrastructure as Code ?

En termes simples, l'infrastructure en tant que code ( IaC ) consiste à utiliser du code pour gérer et approvisionner l'infrastructure (réseaux, machines virtuelles, répartiteurs de charge, grappes, services et topologie de connexion) dans un modèle descriptif au lieu de processus manuels.

Avec IaC, les fichiers de configuration définissent votre infrastructure, ce qui facilite également la modification, le partage et la réutilisation des configurations. En codifiant votre infrastructure, vous mettez à disposition le même environnement chaque fois que vous évitez les modifications de configuration ad hoc non documentées.

Schematics utilise Ansible et Terraform en open source pour fournir un ensemble puissant d'outils IaC en tant que service permettant de programmer votre infrastructure de cloud. Avec Schematics, vous pouvez utiliser cet ensemble riche de fonctions d'automatisation IaC pour générer des piles de ressources de cloud, gérer leur cycle de vie, gérer les modifications dans leurs configurations, déployer vos charges de travail d'application et effectuer des opérations day-2.

Avantages de l'infrastructure en tant que code

L'adoption d'une approche IaC pour le déploiement de l'infrastructure résout de nombreux problèmes courants liés à l'approvisionnement de l'infrastructure et offre plusieurs avantages. Schematics vous permet de bénéficier de ces avantages sans avoir à installer, exécuter et gérer votre propre outil IaC.

  • Fiabilité et cohérence: de nouveaux environnements ou de nouvelles infrastructures sont mis à disposition de manière fiable. Les processus manuels entraînent des erreurs. Avec IaC, les mêmes configurations sont déployées à plusieurs reprises, sans différences. IaC améliore la cohérence entre les environnements et les déploiements.

  • Vitesse: IaC vous permet de configurer rapidement votre infrastructure complète via l'automatisation. Vous l'appliquez à chaque environnement, du développement à la production, au transfert, à l'assurance qualité, etc. Cela peut entraîner une réduction des coûts à mesure que le temps nécessaire au déploiement, à la gestion et à la maintenance des environnements diminue.

  • Suivi et responsabilité: les modifications apportées à l'infrastructure existante sont effectuées dans le code et les modifications sont suivies. Comme tout fichier de code source, vous disposez d'une traçabilité complète des modifications apportées à une configuration.

  • Détecter et corriger la dérive de l'environnement: si une partie de l'infrastructure est modifiée manuellement en dehors du code, elle peut être remise en ligne avec l'état souhaité lors de la prochaine exécution. La détection de dérive est une fonction des espaces de travail Schematics.

Pratiques recommandées

L'adoption de IaC pour le provisionnement et la gestion de la configuration s'accompagne d'un certain nombre de pratiques recommandées. Ces pratiques sont entièrement prises en charge lors de l'utilisation de Schematics.

Codification de tout dans IaC

Toutes les spécifications de l'infrastructure doivent être explicitement codées dans un fichier de configuration, par exemple sous forme de configurations Terraform ou de playbooks Ansible. Les fichiers de configuration sont la source unique de vérité de votre spécification d'infrastructure et décrivent les composants d'infrastructure utilisés dans leur configuration.

Réduire la documentation

IaC est la documentation. Avec IaC, les fichiers de configuration représentent la documentation et sont toujours à jour, ce qui réduit les efforts. La documentation restante concerne le processus. Gérez le code dans un système de contrôle de version.

Les fichiers de configuration IaC doivent être conservés dans un système de contrôle de version (VCS), tel que GitHub ou GitLab. Cela fournit une trace d'audit pour les modifications de code, mais offre également la possibilité de collaborer ou d'effectuer une révision par les pairs et de tester les modifications avant qu'elles ne soient appliquées.

Grâce à cette pratique, vous pouvez facilement suivre, gérer et annuler les modifications potentielles apportées à vos systèmes, avec une traçabilité et une visibilité améliorées.

Tests

L'une des pratiques que IaC emprunte au développement de logiciels est le test. Des tests rigoureux de la configuration de l'infrastructure jouent un rôle dans la réduction des problèmes post-déploiement. Lorsqu'ils sont combinés avec des systèmes de contrôle de version, les tests peuvent être déclenchés automatiquement chaque fois qu'une modification est apportée au code.

Avec l'intégration continue (CI) en place, la configuration de l'infrastructure de modèle peut être implémentée dans plusieurs environnements tels que l'environnement development, UAT, QA ou production avec des modifications minimales appliquées efficacement.

Infrastructure modulaire

La décomposition de l'infrastructure en modules permet de la réutiliser, d'améliorer la fiabilité et de faciliter le chemin d'adoption. Similaire à l'utilisation de modules et de packages dans les langages de programmation. Voici les avantages de cette pratique.

  • Les configurations fréquemment utilisées peuvent être codifiées en tant que modules et réutilisées plusieurs fois dans des environnements.
  • La fiabilité augmente à mesure que les modules peuvent être testés et durcis au fil du temps avec l'utilisation.
  • La composition à partir de modules réutilisables réduit la barrière des compétences à l'adoption d' IaC.
  • Les modifications sont plus faciles à effectuer et à tester au niveau d'un module.
  • Le risque de changement est réduit à mesure que les changements de configuration sont localisés.

Tirer parti des modules Terraform IBM

Les modules Terraform IBM(TIM) fournissent des composants d'infrastructure réutilisables et prêts à la production, spécialement conçus pour IBM Cloud. Ces modules respectent les meilleures pratiques de l'infrastructure en tant que code et réduisent considérablement la complexité du déploiement des services courants sur le site IBM Cloud.

Explorez les modules Terraform IBM pour découvrir des modules prédéfinis pour l'infrastructure VPC, les services de sécurité, l'observabilité, etc. Chaque module est minutieusement testé et entretenu par les experts de IBM Cloud, ce qui garantit la fiabilité et le respect des meilleures pratiques en matière de sécurité.

Approches déclaratives et impératives de IaC

En adoptant le site IaC,, il faut tenir compte de l'approche de l'outillage. Il existe deux styles différents, déclaratifs ou impératifs, parfois décrits comme procéduraux.

Une approche déclarative définit l'état souhaité du système, y compris les ressources dont vous avez besoin et les propriétés qu'ils doivent posséder, et l'outil est configuré pour vous. L'outil détermine lui-même les opérations pour atteindre l'état souhaité à partir de n'importe quel point de départ.

Une approche impérative définit plutôt les commandes spécifiques nécessaires pour obtenir la configuration souhaitée, et ces commandes doivent ensuite être exécutées dans le bon ordre.

Le chef est considéré comme un outil impératif. Terraform est classé comme déclaratif. Ansible est déclaratif mais peut également être utilisé avec des commandes impératives.

Terraform déclarative et gestion du cycle de vie

Schematics prend en charge Terraform et Ansible en tant qu'outils IaC avec des espaces de travail et des actions Schematics. Lorsque la gestion du cycle de vie est importante et que les environnements sont régulièrement montés et démontés, il est recommandé d'utiliser Terraform avec les espaces de travail Schematics. Terraform conserve un enregistrement de l'état actuel de votre infrastructure cloud déployée et Schematics est en mesure de supprimer votre infrastructure dans l'ordre inverse des dépendances sans intervention manuelle.

Idempotence

Un avantage de l'approche déclarative utilisée par Terraform et Ansible est idempotence. Les tâches idempotentes peuvent être exécutées plusieurs fois avec le même résultat final. Quel que soit l'état ou l'emplacement de départ précédent lors du redémarrage après des échecs, l'infrastructure et la configuration mises à disposition sont toujours les mêmes. Cet aspect est essentiel pour garantir la cohérence et la reproductibilité des environnements déployés à l'aide de Schematics.

La façon dont vous utilisez un outil et les modules utilisés ont un impact sur idempotency. En règle générale, les modules Terraform et Ansible sont écrits pour être idempotent. Avec les deux outils, nous pouvons écrire du code qui ne donne pas de résultat idempotent. Dans ce cas, la configuration peut dériver de l'état cible souhaité. Avec Terraform, cette forme de dérive est très probablement utilisée lorsque null-resources est utilisé pour étendre les fonctionnalités du fournisseur avec des scripts personnalisés qui ne sont pas idempotent.

L'immutabilité est une pratique IaC qui réduit le risque de dérive de l'état cible.

non modifiable

L'infrastructure non modifiable fait référence à la gestion des services et des déploiements de logiciels où les ressources telles que les conteneurs ou les machines virtuelles sont remplacées plutôt que modifiées (à l'aide de scripts). Le principal souci d'immuabilité ici est d'éviter la dérive de la configuration. Incohérences dues à des modifications locales ou manuelles ou à des différences dans la séquence des opérations automatisées. Modifications qui rendent plus difficile le débogage et la résolution des problèmes, et augmentent les coûts de support.

Pour garantir l'immuabilité et éliminer la dérive, toutes les modifications doivent être effectuées via la configuration Schematics IaC et les ressources telles que les instances de serveur virtuel doivent être redéployées lorsqu'elles doivent être mises à jour.

Etapes suivantes

Maintenant que vous en savez plus sur IaC, pourquoi ne pas revoir l'utilisation de IaC dans Schematics: