Il y a plusieurs manières d’installer Jenkins sous Linux, que j’ai essayé de comparer.
Sommaire
Première solution : sous Docker
Il ne faut pas se tromper d’image Docker : https://jenkins.io/blog/2018/12/10/the-official-Docker-image/
Avantages
Installation rapide et simple.
Indépendant de la distribution Linux et de sa version.
Facilement déplaçable (avec un orchestrateur).
Inconvénients
Ils déconseillent d’utiliser des bind mount, donc les données sont dans des volumes Docker, pas facilement accessibles pour les personnes qui ne connaîtraient pas. Cf https://github.com/jenkinsci/docker/blob/master/README.md
Il faut personnaliser l’image docker pour chaque outil qu’on veut installer (ex : client SQL Net Oracle)
Si on veut que Jenkins lance des images docker, ça fera du docker dans docker (pas si simple) et/ou peut apporter des risques de sécurité, cf https://forums.docker.com/t/using-docker-in-a-dockerized-jenkins-container/322
On ne peut a priori pas mettre à jour Jenkins via son outil intégré.
Deuxième solution : via les repositories .deb/.rpm
Pour RedHat/CentOS : https://wiki.jenkins.io/display/JENKINS/Installing+Jenkins+on+Red+Hat+distributions
Pour Debian/Ubuntu : https://jenkins.io/doc/book/installing/#debian-ubuntu
Avantages
Mises à jour de sécurité gérées via yum ou apt, comme le reste des outils de la distribution.
On peut choisir un repo LTS, pour n’avoir que les mises à jour en LTS.
Installation rapide et simple.
La version est un peu plus récente que sous Docker (au moment ou j’ai testé : 2.164.2 au lieu de 2.121.1), pour une raison que j’ignore (peut-être que l’image Docker est mise à jour moins fréquemment?)
Tout le paramétrage, les données et logs sont facilement accessibles sur le filesystem, et « rangés » suivant les normes de la distribution.
On peut facilement changer les paramètres de lancement de Jenkins (dans /etc/sysconfig/jenkins sous CentOS, dans /etc/default/jenkins sous Debian/Ubuntu).
Inconvénients
On ne peut pas mettre à jour Jenkins via son outil intégré.
Troisième solution : en java -jar avec systemd
Avantages
Mises à jour de Jenkins faisables via l’IHM.
Inconvénients
Il faut gérer soi-même la création du user, la redirection des logs etc.
Il est plus compliqué de modifier les paramètres de le lancement de Jenkins.
Autres solutions recalées
Installer le WAR sur Tomcat (ou autre serveur d’application) : plus compliqué à installer et inutile.
Utiliser d’autre manières (hors systemd) de créer un service pour Jenkins sous Linux : bof, mal intégré avec les OS Linux récents.
Conclusion
Le choix dépend vraiment du contexte, en fonction des compétences des équipes d’administration, de l’utilisation qui sera faite de Jenkins, des besoins de sécurité etc.
Dans le contexte que j’ai eu, c’est la seconde solution qui a été adoptée. Contrairement à d’autres outils, il m’a semblé que la dockerisation n’apportait pas grand chose à Jenkins, tout en ajoutant des contraintes. Le mécanisme de slaves Jenkins permet de gérer de la scalabilité en standard. Et, dans le contexte en question, les futurs exploitants de cette instance ne sont pas familiers avec Docker (en tous cas pour l’instant…)