Parmi les pratiques pronées par une approche Devops, une pratique est particulièrement représentative de l’hybridation progressive des manières de travailler dans le domaine des technologies de l’information : La programmation de l’infrastructure ou « Infrastructure as code ».

Analyse par Pierre-Antoine Grégoire – IT Architect & Agilist chez Agile Partner.

 

Infrastructure : effet de masse et spécialisation

La généralisation de la virtualisation et la popularisation des conteneurs (par des outils comme Docker), ont amené le nombre d’environnements à gérer (Développement/Sandbox, QA/Testing, Intégration, Production, Cloud privé ou public) et la diversité de configuration de ces environnements (serveur web, serveur de cache, serveur d’applications, base de données, serveur de reporting, annuaires, …) à exploser. Des besoins émergents (mobilité, bigdata) ou plus sensible (auditabilité de sécurité) engendrent le besoin de déploiement de nombreuses solutions inédites et consommatrices en ressources humaines et techniques.

Une pression importante est mise sur les systèmes IT pour fournir des serveurs spécialisés à une cadence importante, tout en garantissant sécurité, continuité de service, facilité à diagnostiquer les problèmes.

Cet effet de masse engendre 2 réflexes:

1. vouloir simplifier le besoin, et tenter de diminuer la spécialisation
2. vouloir revenir à de la centralisation (en créant des ressources partagées par exemple dans le cas des micro-services)

Ces intuitions peuvent permettre de rationaliser les types d’environnement que l’on souhaite fournir, afin de garantir la continuité de service (par exemple: une seule plateforme ou base de données cible). En revanche elles ne doivent pas être un frein à de véritables besoins architecturaux, ou à des contraintes de cycle de vie (de déploiement, de livraison) qui ont changé. Plutôt que vouloir à tout prix réduire le problème par des coupes franches, il faut donc tenter de le rationaliser, et trouver des solutions à la gestion de cette multiplicité et de cette spécialisation.

Le bon diagnostique

Utiliser une approche Devops peut aider à traiter ce problème de manière plus constructive: Devops promeut l’augmentation de la qualité des livrables, l’automatisation, la mesure des systèmes et métriques métier, et le partage des pratiques et des outils entre les différentes équipes de Développement, de Test/QA, et d’Infrastructure/Administration système.

Il convient de comprendre que, dans cette approche, tout le monde est responsable du livrable en production, et que dans une cible virtualisée/”conteneurisée” le livrable correspond non à un binaire applicatif accompagné de fichier de configuration et d’une documentation, ni même à un rapport de test d’acceptance utilisateur, mais bien à un ensemble cohérent de serveurs livré dans de multiples environnement qui fournissent un service qui respecte les besoins des utilisateurs finaux.

Cette cohérence du livrable est atteinte lorsque la traçabilité de la production est garantie, et que tous les acteurs sont confiants dans le niveau de qualité du livrable.

La confiance vient avec la reproductibilité.

Pour atteindre la reproductibilité, il faut à la fois:

• automatiser la production des binaires applicatifs et de leur configurations
• automatiser la création des environnements déployés
• automatiser les tests réalisés par les équipes de QA

La traçabilité permet de sécuriser les systèmes dans le temps. Pour atteindre cette traçabilité, il faut faire résider les éléments permettant l’automatisation dans des systèmes versionnés et cohérents. Ce mode de fonctionnement est très connu des équipes de développements et dérive des pratiques agiles (Intégration continue, Inspection continue du code, utilisation de gestionnaires de code source).

Infrastructure as code

Pour des équipes qui s’occupent d’infrastructure, ces pratiques sont moins classiques. Il est historiquement assez fréquent de modifier directement les systèmes cibles, et de n’avoir que le backup pour retrouver l’historique des scripts déployés.

Le chemin pour atteindre la reproductibilité et la traçabilité que l’on souhaite consiste alors:

• d’abord à gérer ses scripts et packages dans un système de gestion de code source (comme Subversion ou Git)
• ensuite ou concurremment à utiliser des outils de gestion de configuration et d’automatisation (Vagrant/Veewee, Puppet, Ansible, Chef, CFEngine, Salt…etc), dont la configuration s’apparente beaucoup à du code testable.
• enfin de permettre à tous les acteurs de la chaîne de collaborer sur cette configuration avec des outils partagés (développeurs, testeurs, administrateurs système)

La reproductibilité commence dès le poste du développeur ou du testeur qui peuvent déjà lancer des environnements très proches de la cible en local par le biais de machines virtuelles (Virtualbox, VMWare Fusion, KVM…) ou de conteneurs (LXC, Docker…).

Ceci permet de tester en amont et avec une boucle de feedback rapide des configurations (Reverse-proxies, cluster…etc) qui ne seraient classiquement disponibles qu’en intégration. L’avantage des conteneurs sur les machines virtuelles dans ce domaine étant la faible surcharge induite sur le système hôte, et le temps gagné à chaque démarrage du système testé.

Une fois la (ou les) application(s) déployée(s), et ces systèmes testés, on peut déposer dans un dépôt commun les environnements (images de machines virtuelles et de conteneurs) mais surtout le code et la configuration qui ont servi à leur création.

C’est cet « ADN » du système cible qui va être géré conjointement avec le code applicatif et les scripts de test (intégration, acceptance, charge, sécurité) afin de permettre la reproductibilité et la traçabilité dans le temps.

Le code de l’application et de l’infrastructure qui l’héberge constitue donc un tout cohérent. On est assez loin du livrable binaire qui est déployé dans une infrastructure immuable et normalisée. La normalisation se fait au niveau des couches sous-jacentes (Hyperviseurs, serveurs de conteneurs, réseaux virtualisés, gestion de configuration).

On peut ainsi à la fois gérer :

• la multiplicité : créer une VM ou un conteneur est quelquechose de reproductible et d’automatisable,.
• la spécialisation : la normalisation ne se faisant plus au même niveau, mettre en place un logiciel ou un autre revient à charger un autre code dans l’infrastructure.

 

L’intervention humaine n’est donc nécessaire que pour les incidents, et la création initiale et la maintenance du code de l’infrastructure.

On gère du code qui permet de créer/adapter les systèmes, on ne gère plus les systèmes directement.

Impact culturel

Il faut bien comprendre qu’un tel changement va se heurter de front avec des habitudes longuement établies, notamment dans le domaine opérationnel:

• l’installation d’un système vue comme une tâche à valeur ajoutée, on gère les serveurs comme des animaux de compagnie et non comme du bétail (“Pet vs Cattle” http://www.slideshare.net/gmccance/cern-data-centre-evolution/17?src=clipshare), c’est à dire comme des éléments précieux qui sont censés persister dans le temps, au-delà même de l’existence des applications qu’ils hébergent.
• le fait d’appliquer des patchs sur des systèmes plutôt que de changer le code qui le décrit et recréer le système depuis son code en cas d’incident.

La clé de l’”Infrastructure as code” est de réaliser un glissement progressif vers une stratégie ou la continuité du service est dans le code de l’infrastructure, plus que dans l’infrastructure elle-même.

Les consommateurs d’offres de cloud public l’ont compris rapidement, et ont souvent plusieurs fournisseurs cibles pour le déploiement de leur infrastructure.

Les services/systèmes sur lesquels l’on va opérer le déploiement du code d’infrastructure étant instables (dans leur raison sociale, leur quantité ou dans le temps) ou la gestion du risque ou de la facturation imposant d’avoir la possibilité de changer de fournisseur, on ressent naturellement le besoin de faire résider la continuité, la reproductibilité et la traçabilité dans quelquechose de différent et d’inédit; dans une description programmatique de l’infrastructure: “l’infrastructure as code”.

Comment commencer demain ?

Commencez par vous poser la question culturelle : mes serveurs sont-ils des animaux de compagnie ou du bétail ? On pourrait cependant utiliser une analogie qui résonne moins sur l’affect : mes serveurs doivent-ils être des oeuvres d’arts (des pièces uniques) ou des commodités ?

Une fois cette question tranchée, et si vous penchez (très probablement) du côté des serveurs en tant que commodités :

1. commencez par tenter de recréer la configuration de vos serveurs en partant d’un outil de gestion de configuration (Puppet, Ansible, Chef…etc). Cette étape est très simple à réaliser, et peut être testée en isolation en local ou dans des sandbox très facilement.
2. impliquez les équipes de développement et de test, et permettez-leur de reproduire en local, ou dans un hyperviseur les environnements, et d’y contribuer, par le biais d’un gestionnaire de code source et de dépôts de binaires partagés
3. créez vos nouveaux systèmes exclusivement sur la base de cette programmation de l’infrastructure, en proscrivant la connexion manuelle aux systèmes cibles, sauf éventuellement en lecture pour l’investigation sur les incidents (on préfèrera ensuite utiliser des systèmes de monitoring pour cela).

Afin de lever progressivement les résistances, et d’éprouver le système, commencer par l’appliquer aux environnements les moins sensibles, comme des sandbox ou environnements de développement.

Cette approche vous apportera progressivement beaucoup plus de souplesse, en permettant par exemple la mise en place à la volée d’environnemens d’intégration ou d’assemblage cohérents.

Le point clé étant de permettre aux différentes parties-prenantes de collaborer sur des outils communs comme un gestionnaire de code source (Git par exemple), un dépôt de binaires (registry Docker par exemple) et d’avoir une visibilité commune des systèmes.

Il est aussi important de choisir des outils que chacun peut utiliser dans une sandbox personnelle (poste local ou machine virtuelle dédiée).

Pour creuser plus loin, notez aussi que la programmation de l’infrastructure évolue jusqu’à inclure la programmation du réseau… à suivre !

Bien entendu, si vous aussi avez fait l’expérience de la programmation de l’infrastructure, n’hésitez pas à venir échanger avec nous sur notre blog !