Jenkins

Jenkins 認証は、以下の 2 つの方法で管理できます。

Jenkins サーバーは、以下の環境変数で設定できます。

同じプロジェクト以外で Jenkins を実行する場合は、プロジェクトにアクセスするために、Jenkins にアクセストークンを提供する必要があります。

Jenkins イメージはマウントしたボリュームで実行して、設定用に永続ストレージを有効にできます。

正式な OpenShift Container Platform Jenkins イメージをカスタマイズするには、イメージを Source-to-Image (S2I) ビルダーとしてイメージを使用できます。

S2I を使用して、カスタムの Jenkins ジョブ定義をコピーしたり、プラグインを追加したり、同梱の config.xml ファイルを独自のカスタムの設定に置き換えたりできます。

Jenkins イメージに変更を追加するには、以下のディレクトリー構造の Git リポジトリーが必要です。

pluginId:pluginVersion

configuration/ ディレクトリーのコンテンツは /var/lib/jenkins/ ディレクトリーにコピーされるので、このディレクトリーに credentials.xml などのファイルをさらに追加することもできます。

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

OpenShift Jenkins イメージにはプリインストールされた Jenkins 用の Kubernetes プラグイン が含まれているため、Kubernetes と OpenShift Container Platform を使用して複数のコンテナーホストで Jenkins エージェントを動的にプロビジョニングできます。

Kubernetes プラグインを使用するために、OpenShift Container Platform は、Jenkins エージェントとしての使用に適した OpenShift Agent Base イメージを提供します。

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 イメージが実行中のプロジェクト内、またはプラグインの設定にリストされているプロジェクト内で以下の項目を検索します。

Jenkins イメージは、適切なラベルを持つイメージストリーム、または適切なアノテーションを持つイメージストリームタグを見つけると、対応する Kubernetes プラグイン設定を生成します。このようにして、イメージストリームによって提供されるコンテナーイメージを実行する Pod で実行するように Jenkins ジョブを割り当てることができます。

イメージストリームまたはイメージストリームタグの名前とイメージ参照は、Kubernetes プラグインの Pod テンプレートにある名前およびイメージフィールドにマッピングされます。Kubernetes プラグインの Pod テンプレートのラベルフィールドは、agent-label キーを使用してイメージストリームまたはイメージストリームタグオブジェクトにアノテーションを設定することで制御できます。これらを使用しない場合には、名前をラベルとして使用します。

適切なラベルを持つ config map が見つかると、Jenkins イメージは、config map のキーと値のデータペイロードの任意の値に、Jenkins および Kubernetes プラグイン Pod テンプレートの設定形式と一致する Extensible Markup Language (XML) が含まれていると想定します。イメージストリームやイメージストリームタグに対する config map の主な利点の 1 つは、すべての Kubernetes プラグイン Pod テンプレートパラメーターを制御できることです。

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>

以下の例は、openshift namespace のイメージストリームを参照する 2 つのコンテナーを示しています。1 つのコンテナーが、Pod を Jenkins エージェントとして起動するための JNLP コントラクトを処理します。もう 1 つのコンテナーは、特定のコーディング言語でコードを構築するためのツールを備えたイメージを使用します。

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
data:
  template2: |-
        <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
          <inheritFrom></inheritFrom>
          <name>template2</name>
          <instanceCap>2147483647</instanceCap>
          <idleMinutes>0</idleMinutes>
          <label>template2</label>
          <serviceAccount>jenkins</serviceAccount>
          <nodeSelector></nodeSelector>
          <volumes/>
          <containers>
            <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
              <name>jnlp</name>
              <image>image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest</image>
              <privileged>false</privileged>
              <alwaysPullImage>true</alwaysPullImage>
              <workingDir>/home/jenkins/agent</workingDir>
              <command></command>
              <args>\$(JENKINS_SECRET) \$(JENKINS_NAME)</args>
              <ttyEnabled>false</ttyEnabled>
              <resourceRequestCpu></resourceRequestCpu>
              <resourceRequestMemory></resourceRequestMemory>
              <resourceLimitCpu></resourceLimitCpu>
              <resourceLimitMemory></resourceLimitMemory>
              <envVars/>
            </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
            <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
              <name>java</name>
              <image>image-registry.openshift-image-registry.svc:5000/openshift/java:latest</image>
              <privileged>false</privileged>
              <alwaysPullImage>true</alwaysPullImage>
              <workingDir>/home/jenkins/agent</workingDir>
              <command>cat</command>
              <args></args>
              <ttyEnabled>true</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>

インストールされた後、OpenShift Container Platform 同期プラグインは、イメージストリーム、イメージストリームタグ、および config map に更新がないか、OpenShift Container Platform の API サーバーをモニタリングして、Kubernetes プラグインの設定を調整します。

以下のルールが適用されます。

Jenkins エージェントとしてコンテナーイメージを使用するには、イメージが、エントリーポイントとしてエージェントを実行する必要があります。詳細は、公式の Jenkins ドキュメント を参照してください。

config map で、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 では、新規の Jenkins サービスを簡単に作成できるようにテンプレートが提供されています。Jenkins テンプレートは、クラスター管理者が、クラスターの初期設定時に、デフォルトの openshift プロジェクトに登録する必要があります。

使用可能な 2 つのテンプレートは共にデプロイメント設定とサービスを定義します。テンプレートはストレージストラテジーに応じて異なります。これは、Jenkins コンテンツが Pod の再起動時に永続するかどうかに影響を与えます。

PV ストアを使用するには、クラスター管理者は OpenShift Container Platform デプロイメントで PV プールを定義する必要があります。

必要なテンプレートを選択したら、テンプレートをインスタンス化して Jenkins を使用できるようにする必要があります。

両方のテンプレートで、それらに対して oc describe を実行して、オーバーライドに使用できるすべてのパラメーターを確認できます。

以下に例を示します。

$ oc describe jenkins-ephemeral

以下の例では、openshift-jee-sample BuildConfig オブジェクトにより、Jenkins Maven エージェント Pod が動的にプロビジョニングされます。Pod は Java ソースコードをクローンし、WAR ファイルを作成して、2 番目の BuildConfig、openshift-jee-sample-docker を実行します。2 番目の BuildConfig は、新しい WAR ファイルをコンテナーイメージに階層化します。

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 の仕様を上書きすることも可能です。以下は、コンテナーメモリーを上書きして、環境変数を指定するように先の例を変更しています。

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

デフォルトで、Pod はビルドの完了時に削除されます。この動作は、プラグインを使用して、またはパイプライン Jenkinsfile 内で変更できます。

アップストリームの Jenkins では少し前に、パイプラインとインラインで podTemplate パイプライン DSL を定義するための YAML 宣言型フォーマットが導入されました。OpenShift Container Platform の Jenkins イメージで定義されているサンプル java-builder Pod テンプレートを使用したこのフォーマットの例は以下のようになります。

def nodeLabel = 'java-buidler'

pipeline {
  agent {
    kubernetes {
      cloud 'openshift'
      label nodeLabel
      yaml """
apiVersion: v1
kind: Pod
metadata:
  labels:
    worker: ${nodeLabel}
spec:
  containers:
  - name: jnlp
    image: image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest
    args: ['\$(JENKINS_SECRET)', '\$(JENKINS_NAME)']
  - name: java
    image: image-registry.openshift-image-registry.svc:5000/openshift/java:latest
    command:
    - cat
    tty: true
"""
    }
  }

  options {
    timeout(time: 20, unit: 'MINUTES')
  }

  stages {
    stage('Build App') {
      steps {
        container("java") {
          sh "mvn --version"
        }
     }
    }
  }
}

提供される Jenkins の一時また永続テンプレートでデプロイする場合、デフォルトのメモリー制限は 1 Gi になります。

デフォルトで、Jenkins コンテナーで実行する他のすべてのプロセスは、合計の 512 MiB を超えるメモリーを使用することができません。メモリーがさらに必要になると、コンテナーは停止します。そのため、パイプラインが可能な場合に、エージェントコンテナーで外部コマンドを実行することが強く推奨されます。

また、Project クォータがこれを許可する場合は、Jenkins マスターがメモリーの観点から必要とするものについて、Jenkins ドキュメントの推奨事項を参照してください。この推奨事項では、Jenkins マスターにさらにメモリーを割り当てることを禁止しています。

Jenkins Kubernetes プラグインによって作成されるエージェントコンテナーで、メモリー要求および制限の値を指定することが推奨されます。管理者ユーザーは、Jenkins 設定を使用して、エージェントのイメージごとにデフォルト値を設定できます。メモリー要求および制限パラメーターは、コンテナーごとに上書きすることもできます。

Jenkins で利用可能なメモリー量を増やすには、Jenkins の一時テンプレートまたは永続テンプレートをインスタンス化する際に MEMORY_LIMIT パラメーターを上書きします。

OpenShift Container Platform Jenkins エージェントイメージは Quay.io または registry.redhat.io で利用できます。

Jenkins イメージは、Red Hat レジストリーから入手できます。

$ docker pull registry.redhat.io/ocp-tools-4/jenkins-rhel8:<image_tag>

$ docker pull registry.redhat.io/ocp-tools-4/jenkins-agent-base-rhel8:<image_tag>

これらのイメージを使用するには、Quay.io または registry.redhat.io から直接アクセスするか、これらを OpenShift Container Platform コンテナーイメージレジストリーにプッシュします。

各 Jenkins エージェントコンテナーは、以下の環境変数で設定できます。

JVM はすべての Jenkins エージェントで使用され、Jenkins JNLP エージェントをホストし、javac、Maven、Gradle などの Java アプリケーションを実行します。

デフォルトで、Jenkins JNLP エージェントの JVM はヒープにコンテナーメモリー制限の 50% を使用します。この値は、CONTAINER_HEAP_PERCENT の環境変数で変更可能です。上限を指定することも、すべて上書きすることも可能です。

デフォルトでは、シェルスクリプトや oc コマンドをパイプラインから実行するなど、Jenkins エージェントコンテナーで実行される他のプロセスはすべて、OOM kill を呼び出さずに残りの 50% メモリー制限を超えるメモリーを使用することはできません。

デフォルトでは、Jenkins エージェントコンテナーで実行される他の各 JVM プロセスは、最大でコンテナーメモリー制限の 25% をヒープに使用します。多くのビルドワークロードにおいて、この制限の調整が必要になる場合があります。

OpenShift Container Platform の Jenkins エージェントで Gradle ビルドをホストすると、Jenkins JNLP エージェントおよび Gradle JVM に加え、テストが指定されている場合に Gradle が 3 番目の JVM を起動してテストを実行するので、さらに複雑になります。

以下の設定は、OpenShift Container Platform でメモリーに制約がある Jenkins エージェントの Gradle ビルドを実行する場合の開始点として推奨されます。必要に応じて、これらの設定を変更することができます。

Jenkins エージェント Pod は、ビルドが完了するか、停止された後にデフォルトで削除されます。この動作は、Kubernetes プラグイン Pod の保持設定で変更できます。Pod の保持は、すべての Jenkins ビルドについて各 Pod テンプレートの上書きで設定できます。以下の動作がサポートされます。

Pod の保持はパイプライン Jenkinsfile で上書きできます。

podTemplate(label: "mypod",
  cloud: "openshift",
  inheritFrom: "maven",
  podRetention: onFailure(), 1
  containers: [
    ...
  ]) {
  node("mypod") {
    ...
  }
}

Jenkins および OpenShift Pipelines で使用される以下の同等の用語を確認および比較できます。

以下の同等の例を使用して、Jenkins から OpenShift Pipelines へのパイプラインのビルド、テスト、およびデプロイを支援できます。

pipeline {
   agent any
   stages {
       stage('Build') {
           steps {
               sh 'make'
           }
       }
       stage('Test'){
           steps {
               sh 'make check'
               junit 'reports/**/*.xml'
           }
       }
       stage('Deploy') {
           steps {
               sh 'make publish'
           }
       }
   }
}

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-build
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make"]
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myproject-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-ci-image
    command: ["make check"]
    workingDir: $(workspaces.source.path)
  - image: junit-report-image
    script: |
      #!/usr/bin/env bash
      junit-report reports/**/*.xml
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: myprojectd-deploy
spec:
  workspaces:
  - name: source
  steps:
  - image: my-deploy-image
    command: ["make deploy"]
    workingDir: $(workspaces.source.path)

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: myproject-pipeline
spec:
  workspaces:
  - name: shared-dir
  tasks:
  - name: build
    taskRef:
      name: myproject-build
    workspaces:
    - name: source
      workspace: shared-dir
  - name: test
    taskRef:
      name: myproject-test
    workspaces:
    - name: source
      workspace: shared-dir
  - name: deploy
    taskRef:
      name: myproject-deploy
    workspaces:
    - name: source
      workspace: shared-dir

プラグイン を使用して、Jenkins の機能を拡張できます。OpenShift Pipelines で同様の拡張性を実現するには、Tekton Hub から利用可能なタスクのいずれかを使用します。

たとえば、Jenkins の git plug-in に対応する Tekton Hub の git-clone タスクについて考えてみます。

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
 name: demo-pipeline
spec:
 params:
   - name: repo_url
   - name: revision
 workspaces:
   - name: source
 tasks:
   - name: fetch-from-git
     taskRef:
       name: git-clone
     params:
       - name: url
         value: $(params.repo_url)
       - name: revision
         value: $(params.revision)
     workspaces:
     - name: output
       workspace: source

OpenShift Pipelines では、Tekton Hub で適切なタスクが見つからない場合、またはタスクをより細かく制御する必要がある場合は、カスタムタスクとスクリプトを作成して OpenShift Pipelines の機能を拡張できます。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: maven-test
spec:
  workspaces:
  - name: source
  steps:
  - image: my-maven-image
    command: ["mvn test"]
    workingDir: $(workspaces.source.path)

...
steps:
  image: ubuntu
  script: |
      #!/usr/bin/env bash
      /workspace/my-script.sh
...

...
steps:
  image: python
  script: |
      #!/usr/bin/env python3
      print(“hello from python!”)
...

Jenkins と OpenShift Pipelines は同様の機能を提供しますが、アーキテクチャーと実行が異なります。

Jenkins と OpenShift Pipelines はどちらも、次のような一般的な CI/CD ユースケース向けの機能を提供します。

#!/usr/bin/groovy
node('maven') {
    stage 'Checkout'
    checkout scm

    stage 'Build'
    sh 'cd helloworld && mvn clean'
    sh 'cd helloworld && mvn compile'

    stage 'Run Unit Tests'
    sh 'cd helloworld && mvn test'

    stage 'Package'
    sh 'cd helloworld && mvn package'

    stage 'Archive artifact'
    sh 'mkdir -p artifacts/deployments && cp helloworld/target/*.war artifacts/deployments'
    archive 'helloworld/target/*.war'

    stage 'Create Image'
    sh 'oc login https://kubernetes.default -u admin -p admin --insecure-skip-tls-verify=true'
    sh 'oc new-project helloworldproject'
    sh 'oc project helloworldproject'
    sh 'oc process -f helloworld/jboss-eap70-binary-build.json | oc create -f -'
    sh 'oc start-build eap-helloworld-app --from-dir=artifacts/'

    stage 'Deploy'
    sh 'oc new-app helloworld/jboss-eap70-deploy.json' }

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: maven-pipeline
spec:
  workspaces:
    - name: shared-workspace
    - name: maven-settings
    - name: kubeconfig-dir
      optional: true
  params:
    - name: repo-url
    - name: revision
    - name: context-path
  tasks:
    - name: fetch-repo
      taskRef:
        name: git-clone
      workspaces:
        - name: output
          workspace: shared-workspace
      params:
        - name: url
          value: "$(params.repo-url)"
        - name: subdirectory
          value: ""
        - name: deleteExisting
          value: "true"
        - name: revision
          value: $(params.revision)
    - name: mvn-build
      taskRef:
        name: maven
      runAfter:
        - fetch-repo
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["-DskipTests", "clean", "compile"]
    - name: mvn-tests
      taskRef:
        name: maven
      runAfter:
        - mvn-build
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["test"]
    - name: mvn-package
      taskRef:
        name: maven
      runAfter:
        - mvn-tests
      workspaces:
        - name: source
          workspace: shared-workspace
        - name: maven-settings
          workspace: maven-settings
      params:
        - name: CONTEXT_DIR
          value: "$(params.context-path)"
        - name: GOALS
          value: ["package"]
    - name: create-image-and-deploy
      taskRef:
        name: openshift-client
      runAfter:
        - mvn-package
      workspaces:
        - name: manifest-dir
          workspace: shared-workspace
        - name: kubeconfig-dir
          workspace: kubeconfig-dir
      params:
        - name: SCRIPT
          value: |
            cd "$(params.context-path)"
            mkdir -p ./artifacts/deployments && cp ./target/*.war ./artifacts/deployments
            oc new-project helloworldproject
            oc project helloworldproject
            oc process -f jboss-eap70-binary-build.json | oc create -f -
            oc start-build eap-helloworld-app --from-dir=artifacts/
            oc new-app jboss-eap70-deploy.json

OpenShift Container Platform 4.11 では、特定の OpenShift Jenkins イメージの場所と可用性が大幅に変更されています。さらに、これらのイメージをいつ、どのように更新するかを設定できます。

以前は、各 Jenkins イメージは OpenShift Container Platform の 1 つのバージョンのみをサポートしており、Red Hat はこれらのイメージを時間の経過とともに順次更新する可能性がありました。

新規イメージストリームタグについて以下を実行します。

ただし、Cluster Samples Operator は、以前のリリースで作成された jenkins-agent-maven および jenkins-agent-nodejs イメージストリームを削除しません。これらは、registry.redhat.io 上のそれぞれの OpenShift Container Platform ペイロードイメージのタグを指しています。したがって、次のコマンドを実行して、これらのイメージの更新をプルできます。

$ oc import-image jenkins-agent-nodejs -n openshift

$ oc import-image jenkins-agent-maven -n openshift

デフォルトのアップグレード動作をオーバーライドし、Jenkins イメージのアップグレード方法を制御するには、Jenkins デプロイメント設定で使用するイメージストリームタグの値を設定します。

デフォルトのアップグレード動作は、Jenkins イメージがインストールペイロードの一部であったときに存在した動作です。jenkins-rhel.json イメージストリームファイル内のイメージストリームタグ名 2 および ocp-upgrade-redeploy は、SHA 固有のイメージ参照を使用します。したがって、これらのタグが新しい SHA で更新されると、OpenShift Container Platform イメージ変更コントローラーは、関連するテンプレート (jenkins-ephemeral.json や jenkins-persistent.json など) から Jenkins デプロイメント設定を自動的に再デプロイします。

新しいデプロイメントの場合、そのデフォルト値をオーバーライドするには、jenkins-ephemeral.json Jenkins テンプレートの JENKINS_IMAGE_STREAM_TAG の値を変更します。たとえば、"value": "jenkins:2" の 2 を次のイメージストリームタグのいずれかに置き換えます。