Quoi de plus stressant qu’un serveur tournant comme une horloge depuis un long moment, et qui a subit plusieurs upgrade système et une quantité innombrable de déploiements au fil du temps ? Chaque nouveau déploiement devient un travail d’équilibriste, pour éviter de faire s’effondrer le château de cartes que devient inévitablement ce genre de machine, qu’elle soit physique ou virtuelle. Un petit hack manuel dans un script init ou un fichier de configuration, un voeu pieu de backporter la modification dans le système de gestion de configuration (pour peu qu’il y en ait un en place), et vous avez le doigt dans l’engrenage.
Avec l’avènement de la virtualisation et des solutions cloud, une nouvelle approche tend à se formaliser : l’infrastructure immuable. Voyons ensemble quels sont ses avantages, ses inconvénients et ses défis techniques.
Les équipes de développement sont coutumières de considérer leurs livrables comme des briques immuables. Ces livrables traversent les environnements de validation en étant lancés avec différentes configurations, jusqu’à faire leur chemin vers la production.
L’approche Infrastructure Immuable suit les mêmes principes mais en considérant comme brique de base celle qui convient à un système cloud ou virtualisé : l’image serveur. L’image serveur est la nouvelle brique de base pour construire notre système de plus grande envergure.
L’analogie a été reprise dans différentes conférences ces derniers mois : à l’ère du cloud, les serveurs ne doivent plus être traités comme des animaux de compagnie mais comme un cheptel. Une instance de serveur défectueuse doit pouvoir sans risque être arrêtée et remplacée par une instance fraîche.
Pour atteindre ce niveau de confiance et ainsi terminer des serveurs sans remords, il faut posséder un certain niveau de maturité en automatisation. Des outils de provisionning comme Puppet, Ansible, Chef ou Salt, permettent de provisionner la pile applicative au démarrage d’une nouvelle machine. Le principal inconvénient est le temps de mise en condition opérationnelle des machines. Si on additionne les temps de :
On arrive au mieux à une grosse poignée de minutes, au pire, au delà des 10 minutes. L’automatisation pure ne suffit donc pas lorsque les exigences du système atteignent un certain niveau de criticité.
Le scénario décrit au-dessus, suppose que l’on puisse démarrer une image serveur unique, qui se voit attribuer une pile applicative selon sa position dans les groupes de sécurité, sous-réseaux ou autres politiques de gestion de configuration.
L’étape suivante réalisée par de nombreux systèmes : exécuter la phase de configuration en amont puis gérer un catalogue d’images serveur qui vont pouvoir être démarrées directement sur l’environnement de production.
Cela revient à ajouter cette phase de création d’image pré-provisionnée à la fin de votre chaîne de livraison continue.
Pour pouvoir automatiser cette phase de création d’image, plusieurs outils s’offrent à vous en fonction de votre cible de déploiement :
Si vous ne savez pas lequel prendre, je vous encourage à commencer par Packer qui tend à éclipser ses camarades, par sa complétude technique et sa simplicité de prise en main.
Une objection récurrente dans les débats autour de l’approche Infrastructure Immuable est que le système dans sa globalité n’est jamais immuable. Un système totalement immuable n’aurait pas beaucoup d’utilité. Malgré cela, même s’il y a toujours une partie du système qui possède un état, changeant au fil du temps, de nombreux composants intermédiaires peuvent sûrement être considérés comme des briques sans états qui pourraient bénéficier de cette approche.
Pour les briques qui nécessitent la gestion d’un état, comme les bases de données, plusieurs approches sont possibles :
Dans la mesure où la réaction à toute panne est la suppression et le démarrage de nouvelles instances, tout diagnostic de la machine devient impossible. Pour pouvoir analyser à posteriori, il faut avoir mis en place un système de centralisation des logs efficace. Le post mortem de la machine devient alors possible au point central de récupération des logs, et cela de façon beaucoup plus sereine.
Puisque nous sommes dans un environnement cloud, il est possible d’automatiser, non pas une destruction des instances serveurs défectueuses, mais une “mise en quarantaine”. Une suspension de l’activité de l’instance, puis une mise à l’écart dans une zone à l’abri du trafic standard, permet aux équipes techniques de venir à posteriori analyser les incidents. On profite là de l’extrême plasticité des environnements cloud.
C’est une approche qui ne convient pas à tous les contextes techniques. Malgré cela, elle constitue une évolution naturelle des systèmes d’information qui font usage de cloud ou de virtualisation. Les bénéfices qu’elle apporte ne sont pas à négliger.
De la même façon qu’il est nécessaire de connaître les arcanes du système d’exploitation pour réaliser des déploiements tirant le meilleur parti de l’infrastructure, il convient de maîtriser l’environnement cloud sur lequel est déployé l’infrastructure pour en tirer un meilleur parti et le mettre au service de vos objectifs métiers.