Deuxième jour de la PuppetConf 2015

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.

Keynote d’Uber sur l’environnement de travail

 

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é :
uber_2

 

Keynote sur le déploiement de Puppet à grande échelle chez Wal-Mart

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.

 

wal_5

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 :

wal_1

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 :

wal_4

 

Keynote de Puppet sur les évolutions recentes et à venir

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é.

Testing in production

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.

prod_1

prod_2

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 :

prod_7

Comment travailler avec les modules de la communauté?

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.

Mesos, Docker, Chronos gerés par Puppet

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.

mesos_1

It sounded good on paper…

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 :

trench_1

trench_2

trench_9

trench_16

 

 En conclusion

Je retiens 4 choses :

  • Puppet veut dépasser le simple rôle de gestion de configuration de serveurs linux pour couvrir l’Infra As Code dans son ensemble : équipements réseau, appliances, provisioning cloud, topologie applicative, windows, etc
  • Les REX de très gros déploiements (>10 000 noeuds) sont désormais très courant : ING, Wal-Mart, Wells-Fargo pour ceux que j’ai découvert ici
  • La notion de dette technique et de simplification est un vrai enjeu
  • Le dev se professionnalise partout : il n’y a même plus de talk sur les tests mais tout le monde en fait et en parle

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha