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
- …
Chef ou Puppet
- 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.
- Créer une recette simple avec les ressources disponibles
- Réutiliser une recette existante
- Créer un nouveau cookbook
Exemple de recette simple
Exemple de réutilisation d’une recette
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
- config/javaopenjdk.json : Par défaut le cookbook java installe l’openjdk 6 (voir les paramétres par défaut dans cookbooks/java/attributes/default.rb)
- config/javaoracle.json J’ai surchagé certains paramétres pour installer le jdk 7 d’oracle. Il faut accepter une licence pour télécharger le jdk d’Oracle, on ne peut pas le faire automatiquement, j’ai donc copié le binaire sur dropbox (attention c’est la version 64bits)
- config/javaRessource.json le cookbook java définit une nouvelle ressource java_ark qui peut-être utilisé dans d’autres recettes pour installer java: j’ai donc créer ma recette pour installer java: cookbooks/toutantic/recipes/java.rb et la lance avec le fichier config/javaRessource.json
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
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…
Dis Aurélien, ce sera pas plus simple de faire un rpm? Ou un deb ? Finalement.
C’est possible 😉
Mais le .deb ne fait pas tout, en particulier l’orchestration des déploiements, la centralisation de la conf de tous les serveurs, …
@francois : le truc, c’est que dans beaucoup de cas, les packages standard répondent au besoin une fois configurés, et beaucoup d’entre eux acceptent de la configuration modulaire (par exemple dans des répertoires du genre /etc/cron.d/, /etc/apache2/sites-available) et cela s’applique aussi à leurs modules. Dans ces cas-là, refaire un package .deb ou .rpm, qu’il faudra maintenir à jour pour les corrections de sécurité devient vraiment lourd.