Installation/configuration de slaves Jenkins

Jenkins propose un architecture distribuée basée sur des noeuds (aussi appelée master/slave) qui est très efficace et flexible.

Elle permet facilement de répartir des builds sur des machines, qui peuvent être sur des OS différents, avec installation à la volée des outils de build.

Je ne vais pas ré-écrire la documentation de Jenkins, mais donner un retour d’expérience sur des cas que j’ai eu à traiter.

Installation d’un slave

Sous Linux

Sur Linux, il y a peu de pré-requis pour la machine slave :

  • être accessible en SSH
  • avoir une JVM installée dessus (de préférence un JDK pour pouvoir servir aux builds, mais ce n’est pas obligatoire), en version >=8
  • préparer un répertoire où le slave pourra mettre ses données : le owner doit être le user avec lequel on va se connecter dessus, et il faut prévoir la place nécessaire aux builds qui seront faits dessus

Ensuite, dans l’interface web de Jenkins, on déclare un nouveau noeud, avec la méthode « launch agent via SSH ».

Il faut que cette machine fasse partie des « known_hosts » du user qui fait tourner le Jenkins master (sauf si vous choisissez la stratégie de vérification « no verifying », ce qui n’est pas très sécurisé). Il doit y avoir une ligne correspondant à la machine dans le fichier .ssh/known_hosts du home de l’utilisateur (que le master soit sous Windows ou Linux). Pour avoir cette ligne, le plus simple est de s’y connecter une première fois en SSH (avec un user quelconque), de récupérer la ligne dans le known_hosts de ce user, et de la copier-coller.

Sous Windows

La préparation de la machine slave est bien plus compliquée quand elle est sous Windows. Comme sur Linux, il faut qu’une JVM soit installée, et prévoir un répertoire de stockage (avec les droits pour le user qui fera tourner le slave). Mais il y a d’autres manipulations à faire.

Le doc officielle de Jenkins essaie de couvrir tous les cas où la communication ne marche pas (et il y en a beaucoup), avec les contournements : https://wiki.jenkins.io/display/JENKINS/Windows+agents+fail+to+start+via+DCOM.

Dans le cas que j’ai eu à traiter, il s’agissait de machines Windows 2012 dans un domaine Active Directory, donc j’ai eu besoin des paragraphes « Slave under domain account » et « Windows Server 2012 (64bit) », ce qui revient à suivre les étapes ci-dessous :

  1. S’assurer que le compte de service qui sera utilisé est administrateur local de la machine.
  2. Ouvrir le gestionnaire de group policy (gpedit.msc)
  3. Aller dans Computer Configuration->Administrative Templates->System-> UserProfiles
  4. Trouver à droite le paramètre « Do not forcefully unload the user registry at user logoff », et le passer à “Enabled” :
  5. Lancer « regedit » (en tant qu’administrateur)
  6. Rechercher (avec Ctrl+F) la clé de registre suivante : {72C24DD5-D70A-438B-8A42-98424B88AFB8} : si plusieurs correspondent, il faut trouver celle qui se trouve dans HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\
  7. Faire un clic-droit dessus et cliquer sur « Permissions… » puis sur « Advanced »
  8. En haut de l’écran, changer le « Owner », pour y mettre un groupe auquel l’utilisateur actuellement connecté appartient
  9. Dans la liste des « permissions entries », modifier la permission du groupe des administrateurs en « Full Control »
  10. Cliquer sur OK pour appliquer et sortir, puis recliquer sur « Advanced » pour rouvrir la même fenêtre
  11. Changer à nouveau le « owner » pour remettre TrustedInstaller comme c’était au début. Pour cela, il faut choisir la machine courante comme « location », et mettre le nom «NT Service\TrustedInstaller»
  12. Répéter les étapes 6 à 12 pour HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
  13. Redémarrer le service “Remote Registry”

Ouf! Ensuite on configure le noeud dans le Jenkins master.

Il est possible que, lors du premier lancement, la log (visible dans le master) affiche un problème d’authentification lors du démarrage du service (sur le slave). Dans ce cas, le contournement qu’on a trouvé consiste à se connecter en RDP sur le slave, aller dans la gestion des services, aller dans les propriétés du service « Jenkins agent », onglet logon, y mettre manuellement le login/mot de passe du compte de service, et faire appliquer. Puis, dans l’interface web de Jenkins, redémarrer le nœud slave.

Configuration des outils

Quand on veut lancer des builds sur les slaves, on a en général besoin d’outils de build. Dans notre cas, il s’agit de Maven (qui doit être dans une version précise, et qui doit être configuré pour passer par un serveur Nexus), mais il peut s’agir d’une version particulière de Java, de Gradle, de git etc.

Pour cela, Jenkins a une fonction que je trouve géniale, qui permet de déployer automatiquement ces outils (au besoin) sur les différents noeuds (master ou slave). Au lieu de les installer et configurer manuellement sur chaque machine, c’est Jenkins qui s’en occupe.

Dans l’administration de Jenkins, on peut définir cela dans « Configuration globale des outils ». Pour la plupart des outils, il y a une option « install automatically », ou « extract zip/tar.gz ». Si on lui fournit une URL où télécharger une archive de l’outil, il s’occupera de le déployer là ou il y en a besoin. En jouant sur les labels, on peut avoir une archive différente pour chaque OS, mais ce n’est pas toujours nécessaire.

Concernant le téléchargement de l’archive, l’URL que j’avais était soumise à authentification, et je n’ai pas trouvé moyen de configurer Jenkins pour qu’il passe mes credentials (la syntaxe http://user:password@server n’est pas acceptée). J’ai contourné le problème en configurant un reverse-proxy qui passe les credentials à la place de Jenkins.

Configuration de Maven

Dans le cas de Maven, on peut avoir une seule et même archive pour Windows et Linux, puisque c’est du java. Il faut dans ce cas utiliser plutôt du .tar.gz, pour que /bin/mvn ait le droit d’exécution sur linux.

Il y a un autre petit piège : si on prend directement le .tar.gz fourni par apache, tout y est mis dans un répertoire apache-maven-x.x.x. Ca ne convient pas à Jenkins, qui s’attendrait à y trouver directement le répertoire bin, par exemple. Il faut donc recréer manuellement le .tar.gz en y mettant directement le contenu, sans le répertoire apache-maven-x.x.x

C’est aussi l’occasion d’y modifier le fichier settings.xml, pour y mettre le paramétrage custom, notamment les « mirrors » (Nexus, dans notre cas), ou les proxy HTTP.

Conclusion

Avec ce type de configuration, il devient facile de lancer des builds à la fois sur Linux et sur Windows, et de répartir la charge entre plusieurs serveurs. Et la notion d’outils allège beaucoup la préparation (et la maintenance) des serveurs.

Cela peut permettre d’utiliser ponctuellement les ressources de certaines machines (si on a besoin de lancer beaucoup de builds) sans perdre de temps à la préparer (c’est surtout valable pour les machines Linux…), et sans être intrusif sur la machine. On peut notamment configurer les slaves de sorte qu’ils se mettent en sommeil quand ils ne sont pas utilisés : « Bring this agent online when in demand, and take offline when idle »

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *