Aborder l'Infrastructure as Code

(musique techno) - Dans le secteur de l’administration système, l’automatisation n’est pas une nouveauté, mais en DevOps, c’est totalement différent. C’est ce que l’on appelle l’Infrastructure as Code. C’est une approche entièrement programmatique qui permet d’appliquer les pratiques de développement à nos systèmes. Avec la séparation Dev et Ops, les meilleures pratiques des uns ne sont pas transmises aux autres. Par exemple, le contrôle du code source. Une organisation de développement ne soumettant pas son code au contrôle source, c’est inconcevable. C’est de la folie ! - Tout à fait, mais beaucoup d’équipes opérations n’utilisent pas du tout le contrôle du code source. Même pas pour leurs scripts ou d’autres codes. Oui, ce n’est pas bien. Et si nous pouvions traiter nos systèmes comme du code ? [Homme à droite] Oui, on les développerait dans un IDE, on ferait les tests unitaires et d’intégration dans le cadre d’un pipeline d’intégration continue, et on les déploierait. [Homme à gauche] Et on pourrait aussi leur faire prendre des décisions au cours de l’exécution, en fonction de leur état. [Homme à droite] C’est le principe de l’Infrastructure as Code. Certains outils permettent de configurer les serveurs à partir de zéro, et grâce aux serveurs virtuels, aux serveurs Cloud ou aux conteneurs, tout peut être créé, modifié ou éliminé de manière programmatique. [Homme à gauche] Tout à fait, et voilà un exemple. Prenons Amazon Web Services. Vous pouvez décrire entièrement vos systèmes à l’aide du format JSON CloudFormation. [Homme à droite] Vous avez ensuite un actif en contrôle du code source accessible à tous et parfaitement identique à vos systèmes. Ainsi, vous savez que vos environnements de Dev, de simulation et de production sont identiques, puisqu’ils reposent sur la même spécification. [Homme à droite] Évitez de faire vos configurations manuellement. Même les interfaces utilisateur sont vos ennemies. Définissez votre infrastructure dans un modèle ou via un code qui utilise une API REST. [Homme à gauche] Ensuite, on peut la soumettre au contrôle source, la mettre dans un pipeline d’intégration continue pour la tester, et la déployer. Il serait extrêmement risqué de permettre aux développeurs de modifier le code en production. Oui, ça ne se fait plus du tout. C’est contraire aux approches consacrées, alors pourquoi le faire pour les systèmes ? Le principal défi de l’Infrastructure as Code est le changement des mentalités. C’est un nouveau domaine, donc il est impossible de garder les mêmes habitudes qu’avant ou de suivre les bonnes pratiques présentées sur des sites comme infrastructures.org. J’ai été responsable d’une mise à niveau réseau importante dans une grande entreprise IT avec une dizaine d’équipes. Le plan technique qui m’avait été présenté consistait à mettre hors service les applis, puis les bases de données, puis les serveurs, puis le SAN, pour changer le matériel et rallumer tout dans l’ordre inverse. Ensuite, les développeurs allaient tester leurs applis, donc j’ai dit « On risque de rencontrer plein de problèmes qu’il sera difficile de diagnostiquer au niveau applicatif. Comment comptez-vous tester votre niveau avant de passer le relais à l’autre équipe ? » Ils m’ont regardé d’un air perplexe. Ce n’était pas de leur faute. Il était tellement rare de faire des tests sur les infrastructures qu’ils n’y avaient même pas pensé, donc j’ai dit : « On continuera seulement quand chaque niveau pourra me dire comment ses tests seront effectués. » Après un brainstorming, on a trouvé de bonnes idées. L’administrateur UNIX a dit « Et si on déployait un script sur tous nos serveurs pour faire un balayage ping et voir à quoi chaque serveur peut se connecter, et après la mise à niveau, on refait la même chose et on compare. » Super. Pour appliquer l’Infrastructure as Code, il est vital que les ingénieurs infrastructure changent d’approche. Les outils seuls ne suffisent pas. - Aujourd’hui, il y a bien plus de choses à gérer, il ne s’agit plus d’un simple rack de serveurs comme avant. Les systèmes distribués, les systèmes Web évolutifs, les architectures de microservices, la virtualisation, le Cloud et les conteneurs gagnent en complexité. Et si vous continuez de travailler manuellement, il est impossible de rester à jour. Même l’automatisation traditionnelle peine à rester d’actualité, donc il est important de considérer les systèmes comme éphémères. Dans le domaine de l’Infrastructure as Code, on traite les serveurs comme du bétail, pas comme des animaux de compagnie. Oui. Vous n’avez pas à gérer et nommer individuellement chacun de vos serveurs. Vous devez les gérer globalement, comme des troupeaux. [Homme à gauche] Pour terminer, quelques mots sur la conception des solutions Infrastructure as Code. Les équipes Ops ont l’habitude de résoudre des problèmes avec des obstacles, et les développeurs, en écrivant du code. En rapprochant ces deux disciplines, vous pouvez obtenir les meilleures solutions possible. Passons maintenant à l’une des pratiques d’Infrastructure as Code les plus répandues : la gestion des configurations.