Tag Archives: devops

Gérer vos installations comme un Chef !

BIP BIP, message urgent: le serveur 12 est tombé. Nous sommes lundi il est 6H du matin, les utilisateurs vont débarquer en masse dès 8H, et avec un serveur d’appli out on ne va jamais tenir la charge… Heureusement, la procédure d’installation du serveur est à jour… enfin devrait l’être, ça va pas prendre plus de .. oulà 3H pour refaire l’installation.

Vous aussi vos procédures d’installation sont constituées de:

  • scripts shell par forcément à jour
  • une documentation pas synchro avec les scripts shell et encore moins à jour
  • quelques incantations magiques transmises de génération en génération selon la tradition orale
  • …
Après consultation, le médecin est formel, ce sont les symptomes d’une crise de “configuration management”. A traiter d’urgent avec du Chef ou du Puppet.

Chef ou Puppet

Vaste débat, j’ai commencé par puppet, je ne vous raconte pas la galère juste pour réussir à lui faire installer le jdk d’oracle… J’ai eu un peu moins de mal pour faire la même chose avec Chef, j’ai donc choisi ce dernier. L’important n’est pas lequel mais bien d’utiliser un outil de ce genre pour gérer la config des machines.
Deux concepts sont à retenir:
  • Infrastructure As Code => la configuration des serveurs doit se gérer comme le code source d’une application.
  • Documentation executable => Pas de désynchronization entre la doc, le code et ce qui est réellement installé.

Chef pour gérer son poste de dev

Bon évidemment c’est un peu le marteau-pilon pour caser une noix mais c’est un bon moyen de se former. Pour démarrer j’ai voulu suivre la doc officielle, Fast Start Guide avec un compte chef hosted ERREUR. Ce n’est pas que cette doc soit mauvaise mais elle vient avec toute la complexité d’une configuration chef de type client/server. Pour démarrer mieux vaut partir sur chef-solo, avant de passer aux choses sérieuses avec chef-server. Voici un très bon tuto: Chef Solo tutorial: Managing a single server with Chef. La suite de cet article s’en inspire fortement.

Prérequis:

  • debian ou ubuntu, j’ai eu des galères en essayant avec une distrib plus exotique.
  • git, on fait de l’Infrastructure As Code donc gestion de code source…
git clone git://github.com/toutantic/chefrepo.git
git checkout step1

Voici le contenu de ce repo:

??? README.md # ce fichier
??? install.sh # script pour installer chef
??? deploy.sh # script pour déployer vers une machine distante
??? run.sh # script pour démarrer chef-solo
??? config
?   ??? attributes.json # Liste des attributs à utiliser (liste des recettes et paramétres)
?   ??? solo.rb # Configuration de chef-solo 
??? cookbooks
?   ??? toutantic
?       ??? recipes
?       ? ??? default.rb # recette par défault

Le script run.sh lance chef avec la commnde chef-solo -c config/solo.rb -j config/attributes.json

  • config/solo.rb permet de configurer chef-solo en particulier de lui dire où trouver les cookbook
  • config/attributes.json contient les attributs à utiliser en particulier la liste des recettes à appliquer.
3 manières d’utiliser chef:
  • Créer une recette simple avec les ressources disponibles
  • Réutiliser une recette existante
  • Créer un nouveau cookbook

Exemple de recette simple

cookbooks/toutantic/recipes/default.rb contient la description de ce que l’on veut faire sur le poste. J’y ais mis quelques exemple des “resources” que l’on peut décrire en standard avec chef.

Exemple de réutilisation d’une recette

C’est l’un des grands intérêts de chef, c’est un grand livre de cuisine, on trouve en particulier les recettes de:
Je veux donc installer java, vous allez me dire apt-get install openjdk-7-jdk… C’est pas faux. Maintenant si ce n’est pas l’openjdk qu’il vous faut mais celui d’Oracle, c’est déjà moins simple.

Installation d’un jdk avec chef:

git checkout step2_java
  • J’ai légérement modifié le fichier run.sh pour pouvoir passer le nom d’un fichier json en paramétre.
  • J’ai recopié le cookbook java proposé par opscode, il propose deux manières d’installer java:
    • En utilisant directement ce cookbook java, on le paramétre dans le fichier d’attribut json
    • En utilisant le LWRP java_ark qui est définit dans ce cookbook, c’est une nouvelle ressource qu’on peut utiliser et configurer depuis une autre recette
  • J’ai rajouté trois fichiers json et une recette

 Création de son propre cookbook

Il est temps de passer aux choses sérieuses! Tout d’abord un petit lien How to write a good Chef cookbook. Maintenant que java est installé on peut passer à Tomcat, là pour le coup je n’ai jamais été satisfait de apt-get install tomcat7…

git checkout step3_tomcat

Voici mon cookbook pour installer tomcat à ma sauce :

??? tomcat
?   ??? attributes # Tout ce qui est paramétrable
?   ?   ??? default.rb
?   ??? files # Contient les fichiers à copier tel quel
?   ?   ??? default
?   ?     ??? manager.xml
?   ?     ??? tomcat-users.xml
?   ??? recipes
?   ?   ??? default.rb
?   ??? templates # Contient les fichiers paramétrables
?        ??? default
?         ??? tomcat_conf.erb
?         ??? tomcat_debian.erb
Au final, la ressource qui s’est avéré indispensable pour installer tomcat comme je le souhaitais a été celle nommée …”bash” !

Conclusion

Mon sentiment à propos de chef est mitigé. Je suis plus convaincu par les bonnes pratiques que Chef recommande que par l’implémentation elle-même. Chaque avantage que j’ai trouvé dans Chef cache des inconvénients.

Communauté de partage des bonnes recettes, sans doute le point le plus intéressant, mais les recettes proposées par opscode se veulent très générique (multi plateforme) et sont donc trop complexes.

Documentation exécutable, pour celà le DSL Chef pour écrire les recettes est déclaratif, c’est plus lisible, mais aussi beaucoup moins concis  que l’équivalent en bash. Et bien sûr contraignant, on fini par écrire du Ruby ou lancer une commande shell pour sortir du carcan.

Chef Server, c’est sans doute avec cette brique que Chef prend tout son sens. Mais la mise en oeuvre est complexe. A tel point que chez fasterize ils ont trouvé plus simple d’intégrer capistrano avec chef-solo à la place…

La grosse déception étant que l’on reste très loin de pouvoir se passer de connaitre le shell…

Github, Cloudbees, Feature Flags

Quand les enfants ne sont pas là le geek code 😉

Mettre en oeuvre un processus d’intégration continue peut se faire rapidement, avoir une suite de test unitaire couvrant de manière satisfaisante son code est une autre histoire… Particulièrement sur un “code  legacy” (qui a été écrit sans test unitaire) ,  trop souvent les bugs sont découvert en production par les utilisateurs finaux.  Il faut alors revenir en arrière, reproduire et corriger le bug dans un environnement et re-livrer plus tard, sans parler d’une éventuelle reprise des données qui auraient été corrompues. Oui il y a du vécu.

Une technique pour réduire les effets néfastes d’un bug en production est de déployer progressivement à des populations restreintes les nouveautés. Pour cela il faut séparer la livraison du code de l’activation des fonctionnalités qu’il contient.

Un simple if/else peut suffire, on parle de feature flags chez Flikr.

if (newStuffIsOn) {
	doIt
} else {
	doNot
}
Voilà donc ce que j’ai codé ce week-end… Bon un peu plus en fait. Car il faut un moyen propre et élégant de gérer, d’activer et de désactiver ces flags en production.

Voici donc Feature Flags

L’idée est de gérer les flags dans un enum:
public enum Flags implements FeatureFlags {
    ONE("First Feature Flag"),
    TWO("Second Feature Flag", FlagState.UP),
    THREE("Third Feature Flag");
}
if (ONE.isUp()) {
	doIt
} else {
	doNot
}
Feature Flags génére dynamiquement à partir de l’enum une page html pour activer désactiver ces flags en live, mais aussi une interface RESTful pour les manipuler comme on souhaite.

RESTful

GET http://yourhost.net/flags/ONE pour connaitre l'état
POST http://yourhost.net/flags/ONE pour inverser l'état
PUT http://yourhost.net/flags/ONE avec UP ou DOWN en contenu pour forcer l'état d'un flag
Rien de fantastique que ce soit fonctionnellement ou au niveau du code mais il s’agissait aussi d’un pretexte pour me mettre à git et github

GitHub

Quelle claque. J’ai mis du temps à comprendre pourquoi Linus disait que svn ne marchait pas par conception, après tout ça a marché pour moi pendant des années. Git est clairement le bon concept. La preuve: github, il n’existera jamais de svnhub, avec github nous sommes tous à un click de pouvoir contribuer à des milliers de projets open source. D’ici quelques années github aura produit un impact majeur sur la croissance et la vitalité de l’open source. En fait c’est déjà le cas, mais j’ai la conviction que l’on a encore rien vu. Un peu comme les moteurs de blogs ont déclenché la vague web 2.0 du web participatif. On peut parler d’open source 2.0.

Cloudbees

Deuxième claque. Le projet Feature Flags contient une webapp de démo, le plus simple pour montrer ce que fait Feature Flags est encore une démo (vous allez pouvoir découvrir mes talents de designer web, please fork it ! du html là aussi). Mais héberger un war java sur Internet a toujours été un problème. Les différents clouds publiques apportent des solutions. Avec cloudbees déployer du code java est presque aussi simple qu’uploader une appli php. Il s’est écoulé une petite 1/2heure entre le moment où j’ai décidé de m’inscrire à Cloudbees et le moment où mon application était live, le plus long a été de lire un peu la doc. Petite déception, il n’est pas possible n’était pas possible hier de déployer directement un war généré dans le jenkins de DEV@cloud vers le tomcat RUN@cloud.

Age d’or du développeur

Ajouter à ça le mobile (android), html 5, l’adoption des méthodes agiles, le développement vit un nouvel age d’or.