docker
2.486
Jenkins Continuous Integration and Delivery サーバーは Docker Hub で利用できます。
これは完全に機能する Jenkins サーバーです。 https://jenkins.io/。
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
注: 50000ポート マッピングの役割については、以下の「エージェントの接続」セクションをお読みください。注: 「この Jenkins インスタンスはオフラインのようです。」というメッセージが表示された場合は、 「DNS 構成」セクションをお読みください。
これにより、ワークスペースが/var/jenkins_homeに保存されます。プラグインや構成を含め、すべての Jenkins データがそこに存在します。おそらく、それを明示的なボリュームにして管理し、アップグレードのために別のコンテナに接続できるようにする必要があるでしょう。
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17
これにより、ホスト マシン上に「jenkins_home」Docker ボリュームが自動的に作成されます。 Docker ボリュームは、コンテナーが停止、開始、または削除された場合でも、そのコンテンツを保持します。
注: ホスト マシン上のフォルダーから/var/jenkins_homeへのバインド マウントの使用は避けてください。ファイル パーミッションの問題が発生する可能性があります (コンテナー内で使用されているユーザーがホスト マシン上のフォルダーに対する権限を持っていない可能性があります)。本当にマウント jenkins_home をバインドする必要がある場合は、コンテナー内の jenkins ユーザー (jenkins ユーザー - uid 1000) がホスト上のディレクトリにアクセスできることを確認するか、 docker runで-u some_other_userパラメーターを使用します。
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
これにより、ポート転送とボリュームが追加された分離モードで Jenkins が実行されます。最初のログイン トークンを確認するために、コマンド「docker logs CONTAINER_ID」を使用してログにアクセスできます。コンテナの ID は、上記のコマンドの出力から返されます。
ボリュームにマウントをバインドすると、いつでもそのディレクトリ (jenkins_home) を簡単にバックアップできます。
バインド マウントの使用は、権限の問題が発生する可能性があるため、お勧めできません。 jenkins_home ディレクトリをデータベースと同様に扱います。Docker では通常、データベースをボリュームに配置します。
ボリュームがコンテナー内にある場合、 docker cp $ID:/var/jenkins_homeコマンドを使用してデータを抽出するか、他のオプションを使用してボリューム データの場所を見つけることができます。一部の OS 上の一部のシンボリックリンクはコピーに変換される場合があることに注意してください (これにより、jenkins と lastStableBuild リンクなどを混同する可能性があります)
詳細については、ボリュームの使用に関する Docker ドキュメントのセクションを確認してください。
Groovy スクリプトを使用して、Jenkins 組み込みノード上のエグゼキュータの数を定義できます。デフォルトでは、2 つのエグゼキュータに設定されていますが、イメージを拡張して、希望するエグゼキュータ数に変更できます (組み込みノードでは 0 のエグゼキュータを推奨)。
executors.groovy
import jenkins.model.* Jenkins.instance.setNumExecutors(0) // Recommended to not run builds on the built-in node
とDockerfile
FROM jenkins/jenkins:lts COPY --chown=jenkins:jenkins executors.groovy /usr/share/jenkins/ref/init.groovy.d/executors.groovy
すぐにコントローラー上でビルドを実行できます。 Jenkins プロジェクトでは、コントローラー上でエグゼキューターを有効にしないことを推奨しています。
インバウンド TCP 接続を介してエージェントに接続するには、ポートをマップします: -p 50000:50000 。このポートは、エージェントをコントローラに接続するときに使用されます。
SSH (アウトバウンド) ビルド エージェントのみを使用している場合は、コントローラーから接続が確立されるため、このポートは必要ありません。 Web ソケット (Jenkins 2.217 以降) を使用してエージェントに接続する場合、TCP エージェント ポートも使用されません。
通常、システム プロパティを調整したり、ヒープ メモリ設定を微調整したりするために、Jenkins を実行している JVM のカスタマイズが必要になる場合があります。この目的には、 JAVA_OPTSまたは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
他のツールもJAVA_OPTS環境変数に応答する可能性があるため、Jenkins コントローラー専用の JVM オプションはJENKINS_JAVA_OPTSを通じて設定する必要があります。
Jenkins のログ記録は、プロパティ ファイルおよびjava.util.logging.config.file Java プロパティを通じて構成できます。例えば：
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
プレフィックス付きのリバース プロキシ (例: mysite.com/jenkins) の背後に Jenkins をインストールする場合は、環境変数JENKINS_OPTS="--prefix=/jenkins"を追加し、次の手順に従ってリバース プロキシを構成する必要があります。 Apache と Nginx のどちらを使用しているかによって異なります。
アパッチ
Nginx
「この Jenkins インスタンスはオフラインのようです。」というメッセージが表示された場合は、最初の起動時に が表示され、コンテナー ログにjava.net.UnknownHostException: updates.jenkins.ioなどの行が表示される場合、コンテナーで DNS 名の解決に問題が発生している可能性があります。
この問題を解決するには、DNS サーバー (たとえば、Cloudflare の 1.1.1.1、Google の 8.8.8.8、またはその他の 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
Jenkins イメージを実行している docker に渡す引数は jenkins ランチャーに渡されるため、たとえば次のコマンドを実行できます。
docker run jenkins/jenkins:lts-jdk17 --version
これにより、実行可能ファイル war から Jenkins を実行する場合と同様に、Jenkins のバージョンが表示されます。
JENKINS_OPTSを介して Jenkins 引数を定義することもできます。これは、派生 Jenkins イメージ内の jenkins ランチャーへの引数をカスタマイズする場合に役立ちます。次のサンプル Dockerfile では、このオプションを使用して、イメージに含まれる証明書で HTTPS の使用を強制します。
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
サンプル Dockerfile でJENKINS_SLAVE_AGENT_PORT定義することで、Jenkins のデフォルトのエージェント ポートを変更することもできます。
FROM jenkins/jenkins:lts-jdk17 ENV JENKINS_SLAVE_AGENT_PORT=50001
または docker へのパラメータとして、
docker run --name myjenkins -p 8080:8080 -p 50001:50001 --restart=on-failure --env JENKINS_SLAVE_AGENT_PORT=50001 jenkins/jenkins:lts-jdk17
注: この環境変数は、システム プロパティjenkins.model.Jenkins.slaveAgentPortを設定するために使用されます。
このプロパティがすでにJAVA_OPTSまたはJENKINS_JAVA_OPTSに設定されている場合、
JENKINS_SLAVE_AGENT_PORTの値は無視されます。
コンテナーを root として実行し、apt-get 経由でインストールしたり、jenkins ツール インストーラー経由でビルド ステップの一部としてインストールしたり、独自の Dockerfile を作成してカスタマイズしたりできます。
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
このような派生イメージでは、フック スクリプトや追加のプラグインを使用して jenkins インスタンスをカスタマイズできます。この目的のために、ターゲット インストールを次のようにするデフォルトの JENKINS_HOME コンテンツを定義する場所として/usr/share/jenkins/refを使用します。
FROM jenkins/jenkins:lts-jdk17 COPY --chown=jenkins:jenkins custom.groovy /usr/share/jenkins/ref/init.groovy.d/custom.groovy
プラグイン マネージャー CLI を利用して、依存関係とともにダウンロードするプラグインのセットを渡すことができます。このツールはアップデート センターからのダウンロードを実行します。デフォルトのアップデート センターにはインターネット アクセスが必要です。
ダウンロード中、CLI は次の環境変数で定義されたアップデート センターを使用します。
JENKINS_UC - メインのアップデート センター。このアップデート センターでは、Jenkins LTS Core のバージョンに応じてプラグインのバージョンが提供される場合があります。デフォルト値: https://updates.jenkins.io
JENKINS_UC_EXPERIMENTAL - 実験的なアップデート センター。このセンターでは、プラグインのアルファ版とベータ版を提供します。デフォルト値: https://updates.jenkins.io/experimental
JENKINS_INCREMENTALS_REPO_MIRROR - Incrementals リポジトリからプラグインをダウンロードするために使用する Maven ミラーを定義します。デフォルト値: https://repo.jenkins-ci.org/incrementals
JENKINS_UC_DOWNLOAD - アップデート センターのダウンロード URL。デフォルト値: $JENKINS_UC/download
JENKINS_PLUGIN_INFO - プラグイン情報の場所。デフォルト値: https://updates.jenkins.io/current/plugin-versions.json
イメージ内の環境変数をオーバーライドすることができます。
❗ アップデート センター変数を変更しても、Jenkins ランタイムによって使用されるアップデート センターは変更されないことに注意してください。これは、プラグイン マネージャー CLI のみに関係します。
事前に構築されたカスタム プラグインをインストールするには、プラグイン HPI ファイルをDockerfile内の/usr/share/jenkins/ref/plugins/にコピーします。
COPY --chown=jenkins:jenkins path/to/custom.hpi /usr/share/jenkins/ref/plugins/
Dockerfile で CLI を手動で実行できます。
Jenkins/jenkins:lts-jdk17RUN から jenkins-plugin-cli --plugins パイプライン モデル定義 github-branch-source:1.8
さらに、このプラグインのセットを含むファイルを (改行の有無にかかわらず) 渡すことができます。
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
jenkins コンテナーが起動すると、 JENKINS_HOMEこの参照コンテンツがあるかどうかが確認され、必要に応じてそこにコピーされます。このようなファイルはオーバーライドされないため、UI から一部のプラグインをアップグレードした場合、それらは次回の起動時に元に戻されません。
オーバーライドする場合は、参照ファイルの名前に「.override」を追加します。たとえば、 /usr/share/jenkins/ref/config.xml.override ref/config.xml.override という名前のファイルは、JENKINS_HOME 内の既存のconfig.xmlファイルを上書きします。
JENKINS-24986 も参照してください。
既存のサーバーからプラグインのリストを取得する例を次に示します。
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/ /:/'
出力例:
cucumber-testresult-plugin:0.8.2 pam-auth:1.1 matrix-project:1.4.1 script-security:1.13 ...
2.x 派生イメージの場合は、次のことも行うことができます。
RUN echo 2.0 > /usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state
この Jenkins インストールが完全に構成されていることを示します。そうしないと、ユーザーに追加のプラグインをインストールするよう求めるバナーが表示されますが、これは不適切である可能性があります。
Docker コンテナ内の Jenkins ホーム ディレクトリからの Jenkins ユーザー アクセス ログを有効にするには、 JENKINS_OPTS環境変数の値を--accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/jenkins_home/logs/access_logに設定します。 --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/jenkins_home/logs/access_log
Docker Hub のタグの命名規則は<repository_name>:<tag>の形式に従います。リポジトリ名は jenkins/jenkins で、タグはイメージ バージョンを指定します。 LTS および最新バージョンの場合、タグはそれぞれltsおよびlatestです。
これらのタグを使用して、対応する Jenkins イメージを Docker Hub から取得し、システム上で実行できます。たとえば、LTS バージョンの Jenkins イメージをプルするには、次のコマンドを使用します: docker pull jenkins/jenkins:lts
Jenkins で Docker Compose を使用するには、Jenkins インスタンスとそれが依存する他のサービスを含む docker-compose.yml ファイルを定義できます。たとえば、次の docker-compose.yml ファイルは、Jenkins コントローラーと Jenkins SSH エージェントを定義します。
サービス: jenkins:image: jenkins/jenkins:ltsports:
- 「8080:8080」ボリューム:
- jenkins_home:/var/jenkins_home
ssh-agent:image: jenkins/ssh-agentvolumes: jenkins_home:このdocker-compose.ymlファイルは、Jenkins 用と Jenkins SSH エージェント用の 2 つのコンテナを作成します。
Jenkins コンテナーはjenkins/jenkins:ltsイメージに基づいており、ポート 8080 で Jenkins Web インターフェイスを公開します。 jenkins_homeボリュームは、Docker によって作成および管理される名前付きボリュームです。
これは Jenkins コンテナーの/var/jenkins_homeにマウントされ、Jenkins の構成とデータを永続化します。
ssh-agent コンテナはjenkins/ssh-agentイメージに基づいており、SSH サーバーを実行して Jenkins SSH Build Agent を実行します。
Jenkins インスタンスとdocker-compose.ymlファイルで定義されている他のサービスを開始するには、 docker compose up -dを実行します。
これにより、必要なイメージがシステム上に存在しない場合は Docker Hub から取得され、バックグラウンドでサービスが開始されます。
その後、ホスト システム上のhttp://localhost:8080にある Jenkins Web インターフェイスにアクセスして、Jenkins インスタンスを構成および管理できます ( localhost Docker エンジンによって公開されたポートを指します)。
注: 「この Jenkins インスタンスはオフラインのようです。」というメッセージが表示された場合は、 「DNS 構成」セクションをお読みください。その場合は、DNS 構成を yaml に追加します。
サービス: jenkins:# ... その他の configdns:
- 1.1.1.1 - 8.8.8.8# ... その他の構成plugin-installation-manager-tool は、プラグイン ファイルの更新をサポートします。
コマンド例:
JENKINS_IMAGE=ジェンキンス/ジェンキンス: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 プラグイン 2.txt プラグイン.txt必要なデータはすべて /var/jenkins_home ディレクトリにあるため、その管理方法に応じて、アップグレード方法によって異なります。一般に、それをコピーして、イメージを再度「docker pull」すると、最新の LTS が得られます。その後、そのデータ (/var/jenkins_home) を指す -v で起動すると、すべてがそのままになります。残しました。
いつものように、Docker の操作方法、特にボリュームの処理方法を必ず理解してください。
Jenkins ホーム ディレクトリを Docker という名前のボリュームにマウントする場合、アップグレードはdocker pullのみで構成されます。
特にユーザーが Jenkins コンテナーのリバース プロキシとして並列 nginx/Apache コンテナーも実行している場合は、 docker compose使用することをお勧めします。
デフォルトでは、プラグインが手動でアップグレードされていない場合、および Docker イメージのバージョンがコンテナ内のバージョンより新しい場合、プラグインはアップグレードされます。 Docker イメージによってインストールされたバージョンは、マーカー ファイルを通じて追跡されます。
手動でアップグレードされたプラグインを強制的にアップグレードするには、 -e PLUGINS_FORCE_UPGRADE=trueを指定して Docker イメージを実行します。
マーカー ファイルを書き込まない Docker イメージからアップグレードする場合のデフォルトの動作では、既存のプラグインをそのまま残します。マーカーを使用せずに既存のプラグインをアップグレードする場合は-e TRY_UPGRADE_IF_NO_MARKER=trueを指定して Docker イメージを実行できます。 Docker イメージによって提供されるバージョンが新しい場合、プラグインはアップグレードされます。
このリポジトリに修正を提供したい場合は、専用のドキュメントを参照してください。
この Docker イメージのセキュリティに関する情報については、専用のドキュメントを参照してください。
私たちは Gitter を使用しています (https://gitter.im/jenkinsci/docker)
