Installer Puppet sur Travis CI

Si vous développez un module Puppet et que vous souhaitez le tester de manière continue sur Travis CI, il y a déjà pas mal de littérature sur le web à ce sujet. Dans les grandes lignes, il suffit de spécifier dans votre travis.yml que le langage est Ruby et de donner les versions de Puppet à tester.

J’ai eu à traiter un cas légèrement différent.
Le projet Roboconf sur lequel je travaille possède une extension qui permet d’exécuter des modules Puppet. Afin de tester cette extension, j’ai donc besoin que Puppet soit installé sur mes VM. Sauf que ces VM sont configurées pour le langage Java, et non Ruby. Il faut donc que j’installe Puppet à la main. Sachant que Travis utilise actuellement Ubuntu 12.04 LTS, on ne peut pas s’appuyer sur les dépôts Ubuntu (2.x chez Ubuntu contre 3.x côté Puppet Labs).

Dans un premier temps, j’avais simplement ajouté à mon travis.yml

before_script:
  - sudo apt-get install rubygems
  - sudo gem install facter
  - sudo gem install puppet

Mais je récoltais une erreur dans mes tests.
La commande puppet –version échouait lamentablement. Et impossible d’avoir des détails sur le problème, ni même de reproduire cette erreur avec Virtualbox en local. Finalement, j’ai pu obtenir un message détaillé en rajoutant la commande en question dans mon travis.yml (juste après le sudo gem install puppet).

Cela m’a permis de récupérer l’erreur dans la console de Travis.

/usr/lib/ruby/vendor_ruby/1.8/rubygems/dependency.rb:247:in `to_specs’: Could not find puppet (>= 0) amongst [bigdecimal-1.1.0, bundler-1.6.2, bundler-unload-1.0.2, executable-hooks-1.3.2, gem-wrappers-1.2.4, io-console-0.3, json-1.5.5, minitest-2.5.1, rake-10.2.2, rake-0.9.2.2, rdoc-3.9.5, rubygems-update-2.3.0, rvm-1.11.3.9] (Gem::LoadError)
from /usr/lib/ruby/vendor_ruby/1.8/rubygems/dependency.rb:256:in `to_spec’
from /usr/lib/ruby/vendor_ruby/1.8/rubygems.rb:1208:in `gem’
from /usr/local/bin/puppet:18

En cherchant un peu, j’ai trouvé sur le web un article qui évoquait des problèmes de path avec Puppet lorsque l’on utilise le mode super utilisateur. Apparemment, la commande sudo réinitialiserait le path. Du coup, les gems que j’ai installés en sudo ne sont pas dans le path. L’article en question préconisait plutôt d’utiliser rvmsudo en lieu et place de sudo. Sauf que cela ne m’arrangeait pas du tout pour mes tests à venir (Puppet n’est pas exécuté à la main dans mes tests, mais invoqué par du code Java).

En désespoir de cause, je me suis décidé à tenter la commande gem install sans le sudo. Et cela a marché. Voilà donc ce qu’il faut ajouter à votre travis.yml si vous souhaitez installer Puppet sur une VM Java chez Travis.

before_script:
  - sudo apt-get install rubygems
  - gem install puppet

Comme quoi les choses les plus simples…

Quelques Nouvelles

Cela fait quelques temps que je n’avais rien publié ici.
Autant commencer par une annonce directe. Je ne travaille plus sur Petals ESB. Le projet continue d’avancer, à un rythme moins soutenu qu’avant, mais sans moi. Je suis ce qui se passe, mais de loin désormais.

Depuis quelques mois, je travaille sur un projet un peu éloigné des problématiques des ESB. Le projet en question s’appelle Roboconf et tourne autour du déploiement d’applications réparties, que ce soit dans le cloud ou sur d’autres infrastructures (comme de l’embarqué ou des machines plus classiques). Evidemment, le nom Roboconf fait un peu old school, mais on s’y fait.

Le projet est open-source et sous licence Apache.
Et il est hébergé sur GitHub. Un petit site a été bricolé et un début de guides utilisateur et développeur ont été publiés.

Il est probable que je posterai quelques informations et astuces à propos de ce projet. Roboconf est en incubation, et une version stable ne sortira pas avant plusieurs mois. Pour l’instant, le focus est donné à la plateforme. C’est une application répartie également, ce qui pose pas mal de questions sur la testabilité, sur le debug, etc. De par mon expérience, je sais que ce qui fait la différence, c’est l’utilisabilité et les outils. Force est de constater que l’on a jamais atteint le niveau que j’attendais sur ces points avec Petals ESB. Sur Roboconf, j’espère pouvoir influencer ces aspects. Mais le préalable à toutes ces questions, c’est d’abord que la plateforme fonctionne efficacement, et que l’on puisse tester des scénarios utilisateurs. Il y en a encore pour plusieurs mois de travail avant que je ne puisse m’attaquer à des trucs plus cools pour des utilisateurs. Et même si une partie des utilisateurs risque d’être des exploitants, avec un profil d’administrateur système, des outils de diagnostic et d’aide à la résolution des problèmes seront les bienvenus.

En termes de cas d’usage, Linagora prévoit d’utiliser Roboconf pour déployer une plateforme collaborative. Ceux qui connaissent la notion de Réseau Social d’Entreprise (RSE) seront peut-être intéressés par ce projet.

Par ailleurs, nous travaillons sur Roboconf avec l’Université Joseph Fourier à Grenoble. Et force est de constater que l’équipe universitaire apporte tout un tas de cas d’usages intéressants : des problématiques d’analyse de données issues de capteurs (de gros volumes de données remontés jusque dans des outils déployés dans le nuage), des déploiements sur des infrastructures très hétérogènes… C’est parfois assez amusant.

Dans tous les cas, je vois dans ce projet un certain potentiel.
L’avenir nous dira s’il se concrétise.