Nous ne vous proposons pas une version bovine à poils longs de l’Himalaya (yack) du roman “Des souris et des hommes” (Of Mice and Men en version originale) de l’écrivain américain John Steinbeck publié en 1937 mais nous ne pouvions résister au jeu de mot avec l’acronyme IaC !

Quittons plus sérieusement les hauts plateaux de l’Asie centrale pour rejoindre le monde de l’infrastructure informatique et ses principaux acteurs, les Ops.

 

Infrastructure as Code

L’Infrastructure as Code (IaC) permet d’automatiser la gestion, l’approvisionnement et la mise à l’échelle de l’infrastructure (réseaux, machines virtuelles, équilibreurs de charge, espaces de stockage, etc.) dans un modèle déclaratif.

Mise à l’échelle

La mise à l’échelle est la capacité d’un dispositif informatique (matériel ou logiciel) à s’adapter aux besoins de performance d’un système.

Il existe deux types de mise à l’échelle :

  • Mise à l’échelle verticale (ou scalabilité verticale, scale-up et scale-down),
  • Mise à l’échelle horizontale (ou scalabilité horizontale, scale-out et scale-in).

La mise à l’échelle verticale consiste à augmenter (scale-up) ou réduire (scale-down) la puissance de calcul (CPU, RAM) selon les besoins.

La mise à l’échelle horizontale consiste à ajouter (scale-out) ou supprimer (scale-in) de nouveaux serveurs réalisant le même type de tâche.

Modèle déclaratif

Un fichier de définition déclaratif peut définir les exigences d’un composant serveur, sa version spécifique par exemple, mais ne spécifie pas le processus d’installation et de configuration de celui-ci. En d’autres termes, un fichier de définition spécifie ce qu’un environnement requiert (le quoi) et pas nécessairement la procédure (le comment).

Ce principe déclaratif permet de réduire la dette technique de la maintenance du code impératif (scripts de déploiements qui peuvent s’accumuler).

Idempotence

Dans les domaines mathématiques, l’idempotence signifie qu’une opération a le même effet, qu’on l’applique une ou plusieurs fois.

En tant que principe d’IaC, l’idempotence est la propriété qu’une commande de déploiement définit toujours un environnement cible dans une même configuration, quel que soit l’état de démarrage de cet environnement.

L’idempotence est obtenue en configurant automatiquement un environnement cible existant ou en ignorant la cible existante et en recréant un nouvel environnement.

S’il est nécessaire d’apporter des modifications à un environnement, les Ops modifient la source, i.e. la description de l’environnement et la version du modèle de configuration, et non la cible, i.e. l’environnement.

 

Modèle Pet vs Cattle

Le modèle de service opérationnel Pet vs Cattle est l’un des concepts fondamentaux du DevOps.

Ce concept a été introduit par Bill Baker, Distinguished Engineer et General Manager de l’équipe BI du produit SQL Server chez Microsoft de 1996 à 2008, lors d’une présentation de la mise à l’échelle de SQL Server 2012.

Il a ensuite été popularisé par Gavin McCance en 2012 dans la présentation de l’évolution du centre de données du CERN, Organisation européenne pour la recherche nucléaire : CERN Data Centre Evolution.

Pet

Dans le modèle Pet, chaque serveur est considéré comme un animal de compagnie, identifié et nommé affectueusement. Un serveur est unique, élevé avec amour et soigné dès qu’il tombe malade.

Ce type de serveur grandit via une mise à l’échelle verticale et son indisponibilité se remarque immédiatement.

Cattle

Dans le modèle de service Cattle (bétail en français), les serveurs sont identifiés par des numéros, de la même manière que les bovins d’un troupeau reçoivent des boucles d’identification numérotées et étiquetées à leurs oreilles.

Chaque serveur est presque identique l’un à l’autre et quand l’un tombe malade, il est froidement remplacé par un autre.

La mise à l’échelle de ce type de serveur est horizontale, en créant d’autres serveurs, ainsi l’indisponibilité de l’un des serveurs n’est pas remarquable.

Une stratégie de PRA (Plan de Reprise d’Activité) peut ainsi être validée en supprimant et reconstruisant des machines virtuelles à la volée.

De même, une stratégie de déploiement bleu/vert (Blue Green Deployment) ou A/B, sujet abordé lors du partage de notre vision du (Dev)NoOps, peut facilement être mise en œuvre.

Pour rappel, cette stratégie permet de déployer une infrastructure destinée à héberger une nouvelle version d’une application, déployer cette version applicative, rediriger le trafic utilisateur sur le nouvel environnement après validation et pour finir supprimer l’ancienne infrastructure.

L’automatisation et l’Infrastructure as Code deviennent alors les outils indispensables de l’approche Cattle :

  • Les tâches manuelles, répétitives et fastidieuses se réduisent drastiquement,
  • Les erreurs résultant de configurations hétérogènes disparaissent.

Inversement, une erreur introduite dans un script déclaratif de changement de configuration d’une machine peut être généralisée à un ensemble de machines du même type !

Quelles sont donc les bonnes pratiques à mettre en place pour éviter cet écueil ?

 

Bonnes pratiques

Les bonnes pratiques applicables aux développeurs d’applications dans le cadre de l’Intégration Continue (Continuous Integration, CI) deviennent également celles des Ops :

  • Des revues de code sont mises en place afin d’améliorer celui-ci,
  • Les scripts sont stockés et versionnés dans un outil de contrôle de versions (GitHub, BitBucket, etc.),
  • Linting du code : pratique visant à vérifier la syntaxe du code et sa conformité à des standards d’écriture partagés via des outils d’analyse de code,
  • Des tests automatiques sont exécutés afin de détecter d’éventuelles régressions.

Les outils utilisés et pratiques mises en œuvre par les Ops pour réaliser leur tâches les affilient au mouvement du Software craftsmanship, ou artisanat du logiciel, mouvement qui résonne en nous et renvoie à l’identité de Nuageo, L’Atelier du Numérique Responsable.

Le Software craftsmanship prône le côté artisanal du développement logiciel : il ne suffit pas qu’un logiciel soit fonctionnel mais il faut qu’il soit bien conçu !

Garantir la fiabilité et la maintenabilité des applications par des professionnels aptes à concevoir des logiciels dans le respect d’indicateurs de qualité logicielle est l’idée principale de ce mouvement.

En 2008, Robert C. Martin (aussi connu sous le nom d’Uncle Bob), l’un des signataires originels du Manifeste pour le développement Agile de logiciels, souhaitait qu’un des principes de l’artisanat du logiciel, l’artisanat plus que l’exécution (craftsmanship over execution en version originale), soit inclus dans le manifeste Agile.

Cette valeur n’ayant pas été intégrée, des passionnés aspirants artisans du logiciel ont défini un ensemble de principes lors d’une rencontre à Libertyville dans l’Illinois et ont publié en 2009 le Manifeste pour l’Artisanat Logiciel.

Les deux approches ne sont pas forcément incompatibles.

Sandro Mancuso, fondateur de la London Software Craftsmanship Community et auteur du livre The Software Craftsman: Professionalism, Pragmatism, Pride, sépare agilité (capacité à s’adapter rapidement aux changements imprévus et aux nouvelles tendances) et artisanat logiciel en posant les deux questions suivantes :

  • Est-ce qu’on code le bon produit ?
  • Est-ce que le produit est bien codé ?

 

L’écosystème

Les premiers outils open source de gestion de configuration de serveurs sont apparus dès la seconde moitié des années 2000, notamment avec Puppet (2005) et Chef (2009). 

Le modèle de service Cloud IaaS (Infrastructure as a Service) et la virtualisation de toute l’infrastructure (réseaux, ressources de calcul, espaces de stockage) ont ensuite donné naissance à des outils d’orchestration comme Ansible (2012) et Terraform (2014).

Ces deux derniers outils devenus populaires permettent notamment d’automatiser le déploiement de l’infrastructure des principaux fournisseurs de services de Cloud Computing et leurs services managés d’orchestration de conteneurs Docker sous Kubernetes :

  • Amazon Web Services (AWS) et Amazon Elastic Kubernetes Service (EKS),
  • Microsoft Azure et Azure Kubernetes Service (AKS),
  • Google Cloud Platform (GCP) et Google Kubernetes Engine (GKE),
  • Oracle Cloud Infrastructure (OCI, Terraform uniquement),
  • OpenStack (Ansible uniquement).

 

Conclusion

L’outil de déploiement devient le nouvel animal de compagnie des Ops, celui dont ils prennent le plus grand soin car il leur permet d’opérer et superviser 24h sur 24h une plateforme de production.

L’Infrastructure as Code remet en question l’objet de l’attention des Ops mais en aucun cas la valeur de leur métier.

Les Ops sont les nouveaux artisans appréciant le goût du travail bien fait, au même titre que les Dev et les Architectes qui les accompagnent !

 

Si vous souhaitez découvrir de nouveaux articles, cliquez ici

On vous invite aussi à nous suivre sur Linkedin et Twitter !