“When I give a talk, I do stuff that I’m interacting with on-the-fly. Because that is what the computer is for. People who don’t do that either don’t understand that or don’t respect it.”
Category Archives: architecture
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
- 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 |
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…
Innovation As A Service
Je suis un fan des travaux de Simon Wardley à propos du cycle d’évolution des activités: d’une innovation émergent des projets spécifiques qui peuvent devenir des “produits” eux mêmes commodifiés par des services ou des projets open source. Ces commodités pouvant servir de base à de nouvelles innovations auparavant inimaginables… La boucle est bouclée.
Se servir de la technologie comme levier pour innover est l’une des choses qui me motive chaque jour dans mon métier. Nous (les informaticiens) vivons une époque formidable, j’ai aujourd’hui la chance de pouvoir pousser tout ça un peu plus loin à un nouveau poste…
Je rejoins le Groupe Sfeir en tant que Directeur Technique.
Des tweets et des plus n°14 – Agile subway map
A Web Developers’ View of Play Framework 2.0: With Play, the Back button just works [...] Play doesn’t fight HTTP or the browser [...] As a Java EE developer, PHP and Rails developers have been laughing at us for years
La pratique “Définition de prêt pour une story”: Une story non prête n’est pas acceptée dans un sprint qui commence
On Naming: The challenge is that the coder is holding two conversations at once, one with the compiler/interpreter and one with the future maintainer
It’s About The Hashbangs: Directly addressable content is what makes web apps better than desktop apps. It’s certainly not the UIs.
L’architecte
La tête dans les nuages
Les mains dans le cambouis
Les pieds sur la prod
La tête dans les nuages
Pas parce qu’il s’intéresse au cloud, mais parce qu’il doit prendre de la hauteur et du recul pour analyser, synthétiser et savoir restituer des vues adaptés à chacun des acteurs d’un projet. Il est le garant d’une vision partagée et cohérente des objectifs métiers stratégiques jusqu’aux déploiement des composants logiques sur des serveurs physiques ou virtuels.
Les mains dans le cambouis
L’architecte qui ne code plus (pire n’a jamais codé) a vite fait de s’envoler dans les nuages et de perdre le contact avec la réalité. De la vue aérienne d’un projet il doit pouvoir zoomer sur un composant logique, sa conception et la ligne de code. Seul un astro-architecte qui ne quitte jamais les stratosphères de sa cellule architecture et méthode peut retenir des technologies comme EJB1/2 ou JSF, qui en pratique sont inutilisables. Une technologie ou une architecture peut avoir toutes les qualités que l’on voudra, si elle n’est pas comprise et adopté par les développeurs ça n’ira pas loin.
Les pieds sur la prod
Tan qu’il n’est pas entre les mains des utilisateurs un projet informatique ne produit aucune valeur. Et le passage obligé pour atteindre les utilisateurs c’est la prod. Vous suivez à la lettre les recommandations du site 12factors ? Super votre application est prête à être déployé dans le cloud. Dommage, ce qu’attend votre prod c’est un ear pour déployer sur webFear ! Pour que le succès d’une application soit complet travailler en étroite collaboration avec les gens de la prod (Devops) et aussi important que de leur faire avec le métier (les méthodes agiles)
Et chez vous il fait quoi l’architecte (logiciel bien sûr) ?