Cet article de blog est un chapitre de l’ebook De l’administration au DevOps : La méthode sans chichis pour réussir le DevOps dans Azure. N’hésitez pas à le consulter si vous souhaitez plonger dans ce qu’il faut pour réussir le DevOps dans Microsoft Azure en apprenant l’Infrastructure as Code.
Si vous avez déjà créé une infrastructure cloud ou virtuelle sur site manuellement, vous savez qu’il y a beaucoup de clics ou beaucoup de saisie. L’Infrastructure as Code (IaC) s’occupe de cela.
Pour provisionner quoi que ce soit, il faut se souvenir de quelle page aller ou quelle commande exécuter. Si vous jouez simplement pour apprendre Azure, c’est bien, mais une fois que ce jeu se transforme en processus de production critique pour l’entreprise, où le temps c’est de l’argent, quelque chose doit changer.
Lorsque votre organisation commence à prendre au sérieux la provision et la gestion de l’infrastructure, vous allez rencontrer de nombreux nouveaux défis.
Vous serez confronté à des duplications de travail inutiles, à des cas répétés de syndrome de la grosse erreur, à des problèmes de gestion des changements, à une dérive de configuration, et plus encore. Plus l’organisation et l’équipe sont grandes, plus les problèmes sont importants. Tous ces problèmes peuvent être éliminés ou du moins atténués avec un concept appelé Infrastructure as Code (IaC).
Infrastructure as Code (IaC) : Par l’exemple
IaC est un terme de l’industrie qui fait référence au stockage de tout ce qui est nécessaire pour construire des composants d’infrastructure dans du code. Ce code est généralement défini dans des fichiers JSON ou YAML représentant à quoi votre infrastructure devrait ressembler.
Une fois que tous les composants sont définis dans un fichier structuré, un autre processus intervient, comprend le code et commence immédiatement à utiliser ce document comme instructions pour construire l’infrastructure.
Pour donner un exemple générique semblable à du pseudo-code, supposons que vous ayez une machine virtuelle (VM) à créer. Cette VM a des besoins tels que le calcul, le stockage et le réseau. Une approche IaC approximative consisterait à décrire la VM et tous ses composants dans un modèle.
Le Modèle
Dans l’extrait de code suivant, vous pouvez voir un exemple de la façon dont chaque composant est décomposé par une hiérarchie avec des attributs définis pour chaque composant. Cet exemple fictif a été créé dans un fichier JSON que la plupart des services appelleraient un modèle.
Ce modèle définit la VM et tous les attributs associés à cette VM. Il a un schéma spécifique auquel les auteurs de modèles adhèrent pour définir à quoi ressemble cette VM. Supposons ensuite que ce modèle soit enregistré dans un fichier appelé myvm.json.
Contrôle de source
Vous avez maintenant tout ce qui constitue une VM enregistré dans un seul fichier. Comme tout bon professionnel du DevOps, vous enregistrez ce fichier dans un système de contrôle de source. Vous avez ainsi un moyen de suivre les modifications apportées au fichier.
L’outil
Maintenant que le fichier est créé, vous avez besoin d’un outil ou d’un service pour lire ce fichier, qui comprend ce que vous essayez de construire. Cet outil utilise le modèle en entrée et construit la VM selon ces spécifications exactes, sans autre interaction.
Super, non ? Ce n’est pas tout.
Lutter contre la dérive de configuration
Supposons maintenant que vous ayez besoin de changer l’adresse IP statique attribuée à la carte réseau de cette machine virtuelle. Vous pourriez vous connecter à distance à la machine virtuelle et changer l’adresse IP, mais vous ne voulez pas le faire. Pourquoi ?
- Vous effectuez le changement manuellement, ce qui fait perdre du temps et est sujet aux erreurs humaines.
- Il n’y a pas de trace d’audit de la personne qui a effectué le changement de l’adresse IP et de la date à laquelle cela a été fait.
- Il n’y a pas de moyen automatisé de revenir en arrière si vous saisissez incorrectement l’adresse IP.
L’infrastructure en tant que code (IaC) peut résoudre tous ces problèmes. Avec seulement quelques frappes de clavier, vous pouvez effectuer ce changement de manière à ce que votre responsable et votre auditeur vous en félicitent.
Ouvrez myvm.json, modifiez l’attribut IPAddress, enregistrez le changement dans le contrôle de source et exécutez à nouveau l’outil. C’est fait.
L’outil sera suffisamment intelligent pour savoir ce qui doit être modifié. Il ne détachera pas la carte réseau ni ne reconstruira toute la machine virtuelle. Tous les outils et services IaC sont suffisamment intelligents pour savoir comment effectuer le changement. Magique !
Mais maintenant, vous venez de réaliser que vous avez utilisé la mauvaise adresse IP et que vous devez revenir en arrière. Pas de problème. Annulez le changement dans le contrôle de source, enregistrez, exécutez l’outil et vous êtes de retour en affaires.
Mais attendez, il y a plus.
Les débuts de la livraison continue.
Lorsque vous avez une infrastructure stockée dans des modèles sous contrôle de source, vous disposez d’un ensemble d’éléments pour le début d’une livraison automatisée ou d’un pipeline de livraison continue.
Rappelez-vous que vous deviez exécuter cet outil à chaque fois que vous modifiez le modèle. Dans un pipeline/workflow automatisé, cet outil s’exécute automatiquement. Une fois que le processus de création ou de modification de l’environnement est automatisé, l’infrastructure correspond.
Créez suffisamment de modèles et éventuellement, votre infrastructure entière peut être représentée dans du code ou comme du code.
Conclusion
IaC est une méthodologie DevOps qui permet aux opérations de suivre le modèle du développeur de logiciels. IaC apporte de nombreux avantages que les développeurs de logiciels exploitent depuis des années et les met entre les mains de l’administrateur système.
Source:
https://adamtheautomator.com/infrastructure-as-code-iac/