docker
2.486
Der Jenkins Continuous Integration and Delivery-Server ist auf Docker Hub verfügbar.
Dies ist ein voll funktionsfähiger Jenkins-Server. https://jenkins.io/.
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
HINWEIS: Lesen Sie den Abschnitt „Verbinden von Agenten“ unten für die Rolle der 50000 -Port-Zuordnung. HINWEIS: Lesen Sie den Abschnitt „DNS-Konfiguration“ , falls die Meldung „Diese Jenkins-Instanz scheint offline zu sein“ angezeigt wird.
Dadurch wird der Arbeitsbereich in /var/jenkins_home gespeichert. Dort sind alle Jenkins-Daten gespeichert – einschließlich Plugins und Konfiguration. Wahrscheinlich möchten Sie daraus ein explizites Volume machen, damit Sie es verwalten und für Upgrades an einen anderen Container anhängen können:
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17
Dadurch wird automatisch ein Docker-Volume „jenkins_home“ auf dem Host-Computer erstellt. Docker-Volumes behalten ihren Inhalt auch dann, wenn der Container gestoppt, gestartet oder gelöscht wird.
HINWEIS: Vermeiden Sie die Verwendung eines Bind-Mounts von einem Ordner auf dem Host-Computer in /var/jenkins_home , da dies zu Problemen mit der Dateiberechtigung führen kann (der im Container verwendete Benutzer hat möglicherweise keine Rechte für den Ordner auf dem Host-Computer). Wenn Sie den Mount jenkins_home wirklich binden müssen, stellen Sie sicher, dass der Jenkins-Benutzer im Container auf das Verzeichnis auf dem Host zugreifen kann (Jenkins-Benutzer – UID 1000), oder verwenden Sie den Parameter -u some_other_user mit docker run .
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
Dadurch wird Jenkins im getrennten Modus mit hinzugefügter Portweiterleitung und Volumen ausgeführt. Sie können mit dem Befehl „docker logs CONTAINER_ID“ auf Protokolle zugreifen, um das erste Anmeldetoken zu überprüfen. Die ID des Containers wird aus der Ausgabe des obigen Befehls zurückgegeben.
Wenn Sie mount in einem Volume binden, können Sie dieses Verzeichnis (jenkins_home) jederzeit einfach sichern.
Die Verwendung eines Bind-Mounts wird nicht empfohlen, da dies zu Berechtigungsproblemen führen kann. Behandeln Sie das Verzeichnis jenkins_home wie eine Datenbank – in Docker würden Sie eine Datenbank im Allgemeinen auf einem Volume ablegen.
Wenn sich Ihr Volume in einem Container befindet, können Sie den Befehl docker cp $ID:/var/jenkins_home verwenden, um die Daten zu extrahieren, oder andere Optionen verwenden, um herauszufinden, wo sich die Volume-Daten befinden. Beachten Sie, dass einige Symlinks auf einigen Betriebssystemen möglicherweise in Kopien umgewandelt werden (dies kann zu einer Verwechslung von Jenkins mit lastStableBuild-Links usw. führen).
Weitere Informationen finden Sie im Abschnitt „Volumes verwenden“ in der Docker-Dokumentation
Sie können die Anzahl der Executoren auf dem integrierten Jenkins-Knoten mithilfe eines Groovy-Skripts definieren. Standardmäßig ist es auf 2 Executoren eingestellt, aber Sie können das Image erweitern und auf die gewünschte Anzahl von Executoren ändern (empfohlen 0 Executoren auf dem integrierten Knoten):
executors.groovy
import jenkins.model.* Jenkins.instance.setNumExecutors(0) // Recommended to not run builds on the built-in node
und Dockerfile
FROM jenkins/jenkins:lts COPY --chown=jenkins:jenkins executors.groovy /usr/share/jenkins/ref/init.groovy.d/executors.groovy
Sie können Builds sofort auf dem Controller ausführen. Das Jenkins-Projekt empfiehlt, keine Executoren auf dem Controller zu aktivieren.
Um Agenten über eine eingehende TCP-Verbindung zu verbinden, ordnen Sie den Port zu: -p 50000:50000 . Dieser Port wird verwendet, wenn Sie Agenten mit dem Controller verbinden.
Wenn Sie nur SSH-Build-Agenten (ausgehend) verwenden, ist dieser Port nicht erforderlich, da Verbindungen vom Controller aus hergestellt werden. Wenn Sie Agenten über Web-Sockets verbinden (seit Jenkins 2.217), wird der TCP-Agent-Port ebenfalls nicht verwendet.
Möglicherweise müssen Sie die JVM, auf der Jenkins ausgeführt wird, anpassen, normalerweise um Systemeigenschaften anzupassen oder Heap-Speichereinstellungen zu optimieren. Verwenden Sie zu diesem Zweck die Umgebungsvariablen JAVA_OPTS oder 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
JVM-Optionen speziell für den Jenkins-Controller sollten über JENKINS_JAVA_OPTS festgelegt werden, da andere Tools möglicherweise auch auf die Umgebungsvariable JAVA_OPTS reagieren.
Die Jenkins-Protokollierung kann über eine Eigenschaftendatei und die Java-Eigenschaft java.util.logging.config.file konfiguriert werden. Zum Beispiel:
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
Wenn Sie Jenkins hinter einem Reverse-Proxy mit einem Präfix installieren möchten, Beispiel: mysite.com/jenkins, müssen Sie die Umgebungsvariable JENKINS_OPTS="--prefix=/jenkins" hinzufügen und dann die folgenden Verfahren befolgen, um Ihren Reverse-Proxy zu konfigurieren. Das hängt davon ab, ob Sie Apache oder Nginx haben:
Apache
Nginx
Wenn die Meldung „Diese Jenkins-Instanz scheint offline zu sein.“ Beim ersten Start erscheint und in den Containerprotokollen Zeilen wie java.net.UnknownHostException: updates.jenkins.io angezeigt werden, hat Ihr Container möglicherweise Probleme mit der Auflösung von DNS-Namen.
Um das Problem möglicherweise zu lösen, starten Sie den Container und geben Sie einen DNS-Server an (z. B. 1.1.1.1 von Cloudflare oder 8.8.8.8 von Google oder einen anderen DNS-Server):
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
Argumente, die Sie an den Docker übergeben, der das Jenkins-Image ausführt, werden an den Jenkins-Launcher übergeben, sodass Sie beispielsweise Folgendes ausführen können:
docker run jenkins/jenkins:lts-jdk17 --version
Dadurch wird die Jenkins-Version angezeigt, genauso wie wenn Sie Jenkins aus einer ausführbaren Datei ausführen.
Sie können Jenkins-Argumente auch über JENKINS_OPTS definieren. Dies ist nützlich, um Argumente für den Jenkins-Launcher in einem abgeleiteten Jenkins-Image anzupassen. Die folgende Beispiel-Dockerdatei verwendet diese Option, um die Verwendung von HTTPS mit einem im Image enthaltenen Zertifikat zu erzwingen.
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
Sie können den Standard-Agent-Port für Jenkins auch ändern, indem Sie JENKINS_SLAVE_AGENT_PORT in einer Beispiel-Dockerdatei definieren.
FROM jenkins/jenkins:lts-jdk17 ENV JENKINS_SLAVE_AGENT_PORT=50001
oder als Parameter für Docker,
docker run --name myjenkins -p 8080:8080 -p 50001:50001 --restart=on-failure --env JENKINS_SLAVE_AGENT_PORT=50001 jenkins/jenkins:lts-jdk17
Hinweis : Diese Umgebungsvariable wird verwendet, um die Systemeigenschaft jenkins.model.Jenkins.slaveAgentPort festzulegen.
Wenn diese Eigenschaft bereits in JAVA_OPTS oder JENKINS_JAVA_OPTS festgelegt ist, wird der Wert von
JENKINS_SLAVE_AGENT_PORTignoriert.
Sie können Ihren Container als Root ausführen und über apt-get installieren, als Teil der Build-Schritte über Jenkins-Tool-Installer installieren oder Ihre eigene Docker-Datei zur Anpassung erstellen, zum Beispiel:
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
In einem solchen abgeleiteten Image können Sie Ihre Jenkins-Instanz mit Hook-Skripten oder zusätzlichen Plugins anpassen. Verwenden Sie zu diesem Zweck /usr/share/jenkins/ref als Ort, um den standardmäßigen JENKINS_HOME-Inhalt zu definieren, wie die Zielinstallation aussehen soll:
FROM jenkins/jenkins:lts-jdk17 COPY --chown=jenkins:jenkins custom.groovy /usr/share/jenkins/ref/init.groovy.d/custom.groovy
Sie können sich darauf verlassen, dass die Plugin-Manager-CLI eine Reihe von Plugins zum Herunterladen mit ihren Abhängigkeiten übergibt. Dieses Tool führt Downloads von Update-Centern durch und für die Standard-Update-Center ist ein Internetzugang erforderlich.
Während des Downloads verwendet die CLI Update-Center, die durch die folgenden Umgebungsvariablen definiert sind:
JENKINS_UC – Haupt-Update-Center. Abhängig von den Jenkins LTS Core-Versionen bietet dieses Update-Center möglicherweise Plugin-Versionen an. Standardwert: https://updates.jenkins.io
JENKINS_UC_EXPERIMENTAL – Experimentelles Update-Center. Dieses Zentrum bietet Alpha- und Beta-Versionen von Plugins an. Standardwert: https://updates.jenkins.io/experimental
JENKINS_INCREMENTALS_REPO_MIRROR – Definiert den Maven-Spiegel, der zum Herunterladen von Plugins aus dem Incrementals-Repository verwendet werden soll. Standardwert: https://repo.jenkins-ci.org/incrementals
JENKINS_UC_DOWNLOAD – Download-URL des Update Centers. Standardwert: $JENKINS_UC/download
JENKINS_PLUGIN_INFO – Speicherort der Plugin-Informationen. Standardwert: https://updates.jenkins.io/current/plugin-versions.json
Es ist möglich, die Umgebungsvariablen in Bildern zu überschreiben.
❗ Beachten Sie, dass sich durch das Ändern der Update-Center-Variablen nicht das von der Jenkins-Laufzeit verwendete Update Center ändert, sondern nur die Plugin-Manager-CLI betrifft.
Die Installation vorgefertigter, benutzerdefinierter Plugins kann durch Kopieren der Plugin-HPI-Datei nach /usr/share/jenkins/ref/plugins/ innerhalb der Dockerfile erfolgen:
COPY --chown=jenkins:jenkins path/to/custom.hpi /usr/share/jenkins/ref/plugins/
Sie können die CLI manuell in Dockerfile ausführen:
VON jenkins/jenkins:lts-jdk17RUN jenkins-plugin-cli --pluginspipeline-model-definition github-branch-source:1.8
Darüber hinaus ist es möglich, eine Datei zu übergeben, die diese Plugins enthält (mit oder ohne Zeilenumbrüche).
VON jenkins/jenkins:lts-jdk17COPY --chown=jenkins:jenkinsplugins.txt /usr/share/jenkins/ref/plugins.txtRUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt
Wenn der Jenkins-Container gestartet wird, prüft er, ob JENKINS_HOME über diesen Referenzinhalt verfügt, und kopiert ihn bei Bedarf dorthin. Solche Dateien werden nicht überschrieben. Wenn Sie also einige Plugins über die Benutzeroberfläche aktualisiert haben, werden sie beim nächsten Start nicht zurückgesetzt.
Falls Sie die Datei überschreiben möchten , hängen Sie „.override“ an den Namen der Referenzdatei an. Beispielsweise überschreibt eine Datei mit dem Namen /usr/share/jenkins/ref/config.xml.override eine vorhandene config.xml Datei in JENKINS_HOME.
Siehe auch JENKINS-24986
Hier ist ein Beispiel, um die Liste der Plugins von einem vorhandenen Server abzurufen:
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/ /:/'
Beispielausgabe:
cucumber-testresult-plugin:0.8.2 pam-auth:1.1 matrix-project:1.4.1 script-security:1.13 ...
Für 2.x-abgeleitete Bilder möchten Sie möglicherweise auch
RUN echo 2.0 > /usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state
um anzuzeigen, dass diese Jenkins-Installation vollständig konfiguriert ist. Andernfalls erscheint ein Banner, das den Benutzer auffordert, zusätzliche Plugins zu installieren, was möglicherweise unangemessen ist.
Um Jenkins-Benutzerzugriffsprotokolle aus dem Jenkins-Home-Verzeichnis in einem Docker-Container zu aktivieren, legen Sie den Wert der Umgebungsvariablen JENKINS_OPTS auf --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/jenkins_home/logs/access_log
Die Namenskonvention für die Tags auf Docker Hub folgt dem Format <repository_name>:<tag> , wobei der Repository-Name jenkins/jenkins lautet und das Tag die Image-Version angibt. Im Fall der LTS-Version und der neuesten Version lauten die Tags lts bzw. latest .
Mit diesen Tags können Sie die entsprechenden Jenkins-Images vom Docker Hub abrufen und auf Ihrem System ausführen. Um beispielsweise die LTS-Version des Jenkins-Images abzurufen, verwenden Sie diesen Befehl: docker pull jenkins/jenkins:lts
Um Docker Compose mit Jenkins zu verwenden, können Sie eine docker-compose.yml-Datei definieren, die eine Jenkins-Instanz und alle anderen Dienste enthält, von denen sie abhängt. Die folgende docker-compose.yml-Datei definiert beispielsweise einen Jenkins-Controller und einen Jenkins-SSH-Agenten:
Dienstleistungen: jenkins:image: jenkins/jenkins:ltsports:
- „8080:8080“-Volumen:
- jenkins_home:/var/jenkins_home
ssh-agent:image: jenkins/ssh-agentvolumes: jenkins_home: Diese docker-compose.yml Datei erstellt zwei Container: einen für Jenkins und einen für den Jenkins-SSH-Agenten.
Der Jenkins-Container basiert auf dem Image jenkins/jenkins:lts und stellt die Jenkins-Webschnittstelle auf Port 8080 bereit. Das jenkins_home -Volume ist ein benanntes Volume, das von Docker erstellt und verwaltet wird.
Es wird unter /var/jenkins_home im Jenkins-Container gemountet und behält die Jenkins-Konfiguration und -Daten bei.
Der SSH-Agent-Container basiert auf dem jenkins/ssh-agent Image und führt einen SSH-Server aus, um den Jenkins SSH Build Agent auszuführen.
Um die Jenkins-Instanz und die anderen in der Datei docker-compose.yml definierten Dienste zu starten, führen Sie docker compose up -d aus.
Dadurch werden die erforderlichen Bilder vom Docker Hub abgerufen, sofern diese noch nicht auf Ihrem System vorhanden sind, und die Dienste werden im Hintergrund gestartet.
Sie können dann auf die Jenkins-Weboberfläche unter http://localhost:8080 auf Ihrem Hostsystem zugreifen, um Ihre Jenkins-Instanz zu konfigurieren und zu verwalten (wobei localhost auf den von Ihrer Docker Engine veröffentlichten Port verweist).
HINWEIS: Lesen Sie den Abschnitt „DNS-Konfiguration“ , falls die Meldung „Diese Jenkins-Instanz scheint offline zu sein“ angezeigt wird. Fügen Sie in diesem Fall die DNS-Konfiguration zum Yaml hinzu:
Dienste: Jenkins:# ... andere Konfigurationsdaten:
- 1.1.1.1 - 8.8.8.8# ... andere KonfigurationDas Plugin-Installations-Manager-Tool unterstützt die Aktualisierung der Plugin-Datei für Sie.
Beispielbefehl:
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.txtAlle benötigten Daten befinden sich im Verzeichnis /var/jenkins_home – je nachdem, wie Sie das verwalten, hängt es also davon ab, wie Sie ein Upgrade durchführen. Im Allgemeinen können Sie es herauskopieren und dann das Image erneut per „Docker Pull“ abrufen – und Sie erhalten das neueste LTS – Sie können dann mit -v beginnen, das auf diese Daten zeigt (/var/jenkins_home), und alles wird so sein, wie Sie es möchten habe es gelassen.
Wie immer – stellen Sie bitte sicher, dass Sie wissen, wie man Docker steuert – insbesondere mit der Handhabung von Volumes!
Wenn Sie das Jenkins-Home-Verzeichnis auf einem Docker-Volume mit dem Namen mounten, besteht das Upgrade aus docker pull und nichts weiter.
Wir empfehlen die Verwendung von docker compose , insbesondere in Fällen, in denen der Benutzer auch einen parallelen Nginx/Apache-Container als Reverse-Proxy für den Jenkins-Container ausführt.
Standardmäßig werden Plugins aktualisiert, wenn sie nicht manuell aktualisiert wurden und wenn die Version aus dem Docker-Image neuer als die Version im Container ist. Vom Docker-Image installierte Versionen werden über eine Markierungsdatei verfolgt.
Um Upgrades von Plugins zu erzwingen, die manuell aktualisiert wurden, führen Sie das Docker-Image mit -e PLUGINS_FORCE_UPGRADE=true aus.
Das Standardverhalten beim Upgrade von einem Docker-Image, das keine Markierungsdateien geschrieben hat, besteht darin, vorhandene Plugins an Ort und Stelle zu belassen. Wenn Sie vorhandene Plugins ohne Markierung aktualisieren möchten, können Sie das Docker-Image mit -e TRY_UPGRADE_IF_NO_MARKER=true ausführen. Dann werden Plugins aktualisiert, wenn die vom Docker-Image bereitgestellte Version neuer ist.
Wenn Sie Korrekturen zu diesem Repository beitragen möchten, lesen Sie bitte die entsprechende Dokumentation.
Informationen zur Sicherheit dieses Docker-Images finden Sie in der entsprechenden Dokumentation.
Wir sind auf Gitter, https://gitter.im/jenkinsci/docker
