Déployer de manière Agile avec l’Infrastructure ‘as code’
Lors du développement d’une application ou d’un service en ligne, il est maintenant rare de ne pas avoir besoin d’une infrastructure pour la supporter :
- serveurs pour fournir l’application Web et gérer ses interactions
- bases de données pour la persistence des données
- stockage de ressources telles qu’images, documents, …
Ceci implique de provisionner cette infrastructure, configurer les différents services et de la faire évoluer en parallèle du produit.
La solution la plus immédiate sera de tout faire manuellement, en ligne de commande ou via une interface d’administration selon ce qui est à notre disposition, mais vont se poser plusieurs problèmes :
- comment garder une trace de la configuration réalisée ?
- comment revenir en arrière en cas de problème ?
- comment gérer les dépendances entre services ? (un serveur API et une base de données)
- comment dupliquer une configuration ? (pour avoir des environnements ‘dev’, ‘demo’ et ‘prod’)
- comment supprimer un environnement en fin de développement ?
Le pouvoir du code
L’infrastructure ‘as Code’ (ou IaC) est un modèle de configuration consistant à écrire son infrastructure de la même manière qu’on écrit le code d’une application : décrire les différents composants ainsi que leurs interactions dans des fichiers lisibles par un être humain et interprétables par un outil de build.
Ces fichiers sont ensuite donnés en entrée à un outil qui se charge d’appliquer les changements sur l’infrastructure. On retrouve alors tous les avantages des fichiers de code traditionnels :
Sauvegarde
Ces fichiers peuvent être stockés dans un gestionnaire de source type Git, ce qui amène la sauvegarde et la gestion d’historique. On peut facilement voir les évolutions de l’infrastructure au cours du temps et potentiellement revenir en arrière (ou en tout cas, définir facilement les étapes à effectuer pour annuler une action).
Maintenabilité
Suivant le format d’entrée attendu pour l’outil de déploiement, il est possible d’architecturer les fichiers de configuration afin de nommer les ressources utilisées, ajouter des commentaires, qui amélioreront la lisibilité et la maintenance de l’infrastructure.
Ces fichiers servent alors également de documentation.
Réplication
Comme dans tout code de qualité, on va pouvoir extraire des modules regroupant des ressources fréquemment dupliquées. Par exemple, un module regroupant toutes les ressources nécessaires à la fourniture en ligne de fichiers statiques.
Ce genre de module peut être réutilisé plusieurs fois au sein d’un projet, grâce à des paramètres d’entrée différents, mais aussi partagé entre projets !
Au niveau supérieur, il est même possible de répliquer facilement un environnement complet; les mêmes fichiers de configuration peuvent être utilisés pour générer les environnements ‘dev’, ‘demo’ et ‘prod’ en modifiant juste quelques paramètres. Par ce biais, on s’assure qu’aucune divergence ne se glissera entre les différents environnements.
Gestion des dépendances
Il est très rare que notre infrastructure soit composée de ressources totalement autonomes ; par exemple, un serveur API va probablement avoir besoin d’accéder à une base de données.
Suivant les outils utilisés, il sera possible de définir les liens entre ressources et les identifiants/urls d’accès seront automatiquement injectés dans les ressources. Ces liens seront utiles également pour les évolutions de notre infrastructure, par exemple en nous empêchant de supprimer une ressource si une autre ressource en dépend.
Quelques limitations
Tout n’est pas idyllique dans l’utilisation d’un outil d’IaC et il est nécessaire d’être conscient de ses inconvénients avant de se lancer :
Difficulté pour la mise en place
Puisqu’on décrit maintenant notre infrastructure dans de simples fichiers ‘code’, il n’y a plus d’interface utilisateur pour nous guider dans la création de nos ressources; plus d’assistant automatique non plus…
Il peut également y avoir une difficulté à trouver quelle ressource ‘code’ correspondant au type de ressource attendu; ce point dépendra grandement de la documentation de l’outil choisi.
Retard sur la disponibilité de nouvelles ressources/fonctions
Lorsqu’un fournisseur commercialise un nouveau type de ressources (par exemple, AWS commercialisant un nouveau type de base de données), l’outil de déploiement va potentiellement devoir être adapté pour supporter ce nouveau type.
Ce point dépendra grandement de la réactivité de l’éditeur et/ou de la communauté, mais aussi de la capacité de l’outil à permettre de contourner ce genre de problèmes.
Quel outil utiliser ?
La richesse des fonctions disponibles va dépendre des outils mis en place. Parmi les principaux outils, on peut citer Terraform, CloudFormation, Chef, Puppet ou Ansible. Il peut même être utile de combiner plusieurs d’entre eux, suivant les besoins.
Notre préférence va à Terraform, outil très complet au niveau de sa syntaxe, supportant de multiples ‘providers’ (AWS, Azure, GCP mais aussi Docker, Chef, …). Il est de plus gratuit, open source et dispose d’une communauté très active.
Conclusion
A l’ère du développement Agile et du devops, le déploiement et l’évolution d’une infrastructure se doit d’être simple, fiable et itératif. L’Infrastructure as Code répond en grande partie à ces problématiques et, combinée à l’utilisation de plateformes Cloud, nous offre une liberté d’action et un gain de temps sans pareil.
Vous avez aimé cet article ? Cliquez sur 👏 en bas de page pour que d’autres lecteurs puissent le trouver !
