3.3. Préparation d'un serveur de build pour Jenkins

L'installation de Jenkins sur votre machine locale de développement est une chose, mais l'installation de Jenkins sur un bon serveur de build mérite un peu plus de prévoyance et de planification.

Avant de commencer votre installation, la première chose dont vous aurez besoin est un serveur de build. Pour fonctionner correctement, Jenkins a besoin à la fois d'un processeur puissant et de mémoire. Jenkins, pour sa part, est une application web Java relativement modeste. Cependant, pour la majorité des configurations, au moins une partie des builds sera exécutée sur le serveur de build principal. Les builds ont tendance à être à la fois gourmand en mémoire et en temps processeur, et Jenkins peut être configuré pour exécuter plusieurs builds en parallèle. Selon le nombre de tâches de build que vous gérez, Jenkins aura aussi besoin de mémoire dédiée pour son propre usage interne. La quantité de mémoire nécessaire dépendra en grande partie de la nature de vos builds, mais la mémoire n'est pas cher ces temps-ci (du moins pour des environnements non hébergés), et il vaut mieux ne pas être avare.

Un serveur de build a aussi besoin d'un CPU puissant. En règle générale, vous aurez besoin d'un processeur par build parallèle, même si, dans la practique, vous pouvez capitaliser sur les délais d'E/S pour faire un peu mieux que cela. Il est également dans votre intérêt de dédier votre serveur de build, autant que possible, à la tâche de gestion des builds continus. En particulier, vous devriez éviter les applications gourmandes en mémoire ou en CPU tels que les serveurs de test, les applications d'enterprise fortement utilisées, les base de données d'entreprise tel que Oracle, les serveurs de messagerie d'entreprise, et ainsi de suite .

Une option vraiment pratique, disponible dans de nombreuses organisations aujourd'hui, est d'utliser une machine virtuelle. De cette façon, vous pouvez choisir la quantité de mémoire et le nombre de processeurs que vous jugez appropriés pour votre installation initiale, et d'ajouter facilement de la mémoire et des processeurs plus tard si nécessaire. Cependant, si vous utilisez une machine virtuelle, assurez-vous qu'elle dispose de suffisamment de mémoire pour supporter le nombre maximal de builds en parallèle auquel vous vous attendez à être exécuté. L'utilisation de la mémoire d'un serveur d'intégration continue peut-être vue comme des dents de scie — Jenkins créera, au besoin, des JVMs supplémentaires pour ses tâches de build, et celles-ci ont besoin de mémoire.

Une autre approche utile est de configurer plusieurs machines de build. Jenkins rend facile la mise en place d'“esclaves” sur d'autres machines qui peuvent être utilisées pour exécuter des tâches de build additionnelles. Les esclaves restent inactifs jusqu'à ce qu'une nouvelle tâche de build soit demandée — puis l'installation principale de Jenkins envoie la tâche de build à un esclave et rend compte des résultats. C'est une excellente façon d'absorber les pointes soudaines de l'activité de build, par exemple juste avant une livraison majeure de votre principal produit. C'est aussi une stratégie utile si certains gros builds ont tendance à “accaparer” le serveur de build principal — il suffit de les mettre sur leur propre agent de build ! Nous verrons comment faire cela en détail plus loin dans ce livre.

Si vous installez Jenkins sur un serveur de build Linux ou Unix, cela peut-être une bonne idée de créer un utilisateur spécial (et un groupe utilisateur) pour Jenkins. Cela rend plus facile de surveiller d'un coup d'oeil les ressources système utilisées par les builds de Jenkins, et ainsi résoudre les builds qui posent problème en conditions réelles. Les paquets d'installation des binaires natifs décrits ci-dessous font cela pour vous. Si vous n'avez pas utilisé l'un d'entre eux, vous pouvez créer un utilisateur Jenkins dédié depuis la ligne de commande comme montré ici:

			$
			sudo groupadd build
			$
			sudo useradd --create-home --shell
				/bin/bash --groups build jenkins
		

Les détails exacts peuvent varier en fonction de votre environnement. Par exemple, vous préférerez peut-être utiliser une console d'administration graphique au lieu de la ligne de commande, ou, sur un serveur Linux basé sur une Debian (comme Ubuntu), vous pouvez utiliser des commandes plus conviviales comme : adduser et addgroup .

Dans la majorité des environnements, vous devrez configurer correctement Java pour cet utilisateur. Par exemple, vous pouvez le faire en définissant les variables JAVA_HOME et PATH dans le fichier .bashrc , comme montré ici:

export
			JAVA_HOME=/usr/local/java/jdk1.6.0
			export PATH=$JAVA_HOME/bin:$PATH

Vous devriez maintenant être en mesure d'utiliser cet utilisateur pour exécuter Jenkins dans un environnement isolé.