Si vous travaillez dans un environnement Unix, la façon la plus pratique de démarrer un esclave Jenkins est sans aucun doute d'utiliser SSH. Jenkins possède son propre client SSH intégré, et presque tous les environnements Unix supportent SSH (habituellement sshd) de base.

Pour créer un esclave de type Unix, cliquez sur le bouton Nouveau noeud comme nous l'avons mentionné ci-dessus. Cela vous demande d'entrer le nom de votre esclave, et son type (voir Figure 11.2, “Créer un nouveau noeud esclave”). Au moment de l'écriture de ces lignes, seuls les “esclaves passifs” sont supportés en standard; ces esclaves répondent simplement aux requêtes de build en provenance du noeud maître. C'est la façon la plus commune de mettre en place une architecture de build distribuée, et c'est la seule option disponible dans une installation par défaut.

Dans cet écran, vous devez simplement fournir un nom pour votre esclave. Lorsque vous cliquez sur OK, Jenkins vous permet de fournir plus de détails sur vos machines esclaves (voir Figure 11.3, “Créer un noeud esclave Unix”).

Ce nom est simplement un moyen unique pour identifier votre machine esclave. Ce peut être n'importe quoi, mais il pourrait être utile que ce nom vous rappelle la machine physique sur laquelle cela fonctionne. Il est aussi utile que ce nom soit compatible avec le système de fichiers et un format URL. Les espaces sont autorisés, mais cela vous facilitera la vie de les éviter. Ainsi, “Slave-1” est meilleur que “Slave 1”.

La description est aussi purement destinée à la lecture humaine, et peut être utilisée pour indiquer pourquoi utiliser cet esclave plutôt qu'un autre.

Comme sur l'écran principal de configuration Jenkins, le nombre d'exécuteurs vous permet de définir le nombre de tâches de build concurrentes que ce noeud peut exécuter.

Tout noeud esclave Jenkins nécessite aussi un emplacement qu'il puisse utiliser comme racine, ou, plus précisément un répertoire dédié sur la machine esclave que l'agent esclave puisse utiliser pour exécuter des tâches de build. Vous définissez ce répertoire dans le champ racine du disque distant. Vous devez fournir un chemin local, spécifique à l'OS, tel que /var/jenkins pour une machine Unix ou C:\jenkins sur Windows. Rien d'essentiel n'est stocké dans ce répertoire — tout ce qui est important est renvoyé à la machine maître une fois que le build est effectué. Vous n'avez donc généralement pas besoin de vous inquiéter de sauvegarder ces répertoires comme c'est le cas avec ceux du maître.

Les libellés sont un concept particulièrement utile quand votre architecture distribuée commence à grossir. Vous définissez des libellés, des tags, pour chaque noeud de build, et configurez ensuite une tâche de build afin qu'elle s'exécute avec un libellé particulier. Les libellés peuvent avoir trait au système d'exploitation (unix, windows, macosx, etc.), aux environnements (staging, recette, développement, etc.) ou n'importe quel critère que vous trouveriez utile. Par exemple, vous pouvez configurer vos tests automatisés WebDriver/Selenium pour qu'ils s'exécutent avec Internet Explorer, mais seulement sur des noeuds esclaves avec le libellé “windows”.

Le champ Utilisation vous permet de configurer l'intensité avec laquelle Jenkins utilisera cet esclave. Vous avez le choix parmi trois options : utiliser cet esclave autant que possible, réserver pour les tâches de build dédiées, ou le mettre en ligne quand c'est nécessaire.

La première option “Utiliser cet esclave autant que possible”, indique à Jenkins d'utiliser librement cet esclave dès qu'il devient disponible, pour toute tâche qu'il peut exécuter. C'est de loin l'option la plus utilisée, et généralement celle que vous voulez.

Quelques fois, cependant, la seconde option peut s'avérer utile. Dans la configuration du projet, vous pouvez lier une tâche de build à un noeud spécifique — c'est utile quand une tâche particulière, comme un déploiement automatisé ou une suite de tests de performance, nécessite d'être exécutée sur une machine spécifique. Dans ce cas, l'option “Réserver cette machine pour les tâches associées uniquement” peut avoir du sens. Vous pouvez aller encore plus loin en positionnant le nombre maximum d'Exécuteurs à 1. Dans ce cas, non seulement cet esclave sera réservé pour un type particulier de tâche, mais il sera uniquement capable d'exécuter une seule de ces tâches de build à tout instant. C'est une configuration très utile pour les tests de performance ou de charge, où vous avez besoin de réserver la machine pour qu'elle exécute ses tests sans interférence.

La troisième option est “Mettre cet esclave en ligne lors de demande et hors-ligne sinon” (voir Figure 11.4, “Mettre un esclave hors-ligne lorsqu'il est inactif”). Comme le nom l'indique, cette option indique à Jenkins de mettre cet esclave en ligne lorsque la demande est élevée et de le mettre hors-ligne lorsque la demande faiblit. Ceci permet de garder quelques esclaves de build pour les périodes d'utilisation importante, sans avoir à maintenir dessus un agent esclave fonctionnant en permanence. Quand vous choisissez cette option, vous devez aussi fournir quelques détails supplémentaires. Le “Délai de la demande” indique combien de minutes les tâches doivent avoir attendu dans la file d'attente avant que cet esclave ne soit mis en ligne. Le champ Délai d'inactivité indique combien de temps l'esclave doit avoir été inactif avant que Jenkins ne le mette hors-ligne.

La méthode de lancement décide de comment Jenkins lancera le noeud, comme nous l'avons mentionné précédemment. Pour la configuration dont nous parlons ici, vous choisiriez “Lancer les agents esclaves sur machines Unix via SSH”. Le bouton Avancé vous permet d'entrer des détails additionnels dont Jenkins a besoin pour se connecter à la machine esclave Unix : un nom d'hôte, un login et mot de passe et un numéro de port. Vous pouvez aussi fournir un chemin vers un fichier de clé privée SSH sur la machine maître (e.g., id_dsa ou id_rsa) à utiliser pour une authentification “sans mot de passe” par clés Publique/Privée.

Vous pouvez aussi configurer quand Jenkins démarre ou arrête l'esclave. Par défaut, Jenkins gardera simplement l'esclave en fonctionnement et l'utilisera chaque fois qu'il en aura besoin (option “Garder cet esclave en ligne autant que possible”). Si Jenkins remarque que l'esclave est déconnecté (par exemple à cause d'un redémarrage serveur), il essaiera de le redémarrer s'il le peut. Sinon, Jenkins peut être plus conservateur avec vos ressources systèmes, et mettre l'esclave hors-ligne lorsqu'il n'en a pas besoin. Pour faire cela, choisissez simplement l'option “Mettre cet esclave en ligne si nécessaire et hors-ligne en cas d'inactivité”. C'est utile si vous avez régulièrement des pics et accalmies de l'activité de build, car un esclave peut être mis hors-ligne pour conserver les ressources systèmes pour d'autres tâches, et remis en ligne lorsque c'est nécessaire.

Jenkins a aussi besoin de savoir où il peut trouver les outils de build dont il a besoin pour vos tâches de build sur les machines esclaves. Ceci inclut aussi bien les JDKs que les outils de build comme Maven, Ant, et Gradle. Si vous avez configuré vos outils de build pour être automatiquement installés, vous n'aurez générallement pas de configuration supplémentaire à effectuer pour vos machines esclaves; Jenkins téléchargera et installera les outils au besoin. D'un autre côté, si vos outils de build sont installés localement sur la machine esclave, vous aurez besoin d'indiquer à Jenkins où il peut les trouver. Ceci se fait en cochant la case Emplacement des outils, et en fournissant les chemins locaux pour chaque outil nécessaire à vos tâches de build (voir Figure 11.5, “Configurer l'emplacement des outils”).

Vous pouvez aussi spécifier des variables d'environnement. Celles-ci seront passées à vos tâches de build, et ce peut être un moyen de permettre à vos tâches de se comporter différemment en fonction de l'endroit où elles s'exécutent.

Une fois que vous avez fait cela, votre nouveau noeud esclave apparaîtra dans la liste des ordinateurs sur la page des Noeuds Jenkins (voir Figure 11.6, “Votre nouveau noeud esclave en action”).

Une autre option est de démarrer l'agent esclave depuis la machine esclave elle-même en utilisant Java Web Start (JNLP). Cette approche est utile si le serveur ne peut pas se connecter à l'esclave, par exemple si la machine esclave s'exécute de l'autre côté d'un firewall. Cela fonctionne quel que soit le système d'exploitation de votre esclave, toutefois c'est l'option la plus souvent utilisée pour les esclaves Windows. Cela présente quelques inconvénients majeurs : le noeud esclave ne peut pas être démarré, ou redémarré, automatiquement par Jenkins. Ainsi, si l'esclave tombe, l'instance maître ne peut pas le redémarrer.

Quand vous faites cela sur une machine Windows, vous devez démarrer l'esclave Jenkins manuellement au moins une fois. Ceci implique d'ouvrir un navigateur sur la machine, ouvrir la page du noeud esclave sur le maître Jenkins et de lancer l'esclave en utilisant l'icône JNLP bien visible. Une fois que vous avez lancé l'esclave, vous pouvez l'installer comme un service Windows.

Il y a aussi des moments où vous avez besoin de faire cela depuis la ligne de commande, dans un environnement Unix. Vous pourriez avoir besoin de ça à cause d'un firewall ou d'autres problèmes réseau, ou parce que SSH n'est pas disponible dans votre environnement.

Détaillons à présent les deux processus.

La première chose que vous devez faire dans tous les cas est de créer un nouvel esclave. Comme pour tout noeud esclave, vous faites cela en cliquant sur l'entrée Nouveau noeud dans l'écran Noeuds. Lors de la saisie des détails concernant votre noeud esclave, assurez-vous de choisir “Lancer les agents esclave via JNLP” dans le champ Méthode de lancement (voir Figure 11.7, “Créer un noeud esclave pour JNLP”). Rappelez-vous aussi que c'est un noeud esclave Windows, la racine du système de fichiers distant doit être un chemin Windows (comme C:\jenkins-slave). Ce répertoire n'a pas à exister : Jenkins le créera automatiquement s'il manque.

Une fois que vous avez sauvé cette configuration, connectez-vous, ensuite, sur la machine esclave et ouvrez l'écran du noeud esclave dans un navigateur, comme montré sur Figure 11.8, “Lancer un esclave via Java Web Start”. Vous verrez un large bouton orange Lancer — si vous cliquez sur ce bouton, vous devriez être capable de lancer un agent esclave directement depuis votre navigateur.

Si tout va bien, ceci ouvrira une petite fenêtre indiquant que votre esclave est à présent en fonctionnement (voir Figure 11.9, “L'agent esclave Jenkins en action”).

Les navigateurs sont inconstants, toutefois, et Java Web Start n'est pas toujours simple à utiliser. Cette approche fonctionne habituellement avec Firefox, bien que vous deviez auparavant avoir installé le JRE Java pour que Firefox comprenne Java. Utiliser JNLP avec Internet Explorer requiert un ensemble (non négligeable) de bricolages pour associer les fichiers *.jnlp avec l'exécutable Java Web Start, un fichier appelé javaws, que vous trouverez dans le répertoire bin de Java. Il est en fait probablement plus simple de le lancer depuis la ligne de commande comme discuté ci-dessous.

Une approche plus fiable, quoique bas-niveau, est de démarrer l'esclave depuis la ligne de commande. Pour faire ça, invoquez simplemet l'exécutable javaws depuis une fenêtre de commande comme suit :

C:> javaws http://build.myorg.com/jenkins/computer/windows-slave-1/slave-agent.jnlp

La commande exacte que vous devez exécuter, notamment avec l'URL correcte, est idéalement affichée dans la fenêtre du noeud esclave Jenkins juste en dessous du bouton de lancement JNLP (voir Figure 11.8, “Lancer un esclave via Java Web Start”).

Si la sécurité est activée sur votre serveur Jenkins, Jenkins communiquera avec l'esclave sur un port spécifique non standard. Si pour une raison quelconque ce port est inaccessible, le noeud esclave échouera au lancement et affichera un message d'erreur similaire à celui montré dans Figure 11.10, “L'esclave Jenkins échouant à la connexion au maître”.

Ceci est habituellement le signe qu'un firewall bloque un port. Par défaut, Jenkins choisit aléatoirement un port pour la communication TCP avec ses esclaves. Cependant si vous devez avoir un port spécifique que votre firewall autorise, vous pouvez forcer Jenkins à utiliser un port fixe dans l'écran de configuration système en sélectionnant l'option Fixe dans “Port TCP pour les agents esclaves JNLP”, comme montré dans Figure 11.11, “Configurer le port de l'esclave Jenkins”.

Une fois que vous avez démarré votre esclave sur votre machine Windows, vous pouvez vous épargner la peine d'avoir à le redémarrer manuellement chaque fois que votre machine redémarre en l'installant comme un service Windows. Pour faire cela, sélectionnez l'option de menu “Installer comme Service Windows” dans le menu Fichier de la fenêtre de l'agent esclave (voir Figure 11.12, “Installer l'esclave Jenkins en tant que service Windows”).

Une fois que c'est fait, votre noeud esclave Jenkins démarrera automatiquement chaque fois que la machine démarre, et peut être administré comme n'importe quel autre service Windows (voir Figure 11.13, “Gérer le service Windows Jenkins”).

Vous pouvez aussi démarrer un agent esclave en mode headless, directement depuis la ligne de commande. C'est utile si vous n'avez pas d'interface utilisateur disponible, par exemple si vous démarrez un noeud esclave JNLP sur une machine Unix. Si vous travaillez avec des machines Unix, il est généralement plus facile et plus flexible d'utiliser simplement une connexion SSH, mais il y a parfois des contraintes de réseau ou d'architecture qui vous empêchent d'utiliser SSH. Dans ce genre de cas, il est encore possible d'exécuter un noeud esclave depuis la ligne de commande.

Pour démarrer le noeud esclave de cette façon, vous devez utiliser le fichier slave.jar de Jenkins. Vous pouvez le trouver dans JENKINS_HOME/war/WEB-INF/slave.jar. Une fois ce fichier localisé et copié sur la machine esclave Windows, vous pouvez l'exécuter comme suit :

java -jar slave.jar \
 -jnlpUrl http://build.myorg.com/jenkins/computer/windows-slave-1/slave-agent.jnlp

Et si votre serveur Jenkins nécessite une authentification, passez simplement l'option -auth username:password :

java -jar slave.jar \
 -jnlpUrl http://build.myorg.com/jenkins/computer/windows-slave-1/slave-agent.jnlp
 -auth scott:tiger

Une fois que vous avez démarré l'agent esclave, assurez de l'installer en tant que service Windows, comme indiqué dans la section précédente.

Jenkins peut aussi gérer un esclave Windows distant comme un service Windows, en utilisant le service Windows Management Instrumentation (WMI) qui est installé par défaut sur Windows 2000 ou supérieur (voir Figure 11.14, “Permettre à Jenkins de contrôler un esclave Windows comme un service Windows”). Quand vous choisissez cette option, vous avez seulement besoin de fournir un nom d'utilisateur et un mot de passe Windows. Le nom du noeud doit être le nom de machine de la machine esclave.

Ceci est certainement pratique, parce que cela ne requiert pas de se connecter à la machine Windows pour la configurer. Toutefois, cette méthode possède quelques limitations — en particulier, vous ne pouvez pas exécuter d'applications nécessitant une interface graphique, vous ne pouvez donc pas mettre en place un esclave de cette façon pour faire du test Web, par exemple. En pratique, cela peut se révéler un peu compliqué à paramétrer, parce que vous pourriez avoir besoin de configurer le firewall Windows pour ouvrir les ports et services appropriés. Si vous rencontrez des problèmes, assurez-vous que votre configuration réseau autorise les connexions TCP aux ports 135, 139, et 445, ainsi que les connexions UDP aux ports 137 et 138 (voir https://wiki.jenkins-ci.org/display/JENKINS/Windows+slaves+fail+to+start+via+DCOM pour plus de détails).