CITCON Paris 2009
Le CITCON (prononcé « KITCON ») a eu lieu vendredi et samedi dernier à Paris, pour la session européenne 2009. Vendredi soir, après les présentations d’usage, l’open space a commencé par le remplissage du tableau des sessions par les fameux post-it. Pour rappel, les participants écrivent un thème sur un post-it et le collent n’importe où sur le tableau. C’est autour d’un verre, et entre deux discussions, qu’on vote et place les post-it dans les cases proposées pour chaque session.
Samedi matin, j’ai assisté à la session sur la gestion de source dans un environnement distribué. Après une mise au point sur la différence entre gestion de configuration et gestion de source, nous avons entamé la discussion sur l’outil très utilisé dans le développement Open Source dénommé GIT. Cet outil fonctionne en mode décentralisé : il n’y a pas un unique serveur de sources, mais chaque développeur fonctionne à la fois en mode serveur et en mode client. Le développeur peut, par exemple, versionner très souvent ses sources sur son serveur local, mais décider de ne valider ses changements qu’en une seule fois sur le serveur de référence (il peut même signer sa validation !).
Le cas d’un projet partagé entre la France et l’Australie m’a particulièrement intéressé. Le responsable avait mis en place un serveur intermédiaire GIT sur chaque site pour éviter les échanges réseau trop nombreux avec un serveur central. Une synchronisation régulière permettait aux deux sites d’être à jour. Il s’était rendu compte au bout d’un certain temps que cela était en réalité inutile, car la qualité du réseau faisait qu’on pouvait se permettre de n’avoir qu’un seul serveur. En revanche, si cela est peut-être vrai pour l’Australie, ce ne l’est pas forcément pour tous les pays.
Avec GIT, chaque copie du repository est une nouvelle branche ; un développeur en local, c’est une branche. Le fonctionnement des branches est un vrai casse-tête pour des outils comme Subversion, et cette approche propose finalement un peu de simplicité. Mais pour le moment, les serveurs d’Intégration Continue ne font pas la différence entre modes centralisé et décentralisé. Rien n’est proposé aujourd’hui pour mieux profiter d’un monde distribué…
Après un ravitaillement en café et jus d’orange, j’ai suivi Vincent Massol, de XWiki pour savoir comment améliorer notre façon de faire une release avec Maven. Arnaud Heritier faisait parti de la session et après une présentation du processus pour XWiki, ils ont démarré le codage d’une extension au plugin dependency. L’objectif était d’ajouter un goal pour récupérer les différences entre les versions des dépendances entre deux releases. Il faudra être attentif aux prochaines sorties de ce plugin, il y aura peut-être une nouvelle fonction.
Le constat, finalement, était qu’il y avait encore beaucoup d’étapes manuelles lors de la release d’une version et qu’à part développer ses propres MOJOs, Maven était assez loin du compte. Mais ça avance comme le montre le plugin versions, dont Arnaud Heritier nous a vanté les mérites.
L’après-midi, trois sessions nous attendaient mais je souhaite ne parler que de la dernière sur la configuration et le déploiement, les autres étant déjà traitées sur différents blogs. Un problème récurrent se pose sur chaque projet, celui de la modification des valeurs selon l’environnement sur lequel on déploie. On utilise, par exemple, des fichiers de propriétés qui sont remplacés au moment du packaging. Si on s’est trompé dans les propriétés ou si la valeur n’est connue que de la personne qui déploie, il faut dézipper le fichier, changer la valeur et refaire le package. Bonjour la galère !
Deux ingénieurs de ThoughtWorks nous ont présenté leur petit dernier : Escape. Sous ce nom très commun se cache une application Java dans laquelle on peut sauvegarder les valeurs des propriétés de chaque application dans un environnement donné. Ces valeurs peuvent être cryptées. Pour y accéder, une simple interface REST permet d’interroger la base et de récupérer la valeur : l’url http://mymachine:8080/environnements/dev/citcon/city, par exemple, renvoie la valeur de city pour l’environnement de dev sur l’application citcon. Je trouve ce projet simple et efficace pour améliorer la gestion des propriétés de nos applications. La mise en œuvre demandera un peu d’effort pour disposer d’un serveur central mais cela en vaut certainement la peine pour s’affranchir de cette partie de la configuration.
La conférence s’est terminée par un tour des participants sur leur « AA moment » (ie. ce qu’ils ont préférés!) et une distribution de livres sur l’intégration continue.
J’en ai gagné un, écrit par Paul M. Duvall, qui était juste à côté de moi, et me l’a dédicacé. Et c’est aussi ce qui rendait cette journée franchement sympathique et réussie; mon « AA moment » a été de mettre enfin un visage sur des auteurs de blogs ou des contributeurs open source, et surtout pouvoir converser de visu.
Perso, au niveau applicatif, ma proposition pour stocker les propriétés utilisées par une application : utiliser une base de données orientée objet (qui peut avoir un accès web) : http://www.jroller.com/dmdevito/entry/and_now_something_completely_different
Coté application, soit on lirait ces propriétés au vol, soit on les utiliserait pour initialiser une variable, statique par ex, soit l’initialisation sera rendue implicite via un binding par annotation Java.
Cela ressemble un peu à ce qui est proposé là (sauf que j’ai du mal à identifier à quel stade Escape joue son rôle ? au niveau de la CI ? du packaging ? et/ou au niveau applicatif ?), modulo le fait que Escape propose un accès web/REST.
La présentation d’Escape a pris le cas de l’initialisation des variables au niveau applicatif, ie lorsque l’application démarre ou lors de la première utilisation de la propriété.
Mais on peut très bien envisager de récupérer les valeurs avant le packaging et de les stocker directement dans les fichiers de propriétés. Avec la commande _curl_ sous Unix, on peut retrouver une valeur sans pour autant être dans du code Java, Python ou autres.
Les auteurs du produit ne le limitent pas à un rôle donné. Escape ne fait que servir une information à la demande et c’est plutôt au projet de choisir à quel moment on veut l’interroger.
OK, merci de la précision. Intéressant.
Cela rejoint (un peu) mon idée, modulo l’accès web/REST.
Escape me laisse tout à fait perplexe, il me semble qu’il a tout d’un bon candidat pour être le point de faiblesse d’une architecture (single point of failure). Dans ma boîte, nous regardons avec attention Zookeeper (http://hadoop.apache.org/zookeeper/) qui a les mêmes avantages de centralisation de Escape, mais avec en plus la FIABILITE.
Je n’ai pas encore de retour du terrain de la part de Zookeeper, mais il est sûr que Escape ne fait pas un bon candidat. ThoughtWorks nous avait habitué à mieux.
Ces deux solutions (Escape et Zookeeper) me paraissent bien compliquées pour répondre à une problématique pourtant simple : « des valeurs de propriétés pour des environnements différents »
Sur le projet liferay, un pattern très pratique est mis en place : le « chaînage » de fichiers properties.
Le principe est simple : ils utilisent un PropertiesPlaceHolder (spring … mais le principe n’a pas besoin de se reposer sur spring) maison qui va charger un fichier properties.
Si, dans ce fichier, il trouve une clef « magique » (ex: « include-and-override »), il tentera de charger le fichier pointé par cette clef dans le classpath et mergera son contenu avec les propriétés déjà chargées (et ainsi de suite..)
Exemple :
Fichier exemple.default.properties -déclaré systématiquement dans le classpath : contient la configuration « par défaut » de l’appli-
include-and-override=exemple.recette.properties
log.level=INFO
Fichier exemple.recette.properties -à rajouter lors du packaging de recette, contiendra la conf de recette-
include-and-override=exemple.prod.properties
log.level=DEBUG
Fichier exemple.prod.properties -à rajouter lors du packaging de prod, en plus du exemple.recette.properties ci-dessus-
log.level=ERROR
Lorsque le développeur récupère ce qu’il y a sur le référentiel, « out of the box » le niveau de log est en INFO.
Eventuellement il peut customiser son niveau de log en DEBUG en rajoutant (sans le commiter) un exemple.recette.properties dans son classpath
En recette, exemple.default.properties et exemple.recette.properties sont packagés pour un log « final » en DEBUG
Enfin, pour la prod, exemple.default.properties, exemple.recette.properties et exemple.prod.properties sont packagés pour un log final en ERROR
=> Qu’en pensez-vous ?
Frédéric
Zookeeper présente un intérêt dans un environnement où plusieurs centaines d’applications partagent certaines propriétés communes (comme une adresse IP) que l’on veut pouvoir gérer de façon centralisée, puis pouvoir propager la configuration sur chacun des serveurs sans intervention manuelle.
Evidemment, Zookeeper ne s’adresse pas à une problématique dans laquelle seules quelques applications sont en jeu.
Dac je saisis mieux la problématique => je suis à coté avec le pattern évoqué précédemment
Effectivement, je n’ai pas tellement insisté sur ce point, mais l’avantage d’Escape (et de Zookeeper !) est de centraliser toutes les valeurs des propriétés à l’extérieur des applications. On peut évidememnt les partager entre plusieurs d’entre elles, mais rien ne l’y oblige.
Bob, je suis d’accord avec toi sur les faiblesses d’architecture d’Escape comparé à Zookeeper, mais le besoin n’est pas exactement le même. Escape ne nécessite pas une architecture aussi complexe, car il est surtout utilisé au démarrage des applications et peu en cours d’utilisation.
D’autre part, son point fort, pour moi, c’est sa simplicité de mise en oeuvre. ZooKeeper est plus complexe, il propose, par exemple, une fonctionnalité de notifications de changement d’une valeur. Ca va beaucoup plus loin qu’un simple CMDB.
Et l’autre point important, c’est la protection et l’encryption des données. Je n’ai pas lu que ZooKeeper sécurisait ses données. Est-ce le cas?
De mon point de vue, on ne peut pas considérer ZooKeeper comme un CMDB, ce n’est pas sa fonction principale alors qu’Escape se positionne complètement dans ce rôle.
Emmanuel, pour répondre à ta question, tu peux te reporter à http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperProgrammers.html#sc_ZooKeeperAccessControl
Encore une fois, je n’essaye pas de « vendre » cette solution car je n’ai pas de retour d’expérience sur le sujet. Mais le concept me semble intéressant.