5장. Jenkins


5.1. Jenkins 이미지 구성

OpenShift Container Platform은 실행 중인 Jenkins에 대한 컨테이너 이미지를 제공합니다. 이 이미지는 Jenkins 서버 인스턴스를 제공하며, 지속적인 테스트, 통합 및 제공을 위한 기본 흐름을 설정하는 데 사용할 수 있습니다.

이미지는 Red Hat UBI(Universal Base Images)를 기반으로 합니다.

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/ocp-tools-4/jenkins-rhel8:<image_tag>

이러한 이미지를 사용하려면 해당 레지스트리에서 직접 이미지에 액세스하거나 OpenShift Container Platform 컨테이너 이미지 레지스트리로 이미지를 푸시할 수 있습니다. 컨테이너 이미지 레지스트리 또는 외부 위치에서 이미지를 가리키는 이미지 스트림을 생성할 수도 있습니다. 그러면 OpenShift Container Platform 리소스에서 이미지 스트림을 참조할 수 있습니다.

하지만 편의를 위해 OpenShift Container Platform은 openshift 네임스페이스에서 핵심 Jenkins 이미지를 위한 이미지 스트림은 물론 Jenkins와 OpenShift Container Platform의 통합을 위한 에이전트 이미지 예제도 제공합니다.

5.1.1. 구성 및 사용자 정의

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

  • OpenShift Container Platform 로그인 플러그인에서 제공하는 OpenShift Container Platform OAuth 인증
  • Jenkins에서 제공하는 표준 인증

5.1.1.1. OpenShift Container Platform OAuth 인증

OAuth 인증은 Jenkins UI의 글로벌 보안 구성 패널에서 옵션을 구성하거나 Jenkins 배포 구성에서 OPENSHIFT_ENABLE_OAUTH 환경 변수를 false 이외의 값으로 설정하면 활성화됩니다. 이렇게 하면 Pod 데이터에서 구성 정보를 검색하거나 OpenShift Container Platform API 서버와 상호 작용하는 OpenShift Container Platform 로그인 플러그인이 활성화됩니다.

유효한 인증 정보는 OpenShift Container Platform ID 공급자가 제어합니다.

Jenkins는 브라우저 액세스 및 브라우저 이외의 액세스를 둘 다 지원합니다.

유효한 사용자는 로그인 시 Jenkins 권한 부여 매트릭스에 자동으로 추가되며 OpenShift Container Platform 역할에 따라 사용자가 가지는 특정 Jenkins 권한이 지정됩니다. 기본적으로 사용되는 역할은 사전 정의된 admin, editview입니다. 로그인 플러그인은 Jenkins가 실행되는 네임스페이스 또는 프로젝트에서 해당 역할에 대해 자체AR 요청을 실행합니다.

admin 역할의 사용자에게는 기존 Jenkins 관리자 권한이 있습니다. edit 또는 view 역할의 사용자는 점차 더 적은 권한을 가지게 됩니다.

기본 OpenShift Container Platform admin, editview 역할과 Jenkins 인스턴스에서 해당 역할이 할당된 Jenkins 권한은 구성할 수 있습니다.

OpenShift Container Platform Pod에서 Jenkins를 실행하는 경우 로그인 플러그인은 Jenkins가 실행되는 네임스페이스에서 openshift-jenkins-login-plugin-config 라는 구성 맵을 찾습니다.

이 플러그인이 해당 구성 맵을 찾아서 읽을 수 있는 경우 Jenkins 권한 매핑에 대해 역할을 정의할 수 있습니다. 특히 다음 내용에 유의하십시오.

  • 로그인 플러그인은 구성 맵의 키 및 값 쌍을 OpenShift Container Platform 역할 매핑에 대한 Jenkins 권한으로 처리합니다.
  • 키는 Jenkins 권한 그룹 짧은 ID와 Jenkins 권한 짧은 ID이며 두 개가 하이픈 문자로 구분되어 있습니다.
  • OpenShift Container Platform 역할에 Overall Jenkins Administer 권한을 추가하려면 키가 Overall-Administer여야 합니다.
  • 사용 가능한 권한 그룹 및 권한 ID를 파악하려면 Jenkins 콘솔 및 ID의 매트릭스 권한 부여 페이지로 이동하여 제공된 테이블의 그룹 및 개인 권한을 확인합니다.
  • 키 및 값 쌍의 값은 권한이 적용되어야 하며 각 역할이 쉼표로 구분되어 있는 OpenShift Container Platform 역할의 목록입니다.
  • 기본 adminedit 역할과 생성한 새 jenkins 역할 모두에 Overall Jenkins Administer 권한을 추가하려면 키 Overall-Administer의 값이 admin,edit,jenkins가 됩니다.
참고

OpenShift Container Platform OAuth가 사용되는 경우 OpenShift Container Platform Jenkins 이미지에서 관리자 권한으로 미리 입력된 admin 사용자에게는 해당 권한이 부여되지 않습니다. 이러한 권한을 부여하려면 OpenShift Container Platform 클러스터 관리자가 OpenShift Container Platform ID 공급자에서 해당 사용자를 명시적으로 정의하고 이 사용자에게 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 서비스를 생성하는 가장 쉬운 방법은 템플릿을 사용하는 것입니다.

5.1.1.2. Jenkins 인증

템플릿을 사용하지 않고 이미지를 직접 실행하는 경우 기본적으로 Jenkins 인증이 사용됩니다.

Jenkins가 처음 시작되면 관리자 및 암호와 함께 구성이 생성됩니다. 기본 사용자 인증 정보는 adminpassword입니다. 표준 Jenkins 인증을 사용하는 경우에만 JENKINS_PASSWORD 환경 변수를 설정하여 기본 암호를 구성합니다.

프로세스

  • 표준 Jenkins 인증을 사용하는 Jenkins 애플리케이션을 생성합니다.

    $ oc new-app -e \
        JENKINS_PASSWORD=<password> \
        ocp-tools-4/jenkins-rhel8

5.1.2. Jenkins 환경 변수

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

변수정의값 및 설정 예

OPENSHIFT_ENABLE_OAUTH

Jenkins에 로그인할 때 OpenShift Container Platform 로그인 플러그인이 인증을 관리하는지 여부를 결정합니다. 활성화하려면 true로 설정합니다.

기본값: false

JENKINS_PASSWORD

표준 Jenkins 인증을 사용하는 경우 admin 사용자의 암호입니다. OPENSHIFT_ENABLE_OAUTHtrue로 설정된 경우 해당되지 않습니다.

기본값: password

JAVA_MAX_HEAP_PARAM, CONTAINER_HEAP_PERCENT, JENKINS_MAX_HEAP_UPPER_BOUND_MB

이 값은 Jenkins JVM의 최대 힙 크기를 제어합니다. JAVA_MAX_HEAP_PARAM이 설정된 경우 해당 값이 우선합니다. 설정되지 않은 경우 최대 힙 크기는 컨테이너 메모리 제한의 CONTAINER_HEAP_PERCENT로 동적으로 계산되며, 선택적으로 JENKINS_MAX_HEAP_UPPER_BOUND_MBMiB로 제한될 수 있습니다.

기본적으로 Jenkins JVM의 최대 힙 크기는 제한 없이 컨테이너 메모리 제한의 50%로 설정됩니다.

JAVA_MAX_HEAP_PARAM 설정 예: -Xmx512m

CONTAINER_HEAP_PERCENT 기본값: 0.5 또는 50%

JENKINS_MAX_HEAP_UPPER_BOUND_MB 설정 예: 512 MiB

JAVA_INITIAL_HEAP_PARAM, CONTAINER_INITIAL_PERCENT

이 값은 Jenkins JVM의 초기 힙 크기를 제어합니다. JAVA_INITIAL_HEAP_PARAM이 설정된 경우 해당 값이 우선합니다. 설정되지 않은 경우 초기 힙 크기는 동적으로 계산된 최대 힙 크기의 CONTAINER_INITIAL_PERCENT로 동적으로 계산됩니다.

기본적으로 JVM은 초기 힙 크기를 설정합니다.

JAVA_INITIAL_HEAP_PARAM 설정 예: -Xms32m

CONTAINER_INITIAL_PERCENT 설정 예: 0.1 또는 10%

CONTAINER_CORE_LIMIT

설정되는 경우 내부 JVM 스레드 수를 조정하는 데 사용되는 정수 코어 수를 지정합니다.

설정 예: 2

JAVA_TOOL_OPTIONS

이 컨테이너에서 실행되는 모든 JVM에 적용할 옵션을 지정합니다. 이 값은 재정의하지 않는 것이 좋습니다.

Default: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true

JAVA_GC_OPTS

Jenkins JVM 가비지 컬렉션 매개변수를 지정합니다. 이 값은 재정의하지 않는 것이 좋습니다.

Default: -XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90

JENKINS_JAVA_OVERRIDES

Jenkins JVM에 대한 추가 옵션을 지정합니다. 이러한 옵션은 위의 Java 옵션을 포함하여 다른 모든 옵션에 추가되며 필요한 경우 옵션을 재정의하는 데 사용될 수 있습니다. 각각의 추가 옵션을 공백으로 구분합니다. 옵션에 공백 문자가 포함되어 있으면 백슬래시로 이스케이프합니다.

설정 예: -Dfoo -Dbar; -Dfoo=first\ value -Dbar=second\ value

JENKINS_OPTS

Jenkins에 대한 인수를 지정합니다.

 

INSTALL_PLUGINS

컨테이너를 처음 실행할 때 또는 OVERRIDE_PV_PLUGINS_IMAGE_PLUGINStrue 로 설정된 경우 설치할 추가 Jenkins 플러그인을 지정합니다. 플러그인은 쉼표로 구분된 이름:버전 쌍 목록으로 지정됩니다.

설정 예: git:3.7.0,subversion:2.10.2

OPENSHIFT_PERMISSIONS_POLL_INTERVAL

OpenShift Container Platform 로그인 플러그인이 Jenkins에서 정의된 각 사용자와 연결된 권한에 대해 OpenShift Container Platform을 폴링하는 간격(밀리초)을 지정합니다.

기본값: 300000 - 5분

OVERRIDE_PV_CONFIG_WITH_IMAGE_CONFIG

Jenkins 구성 디렉토리에 대해 OpenShift Container Platform 영구 볼륨(PV)을 사용하여 이 이미지를 실행하는 경우 영구 볼륨 클레임(PVC) 이 생성되면 영구 볼륨이 할당되므로 이미지가 처음 시작될 때만 이미지에서 영구 볼륨으로 구성 전송을 수행합니다. 이 이미지를 확장하고 초기 시작 후 사용자 정의 이미지의 구성을 업데이트하는 사용자 정의 이미지를 생성하는 경우 이 환경 변수를 true 로 설정하지 않으면 구성이 복사되지 않습니다.

기본값: false

OVERRIDE_PV_PLUGINS_WITH_IMAGE_PLUGINS

Jenkins 구성 디렉토리에 대해 OpenShift Container Platform PV를 사용하여 이 이미지를 실행하는 경우 PVC가 생성될 때 PV가 할당되므로 이미지가 처음 시작될 때만 이미지에서 PV로 플러그인 전송을 수행합니다. 초기 시작 후 이 이미지를 확장하고 사용자 정의 이미지의 플러그인을 업데이트하는 사용자 정의 이미지를 생성하는 경우 이 환경 변수를 true 로 설정하지 않으면 플러그인이 복사되지 않습니다.

기본값: false

ENABLE_FATAL_ERROR_LOG_FILE

Jenkins 구성 디렉토리에 대해 OpenShift Container Platform 영구 볼륨 클레임(PVC)으로 이 이미지를 실행하는 경우 이 환경 변수를 사용하면 치명적 오류가 발생할 때 치명적 오류 로그 파일을 유지할 수 있습니다. 치명적 오류 파일은 /var/lib/jenkins/logs에 저장됩니다.

기본값: false

AGENT_BASE_IMAGE

이 값을 설정하면 이 이미지와 함께 제공되는 샘플 Kubernetes 플러그인 pod 템플릿에서 jnlp 컨테이너에 사용되는 이미지가 재정의됩니다. 그러지 않으면 openshift 네임스페이스의 jenkins-agent-base-rhel8:latest 이미지 스트림 태그의 이미지가 사용됩니다.

default: image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest

JAVA_BUILDER_IMAGE

이 값을 설정하면 이 이미지와 함께 제공된 java-builder 샘플 Kubernetes 플러그인 pod 템플릿에서 java-builder 컨테이너에 사용되는 이미지가 재정의됩니다. 그러지 않으면 openshift 네임스페이스의 java:latest 이미지 스트림 태그의 이미지가 사용됩니다.

default: image-registry.openshift-image-registry.svc:5000/openshift/java:latest

NODEJS_BUILDER_IMAGE

이 값을 설정하면 이 이미지와 함께 제공된 nodejs-builder 샘플 Kubernetes 플러그인 pod 템플릿에서 nodejs-builder 컨테이너에 사용되는 이미지가 재정의됩니다. 그러지 않으면 openshift 네임스페이스의 nodejs:latest 이미지 스트림 태그 이미지가 사용됩니다.

default: image-registry.openshift-image-registry.svc:5000/openshift/nodejs:latest

JAVA_FIPS_OPTIONS

이 값을 설정하면 FIPS 노드에서 실행할 때 JVM이 작동하는 방식을 제어합니다. 자세한 내용은 FIPS 모드에서 OpenJDK 11 구성을 참조하십시오.

기본값: -Dcom.redhat.fips=false

5.1.3. Jenkins에 프로젝트 간 액세스 권한 제공

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

프로세스

  1. 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로 지정됩니다.

  2. 시크릿에서 토큰을 검색합니다.

    $ 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가 프로젝트에 액세스하는 데 필요한 토큰 값이 포함되어 있습니다.

5.1.4. Jenkins 볼륨 간 마운트 지점

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

  • /var/lib/jenkins - Jenkins가 작업 정의를 비롯한 구성 파일을 저장하는 데이터 디렉토리입니다.

5.1.5. S2I(Source-to-Image)를 통해 Jenkins 이미지 사용자 정의

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

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

1
source 매개변수는 위에서 설명한 레이아웃으로 소스 Git 리포지터리를 정의합니다.
2
strategy 매개변수는 빌드의 소스 이미지로 사용할 원본 Jenkins 이미지를 정의합니다.
3
output 매개변수는 공식 Jenkins 이미지 대신 배포 구성에 사용할 수 있는 사용자 정의 Jenkins 이미지를 정의합니다.

5.1.6. Jenkins Kubernetes 플러그인 구성

OpenShift Jenkins 이미지에는 Kubernetes 및 OpenShift Container Platform을 사용하여 여러 컨테이너 호스트에서 Jenkins 에이전트를 동적으로 프로비저닝할 수 있도록 사전 설치된 Kubernetes 플러그인이 포함되어 있습니다.

Kubernetes 플러그인을 사용하기 위해 OpenShift Container Platform은 Jenkins 에이전트로 사용하기에 적합한 이미지(기본, Maven, Node.js)를 제공합니다.

중요

OpenShift Container Platform 4.11은 OpenShift Jenkins 및 OpenShift Agent Base 이미지를 registry.redhat.io 에서 ocp-tools-4 리포지토리로 이동하여 Red Hat이 OpenShift Container Platform 라이프사이클 외부에서 이미지를 생성하고 업데이트할 수 있습니다. 이전에는 이러한 이미지가 OpenShift Container Platform 설치 페이로드에 있고 registry.redhat.ioopenshift4 리포지토리에 있었습니다.

OpenShift Container Platform 4.11은 페이로드에서 OpenShift Jenkins Maven 및 NodeJS 에이전트 이미지를 제거합니다. Red Hat은 더 이상 이러한 이미지를 생성하지 않으며 registry.redhat.ioocp-tools-4 리포지토리에서 사용할 수 없습니다. Red Hat은 OpenShift Container Platform 라이프 사이클 정책에 따라 중요한 버그 수정 또는 보안 CVE에 대해 이러한 이미지의 4.10 및 이전 버전을 유지 관리합니다.

자세한 내용은 다음 "추가 리소스" 섹션의 "OpenShift Jenkins 이미지에 중요한 변경 사항" 링크를 참조하십시오.

Maven 및 Node.js 에이전트 이미지 둘 다 OpenShift Container Platform Jenkins 이미지 구성에 Kubernetes pod 템플릿 이미지로 자동 구성됩니다. 해당 구성에는 이 프로젝트를 실행할 수 있는 제한 설정에 따라 모든 Jenkins 작업에 적용할 수 있는 각 이미지의 레이블이 포함되어 있습니다. 레이블이 적용되면 해당 에이전트 이미지를 실행하는 OpenShift Container Platform pod에서 작업이 실행됩니다.

중요

OpenShift Container Platform 4.10 이상에서는 Kubernetes 플러그인을 사용하여 Jenkins 에이전트를 실행하는 데 권장되는 패턴은 jnlp사이드카 컨테이너 모두에서 Pod 템플릿을 사용하는 것입니다. jnlp 컨테이너는 OpenShift Container Platform Jenkins Base 에이전트 이미지를 사용하여 빌드에 별도의 Pod를 쉽게 시작할 수 있습니다. 사이드카 컨테이너 이미지에는 시작된 별도의 Pod 내에서 특정 언어로 빌드하는 데 필요한 도구가 있습니다. Red Hat Container Catalog의 많은 컨테이너 이미지는 openshift 네임스페이스에 있는 샘플 이미지 스트림에서 참조됩니다. OpenShift Container Platform Jenkins 이미지에는 이 방법을 보여주는 사이드카 컨테이너가 포함된 java-buildnodejs-builder 라는 두 개의 포드 템플릿이 있습니다. 이 두 pod 템플릿은 openshift 네임스페이스의 javanodejs 이미지 스트림에서 제공하는 최신 Java 및 NodeJS 버전을 사용합니다.

이번 업데이트를 통해 OpenShift Container Platform 4.10 이상에서는 Jenkins용 타사 mavennodejs pod 템플릿이 더 이상 사용되지 않습니다. 이러한 Pod 템플릿은 향후 릴리스에서 제거될 예정입니다. 버그 수정 및 지원은 향후 라이프사이클이 끝나면 새로운 기능 개선 사항을 통해 제공됩니다.

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

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

  • role 레이블이 jenkins-agent로 설정된 이미지 스트림
  • role 주석이 jenkins-agent로 설정된 이미지 스트림 태그
  • role 레이블이 jenkins-agent로 설정된 구성 맵

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

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

참고

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>
          // Writer, remove or update this in 4.12
          <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 네임스페이스에 있는 이미지 스트림을 참조하는 두 개의 컨테이너를 보여줍니다. 하나의 컨테이너는 Pod를 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>
참고

Jenkins 콘솔에 로그인하고 pod 템플릿이 생성된 후 pod 템플릿 구성을 추가로 변경하고 OpenShift Container Platform 동기화 플러그인에서 구성 맵이 변경되었음을 탐지하면 pod 템플릿을 교체하고 해당 구성 변경 사항을 덮어씁니다. 새 구성은 기존 구성과 병합할 수 없습니다.

Jenkins 콘솔에 로그인하지 말고 pod 템플릿 구성을 변경합니다. Pod 템플릿이 생성된 후 이를 수행하고 OpenShift Container Platform 동기화 플러그인에서 이미지 스트림 또는 이미지 스트림 태그와 연결된 이미지가 변경되었음을 탐지하면 pod 템플릿을 교체하고 구성 변경 사항을 덮어씁니다. 새 구성은 기존 구성과 병합할 수 없습니다.

보다 복잡한 구성이 필요한 경우 구성 맵 접근 방법을 고려하십시오.

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

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

  • 구성 맵, 이미지 스트림 또는 이미지 스트림 태그에서 레이블 또는 주석을 제거하면 Kubernetes 플러그인 구성에서 기존 PodTemplate 이 삭제됩니다.
  • 이러한 오브젝트가 제거되면 Kubernetes 플러그인에서 해당 구성이 제거됩니다.
  • 레이블 또는 주석이 적절히 지정된 ConfigMap, ImageStream 또는 ImageStreamTag 오브젝트를 생성하거나 초기 생성 후 레이블을 추가하면 Kubernetes 플러그인 구성에서 PodTemplate이 생성됩니다.
  • 구성 맵 형식별 PodTemplate 의 경우 PodTemplate의 구성 맵 데이터에 대한 변경 사항이 Kubernetes 플러그인 구성의 PodTemplate 설정에 적용되며 구성 맵 변경 간에 Jenkins UI를 통해 변경한 PodTemplate 변경 사항을 덮어씁니다.

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

5.1.7. 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 동기화 플러그인에서 자동으로 검색되는 pod 템플릿은 서비스 계정으로 Jenkins 마스터 서비스 계정을 사용하도록 구성됩니다.
  • Jenkins 및 Kubernetes 플러그인에 pod 템플릿 정의를 제공할 수 있는 다른 방법의 경우 사용할 서비스 계정을 명시적으로 지정해야 합니다. 다른 방법으로는 Jenkins 콘솔, Kubernetes 플러그인에서 제공하는 podTemplate 파이프라인 DSL 또는 pod 템플릿의 XML 구성 데이터가 있는 구성 맵에 레이블을 지정하는 방법이 있습니다.
  • 서비스 계정의 값을 지정하지 않으면 default 서비스 계정이 사용됩니다.
  • 사용할 서비스 계정이 OpenShift Container Platform 내에 정의된 필요한 권한, 역할 등을 가지고 있어서 pod에서 선택한 모든 프로젝트를 조작할 수 있는지 확인하십시오.

5.1.8. 템플릿에서 Jenkins 서비스 생성

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

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

참고

pod가 다른 노드로 이동되거나 배포 구성 업데이트에 따라 재배포가 트리거되는 경우 pod가 재시작될 수 있습니다.

  • jenkins-ephemeral에서는 ephemeral 스토리지를 사용합니다. pod를 다시 시작하면 모든 데이터가 손실됩니다. 이 템플릿은 개발 또는 테스트에만 유용합니다.
  • jenkins-persistent에서는 영구 볼륨 (PV) 저장소를 사용합니다. pod를 다시 시작해도 데이터가 유지됩니다.

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

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

프로세스

  1. 다음 방법 중 하나를 사용하여 새 Jenkins 애플리케이션을 생성합니다.

    • A PV:

      $ oc new-app jenkins-persistent
    • pod를 다시 시작하면 구성이 유지되지 않는 emptyDir 유형 볼륨:

      $ oc new-app jenkins-ephemeral

두 템플릿을 모두 사용하면 oc describe 를 실행하여 덮어쓰기에 사용할 수 있는 모든 매개변수를 확인할 수 있습니다.

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

$ oc describe jenkins-ephemeral

5.1.9. Jenkins Kubernetes 플러그인 사용

다음 예에서는 openshift-jee-sample BuildConfig 오브젝트로 인해 Jenkins Maven 에이전트 pod가 동적으로 프로비저닝됩니다. pod는 일부 Java 소스 코드를 복제하고 WAR 파일을 빌드하며 두 번째 BuildConfigopenshift-jee-sample-docker가 실행되도록 합니다. 두 번째 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 플러그인을 사용하여 메모리 제한 및 환경 변수를 지정하는 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
값이 0.25인 환경 변수 CONTAINER_HEAP_PERCENT가 지정되었습니다.
9
노드 스탠자는 정의된 pod 템플릿의 이름을 참조합니다.

기본적으로 pod는 빌드가 완료되면 삭제됩니다. 이 동작은 플러그인 또는 파이프라인 Jenkinsfile 내에서 수정할 수 있습니다.

업스트림 Jenkins는 파이프라인과 함께 podTemplate 파이프라인 DSL을 정의하기 위해 최근에 YAML 선언적 형식을 도입했습니다. OpenShift Container Platform Jenkins 이미지에 정의된 샘플 java-builder 포드 템플릿을 사용하는 이 형식의 예는 다음과 같습니다.

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"
        }
     }
    }
  }
}

5.1.10. Jenkins 메모리 요구 사항

제공된 Jenkins Ephemeral 또는 Jenkins Persistent 템플릿으로 배포하는 경우 기본 메모리 제한은 1Gi입니다.

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

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

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

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

5.1.11. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.