Et voilà le deuxième jour de la PuppetConf. Une liste d'idées et de choses à tester qui s'allonge encore et encore !
Edit : les vidéos sont disponibles.
La keynote reprend beaucoup de sujets abordés lors de l'USI : une culture forte, faire ses choix en fonction du WHY, etc... Je ne vais pas rentrer dans le détail mais je dois avouer que je ne m'attendais pas à voir ce genre de keynote dans une conférence aussi technique, bonne surprise !
Je retiens une slide, la notion de chaos (technique) ordonné : 
Après une arrivée sur the final countdown, nous avons eu un retour d'expérience très intéressant de la part de Wal-Mart : ils sont aujourd'hui l'un des plus gros déploiement Puppet avec presque 50 000 serveurs et seulement 13 personnes dédiées.
Ils ont fait, comme beaucoup, un POC : ils géraient 1000 noeuds. A ce moment, on est en juillet : il reste 2 mois de "projet" avant d'arriver à la période la plus chargée de l'année pour Wal-Mart : Halloween, Thanksgiving et Noel.
Quelle est l'ambition de l'équipe d'ici là ? Doubler le nombre de noeud : passer à 2000. Le chef, lors de la réunion, fixe 7000 comme objectif. Oui mais 7000, ça ne correspond pas à un pan du SI isolé, pourquoi ne pas viser 30000 serveurs repartis dans les 11000 magasins à travers le monde ? Sacré ambition ! Résultat : ils le font en 6 semaines au lieu de 8.
Aujourd'hui, il s'est écoulé 2 ans depuis le début du POC, ils gèrent quasiment l’intégralité de leur parc Linux et ils vont s'attaquer à leur parc Windows.
Ces 13 personnes n'ont pas eu pour rôle d'automatiser du legacy dans Puppet (le "brownfield land") mais plus largement :
C'est à dire qu'ils ont aussi eu la liberté de ne pas gérer certains cas trop complexes et sans véritable raison d'être.
En résumé, pour réussir un tel déploiement :
Le directeur de l'ingénierie de Puppetlabs nous présente ce qui est dans les tuyaux.
Nous avons eu le droit à une démo d'un prototype de réécriture du moteur de compilation de catalogue en C++ : les perfs sont impressionnantes. Un catalogue compilé en 45 sec avec la stack ruby, passe à un peu plus de 100ms en C++. Alors bien sûr, tout n'a pas encore été implémenté, notamment les appels à des providers et fonctions custom mais on devrait gagner énormément en perf.
Le travail a déjà été fait sur facter où sur windows, à cause des nombreuses couches d'abstraction entre facter et les API systèmes, la collecte prenait une éternité.
Un titre un peu provocateur mais dont le propos peut se résumer en une phrase : il faut tester en dev mais le juge de paix, ça sera la production parce que la plateforme de dev ne ressemble jamais à la production. Le bug de Google Docs d'hier non détecté en dev en est un bel exemple.
Il a également parlé de comment tester en production sans casser la production : canary severs, feature flipping dans le code Puppet avec l'ancien code dans la bloc else.
Une slide qui résume la todo list d'un ops :
Au delà du test avec 2-3 modules, on se retrouve vite à devoir gérer le cycle de vie des 20-50-100 modules de la forge qu'on utilise dans son déploiement. L'idée du talk est de nous présenter les outils pour gérer ça en conservant sa santé mentale.
On parle de pourquoi les submodules git ne sont pas vraiment adaptés, de pourquoi librarian-puppet génère un Puppetfile.lock comme bundler et un Gemfile.lock et enfin de pourquoi r10k est aujourd'hui le meilleur outil.
Une présentation d'un ancien de Puppetlabs, désormais chez Mesosphere. Après avoir expliqué le concept de la stack, nous avons surtout eu le droit à une présentation des modules utilisés et à quel point il devient simple de gérer un cluster de ce type avec Puppet. Le code de sa démo est disponible ici.
Et le meilleur pour la fin, c'est pour moi la meilleure présentation de la journée. Elle se concentre sur les erreurs qu'on veut faire "parce que ça a l'air trop compliqué" quand on débute. Une checklist très efficace !
Quelques slides pour vous donner envie de regarder la vidéo dès qu'elle sera publiée :
Je retiens 4 choses :