빌드는 입력 매개변수를 결과 오브젝트로 변환하는 프로세스입니다. 대부분의 경우 프로세스는 입력 매개변수 또는 소스 코드를 실행 가능한 이미지로 변환하는 데 사용됩니다. BuildConfig 오브젝트는 전체 빌드 프로세스에 대한 정의입니다.

OpenShift Container Platform에서는 빌드 이미지에서 컨테이너를 생성하고 이를 컨테이너 이미지 레지스트리로 내보내는 방식으로 Kubernetes를 사용합니다.

빌드 오브젝트는 빌드에 대한 입력, 즉 빌드 프로세스를 완료하고 빌드 프로세스를 로깅한 후 성공한 빌드의 리소스를 게시하고 빌드의 최종 상태를 게시하는 데 필요한 요구 사항과 같은 공통 특징을 공유합니다. 빌드에서는 CPU 사용량, 메모리 사용량, 빌드 또는 Pod 실행 시간과 같은 리소스 제한 사항을 활용합니다.

OpenShift Container Platform 빌드 시스템은 빌드 API에서 지정한 선택 가능한 유형을 기반으로 하는 빌드 전략에 확장 가능한 지원을 제공합니다. 다음은 세 가지 주요 빌드 전략입니다.

기본적으로 Docker 빌드 및 S2I 빌드가 지원됩니다.

빌드의 결과 오브젝트는 빌드를 생성하는 데 사용된 빌더에 따라 다릅니다. Docker 및 S2I 빌드의 경우 결과 오브젝트는 실행 가능한 이미지입니다. 사용자 정의 빌드의 경우 결과 오브젝트는 빌더 이미지 작성자가 지정한 모든 항목입니다.

또한 파이프라인 빌드 전략을 사용하여 정교한 워크플로를 구현할 수 있습니다.

빌드 구성은 단일 빌드 정의와 새 빌드가 생성될 때의 트리거 세트를 나타냅니다. 빌드 구성은 BuildConfig에 의해 정의되는데 BuildConfig는 새 인스턴스를 생성하기 위해 API 서버에 대한 POST에 사용할 수 있는 REST 오브젝트입니다.

빌드 구성 또는 BuildConfig는 빌드 전략 및 하나 이상의 소스가 특징입니다. 전략에 따라 프로세스가 결정되고 소스에서는 입력을 제공합니다.

OpenShift Container Platform을 사용하여 애플리케이션을 생성하기 위해 선택하는 방법에 따라 BuildConfig는 일반적으로 웹 콘솔 또는 CLI를 사용하는 경우 자동으로 생성되며 언제든지 편집할 수 있습니다. BuildConfig를 구성하는 부분과 해당 부분의 사용 가능한 옵션을 이해하면 나중에 구성을 수동으로 변경할 때 도움이 될 수 있습니다.

다음 예제 BuildConfig에서는 컨테이너 이미지 태그 또는 소스 코드가 변경될 때마다 새 빌드를 생성합니다.

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: "ruby-sample-build" 1
spec:
  runPolicy: "Serial" 2
  triggers: 3
    -
      type: "GitHub"
      github:
        secret: "secret101"
    - type: "Generic"
      generic:
        secret: "secret101"
    -
      type: "ImageChange"
  source: 4
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy: 5
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "ruby-20-centos7:latest"
  output: 6
    to:
      kind: "ImageStreamTag"
      name: "origin-ruby-sample:latest"
  postCommit: 7
      script: "bundle exec rake test"

빌드 입력에서는 빌드가 작동하도록 소스 콘텐츠를 제공합니다. 다음 빌드 입력을 사용하여 OpenShift Container Platform에 소스를 제공할 수 있습니다(우선순위 순으로 표시됨).

단일 빌드에서 여러 입력을 결합할 수 있습니다. 그러나 인라인 Dockerfile이 우선하므로 다른 입력에서 제공하는 Dockerfile이라는 기타 파일을 덮어쓸 수 있습니다. 바이너리(local) 입력과 Git 리포지토리는 서로 함께 사용할 수 없는 입력입니다.

빌드 중 사용한 특정 리소스 또는 자격 증명을 빌드에서 생성한 최종 애플리케이션 이미지에 사용하지 않으려는 경우 또는 보안 리소스에 정의된 값을 사용하려는 경우에는 입력 보안을 사용하면 됩니다. 외부 아티팩트를 사용하면 기타 빌드 입력 유형 중 하나로 사용할 수 없는 추가 파일을 가져올 수 있습니다.

빌드를 실행하면 다음이 수행됩니다.

다음 소스 정의 예제에는 다양한 입력 유형 및 이러한 유형이 결합되는 방법에 대한 설명이 포함되어 있습니다. 각 입력 유형이 정의되는 방법에 대한 자세한 내용은 각 입력 유형별 섹션을 참조하십시오.

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git 1
    ref: "master"
  images:
  - from:
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths:
    - destinationDir: app/dir/injected/dir 2
      sourcePath: /usr/lib/somefile.jar
  contextDir: "app/dir" 3
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 4

dockerfile 값을 제공하면 이 필드의 콘텐츠가 dockerfile이라는 파일로 디스크에 작성됩니다. 이 작업은 다른 입력 소스를 처리한 후 수행되므로 입력 소스 리포지토리의 루트 디렉터리에 Dockerfile이 포함된 경우 해당 콘텐츠가 이를 덮어씁니다.

소스 정의는 BuildConfig에 있는 spec 섹션의 일부입니다.

source:
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 1

이미지가 포함된 빌드 프로세스에 파일을 추가할 수 있습니다. 입력 이미지는 From 및 To 이미지 타겟을 정의하는 방식과 동일한 방식으로 참조합니다. 즉 컨테이너 이미지와 이미지 스트림 태그를 모두 참조할 수 있습니다. 이미지와 함께 이미지를 복사할 파일 또는 디렉터리의 경로와 빌드 컨텍스트에서 해당 이미지를 배치할 대상을 나타내는 하나 이상의 경로 쌍을 제공해야 합니다.

소스 경로는 지정된 이미지 내의 모든 절대 경로일 수 있습니다. 대상은 상대 디렉터리 경로여야 합니다. 빌드 시 이미지가 로드되고 표시된 파일과 디렉터리가 빌드 프로세스의 컨텍스트 디렉터리로 복사됩니다. 이 디렉터리는 소스 리포지토리 콘텐츠가 복제되는 것과 동일한 디렉터리입니다. 소스 경로가 /.로 종료되면 디렉터리의 콘텐츠가 복사되지만 디렉터리 자체는 대상에 생성되지 않습니다.

이미지 입력은 BuildConfig의 source 정의에 지정됩니다.

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git
    ref: "master"
  images: 1
  - from: 2
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths: 3
    - destinationDir: injected/dir 4
      sourcePath: /usr/lib/somefile.jar 5
  - from:
      kind: ImageStreamTag
      name: myotherinputimage:latest
      namespace: myothernamespace
    pullSecret: mysecret 6
    paths:
    - destinationDir: injected/dir
      sourcePath: /usr/lib/somefile.jar

$ oc secrets link builder dockerhub

지정하는 경우 입력한 위치에서 소스 코드를 가져옵니다.

인라인 Dockerfile을 제공하는 경우 Git 리포지토리의 contextDir에 Dockerfile을 덮어씁니다.

소스 정의는 BuildConfig에 있는 spec 섹션의 일부입니다.

source:
  git: 1
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 2
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3

ref 필드가 가져오기 요청을 나타내는 경우 시스템은 git fetch 작업을 사용한 후 FETCH_HEAD를 점검합니다.

ref 값을 제공하지 않으면 OpenShift Container Platform에서 부분 복제(--depth=1)를 수행합니다. 이 경우 기본 분기(일반적으로 master)의 최근 커밋과 관련된 파일만 다운로드됩니다. 그러면 리포지토리는 더 빠르게 다운로드되지만 전체 커밋 내역은 다운로드되지 않습니다. 지정된 리포지토리의 기본 분기의 전체 git clone 을 수행하려면 기본 분기 이름(예: main)으로 ref 를 설정합니다.

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...
---
kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...

apiVersion: "build.openshift.io/v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>

[http]
        sslVerify=false

로컬 파일 시스템의 콘텐츠를 빌더로 스트리밍하는 것을 Binary 빌드라고 합니다. 이러한 빌드의 경우 BuildConfig.spec.source.type의 해당 값이 Binary입니다.

이 소스 유형은 oc start-build를 사용할 때만 활용하므로 고유합니다.

바이너리 빌드를 사용하려면 다음 옵션 중 하나를 사용하여 oc start-build를 호출합니다.

위에 나열된 각 사례에서 다음을 수행합니다.

HTTP 또는 HTTPS 스키마를 사용하여 파일 이름 대신 URL을 --from-file 및 --from-archive로 전달할 수 있습니다. URL과 함께 --from-file을 사용하는 경우 빌더 이미지의 파일 이름은 웹 서버에서 전송한 Content-Disposition 헤더 또는 헤더가 없는 경우 URL 경로의 마지막 구성 요소에 따라 결정됩니다. 지원되는 인증 형식이 없는 경우 사용자 정의 TLS 인증서를 사용하거나 인증서 검증 작업을 비활성화할 수 없습니다.

oc new-build --binary=true를 사용하면 명령에서 바이너리 빌드와 관련된 제한을 적용합니다. 생성된 BuildConfig의 소스 유형이 Binary이므로 이 BuildConfig로 빌드를 실행하는 유일한 방법은 --from 옵션 중 하나와 함께 oc start-build를 사용하여 필수 바이너리 데이터를 제공하는 것입니다.

Dockerfile 및 contextDir 소스 옵션에는 바이너리 빌드에서 특별한 의미가 있습니다.

Dockerfile은 바이너리 빌드 소스와 함께 사용할 수 있습니다. Dockerfile을 사용하고 바이너리 스트림이 아카이브인 경우 해당 콘텐츠는 아카이브의 모든 Dockerfile에 대한 대체 Dockerfile 역할을 합니다. Dockerfile을 --from-file 인수와 함께 사용하고 파일 인수의 이름이 Dockerfile인 경우 Dockerfile의 값이 바이너리 스트림의 값을 대체합니다.

추출된 아카이브 콘텐츠를 캡슐화하는 바이너리 스트림의 경우 contextDir 필드의 값이 아카이브 내 하위 디렉터리로 해석되고, 유효한 경우 빌드를 실행하기 전에 빌더가 해당 하위 디렉터리로 변경됩니다.

일부 시나리오에서는 빌드 작업을 수행하려면 종속 리소스에 액세스하기 위해 자격 증명 또는 기타 구성 데이터가 필요합니다. 그러나 이러한 정보가 소스 제어에 배치되는 것은 바람직하지 않습니다. 이러한 용도를 위해 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.

예를 들어 Maven으로 Java 애플리케이션을 빌드할 때 개인 키로 액세스할 수 있는 Maven Central 또는 JCenter의 개인 미러를 설정할 수 있습니다. 해당 개인 미러에서 라이브러리를 다운로드하려면 다음을 제공해야 합니다.

보안상의 이유로 애플리케이션 이미지에 자격 증명을 노출해서는 안 됩니다.

이 예제에서는 Java 애플리케이션을 설명하지만 /etc/ssl/certs 디렉터리, API 키 또는 토큰, 라이선스 파일 등에 SSL 인증서를 추가하는 데 동일한 접근 방식을 사용할 수 있습니다.

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 1
data: 2
  username: <username> 3
  password: <password>
stringData: 4
  hostname: myapp.mydomain.com 5

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn” \
    --build-config-map "settings-mvn"

source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
      destinationDir: ".m2"
  secrets:
    - secret:
        name: secret-mvn
      destinationDir: ".ssh"

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn:.ssh” \
    --build-config-map "settings-mvn:.m2"

FROM centos/ruby-22-centos7

USER root
COPY ./secret-dir /secrets
COPY ./config /

# Create a shell script that will output secrets and ConfigMaps when the image is run
RUN echo '#!/bin/sh' > /input_report.sh
RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh
RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh
RUN chmod 755 /input_report.sh

CMD ["/bin/sh", "-c", "/input_report.sh"]

바이너리 파일을 소스 리포지토리에 저장하지 않는 것이 좋습니다. 따라서 빌드 프로세스 중 Java .jar 종속 항목과 같은 추가 파일을 가져오는 빌드를 정의해야 합니다. 이 작업을 수행하는 방법은 사용 중인 빌드 전략에 따라 다릅니다.

소스 빌드 전략의 경우 assemble 스크립트에 적절한 쉘 명령을 배치해야 합니다.

#!/bin/sh
APP_VERSION=1.0
wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

#!/bin/sh
exec java -jar app.jar

Docker 빌드 전략의 경우 Dockerfile을 수정하고 RUN 명령을 사용하여 쉘 명령을 호출해야 합니다.

FROM jboss/base-jdk:8

ENV APP_VERSION 1.0
RUN wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

EXPOSE 8080
CMD [ "java", "-jar", "app.jar" ]

실제로 Dockerfile 또는 assemble 스크립트를 업데이트하는 대신 BuildConfig에 정의된 환경 변수를 사용하여 다운로드할 특정 파일을 사용자 정의할 수 있도록 파일 위치에 대한 환경 변수를 사용할 수 있습니다.

다음과 같이 환경 변수를 정의하는 다양한 방법 중에서 선택할 수 있습니다.

개인 컨테이너 레지스트리에 유효한 자격 증명이 있는 docker/config.json 파일을 사용하여 빌드를 제공할 수 있습니다. 이 경우 출력 이미지를 개인 컨테이너 이미지 레지스트리로 내보내거나 인증이 필요한 개인 컨테이너 이미지 레지스트리에서 빌더 이미지를 가져올 수 있습니다.

동일한 레지스트리 내에 여러 리포지토리의 인증 정보를 제공할 수 있으며, 각각 해당 레지스트리 경로에 고유한 인증 정보를 제공합니다.

.docker/config.json 파일은 기본적으로 홈 디렉터리에 있으며 다음과 같은 형식을 취합니다.

auths:
  index.docker.io/v1/: 1
    auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 2
    email: "user@example.com" 3
  docker.io/my-namespace/my-user/my-image: 4
    auth: "GzhYWRGU6R2fbclabnRgbkSp=""
    email: "user@example.com"
  docker.io/my-namespace: 5
    auth: "GzhYWRGU6R2deesfrRgbkSp=""
    email: "user@example.com"

여러 컨테이너 이미지 레지스트리를 정의하거나 동일한 레지스트리에 여러 리포지토리를 정의할 수 있습니다. 또는 docker login 명령을 실행하여 이 파일에 인증 항목을 추가할 수도 있습니다. 파일이 없는 경우 생성됩니다.

Kubernetes는 구성 및 암호를 저장하는 데 사용할 수 있는 Secret 오브젝트를 제공합니다.

Pod 환경 변수와 마찬가지로 빌드 환경 변수는 다른 리소스 또는 변수에 대한 참조 측면에서 Downward API를 사용하여 정의할 수 있습니다. 여기에는 잘 알려진 몇 가지 예외가 있습니다.

oc set env 명령을 사용하면 BuildConfig에 정의된 환경 변수도 관리할 수 있습니다.

서비스 제공 인증서 보안은 즉시 사용 가능한 인증서가 필요한 복잡한 미들웨어 애플리케이션을 지원하기 위한 것입니다. 해당 설정은 관리자 툴에서 노드 및 마스터에 대해 생성하는 서버 인증서와 동일합니다.

기타 Pod는 해당 Pod에 자동으로 마운트되는 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 파일의 CA(인증 기관) 번들을 사용하여 내부 DNS 이름에만 서명되는 클러스터 생성 인증서를 신뢰할 수 있습니다.

이 기능의 서명 알고리즘은 x509.SHA256WithRSA입니다. 직접 교대하려면 생성된 보안을 삭제합니다. 새 인증서가 생성됩니다.

보안을 사용하려면 Pod에서 보안을 참조해야 합니다. 보안은 다음 세 가지 방법으로 Pod에서 사용할 수 있습니다.

볼륨 유형 보안은 볼륨 메커니즘을 사용하여 데이터를 컨테이너에 파일로 작성합니다. imagePullSecrets는 서비스 계정을 사용하여 네임스페이스의 모든 Pod에 보안을 자동으로 주입합니다.

템플릿에 보안 정의가 포함된 경우 템플릿에 제공된 보안을 사용할 수 있는 유일한 방법은 보안 볼륨 소스를 검증하고 지정된 오브젝트 참조가 유형이 Secret인 오브젝트를 실제로 가리키는 것입니다. 따라서 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다. 가장 효과적인 방법은 서비스 계정을 사용하여 자동으로 삽입되도록 하는 것입니다.

Secret API 오브젝트는 네임스페이스에 있습니다. 동일한 네임스페이스에 있는 Pod만 참조할 수 있습니다.

개별 보안은 1MB로 제한됩니다. 이는 대규모 보안이 생성되어 apiserver 및 kubelet 메모리가 소진되는 것을 막기 위한 것입니다. 그러나 작은 보안을 많이 생성해도 메모리가 소진될 수 있습니다.

Docker 또는 S2I(source-to-image) 전략을 사용하는 빌드에서는 새 컨테이너 이미지를 생성합니다. 그런 다음 이미지를 Build 사양의 output 섹션에 지정된 컨테이너 이미지 레지스트리로 푸시됩니다.

출력 종류가 ImageStreamTag 인 경우 이미지를 통합 OpenShift 이미지 레지스트리로 푸시하고 지정된 이미지 스트림에 태그를 지정합니다. 출력 유형이 DockerImage인 경우에는 출력 참조 이름이 Docker 내보내기 사양으로 사용됩니다. 사양은 레지스트리를 포함할 수 있으며 레지스트리가 지정되지 않은 경우 기본적으로 DockerHub로 설정됩니다. 빌드 사양의 출력 섹션이 비어 있으면 빌드 종료 시 이미지를 푸시하지 않습니다.

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"

spec:
  output:
    to:
      kind: "DockerImage"
      name: "my-registry.mycompany.com:5000/myimages/myimage:tag"

Docker 및 S2I(Source-to-Image) 전략 빌드에서는 출력 이미지에 다음 환경 변수를 설정합니다.

또한 모든 사용자 정의 환경 변수(예: S2I 또는 Docker 전략 옵션으로 구성된 환경 변수)도 출력 이미지 환경 변수 목록의 일부입니다.

Docker 및 S2I(Source-to-Image)의 빌드에서는 출력 이미지에 다음 라벨을 설정합니다.

BuildConfig.spec.output.imageLabels 필드를 사용하여 빌드 구성에서 빌드하는 각 이미지에 적용할 사용자 정의 라벨 목록을 지정할 수도 있습니다.

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "my-image:latest"
    imageLabels:
    - name: "vendor"
      value: "MyCompany"
    - name: "authoritative-source-url"
      value: "registry.mycompany.com"

OpenShift Container Platform은 Buildah를 사용하여 Dockerfile에서 컨테이너 이미지를 빌드합니다. Dockerfile을 사용하여 컨테이너 이미지를 빌드하는 방법에 대한 자세한 내용은 Dockerfile 참조 문서를 참조하십시오.

strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

dockerStrategy:
...
  buildArgs:
    - name: "foo"
      value: "bar"

S2I(Source-to-Image)는 재현 가능한 컨테이너 이미지를 빌드하는 툴입니다. 컨테이너 이미지에 애플리케이션 소스를 삽입하고 새 이미지를 어셈블하여 실행할 수 있는 이미지를 생성합니다. 새 이미지는 기본 이미지, 빌더, 빌드 소스를 통합하고 buildah run 명령과 함께 사용할 수 있습니다. S2I는 이전에 다운로드한 종속 항목, 이전에 빌드한 아티팩트 등을 다시 사용하는 증분 빌드를 지원합니다.

#!/bin/bash

# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
    mv /tmp/s2i/artifacts/* $HOME/.
fi

# move the application source
mv /tmp/s2i/src $HOME/src

# build application artifacts
pushd ${HOME}
make all

# install the artifacts
make install
popd

#!/bin/bash

# run the application
/opt/application/run.sh

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

#!/bin/bash

# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF

사용자 정의 빌드 전략을 사용하면 개발자가 전체 빌드 프로세스를 담당하는 특정 빌더 이미지를 정의할 수 있습니다. 자체 빌더 이미지를 사용하면 빌드 프로세스를 사용자 정의할 수 있습니다.

사용자 정의 빌더 이미지는 빌드 프로세스 논리가 포함된 일반 컨테이너 이미지입니다(예: RPM 또는 기본 이미지 빌드).

사용자 정의 빌드는 높은 권한으로 실행되며 기본적으로 사용자에게 제공되지 않습니다. 클러스터 관리 권한이 있는 신뢰할 수 있는 사용자에게만 사용자 정의 빌드를 실행할 수 있는 권한을 부여해야 합니다.

파이프라인 빌드 전략을 사용하면 개발자가 Jenkins 파이프라인 플러그인에서 사용할 Jenkins 파이프라인을 정의할 수 있습니다. 다른 빌드 유형과 동일한 방식으로 OpenShift Container Platform에서 빌드를 시작, 모니터링, 관리할 수 있습니다.

파이프라인 워크플로는 빌드 구성에 직접 포함하거나 Git 리포지토리에 제공하는 방식으로 jenkinsfile에 정의하고 빌드 구성에서 참조합니다.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        node('agent') {
          stage 'build'
          openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true')
          stage 'deploy'
          openshiftDeploy(deploymentConfig: 'frontend')
        }

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "sample-pipeline"
spec:
  source:
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfilePath: some/repo/dir/filename 1

개인 리포지토리에 액세스할 수 있도록 빌드 구성에 보안을 추가할 수 있습니다.

빌드 구성에 가져오기 보안을 설정하여 프라이빗 레지스트리로 가져오고 내보내기 보안을 설정하여 내보낼 수 있습니다.

내보내기를 활성화하려면 다음을 수행합니다.

사용자 정의 빌드 이미지로 사용할 이미지를 생성해야 합니다.

OpenShift Container Platform을 사용하여 사용자 정의 전략에서 사용할 사용자 정의 빌더 이미지를 빌드하고 내보낼 수 있습니다.

사용자 정의 빌더 이미지와 함께 사용자 정의 전략을 사용하여 사용자 정의 빌드 논리를 실행하는 BuildConfig 오브젝트를 정의할 수 있습니다.

현재 프로젝트의 기존 빌드 구성에서 새 빌드를 수동으로 시작할 수 있습니다.

$ oc start-build <buildconfig_name>

웹 콘솔을 사용하거나 다음 CLI 명령을 사용하여 빌드를 취소할 수 있습니다.

빌드 구성을 편집하려면 개발자 화면의 빌드 보기에서 빌드 구성 편집 옵션을 사용합니다.

다음 뷰 중 하나를 사용하여 BuildConfig 를 편집할 수 있습니다.

데이터를 손실하지 않고 양식 보기 와 YAML 보기를 전환할 수 있습니다. 양식 보기의 데이터는 YAML 보기로 전송되며 그 반대의 경우도 마찬가지입니다.

다음 명령을 사용하여 BuildConfig를 삭제할 수 있습니다.

웹 콘솔을 사용하거나 oc describe CLI 명령을 사용하여 빌드 세부 정보를 볼 수 있습니다.

다음을 포함한 정보가 표시됩니다.

빌드에서 Docker 또는 Source 전략을 사용하는 경우 oc describe 출력에 커밋 ID, 작성자, 커밋, 메시지 등 해당 빌드에 사용된 소스 리버전 정보도 포함됩니다.

웹 콘솔 또는 CLI를 사용하여 빌드 로그에 액세스할 수 있습니다.

BuildConfig를 정의할 때 BuildConfig를 실행해야 하는 상황을 제어하기 위해 트리거를 정의할 수 있습니다. 다음과 같은 빌드 트리거를 사용할 수 있습니다.

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1

$ oc describe bc <name>

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: bc-ict-example
  namespace: bc-ict-example-namespace
spec:

# ...

  triggers:
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input:latest
        namespace: bc-ict-example-namespace
  - imageChange:
      from:
        kind: ImageStreamTag
        name: input2:latest
        namespace: bc-ict-example-namespace
    type: ImageChange
status:
  imageChangeTriggers:
  - from:
      name: input:latest
      namespace: bc-ict-example-namespace
    lastTriggerTime: "2021-06-30T13:47:53Z"
    lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input@sha256:0f88ffbeb9d25525720bfa3524cb1bf0908b7f791057cf1acfae917b11266a69
  - from:
      name: input2:latest
      namespace: bc-ict-example-namespace
    lastTriggeredImageID:  image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input2@sha256:0f88ffbeb9d25525720bfa3524cb2ce0908b7f791057cf1acfae917b11266a69

  lastVersion: 1

  type: "ConfigChange"

$ oc set triggers --help

빌드 후크를 사용하면 빌드 프로세스에 동작을 삽입할 수 있습니다.

BuildConfig 오브젝트의 postCommit 필드는 빌드 출력 이미지를 실행하는 임시 컨테이너 내에서 명령을 실행합니다. 후크는 이미지의 마지막 계층을 커밋한 직후 그리고 이미지를 레지스트리로 푸시되기 전에 실행됩니다.

현재 작업 디렉터리는 이미지의 WORKDIR로 설정되어 있으며 이는 컨테이너 이미지의 기본 작업 디렉터리입니다. 대부분의 이미지에서 이 디렉터리는 소스 코드가 있는 위치입니다.

스크립트 또는 명령에서 0이 아닌 종료 코드를 반환하거나 임시 컨테이너를 시작하지 못하는 경우 후크가 실패합니다. 후크가 실패하면 빌드가 실패로 표시되고 이미지를 레지스트리로 푸쉬하지 않습니다. 실패 이유는 빌드 로그를 확인하여 검사할 수 있습니다.

빌드 후크를 사용하면 빌드를 완료로 표시하고 레지스트리에 이미지를 제공하기 전에 단위 테스트를 실행하여 이미지를 확인할 수 있습니다. 모든 테스트를 통과하고 테스트 실행기에서 종료 코드 0을 반환하면 빌드가 성공으로 표시됩니다. 실패한 테스트가 있는 경우 빌드가 실패로 표시됩니다. 어떠한 경우든 빌드 로그에는 테스트 실행기의 출력이 포함되므로 실패한 테스트를 확인할 수 있습니다.

postCommit 후크는 테스트 실행뿐만 아니라 다른 명령에도 사용할 수 있습니다. 이 후크는 임시 컨테이너에서 실행되기 때문에 후크에 의한 변경 사항은 지속되지 않습니다. 즉 후크를 실행해도 최종 이미지에는 영향을 미치지 않습니다. 이러한 동작으로 인해 특히 자동으로 삭제되어 최종 이미지에 존재하지 않는 테스트 종속 항목을 설치하고 사용할 수 있습니다.

기본적으로 빌드는 Pod에서 메모리 및 CPU와 같이 바인딩되지 않은 리소스를 사용하여 완료합니다. 이러한 리소스는 제한될 수 있습니다.

BuildConfig 오브젝트를 정의할 때는 completionDeadlineSeconds 필드를 설정하여 최대 기간을 정의할 수 있습니다. 이는 초 단위로 지정되며 기본적으로 설정되어 있지 않습니다. 설정하지 않으면 최대 기간이 적용되지 않습니다.

최대 기간은 시스템에서 빌드 Pod를 예약하는 시점부터 계산되며 빌더 이미지를 가져오는 데 필요한 시간을 포함하여 활성화할 수 있는 기간을 정의합니다. 지정된 타임아웃에 도달하면 OpenShift Container Platform에서 빌드를 종료합니다.

빌드 구성의 nodeSelector 필드에 라벨을 지정하면 빌드가 특정 노드에서 실행되도록 타겟을 지정할 수 있습니다. nodeSelector 값은 빌드 Pod를 예약할 때 Node 라벨과 일치하는 일련의 키-값 쌍입니다.

nodeSelector 값은 클러스터 전체 기본값 및 덮어쓰기 값으로도 제어할 수 있습니다. 기본값은 빌드 구성에서 nodeSelector에 키-값 쌍을 정의하지 않고 명시적으로 비어 있는 맵 값(nodeSelector:{})도 정의하지 않는 경우에만 적용됩니다. 덮어쓰기 값은 키에 따라 빌드 구성의 값을 대체합니다.

Go, C, C++, Java와 같이 컴파일된 언어의 경우 애플리케이션 이미지에서 컴파일하는 데 필요한 종속 항목을 포함하면 이미지 크기가 늘어나거나 악용될 수 있는 취약점이 발생할 수 있습니다.

이러한 문제를 방지하기 위해 두 개의 빌드를 함께 연결할 수 있습니다. 하나는 컴파일된 아티팩트를 생성하는 빌드이고 다른 하나는 해당 아티팩트를 실행하는 별도의 이미지에 아티팩트를 배치하는 빌드입니다.

다음 예제에서는 S2I(source-to-image) 빌드가 Docker 빌드와 결합되어 아티팩트를 컴파일하고 해당 아티팩트는 별도의 런타임 이미지에 배치됩니다.

첫 번째 빌드에서는 애플리케이션 소스를 가져와서 WAR 파일이 포함된 이미지를 생성합니다. 이미지는 artifact-image 이미지 스트림으로 푸쉬합니다. 출력 아티팩트의 경로는 사용된 S2I 빌더의 assemble 스크립트에 따라 달라집니다. 다음 예제의 경우 /wildfly/standalone/deployments/ROOT.war로 출력됩니다.

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: artifact-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: artifact-image:latest
  source:
    git:
      uri: https://github.com/openshift/openshift-jee-sample.git
      ref: "master"
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: wildfly:10.1
        namespace: openshift

두 번째 빌드에서는 이미지 소스와 첫 번째 빌드의 출력 이미지 내부에 있는 WAR 파일에 대한 경로를 사용합니다. 인라인 dockerfile은 해당 WAR 파일을 런타임 이미지에 복사합니다.

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: image-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: image-build:latest
  source:
    dockerfile: |-
      FROM jee-runtime:latest
      COPY ROOT.war /deployments/ROOT.war
    images:
    - from: 1
        kind: ImageStreamTag
        name: artifact-image:latest
      paths: 2
      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from: 3
        kind: ImageStreamTag
        name: jee-runtime:latest
  triggers:
  - imageChange: {}
    type: ImageChange

이 설정으로 인해 두 번째 빌드의 출력 이미지에 WAR 파일을 생성하는 데 필요한 빌드 툴을 포함하지 않아도 됩니다. 또한 두 번째 빌드에는 이미지 변경 트리거가 포함되어 있기 때문에 첫 번째 빌드가 실행되어 바이너리 아티팩트가 포함된 새 이미지를 생성할 때마다 두 번째 빌드가 자동으로 트리거되어 해당 아티팩트가 포함된 런타임 이미지를 생성합니다. 따라서 두 빌드 모두 두 단계가 있는 단일 빌드로 작동합니다.

기본적으로 라이프사이클이 완료된 빌드는 무기한 유지됩니다. 유지되는 이전 빌드의 수를 제한할 수 있습니다.

빌드는 생성 타임스탬프에 따라 정렬되고 가장 오래된 빌드가 가장 먼저 정리됩니다.

빌드 실행 정책은 빌드 구성에서 생성한 빌드를 실행할 순서를 지정합니다. 이 작업은 Build 사양의 spec 섹션에서 runPolicy 필드 값을 변경하여 수행할 수 있습니다.

다음과 같이 기존 빌드 구성의 runPolicy 값을 변경할 수도 있습니다.

빌드 내에서 Red Hat 서브스크립션을 사용하려면 UBI(Universal Base Image)를 참조하는 이미지 스트림 태그를 생성합니다.

클러스터의 모든 프로젝트에서 UBI를 사용할 수 있도록 하려면 openshift 네임스페이스에 이미지 스트림 태그를 추가합니다. 또는 UBI를 특정 프로젝트에서 사용할 수 있도록 하려면 해당 프로젝트에 이미지 스트림 태그를 추가합니다.

이미지 스트림 태그를 이러한 방식으로 사용할 때의 이점은 다른 사용자에게 가져오기 보안을 노출하지 않고 설치의 registry.redhat.io 자격 증명에 따라 UBI에 대한 액세스 권한을 부여할 수 있다는 점입니다. 이 방식은 각 개발자에게 각 프로젝트에서 registry.redhat.io 자격 증명을 사용하여 가져오기 보안을 설치하도록 요구하는 방식보다 편리합니다.

Red Hat 서브스크립션을 사용하여 콘텐츠를 설치하는 빌드에는 자격 키가 빌드 보안으로 포함되어야 합니다.

RUN rm /etc/rhsm-host

다른 네임스페이스의 Secret 오브젝트에서 RHEL 인타이틀먼트를 안전하게 사용하는 하나의 네임스페이스에서 빌드를 구성하고 수행할 수 있습니다.

Build 오브젝트와 동일한 네임스페이스에서 서브스크립션 자격 증명으로 Secret 오브젝트를 생성하여 OpenShift 빌드의 RHEL 인타이틀먼트에 계속 액세스할 수 있습니다. 그러나 OpenShift Container Platform 4.10 이상에서는 OpenShift Container Platform 시스템 네임스페이스 중 하나에서 Secret 오브젝트에서 인증 정보 및 인증서에 액세스할 수 있습니다. Secret 오브젝트를 참조하는 SharedSecret CR(사용자 정의 리소스) 인스턴스의 CSI 볼륨 마운트를 사용하여 권한이 있는 빌드를 실행합니다.

이 절차에서는 OpenShift Container Platform 빌드에서 CSI 볼륨 마운트를 선언하는 데 사용할 수 있는 새로 도입된 Shared Resources CSI Driver 기능을 사용합니다. 또한 OpenShift Container Platform Insights Operator를 사용합니다.

특정 빌드 전략에 대한 액세스를 전역적으로 방지하려면 클러스터 관리자 권한이 있는 사용자로 로그인하여 system:authenticated 그룹에서 해당 역할을 제거한 후 주석 rbac.authorization.kubernetes.io/autoupdate: "false"를 적용하여 API를 재시작할 때마다 변경되지 않도록 보호하십시오. 다음 예제에서는 Docker 빌드 전략을 비활성화하는 방법을 보여줍니다.

특정 사용자 집합이 특정 전략을 사용하여 빌드를 생성하도록 허용할 수 있습니다.

전역적으로 사용자에게 빌드 전략 역할을 부여하는 것과 유사하게 프로젝트 내의 특정 사용자 집합이 특정 전략을 사용하여 빌드를 생성하도록 허용할 수 있습니다.

build.config.openshift.io/cluster 리소스에서는 다음과 같은 구성 매개변수를 제공합니다.

build.config.openshift.io/cluster 리소스를 편집하여 빌드 설정을 구성할 수 있습니다.

리소스에 대한 액세스 요청이 거부되는 경우:

requested access to the resource is denied

$ oc describe quota

리소스에 대한 액세스 요청이 거부되는 경우:

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

$ oc delete secret <secret_name>

$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-

$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-

다음 절차에 따라 이미지를 내보내고 가져올 때 사용할 클러스터에 인증서 CA(인증 기관)를 추가할 수 있습니다.

Red Hat OpenShift GitOps는 다음 작업을 자동화하는 데 도움이 됩니다.

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 템플릿 이미지로 자동 구성됩니다. 해당 구성에는 이 프로젝트를 실행할 수 있는 제한 아래의 모든 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 네임스페이스에서 이미지 스트림을 참조하는 두 개의 컨테이너를 보여줍니다. 하나의 컨테이너는 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>

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 포드 템플릿을 사용하는 이 형식의 예는 다음과 같습니다.

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 를 다음 이미지 스트림 태그 중 하나로 바꿉니다.