Jenkins 인증은 다음 두 가지 방법으로 관리할 수 있습니다.

Jenkins 서버는 다음 환경 변수로 구성할 수 있습니다.

동일한 프로젝트가 아닌 다른 위치에서 Jenkins를 실행하려는 경우 Jenkins에 액세스 토큰을 제공해야 프로젝트에 액세스할 수 있습니다.

구성을 위한 영구 스토리지가 활성화되도록 마운트된 볼륨을 사용하여 Jenkins 이미지를 실행할 수 있습니다.

공식 OpenShift Container Platform Jenkins 이미지를 사용자 정의하려면 이미지를 S2I(Source-to-Image) 빌더로 사용할 수 있습니다.

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 에이전트 기본 이미지를 제공합니다.

Maven 및 Node.js 에이전트 이미지는 Kubernetes 플러그인에 대한 OpenShift Container Platform Jenkins 이미지 구성에서 Kubernetes pod 템플릿 이미지로 자동 구성됩니다. 해당 구성에는 Restrict where this project can be run 아래의 모든 Jenkins 작업에 적용할 수 있는 각 이미지의 레이블이 포함됩니다. 레이블이 적용되면 해당 에이전트 이미지를 실행하는 OpenShift Container Platform pod에서 작업이 실행됩니다.

Jenkins 이미지는 Kubernetes 플러그인의 추가 에이전트 이미지 자동 검색 및 자동 구성 기능도 제공합니다.

Jenkins 시작 시 OpenShift Container Platform 동기화 플러그인을 사용하면 Jenkins 이미지가 실행 중인 프로젝트 또는 플러그인 구성에 나열된 프로젝트에서 다음 항목을 검색합니다.

Jenkins 이미지에서 적절한 레이블이 있는 이미지 스트림 또는 적절한 주석이 있는 이미지 스트림 태그를 찾으면 해당 Kubernetes 플러그인 구성이 생성됩니다. 이렇게 하면 이미지 스트림에서 제공하는 컨테이너 이미지를 실행하는 포드에서 Jenkins 작업을 실행하도록 할당할 수 있습니다.

이미지 스트림 또는 이미지 스트림 태그의 이름 및 이미지 참조는 Kubernetes 플러그인 pod 템플릿의 이름 및 이미지 필드에 매핑됩니다. agent-label 키로 이미지 스트림 또는 이미지 스트림 태그 오브젝트에 주석을 설정하여 Kubernetes 플러그인 pod 템플릿의 레이블 필드를 제어할 수 있습니다. 그러지 않으면 이름이 레이블로 사용됩니다.

적절한 레이블이 있는 구성 맵을 찾으면 Jenkins 이미지는 구성 맵의 키-값 데이터 페이로드에 있는 값에 Jenkins 및 Kubernetes 플러그인 pod 템플릿의 구성 형식과 일치하는 XML(Extensible Markup Language)이 포함되어 있다고 가정합니다. 이미지 스트림 및 이미지 스트림 태그에 대한 구성 맵의 한 가지 주요 장점은 모든 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 네임스페이스에서 이미지 스트림을 참조하는 두 개의 컨테이너를 보여줍니다. 하나의 컨테이너는 Jenkins 에이전트로 포드를 시작하기 위한 JNLP 계약을 처리합니다. 다른 컨테이너에서는 특정 코딩 언어로 코드를 빌드하는 데 툴이 포함된 이미지를 사용합니다.

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 동기화 플러그인이 설치되면 OpenShift Container Platform의 API 서버를 모니터링하여 이미지 스트림, 이미지 스트림 태그 및 구성 맵에 대한 업데이트를 확인하고 Kubernetes 플러그인의 구성을 조정합니다.

적용되는 규칙은 다음과 같습니다.

컨테이너 이미지를 Jenkins 에이전트로 사용하려면 이미지가 에이전트를 진입점으로 실행해야 합니다. 자세한 내용은 공식 Jenkins 설명서를 참조하십시오.

구성 맵에서 pod 템플릿 XML의 <serviceAccount> 요소가 결과 pod에 사용된 OpenShift Container Platform 서비스 계정인 경우 서비스 계정 인증 정보가 해당 pod에 마운트됩니다. 권한은 이 서비스 계정과 연결되며 pod에서 허용되는 OpenShift Container Platform 마스터 작업을 제어합니다.

Pod에 사용된 서비스 계정을 사용하는 다음 시나리오를 고려해 보십시오. 이 pod는 OpenShift Container Platform Jenkins 이미지에서 실행되는 Kubernetes 플러그인에 의해 시작됩니다.

OpenShift Container Platform에서 제공하는 Jenkins에 대한 템플릿 예를 사용하는 경우 Jenkins가 실행되는 프로젝트에 대해 jenkins 서비스 계정이 edit 역할로 정의되고 마스터 Jenkins Pod에 해당 서비스 계정이 마운트됩니다.

Jenkins 구성에 삽입된 두 개의 기본 Maven 및 NodeJS pod 템플릿도 Jenkins 마스터와 동일한 서비스 계정을 사용하도록 설정됩니다.

템플릿은 모든 환경 변수를 사전 정의된 기본값으로 정의하는 매개변수 필드를 제공합니다. OpenShift Container Platform은 새로운 Jenkins 서비스 생성을 용이하게 해주는 템플릿을 제공합니다. Jenkins 템플릿은 초기 클러스터를 설정하는 중에 클러스터 관리자에 의해 기본 openshift 프로젝트에서 등록되어야 합니다.

사용 가능한 두 템플릿은 둘 다 배포 구성 및 서비스를 정의합니다. 스토리지 전략에서는 pod를 다시 시작하면 Jenkins 콘텐츠가 지속되는지 여부에 영향을 미칩니다.

영구 볼륨 (PV) 저장소를 사용하려면 클러스터 관리자가 OpenShift Container Platform 배포에서 영구 볼륨 (PV) 풀을 정의해야 합니다.

원하는 템플릿을 선택한 후 Jenkins를 사용할 수 있도록 템플릿을 인스턴스화해야 합니다.

두 템플릿 모두 oc describe 를 실행하여 재정의에 사용할 수 있는 모든 매개변수를 확인할 수 있습니다.

예를 들면 다음과 같습니다.

$ oc describe jenkins-ephemeral

다음 예에서는 openshift-jee-sample BuildConfig 오브젝트로 인해 Jenkins Maven 에이전트 pod가 동적으로 프로비저닝됩니다. pod는 일부 Java 소스 코드를 복제하고 WAR 파일을 빌드하며 두 번째 BuildConfig인 openshift-jee-sample-docker가 실행되도록 합니다. 두 번째 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 Ephemeral 또는 Jenkins Persistent 템플릿으로 배포하는 경우 기본 메모리 제한은 1Gi입니다.

기본적으로 Jenkins 컨테이너에서 실행되는 다른 모든 프로세스에서는 총 512 MiB 이상의 메모리를 사용할 수 없습니다. 더 많은 메모리가 필요한 경우 컨테이너가 중지됩니다. 따라서 가능한 경우 Pipeline은 에이전트 컨테이너에서 외부 명령을 실행하는 것이 좋습니다.

Project 할당량이 허용하는 경우 메모리 관점에서 Jenkins 마스터가 갖추어야 할 사항에 대한 Jenkins 문서의 권장 사항을 참조하십시오. 이러한 권장 사항에서는 Jenkins 마스터에 더 많은 메모리를 할당하지 않도록 합니다.

Jenkins Kubernetes 플러그인에 의해 생성된 에이전트 컨테이너에서 메모리 요청 및 제한 값을 지정하는 것이 좋습니다. 관리자는 Jenkins 구성을 통해 개별 에이전트 이미지를 기반으로 기본값을 설정할 수 있습니다. 메모리 요청 및 제한 매개변수는 개별 컨테이너를 기반으로 재정의할 수도 있습니다.

imagestreamtagJenkins Ephemeral 또는 Jenkins Persistent 템플릿을 인스턴스화하는 경우 MEMORY_LIMIT 매개변수를 재정의하여 Jenkins에서 사용할 수 있는 메모리 크기를 늘릴 수 있습니다.

OpenShift Container Platform Jenkins 에이전트 이미지는 Quay.io 또는 registry.redhat.io 에서 사용할 수 있습니다.

Jenkins 이미지는 Red Hat Registry를 통해 사용할 수 있습니다.

$ 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을 종료하지 않고는 나머지 50%의 메모리 제한을 초과하여 사용할 수 없습니다.

기본적으로 Jenkins 에이전트 컨테이너에서 실행되는 각각의 추가 JVM 프로세스는 힙에 대해 컨테이너 메모리 제한의 최대 25%를 사용합니다. 많은 빌드 워크로드에 대해 이 제한을 튜닝해야 할 수도 있습니다.

OpenShift Container Platform의 Jenkins 에이전트에서 Gradle 빌드를 호스트하면 Jenkins JNLP 에이전트 및 Gradle JVM 외에도 여러 빌드가 지정된 경우 테스트를 실행하는 세 번째 JVM을 Gradle이 생성하므로 복잡성이 더욱 가중됩니다.

다음은 OpenShift Container Platform의 메모리가 제한된 Jenkins 에이전트에서 Gradle 빌드를 실행하기 위한 시작점으로 제안된 설정입니다. 필요에 따라 이러한 설정을 수정할 수 있습니다.

Jenkins 에이전트 pod는 빌드가 완료되거나 중지되면 기본적으로 삭제됩니다. 이 동작은 Kubernetes 플러그인 pod 보존 설정을 통해 변경할 수 있습니다. pod 보존은 각 pod 템플릿에 대한 재정의를 통해 모든 Jenkins 빌드에 대해 설정할 수 있습니다. 지원되는 동작은 다음과 같습니다.

pod 보존은 Pipeline 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 plugin 에 해당하는 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 버전만 지원했으며 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 를 다음 이미지 스트림 태그 중 하나로 바꿉니다.