12.2. Jenkins イメージの設定
OpenShift Container Platform には、Jenkins 実行用のコンテナーイメージがあります。このイメージには Jenkins サーバーインスタンスが含まれており、このインスタンスを使用して継続的なテスト、統合、デリバリーの基本フローを設定することができます。
イメージは、Red Hat Universal Base Images (UBI) に基づいています。
OpenShift Container Platform は、Jenkins の LTS リリースに従います。OpenShift Container Platform は、Jenkins 2.x を含むイメージを提供します。
OpenShift Container Platform Jenkins イメージは Quay.io または registry.redhat.io で利用できます。
以下に例を示します。
$ podman pull registry.redhat.io/openshift4/ose-jenkins:<v4.3.0>
これらのイメージを使用するには、これらのレジストリーから直接アクセスするか、これらを OpenShift Container Platform コンテナーイメージレジストリーにプッシュできます。さらに、コンテナーイメージレジストリーまたは外部の場所で、対象イメージを参照するイメージストリームを作成することもできます。その後、OpenShift Container Platform リソースがイメージストリームを参照できます。
ただし便宜上、OpenShift Container Platform はコア Jenkins イメージの openshift
namespace にイメージストリームを提供するほか、OpenShift Container Platform を Jenkins と統合するために提供されるエージェントイメージのサンプルも提供します。
12.2.1. 設定とカスタマイズ
Jenkins 認証は、以下の 2 つの方法で管理できます。
- OpenShift Container Platform ログインプラグインが提供する OpenShift Container Platform OAuth 認証
- Jenkins が提供する標準認証。
12.2.1.1. OpenShift Container Platform OAuth 認証
OAuth 認証は、Jenkins UI の Configure Global Security パネルでオプションを設定するか、Jenkins デプロイメント設定の OPENSHIFT_ENABLE_OAUTH
環境変数を false
以外に設定して、有効にします。これにより、OpenShift Container Platform ログインプラグインが有効になり、Pod データからか、または OpenShift Container Platform API サーバーと対話して設定情報を取得します。
有効な認証情報は、OpenShift Container Platform アイデンティティープロバイダーが制御します。
Jenkins はブラウザーおよびブラウザー以外のアクセスの両方をサポートします。
OpenShift Container Platform ロールでユーザーに割り当てられる固有の Jenkins パーミッションが指定されている場合、有効なユーザーは、ログイン時に自動的に Jenkins 認証マトリックスに追加されます。デフォルトで使用されるロールは、事前に定義される admin
、edit
、および view
です。ログインプラグインは、Jenkins が実行されているプロジェクトまたは namespace のそれらのロールに対して自己 SAR 要求 (self-SAR request) を実行します。
admin
ロールを持つユーザーには、従来の Jenkins 管理ユーザーパーミッションがあります。ユーザーのパーミッションは、ロールが edit
、view
になるほど少なくなります。
OpenShift Container Platform のデフォルトの admin
、edit
、view
のロール、これらのロールが Jenkins インスタンスに割り当てられている Jenkins パーミッションは設定可能です。
OpenShift Container Platform Pod で Jenkins を実行する場合、ログインプラグインは Jenkins が実行されている namespace で openshift-jenkins-login-plugin-config
という名前の設定マップを検索します。
このプラグインが検出し、その設定マップで読み取り可能な場合には、ロールを Jenkins パーミッションマッピングに定義できます。具体的には以下を実行します。
- ログインプラグインは、設定マップのキーと値のペアを OpenShift Container Platform のロールのマッピングに対する Jenkins パーミッションとして処理します。
- キーは Jenkins パーミッショングループの短い ID と Jenkins パーミッションの短い ID で、この 2 つはハイフンで区切られています。
-
OpenShift Container Platform ロールに
Overall Jenkins Administer
パーミッションを追加する場合は、キーはOverall-Administer
である必要があります。 - パーミッショングループおよびパーミッション ID が利用可能であるかどうかを把握するには、Jenkins コンソールのマトリックス認証ページに移動し、グループの ID とグループが提供するテーブルの個々のパーミッションを確認します。
- キーと値ペアの値は、パーミッションが適用される必要がある OpenShift Container Platform ロールの一覧で、各ロールはコンマで区切られています。
-
Overall Jenkins Administer
パーミッションをデフォルトのadmin
およびedit
ロールの両方に追加し、作成した新規の jenkins ロールも追加する場合は、キーのOverall-Administer
の値はadmin,edit,jenkins
になります。
OpenShift Container Platform OAuth が使用されている場合、管理者権限で OpenShift Container Platform Jenkins イメージに事前に設定されている admin
ユーザーには、これらの権限は割り当てられません。これらのパーミッションを付与するには、OpenShift Container Platform クラスター管理者は OpenShift Container Platform アイデンティティープロバイダーでそのユーザーを明示的に定義し、admin
ロールをユーザーに割り当てる必要があります。
保存される Jenkins ユーザーのパーミッションは、初回のユーザー作成後に変更できます。OpenShift Container Platform ログインプラグインは、OpenShift Container Platform API サーバーをポーリングしてパーミッションを取得し、ユーザーごとに Jenkins に保存されているパーミッションを、OpenShift Container Platform から取得したパーミッションに更新します。Jenkins UI を使用して Jenkins ユーザーのパーミッションを更新する場合には、プラグインが次回に OpenShift Container Platform をポーリングするタイミングで、パーミッションの変更が上書きされます。
ポーリングの頻度は OPENSHIFT_PERMISSIONS_POLL_INTERVAL
環境変数で制御できます。デフォルトのポーリングの間隔は 5 分です。
OAuth 認証を使用して新しい Jenkins サービスを作成するには、テンプレートを使用するのが最も簡単な方法です。
12.2.1.2. Jenkins 認証
テンプレートを使用せず、イメージが直接実行される場合には、デフォルトで Jenkins 認証が使用されます。
Jenkins の初回起動時には、設定、管理ユーザーおよびパスワードが作成されます。デフォルトのユーザー認証情報は、admin
と password
です。標準の Jenkins 認証を使用する場合のみ、JENKINS_PASSWORD
環境変数を設定してデフォルトのパスワードを設定します。
手順
標準の Jenkins 認証を使用する Jenkins アプリケーションを作成します。
$ oc new-app -e \ JENKINS_PASSWORD=<password> \ openshift4/ose-jenkins
12.2.2. Jenkins 環境変数
Jenkins サーバーは、以下の環境変数で設定できます。
変数 | 定義 | 値と設定の例 |
---|---|---|
|
Jenkins へのログイン時に OpenShift Container Platform ログインプラグインが認証を管理するかどうかを決定します。有効にするには、 |
デフォルト: |
|
標準の Jenkins 認証を使用する際の |
デフォルト: |
|
これらの値は Jenkins JVM の最大ヒープサイズを制御します。 デフォルトでは Jenkins JVM の最大ヒープサイズは、上限なしでコンテナーメモリー制限の 50% に設定されます。 |
|
|
これらの値は Jenkins JVM の初期ヒープサイズを制御します。 デフォルトでは、JVM は初期のヒープサイズを設定します。 |
|
| 設定されている場合には、内部の JVM スレッドのサイジング数に使用するコアの数を整数で指定します。 |
設定例: |
| このコンテナーで実行中のすべての JVM に適用するオプションを指定します。この値の上書きは推奨していません。 |
デフォルト: |
| Jenkins JVM ガーベッジコレクションのパラメーターを指定します。この値の上書きは推奨していません。 |
デフォルト: |
| Jenkins JVM の追加オプションを指定します。これらのオプションは、上記の Java オプションなどその他すべてのオプションに追加され、必要に応じてそれらの値のいずれかを上書きするのに使用できます。追加オプションがある場合には、スペースで区切ります。オプションにスペース文字が含まれる場合には、バックスラッシュでエスケープしてください。 |
設定例: |
| Jenkins への引数を指定します。 | |
|
コンテナーが初めて実行された場合や、 |
設定例: |
| OpenShift Container Platform ログインプラグインが Jenkins に定義されているユーザーごとに関連付けられたパーミッションを OpenShift Container Platform でポーリングする間隔をミリ秒単位で指定します。 |
デフォルト: |
|
Jenkins 設定ディレクトリー用に OpenShift Container Platform 永続ボリューム (PV) を使用してこのイメージを実行する場合、PV は永続ボリューム要求 (PVC) の作成時に割り当てられるため、イメージから PV に設定が転送されるのは、イメージの初回起動時のみです。このイメージを拡張し、初回起動後にカスタムイメージの設定を更新するカスタムイメージを作成する場合、この環境変数を |
デフォルト: |
|
Jenkins 設定ディレクトリー用に OpenShift Container Platform PV を使用してこのイメージを実行する場合、PV は PVC の作成時に割り当てられるため、イメージから PV にプラグインが転送されるのは、イメージの初回起動時のみです。このイメージを拡張し、初回起動後にカスタムイメージのプラグインを更新するカスタムイメージを作成する場合、この環境変数を |
デフォルト: |
|
Jenkins 設定ディレクトリー用に OpenShift Container Platform PVC を使用してこのイメージを実行する場合に、この環境変数は致命的なエラーが生じる際に致命的なエラーのログファイルが永続することを可能にします。致命的なエラーのファイルは |
デフォルト: |
|
この値を設定すると、デフォルトの Node.js エージェント Pod 設定に使用されるイメージが上書きされます。 |
Jenkins サーバーのデフォルトの Node.js エージェントイメージ: |
|
この値を設定すると、デフォルトの maven エージェント Pod 設定に使用されるイメージが上書きされます。 |
Jenkins サーバーのデフォルトの Maven エージェントイメージ: |
12.2.3. Jenkins へのプロジェクト間のアクセスの提供
同じプロジェクト以外で Jenkins を実行する場合には、プロジェクトにアクセスするために、Jenkins にアクセストークンを提供する必要があります。
手順
サービスアカウントのシークレットを特定します。そのアカウントには、Jenkins がアクセスする必要のあるプロジェクトにアクセスするための適切なパーミッションがあります。
$ oc describe serviceaccount jenkins
出力例
Name: default Labels: <none> Secrets: { jenkins-token-uyswp } { jenkins-dockercfg-xcr3d } Tokens: jenkins-token-izv1u jenkins-token-uyswp
ここでは、シークレットの名前は
jenkins-token-uyswp
です。シークレットからトークンを取得します。
$ oc describe secret <secret name from above>
出力例
Name: jenkins-token-uyswp Labels: <none> Annotations: kubernetes.io/service-account.name=jenkins,kubernetes.io/service-account.uid=32f5b661-2a8f-11e5-9528-3c970e3bf0b7 Type: kubernetes.io/service-account-token Data ==== ca.crt: 1066 bytes token: eyJhbGc..<content cut>....wRA
トークンパラメーターには、Jenkins がプロジェクトにアクセスするために必要とするトークンの値が含まれます。
12.2.4. Jenkins のボリューム間のマウントポイント
Jenkins イメージはマウントしたボリュームで実行して、設定用に永続ストレージを有効にできます。
-
/var/lib/jenkins
- Jenkins がジョブ定義などの設定ファイルを保存するデータディレクトリーです。
12.2.5. S2I (Source-To-Image) による Jenkins イメージのカスタマイズ
正式な OpenShift Container Platform Jenkins イメージをカスタマイズするには、イメージを Source-To-Image (S2I) ビルダーとしてイメージを使用できます。
S2I を使用して、カスタムの Jenkins ジョブ定義をコピーしたり、プラグインを追加したり、同梱の config.xml
ファイルを独自のカスタムの設定に置き換えたりできます。
Jenkins イメージに変更を追加するには、以下のディレクトリー構造の Git リポジトリーが必要です。
plugins
- このディレクトリーには、Jenkins にコピーするバイナリーの Jenkins プラグインを含めます。
plugins.txt
- このファイルは、以下の構文を使用して、インストールするプラグインを一覧表示します。
pluginId:pluginVersion
configuration/jobs
- このディレクトリーには、Jenkins ジョブ定義が含まれます。
configuration/config.xml
- このファイルには、カスタムの Jenkins 設定が含まれます。
configuration/
ディレクトリーのコンテンツは /var/lib/jenkins/
ディレクトリーにコピーされるので、このディレクトリーに credentials.xml
などのファイルをさらに追加することもできます。
ビルド設定のサンプルは、OpenShift Container Platform で Jenkins イメージをカスタマイズします。
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: custom-jenkins-build spec: source: 1 git: uri: https://github.com/custom/repository type: Git strategy: 2 sourceStrategy: from: kind: ImageStreamTag name: jenkins:2 namespace: openshift type: Source output: 3 to: kind: ImageStreamTag name: custom-jenkins:latest
12.2.6. Jenkins Kubernetes プラグインの設定
OpenShift Container Platform Jenkins イメージには、事前にインストール済みの Kubernetes プラグイン が含まれ、Kubernetes および OpenShift Container Platform を使用して、Jenkins エージェントを複数のコンテナーホストで動的にプロビジョニングできるようにします。
OpenShift Container Platform は、Kubernetes プラグインを使用するために、Jenkins エージェントとして使用するのに適したイメージ (Base、Maven、および Node.js イメージ) を提供します。
Maven および Node.js のエージェントイメージは、Kubernetes プラグイン用の OpenShift Container Platform Jenkins イメージの設定内で、Kubernetes Pod テンプレートイメージとして自動的に設定されます。この設定にはイメージごとのラベルが含まれており、Restrict where this project can be run の設定にある Jenkins ジョブのいずれかに適用できます。ラベルが適用されている場合、ジョブはそれぞれのエージェントイメージを実行する OpenShift Container Platform Pod の下で実行されます。
Jenkins イメージは、Kubernetes プラグイン向けの追加エージェントイメージの自動検出および自動設定も提供します。
OpenShift Container Platform 同期プラグインでは、Jenkins イメージは、Jenkins の起動時に、実行中のプロジェクトまたはプラグインの設定に具体的に一覧表示されているプロジェクト内で以下を検索します。
-
ラベル
role
がjenkins-agent
に設定されているイメージストリーム -
アノテーション
role
がjenkins-agent
に設定されているイメージストリーム -
ラベル
role
がjenkins-agent
に設定されている設定マップ
適切なラベルまたは、適切なアノテーションが付いたイメージストリームタグが見つかると、適切な Kubernetes プラグイン設定が生成され、イメージストリーム提供のコンテナーイメージを実行する Pod で、Jenkins ジョブを実行するように割り当てることができます。
イメージストリームまたはイメージストリームタグの名前とイメージ参照は、Kubernetes プラグインの Pod テンプレートにある名前およびイメージフィールドにマッピングされます。Kubernetes プラグインの Pod テンプレートのラベルフィールドは、agent-label
キーを使用してイメージストリームまたはイメージストリームタグオブジェクトにアノテーションを設定することで制御できます。これらを使用しない場合には、名前をラベルとして使用します。
Jenkins コンソールにログインして、Pod テンプレート設定を変更しないでください。Pod テンプレートが作成された後にこれを行い、OpenShift Container Platform 同期プラグインがイメージストリームまたはイメージストリームタグに関連付けられたイメージが変更されたことを検知した場合、Pod テンプレートを置き換え、これらの設定変更を上書きします。新しい設定を既存の設定とマージすることはできません。
より複雑な設定が必要な場合は、設定マップ を使用する方法を検討してください。
適切なラベルが指定された設定マップが検出される場合は、設定マップのキーと値のデータペイロードの値に、Jenkins および Kubernetes プラグインの Pod テンプレートの設定形式に準拠する XML (Extensible Markup Language) が含まれることが想定されます。設定マップを使用時に注意すべき主な違いは、イメージストリームまたはイメージストリームタグではなく、Kubernetes プラグインの Pod テンプレートのパラメーターすべてを制御できます。
jenkins-agent
の設定マップの例:
kind: ConfigMap apiVersion: v1 metadata: name: jenkins-agent labels: role: jenkins-agent data: template1: |- <org.csanchez.jenkins.plugins.kubernetes.PodTemplate> <inheritFrom></inheritFrom> <name>template1</name> <instanceCap>2147483647</instanceCap> <idleMinutes>0</idleMinutes> <label>template1</label> <serviceAccount>jenkins</serviceAccount> <nodeSelector></nodeSelector> <volumes/> <containers> <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate> <name>jnlp</name> <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image> <privileged>false</privileged> <alwaysPullImage>true</alwaysPullImage> <workingDir>/tmp</workingDir> <command></command> <args>${computer.jnlpmac} ${computer.name}</args> <ttyEnabled>false</ttyEnabled> <resourceRequestCpu></resourceRequestCpu> <resourceRequestMemory></resourceRequestMemory> <resourceLimitCpu></resourceLimitCpu> <resourceLimitMemory></resourceLimitMemory> <envVars/> </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate> </containers> <envVars/> <annotations/> <imagePullSecrets/> <nodeProperties/> </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
Jenkins コンソールにログインして、Pod テンプレートの作成後に Pod テンプレート設定をさらに変更し、OpenShift Container Platform 同期プラグインが設定マップが変更されたことを検知すると、これは Pod テンプレートを置き換え、この設定変更を上書きします。新しい設定を既存の設定とマージすることはできません。
Jenkins コンソールにログインして、Pod テンプレート設定を変更しないでください。Pod テンプレートが作成された後にこれを行い、OpenShift Container Platform 同期プラグインがイメージストリームまたはイメージストリームタグに関連付けられたイメージが変更されたことを検知した場合、Pod テンプレートを置き換え、これらの設定変更を上書きします。新しい設定を既存の設定とマージすることはできません。
より複雑な設定が必要な場合は、設定マップ を使用する方法を検討してください。
インストールされた後、OpenShift Container Platform 同期プラグインは、イメージストリーム、イメージストリームタグ、および設定マップに更新がないか、OpenShift Container Platform の API サーバーをモニターリングして、Kubernetes プラグインの設定を調整します。
以下のルールが適用されます。
-
設定マップ、イメージストリーム、またはイメージストリームタグからラベルまたはアノテーションを削除すると、既存の
PodTemplate
が Kubernetes プラグインの設定から削除されます。 - これらのオブジェクトが削除されると、対応する設定が Kubernetes プラグインから削除されます。
-
適切なラベルおよびアノテーションが付いた
ConfigMap
、ImageStream
、またはImageStreamTag
オブジェクトを作成するか、初回作成後にラベルを追加すると、Kubernetes プラグイン設定にPodTemplate
が作成されます。 -
設定マップフォームの
PodTemplate
の場合には、PodTemplate
の設定マップデータへの変更は、Kubernetes プラグイン設定のPodTemplate
設定に適用され、設定マップに変更を加えてから次に変更を加えるまでの間に、Jenkins UI で加えたPodTemplate
の変更が上書きされます。
Jenkins エージェントとしてコンテナーイメージを使用するには、イメージは、エントリーポイントとしてエージェントを実行する必要があります。これに関する詳細情報は、公式の Jenkins ドキュメント を参照してください。
12.2.7. Jenkins パーミッション
設定マップで、Pod テンプレート XML の <serviceAccount>
要素が結果として作成される Pod に使用される OpenShift Container Platform サービスアカウントである場合、サービスアカウントの認証情報が Pod にマウントされます。パーミッションはサービスアカウントに関連付けられ、OpenShift Container Platform マスターに対するどの操作が Pod から許可されるかについて制御します。
Pod に使用されるサービスアカウントについて以下のシナリオを考慮してください。この Pod は、OpenShift Container Platform Jenkins イメージで実行される Kubernetes プラグインによって起動されます。
OpenShift Container Platform で提供される Jenkins のテンプレートサンプルを使用する場合には、jenkins
サービスアカウントが、Jenkins が実行するプロジェクトの edit
ロールで定義され、マスター Jenkins Pod にサービスアカウントがマウントされます。
Jenkins 設定に挿入される 2 つのデフォルトの Maven および NodeJS Pod テンプレートは、Jenkins マスターと同じサービスアカウントを使用するように設定されます。
- イメージストリームまたはイメージストリームタグに必要なラベルまたはアノテーションがあるために OpenShift Container Platform 同期プラグインで自動的に検出されるすべての Pod テンプレートは、Jenkins マスターのサービスアカウントをサービスアカウントとして使用するように設定されます。
-
Pod テンプレートの定義を Jenkins と Kubernetes プラグインに渡す他の方法として、使用するサービスアカウントを明示的に指定する必要があります。他の方法には、Jenkins コンソール、Kubernetes プラグインで提供される
podTemplate
パイプライン DSL、または Pod テンプレートの XML 設定をデータとする設定マップのラベル付けなどが含まれます。 -
サービスアカウントの値を指定しない場合には、
default
のサービスアカウントが使用されます。 - 使用するサービスアカウントが何であっても、必要なパーミッション、ロールなどを OpenShift Container Platform 内で定義して、Pod から操作するプロジェクトをすべて操作できるようにする必要があります。
12.2.8. テンプレートからの Jenkins サービスの作成
テンプレートには各種パラメーターフィールドがあり、事前定義されたデフォルト値ですべての環境変数を定義できます。OpenShift Container Platform では、新規の Jenkins サービスを簡単に作成できるようにテンプレートが提供されています。Jenkins テンプレートは、クラスター管理者が、クラスターの初期設定時に、デフォルトの openshift
プロジェクトに登録する必要があります。
使用可能な 2 つのテンプレートは共にデプロイメント設定とサービスを定義します。テンプレートはストレージストラテジーに応じて異なります。これは、Jenkins コンテンツが Pod の再起動時に永続するかどうかに影響を与えます。
Pod は、別のノードへの移動時や、デプロイメント設定の更新で再デプロイメントがトリガーされた時に再起動される可能性があります。
-
jenkins-ephemeral
は一時ストレージを使用します。Pod が再起動すると、すべてのデータが失われます。このテンプレートは、開発またはテストにのみ役立ちます。 -
jenkins-persistent
は永続ボリューム (PV) ストアを使用します。データは Pod が再起動されても保持されます。
PV ストアを使用するには、クラスター管理者は OpenShift Container Platform デプロイメントで PV プールを定義する必要があります。
必要なテンプレートを選択したら、テンプレートをインスタンス化して Jenkins を使用できるようにする必要があります。
手順
以下の方法のいずれかを使用して、新しい Jenkins アプリケーションを作成します。
PV:
$ oc new-app jenkins-persistent
または、Pod の再起動で設定が維持されない
emptyDir
タイプボリューム:$ oc new-app jenkins-ephemeral
12.2.9. Jenkins Kubernetes プラグインの使用
以下の例では、openshift-jee-sample
BuildConfig
オブジェクトにより、Jenkins Maven エージェント Pod が動的にプロビジョニングされます。Pod は Java ソースコードをクローンし、WAR ファイルを作成して、2 番目の BuildConfig
、openshift-jee-sample-docker
を実行します。2 番目の BuildConfig
は、新しい WAR ファイルをコンテナーイメージに階層化します。
Jenkins Kubernetes プラグインを使用した BuildConfig
の例
kind: List apiVersion: v1 items: - kind: ImageStream apiVersion: image.openshift.io/v1 metadata: name: openshift-jee-sample - kind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: openshift-jee-sample-docker spec: strategy: type: Docker source: type: Docker dockerfile: |- FROM openshift/wildfly-101-centos7:latest COPY ROOT.war /wildfly/standalone/deployments/ROOT.war CMD $STI_SCRIPTS_PATH/run binary: asFile: ROOT.war output: to: kind: ImageStreamTag name: openshift-jee-sample:latest - kind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: openshift-jee-sample spec: strategy: type: JenkinsPipeline jenkinsPipelineStrategy: jenkinsfile: |- node("maven") { sh "git clone https://github.com/openshift/openshift-jee-sample.git ." sh "mvn -B -Popenshift package" sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war" } triggers: - type: ConfigChange
動的に作成された Jenkins エージェント Pod の仕様を上書きすることも可能です。以下は、コンテナーメモリーを上書きして、環境変数を指定するように先の例を変更しています。
Jenkins Kubernetes Plug-in を使用し、メモリー制限と環境変数を指定するサンプル BuildConfig
kind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: openshift-jee-sample spec: strategy: type: JenkinsPipeline jenkinsPipelineStrategy: jenkinsfile: |- podTemplate(label: "mypod", 1 cloud: "openshift", 2 inheritFrom: "maven", 3 containers: [ containerTemplate(name: "jnlp", 4 image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 5 resourceRequestMemory: "512Mi", 6 resourceLimitMemory: "512Mi", 7 envVars: [ envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 8 ]) ]) { node("mypod") { 9 sh "git clone https://github.com/openshift/openshift-jee-sample.git ." sh "mvn -B -Popenshift package" sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war" } } triggers: - type: ConfigChange
- 1
mypod
という名前の新しい Pod テンプレートが動的に定義されます。この新しい Pod テンプレート名はノードのスタンザで参照されます。- 2
cloud
の値はopenshift
に設定する必要があります。- 3
- 新しい Pod テンプレートは、既存の Pod テンプレートから設定を継承できます。この場合、OpenShift Container Platform で事前定義された Maven Pod テンプレートから継承されます。
- 4
- この例では、既存のコンテナーの値を上書きし、名前で指定する必要があります。OpenShift Container Platform に含まれる Jenkins エージェントイメージはすべて、コンテナー名として
jnlp
を使用します。 - 5
- 再びコンテナーイメージ名を指定します。これは既知の問題です。
- 6
512 Mi
のメモリー要求を指定します。- 7
512 Mi
のメモリー制限を指定します。- 8
- 環境変数
CONTAINER_HEAP_PERCENT
に値0.25
を指定します。 - 9
- ノードスタンザは、定義された Pod テンプレート名を参照します。
デフォルトで、Pod はビルドの完了時に削除されます。この動作は、プラグインを使用して、またはパイプライン Jenkinsfile 内で変更できます。
12.2.10. Jenkins メモリーの要件
提供される Jenkins の一時また永続テンプレートでデプロイする場合にはデフォルトのメモリー制限は 1 Gi
です。
デフォルトで、Jenkins コンテナーで実行する他のすべてのプロセスは、合計の 512 MiB
を超えるメモリーを使用することはできません。メモリーがさらに必要になると、コンテナーは停止します。そのため、パイプラインが可能な場合に、エージェントコンテナーで外部コマンドを実行することを強く推奨されます。
また、Project
クォータがこれを許可する場合は、Jenkins マスターがメモリーの観点から必要とするものについて、Jenkins ドキュメントの推奨事項を参照してください。この推奨事項では、Jenkins マスターにさらにメモリーを割り当てることを禁止しています。
Jenkins Kubernetes プラグインによって作成されるエージェントコンテナーで、メモリー要求および制限の値を指定することが推奨されます。管理者ユーザーは、Jenkins 設定を使用して、エージェントのイメージごとにデフォルト値を設定できます。メモリー要求および制限パラメーターは、コンテナーごとに上書きすることもできます。
Jenkins で利用可能なメモリー量を増やすには、Jenkins の一時テンプレートまたは永続テンプレートをインスタンス化する際に MEMORY_LIMIT
パラメーターを上書きします。
12.2.11. 関連情報
- Red Hat Universal Base Images (UBI) の詳細は、ベースイメージのオプション を参照してください。