Config Management Camp 2020 : Notre retour

Introduction

Avez-vous déjà entendu parlé du Config Management Camp ? (CfgMgmtCamp pour les intimes). Cette année, l’événement se déroulait les 3, 4 et 5 février.

C’est une conférence sur 3 jours qui balaye des sujets techniques autour de la gestion de configuration. On y retrouve chaque année les incontournables Ansible et Terraform, mais pas que !!

Les 2 premières journées sont dédiées aux conférences plénières sur des sujets techniques. Pas de publicité, ni de promotion graveleuse en séance (au risque pour l’intervenant de n’avoir personne à sa présentation). Quelques moments bien définis dans la journée permettent aux sociétés à promouvoir leurs produits.

Le site de l’événement est disponible ici.

Localisation de l’événement

L’événement se déroule à Gand, en Belgique, sur le campus de l’Université HoGent.

Les organisateurs réquisitionnent le bâtiment qui comporte l’accueil (batiment B) et utilisent les salles de conférence/spectacle et les salles de classe pour dispenser les sessions.

Conférences

Cloud native configuration management : état de l’art

Cette conférence très inspirante fait l’objet d’un article entièrement dédié. Si vous souhaitez de plus amples informations sur cette conférence, vous pouvez vous rendre directement sur l’article.

La première conférence de la journée était animée par Eric Sorenson, développeur chez Puppet, qui nous présente sa vision du Config Management en 2020 et au delà.

Eric a présenté le projet sur lequel il travaille actuellement : Project Nebula ; qui vise à simplifier le déploiement des applications sur les cloud providers.

L’animateur a présenté sa vision de la gestion de la configuration et des environnements. Il a exposé plusieurs théories simples qui visent à identifier et qualifier la maturité du contexte et des outils de gestion de configuration.

Les concepts mis en avant

The 12-factors app

Courbe de complexité de la configuration

La courbe de la complexité permet de positionner un outil de configuration sur une échelle basique afin d’en faire ressortie les axes suivants :

• Niveau des utilisateurs qui opèrent ;
• Niveau d’abstraction souhaité ;
• Flexibilité dans l’outil et facilité à tordre le modèle de base ;
• Facilité à transposer la description vers l’action réalisée.

Taxonomie des outils de configuration cloud natifs

La courbe sur la taxonomie permet de distinguer le degré de complexité de l’outil vis-à-vis de son utilisation.

Ainsi, plus les outils apportent une couche d’abstraction, plus ces outils introduisent des nouveaux objets et concepts, mais plus ils sont complexes à prendre en main ou complexe à utiliser (face à des systèmes usuels).

Kubernetes Operator Controller

Cette conférence très intéressante fait l’objet d’un article entièrement dédié. Si vous souhaitez de plus amples informations sur cette conférence, vous pouvez vous rendre directement sur l’article.

Nicolas Frankel, développeur et architecte chez Hazelcast, nous a présenté comment interférer dans la vie du cluster Kubernetes à l’aide des Controllers (et non des Operators !).

Quelle est la différence entre un Controller un Operator ?

Nicolas nous rappelle la différence entre un Controller et un Operator. Il marque ainsi le pas entre 2 objets à la base similaire.

Globalement, un controller vise à interférer avec le cluster tandis qu’un Operator vise à être dédié aux applications en étant accessible en interne, sous forme d’une URL créée à l’aide des CRD (Custom Resource Definition).

Choix du langage

Le cluster est basique accessible, via son composant API Server, et la communication se fait sur base de JSON et d’API REST. Il devient facile d’interfacer nos propres composants dessus. Tous les langages sont en mesures de répondre à ce besoin.

Concrètement, le choix du langage ne dépend que de vous. Libre à vous de vous d’utiliser un langage connu ou d’en découvrir un nouveau.

Démonstration

Nicolas a procédé à une démonstration, en Java, sur base de son historique Git pour reprendre chaque étape de la construction de son Controller. Il nous a confrontés aux problèmes qu’il a rencontré et leurs résolutions.

Le but de la démonstration est de créer un Pod Hazelcast à chaque nouveau Pod généré sur le cluster.

L’avancées dans les étapes de construction du Controller, l’orateur nous fait confronter aux problèmes qu’il a rencontré, entre manque de droits, permissions non accordées, démarrage hazardeux des conteneurs, nous avons eu droit à toute la panoplie d’erreur envisageables.

Pour faciliter les développement, l’animateur a introduit l’outil Fabrik8 afin de changer le mode d’implémentation de son Controller.

Petite subtilité de fin, la cible est d’interférer avec un conteneur et non un sidecar. Il a fallu adapté le code pour déclencher les actions uniquement sur création d’un conteneur.

Le Graal

Pour terminer la conférence, Nicolas Frankel a introduit la notion de compilation machine avec GraalVM, boite à outil qui permet de compiler le code au plus prêt du noyau système. Cette pratique écrit le code en langage machine et boost drastiquement les performance de l’application compilée.

Les indicateurs de qualité/performance de GraalVM distingués par Nicolas sont les suivants :

• Temps de démarrage : plus rapide
• Langage machine du binaire : plus complexe
• Taille du binaire : plus petit
• Portabilité du binaire : portée par l’architecture du serveur (Linux x86_64, OS X, etc…)

Une conférence très intéressante qui couvre pas mal de sujets du moment dont Kubernetes et ses Controllers, GraalVM.

Le concurrent de Terraform

La session était animée par Paul Stack, développeur chez Pulumi, face à une (grande) salle quasi comble. Bien que parti pris pour la solution, il nous a assuré que toutes les fonctionnalités qu’il allait citer n’étaient pas payantes. En effet, la conférence ne mettait pas la marque Pulumi en avant mais bien la puissance de l’outil (différence subtile mais notable).

Démonstration

Paul a fait son show en commençant par faire participer l’assemblée au sujet de pratiques autour du cloud, et ainsi préparer son propre terrain de jeu. Il a continué par une démo Live, qu’il a fait tourner tout au long de son discours et qu’il a agrémenté d’explications.

Outre la promotion du produit, la partie la plus intéressante est la mise en avant de fonctionnalité mises à disposition par la solution. Bien que Pulumi sache déployer des infrastructures complètes et complexes sur les cloud providers, tout est écrit en Typescript pour permettre un on-boarding facile sur le langage et surtout récupérer la puissance de la programmation classique. Les nouveaux DSL portent l’inconvénient d’apprendre un nouveau langage et d’être limité dans les fonctionnalités : par exemple la gestion des boucles (loop-for) dans Terraform v0.11.

Le watcher de manifests

Une fonctionnalité très intéressante et attendue est la notion de watch sur le code écrit, où l’infrastructure est déployée après chaque ligne de code (ajout et suppression). On peut ainsi écrire une infrastructure et la voir apparaître dans la foulée sur le cloud provider. Tellement incroyable et pratique pour les longues phases d’écritures des manifestes. Terminées les phases où on écrit tout d’un coup et applique les changement uniquement à la fin.

Le requêteur universel

Une autre fonctionnalité est la mise en place d’un wrapper de requêtes pour base de données. Peu importe la nature, le type de la base et sa version, le requêteur permet d’écriture d’une manière et d’appliquer a requete au travers du requêteur. C’est le middleware de Pulumi qui se charge de transcrire la requête dans le bon langage et format.
Particulièrement pratique pour tester une requête ou injecter des données en base sans se soucier de la syntaxe finale.

Stack store

La gestion des stack Pulumi au travers de leur store n’est pas nouveau, la démonstration de Paul a permet de mettre un point d’honneur sur son utilisation. Chaque stack possède un identifiant unique qui permet de faire appel à la notion de dépendances ou de partage. On peut ainsi “forker” une stack externe et l’adapter pour son projet.

Guides

Pulumi fournit également un panel d’exemples d’infrastructures classiques déjà codées. Ces guides permettent de faciliter le on-boarding dans l’écriture des manifestes et de découvrir les bonnes pratiques d’écriture poussées par la société.

Infrastructure testing : the road to reliability

Provisioning d’une infrastructure

Concepts

La prise de hauteur sur la partie tests nous amène à visualiser le cycle de développement d’une application :

Développement --> Vérification --> Implémentation --> Application --> Tests

Ce schéma, en réalité très classique et intuitif, permet de poser ce que tout le monde fait dans le monde du développement.

Maintenant, en appliquant ce modèle à l’infrastructure, on fait émerger plusieurs niveaux de tests :

• Sur le code de déploiement
• Sur l’infrastructure déployée
• En fonction des environnements

On obtient un schéma similaire à celui-ci :

Développement --> Tests du code brut --> Implémentation --> Tests du codé généré --> Application --> Tests de l'infrastructure

Où on considère les éléments suivants :

• Tests du code brut : assure la bonne syntaxe, la gestion des dépendances, la robustesse et la sécurité (implémentation et bonnes pratiques) des actions réalisées ;
• Tests du code généré : (valable pour les outils de génération) assure la pertinence, la sécurité (valeurs appliquées) des objets générés ;
• Tests de l’infrastructure : assure la bonne cohérence entre le code écrit/généré et l’infrastructure déployée.

Positionnement des tests

Les développeurs qui connaissent les tests n’ont pas l’habitude de cette réflexion des tests portée par l’infrastructure. On connait le schéma classique des développeurs présentés par le schéma qui suit :

En prenant de la hauteur face à ses deux couvertures de tests, développeur et infrastructure, on peut mettre en place une abstraction de ces tests et voir le lien entre tous.

Abstraction

On distingue 3 types de tests, chacun comporte ses forces et faiblesses : hardware, API Cloud, Code.

• Hardware : les tests sont réalisés à même le serveur
  • Positifs :
    • Tests au plus près du serveur ;
    • Intégrés à l’environnement ;
    • Flux réseaux entre les équipements.
  • Contraintes :
    • Tests intrusifs ;
    • Contraignants à mettre en place ;
    • Lourds à maintenir.
• API Cloud :
  • Positifs :
    • Endpoint du cloud provider.
  • Contraintes :
    • Maintenabilité suite aux MàJ ;
    • Mise à jour régulièrement ;
    • Douter de l’API du cloud provider.
• Code :
  • Positifs :
    • Tester le code implémenté ;
    • Lancé en local ;
    • Gestion de la syntaxe ;
    • Gestion des dépendances.
  • Contraintes :
    • Testé en local ;
    • Test du code, pas de l’infrastructure déployée.

Tester son code et son modèle

L’intervenant a énoncé quelques technologies et usecases pour tester son code sur les logiciels suivants : Terraform et Pulumi.

Terraform

De part sa nature complexe, Terraform emploie son propre DSL : le HCL. Il est difficile de tester le code généré avec le langage mis à disposition par l’outil.

Une société met à disposition un outil, Terratest, qui permet de visualiser et valider la configuration générée.

Terratest est disponible ici : https://github.com/gruntwork-io/terratest, et est maintenu par Gruntwork.

Les participants de la session ont également évoqué Kitchen Terraform pour tester les script TF.

Pulumi

Pulumi est écrit en Typescript, il est donc beaucoup plus facile de tester le code écrit grâce aux librairies mises à disposition par la communauté Javascript.

Constantin avait mis en place, pour la démo, une couverture de tests qui vérifie la teneur et la permissivité des Security Groups en place.
Mocha est l’un des outils qui permet réaliser ces tests.

Using Ansible Vault

Pour cette session dédiée à Ansible, Amit Upadhye a pris la parole en tant que développeur chez RedHat et nous venait tout droit d’Inde.

Ansible est l’outil par excellence d’automatisation pour l’installation et les configurations des infrastructures en masse. La grande question se pose sur le stockage des données sensibles liées à la configuration des applications, telles que les clés SSH, les mots de passe, les certificats, etc… qui ne doivent, en aucun cas, être en clair et accessible par quiconque.

La parade est de chiffrer ces données à l’aide d’outils. Il en existe beaucoup sur le marché, dont un pleinement intégré (car natif) dans Ansible : Ansible Vault.

Ansible Vault permet de verrouiller un fichier entier ou une simple valeur sur base d’un algorithme de chiffrement AES256.

La documentation est disponible sur le site de Ansible : Ansible Vault.

Conclusion

Les conférences étaient en partie propulsées et animées par les créateurs eux-mêmes, telles que Pulumi, Ansible et Foreman. Les autres intervenants partageaient quant eux les retours, issus de leurs propres expériences, sur l’utilisation des outils présentés.

L’agenda de l’événement était bien pensé et permettait de choisir les conférences organisée par salle et par thème : une salle portait généralement une technologie sur la journée.
Le rythme des conférences n’est pas trop soutenu, laissant du répit aux participants avec des pauses régulières.

Notre ressenti

Les conférences proposées par l’organisation sont de qualité, les intervenants sont souvent des pointures qui connaissent leur sujet sur le bout des doigts. Rien à dire sur le contenu.

La seule remarque se trouve sur la forme, où le catering, les corbeilles à fruits et rafraîchissements, mis à disposition est très vite dévalisé. On se retrouve rapidement sans boisson fraîche ou de quoi grignoter. Il faut nécessairement passer par le distributeur de boissons pour réconcilier son estomac.

On renouvelle l’expérience ?

Sans hésiter, l’an prochain nous y retournerons !

Nous participerons également au Fosdem où des pointures similaires sont présentes, mais en plus grand nombre.