docker
2.486
Le serveur d'intégration et de livraison continues Jenkins disponible sur Docker Hub.
Il s'agit d'un serveur Jenkins entièrement fonctionnel. https://jenkins.io/.
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
REMARQUE : lisez la section Agents de connexion ci-dessous pour connaître le rôle du mappage de 50000 ports. REMARQUE : lisez la section Configuration DNS au cas où vous verriez le message « Cette instance Jenkins semble être hors ligne. »
Cela stockera l'espace de travail dans /var/jenkins_home . Toutes les données Jenkins y résident, y compris les plugins et la configuration. Vous souhaiterez probablement en faire un volume explicite afin de pouvoir le gérer et le connecter à un autre conteneur pour les mises à niveau :
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17
Cela créera automatiquement un volume docker « jenkins_home » sur la machine hôte. Les volumes Docker conservent leur contenu même lorsque le conteneur est arrêté, démarré ou supprimé.
REMARQUE : évitez d'utiliser un montage lié à partir d'un dossier sur la machine hôte vers /var/jenkins_home , car cela pourrait entraîner des problèmes d'autorisation de fichier (l'utilisateur utilisé à l'intérieur du conteneur peut ne pas avoir de droits sur le dossier sur la machine hôte). Si vous avez vraiment besoin de lier le montage jenkins_home, assurez-vous que le répertoire sur l'hôte est accessible par l'utilisateur jenkins à l'intérieur du conteneur (utilisateur jenkins - uid 1000) ou utilisez le paramètre -u some_other_user avec docker run .
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
Cela exécutera Jenkins en mode détaché avec la redirection de port et le volume ajouté. Vous pouvez accéder aux journaux avec la commande 'docker logs CONTAINER_ID' afin de vérifier le premier jeton de connexion. L'ID du conteneur sera renvoyé par la sortie de la commande ci-dessus.
Si vous liez le montage dans un volume, vous pouvez simplement sauvegarder ce répertoire (qui est jenkins_home) à tout moment.
L'utilisation d'un montage lié n'est pas recommandée car elle peut entraîner des problèmes d'autorisation. Traitez le répertoire jenkins_home comme vous le feriez pour une base de données - dans Docker, vous placeriez généralement une base de données sur un volume.
Si votre volume se trouve dans un conteneur, vous pouvez utiliser la commande docker cp $ID:/var/jenkins_home pour extraire les données, ou d'autres options pour trouver où se trouvent les données du volume. Notez que certains liens symboliques sur certains systèmes d'exploitation peuvent être convertis en copies (cela peut confondre jenkins avec les liens lastStableBuild, etc.)
Pour plus d'informations, consultez la section de la documentation Docker sur Utiliser les volumes
Vous pouvez définir le nombre d'exécuteurs sur le nœud intégré Jenkins à l'aide d'un script groovy. Par défaut, il est défini sur 2 exécuteurs, mais vous pouvez étendre l'image et la modifier selon le nombre d'exécuteurs souhaité (0 exécuteurs recommandés sur le nœud intégré) :
executors.groovy
import jenkins.model.* Jenkins.instance.setNumExecutors(0) // Recommended to not run builds on the built-in node
et Dockerfile
FROM jenkins/jenkins:lts COPY --chown=jenkins:jenkins executors.groovy /usr/share/jenkins/ref/init.groovy.d/executors.groovy
Vous pouvez exécuter des builds sur le contrôleur immédiatement. Le projet Jenkins recommande qu'aucun exécuteur ne soit activé sur le contrôleur.
Afin de connecter des agents via une connexion TCP entrante , mappez le port : -p 50000:50000 . Ce port sera utilisé lorsque vous connecterez des agents au contrôleur.
Si vous utilisez uniquement des agents de build SSH (sortants), ce port n'est pas requis, car les connexions sont établies à partir du contrôleur. Si vous connectez des agents à l'aide de web sockets (depuis Jenkins 2.217), le port de l'agent TCP n'est pas non plus utilisé.
Vous devrez peut-être personnaliser la JVM exécutant Jenkins, généralement pour ajuster les propriétés du système ou modifier les paramètres de mémoire tas. Utilisez pour cela les variables d'environnement JAVA_OPTS ou JENKINS_JAVA_OPTS :
docker run --name myjenkins -p 8080:8080 -p 50000:50000 --restart=on-failure --env JAVA_OPTS=-Dhudson.footerURL=http://mycompany.com jenkins/jenkins:lts-jdk17
Les options JVM spécifiquement pour le contrôleur Jenkins doivent être définies via JENKINS_JAVA_OPTS , car d'autres outils peuvent également répondre à la variable d'environnement JAVA_OPTS .
La journalisation Jenkins peut être configurée via un fichier de propriétés et la propriété Java java.util.logging.config.file . Par exemple:
mkdir data cat > data/log.properties <<EOF handlers=java.util.logging.ConsoleHandler jenkins.level=FINEST java.util.logging.ConsoleHandler.level=FINEST EOF docker run --name myjenkins -p 8080:8080 -p 50000:50000 --restart=on-failure --env JAVA_OPTS="-Djava.util.logging.config.file=/var/jenkins_home/log.properties" -v `pwd`/data:/var/jenkins_home jenkins/jenkins:lts-jdk17
Si vous souhaitez installer Jenkins derrière un proxy inverse avec un préfixe, exemple : mysite.com/jenkins, vous devez ajouter la variable d'environnement JENKINS_OPTS="--prefix=/jenkins" puis suivre les procédures ci-dessous pour configurer votre proxy inverse, ce qui dépendra si vous avez Apache ou Nginx :
Apache
Nginx
Si le message « Cette instance Jenkins semble être hors ligne. » apparaît au premier démarrage et les journaux du conteneur affichent des lignes telles que java.net.UnknownHostException: updates.jenkins.io , votre conteneur peut avoir des problèmes pour résoudre les noms DNS.
Pour potentiellement résoudre le problème, démarrez le conteneur en spécifiant un serveur DNS (par exemple le 1.1.1.1 de Cloudflare ou le 8.8.8.8 de Google, ou tout autre serveur DNS) :
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure --dns 1.1.1.1 --dns 8.8.8.8 jenkins/jenkins:lts-jdk17
Les arguments que vous transmettez au docker exécutant l'image Jenkins sont transmis au lanceur jenkins, vous pouvez donc par exemple exécuter :
docker run jenkins/jenkins:lts-jdk17 --version
Cela affichera la version de Jenkins, la même que lorsque vous exécutez Jenkins à partir d'un war exécutable.
Vous pouvez également définir des arguments Jenkins via JENKINS_OPTS . Ceci est utile pour personnaliser les arguments du lanceur Jenkins dans une image Jenkins dérivée. L'exemple Dockerfile suivant utilise cette option pour forcer l'utilisation de HTTPS avec un certificat inclus dans l'image.
FROM jenkins/jenkins:lts-jdk17 COPY --chown=jenkins:jenkins certificate.pfx /var/lib/jenkins/certificate.pfx COPY --chown=jenkins:jenkins https.key /var/lib/jenkins/pk ENV JENKINS_OPTS="--httpPort=-1 --httpsPort=8083 --httpsKeyStore=/var/lib/jenkins/certificate.pfx --httpsKeyStorePassword=Password12" EXPOSE 8083
Vous pouvez également modifier le port d'agent par défaut pour Jenkins en définissant JENKINS_SLAVE_AGENT_PORT dans un exemple de Dockerfile.
FROM jenkins/jenkins:lts-jdk17 ENV JENKINS_SLAVE_AGENT_PORT=50001
ou comme paramètre pour docker,
docker run --name myjenkins -p 8080:8080 -p 50001:50001 --restart=on-failure --env JENKINS_SLAVE_AGENT_PORT=50001 jenkins/jenkins:lts-jdk17
Remarque : Cette variable d'environnement sera utilisée pour définir la propriété système jenkins.model.Jenkins.slaveAgentPort .
Si cette propriété est déjà définie dans JAVA_OPTS ou JENKINS_JAVA_OPTS , alors la valeur de
JENKINS_SLAVE_AGENT_PORTsera ignorée.
Vous pouvez exécuter votre conteneur en tant que root - et l'installer via apt-get, l'installer dans le cadre des étapes de construction via les installateurs de l'outil Jenkins, ou vous pouvez créer votre propre Dockerfile à personnaliser, par exemple :
FROM jenkins/jenkins:lts-jdk17 # if we want to install via apt USER root RUN apt-get update && apt-get install -y ruby make more-thing-here # drop back to the regular jenkins user - good practice USER jenkins
Dans une telle image dérivée, vous pouvez personnaliser votre instance jenkins avec des scripts hook ou des plugins supplémentaires. À cette fin, utilisez /usr/share/jenkins/ref comme emplacement pour définir le contenu JENKINS_HOME par défaut auquel vous souhaitez que l'installation cible ressemble :
FROM jenkins/jenkins:lts-jdk17 COPY --chown=jenkins:jenkins custom.groovy /usr/share/jenkins/ref/init.groovy.d/custom.groovy
Vous pouvez compter sur la CLI du gestionnaire de plugins pour transmettre un ensemble de plugins à télécharger avec leurs dépendances. Cet outil effectuera des téléchargements à partir des centres de mise à jour et un accès Internet est requis pour les centres de mise à jour par défaut.
Lors du téléchargement, la CLI utilisera les centres de mise à jour définis par les variables d'environnement suivantes :
JENKINS_UC - Centre de mise à jour principal. Ce centre de mise à jour peut proposer des versions de plugins en fonction des versions de Jenkins LTS Core. Valeur par défaut : https://updates.jenkins.io
JENKINS_UC_EXPERIMENTAL - Centre de mise à jour expérimentale. Ce centre propose des versions Alpha et Beta de plugins. Valeur par défaut : https://updates.jenkins.io/experimental
JENKINS_INCREMENTALS_REPO_MIRROR - Définit le miroir Maven à utiliser pour télécharger des plugins à partir du référentiel Incrementals. Valeur par défaut : https://repo.jenkins-ci.org/incrementals
JENKINS_UC_DOWNLOAD - URL de téléchargement du centre de mise à jour. Valeur par défaut : $JENKINS_UC/download
JENKINS_PLUGIN_INFO - Emplacement des informations sur le plugin. Valeur par défaut : https://updates.jenkins.io/current/plugin-versions.json
Il est possible de remplacer les variables d'environnement dans les images.
❗ Notez que la modification des variables du centre de mise à jour ne modifiera pas le centre de mise à jour utilisé par le runtime Jenkins, cela concerne uniquement la CLI du gestionnaire de plugins.
L'installation de plugins prédéfinis et personnalisés peut être réalisée en copiant le fichier HPI du plugin dans /usr/share/jenkins/ref/plugins/ dans le Dockerfile :
COPY --chown=jenkins:jenkins path/to/custom.hpi /usr/share/jenkins/ref/plugins/
Vous pouvez exécuter la CLI manuellement dans Dockerfile :
DE jenkins/jenkins :lts-jdk17RUN jenkins-plugin-cli --plugins pipeline-model-definition github-branch-source :1.8
De plus il est possible de transmettre un fichier contenant cet ensemble de plugins (avec ou sans sauts de ligne).
FROM jenkins/jenkins:lts-jdk17COPY --chown=jenkins:jenkins plugins.txt /usr/share/jenkins/ref/plugins.txtRUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt
Lorsque le conteneur jenkins démarre, il vérifiera que JENKINS_HOME a ce contenu de référence et les copiera là-bas si nécessaire. Il ne remplacera pas ces fichiers, donc si vous avez mis à niveau certains plugins depuis l'interface utilisateur, ils ne seront pas rétablis au prochain démarrage.
Si vous souhaitez remplacer, ajoutez « .override » au nom du fichier de référence. Par exemple, un fichier nommé /usr/share/jenkins/ref/config.xml.override écrasera un fichier config.xml existant dans JENKINS_HOME.
Voir aussi JENKINS-24986
Voici un exemple pour obtenir la liste des plugins d'un serveur existant :
JENKINS_HOST=username:[email protected]:port curl -sSL "http://$JENKINS_HOST/pluginManager/api/xml?depth=1&xpath=/*/*/shortName|/*/*/version&wrapper=plugins" | perl -pe 's/.*?<shortName>([w-]+).*?<version>([^<]+)()(</w+>)+/1 2n/g'|sed 's/ /:/'
Exemple de sortie :
cucumber-testresult-plugin:0.8.2 pam-auth:1.1 matrix-project:1.4.1 script-security:1.13 ...
Pour les images dérivées de 2.x, vous souhaiterez peut-être également
RUN echo 2.0 > /usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state
pour indiquer que cette installation Jenkins est entièrement configurée. Sinon, une bannière apparaîtra invitant l'utilisateur à installer des plugins supplémentaires, ce qui peut s'avérer inapproprié.
Pour activer les journaux d'accès des utilisateurs Jenkins à partir du répertoire personnel de Jenkins dans un conteneur Docker, définissez la valeur de la variable d'environnement JENKINS_OPTS sur --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/jenkins_home/logs/access_log
La convention de dénomination des balises sur Docker Hub suit le format <repository_name>:<tag> , où le nom du référentiel est jenkins/jenkins et où la balise spécifie la version de l'image. Dans le cas des versions LTS et Latest, les balises sont respectivement lts et latest .
Vous pouvez utiliser ces balises pour extraire les images Jenkins correspondantes de Docker Hub et les exécuter sur votre système. Par exemple, pour extraire la version LTS de l'image Jenkins, utilisez cette commande : docker pull jenkins/jenkins:lts
Pour utiliser Docker Compose avec Jenkins, vous pouvez définir un fichier docker-compose.yml comprenant une instance Jenkins et tous les autres services dont elle dépend. Par exemple, le fichier docker-compose.yml suivant définit un contrôleur Jenkins et un agent SSH Jenkins :
services : jenkins :image : jenkins/jenkins :ltsports :
-Volumes "8080:8080":
- jenkins_home:/var/jenkins_home
ssh-agent:image : jenkins/ssh-agentvolumes : jenkins_home : Ce fichier docker-compose.yml crée deux conteneurs : un pour Jenkins et un pour l'agent Jenkins SSH.
Le conteneur Jenkins est basé sur l'image jenkins/jenkins:lts et expose l'interface Web Jenkins sur le port 8080. Le volume jenkins_home est un volume nommé créé et géré par Docker.
Il est monté dans /var/jenkins_home dans le conteneur Jenkins et conservera la configuration et les données Jenkins.
Le conteneur ssh-agent est basé sur l'image jenkins/ssh-agent et exécute un serveur SSH pour exécuter Jenkins SSH Build Agent.
Pour démarrer l'instance Jenkins et les autres services définis dans le fichier docker-compose.yml , exécutez le docker compose up -d .
Cela extraira les images nécessaires de Docker Hub si elles ne sont pas déjà présentes sur votre système et démarrera les services en arrière-plan.
Vous pouvez ensuite accéder à l'interface Web Jenkins sur http://localhost:8080 sur votre système hôte pour configurer et gérer votre instance Jenkins (où localhost pointe vers le port publié par votre moteur Docker).
REMARQUE : lisez la section Configuration DNS au cas où vous verriez le message « Cette instance Jenkins semble être hors ligne. » Dans ce cas, ajoutez la configuration DNS au yaml :
services : jenkins :# ... autres noms de configuration :
- 1.1.1.1 - 8.8.8.8# ... autre configurationL'outil plugin-installation-manager-tool prend en charge la mise à jour du fichier plugin pour vous.
Exemple de commande :
JENKINS_IMAGE=jenkins/jenkins:lts-jdk17
docker run -it ${JENKINS_IMAGE} bash -c "stty -onlcr && jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt --available-updates --output txt" > plugins2.txt
mv plugins2.txt plugins.txtToutes les données nécessaires se trouvent dans le répertoire /var/jenkins_home - donc selon la façon dont vous gérez cela - cela dépend de la façon dont vous effectuez la mise à niveau. Généralement - vous pouvez la copier - puis "docker extraire" à nouveau l'image - et vous aurez le dernier LTS - vous pouvez alors démarrer avec -v pointant vers ces données (/var/jenkins_home) et tout sera comme vous je l'ai laissé.
Comme toujours, assurez-vous de savoir comment piloter Docker, en particulier la gestion des volumes !
Si vous montez le répertoire personnel Jenkins sur un volume nommé Docker, la mise à niveau consiste en une docker pull et rien de plus.
Nous vous recommandons d'utiliser docker compose , en particulier dans les cas où l'utilisateur exécute également un conteneur nginx/apache parallèle en tant que proxy inverse pour le conteneur Jenkins.
Par défaut, les plugins seront mis à niveau s'ils ne l'ont pas été manuellement et si la version de l'image Docker est plus récente que la version dans le conteneur. Les versions installées par l'image Docker sont suivies via un fichier de marqueur.
Pour forcer les mises à niveau des plugins qui ont été mis à niveau manuellement, exécutez l'image Docker avec -e PLUGINS_FORCE_UPGRADE=true .
Le comportement par défaut lors de la mise à niveau à partir d'une image Docker qui n'a pas écrit de fichiers de marqueurs consiste à laisser les plugins existants en place. Si vous souhaitez mettre à niveau les plugins existants sans marqueur, vous pouvez exécuter l'image docker avec -e TRY_UPGRADE_IF_NO_MARKER=true . Ensuite, les plugins seront mis à niveau si la version fournie par l'image docker est plus récente.
Si vous souhaitez apporter des correctifs à ce référentiel, veuillez vous référer à la documentation dédiée.
Pour plus d'informations relatives à la sécurité de cette image Docker, veuillez vous référer à la documentation dédiée.
Nous sommes sur Gitter, https://gitter.im/jenkinsci/docker
