CI/CD

OpenShift Container Platform 4.13

OpenShift Container Platform의 빌드, 파이프라인, GitOps에 대한 정보 제공

Red Hat OpenShift Documentation Team

초록

OpenShift Container Platform의 CI/CD

1장. OpenShift Container Platform CI/CD 개요

OpenShift Container Platform은 개발자를 위한 엔터프라이즈급 Kubernetes 플랫폼으로, 조직이 CI(Continuous Integration) 및 CD(Continuous Delivery)와 같은 DevOps 관행을 통해 애플리케이션 제공 프로세스를 자동화할 수 있습니다. OpenShift Container Platform은 조직의 요구 사항을 충족하기 위해 다음과 같은 CI/CD 솔루션을 제공합니다.

  • OpenShift Builds
  • OpenShift Pipelines
  • OpenShift GitOps

1.1. OpenShift Builds

OpenShift 빌드를 사용하면 선언적 빌드 프로세스를 사용하여 클라우드 네이티브 애플리케이션을 생성할 수 있습니다. BuildConfig 오브젝트를 생성하는 데 사용하는 YAML 파일에서 빌드 프로세스를 정의할 수 있습니다. 이 정의에는 빌드 트리거, 입력 매개변수, 소스 코드와 같은 속성이 포함됩니다. 배포된 BuildConfig 오브젝트는 일반적으로 실행 가능한 이미지를 빌드하여 컨테이너 이미지 레지스트리로 푸시합니다.

OpenShift Builds는 빌드 전략에 대해 다음과 같은 확장 가능한 지원을 제공합니다.

  • Docker 빌드
  • S2I(Source-to-Image) 빌드
  • 사용자 정의 빌드

자세한 내용은 이미지 빌드 이해를참조하십시오.

1.2. OpenShift Pipelines

OpenShift Pipelines는 Kubernetes 네이티브 CI/CD 프레임워크를 제공하여 자체 컨테이너에서 CI/CD 파이프라인의 각 단계를 설계하고 실행합니다. 이는 예측 가능한 결과를 통해 온 디맨드 파이프라인에 맞게 개별적으로 확장할 수 있습니다.

자세한 내용은 OpenShift Pipelines 이해를참조하십시오.

1.3. OpenShift GitOps

OpenShift GitOps는 Argo CD를 선언적 GitOps 엔진으로 사용하는 Operator입니다. 다중 클러스터 OpenShift 및 Kubernetes 인프라에서 GitOps 워크플로를 활성화합니다. 관리자는 OpenShift GitOps를 사용하여 클러스터 및 개발 라이프사이클에 Kubernetes 기반 인프라 및 애플리케이션을 일관되게 구성하고 배포할 수 있습니다.

자세한 내용은 OpenShift GitOps 이해를참조하십시오.

1.4. Jenkins

Jenkins는 애플리케이션 및 프로젝트 빌드, 테스트 및 배포 프로세스를 자동화합니다. OpenShift Developer Tools는 OpenShift Container Platform과 직접 통합되는 Jenkins 이미지를 제공합니다. Jenkins는 Samples Operator 템플릿 또는 인증된 Helm 차트를 사용하여 OpenShift에 배포할 수 있습니다.

2장. 빌드

2.1. 이미지 빌드 이해

2.1.1. 빌드

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

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

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

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

  • Docker 빌드
  • S2I(Source-to-Image) 빌드
  • 사용자 정의 빌드

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

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

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

  • 연속 통합
  • 연속 배포

2.1.1.1. Docker 빌드

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

작은 정보

buildArgs 배열을 사용하여 Docker 빌드 인수를 설정하는 경우 Dockerfile 참조 문서에서 ARG 및 FROM이 상호 작용하는 방법 이해를 참조하십시오.

2.1.1.2. S2I(Source-to-Image) 빌드

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

2.1.1.3. 사용자 정의 빌드

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

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

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

2.1.1.4. 파이프라인 빌드

중요

파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.

OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.

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

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

2.2. 빌드 구성 이해

다음 섹션에서는 빌드의 개념과 빌드 구성을 정의하고 사용 가능한 주요 빌드 전략을 간략히 설명합니다.

2.2.1. BuildConfigs

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

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

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

다음 예제 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"

1
이 사양은 ruby-sample-build라는 새 BuildConfig를 생성합니다.
2
runPolicy 필드는 이 빌드 구성에서 생성한 빌드를 동시에 실행할 수 있는지 여부를 제어합니다. 기본값은 Serial입니다. 즉 새 빌드가 동시에 실행되지 않고 순차적으로 실행됩니다.
3
트리거 목록을 지정할 수 있으며 이 경우 새 빌드가 생성될 수 있습니다.
4
source 섹션은 빌드의 소스를 정의합니다. 소스 유형에 따라 기본 입력 소스가 결정되는데, 소스 유형은 코드 리포지토리 위치를 가리키는 Git, 인라인 Dockerfile에서 빌드하는 Dockerfile 또는 바이너리 페이로드를 허용하는 Binary일 수 있습니다. 한 번에 여러 개의 소스를 사용할 수 있습니다. 자세한 내용은 각 소스 유형에 대한 설명서를 참조하십시오.
5
strategy 섹션에서는 빌드를 실행하는 데 사용하는 빌드 전략에 대해 설명합니다. 여기에서 Source , Docker 또는 Custom 전략을 지정할 수 있습니다. 이 예에서는 S2I(Source-to-Image)에서 애플리케이션 빌드에 사용하는 ruby-20-centos7 컨테이너 이미지를 사용합니다.
6
컨테이너 이미지가 성공적으로 빌드되면 output 섹션에 설명된 리포지토리로 푸시됩니다.
7
postCommit 섹션에서는 선택적 빌드 후크를 정의합니다.

2.3. 빌드 입력 생성

다음 섹션에서는 빌드 입력에 대한 개요, 입력을 사용하여 빌드가 작동하도록 소스 콘텐츠를 제공하는 방법, 빌드 환경을 사용하고 보안을 생성하는 방법에 대한 지침을 확인할 수 있습니다.

2.3.1. 빌드 입력

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

  • 인라인 Dockerfile 정의
  • 기존 이미지에서 추출한 컨텐츠
  • Git 리포지토리
  • 바이너리(로컬) 입력
  • 입력 보안
  • 외부 아티팩트

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

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

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

  1. 작업 디렉터리가 구성되고 모든 입력 콘텐츠가 작업 디렉터리에 배치됩니다. 예를 들어 입력 Git 리포지토리가 작업 디렉터리에 복제되고 입력 이미지에서 지정된 파일이 타겟 경로를 사용하여 작업 디렉터리에 복사됩니다.
  2. 빌드 프로세스에서는 contextDir이 정의된 경우 디렉터리를 해당 디렉터리로 변경합니다.
  3. 인라인 Dockerfile(있는 경우)은 현재 디렉터리에 기록됩니다.
  4. 현재 디렉터리의 콘텐츠는 Dockerfile, 사용자 지정 빌더 논리 또는 assemble 스크립트에서 참조할 수 있도록 빌드 프로세스에 제공됩니다. 즉 contextDir 외부에 있는 모든 입력 콘텐츠는 빌드에서 무시합니다.

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

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
1
빌드를 위한 작업 디렉터리에 복제할 리포지토리입니다.
2
myinputimage의 /usr/lib/somefile.jar는 <workingdir>/app/dir/injected/dir에 저장됩니다.
3
빌드용 작업 디렉터리는 <original_workingdir>/app/dir입니다.
4
이 콘텐츠가 포함된 Dockerfile은 <original_workingdir>/app/dir에 생성되어 해당 이름의 기존 파일을 덮어씁니다.

2.3.2. Dockerfile 소스

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

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

source:
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 1
1
dockerfile 필드에는 빌드된 인라인 Dockerfile이 포함됩니다.

추가 리소스

  • 이 필드는 일반적으로 Docker 전략 빌드에 Dockerfile을 제공하는 데 사용합니다.

2.3.3. 이미지 소스

이미지가 포함된 빌드 프로세스에 파일을 추가할 수 있습니다. 입력 이미지는 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
1
하나 이상의 입력 이미지 및 파일로 이루어진 배열입니다.
2
복사할 파일이 포함된 이미지에 대한 참조입니다.
3
소스/대상 경로로 이루어진 배열입니다.
4
빌드 프로세스에서 파일에 액세스할 수 있는, 빌드 루트의 상대 디렉터리입니다.
5
참조한 이미지에서 복사할 파일의 위치입니다.
6
입력 이미지에 액세스하는 데 자격 증명이 필요한 경우 제공되는 선택적 보안입니다.
참고

클러스터에서 ImageDigestMirrorSet 또는 ImageTagMirrorSet 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에는 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

pull secret이 필요한 이미지

가져오기 보안이 필요한 입력 이미지를 사용하는 경우 빌드에서 사용하는 서비스 계정에 가져오기 보안을 연결할 수 있습니다. 기본적으로 빌드에서는 builder 서비스 계정을 사용합니다. 보안에 입력 이미지를 호스팅하는 리포지토리와 일치하는 자격 증명이 포함된 경우 가져오기 보안이 빌드에 자동으로 추가됩니다. 빌드에서 사용하는 서비스 계정에 가져오기 보안을 연결하려면 다음을 실행합니다. 

$ oc secrets link builder dockerhub
참고

이 기능은 사용자 정의 전략을 사용하는 빌드에는 지원되지 않습니다.

pull secret이 필요한 미러링된 레지스트리의 이미지

미러링된 레지스트리에서 입력 이미지를 사용하는 경우 빌드 오류가 표시되는 경우 이미지 메시지를 가져오지 못하면 다음 방법 중 하나를 사용하여 오류를 해결할 수 있습니다.

  • 빌더 이미지 리포지토리 및 알려진 모든 미러에 대한 인증 자격 증명이 포함된 입력 보안을 생성합니다. 이 경우 이미지 레지스트리와 해당 미러에 대한 자격 증명의 풀 시크릿을 생성합니다.
  • 입력 보안을 BuildConfig 오브젝트의 풀 시크릿으로 사용합니다.

2.3.4. Git 소스

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

인라인 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
1
git 필드에는 소스 코드의 원격 Git 리포지토리에 대한 URI(Uniform Resource Identifier)가 포함되어 있습니다. 특정 Git 참조를 확인하려면 ref 필드의 값을 지정해야 합니다. 유효한 ref는 SHA1 태그 또는 분기 이름이 될 수 있습니다. ref 필드의 기본값은 master 입니다.
2
contextDir 필드를 사용하면 빌드에서 애플리케이션 소스 코드를 찾는 소스 코드 리포지토리 내부의 기본 위치를 덮어쓸 수 있습니다. 애플리케이션이 하위 디렉터리에 있는 경우 이 필드를 사용하여 기본 위치(루트 폴더)를 덮어쓸 수 있습니다.
3
선택적 dockerfile 필드를 제공하는 경우 소스 리포지토리에 있을 수 있는 모든 Dockerfile을 덮어쓰는 Dockerfile이 문자열에 포함되어야 합니다.

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

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

주의

MITM(Man in the middle) TLS 하이재킹을 수행하거나 프록시 연결을 재암호화하고 있는 프록시를 통과하는 Git 복제 작업이 작동하지 않습니다.

2.3.4.1. 프록시 사용

프록시를 사용하는 경우에만 Git 리포지토리에 액세스할 수 있는 경우 빌드 구성의 source 섹션에 사용할 프록시를 정의할 수 있습니다. 사용할 HTTP 및 HTTPS 프록시를 둘 다 구성할 수 있습니다. 두 필드 모두 선택 사항입니다. 프록시를 사용할 수 없는 도메인도 NoProxy 필드에 지정할 수 있습니다.

참고

이를 위해서는 소스 URI에서 HTTP 또는 HTTPS 프로토콜을 사용해야 합니다. 

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
참고

Pipeline 전략 빌드의 경우 Jenkins용 Git 플러그인에 대한 현재 제한 사항을 고려할 때 Git 플러그인을 통한 모든 Git 작업은 BuildConfig 에 정의된 HTTP 또는 HTTPS 프록시를 사용하지 않습니다. Git 플러그인은 플러그인 관리자 패널에서 Jenkins UI에 구성된 프록시만 사용합니다. 그런 다음 이 프록시는 모든 작업에서 Jenkins 내의 모든 Git 상호 작용에 사용됩니다.

추가 리소스

  • JenkinsBehindProxy에서 Jenkins UI를 통해 프록시를 구성하는 방법에 대한 지침을 확인할 수 있습니다.

2.3.4.2. 소스 복제 보안

빌더 Pod는 빌드의 소스로 정의된 모든 Git 리포지토리에 액세스해야 합니다. 소스 복제 보안은 자체 서명되거나 신뢰할 수 없는 SSL 인증서가 있는 프라이빗 리포지토리 또는 리포지토리와 같이 일반적으로 액세스할 수 없는 리포지토리에 대한 액세스 권한을 제공하는 데 사용됩니다.

다음과 같은 소스 복제 보안 구성이 지원됩니다.

  • .gitconfig 파일
  • 기본 인증
  • SSH 키 인증
  • 신뢰할 수 있는 인증 기관
참고

이러한 구성의 조합을 사용하여 특정 요구 사항을 충족할 수도 있습니다.

2.3.4.2.1. 빌드 구성에 소스 복제 보안 자동 추가

BuildConfig가 생성되면 OpenShift Container Platform에서 소스 복제 보안 참조를 자동으로 채울 수 있습니다. 이 동작을 사용하면 생성된 빌드에서 참조된 보안에 저장된 자격 증명을 자동으로 사용하여 추가 구성없이 원격 Git 리포지토리에 인증할 수 있습니다.

이 기능을 사용하려면 Git 리포지토리 자격 증명이 포함된 보안이 나중에 BuildConfig가 생성되는 네임스페이스에 있어야 합니다. 이 보안에는 build.openshift.io/source-secret-match-uri- 접두사가 있는 주석이 하나 이상 포함되어야 합니다. 이러한 주석의 각 값은 다음과 같이 정의되는 URI(Uniform Resource Identifier) 패턴입니다. 소스 복제 보안 참조 없이 BuildConfig를 생성하고 해당 Git 소스 URI가 보안 주석의 URI 패턴과 일치하는 경우 OpenShift Container Platform은 BuildConfig에 해당 보안에 대한 참조를 자동으로 삽입합니다.

사전 요구 사항

URI 패턴은 다음으로 구성되어야 합니다.

  • 유효 스키마: *://, git://, http://, https:// 또는 ssh://
  • 호스트: *' 또는 유효한 호스트 이름이나 필요한 경우 앞에 *.가 있는 IP 주소
  • 경로: /* 또는 / 뒤에 * 문자를 선택적으로 포함하는 모든 문자

위의 모든 항목에서 * 문자는 와일드카드로 해석됩니다.

중요

URI 패턴은 RFC3986을 준수하는 Git 소스 URI와 일치해야 합니다. URI 패턴에 사용자 이름(또는 암호) 구성 요소를 포함하지 마십시오.

예를 들어 Git 리포지토리 URL에 ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN jira.git을 사용하는 경우 소스 보안을 ssh://bitbucket.atlassian.com:7999/*(ssh://git@bitbucket.atlassian.com:7999/* 아님)로 지정해야 합니다. 

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

프로세스

특정 BuildConfig의 Git URI와 일치하는 보안이 여러 개인 경우 OpenShift Container Platform은 가장 긴 일치 항목이 있는 보안을 선택합니다. 이렇게 하면 다음 예와 같이 기본 덮어쓰기가 가능합니다.

다음 조각은 두 개의 부분적인 소스 복제 보안을 보여줍니다. 첫 번째는 HTTPS를 통해 액세스하는 도메인 mycorp.com의 모든 서버와 일치하고, 두 번째는 서버 mydev1.mycorp.com 및 mydev2.mycorp.com에 대한 액세스 권한을 덮어씁니다. 

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:
  ...

  • 다음을 사용하여 기존 보안에 build.openshift.io/source-secret-match-uri- 주석을 추가합니다. 

    $ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
2.3.4.2.2. 수동으로 소스 복제 보안 추가

소스 복제 보안은 BuildConfig 내부의 source 필드에 sourceSecret 필드를 추가한 후 사용자가 생성한 보안의 이름으로 설정하는 방식으로 빌드 구성에 수동으로 추가할 수 있습니다. 다음 예에서는 basicsecret입니다. 

apiVersion: "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 set build-secret 명령을 사용하여 기존 빌드 구성에 소스 복제 보안을 설정할 수도 있습니다.

  • 기존 빌드 구성에 소스 복제 보안을 설정하려면 다음 명령을 입력합니다. 

    $ oc set build-secret --source bc/sample-build basicsecret
2.3.4.2.3. .gitconfig 파일에서 보안 생성

애플리케이션 복제에서 .gitconfig 파일을 사용하는 경우 이 파일을 포함하는 보안을 생성할 수 있습니다. 빌더 서비스 계정에 추가한 다음 BuildConfig에 추가합니다.

프로세스

  • .gitconfig 파일에서 보안을 생성하려면 다음을 수행합니다. 
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
참고

.gitconfig 파일의 http 섹션에 sslVerify=false가 설정되어 있는 경우 SSL 확인을 해제할 수 있습니다. 

[http]
        sslVerify=false
2.3.4.2.4. 보안 Git의 .gitconfig 파일에서 보안 생성

Git 서버가 양방향 SSL과 사용자 이름 및 암호로 보호되는 경우 소스 빌드에 인증서 파일을 추가하고 .gitconfig 파일의 인증서 파일에 참조를 추가해야 합니다.

사전 요구 사항

  • Git 자격 증명이 있어야 합니다.

프로세스

소스 빌드에 인증서 파일을 추가하고 .gitconfig 파일의 인증서 파일에 대한 참조를 추가합니다.

  1. 애플리케이션 소스 코드의 /var/run/secrets/openshift.io/source/ 폴더에 client.crt, cacert.crt, client.key 파일을 추가합니다.

  2. 서버의 .gitconfig 파일에서 다음 예에 표시된 [http] 섹션을 추가합니다. 

    # cat .gitconfig

    출력 예

    [user]
        name = <name>
        email = <email>
[http]
        sslVerify = false
        sslCert = /var/run/secrets/openshift.io/source/client.crt
        sslKey = /var/run/secrets/openshift.io/source/client.key
        sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt

  3. 보안을 생성합니다. 

    $ oc create secret generic <secret_name> \
--from-literal=username=<user_name> \ 1
--from-literal=password=<password> \ 2
--from-file=.gitconfig=.gitconfig \
--from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
--from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
--from-file=client.key=/var/run/secrets/openshift.io/source/client.key
    1
    사용자의 Git 사용자 이름입니다.
    2
    이 사용자의 암호입니다.
중요

암호를 다시 입력하지 않으려면 빌드에서 S2I(Source-to-Image) 이미지를 지정해야 합니다. 그러나 리포지토리를 복제할 수 없는 경우 빌드를 승격하려면 사용자 이름과 암호를 계속 지정해야 합니다.

추가 리소스

  • 애플리케이션 소스 코드의 /var/run/secrets/openshift.io/source/ 폴더입니다.
2.3.4.2.5. 소스 코드 기본 인증에서 보안 생성

기본 인증에는 --username 및 --password의 조합 또는 SCM(소프트웨어 구성 관리) 서버에 대해 인증하는 토큰이 필요합니다.

사전 요구 사항

  • 개인 리포지토리에 액세스할 수 있는 사용자 이름 및 암호입니다.

프로세스

  1. 먼저 보안을 생성한 후 --username 및 --password를 사용하여 개인 리포지토리에 액세스합니다. 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --type=kubernetes.io/basic-auth

  2. 토큰을 사용하여 기본 인증 보안을 생성합니다. 

    $ oc create secret generic <secret_name> \
    --from-literal=password=<token> \
    --type=kubernetes.io/basic-auth
2.3.4.2.6. 소스 코드 SSH 키 인증에서 보안 생성

SSH 키 기반 인증에는 개인 SSH 키가 필요합니다.

리포지토리 키는 일반적으로 $HOME/.ssh/ 디렉터리에 있으며 기본적으로 이름이 id_dsa.pub, id_ecdsa.pub, id_ed25519.pub 또는 id_rsa.pub입니다.

프로세스

  1. SSH 키 자격 증명을 생성합니다. 

    $ ssh-keygen -t ed25519 -C "your_email@example.com"
    참고

    SSH 키의 암호를 생성하면 OpenShift Container Platform이 빌드되지 않습니다. 암호를 입력하라는 메시지가 표시되면 비워 두십시오.

    두 파일(공개 키 및 해당 개인 키(id_dsa, id_ecdsa, id_ed25519 또는 id_rsa))이 생성됩니다. 두 파일이 모두 있는 상태에서 공개 키를 업로드하는 방법에 대한 SCM(소스 제어 관리) 시스템의 설명서를 참조하십시오. 개인 키는 개인 리포지토리에 액세스하는 데 사용됩니다.

  2. SSH 키를 사용하여 개인 리포지토리에 액세스하기 전에 보안을 생성합니다. 

    $ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/known_hosts> \ 1
    --type=kubernetes.io/ssh-auth
    1
    선택 사항: 이 필드를 추가하면 엄격한 서버 호스트 키 확인이 가능합니다.
    주의

    시크릿을 생성하는 동안 known_hosts 파일을 건너뛰면 잠재적인 MIT(man-in-the-middle) 공격에 빌드가 취약해집니다.

    참고

    known_hosts 파일에 소스 코드 호스트의 항목이 포함되어 있는지 확인합니다.

2.3.4.2.7. 신뢰할 수 있는 소스 코드 인증 기관에서 보안 생성

Git 복제 작업 중 신뢰할 수 있는 일련의 TLS(Transport Layer Security) CA(인증 기관)가 OpenShift Container Platform 인프라 이미지로 빌드됩니다. Git 서버에서 자체 서명된 인증서 또는 이미지에서 신뢰할 수 없는 인증 기관에서 서명한 인증서를 사용하는 경우 인증서가 포함된 보안을 생성하거나 TLS 확인을 비활성화할 수 있습니다.

CA 인증서에 대한 보안을 생성하는 경우 OpenShift Container Platform에서는 Git 복제 작업 중 Git 서버에 액세스합니다. 이 방법을 사용하면 제공되는 모든 TLS 인증서를 허용하는 Git SSL 확인을 비활성화하는 것보다 더 안전합니다.

프로세스

CA 인증서 파일을 사용하여 보안을 생성합니다.

  1. CA에서 중간 인증 기관을 사용하는 경우 ca.crt 파일의 모든 CA 인증서를 결합합니다. 다음 명령을 실행합니다. 

    $ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt

    1. 보안을 생성합니다. 

      $ oc create secret generic mycert --from-file=ca.crt=</path/to/file> 1
      1
      키 이름으로 ca.crt를 사용해야 합니다.
2.3.4.2.8. 소스 보안 조합

특정 요구 사항에 맞는 소스 복제 보안을 생성하기 위해 다양한 방법을 결합할 수 있습니다.

2.3.4.2.8.1. .gitconfig 파일을 사용하여 SSH 기반 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: .gitconfig 파일을 사용하는 SSH 기반 인증 보안).

사전 요구 사항

  • SSH 인증
  • .gitconfig 파일

프로세스

  • .gitconfig 파일을 사용하여 SSH 기반 인증 보안을 생성하려면 다음을 실행합니다. 

    $ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/.gitconfig> \
    --type=kubernetes.io/ssh-auth
2.3.4.2.8.2. .gitconfig 파일 및 CA 인증서를 결합하는 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: .gitconfig 파일 및 CA(인증 기관) 인증서를 결합하는 보안).

사전 요구 사항

  • .gitconfig 파일
  • CA 인증서

프로세스

  • .gitconfig 파일 및 CA 인증서를 결합하는 보안을 생성하려면 다음을 실행합니다. 

    $ oc create secret generic <secret_name> \
    --from-file=ca.crt=<path/to/certificate> \
    --from-file=<path/to/.gitconfig>
2.3.4.2.8.3. CA 인증서를 사용하여 기본 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: 기본 인증 및 CA(인증 기관) 인증서를 결합하는 보안).

사전 요구 사항

  • 기본 인증 자격 증명
  • CA 인증서

프로세스

  • CA 인증서로 기본 인증 보안을 생성하려면 다음을 실행합니다. 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth
2.3.4.2.8.4. .gitconfig 파일을 사용하여 기본 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: 기본 인증 및 .gitconfig 파일을 결합하는 보안 ).

사전 요구 사항

  • 기본 인증 자격 증명
  • .gitconfig 파일

프로세스

  • .gitconfig 파일을 사용하여 기본 인증 보안을 생성하려면 다음을 실행합니다. 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --type=kubernetes.io/basic-auth
2.3.4.2.8.5. .gitconfig 파일 및 CA 인증서를 사용하여 기본 인증 보안 생성

다양한 방법을 결합하여 특정 요구 사항에 맞는 소스 복제 보안을 생성할 수 있습니다(예: 기본 인증, .gitconfig 파일, CA(인증 기관) 인증서를 결합하는 보안).

사전 요구 사항

  • 기본 인증 자격 증명
  • .gitconfig 파일
  • CA 인증서

프로세스

  • .gitconfig 파일 및 CA 인증서를 사용하여 기본 인증 보안을 생성하려면 다음을 실행합니다. 

    $ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --from-file=ca-cert=</path/to/file> \
    --type=kubernetes.io/basic-auth

2.3.5. 바이너리(로컬) 소스

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

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

참고

바이너리 유형 빌드에서는 로컬 파일 시스템의 콘텐츠를 스트리밍해야 하므로 이미지 변경 트리거와 같이 바이너리 유형 빌드를 자동으로 트리거할 수 없습니다. 바이너리 파일을 제공할 수 없기 때문입니다. 마찬가지로 웹 콘솔에서 바이너리 유형 빌드를 시작할 수 없습니다.

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

  • --from-file: 지정한 파일의 콘텐츠가 빌더에 바이너리 스트림으로 전송됩니다. 파일에 URL을 지정할 수도 있습니다. 그러면 빌더에서 빌드 컨텍스트 상단에 있는 것과 동일한 이름으로 파일에 데이터를 저장합니다.
  • --from-dir 및 --from-repo: 콘텐츠가 보관되고 빌더에 바이너리 스트림으로 전송됩니다. 그러면 빌더가 빌드 컨텍스트 디렉터리 내에서 아카이브 콘텐츠를 추출합니다. --from-dir을 사용하면 추출된 아카이브에 URL을 지정할 수도 있습니다.
  • --from-archive: 지정하는 아카이브가 빌더로 전송되며 빌드 컨텍스트 디렉터리 내에서 추출됩니다. 이 옵션은 --from-dir과 동일하게 작동합니다. 이러한 옵션에 대한 인수가 디렉터리인 경우 먼저 호스트에서 아카이브가 생성됩니다.

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

  • BuildConfig에 이미 Binary 소스 유형이 정의되어 있는 경우 효과적으로 무시되고 클라이언트에서 전송하는 내용으로 교체됩니다.
  • BuildConfig에 Git 소스 유형이 정의되어 있는 경우 Binary 및 Git을 함께 사용할 수 없으므로 해당 BuildConfig가 동적으로 비활성화되고 빌더에 제공하는 바이너리 스트림의 데이터에 우선순위가 지정됩니다.

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 필드의 값이 아카이브 내 하위 디렉터리로 해석되고, 유효한 경우 빌드를 실행하기 전에 빌더가 해당 하위 디렉터리로 변경됩니다.

2.3.6. 입력 보안 및 구성 맵

중요

입력 보안 및 구성 맵의 콘텐츠가 빌드 출력 컨테이너 이미지에 표시되지 않도록 하려면 Docker 빌드 및 source-to-image 빌드 전략에서 빌드 볼륨을 사용합니다.

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

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

  1. 미러의 URL 및 연결 설정으로 구성된 settings.xml 파일
  2. 설정 파일에서 참조하는 개인 키(예: ~/.ssh/id_rsa)

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

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

2.3.6.1. 비밀이란?

Secret 오브젝트 유형에서는 암호, OpenShift Container Platform 클라이언트 구성 파일, dockercfg 파일, 개인 소스 리포지토리 자격 증명 등과 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 중요한 콘텐츠를 분리합니다. 볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 시크릿을 사용하여 Pod 대신 작업을 수행할 수 있습니다.

YAML 보안 오브젝트 정의

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

1
보안의 키 이름과 값의 구조를 나타냅니다.
2
data 필드에서 허용되는 키 형식은 Kubernetes 구분자 용어집의 DNS_SUBDOMAIN 값에 있는 지침을 충족해야 합니다.
3
data 맵의 키와 관련된 값은 base64로 인코딩되어야 합니다.
4
stringData 맵의 항목이 base64로 변환된 후 해당 항목이 자동으로 data 맵으로 이동합니다. 이 필드는 쓰기 전용입니다. 해당 값은 data 필드에서만 반환합니다.
5
stringData 맵의 키와 관련된 값은 일반 텍스트 문자열로 구성됩니다.
2.3.6.1.1. 보안 속성

주요 속성은 다음과 같습니다.

  • 보안 데이터는 정의와는 별도로 참조할 수 있습니다.
  • 보안 데이터 볼륨은 임시 파일 저장 기능(tmpfs)에 의해 지원되며 노드에 저장되지 않습니다.
  • 보안 데이터는 네임스페이스 내에서 공유할 수 있습니다.
2.3.6.1.2. 보안 유형

type 필드의 값은 보안의 키 이름과 값의 구조를 나타냅니다. 유형을 사용하면 보안 오브젝트에 사용자 이름과 키를 적용할 수 있습니다. 검증을 수행하지 않으려면 기본값인 opaque 유형을 사용합니다.

보안 데이터에 특정 키 이름이 있는지 확인하기 위해 서버 측 최소 검증을 트리거하려면 다음 유형 중 하나를 지정합니다.

  • kubernetes.io/service-account-token. 서비스 계정 토큰을 사용합니다.
  • kubernetes.io/dockercfg. 필수 Docker 자격 증명으로 .dockercfg 파일을 사용합니다.
  • kubernetes.io/dockerconfigjson. 필수 Docker 자격 증명으로 .docker/config.json 파일을 사용합니다.
  • kubernetes.io/basic-auth. 기본 인증에 사용합니다.
  • kubernetes.io/ssh-auth. SSH 키 인증에 사용합니다.
  • kubernetes.io/tls. TLS 인증 기관에 사용합니다.

검증을 수행하지 않으려면 type= Opaque를 지정합니다. 즉 보안에서 키 이름 또는 값에 대한 규칙을 준수하도록 요청하지 않습니다. opaque 보안에는 임의의 값을 포함할 수 있는 비정형 key:value 쌍을 사용할 수 있습니다.

참고

example.com/my-secret-type과 같은 다른 임의의 유형을 지정할 수 있습니다. 이러한 유형은 서버 측에 적용되지 않지만 보안 생성자가 해당 유형의 키/값 요구 사항을 준수하도록 의도했음을 나타냅니다.

2.3.6.1.3. 보안 업데이트

보안 값을 수정해도 이미 실행 중인 Pod에서 사용하는 값은 동적으로 변경되지 않습니다. 보안을 변경하려면 동일한 PodSpec을 사용하는 일부 경우에서 원래 Pod를 삭제하고 새 Pod를 생성해야 합니다.

보안 업데이트 작업에서는 새 컨테이너 이미지를 배포하는 것과 동일한 워크플로를 따릅니다. kubectl rolling-update 명령을 사용할 수 있습니다.

보안의 resourceVersion 값은 참조 시 지정되지 않습니다. 따라서 Pod가 시작되는 동시에 보안이 업데이트되는 경우 Pod에 사용되는 보안의 버전이 정의되지 않습니다.

참고

현재는 Pod가 생성될 때 사용된 보안 오브젝트의 리소스 버전을 확인할 수 없습니다. 컨트롤러에서 이전 resourceVersion 을 사용하여 재시작할 수 있도록 Pod에서 이 정보를 보고하도록 계획되어 있습니다. 그동안 기존 보안 데이터를 업데이트하지 말고 고유한 이름으로 새 보안을 생성하십시오.

2.3.6.2. 보안 생성

먼저 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다.

보안 생성 시 다음을 수행합니다.

  • 보안 데이터를 사용하여 보안 오브젝트를 생성합니다.
  • Pod 서비스 계정을 업데이트하여 보안에 대한 참조를 허용합니다.
  • 보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.

프로세스

  • create 명령을 사용하여 JSON 또는 YAML 파일에서 보안 오브젝트를 생성합니다. 

    $ oc create -f <filename>

    예를 들어 로컬 .docker/config.json 파일에서 보안을 생성할 수 있습니다. 

    $ oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

    이 명령은 dockerhub라는 보안의 JSON 사양을 생성한 후 오브젝트를 생성합니다.

    YAML Opaque Secret 오브젝트 정의

    apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque 1
data:
  username: <username>
  password: <password>

    1
    불투명 보안을 지정합니다.

    Docker 구성 JSON 파일 보안 오브젝트 정의

    apiVersion: v1
kind: Secret
metadata:
  name: aregistrykey
  namespace: myapps
type: kubernetes.io/dockerconfigjson 1
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2

    1
    보안에서 Docker 구성 JSON 파일을 사용하도록 지정합니다.
    2
    base64로 인코딩된 Docker 구성 JSON 파일의 출력입니다.

2.3.6.3. 보안 사용

보안을 생성한 후에는 해당 보안을 참조하는 Pod를 생성하고 로그를 가져오고 해당 Pod를 삭제할 수 있습니다.

프로세스

  1. 보안을 참조할 Pod를 생성합니다. 

    $ oc create -f <your_yaml_file>.yaml

  2. 로그를 가져옵니다. 

    $ oc logs secret-example-pod

  3. Pod를 삭제합니다. 

    $ oc delete pod secret-example-pod

추가 리소스

  • 보안 데이터가 있는 YAML 파일의 예:

    파일 4개를 생성할 YAML 보안

    apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: <username> 1
  password: <password> 2
stringData:
  hostname: myapp.mydomain.com 3
  secret.properties: |-     4
    property1=valueA
    property2=valueB

    1
    파일에 디코딩된 값이 포함되어 있습니다.
    2
    파일에 디코딩된 값이 포함되어 있습니다.
    3
    파일에 제공된 문자열이 포함되어 있습니다.
    4
    파일에 제공된 데이터가 포함되어 있습니다.

    보안 데이터로 볼륨의 파일을 채우는 Pod의 YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:
          # name must match the volume name below
          - name: secret-volume
            mountPath: /etc/secret-volume
            readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
  restartPolicy: Never

    보안 데이터로 환경 변수를 채우는 Pod의 YAML

    apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: username
  restartPolicy: Never

    보안 데이터로 환경 변수를 채우는 빌드 구성의 YAML

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:
            name: test-secret
            key: username

2.3.6.4. 입력 보안 및 구성 맵 추가

소스 제어에 의존하지 않고 인증 정보 및 기타 구성 데이터를 빌드에 제공하기 위해 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.

일부 시나리오에서는 빌드 작업을 수행하려면 종속 리소스에 액세스하기 위해 인증 정보 또는 기타 구성 데이터가 필요합니다. 해당 정보를 소스 제어에 배치하지 않고 사용할 수 있도록 입력 보안 및 입력 구성 맵을 정의할 수 있습니다.

절차

입력 보안이나 구성 맵 또는 둘 다를 기존 BuildConfig 오브젝트에 추가하려면 다음을 수행합니다.

  1. ConfigMap 오브젝트가 없는 경우 해당 오브젝트를 생성합니다. 

    $ oc create configmap settings-mvn \
    --from-file=settings.xml=<path/to/settings.xml>

    그러면 settings-mvn이라는 새 구성 맵이 생성됩니다. 이 맵에는 settings.xml 파일의 일반 텍스트 내용이 포함됩니다.

    작은 정보

    다음 YAML을 적용하여 구성 맵을 만들 수 있습니다. 

    apiVersion: core/v1
kind: ConfigMap
metadata:
  name: settings-mvn
data:
  settings.xml: |
    <settings>
    … # Insert maven settings here
    </settings>

  2. Secret 오브젝트가 없는 경우 해당 오브젝트를 생성합니다. 

    $ oc create secret generic secret-mvn \
    --from-file=ssh-privatekey=<path/to/.ssh/id_rsa>
    --type=kubernetes.io/ssh-auth

    그러면 secret-mvn이라는 새 보안이 생성됩니다. 이 보안에는 id_rsa 개인 키의 base64 인코딩 콘텐츠가 포함됩니다.

    작은 정보

    다음 YAML을 적용하여 입력 보안을 생성할 수 있습니다. 

    apiVersion: core/v1
kind: Secret
metadata:
  name: secret-mvn
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: |
    # Insert ssh private key, base64 encoded

  3. 다음과 같이 기존 BuildConfig 오브젝트의 source 섹션에 구성 맵과 보안을 추가합니다. 

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

새 BuildConfig 오브젝트에 구성 맵과 보안을 포함하려면 다음 명령을 실행합니다. 

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

빌드 중 settings.xml 및 id_rsa 파일이 소스 코드가 있는 디렉터리로 복사됩니다. OpenShift Container Platform S2I 빌더 이미지의 경우 이 디렉터리는 Dockerfile에 WORKDIR 명령을 사용하여 설정하는 이미지 작업 디렉터리입니다. 다른 디렉터리를 지정하려면 정의에 destinationDir을 추가합니다. 

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"

새 BuildConfig 오브젝트를 생성할 때 대상 디렉터리를 지정할 수도 있습니다. 

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

두 경우 모두 settings.xml 파일은 빌드 환경의 ./.m2 디렉터리에 추가되고 id_rsa 키는 ./.ssh 디렉터리에 추가됩니다.

2.3.6.5. S2I(Source-to-Image) 전략

Source 전략을 사용하면 정의된 모든 입력 보안이 해당 destinationDir에 복사됩니다. destinationDir을 비워 두면 보안이 빌더 이미지의 작업 디렉터리에 배치됩니다.

destinationDir이 상대 경로인 경우 동일한 규칙이 사용됩니다. 보안은 이미지 작업 디렉터리의 상대 경로에 배치됩니다. destinationDir 경로의 최종 디렉터리가 빌더 이미지에 없는 경우 해당 디렉터리가 생성됩니다. destinationDir의 선행 디렉터리가 모두 존재해야 합니다. 없는 경우 오류가 발생합니다.

참고

입력 보안은 전역 쓰기 가능으로 추가되고 0666 권한이 있으며 assemble 스크립트 실행 후 크기가 0으로 잘립니다. 즉 보안 파일은 결과 이미지에 존재하지만 보안상의 이유로 비어 있습니다.

assemble 스크립트가 완료되면 입력 구성 맵이 잘리지 않습니다.

2.3.6.6. Docker 전략

docker 전략을 사용하는 경우 Dockerfile의 ADD 및 COPY 명령을 사용하여 정의된 모든 입력 보안을 컨테이너 이미지에 추가할 수 있습니다.

보안의 destinationDir을 지정하지 않으면 Dockerfile이 있는 동일한 디렉터리로 파일이 복사됩니다. 상대 경로를 destinationDir로 지정하면 보안이 Dockerfile 위치와 상대되는 해당 디렉터리에 복사됩니다. 그러면 Docker 빌드 작업에서 빌드 중 사용하는 컨텍스트 디렉터리의 일부로 보안 파일을 사용할 수 있습니다.

보안 및 구성 맵 데이터를 참조하는 Dockerfile의 예

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

중요

일반적으로 사용자는 해당 이미지에서 실행되는 컨테이너에 보안이 표시되지 않도록 최종 애플리케이션 이미지에서 입력 보안을 제거합니다. 그러나 보안은 추가된 계층에 있는 이미지 자체에 계속 있습니다. 이 제거는 Dockerfile 자체에 포함됩니다.

입력 보안 및 구성 맵의 콘텐츠가 빌드 출력 컨테이너 이미지에 표시되지 않도록 하려면 Docker 빌드 전략의 빌드 볼륨을 대신 사용합니다.

2.3.6.7. 사용자 정의 전략

사용자 정의 전략을 사용하는 경우 정의된 입력 보안 및 구성 맵을 /var/run/secrets/openshift.io/build 디렉터리의 빌더 컨테이너에서 모두 사용할 수 있습니다. 사용자 정의 빌드 이미지에서는 이러한 보안 및 구성 맵을 적절하게 사용해야 합니다. 사용자 정의 전략을 사용하면 사용자 정의 전략 옵션에 설명된 대로 보안을 정의할 수 있습니다.

기존 전략 보안과 입력 보안은 기술적으로 차이가 없습니다. 하지만 빌더 이미지는 빌드 사용 사례에 따라 해당 항목을 구분하고 다르게 사용할 수 있습니다.

입력 보안은 항상 /var/run/secrets/openshift.io/build 디렉터리에 마운트되거나 빌더에서 전체 빌드 오브젝트를 포함하는 $BUILD 환경 변수를 구문 분석할 수 있습니다.

중요

레지스트리에 대한 가져오기 보안이 네임스페이스와 노드 모두에 있는 경우 빌드는 기본적으로 네임스페이스의 가져오기 보안을 사용합니다.

2.3.7. 외부 아티팩트

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

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

.s2i/bin/assemble 파일

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

.s2i/bin/run 파일

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

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

Dockerfile 발췌 내용

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에 정의된 환경 변수를 사용하여 다운로드할 특정 파일을 사용자 정의할 수 있도록 파일 위치에 대한 환경 변수를 사용할 수 있습니다.

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

  • .s2i/environment 파일 사용(소스 빌드 전략 전용)
  • BuildConfig에 설정
  • oc start-build --env를 사용하여 명시적으로 제공(수동으로 트리거하는 빌드 전용)

2.3.8. 개인 레지스트리에 Docker 자격 증명 사용

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

동일한 레지스트리 내에서 여러 리포지토리에 대한 인증 정보를 제공할 수 있으며, 각각 해당 레지스트리 경로에 해당하는 인증 정보를 제공할 수 있습니다.

참고

OpenShift Container Platform 컨테이너 이미지 레지스트리의 경우 OpenShift Container Platform에서 보안이 자동으로 생성되므로 필요하지 않습니다.

.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"
1
레지스트리의 URL입니다.
2
암호화된 암호입니다.
3
로그인에 사용할 이메일 주소입니다.
4
네임스페이스의 특정 이미지에 대한 URL 및 인증 정보.
5
레지스트리 네임스페이스의 URL 및 자격 증명입니다.

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

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

사전 요구 사항

  • .docker/config.json 파일이 있어야 합니다.

프로세스

  1. 로컬 .docker/config.json 파일에서 보안을 생성합니다. 

    $ oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

    이 명령은 dockerhub라는 보안의 JSON 사양을 생성한 후 오브젝트를 생성합니다.

  2. BuildConfig의 output 섹션에 pushSecret 필드를 추가하고 생성한 secret 이름(위 예의 경우 dockerhub)으로 설정합니다. 

    spec:
  output:
    to:
      kind: "DockerImage"
      name: "private.registry.com/org/private-image:latest"
    pushSecret:
      name: "dockerhub"

    oc set build-secret 명령을 사용하여 빌드 구성에 내보내기 보안을 설정할 수 있습니다. 

    $ oc set build-secret --push bc/sample-build dockerhub

    pushSecret 필드를 지정하는 대신 빌드에서 사용하는 서비스 계정에 내보내기 보안을 연결할 수도 있습니다. 기본적으로 빌드에서는 builder 서비스 계정을 사용합니다. 보안에 빌드의 출력 이미지를 호스팅하는 리포지토리와 일치하는 자격 증명이 포함된 경우 내보내기 보안이 빌드에 자동으로 추가됩니다. 

    $ oc secrets link builder dockerhub

  3. 빌드 전략 정의의 일부인 pullSecret 필드를 지정하여 개인 컨테이너 이미지 레지스트리에서 빌더 컨테이너 이미지를 가져옵니다. 

    strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "docker.io/user/private_repository"
    pullSecret:
      name: "dockerhub"

    oc set build-secret 명령을 사용하여 빌드 구성에 가져오기 보안을 설정할 수 있습니다. 

    $ oc set build-secret --pull bc/sample-build dockerhub
    참고

    이 예제에서는 소스 빌드에 pullSecret을 사용하지만 Docker 및 Custom 빌드에도 적용할 수 있습니다.

    pullSecret 필드를 지정하는 대신 빌드에서 사용하는 서비스 계정에 가져오기 보안을 연결할 수도 있습니다. 기본적으로 빌드에서는 builder 서비스 계정을 사용합니다. 보안에 빌드의 입력 이미지를 호스팅하는 리포지토리와 일치하는 자격 증명이 포함된 경우 가져오기 보안이 빌드에 자동으로 추가됩니다. pullSecret 필드를 지정하는 대신 빌드에서 사용하는 서비스 계정에 가져오기 보안을 연결하려면 다음을 실행합니다. 

    $ oc secrets link builder dockerhub
    참고

    이 기능을 사용하려면 BuildConfig 사양에 from 이미지를 지정해야 합니다. oc new-build 또는 oc new-app으로 생성한 Docker 전략 빌드는 특정 상황에서 이러한 작업을 수행하지 못할 수 있습니다.

2.3.9. 빌드 환경

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

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

참고

빌드 환경 변수에서 valueFrom을 사용하여 컨테이너 리소스를 참조하는 기능은 컨테이너를 생성하기 전에 참조를 확인하기 때문에 지원되지 않습니다.

2.3.9.1. 빌드 필드를 환경 변수로 사용

값을 가져올 필드의 JsonPath에 fieldPath 환경 변수 소스를 설정하면 빌드 오브젝트에 대한 정보를 삽입할 수 있습니다.

참고

Jenkins Pipeline 전략에서는 환경 변수에 valueFrom 구문을 지원하지 않습니다.

프로세스

  • fieldPath 환경 변수 소스를 값을 가져올 필드의 JsonPath로 설정합니다. 

    env:
  - name: FIELDREF_ENV
    valueFrom:
      fieldRef:
        fieldPath: metadata.name

2.3.9.2. 보안을 환경 변수로 사용

valueFrom 구문을 사용하여 보안의 키 값을 환경 변수로 사용하도록 설정할 수 있습니다.

중요

이 방법은 빌드 Pod 콘솔의 출력에 보안을 일반 텍스트로 표시합니다. 이를 방지하려면 입력 보안 및 구성 맵을 대신 사용합니다.

절차

  • 보안을 환경 변수로 사용하려면 valueFrom 구문을 설정합니다. 

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: MYVAL
        valueFrom:
          secretKeyRef:
            key: myval
            name: mysecret

추가 리소스

2.3.10. 서비스 제공 인증서 보안

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

프로세스

서비스와의 통신을 보호하려면 클러스터에서 서명된 제공 인증서/키 쌍을 네임스페이스의 보안에 생성하도록 합니다.

  • 보안에 사용할 이름으로 설정된 값을 사용하여 서비스에 service.beta.openshift.io/serving-cert-secret-name 주석을 설정합니다.

    그러면 PodSpec에서 해당 보안을 마운트할 수 있습니다. 사용 가능한 경우 Pod가 실행됩니다. 인증서는 내부 서비스 DNS 이름인 <service.name>.<service.namespace>.svc에 적합합니다.

    인증서 및 키는 PEM 형식이며 각각 tls.crt 및 tls.key에 저장됩니다. 인증서/키 쌍은 만료 시기가 다가오면 자동으로 교체됩니다. 시크릿의 service.beta.openshift.io/expiry 주석에서 RFC3339 형식으로 된 만료 날짜를 확인합니다.

참고

대부분의 경우 서비스 DNS 이름 <service.name>.<service.namespace>.svc는 외부에서 라우팅할 수 없습니다. <service.name>.<service.namespace>.svc는 주로 클러스터 내 또는 서비스 내 통신과 경로 재암호화에 사용됩니다.

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

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

2.3.11. 보안 제한 사항

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

  • 컨테이너에 환경 변수를 채우기 위해 사용.
  • 하나 이상의 컨테이너에 마운트된 볼륨에서 파일로 사용.
  • Pod에 대한 이미지를 가져올 때 kubelet으로 사용.

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

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

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

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

2.4. 빌드 출력 관리

빌드 출력 관리에 대한 개요 및 지침은 다음 섹션에서 확인하십시오.

2.4.1. 빌드 출력

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

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

ImageStreamTag로 출력

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

Docker 내보내기 사양으로 출력

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

2.4.2. 이미지 환경 변수 출력

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

변수설명

OPENSHIFT_BUILD_NAME

빌드 이름

OPENSHIFT_BUILD_NAMESPACE

빌드의 네임스페이스

OPENSHIFT_BUILD_SOURCE

빌드의 소스 URL

OPENSHIFT_BUILD_REFERENCE

빌드에 사용된 Git 참조

OPENSHIFT_BUILD_COMMIT

빌드에 사용된 소스 커밋

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

2.4.3. 출력 이미지 라벨

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

레이블설명

io.openshift.build.commit.author

빌드에 사용된 소스 커밋 작성자

io.openshift.build.commit.date

빌드에 사용된 소스 커밋의 날짜

io.openshift.build.commit.id

빌드에 사용된 소스 커밋의 해시

io.openshift.build.commit.message

빌드에 사용된 소스 커밋의 메시지

io.openshift.build.commit.ref

소스에 지정된 분기 또는 참조

io.openshift.build.source-location

빌드의 소스 URL

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"

2.5. 빌드 전략 사용

다음 섹션에서는 지원되는 주요 빌드 전략과 이러한 전략을 사용하는 방법을 정의합니다.

2.5.1. Docker 빌드

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

작은 정보

buildArgs 배열을 사용하여 Docker 빌드 인수를 설정하는 경우 Dockerfile 참조 문서에서 ARG 및 FROM이 상호 작용하는 방법 이해를 참조하십시오.

2.5.1.1. Dockerfile FROM 이미지 교체

Dockerfile의 FROM 명령을 BuildConfig 오브젝트의 from으로 교체할 수 있습니다. Dockerfile에서 다중 단계 빌드를 사용하는 경우 마지막 FROM 명령의 이미지가 교체됩니다.

프로세스

Dockerfile의 FROM 명령을 BuildConfig 오브젝트의 from으로 교체 

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

2.5.1.2. Dockerfile 경로 사용

기본적으로 Docker 빌드는 BuildConfig.spec.source.contextDir 필드에 지정된 컨텍스트의 루트에 있는 Dockerfile을 사용합니다.

dockerfilePath 필드를 사용하면 BuildConfig.spec.source.contextDir 필드와 상대되는 다른 경로를 사용하여 Dockerfile을 찾을 수 있습니다. 파일 이름은 기본 Dockerfile(예: MyDockerfile) 또는 하위 디렉터리의 Dockerfile 경로(예: dockerfiles/app1/Dockerfile)와 다를 수 있습니다.

프로세스

빌드에서 다른 경로를 사용하여 Dockerfile을 찾도록 dockerfilePath 필드를 사용하려면 다음과 같이 설정합니다. 

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

2.5.1.3. Docker 환경 변수 사용

Docker 빌드 프로세스 및 생성된 이미지에 환경 변수를 사용할 수 있도록 빌드 구성의 dockerStrategy 정의에 환경 변수를 추가할 수 있습니다.

정의된 환경 변수는 FROM 명령 직후 단일 ENV Dockerfile 명령으로 삽입되어 나중에 Dockerfile 내에서 참조할 수 있습니다.

프로세스

변수는 빌드 중 정의되고 출력 이미지에 유지되므로 해당 이미지를 실행하는 모든 컨테이너에도 존재합니다.

예를 들어 다음은 빌드 및 런타임 중 사용할 사용자 정의 HTTP 프록시를 정의합니다. 

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

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

2.5.1.4. Docker 빌드 인수 추가

buildArgs 배열을 사용하여 Docker 빌드 인수를 설정할 수 있습니다. 빌드 인수는 빌드가 시작될 때 Docker로 전달됩니다.

작은 정보

Dockerfile 참조 문서에서 ARG 및 FROM이 상호 작용하는 방법 이해를 참조하십시오.

절차

Docker 빌드 인수를 설정하려면 BuildConfig 오브젝트의 dockerStrategy 정의에 있는 buildArgs 배열에 항목을 추가합니다. 예를 들면 다음과 같습니다. 

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

name 및 value 필드만 지원됩니다. valueFrom 필드의 설정은 모두 무시됩니다.

2.5.1.5. Docker 빌드가 포함된 스쿼시링 계층

Docker 빌드는 일반적으로 Dockerfile의 각 명령을 나타내는 계층을 생성합니다. imageOptimizationPolicy를 SkipLayers로 설정하면 모든 명령을 기본 이미지 상단의 단일 계층으로 병합합니다.

프로세스

  • imageOptimizationPolicy를 SkipLayers로 설정합니다. 

    strategy:
  dockerStrategy:
    imageOptimizationPolicy: SkipLayers

2.5.1.6. 빌드 볼륨 사용

빌드 볼륨을 마운트하여 실행 중인 빌드에서 출력 컨테이너 이미지에서 유지하지 않는 정보에 대한 액세스 권한을 부여할 수 있습니다.

빌드 볼륨은 빌드 환경 또는 구성이 빌드 시에만 필요한 리포지토리 자격 증명과 같은 중요한 정보를 제공합니다. 빌드 볼륨은 출력 컨테이너 이미지에서 데이터가 유지될 수 있는 빌드 입력 과 다릅니다.

실행 중인 빌드 볼륨에서 데이터를 읽는 빌드 볼륨의 마운트 지점은 Pod 볼륨 마운트 와 기능적으로 유사합니다.

사전 요구 사항

절차

  • BuildConfig 오브젝트의 dockerStrategy 정의에서 volumes 배열에 빌드 볼륨을 추가합니다. 예를 들면 다음과 같습니다. 

    spec:
  dockerStrategy:
    volumes:
      - name: secret-mvn 1
        mounts:
        - destinationPath: /opt/app-root/src/.ssh 2
        source:
          type: Secret 3
          secret:
            secretName: my-secret 4
      - name: settings-mvn 5
        mounts:
        - destinationPath: /opt/app-root/src/.m2  6
        source:
          type: ConfigMap 7
          configMap:
            name: my-config 8
      - name: my-csi-volume 9
        mounts:
        - destinationPath: /opt/app-root/src/some_path  10
        source:
          type: CSI 11
          csi:
            driver: csi.sharedresource.openshift.io 12
            readOnly: true 13
            volumeAttributes: 14
              attribute: value
    1 5 9
    필수 항목입니다. 고유한 이름입니다.
    2 6 10
    필수 항목입니다. 마운트 지점의 절대 경로입니다. .. 또는 : 를 포함하지 않아야 하며 빌더에서 생성한 대상 경로와 충돌하지 않아야 합니다. /opt/app-root/src 는 많은 Red Hat S2I 지원 이미지의 기본 홈 디렉토리입니다.
    3 7 11
    필수 항목입니다. 소스, ConfigMap,Secret 또는 CSI 의 유형입니다.
    4 8
    필수 항목입니다. 소스 이름입니다.
    12
    필수 항목입니다. 임시 CSI 볼륨을 제공하는 드라이버입니다.
    13
    필수 항목입니다. 이 값은 true 로 설정해야 합니다. 읽기 전용 볼륨을 제공합니다.
    14
    선택 사항: 임시 CSI 볼륨의 볼륨 속성입니다. 지원되는 속성 키와 값은 CSI 드라이버의 설명서를 참조하십시오.
참고

공유 리소스 CSI 드라이버는 기술 프리뷰 기능으로 지원됩니다.

2.5.2. S2I(Source-to-Image) 빌드

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

2.5.2.1. S2I(Source-to-Image) 증분 빌드 수행

S2I(Source-to-Image)는 증분 빌드를 수행할 수 있으므로 이전에 빌드한 이미지의 아티팩트를 재사용할 수 있습니다.

프로세스

  • 증분 빌드를 생성하려면 전략 정의를 다음과 같이 수정합니다. 

    strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "incremental-image:latest" 1
    incremental: true 2
    1
    증분 빌드를 지원하는 이미지를 지정합니다. 빌더 이미지 설명서를 참조하여 이 동작을 지원하는지 확인합니다.
    2
    이 플래그는 증분 빌드 시도 여부를 제어합니다. 빌더 이미지에서 증분 빌드를 지원하지 않는 경우 빌드는 성공하지만 save-artifacts 스크립트 누락으로 인해 증분 빌드가 성공하지 못했다는 로그 메시지가 표시됩니다.

추가 리소스

  • 증분 빌드를 지원하는 빌더 이미지를 생성하는 방법에 대한 내용은 S2I 요구 사항을 참조하십시오.

2.5.2.2. S2I(Source-to-Image) 빌더 이미지 스크립트 덮어쓰기

빌더 이미지에서 제공하는 assemble, run, save-artifacts S2I(Source-to-Image) 스크립트를 덮어쓸 수 있습니다.

프로세스

빌더 이미지에서 제공하는 assemble, run, save-artifacts S2I 스크립트를 덮어쓰려면 다음 중 하나를 수행합니다.

  • 애플리케이션 소스 리포지토리의 .s2i/bin 디렉터리에 assemble, run, 또는 save-artifacts 스크립트를 제공합니다.

  • 스크립트가 포함된 디렉터리의 URL을 전략 정의의 일부로 제공합니다. 예를 들면 다음과 같습니다. 

    strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "builder-image:latest"
    scripts: "http://somehost.com/scripts_directory" 1
    1
    이 경로에는 run, assemble, save-artifacts가 추가됩니다. 일부 또는 모든 스크립트가 확인되면 해당 스크립트가 이미지에 제공된 동일한 이름의 스크립트 대신 사용됩니다.
참고

scripts URL에 있는 파일은 소스 리포지토리의 .s2i/bin에 있는 파일보다 우선합니다.

2.5.2.3. S2I(Source-to-Image) 환경 변수

소스 빌드 프로세스 및 결과 이미지에서 환경 변수를 사용할 수 있도록 하는 방법에는 환경 파일과 BuildConfig 환경 값을 사용하는 것입니다. 제공되는 변수는 빌드 프로세스 중 출력 이미지에 제공됩니다.

2.5.2.3.1. S2I(Source-to-Image) 환경 파일 사용

소스 빌드를 사용하면 소스 리포지토리의 .s2i/environment 파일에 지정하는 방식으로 애플리케이션 내에서 행당 하나씩 환경 값을 설정할 수 있습니다. 이 파일에 지정된 환경 변수는 빌드 프로세스 중 출력 이미지에 제공됩니다.

소스 리포지토리에 .s2i/environment 파일을 제공하는 경우 빌드 중 S2I(Source-to-Image)에서 이 파일을 읽습니다. 그러면 assemble 스크립트에서 이러한 변수를 사용할 수 있으므로 빌드 동작을 사용자 정의할 수 있습니다.

프로세스

예를 들어 빌드 중 Rails 애플리케이션의 자산 컴파일을 비활성화하려면 다음을 수행합니다.

  • .s2i/environment 파일에 DISABLE_ASSET_COMPILATION=true를 추가합니다.

빌드 외에 지정된 환경 변수도 실행 중인 애플리케이션 자체에서 사용할 수 있습니다. 예를 들어 Rails 애플리케이션이 production 대신 development 모드에서 시작되도록 하려면 다음을 수행합니다.

  • RAILS_ENV=development를 .s2i/environment 파일에 추가합니다.

지원되는 환경 변수의 전체 목록은 각 이미지의 이미지 사용 섹션에서 확인할 수 있습니다.

2.5.2.3.2. S2I(Source-to-Image) 빌드 구성 환경 사용

빌드 구성의 sourceStrategy 정의에 환경 변수를 추가할 수 있습니다. 여기에 정의된 환경 변수는 assemble 스크립트를 실행하는 동안 표시되고 출력 이미지에 정의되어 run 스크립트 및 애플리케이션 코드에서도 사용할 수 있습니다.

프로세스

  • 예를 들어 Rails 애플리케이션의 자산 컴파일을 비활성화하려면 다음을 수행합니다. 

    sourceStrategy:
...
  env:
    - name: "DISABLE_ASSET_COMPILATION"
      value: "true"

추가 리소스

  • 빌드 환경 섹션에서는 고급 지침을 제공합니다.
  • oc set env 명령을 사용하면 빌드 구성에 정의된 환경 변수도 관리할 수 있습니다.

2.5.2.4. S2I(Source-to-Image) 소스 파일 무시

S2I(Source-to-Image)는 무시해야 하는 파일 패턴 목록이 포함된 .s2iignore 파일을 지원합니다. .s2iignore 파일에 있는 패턴과 일치하고 다양한 입력 소스에서 제공하는 빌드 작업 디렉터리의 파일은 assemble 스크립트에서 사용할 수 없습니다.

2.5.2.5. S2I(Source-to-Image)를 사용하여 소스 코드에서 이미지 생성

S2I(Source-to-Image)는 애플리케이션 소스 코드를 입력으로 사용하고 어셈블된 애플리케이션을 실행하는 새 이미지를 출력으로 생성하는 이미지를 쉽게 작성할 수 있는 프레임워크입니다.

재현 가능한 컨테이너 이미지를 빌드하는 데 S2I를 사용하는 주요 장점은 개발자가 쉽게 사용할 수 있다는 점입니다. 빌더 이미지 작성자는 이미지에서 최상의 S2I 성능, 빌드 프로세스, S2I 스크립트를 제공하도록 두 가지 기본 개념을 이해해야 합니다.

2.5.2.5.1. S2I(Source-to-Image) 빌드 프로세스 이해

빌드 프로세스는 최종 컨테이너 이미지로 통합되는 다음 세 가지 기본 요소로 구성됩니다.

  • 소스
  • S2I(Source-to-Image) 스크립트
  • 빌더 이미지

S2I는 첫 번째 FROM 명령으로 빌더 이미지가 포함된 Dockerfile을 생성합니다. 그런 다음 S2I에서 생성된 Dockerfile은 Buildah로 전달됩니다.

2.5.2.5.2. S2I(Source-to-Image) 스크립트를 작성하는 방법

스크립트를 빌더 이미지 내에서 실행할 수 있는 경우 모든 프로그래밍 언어로 S2I(Source-to-Image) 스크립트를 작성할 수 있습니다. S2I는 assemble/run/save-artifacts 스크립트를 제공하는 다양한 옵션을 지원합니다. 이러한 위치는 모두 다음 순서에 따라 각 빌드에서 확인합니다.

  1. 빌드 구성에 지정된 스크립트입니다.
  2. 애플리케이션 소스 .s2i/bin 디렉터리에 있는 스크립트입니다.
  3. 라벨이 io.openshift.s2i.scripts-url인 기본 이미지 URL에 있는 스크립트입니다.

이미지에 지정된 io.openshift.s2i.scripts-url 라벨과 빌드 구성에 지정된 스크립트 모두 다음 양식 중 하나를 취할 수 있습니다.

  • image:///path_to_scripts_dir: S2I 스크립트가 있는 디렉터리에 대한 이미지 내부의 절대 경로입니다.
  • file:///path_to_scripts_dir: S2I 스크립트가 있는 호스트의 디렉터리에 대한 상대 또는 절대 경로입니다.
  • http(s)://path_to_scripts_dir: S2I 스크립트가 있는 디렉터리에 대한 URL입니다.

표 2.1. S2I 스크립트

스크립트설명

assemble

assemble 스크립트는 소스에서 애플리케이션 아티팩트를 빌드하여 이미지 내부의 적절한 디렉터리에 배치합니다. 이 스크립트는 필수입니다. 이 스크립트의 워크플로는 다음과 같습니다.

  1. 선택 사항: 빌드 아티팩트를 복구합니다. 증분 빌드를 지원하려면 save-artifacts도 정의해야 합니다.
  2. 애플리케이션 소스를 원하는 위치에 배치합니다.
  3. 애플리케이션 아티팩트를 빌드합니다.
  4. 아티팩트를 실행할 수 있는 적절한 위치에 설치합니다.

run

run 스크립트는 애플리케이션을 실행합니다. 이 스크립트는 필수입니다.

save-artifacts

save-artifacts 스크립트는 이어지는 빌드 프로세스의 속도를 높일 수 있는 모든 종속 항목을 수집합니다. 이 스크립트는 선택 사항입니다. 예를 들면 다음과 같습니다.

  • Ruby의 경우 Bundler에서 설치한 gems입니다.
  • Java의 경우 .m2 콘텐츠입니다.

이러한 종속 항목은 tar 파일로 수집되어 표준 출력으로 스트리밍됩니다.

usage

usage 스크립트를 사용하면 사용자에게 이미지를 올바르게 사용하는 방법을 알릴 수 있습니다. 이 스크립트는 선택 사항입니다.

test/run

test/run 스크립트를 사용하면 이미지가 올바르게 작동하는지 확인하는 프로세스를 생성할 수 있습니다. 이 스크립트는 선택 사항입니다. 해당 프로세스의 제안된 흐름은 다음과 같습니다.

  1. 이미지를 빌드합니다.
  2. 이미지를 실행하여 usage 스크립트를 확인합니다.
  3. s2i build를 실행하여 assemble 스크립트를 확인합니다.
  4. 선택 사항: s2i build를 다시 실행하여 save-artifacts 및 assemble 스크립트에서 아티팩트 기능을 저장 및 복원하는지 확인합니다.
  5. 이미지를 실행하여 테스트 애플리케이션이 작동하는지 확인합니다.
참고

test/run 스크립트로 빌드한 테스트 애플리케이션을 배치하도록 제안된 위치는 이미지 리포지토리의 test/test-app 디렉터리입니다.

S2I 스크립트의 예

다음 예제 S2I 스크립트는 Bash로 작성됩니다. 각 예에서는 tar 콘텐츠가 /tmp/s2i 디렉터리에 압축 해제되어 있다고 가정합니다.

assemble 스크립트:

#!/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

run 스크립트:

#!/bin/bash

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

save-artifacts 스크립트:

#!/bin/bash

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

usage 스크립트:

#!/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

추가 리소스

2.5.2.6. 빌드 볼륨 사용

빌드 볼륨을 마운트하여 실행 중인 빌드에서 출력 컨테이너 이미지에서 유지하지 않는 정보에 대한 액세스 권한을 부여할 수 있습니다.

빌드 볼륨은 빌드 환경 또는 구성이 빌드 시에만 필요한 리포지토리 자격 증명과 같은 중요한 정보를 제공합니다. 빌드 볼륨은 출력 컨테이너 이미지에서 데이터가 유지될 수 있는 빌드 입력 과 다릅니다.

실행 중인 빌드 볼륨에서 데이터를 읽는 빌드 볼륨의 마운트 지점은 Pod 볼륨 마운트 와 기능적으로 유사합니다.

사전 요구 사항

절차

  • BuildConfig 오브젝트의 sourceStrategy 정의에서 volumes 배열에 빌드 볼륨을 추가합니다. 예를 들면 다음과 같습니다. 

    spec:
  sourceStrategy:
    volumes:
      - name: secret-mvn 1
        mounts:
        - destinationPath: /opt/app-root/src/.ssh 2
        source:
          type: Secret 3
          secret:
            secretName: my-secret 4
      - name: settings-mvn 5
        mounts:
        - destinationPath: /opt/app-root/src/.m2 6
        source:
          type: ConfigMap 7
          configMap:
            name: my-config 8
      - name: my-csi-volume 9
        mounts:
        - destinationPath: /opt/app-root/src/some_path  10
        source:
          type: CSI 11
          csi:
            driver: csi.sharedresource.openshift.io 12
            readOnly: true 13
            volumeAttributes: 14
              attribute: value
1 5 9
필수 항목입니다. 고유한 이름입니다.
2 6 10
필수 항목입니다. 마운트 지점의 절대 경로입니다. .. 또는 : 를 포함하지 않아야 하며 빌더에서 생성한 대상 경로와 충돌하지 않아야 합니다. /opt/app-root/src 는 많은 Red Hat S2I 지원 이미지의 기본 홈 디렉토리입니다.
3 7 11
필수 항목입니다. 소스, ConfigMap,Secret 또는 CSI 의 유형입니다.
4 8
필수 항목입니다. 소스 이름입니다.
12
필수 항목입니다. 임시 CSI 볼륨을 제공하는 드라이버입니다.
13
필수 항목입니다. 이 값은 true 로 설정해야 합니다. 읽기 전용 볼륨을 제공합니다.
14
선택 사항: 임시 CSI 볼륨의 볼륨 속성입니다. 지원되는 속성 키와 값은 CSI 드라이버의 설명서를 참조하십시오.
참고

공유 리소스 CSI 드라이버는 기술 프리뷰 기능으로 지원됩니다.

2.5.3. 사용자 정의 빌드

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

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

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

2.5.3.1. 사용자 정의 빌드에 FROM 이미지 사용

customStrategy.from 섹션을 사용하여 사용자 정의 빌드에 사용할 이미지를 표시할 수 있습니다.

프로세스

  • customStrategy.from 섹션을 설정합니다. 

    strategy:
  customStrategy:
    from:
      kind: "DockerImage"
      name: "openshift/sti-image-builder"

2.5.3.2. 사용자 정의 빌드에서 보안 사용

사용자 정의 전략에서는 모든 빌드 유형에 추가할 수 있는 소스 및 이미지 보안 외에 임의의 보안 목록을 빌더 Pod에 추가할 수 있습니다.

프로세스

  • 각 보안을 특정 위치에 마운트하려면 strategy YAML 파일의 secretSource 및 mountPath 필드를 편집합니다. 

    strategy:
  customStrategy:
    secrets:
      - secretSource: 1
          name: "secret1"
        mountPath: "/tmp/secret1" 2
      - secretSource:
          name: "secret2"
        mountPath: "/tmp/secret2"
    1
    secretSource는 빌드와 동일한 네임스페이스에 있는 보안에 대한 참조입니다.
    2
    mountPath는 보안을 마운트해야 하는 사용자 정의 빌더 내부의 경로입니다.

2.5.3.3. 사용자 정의 빌드에 환경 변수 사용

사용자 정의 빌드 프로세스에서 환경 변수를 사용할 수 있도록 하려면 빌드 구성의 customStrategy 정의에 환경 변수를 추가하면 됩니다.

여기에서 정의한 환경 변수는 사용자 정의 빌드를 실행하는 Pod로 전달됩니다.

프로세스

  1. 빌드 중 사용할 사용자 정의 HTTP 프록시를 정의합니다. 

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

  2. 빌드 구성에 정의된 환경 변수를 관리하려면 다음 명령을 입력합니다. 

    $ oc set env <enter_variables>

2.5.3.4. 사용자 정의 빌더 이미지 사용

OpenShift Container Platform의 사용자 정의 빌드 전략을 사용하면 전체 빌드 프로세스를 담당하는 특정 빌더 이미지를 정의할 수 있습니다. 패키지, JAR, WAR, 설치 가능한 ZIP 또는 기본 이미지와 같은 개별 아티팩트를 생성하는 빌드가 필요한 경우 사용자 정의 빌드 전략을 사용하는 사용자 정의 빌더 이미지를 사용합니다.

사용자 정의 빌더 이미지는 RPM 또는 기본 컨테이너 이미지와 같은 아티팩트를 구축하는 데 사용되는 빌드 프로세스 논리에 내장된 일반 컨테이너 이미지입니다.

또한 사용자 정의 빌더를 사용하면 단위 테스트 또는 통합 테스트를 실행하는 CI/CD 흐름과 같이 확장된 빌드 프로세스를 구현할 수 있습니다.

2.5.3.4.1. 사용자 정의 빌더 이미지

사용자 정의 빌더 이미지는 호출 시 빌드를 진행하는 데 필요한 정보와 함께 다음 환경 변수를 수신합니다.

표 2.2. 사용자 정의 빌더 환경 변수

변수 이름설명

BUILD

Build 오브젝트 정의의 전체 직렬화 JSON입니다. 직렬화에 특정 API 버전을 사용해야 하는 경우 빌드 구성의 사용자 정의 전략 사양에 buildAPIVersion 매개변수를 설정하면 됩니다.

SOURCE_REPOSITORY

빌드할 소스가 있는 Git 리포지토리의 URL입니다.

SOURCE_URI

SOURCE_REPOSITORY와 동일한 값을 사용합니다. 둘 중 하나를 사용할 수 있습니다.

SOURCE_CONTEXT_DIR

빌드할 때 사용할 Git 리포지토리의 하위 디렉터리를 지정합니다. 정의한 경우에만 존재합니다.

SOURCE_REF

빌드할 Git 참조입니다.

ORIGIN_VERSION

이 빌드 오브젝트를 생성한 OpenShift Container Platform 마스터의 버전입니다.

OUTPUT_REGISTRY

이미지를 내보낼 컨테이너 이미지 레지스트리입니다.

OUTPUT_IMAGE

빌드 중인 이미지의 컨테이너 이미지 태그 이름입니다.

PUSH_DOCKERCFG_PATH

podman push 작업을 실행하는 데 필요한 컨테이너 레지스트리 자격 증명의 경로입니다.

2.5.3.4.2. 사용자 정의 빌더 워크플로

사용자 정의 빌더 이미지 작성자는 빌드 프로세스를 정의하는 데 유연성이 있지만 빌더 이미지는 OpenShift Container Platform 내에서 빌드를 실행하는 데 필요한 다음 단계를 준수해야 합니다.

  1. Build 오브젝트 정의에는 빌드의 입력 매개변수에 대한 모든 필수 정보가 포함되어 있습니다.
  2. 빌드 프로세스를 실행합니다.
  3. 빌드에서 이미지를 생성하면 빌드의 출력 위치가 정의된 경우 해당 위치로 내보냅니다. 다른 출력 위치는 환경 변수를 통해 전달할 수 있습니다.

2.5.4. 파이프라인 빌드

중요

파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.

OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.

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

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

2.5.4.1. OpenShift Container Platform 파이프라인 이해

중요

파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.

OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.

파이프라인을 사용하면 OpenShift Container Platform에서 애플리케이션의 빌드, 배포, 승격을 제어할 수 있습니다. Jenkins Pipeline 빌드 전략, jenkinsfiles 및 OpenShift Container Platform Domain Specific Language (DSL)의 조합을 사용하여 Jenkins 클라이언트 플러그인에서 제공하는 DSL(OpenShift Container Platform Domain Specific Language)을 사용하면 모든 시나리오에 대해 고급 빌드, 테스트, 배포 및 승격을 수행할 수 있습니다.

OpenShift Container Platform Jenkins 동기화 플러그인

OpenShift Container Platform Jenkins 동기화 플러그인은 Jenkins 작업 및 빌드와 동기화된 빌드 구성 및 빌드 오브젝트를 유지하고 다음 기능을 제공합니다.

  • Jenkins에서 동적 작업 및 실행 생성
  • 이미지 스트림, 이미지 스트림 태그 또는 구성 맵에서 에이전트 Pod 템플릿 동적 생성
  • 환경 변수의 경우:
  • OpenShift Container Platform 웹 콘솔의 파이프라인 시각화
  • Jenkins Git 플러그인과의 통합으로 OpenShift Container Platform 빌드의 커밋 정보를 Jenkins Git 플러그인에 전달합니다.
  • Jenkins 인증 정보 항목에 시크릿 동기화.

OpenShift Container Platform Jenkins 클라이언트 플러그인

OpenShift Container Platform Jenkins 클라이언트 플러그인은 Jenkins 플러그인 중 하나로, OpenShift Container Platform API 서버와의 다양한 상호 작용을 위해 읽기 쉽고 간결하고 포괄적이며 유창한 Jenkins Pipeline 구문을 제공하기 위한 것입니다. 플러그인은 OpenShift Container Platform 명령줄 툴인 oc를 사용하는데 스크립트를 실행하는 노드에서 이 툴을 사용할 수 있어야 합니다.

Jenkins 클라이언트 플러그인은 애플리케이션의 jenkinsfile 내에서 OpenShift Container Platform DSL을 사용할 수 있도록 Jenkins 마스터에 설치해야 합니다. 이 플러그인은 OpenShift Container Platform Jenkins 이미지를 사용할 때 기본적으로 설치 및 활성화됩니다.

프로젝트 내 OpenShift Container Platform Pipeline의 경우 Jenkins Pipeline 빌드 전략을 사용해야 합니다. 이 전략에서는 기본적으로 소스 리포지토리의 루트에서 jenkinsfile을 사용하지만 다음과 같은 구성 옵션을 제공합니다.

  • 빌드 구성 내의 인라인 jenkinsfile 필드
  • 소스 contextDir에 상대적으로 사용할 jenkinsfile의 위치를 참조하는, 빌드 구성 내의 jenkinsfilePath 필드
참고

선택적 jenkinsfilePath 필드는 소스 contextDir에 상대적으로 사용할 파일의 이름을 지정합니다. contextDir이 생략된 경우 기본값은 리포지토리의 루트입니다. jenkinsfilePath가 생략된 경우 기본값은 jenkinsfile입니다.

2.5.4.2. 파이프라인 빌드를 위한 Jenkins 파일 제공

중요

파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.

OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.

jenkinsfile에서는 표준 Groovy 언어 구문을 사용하여 애플리케이션의 구성, 빌드, 배포를 세부적으로 제어할 수 있습니다.

다음 방법 중 하나로 jenkinsfile을 제공할 수 있습니다.

  • 소스 코드 리포지토리에 있는 파일
  • jenkinsfile 필드를 사용하여 빌드 구성의 일부로 포함

첫 번째 옵션을 사용하는 경우 다음 위치 중 하나의 애플리케이션 소스 코드 리포지토리에 jenkinsfile을 포함해야 합니다.

  • 리포지토리 루트에 있는 jenkinsfile이라는 파일
  • 리포지토리의 소스 contextDir 루트에 있는 jenkinsfile이라는 파일
  • BuildConfig의 JenkinsPipelineStrategy 섹션에 있는 jenkinsfilePath 필드를 통해 지정되는 파일 이름(제공되는 경우 소스 contextDir에 상대적이고 제공되지 않는 경우 기본값은 리포지토리의 루트임)

jenkinsfile은 Jenkins 에이전트 Pod에서 실행됩니다. OpenShift Container Platform DSL을 사용하려면 해당 Pod에 사용 가능한 OpenShift Container Platform 클라이언트 바이너리가 있어야 합니다.

프로세스

다음 중 하나를 수행하여 Jenkins 파일을 제공할 수 있습니다.

  • 빌드 구성에 Jenkins 파일 포함
  • 빌드 구성에 Jenkins 파일이 포함된 Git 리포지토리에 대한 참조 포함

포함된 정의

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')
        }

Git 리포지토리에 대한 참조

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

1
선택적 jenkinsfilePath 필드는 소스 contextDir에 상대적으로 사용할 파일의 이름을 지정합니다. contextDir이 생략된 경우 기본값은 리포지토리의 루트입니다. jenkinsfilePath가 생략된 경우 기본값은 jenkinsfile입니다.

2.5.4.3. 파이프라인 빌드에 환경 변수 사용

중요

파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.

OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.

파이프라인 빌드 프로세스에서 환경 변수를 사용할 수 있도록 하려면 빌드 구성의 jenkinsPipelineStrategy 정의에 환경 변수를 추가하면 됩니다.

정의된 환경 변수는 빌드 구성과 관련된 모든 Jenkins 작업의 매개변수로 설정됩니다.

프로세스

  • 빌드 중 사용할 환경 변수를 정의하려면 YAML 파일을 다음과 같이 편집합니다. 

    jenkinsPipelineStrategy:
...
  env:
    - name: "FOO"
      value: "BAR"

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

2.5.4.3.1. BuildConfig 환경 변수 및 Jenkins 작업 매개변수 간 매핑

파이프라인 전략 빌드 구성의 변경 사항에 따라 Jenkins 작업이 생성되거나 업데이트되면 빌드 구성의 모든 환경 변수가 Jenkins 작업 매개 변수 정의에 매핑됩니다. 여기서 Jenkins 작업 매개변수 정의의 기본값은 연결된 환경 변수의 현재 값입니다.

Jenkins 작업의 초기 생성 후에도 Jenkins 콘솔에서 작업에 매개변수를 추가할 수 있습니다. 매개변수 이름은 빌드 구성의 환경 변수 이름과 다릅니다. 매개변수는 해당 Jenkins 작업에 대한 빌드가 시작될 때 적용됩니다.

Jenkins 작업의 빌드를 시작하는 방법에 따라 매개변수 설정 방법이 결정됩니다.

  • oc start-build로 시작하는 경우 빌드 구성의 환경 변수 값은 해당 작업 인스턴스에 설정된 매개변수입니다. Jenkins 콘솔에서 매개변수 기본값을 변경하면 해당 변경 사항이 무시됩니다. 빌드 구성 값이 우선합니다.

  • oc start-build -e로 시작하는 경우 -e 옵션에 지정된 환경 변수의 값이 우선합니다.

    • 빌드 구성에 나열되지 않은 환경 변수를 지정하면 Jenkins 작업 매개변수 정의로 추가됩니다.
    • Jenkins 콘솔에서 환경 변수에 해당하는 매개변수를 변경하면 해당 변경 사항이 무시됩니다. 빌드 구성 및 oc start-build -e로 지정하는 항목이 우선합니다.
  • Jenkins 콘솔에서 Jenkins 작업을 시작하면 작업의 빌드를 시작하는 과정의 일부로 Jenkins 콘솔을 사용하여 매개변수 설정을 제어할 수 있습니다.
참고

빌드 구성에서 작업 매개변수와 연결할 수 있는 모든 환경 변수를 지정하는 것이 좋습니다. 이렇게 하면 디스크 I/O가 줄어들고 Jenkins 처리 중 성능이 향상됩니다.

2.5.4.4. 파이프라인 빌드 튜토리얼

중요

파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.

OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.

이 예제에서는 nodejs-mongodb.json 템플릿을 사용하여 Node.js/MongoDB 애플리케이션을 빌드, 배포, 확인할 OpenShift Container Platform Pipeline을 생성하는 방법을 보여줍니다.

프로세스

  1. Jenkins 마스터를 생성합니다. 

      $ oc project <project_name>

    사용할 프로젝트를 선택하거나 oc new-project <project_name>을 사용하여 새 프로젝트를 생성합니다. 

      $ oc new-app jenkins-ephemeral 1

    영구 스토리지를 사용하려면 대신 jenkins-persistent를 사용합니다.

  2. 다음 콘텐츠를 사용하여 nodejs-sample-pipeline.yaml이라는 파일을 생성합니다.

    참고

    이 과정에서 Jenkins Pipeline 전략을 사용하여 Node.js/MongoDB 예제 애플리케이션을 빌드, 배포, 스케일링하는 BuildConfig 오브젝트가 생성됩니다. 

    kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "nodejs-sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: <pipeline content from below>
    type: JenkinsPipeline

  3. jenkinsPipelineStrategy를 사용하여 BuildConfig 오브젝트를 생성한 후에는 인라인 jenkinsfile을 사용하여 파이프라인에 수행할 작업을 지시합니다.

    참고

    이 예에서는 애플리케이션에 대한 Git 리포지토리를 설정하지 않습니다.

    다음 jenkinsfile 콘텐츠는 OpenShift Container Platform DSL을 사용하여 Groovy로 작성됩니다. 소스 리포지토리에 jenkinsfile을 포함하는 것이 기본 방법이지만 이 예제에서는 YAML 리터럴 스타일을 사용하여 BuildConfig 오브젝트에 인라인 콘텐츠를 포함합니다. 

    def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 1
def templateName = 'nodejs-mongodb-example' 2
pipeline {
  agent {
    node {
      label 'nodejs' 3
    }
  }
  options {
    timeout(time: 20, unit: 'MINUTES') 4
  }
  stages {
    stage('preamble') {
        steps {
            script {
                openshift.withCluster() {
                    openshift.withProject() {
                        echo "Using project: ${openshift.project()}"
                    }
                }
            }
        }
    }
    stage('cleanup') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.selector("all", [ template : templateName ]).delete() 5
                  if (openshift.selector("secrets", templateName).exists()) { 6
                    openshift.selector("secrets", templateName).delete()
                  }
                }
            }
        }
      }
    }
    stage('create') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.newApp(templatePath) 7
                }
            }
        }
      }
    }
    stage('build') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def builds = openshift.selector("bc", templateName).related('builds')
                  timeout(5) { 8
                    builds.untilEach(1) {
                      return (it.object().status.phase == "Complete")
                    }
                  }
                }
            }
        }
      }
    }
    stage('deploy') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def rm = openshift.selector("dc", templateName).rollout()
                  timeout(5) { 9
                    openshift.selector("dc", templateName).related('pods').untilEach(1) {
                      return (it.object().status.phase == "Running")
                    }
                  }
                }
            }
        }
      }
    }
    stage('tag') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 10
                }
            }
        }
      }
    }
  }
}
    1
    사용할 템플릿의 경로입니다.
    1 2
    생성할 템플릿의 이름입니다.
    3
    이 빌드를 실행할 node.js 에이전트 Pod를 구동합니다.
    4
    이 파이프라인에 타임아웃을 20분으로 설정합니다.
    5
    이 템플릿 라벨이 있는 모든 항목을 삭제합니다.
    6
    이 템플릿 라벨을 사용하여 모든 보안을 삭제합니다.
    7
    templatePath에서 새 애플리케이션을 생성합니다.
    8
    빌드가 완료될 때까지 최대 5분 동안 기다립니다.
    9
    배포가 완료될 때까지 최대 5분 정도 기다립니다.
    10
    다른 모든 과정이 성공하면 $ {templateName}:latest 이미지에 $ {templateName}-staging:latest 태그를 지정합니다. 스테이징 환경에 대한 파이프라인 빌드 구성에서는 $ {templateName}-staging:latest 이미지가 변경될 때까지 기다린 다음 해당 이미지를 스테이징 환경에 배포할 수 있습니다.
    참고

    위 예제는 선언적 파이프라인 스타일로 작성되었지만 기존에 스크립팅된 파이프라인 스타일도 지원됩니다.

  4. OpenShift Container Platform 클러스터에서 파이프라인 BuildConfig를 생성합니다. 

    $ oc create -f nodejs-sample-pipeline.yaml

    1. 자체 파일을 생성하지 않으려면 다음을 실행하여 원래 리포지토리의 샘플을 사용하면 됩니다. 

      $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml

  5. 파이프라인을 시작합니다. 

    $ oc start-build nodejs-sample-pipeline
    참고

    또는 빌드 → 파이프라인 섹션으로 이동하여 파이프라인 시작을 클릭하거나 Jenkins 콘솔을 방문하여 생성한 파이프라인으로 이동한 다음 지금 빌드를 클릭하여 OpenShift Container Platform 웹 콘솔에서 파이프라인을 시작할 수 있습니다.

    파이프라인이 시작되면 프로젝트 내에서 수행되는 다음 작업이 표시되어야 합니다.

    • Jenkins 서버에서 작업 인스턴스가 생성됩니다.
    • 파이프라인에 필요한 경우 에이전트 Pod가 시작됩니다.

    • 파이프라인은 에이전트 Pod에서 실행되지만 에이전트가 필요하지 않은 경우에는 마스터에서 실행됩니다.

      • template=nodejs-mongodb-example 라벨을 사용하여 이전에 생성한 리소스는 삭제됩니다.
      • 새 애플리케이션 및 이 애플리케이션의 모든 관련 리소스는 nodejs-mongodb-example 템플릿에서 생성됩니다.

      • nodejs-mongodb-example BuildConfig를 사용하여 빌드가 시작됩니다.

        • 파이프라인은 빌드가 완료될 때까지 기다린 후 다음 단계를 트리거합니다.

      • 배포는 nodejs-mongodb-example 배포 구성을 사용하여 시작됩니다.

        • 파이프라인은 배포가 완료될 때까지 기다린 후 다음 단계를 트리거합니다.
      • 빌드 및 배포가 성공하면 nodejs-mongodb-example:latest 이미지에 nodejs-mongodb-example:stage 태그가 지정됩니다.

    • 파이프라인에 필요한 경우 에이전트 pod가 삭제됩니다.

      참고

      파이프라인 실행을 시각화하는 가장 좋은 방법은 OpenShift Container Platform 웹 콘솔에서 확인하는 것입니다. 웹 콘솔에 로그인하고 빌드 → 파이프라인으로 이동하여 파이프라인을 확인할 수 있습니다.

2.5.5. 웹 콘솔을 사용하여 보안 추가

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

프로세스

OpenShift Container Platform 웹 콘솔에서 개인 리포지토리에 액세스할 수 있도록 빌드 구성에 보안을 추가하려면 다음을 수행합니다.

  1. 새 OpenShift Container Platform 프로젝트를 생성합니다.
  2. 개인 소스 코드 리포지토리에 액세스하는 데 필요한 자격 증명이 포함된 보안을 생성합니다.
  3. 빌드 구성을 생성합니다.
  4. 빌드 구성 편집기 페이지 또는 웹 콘솔의 빌더 이미지에서 앱 생성 페이지에서 소스 보안을 설정합니다.
  5. 저장을 클릭합니다.

2.5.6. 가져오기 및 내보내기 활성화

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

프로세스

프라이빗 레지스트리로 가져오기를 활성화하려면 다음을 수행합니다.

  • 빌드 구성에 가져오기 보안을 설정합니다.

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

  • 빌드 구성에 내보내기 보안을 설정합니다.

2.6. Buildah를 사용한 사용자 정의 이미지 빌드

OpenShift Container Platform 4.13에서는 호스트 노드에 Docker 소켓이 존재하지 않습니다. 즉 사용자 정의 빌드의 Docker 소켓 마운트 옵션에서 사용자 정의 빌드 이미지 내에서 사용하도록 액세스 가능한 Docker 소켓을 제공하지 않을 수 있습니다.

이미지를 빌드하고 내보내기 위해 이 기능이 필요한 경우 사용자 정의 빌드 이미지에 Buildah 툴을 추가한 후 이 툴을 사용하여 사용자 정의 빌드 논리 내에서 이미지를 빌드하고 내보내십시오. 다음은 Buildah를 사용하여 사용자 정의 빌드를 실행하는 방법의 예입니다.

참고

사용자 정의 빌드 전략을 사용하려면 사용자가 클러스터에서 실행되는 권한 있는 컨테이너 내에서 임의의 코드를 실행할 수 있으므로 기본적으로 일반 사용자에게는 없는 권한이 필요합니다. 이 수준의 액세스 권한은 사용 시 클러스터를 손상시킬 수 있으므로 클러스터에 대한 관리 권한이 있는 신뢰할 수 있는 사용자에게만 부여해야 합니다.

2.6.1. 사전 요구 사항

2.6.2. 사용자 정의 빌드 아티팩트 생성

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

프로세스

  1. 빈 디렉터리에서부터 다음 콘텐츠를 사용하여 Dockerfile이라는 파일을 생성합니다. 

    FROM registry.redhat.io/rhel8/buildah
# In this example, `/tmp/build` contains the inputs that build when this
# custom builder image is run. Normally the custom builder image fetches
# this content from some location at build time, by using git clone as an example.
ADD dockerfile.sample /tmp/input/Dockerfile
ADD build.sh /usr/bin
RUN chmod a+x /usr/bin/build.sh
# /usr/bin/build.sh contains the actual custom build logic that will be run when
# this custom builder image is run.
ENTRYPOINT ["/usr/bin/build.sh"]

  2. 동일한 디렉터리에서 dockerfile.sample이라는 파일을 생성합니다. 이 파일은 사용자 정의 빌드 이미지에 포함되어 있으며 사용자 정의 빌드에서 생성하는 이미지를 정의합니다. 

    FROM registry.access.redhat.com/ubi9/ubi
RUN touch /tmp/build

  3. 동일한 디렉터리에 build.sh라는 파일을 생성합니다. 이 파일에는 사용자 정의 빌드가 실행될 때 실행되는 논리가 포함되어 있습니다. 

    #!/bin/sh
# Note that in this case the build inputs are part of the custom builder image, but normally this
# is retrieved from an external source.
cd /tmp/input
# OUTPUT_REGISTRY and OUTPUT_IMAGE are env variables provided by the custom
# build framework
TAG="${OUTPUT_REGISTRY}/${OUTPUT_IMAGE}"


# performs the build of the new image defined by dockerfile.sample
buildah --storage-driver vfs bud --isolation chroot -t ${TAG} .


# buildah requires a slight modification to the push secret provided by the service
# account to use it for pushing the image
cp /var/run/secrets/openshift.io/push/.dockercfg /tmp
(echo "{ \"auths\": " ; cat /var/run/secrets/openshift.io/push/.dockercfg ; echo "}") > /tmp/.dockercfg


# push the new image to the target for the build
buildah --storage-driver vfs push --tls-verify=false --authfile /tmp/.dockercfg ${TAG}

2.6.3. 사용자 정의 빌더 이미지 빌드

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

사전 요구 사항

  • 새 사용자 정의 빌더 이미지를 생성하는 데 사용할 모든 입력을 정의합니다.

프로세스

  1. 사용자 정의 빌더 이미지를 빌드할 BuildConfig 오브젝트를 정의합니다. 

    $ oc new-build --binary --strategy=docker --name custom-builder-image

  2. 사용자 정의 빌드 이미지를 생성한 디렉터리에서 빌드를 실행합니다. 

    $ oc start-build custom-builder-image --from-dir . -F

    빌드가 완료되면 custom-builder-image:latest라는 이미지 스트림 태그의 프로젝트에서 새 사용자 정의 빌더 이미지를 사용할 수 있습니다.

2.6.4. 사용자 정의 빌더 이미지 사용

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

사전 요구 사항

  • 새 사용자 정의 빌더 이미지에 필요한 모든 입력을 정의합니다.
  • 사용자 정의 빌더 이미지를 빌드합니다.

프로세스

  1. buildconfig.yaml이라는 파일을 생성합니다. 이 파일은 프로젝트에서 생성되어 실행되는 BuildConfig 오브젝트를 정의합니다. 

    kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: sample-custom-build
  labels:
    name: sample-custom-build
  annotations:
    template.alpha.openshift.io/wait-for-ready: 'true'
spec:
  strategy:
    type: Custom
    customStrategy:
      forcePull: true
      from:
        kind: ImageStreamTag
        name: custom-builder-image:latest
        namespace: <yourproject> 1
  output:
    to:
      kind: ImageStreamTag
      name: sample-custom:latest
    1
    프로젝트 이름을 지정합니다.

  2. BuildConfig를 생성합니다. 

    $ oc create -f buildconfig.yaml

  3. imagestream.yaml이라는 파일을 생성합니다. 이 파일은 빌드에서 이미지를 내보낼 이미지 스트림을 정의합니다. 

    kind: ImageStream
apiVersion: image.openshift.io/v1
metadata:
  name: sample-custom
spec: {}

  4. 이미지 스트림을 생성합니다. 

    $ oc create -f imagestream.yaml

  5. 사용자 정의 빌드를 실행합니다. 

    $ oc start-build sample-custom-build -F

    빌드를 실행하면 빌드에서 이전에 빌드한 사용자 정의 빌더 이미지를 실행하는 Pod를 시작합니다. Pod는 사용자 정의 빌더 이미지의 진입점으로 정의된 build.sh 논리를 실행합니다. build.sh 논리는 Buildah를 호출하여 사용자 정의 빌더 이미지에 포함된 dockerfile.sample을 빌드한 다음 Buildah를 사용하여 새 이미지를 sample-custom image stream으로 내보냅니다.

2.7. 기본 빌드 수행 및 구성

다음 섹션에서는 빌드 시작 및 취소, BuildConfig 편집, BuildConfig 삭제, 빌드 세부 정보 보기, 빌드 로그 액세스 등 기본 빌드 작업에 대한 지침을 제공합니다.

2.7.1. 빌드 시작

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

프로세스

빌드를 수동으로 시작하려면 다음 명령을 입력합니다. 

$ oc start-build <buildconfig_name>

2.7.1.1. 빌드 재실행

--from-build 플래그를 사용하여 빌드를 수동으로 다시 실행할 수 있습니다.

프로세스

  • 빌드를 수동으로 다시 실행하려면 다음 명령을 입력합니다. 

    $ oc start-build --from-build=<build_name>

2.7.1.2. 빌드 로그 스트리밍

--follow 플래그를 지정하여 빌드의 로그를 stdout에서 스트리밍할 수 있습니다.

프로세스

  • stdout에서 빌드 로그를 수동으로 스트리밍하려면 다음 명령을 입력합니다. 

    $ oc start-build <buildconfig_name> --follow

2.7.1.3. 빌드 시작 시 환경 변수 설정

--env 플래그를 지정하여 빌드에 원하는 환경 변수를 설정할 수 있습니다.

프로세스

  • 원하는 환경 변수를 지정하려면 다음 명령을 입력합니다. 

    $ oc start-build <buildconfig_name> --env=<key>=<value>

2.7.1.4. 소스를 사용하여 빌드 시작

빌드에 Git 소스 가져오기 또는 Dockerfile을 사용하는 대신 소스를 직접 내보내 빌드를 시작할 수 있습니다. 소스는 Git 또는 SVN 작업 디렉터리, 배포하려는 사전 빌드된 바이너리 아티팩트 세트 또는 단일 파일의 콘텐츠일 수 있습니다. 이 작업은 start-build 명령에 다음 옵션 중 하나를 지정하여 수행할 수 있습니다.

옵션설명

--from-dir=<directory>

보관하여 빌드에 바이너리 입력으로 사용할 디렉터리를 지정합니다.

--from-file=<file>

빌드 소스에서 유일한 파일이 될 단일 파일을 지정합니다. 이 파일은 제공된 원래 파일과 파일 이름이 동일한 빈 디렉터리의 루트에 배치됩니다.

--from-repo=<local_source_repo>

빌드에 바이너리 입력으로 사용할 로컬 리포지토리의 경로를 지정합니다. 빌드에 사용되는 분기, 태그 또는 커밋을 제어하는 --commit 옵션을 추가합니다.

이러한 옵션을 빌드에 직접 전달하면 해당 콘텐츠가 빌드로 스트리밍되어 현재 빌드 소스 설정을 덮어씁니다.

참고

바이너리 입력에서 트리거된 빌드는 서버의 소스를 유지하지 않으므로 기본 이미지 변경에 의해 트리거된 리빌드는 빌드 구성에 지정된 소스를 사용합니다.

프로세스

  • 다음 명령을 통해 소스에서 빌드를 시작하여 태그 v2의 아카이브로 로컬 Git 리포지토리의 콘텐츠를 보냅니다. 

    $ oc start-build hello-world --from-repo=../hello-world --commit=v2

2.7.2. 빌드 취소

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

프로세스

  • 빌드를 수동으로 취소하려면 다음 명령을 입력합니다. 

    $ oc cancel-build <build_name>

2.7.2.1. 여러 빌드 취소

다음 CLI 명령으로 여러 빌드를 취소할 수 있습니다.

프로세스

  • 여러 빌드를 수동으로 취소하려면 다음 명령을 입력합니다. 

    $ oc cancel-build <build1_name> <build2_name> <build3_name>

2.7.2.2. 모든 빌드 취소

다음 CLI 명령을 사용하여 빌드 구성에서 모든 빌드를 취소할 수 있습니다.

프로세스

  • 모든 빌드를 취소하려면 다음 명령을 입력합니다. 

    $ oc cancel-build bc/<buildconfig_name>

2.7.2.3. 지정된 상태의 모든 빌드 취소

지정된 상태(new 또는 pending 등)의 빌드는 모두 취소하고 다른 상태의 빌드는 무시할 수 있습니다.

프로세스

  • 지정된 상태의 빌드를 모두 취소하려면 다음 명령을 입력합니다. 

    $ oc cancel-build bc/<buildconfig_name>

2.7.3. BuildConfig 편집

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

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

  • 양식 보기를 사용하면 표준 양식 필드 및 확인란을 사용하여 BuildConfig 를 편집할 수 있습니다.
  • YAML 보기를 사용하면 작업을 완전히 제어하여 BuildConfig 를 편집할 수 있습니다.

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

절차

  1. 개발자 화면의 빌드 보기에서 kebab 메뉴를 클릭하여 BuildConfig 편집 옵션을 확인합니다.
  2. BuildConfig 편집 을 클릭하여 양식 보기 옵션을 확인합니다.

  3. Git 섹션에서 애플리케이션을 생성하는 데 사용할 코드베이스의 Git 리포지토리 URL을 입력합니다. 그런 다음 URL을 검증합니다.

    • 선택 사항: 고급 Git 옵션 표시를 클릭하여 다음과 같은 세부 정보를 추가합니다.

      • 애플리케이션을 빌드하는 데 사용할 코드가 포함된 분기, 태그 또는 커밋을 지정하는 Git 참조 입니다.
      • 컨텍스트 디렉터리: 애플리케이션을 빌드하는 데 사용할 코드가 포함된 하위 디렉터리를 지정합니다.
      • 소스 시크릿: 프라이빗 리포지토리에서 소스 코드를 가져올 수 있는 자격 증명이 포함된 시크릿 이름을 생성합니다.

  4. 빌드 from 섹션에서 빌드하려는 옵션을 선택합니다. 다음 옵션을 사용할 수 있습니다.

    • 이미지 스트림 태그 는 지정된 이미지 스트림 및 태그의 이미지를 참조합니다. 빌드하려는 위치의 프로젝트, 이미지 스트림, 태그를 입력하고 내보냅니다.
    • 이미지 스트림 이미지는 지정된 이미지 스트림 및 이미지 이름의 이미지를 참조합니다. 빌드하려는 이미지 스트림 이미지를 입력합니다. 또한 내보낼 프로젝트, 이미지 스트림 및 태그도 입력합니다.
    • Docker 이미지: Docker 이미지 리포지터리를 통해 Docker 이미지를 참조합니다. 또한 프로젝트, 이미지 스트림 및 태그를 입력하여 푸시할 위치를 참조해야 합니다.
  5. 선택 사항: 환경 변수 섹션에서 이름 및 값 필드를 사용하여 프로젝트와 관련된 환경 변수를 추가합니다. 환경 변수를 추가하려면 Add Value, 또는 Add from ConfigMap and Secret 을 사용합니다.

  6. 선택 사항: 애플리케이션을 추가로 사용자 지정하려면 다음 고급 옵션을 사용합니다.

    Trigger
    빌더 이미지가 변경되면 새 이미지 빌드를 트리거합니다. 트리거 추가를 클릭하고 유형 및 보안을 선택하여 트리거 를 추가합니다.
    보안
    애플리케이션에 대한 시크릿을 추가합니다. 시크릿 추가를 클릭하고 시크릿 및 마운트 지점 을 선택하여 더 많은 시크릿 을 추가합니다.
    정책
    Run policy 를 클릭하여 빌드 실행 정책을 선택합니다. 선택한 정책에 따라 빌드 구성에서 생성한 빌드가 실행되어야 하는 순서가 결정됩니다.
    후크
    이미지 빌드 후 빌드 후크 실행을 선택하여 빌드 끝에 명령을 실행하고 이미지를 확인합니다. Hook type,Command, Arguments 를 추가하여 명령에 추가합니다.
  7. 저장을 클릭하여 BuildConfig 를 저장합니다.

2.7.4. BuildConfig 삭제

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

프로세스

  • BuildConfig를 삭제하려면 다음 명령을 입력합니다. 

    $ oc delete bc <BuildConfigName>

    이 명령은 이 BuildConfig에서 인스턴스화한 빌드도 모두 삭제합니다.

  • BuildConfig는 삭제하고 BuildConfig에서 인스턴스화한 빌드는 유지하려면 다음 명령을 입력할 때 --cascade=false 플래그를 지정하십시오. 

    $ oc delete --cascade=false bc <BuildConfigName>

2.7.5. 빌드 세부 정보 보기

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

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

  • 빌드 소스입니다.
  • 빌드 전략입니다.
  • 출력 대상입니다.
  • 대상 레지스트리의 이미지 다이제스트입니다.
  • 빌드를 생성한 방법입니다.

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

프로세스

  • 빌드 세부 정보를 보려면 다음 명령을 입력합니다. 

    $ oc describe build <build_name>

2.7.6. 빌드 로그에 액세스

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

프로세스

  • 빌드를 직접 사용하여 로그를 스트리밍하려면 다음 명령을 입력합니다. 

    $ oc describe build <build_name>

2.7.6.1. BuildConfig 로그에 액세스

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

프로세스

  • BuildConfig의 최신 빌드 로그를 스트리밍하려면 다음 명령을 입력합니다. 

    $ oc logs -f bc/<buildconfig_name>

2.7.6.2. 특정 버전 빌드의 BuildConfig 로그에 액세스

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

프로세스

  • 특정 버전 빌드의 BuildConfig 로그를 스트리밍하려면 다음 명령을 입력합니다. 

    $ oc logs --version=<number> bc/<buildconfig_name>

2.7.6.3. 로그 세부 정보 표시 활성화

BuildConfig에서 sourceStrategy 또는 dockerStrategy의 일부로 BUILD_LOGLEVEL 환경 변수를 전달하여 더 세부적인 출력을 제공할 수 있습니다.

참고

관리자는 env/BUILD_LOGLEVEL을 구성하여 전체 OpenShift Container Platform 인스턴스에 대한 기본 빌드 세부 정보 표시 수준을 설정할 수 있습니다. 이 기본값은 지정된 BuildConfig에 BUILD_LOGLEVEL을 지정하여 덮어쓸 수 있습니다. 명령줄에서 --build-loglevel을 oc start-build로 전달하여 바이너리가 아닌 빌드에 더 높은 우선순위를 지정할 수 있습니다.

소스 빌드에 사용 가능한 로그 수준은 다음과 같습니다.

수준 0

assemble 스크립트를 실행하는 컨테이너의 출력과 발생한 모든 오류를 생성합니다. 이는 기본값입니다.

수준 1

실행된 프로세스에 대한 기본 정보를 생성합니다.

수준 2

실행된 프로세스에 대한 매우 자세한 정보를 생성합니다.

수준 3

실행된 프로세스에 대한 자세한 정보와 아카이브 콘텐츠 목록을 생성합니다.

수준 4

현재는 수준 3과 동일한 정보를 제공합니다.

수준 5

위 수준에서 언급한 모든 정보를 생성하고 Docker 내보내기 메시지도 제공합니다.

프로세스

  • 더 세부적인 출력을 제공하기 위해 BuildConfig에서 sourceStrategy 또는 dockerStrategy의 일부로 BUILD_LOGLEVEL 환경 변수를 전달합니다. 

    sourceStrategy:
...
  env:
    - name: "BUILD_LOGLEVEL"
      value: "2" 1
    1
    이 값을 원하는 로그 수준으로 조정합니다.

2.8. 빌드 트리거 및 수정

다음 섹션에서는 빌드 후크를 사용하여 빌드를 트리거하고 수정하는 방법을 간략하게 설명합니다.

2.8.1. 빌드 트리거

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

  • Webhook
  • 이미지 변경
  • 구성 변경

2.8.1.1. Webhook 트리거

Webhook 트리거를 사용하면 OpenShift Container Platform API 끝점에 요청을 전송하여 새 빌드를 트리거할 수 있습니다. 이러한 트리거는 GitHub, GitLab, Bitbucket 또는 Generic Webhook를 사용하여 정의할 수 있습니다.

현재는 OpenShift Container Platform Webhook에서 Git 기반 SCM(소스 코드 관리) 시스템 각각에 대해 유사한 버전의 내보내기 이벤트만 지원합니다. 기타 모든 이벤트 유형은 무시됩니다.

내보내기 이벤트가 처리되면 OpenShift Container Platform 컨트롤 플레인 호스트에서 이벤트 내부의 분기 참조가 해당 BuildConfig 의 분기 참조와 일치하는지 확인합니다. 일치하는 경우 OpenShift Container Platform 빌드의 Webhook 이벤트에 언급된 커밋 참조가 정확한지 확인합니다. 일치하지 않는 경우에는 빌드가 트리거되지 않습니다.

참고

oc new-app 및 oc new-build는 GitHub 및 Generic Webhook 트리거를 자동으로 생성하지만 필요한 다른 Webhook 트리거는 수동으로 추가해야 합니다. 트리거 설정을 통해 트리거를 수동으로 추가할 수 있습니다.

모든 Webhook에 대해 WebHookSecretKey라는 키와 Webhook를 호출할 때 제공할 값이 되는 값을 사용하여 보안을 정의해야 합니다. 그런 다음 Webhook 정의에서 보안을 참조해야 합니다. 보안을 사용하면 URL의 고유성이 보장되어 다른 사용자가 빌드를 트리거할 수 없습니다. 키 값은 Webhook 호출 중 제공되는 보안과 비교됩니다.

예를 들면 아래 예제에는 mysecret이라는 보안에 대한 참조가 포함된 GitHub Webhook가 있습니다. 

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

그런 다음 보안이 다음과 같이 정의됩니다. 보안 값은 Secret 오브젝트의 data 필드에 필요하므로 base64로 인코딩됩니다. 

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx
2.8.1.1.1. GitHub Webhook 사용

GitHub Webhook는 리포지토리를 업데이트할 때 GitHub에서 생성하는 호출을 처리합니다. 트리거를 정의할 때는 보안을 지정해야 하는데, 보안은 Webhook를 구성할 때 GitHub에 제공하는 URL의 일부입니다.

GitHub Webhook 정의의 예: 

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

Webhook 트리거 구성에 사용되는 보안은 GitHub UI에서 Webhook를 구성할 때 표시되는 secret 필드와 동일하지 않습니다. 전자는 Webhook URL을 고유하고 예측하기 어렵게 만들고, 후자는 X-Hub-Signature 헤더로 전송되는 본문의 HMAC 16진수 다이제스트를 생성하는 데 사용되는 선택적 문자열 필드입니다.

페이로드 URL은 oc describe 명령에 의해 GitHub Webhook URL로 반환되고(Webhook URL 표시 참조) 다음과 같이 구성됩니다.

출력 예

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

사전 요구 사항

  • GitHub 리포지토리에서 BuildConfig를 생성합니다.

프로세스

  1. GitHub Webhook를 구성하려면 다음을 수행합니다.

    1. GitHub 리포지토리에서 BuildConfig를 생성한 후 다음을 실행합니다. 

      $ oc describe bc/<name-of-your-BuildConfig>

      그러면 다음과 같은 Webhook GitHub URL이 생성됩니다.

      출력 예

      <https://api.starter-us-east-1.openshift.com:443/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

    2. GitHub 웹 콘솔에서 이 URL을 잘라내어 GitHub에 붙여넣습니다.
    3. GitHub 리포지토리의 설정 → Webhook에서 Webhook 추가를 선택합니다.
    4. URL 출력을 페이로드 URL 필드에 붙여넣습니다.
    5. GitHub의 기본 application/x-www-form-urlencoded에서 콘텐츠 유형을 application/json으로 변경합니다.

    6. Webhook 추가를 클릭합니다.

      GitHub에서 Webhook가 성공적으로 구성되었음을 알리는 메시지가 표시됩니다.

      이제 GitHub 리포지토리에 변경 사항을 내보내면 새 빌드가 자동으로 시작되고 빌드가 성공하면 새 배포가 시작됩니다.

      참고

      Gogs는 GitHub와 동일한 Webhook 페이로드 형식을 지원합니다. 따라서 Gogs 서버를 사용하는 경우 BuildConfig에 GitHub Webhook 트리거를 정의하고 Gogs 서버에서도 트리거할 수 있습니다.

  2. payload.json과 같이 유효한 JSON 페이로드가 포함된 파일의 경우 curl을 사용하여 Webhook를 수동으로 트리거할 수 있습니다. 

    $ curl -H "X-GitHub-Event: push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

    -k 인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.

참고

GitHub Webhook 이벤트의 ref 값이 BuildConfig 리소스의 source.git 필드에 지정된 참조 값과 일치하는 경우에만 빌드가 트리거됩니다.

추가 리소스

2.8.1.1.2. GitLab Webhook 사용

GitLab Webhook는 리포지토리를 업데이트할 때 GitLab에서 생성하는 호출을 처리합니다. GitHub 트리거와 마찬가지로 보안을 지정해야 합니다. 다음 예제는 BuildConfig 내의 트리거 정의 YAML입니다. 

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

페이로드 URL은 oc describe 명령을 통해 GitLab Webhook URL로 반환되고 다음과 같이 구조화됩니다.

출력 예

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

프로세스

  1. GitLab Webhook를 구성하려면 다음을 수행합니다.

    1. Webhook URL을 가져오도록 BuildConfig를 지정합니다. 

      $ oc describe bc <name>
    2. Webhook URL을 복사하여 <secret>을 보안 값으로 교체합니다.
    3. GitLab 설정 지침에 따라 Webhook URL을 GitLab 리포지토리 설정에 붙여넣습니다.

  2. payload.json과 같이 유효한 JSON 페이로드가 포함된 파일의 경우 curl을 사용하여 Webhook를 수동으로 트리거할 수 있습니다. 

    $ curl -H "X-GitLab-Event: Push Hook" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

    -k 인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.

2.8.1.1.3. Bitbucket Webhook 사용

Bitbucket Webhook는 리포지토리가 업데이트될 때 Bitbucket에서 만든 호출을 처리합니다. 이전 트리거와 유사하게 보안을 지정해야 합니다. 다음 예제는 BuildConfig 내의 트리거 정의 YAML입니다. 

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

페이로드 URL은 oc describe 명령을 통해 Bitbucket Webhook URL로 반환되고 다음과 같이 구조화됩니다.

출력 예

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

프로세스

  1. Bitbucket Webhook를 구성하려면 다음을 수행합니다.

    1. Webhook URL을 가져오도록 'BuildConfig'를 지정합니다. 

      $ oc describe bc <name>
    2. Webhook URL을 복사하여 <secret>을 보안 값으로 교체합니다.
    3. Bitbucket 설정 지침에 따라 Webhook URL을 Bitbucket 리포지토리 설정에 붙여넣습니다.

  2. payload.json과 같이 유효한 JSON 페이로드가 포함된 파일의 경우 curl을 사용하여 Webhook를 수동으로 트리거할 수 있습니다. 

    $ curl -H "X-Event-Key: repo:push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

    -k 인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.

2.8.1.1.4. 일반 Webhook 사용

일반 Webhook는 웹 요청을 수행할 수 있는 모든 시스템에서 호출합니다. 다른 Webhook와 마찬가지로 보안을 지정해야 하는데 보안은 호출자가 빌드를 트리거하는 데 사용해야 하는 URL의 일부입니다. 보안을 사용하면 URL의 고유성이 보장되어 다른 사용자가 빌드를 트리거할 수 없습니다. 다음은 BuildConfig 내 트리거 정의 YAML의 예입니다. 

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1
1
일반 Webhook에서 환경 변수를 전달하도록 허용하려면 true로 설정합니다.

프로세스

  1. 호출자를 설정하기 위해 빌드에 대한 일반 Webhook 끝점의 URL을 호출 시스템에 제공합니다.

    출력 예

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

    호출자는 Webhook를 POST 작업으로 호출해야 합니다.

  2. Webhook를 수동으로 호출하려면 curl을 사용하면 됩니다. 

    $ curl -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

    HTTP 동사를 POST로 설정해야 합니다. 비보안 -k 플래그는 인증서 검증을 무시하도록 지정됩니다. 클러스터에 올바르게 서명된 인증서가 있는 경우 이 두 번째 플래그는 필요하지 않습니다.

    끝점은 다음 형식을 사용하여 선택적 페이로드를 허용할 수 있습니다. 

    git:
  uri: "<url to git repository>"
  ref: "<optional git reference>"
  commit: "<commit hash identifying a specific git commit>"
  author:
    name: "<author name>"
    email: "<author e-mail>"
  committer:
    name: "<committer name>"
    email: "<committer e-mail>"
  message: "<commit message>"
env: 1
   - name: "<variable name>"
     value: "<variable value>"
    1
    BuildConfig 환경 변수와 유사하게 여기에 정의된 환경 변수도 빌드에 사용할 수 있습니다. 이러한 변수가 BuildConfig 환경 변수와 충돌하는 경우 해당 변수가 우선합니다. 기본적으로 Webhook에서 전달하는 환경 변수는 무시됩니다. 이 동작을 활성화하려면 Webhook 정의에서 allowEnv 필드를 true로 설정합니다.

  3. curl을 사용하여 이 페이로드를 전달하려면 payload_file.yaml이라는 파일에 페이로드를 정의하고 다음을 실행합니다. 

    $ curl -H "Content-Type: application/yaml" --data-binary @payload_file.yaml -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

    인수는 위 예제와 동일하고 헤더와 페이로드가 추가되었습니다. -H 인수는 페이로드 형식에 따라 Content-Type 헤더를 application/yaml 또는 application/json으로 설정합니다. --data-binary 인수는 POST 요청을 사용하여 온전한 새 줄로 바이너리 페이로드를 보내는 데 사용됩니다.

참고

OpenShift Container Platform에서는 유효하지 않은 요청 페이로드(예: 유효하지 않은 콘텐츠 유형, 구문 분석할 수 없거나 유효하지 않은 콘텐츠 등)가 제공되는 경우에도 일반 Webhook에서 빌드를 트리거할 수 있습니다. 이 동작은 이전 버전과의 호환성을 위해 유지됩니다. 유효하지 않은 요청 페이로드가 제공되면 OpenShift Container Platform에서 HTTP 200 OK 응답의 일부로 JSON 형식의 알림을 반환합니다.

2.8.1.1.5. Webhook URL 표시

다음 명령을 사용하여 빌드 구성과 관련된 Webhook URL을 표시할 수 있습니다. 이 명령에서 Webhook URL을 표시하지 않으면 해당 빌드 구성에 Webhook 트리거가 정의되지 않습니다.

프로세스

  • BuildConfig와 관련된 Webhook URL을 표시하려면 다음을 실행합니다. 
$ oc describe bc <name>

2.8.1.2. 이미지 변경 트리거 사용

개발자는 기본 이미지가 변경될 때마다 자동으로 실행되도록 빌드를 구성할 수 있습니다.

이미지 변경 트리거를 사용하여 업스트림 이미지의 새 버전을 사용할 수 있을 때 빌드를 자동으로 호출할 수 있습니다. 예를 들어 빌드가 RHEL 이미지를 기반으로 하는 경우 해당 빌드를 트리거하여 RHEL 이미지를 변경할 때마다 실행할 수 있습니다. 결과적으로 애플리케이션 이미지는 항상 최신 RHEL 기본 이미지에서 실행됩니다.

참고

v1 컨테이너 레지스트리의 컨테이너 이미지를 가리키는 이미지 스트림은 이미지 스트림 태그를 사용할 수 있을 때 빌드를 한 번만 트리거하고 후속 이미지 업데이트에서는 빌드를 트리거하지 않습니다. 이는 v1 컨테이너 레지스트리에서 고유하게 확인할 수 있는 이미지가 없기 때문입니다.

절차

  1. 트리거로 사용하려는 업스트림 이미지를 가리키는 ImageStream을 정의합니다. 

    kind: "ImageStream"
apiVersion: "v1"
metadata:
  name: "ruby-20-centos7"

    이는 <system-registry>/<namespace>/ruby-20-centos7에 있는 컨테이너 이미지 리포지토리에 연결된 이미지 스트림을 정의합니다. <system-registry>는 OpenShift Container Platform에서 실행 중인 docker-registry라는 이름을 사용하여 서비스로 정의됩니다.

  2. 이미지 스트림이 빌드의 기본 이미지인 경우 빌드 전략의 from 필드를 ImageStream을 가리키도록 설정합니다. 

    strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "ruby-20-centos7:latest"

    이 경우 sourceStrategy 정의에서는 이 네임스페이스 내에 있는 ruby-20-centos7이라는 이미지 스트림의 latest 태그를 사용합니다.

  3. ImageStreams를 가리키는 하나 이상의 트리거를 사용하여 빌드를 정의합니다. 

    type: "ImageChange" 1
imageChange: {}
type: "ImageChange" 2
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
    1
    빌드 전략의 from 필드에 정의된 ImageStream 및 Tag를 모니터링하는 이미지 변경 트리거입니다. 여기에서 imageChange 오브젝트는 비어 있어야 합니다.
    2
    임의의 이미지 스트림을 모니터링하는 이미지 변경 트리거입니다. 이 경우 imageChange 부분에 모니터링할 ImageStreamTag를 참조하는 from 필드를 포함해야 합니다.

전략 이미지 스트림에 이미지 변경 트리거를 사용하는 경우 생성된 빌드에 해당 태그와 일치하는 최신 이미지를 가리키는 변경 불가능한 Docker 태그가 제공됩니다. 이 새 이미지 참조는 빌드에 대해 실행할 때 전략에서 사용합니다.

전략 이미지 스트림을 참조하지 않는 다른 이미지 변경 트리거의 경우 새 빌드가 시작되지만 빌드 전략은 고유 이미지 참조로 업데이트되지 않습니다.

이 예제에는 전략에 대한 이미지 변경 트리거가 있으므로 결과 빌드는 다음과 같습니다. 

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

그 결과 트리거된 빌드는 리포지토리로 방금 푸시된 새 이미지를 사용하고 동일한 입력을 사용하여 빌드를 다시 실행할 수 있습니다.

이미지 변경 트리거를 일시 정지하여 빌드를 시작하기 전에 참조 이미지 스트림에 대한 다양한 변경 사항을 허용할 수 있습니다. 처음에 ImageChangeTrigger를 BuildConfig에 추가할 때 빌드가 즉시 트리거되지 않도록 paused 특성을 true로 설정할 수도 있습니다. 

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

모든 Strategy 유형의 이미지 필드를 설정하는 것 외에 사용자 지정 빌드의 경우 OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE 환경 변수도 확인합니다. 존재하지 않는 경우 변경 불가능한 이미지 참조를 사용하여 생성됩니다. 존재하는 경우 변경 불가능한 이미지 참조를 사용하여 업데이트됩니다.

Webhook 트리거 또는 수동 요청으로 인해 빌드가 트리거되는 경우 생성된 빌드는 Strategy에서 참조한 ImageStream의 확인된 <immutableid>를 사용합니다. 그러면 쉽게 재현할 수 있도록 일관된 이미지 태그를 사용하여 빌드를 수행할 수 있습니다.

추가 리소스

2.8.1.3. 빌드의 이미지 변경 트리거 식별

개발자는 이미지 변경 트리거가 있는 경우 마지막 빌드를 시작한 이미지 변경 사항을 확인할 수 있습니다. 이는 빌드를 디버깅하거나 문제 해결하는 데 유용할 수 있습니다.

BuildConfig 예

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

참고

이 예제에서는 이미지 변경 트리거와 관련이 없는 요소를 생략합니다.

사전 요구 사항

  • 여러 이미지 변경 트리거를 구성했습니다. 이러한 트리거는 하나 이상의 빌드를 트리거했습니다.

절차

  1. buildConfig.status.imageChangeTriggers에서 최신 타임 스탬프가 있는 lastTriggerTime을 식별합니다.

    ImageChangeTriggerStatus 

    Then you use the `name` and `namespace` from that build to find the corresponding image change trigger in `buildConfig.spec.triggers`.
  2. imageChangeTriggers에서 타임스탬프를 비교하여 최신 정보를 식별합니다.

이미지 변경 트리거

빌드 구성에서 buildConfig.spec.triggers는 빌드 트리거 정책인 BuildTriggerPolicy의 배열입니다.

각 BuildTriggerPolicy에는 type 필드와 포인터 필드 세트가 있습니다. 각 포인터 필드는 type 필드에 허용된 값 중 하나에 해당합니다. 따라서 BuildTriggerPolicy를 하나의 포인터 필드로만 설정할 수 있습니다.

이미지 변경 트리거의 경우 type 값은 ImageChange입니다. 그런 다음 imageChange 필드는 다음 필드가 있는 ImageChangeTrigger 오브젝트의 포인터입니다.

  • lastTriggeredImageID: 예제에 표시되지 않는 이 필드는 OpenShift Container Platform 4.8에서 더 이상 사용되지 않으며 향후 릴리스에서 무시됩니다. 이 BuildConfig에서 마지막 빌드가 트리거된 경우 ImageStreamTag에 대한 확인된 이미지 참조가 포함됩니다.
  • paused: 예제에 표시되지 않는 이 필드를 사용하여 이 특정 이미지 변경 트리거를 일시적으로 비활성화할 수 있습니다.
  • from: 이 필드를 사용하여 이 이미지 변경 트리거를 구동하는 ImageStreamTag를 참조합니다. 유형은 핵심 Kubernetes 유형인 OwnerReference입니다.

from 필드에는 다음과 같은 참고 필드가 있습니다. kind: 이미지 변경 트리거의 경우 지원되는 유일한 값은 ImageStreamTag입니다. namespace:이 필드를 사용하여 ImageStreamTag의 네임스페이스를 지정합니다. ** name:이 필드를 사용하여 ImageStreamTag를 지정합니다.

이미지 변경 트리거 상태

빌드 구성에서 buildConfig.status.imageChangeTriggers는 ImageChangeTriggerStatus 요소의 배열입니다. 각 ImageChangeTriggerStatus 요소에는 앞의 예에서 표시된 from, lastTriggeredImageID 및 lastTriggerTime 요소가 포함됩니다.

가장 최근의 lastTriggerTime이 있는 ImageChangeTriggerStatus가 가장 최근 빌드를 트리거했습니다. 해당 name 및 namespace를 사용하여 빌드를 트리거한 buildConfig.spec.triggers에서 이미지 변경 트리거를 식별합니다.

가장 최근 타임스탬프를 사용하는 lastTriggerTime은 마지막 빌드의 ImageChangeTriggerStatus를 나타냅니다. 이 ImageChangeTriggerStatus에는 빌드를 트리거한 buildConfig.spec.triggers의 이미지 변경 트리거와 동일한 name과 namespace가 있습니다.

추가 리소스

2.8.1.4. 구성 변경 트리거

구성 변경 트리거를 사용하면 새 BuildConfig가 생성되는 즉시 빌드가 자동으로 호출됩니다.

다음은 BuildConfig 내 트리거 정의 YAML의 예입니다. 

  type: "ConfigChange"
참고

구성 변경 트리거는 현재 새 BuildConfig를 생성할 때만 작동합니다. 향후 릴리스에서는 BuildConfig가 업데이트될 때마다 구성 변경 트리거도 빌드를 시작할 수 있습니다.

2.8.1.4.1. 트리거 수동 설정

oc set triggers를 사용하여 빌드 구성에서 트리거를 추가 및 제거할 수 있습니다.

프로세스

  • 빌드 구성에 GitHub Webhook 트리거를 설정하려면 다음을 사용합니다. 

    $ oc set triggers bc <name> --from-github

  • 이미지 변경 트리거를 설정하려면 다음을 사용합니다. 

    $ oc set triggers bc <name> --from-image='<image>'

  • 트리거를 제거하려면 --remove를 추가합니다. 

    $ oc set triggers bc <name> --from-bitbucket --remove
참고

Webhook 트리거가 이미 있는 경우 해당 트리거를 다시 추가하면 Webhook 보안이 다시 생성됩니다.

자세한 내용은 다음을 실행하여 도움말 문서를 참조하십시오. 

$ oc set triggers --help

2.8.2. 빌드 후크

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

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

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

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

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

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

2.8.2.1. post-commit 빌드 후크 구성

빌드 후 후크를 구성하는 방법은 다양합니다. 다음 예제에서 모든 양식은 동일하고 bundle exec rake test --verbose를 실행합니다.

프로세스

  • 쉘 스크립트: 

    postCommit:
  script: "bundle exec rake test --verbose"

    script 값은 /bin/sh -ic를 사용하여 실행할 쉘 스크립트입니다. 쉘 스크립트가 빌드 후크를 실행하는 데 적합한 경우 이 값을 사용합니다. 예를 들면 위와 같이 단위 테스트를 실행하는 경우입니다. 이미지 항목 지점을 제어하려는 경우 또는 이미지에 /bin/sh가 없는 경우 command 및/또는 args를 사용합니다.

    참고

    추가 -i 플래그는 CentOS 및 RHEL 이미지 작업 환경을 개선하기 위해 도입되었으며 향후 릴리스에서 제거될 수 있습니다.

  • 이미지 진입점으로서의 명령: 

    postCommit:
  command: ["/bin/bash", "-c", "bundle exec rake test --verbose"]

    이 양식에서 command는 실행할 명령에 해당하며 Dockerfile 참조에 설명된 exec 형식의 이미지 진입점을 덮어씁니다. 이 명령은 이미지에 /bin/sh가 없거나 쉘을 사용하지 않는 경우 필요합니다. 다른 모든 경우에는 script를 사용하는 것이 더 편리할 수 있습니다.

  • 인수가 있는 명령: 

    postCommit:
  command: ["bundle", "exec", "rake", "test"]
  args: ["--verbose"]

    이 형식은 command에 인수를 추가하는 것과 동일합니다.

참고

script와 command를 동시에 제공하면 유효하지 않은 빌드 후크가 생성됩니다.

2.8.2.2. CLI를 사용하여 post-commit 빌드 후크 설정

oc set build-hook 명령은 빌드 설정에 빌드 후크를 설정하는 데 사용할 수 있습니다.

프로세스

  1. 명령을 post-commit 빌드 후크로 설정하려면 다음을 실행합니다. 

    $ oc set build-hook bc/mybc \
    --post-commit \
    --command \
    -- bundle exec rake test --verbose

  2. 스크립트를 post-commit 빌드 후크로 설정하려면 다음을 실행합니다. 

    $ oc set build-hook bc/mybc --post-commit --script="bundle exec rake test --verbose"

2.9. 고급 빌드 수행

다음 섹션에서는 빌드 리소스 및 최대 기간 설정, 노드에 빌드 할당, 빌드 연결, 빌드 정리, 빌드 실행 정책 등 고급 빌드 작업에 대한 지침을 제공합니다.

2.9.1. 빌드 리소스 설정

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

프로세스

다음 두 가지 방법으로 리소스 사용을 제한할 수 있습니다.

  • 프로젝트의 기본 컨테이너 제한에 리소스 제한을 지정하여 리소스 사용 제한을 제한합니다.

  • 리소스 제한을 빌드 구성의 일부로 지정하여 리소스 사용을 제한합니다. **다음 예제에서는 각 resources, cpu, memory 매개변수가 선택 사항입니다. 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  resources:
    limits:
      cpu: "100m" 1
      memory: "256Mi" 2
    1
    cpu는 CPU 단위입니다. 100m은 0.1 CPU 단위(100 * 1e-3)를 나타냅니다.
    2
    memory는 바이트 단위입니다. 256Mi는 268435456바이트(256 * 2 ^ 20)를 나타냅니다.

    그러나 프로젝트에 할당량을 정의한 경우 다음 두 항목 중 하나가 필요합니다.

    • requests가 명시적으로 설정된 resources 섹션: 

      resources:
  requests: 1
    cpu: "100m"
    memory: "256Mi"
      1
      requests 오브젝트에 할당량의 리소스 목록에 해당하는 리소스 목록이 포함되어 있습니다.

    • 프로젝트에 정의된 제한 범위: LimitRange 오브젝트의 기본값은 빌드 프로세스 중 생성된 Pod에 적용됩니다.

      그러지 않으면 할당량을 충족하지 못하여 빌드 Pod 생성이 실패합니다.

2.9.2. 최대 기간 설정

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

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

프로세스

  • 최대 기간을 설정하려면 BuildConfig에서 completionDeadlineSeconds를 지정합니다. 다음 예제에서는 completionDeadlineSeconds 필드를 30분으로 지정하는 BuildConfig의 일부를 보여줍니다. 

    spec:
  completionDeadlineSeconds: 1800
참고

파이프라인 전략 옵션에서는 이 설정이 지원되지 않습니다.

2.9.3. 특정 노드에 빌드 할당

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

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

참고

지정된 NodeSelector가 해당 라벨이 있는 노드와 일치하지 않는 경우 빌드는 계속 Pending 상태로 무기한 유지됩니다.

프로세스

  • BuildConfig의 nodeSelector 필드에 라벨을 할당하여 특정 노드에서 실행할 빌드를 할당합니다. 예를 들면 다음과 같습니다. 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  nodeSelector:1
    key1: value1
    key2: value2
    1
    이 빌드 구성과 관련된 빌드는 key1=value2 및 key2=value2 라벨이 있는 노드에서만 실행됩니다.

2.9.4. 연결된 빌드

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

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

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

참고

이 예제에서는 S2I 빌드와 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
1
from은 Docker 빌드에 이전 빌드의 타겟이었던 artifact-image 이미지 스트림의 이미지 출력이 포함되어야 함을 나타냅니다.
2
paths는 현재 Docker 빌드에 포함할 대상 이미지의 경로를 지정합니다.
3
런타임 이미지는 Docker 빌드의 소스 이미지로 사용됩니다.

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

2.9.5. 빌드 정리

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

프로세스

  1. BuildConfig의 successfulBuildsHistoryLimit 또는 failedBuildsHistoryLimit에 양의 정수 값을 제공하여 유지되는 이전 빌드의 수를 제한합니다. 예를 들면 다음과 같습니다. 

    apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2 1
  failedBuildsHistoryLimit: 2 2
    1
    successfulBuildsHistoryLimit은 completed 상태의 빌드를 두 개까지 유지합니다.
    2
    failedBuildsHistoryLimit은 failed, canceled 또는 error 상태의 빌드를 두 개까지 유지합니다.

  2. 다음 작업 중 하나로 빌드 정리를 트리거합니다.

    • 빌드 구성 업데이트
    • 빌드가 라이프사이클을 완료할 때까지 대기

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

참고

관리자는 'oc adm' 오브젝트 정리 명령을 사용하여 수동으로 빌드를 정리할 수 있습니다.

2.9.6. 빌드 정책 실행

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

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

  • Parallel을 Serial 또는 SerialLatestOnly로 변경하고 이 구성에서 새 빌드를 트리거하면 직렬 빌드는 단독으로만 실행할 수 있으므로 모든 병렬 빌드가 완료될 때까지 새 빌드가 대기합니다.
  • Serial을 SerialLatestOnly로 변경하고 새 빌드를 트리거하면 현재 실행 중인 빌드와 최근 생성된 빌드를 제외하고 대기열에 있는 기존 빌드가 모두 취소됩니다. 최신 빌드는 다음에 실행됩니다.

2.10. 빌드에서 Red Hat 서브스크립션 사용

OpenShift Container Platform에서 권한이 있는 빌드를 실행하려면 다음 섹션을 사용합니다.

2.10.1. Red Hat Universal Base Image에 대한 이미지 스트림 태그 생성

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

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

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

프로세스

  • openshift 네임스페이스에 ImageStreamTag를 생성하려면 모든 프로젝트의 개발자가 다음을 입력하면 됩니다. 

    $ oc tag --source=docker registry.redhat.io/ubi9/ubi:latest ubi:latest -n openshift
    작은 정보

    다음 YAML을 적용하여 openshift 네임스페이스에 ImageStreamTag 를 생성할 수 있습니다. 

    apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
  name: ubi
  namespace: openshift
spec:
  tags:
  - from:
      kind: DockerImage
      name: registry.redhat.io/ubi9/ubi:latest
    name: latest
    referencePolicy:
      type: Source

  • 단일 프로젝트에서 ImageStreamTag를 생성하려면 다음을 입력합니다. 

    $ oc tag --source=docker registry.redhat.io/ubi9/ubi:latest ubi:latest
    작은 정보

    또는 다음 YAML을 적용하여 단일 프로젝트에서 ImageStreamTag 를 생성할 수 있습니다. 

    apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
  name: ubi
spec:
  tags:
  - from:
      kind: DockerImage
      name: registry.redhat.io/ubi9/ubi:latest
    name: latest
    referencePolicy:
      type: Source

2.10.2. 서브스크립션 자격을 빌드 보안으로 추가

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

사전 요구 사항

서브스크립션을 통해 Red Hat 인타이틀먼트에 액세스할 수 있어야 합니다. 자격 시크릿은 Insights Operator에 의해 자동으로 생성됩니다.

작은 정보

RHEL(Red Hat Enterprise Linux) 7을 사용하여 인타이틀먼트 빌드를 수행하는 경우 yum 명령을 실행하기 전에 Dockerfile에 다음 지침이 있어야 합니다. 

RUN rm /etc/rhsm-host

절차

  1. 빌드 구성의 Docker 전략에 etc-pki-entitlement 보안을 빌드 볼륨으로 추가합니다. 

    strategy:
  dockerStrategy:
    from:
      kind: ImageStreamTag
      name: ubi:latest
    volumes:
    - name: etc-pki-entitlement
      mounts:
      - destinationPath: /etc/pki/entitlement
      source:
        type: Secret
        secret:
          secretName: etc-pki-entitlement

2.10.3. 서브스크립션 관리자를 사용한 빌드 실행

2.10.3.1. 서브스크립션 관리자를 사용하는 Docker 빌드

Docker 전략 빌드에서는 Subscription Manager를 사용하여 서브스크립션 콘텐츠를 설치할 수 있습니다.

사전 요구 사항

자격 키는 빌드 전략 볼륨으로 추가해야 합니다.

절차

다음을 예제 Dockerfile로 사용하여 서브스크립션 관리자를 통해 콘텐츠를 설치합니다. 

FROM registry.redhat.io/ubi9/ubi:latest
RUN dnf search kernel-devel --showduplicates && \
        dnf install -y kernel-devel

2.10.4. Red Hat Satellite 서브스크립션을 사용하여 빌드 실행

2.10.4.1. 빌드에 Red Hat Satellite 구성 추가

Red Hat Satellite를 사용하여 콘텐츠를 설치하는 빌드에서는 Satellite 리포지토리에서 콘텐츠를 가져오기 위해 적절한 구성을 제공해야 합니다.

사전 요구 사항

  • Satellite 인스턴스에서 콘텐츠를 다운로드하는 yum 호환 리포지토리 구성 파일을 제공하거나 생성해야 합니다.

    샘플 리포지토리 구성

    [test-<name>]
name=test-<number>
baseurl = https://satellite.../content/dist/rhel/server/7/7Server/x86_64/os
enabled=1
gpgcheck=0
sslverify=0
sslclientkey = /etc/pki/entitlement/...-key.pem
sslclientcert = /etc/pki/entitlement/....pem

절차

  1. Satellite 리포지토리 구성 파일이 포함된 ConfigMap을 생성합니다. 

    $ oc create configmap yum-repos-d --from-file /path/to/satellite.repo

  2. Satellite 리포지토리 구성 및 인타이틀먼트 키를 빌드 볼륨으로 추가합니다. 

    strategy:
  dockerStrategy:
    from:
      kind: ImageStreamTag
      name: ubi:latest
    volumes:
    - name: yum-repos-d
      mounts:
      - destinationPath: /etc/yum.repos.d
      source:
        type: ConfigMap
        configMap:
          name: yum-repos-d
    - name: etc-pki-entitlement
      mounts:
      - destinationPath: /etc/pki/entitlement
      source:
        type: Secret
        secret:
          secretName: etc-pki-entitlement

2.10.4.2. Red Hat Satellite 서브스크립션을 사용하는 Docker 빌드

Docker 전략 빌드에서는 Red Hat Satellite 리포지토리를 사용하여 서브스크립션 콘텐츠를 설치할 수 있습니다.

사전 요구 사항

  • 인타이틀먼트 키와 Satellite 리포지토리 구성을 빌드 볼륨으로 추가했습니다.

절차

다음을 예제 Dockerfile로 사용하여 Satellite를 통해 콘텐츠를 설치합니다. 

FROM registry.redhat.io/ubi9/ubi:latest
RUN dnf search kernel-devel --showduplicates && \
        dnf install -y kernel-devel

추가 리소스

2.10.5. SharedSecret 오브젝트를 사용하여 권한이 부여된 빌드 실행

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

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

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

중요

공유 리소스 CSI 드라이버 및 빌드 CSI 볼륨은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있는 기술 프리뷰 기능입니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

공유 리소스 CSI 드라이버 및 빌드 CSI 볼륨 기능은 현재 기술 프리뷰 기능의 하위 집합인 TechPreviewNoUpgrade 기능 세트에도 속합니다. 테스트 클러스터에서 TechPreviewNoUpgrade 기능 세트를 활성화할 수 있습니다. 이 기능은 프로덕션 클러스터에서 비활성화된 상태로 유지하면서 완전히 테스트할 수 있습니다. 이 기능 세트를 활성화하면 실행 취소할 수 없으며 마이너 버전 업데이트를 방지할 수 없습니다. 이 기능 세트는 프로덕션 클러스터에서는 권장되지 않습니다. 다음 "ECDHE 리소스" 섹션의 기능 게이트를 사용하여 기술 프리뷰 기능 활성화를 참조하십시오.

사전 요구 사항

  • 기능 게이트를 사용하여 설정된 TechPreviewNoUpgrade 기능을 활성화했습니다.
  • Insights Operator가 서브스크립션 인증 정보를 저장하는 Secret 오브젝트를 참조하는 SharedSecret CR(사용자 정의 리소스) 인스턴스가 있습니다.

  • 다음 작업을 수행할 수 있는 권한이 있어야 합니다.

    • 빌드 구성을 생성하고 빌드를 시작합니다.
    • oc get sharedsecrets 명령을 입력하고 비어 있지 않은 목록을 다시 가져와서 사용할 수 있는 SharedSecret CR 인스턴스를 검색합니다.
    • 네임스페이스에서 사용 가능한 builder 서비스 계정이 지정된 SharedSecret CR 인스턴스를 사용할 수 있는지 확인합니다. 즉, 특정 SharedSecret>의 <identifier>를 사용할 수 있는 oc adm 정책을 실행하여 네임스페이스의 builder 서비스 계정이 나열되어 있는지 확인할 수 있습니다.
참고

이 목록에 있는 마지막 두 개의 사전 요구 사항이 모두 충족되거나, 설정 또는 설정하도록 요청하면 SharedSecret CR 인스턴스를 검색하고 서비스 계정에서 SharedSecret CR 인스턴스를 사용할 수 있도록 필요한 RBAC(역할 기반 액세스 제어)입니다.

절차

  1. oc apply 를 YAML 콘텐츠와 함께 사용하여 SharedSecret CR 인스턴스를 사용하도록 builder 서비스 계정 RBAC 권한을 부여합니다.

    참고

    현재 kubectl 및 oc 는 Pod 보안에 중점을 둔 역할로 use 동사를 제한하는 하드 코드 특수 케이스 논리가 있습니다. 따라서 oc create role …​ 을 사용하여 SharedSecret CR 인스턴스 사용에 필요한 역할을 생성할 수 없습니다.

    YAML 역할 오브젝트 정의를 사용하는 oc apply -f 명령의 예

    $ oc apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: shared-resource-my-share
  namespace: my-namespace
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedsecrets
    resourceNames:
      - my-share
    verbs:
      - use
EOF

  2. oc 명령을 사용하여 역할과 관련된 RoleBinding 을 생성합니다.

    oc create rolebinding 명령 예

    $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

  3. RHEL 인타이틀먼트에 액세스하는 BuildConfig 오브젝트를 생성합니다.

    YAML BuildConfig 오브젝트 정의 예

    apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: my-csi-bc
  namespace: my-csi-app-namespace
spec:
  runPolicy: Serial
  source:
    dockerfile: |
      FROM registry.redhat.io/ubi9/ubi:latest
      RUN ls -la /etc/pki/entitlement
      RUN rm /etc/rhsm-host
      RUN yum repolist --disablerepo=*
      RUN subscription-manager repos --enable rhocp-4.9-for-rhel-8-x86_64-rpms
      RUN yum -y update
      RUN yum install -y openshift-clients.x86_64
  strategy:
    type: Docker
    dockerStrategy:
      volumes:
        - mounts:
            - destinationPath: "/etc/pki/entitlement"
          name: my-csi-shared-secret
          source:
            csi:
              driver: csi.sharedresource.openshift.io
              readOnly: true
              volumeAttributes:
                sharedSecret: my-share-bc
            type: CSI

  4. BuildConfig 오브젝트에서 빌드를 시작하고 oc 명령을 사용하여 로그를 따릅니다.

    oc start-build 명령 예

    $ oc start-build my-csi-bc -F

    예 2.1. oc start-build 명령의 출력 예

    참고

    다음 출력의 일부 섹션은 …​로 교체되었습니다. 

    build.build.openshift.io/my-csi-bc-1 started
Caching blobs under "/var/cache/blobs".

Pulling image registry.redhat.io/ubi9/ubi:latest ...
Trying to pull registry.redhat.io/ubi9/ubi:latest...
Getting image source signatures
Copying blob sha256:5dcbdc60ea6b60326f98e2b49d6ebcb7771df4b70c6297ddf2d7dede6692df6e
Copying blob sha256:8671113e1c57d3106acaef2383f9bbfe1c45a26eacb03ec82786a494e15956c3
Copying config sha256:b81e86a2cb9a001916dc4697d7ed4777a60f757f0b8dcc2c4d8df42f2f7edb3a
Writing manifest to image destination
Storing signatures
Adding transient rw bind mount for /run/secrets/rhsm
STEP 1/9: FROM registry.redhat.io/ubi9/ubi:latest
STEP 2/9: RUN ls -la /etc/pki/entitlement
total 360
drwxrwxrwt. 2 root root 	80 Feb  3 20:28 .
drwxr-xr-x. 10 root root	154 Jan 27 15:53 ..
-rw-r--r--. 1 root root   3243 Feb  3 20:28 entitlement-key.pem
-rw-r--r--. 1 root root 362540 Feb  3 20:28 entitlement.pem
time="2022-02-03T20:28:32Z" level=warning msg="Adding metacopy option, configured globally"
--> 1ef7c6d8c1a
STEP 3/9: RUN rm /etc/rhsm-host
time="2022-02-03T20:28:33Z" level=warning msg="Adding metacopy option, configured globally"
--> b1c61f88b39
STEP 4/9: RUN yum repolist --disablerepo=*
Updating Subscription Management repositories.


...

--> b067f1d63eb
STEP 5/9: RUN subscription-manager repos --enable rhocp-4.9-for-rhel-8-x86_64-rpms
Repository 'rhocp-4.9-for-rhel-8-x86_64-rpms' is enabled for this system.
time="2022-02-03T20:28:40Z" level=warning msg="Adding metacopy option, configured globally"
--> 03927607ebd
STEP 6/9: RUN yum -y update
Updating Subscription Management repositories.

...

Upgraded:
  systemd-239-51.el8_5.3.x86_64      	systemd-libs-239-51.el8_5.3.x86_64
  systemd-pam-239-51.el8_5.3.x86_64
Installed:
  diffutils-3.6-6.el8.x86_64           	libxkbcommon-0.9.1-1.el8.x86_64
  xkeyboard-config-2.28-1.el8.noarch

Complete!
time="2022-02-03T20:29:05Z" level=warning msg="Adding metacopy option, configured globally"
--> db57e92ff63
STEP 7/9: RUN yum install -y openshift-clients.x86_64
Updating Subscription Management repositories.

...

Installed:
  bash-completion-1:2.7-5.el8.noarch
  libpkgconf-1.4.2-1.el8.x86_64
  openshift-clients-4.9.0-202201211735.p0.g3f16530.assembly.stream.el8.x86_64
  pkgconf-1.4.2-1.el8.x86_64
  pkgconf-m4-1.4.2-1.el8.noarch
  pkgconf-pkg-config-1.4.2-1.el8.x86_64

Complete!
time="2022-02-03T20:29:19Z" level=warning msg="Adding metacopy option, configured globally"
--> 609507b059e
STEP 8/9: ENV "OPENSHIFT_BUILD_NAME"="my-csi-bc-1" "OPENSHIFT_BUILD_NAMESPACE"="my-csi-app-namespace"
--> cab2da3efc4
STEP 9/9: LABEL "io.openshift.build.name"="my-csi-bc-1" "io.openshift.build.namespace"="my-csi-app-namespace"
COMMIT temp.builder.openshift.io/my-csi-app-namespace/my-csi-bc-1:edfe12ca
--> 821b582320b
Successfully tagged temp.builder.openshift.io/my-csi-app-namespace/my-csi-bc-1:edfe12ca
821b582320b41f1d7bab4001395133f86fa9cc99cc0b2b64c5a53f2b6750db91
Build complete, no image push requested

2.10.6. 추가 리소스

2.11. 전략에 따른 빌드 보안

OpenShift Container Platform의 빌드는 권한이 있는 컨테이너에서 실행됩니다. 권한이 있는 경우 사용한 빌드 전략에 따라 빌드를 실행하여 클러스터 및 호스트 노드에 대한 권한을 에스컬레이션할 수 있습니다. 그리고 일종의 보안 조치로 빌드 및 해당 빌드에 사용하는 전략을 실행할 수 있는 사람을 제한합니다. 사용자 정의 빌드는 권한 있는 컨테이너 내의 모든 코드를 실행할 수 있기 때문에 본질적으로 소스 빌드보다 안전하지 않으며, 기본적으로 비활성화되어 있습니다. Dockerfile 처리 논리의 취약성으로 인해 호스트 노드에 권한이 부여될 수 있으므로 Docker 빌드 권한을 주의하여 부여하십시오.

기본적으로 빌드를 생성할 수 있는 모든 사용자에게 Docker 및 S2I(Source-to-image) 빌드 전략을 사용할 수 있는 권한이 부여됩니다. 클러스터 관리자 권한이 있는 사용자는 ‘전역적으로 빌드 전략을 사용자로 제한’ 섹션에 언급된 대로 사용자 정의 빌드 전략을 활성화할 수 있습니다.

권한 부여 정책을 사용하여 빌드할 수 있는 사용자와 이들이 사용할 수 있는 빌드 전략을 제어할 수 있습니다. 각 빌드 전략에는 해당 빌드의 하위 소스가 있습니다. 사용자는 빌드를 생성할 수 있는 권한과 해당 전략을 사용하여 빌드를 생성하기 위해 빌드 전략 하위 리소스에서 생성할 수 있는 권한이 있어야 합니다. 빌드 전략 하위 리소스에 생성 권한을 부여하는 기본 역할이 제공됩니다.

표 2.3. 빌드 전략 하위 리소스 및 역할

전략하위 리소스역할

Docker

빌드/Docker

system:build-strategy-docker

S2I(Source-to-Image)

빌드/소스

system:build-strategy-source

사용자 정의

빌드/사용자 정의

system:build-strategy-custom

JenkinsPipeline

builds/jenkinspipeline

system:build-strategy-jenkinspipeline

2.11.1. 전역적으로 빌드 전략에 대한 액세스 비활성화

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

프로세스

  1. rbac.authorization.kubernetes.io/autoupdate 주석을 적용합니다. 

    $ oc edit clusterrolebinding system:build-strategy-docker-binding

    출력 예

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "false" 1
  creationTimestamp: 2018-08-10T01:24:14Z
  name: system:build-strategy-docker-binding
  resourceVersion: "225"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding
  uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:build-strategy-docker
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

    1
    rbac.authorization.kubernetes.io/autoupdate 주석 값을 "false"로 변경합니다.

  2. 역할을 제거합니다. 

    $ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated

  3. 빌드 전략 하위 소스도 이러한 역할에서 제거되었는지 확인합니다. 

    $ oc edit clusterrole admin
    $ oc edit clusterrole edit

  4. 각 역할에 대해 비활성화할 전략 리소스에 해당하는 하위 리소스를 지정합니다.

    1. admin에 대한 Docker 빌드 전략을 비활성화합니다. 

      kind: ClusterRole
metadata:
  name: admin
...
- apiGroups:
  - ""
  - build.openshift.io
  resources:
  - buildconfigs
  - buildconfigs/webhooks
  - builds/custom 1
  - builds/source
  verbs:
  - create
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
...
      1
      admin 역할의 사용자에 대해 Docker 빌드를 전역적으로 비활성화하려면 빌드/사용자 정의 및 빌드/소스 를 추가합니다.

2.11.2. 전역적으로 빌드 전략을 사용자로 제한

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

사전 요구 사항

  • 빌드 전략에 대한 글로벌 액세스 권한을 비활성화합니다.

프로세스

  • 빌드 전략에 해당하는 역할을 특정 사용자에게 할당합니다. 예를 들어 system:build-strategy-docker 클러스터 역할을 사용자 devuser에 추가하려면 다음을 수행합니다. 

    $ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
    주의

    클러스터 수준의 사용자 액세스 권한을 builds/docker 하위 리소스에 부여하면 사용자가 빌드를 생성할 수 있는 모든 프로젝트에서 Docker 전략을 사용하여 빌드를 생성할 수 있습니다.

2.11.3. 프로젝트 내 사용자로 빌드 전략 제한

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

사전 요구 사항

  • 빌드 전략에 대한 글로벌 액세스 권한을 비활성화합니다.

프로세스

  • 빌드 전략에 해당하는 역할을 특정 프로젝트 내 사용자에게 할당합니다. 예를 들어 프로젝트 devproject 내에서 system:build-strategy-docker 역할을 사용자 devuser에 추가하려면 다음을 실행합니다. 

    $ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject

2.12. 빌드 구성 리소스

빌드 설정을 구성하려면 다음 절차를 사용합니다.

2.12.1. 빌드 컨트롤러 구성 매개변수

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

매개변수설명

Build

빌드 처리 방법에 대한 클러스터 전체 정보가 들어 있습니다. 유일하게 유효한 정식 이름은 cluster입니다.

spec: 빌드 컨트롤러 구성에 사용자가 설정할 수 있는 값이 포함되어 있습니다.

buildDefaults

빌드의 기본 정보를 제어합니다.

defaultProxy: 이미지 가져오기 또는 내보내기 및 소스 다운로드를 포함하여 모든 빌드 작업에 대한 기본 프록시 설정이 포함됩니다.

BuildConfig 전략에 HTTP_PROXY, HTTPS_PROXY, NO_PROXY 환경 변수를 설정하여 값을 덮어쓸 수 있습니다.

gitProxy: Git 작업에 대한 프록시 설정만 포함됩니다. 설정하는 경우 git clone과 같은 모든 Git 명령의 모든 프록시 설정을 덮어씁니다.

여기에 설정되지 않은 값은 DefaultProxy에서 상속됩니다.

env: 지정된 변수가 빌드에 존재하지 않는 경우 빌드에 적용되는 기본 환경 변수 집합입니다.

imageLabels: 결과 이미지에 적용되는 라벨 목록입니다. BuildConfig에 동일한 이름의 라벨을 제공하여 기본 라벨을 덮어쓸 수 있습니다.

resources: 빌드를 실행하는 데 필요한 리소스 요구 사항을 정의합니다.

ImageLabel

name: 라벨 이름을 정의합니다. 길이가 0이 아니어야 합니다.

buildOverrides

빌드에 대한 덮어쓰기 설정을 제어합니다.

imageLabels: 결과 이미지에 적용되는 라벨 목록입니다. 이 표에 있는 것과 같은 이름이 있는 BuildConfig에 라벨을 제공한 경우 해당 라벨을 덮어씁니다.

nodeSelector: 빌드 Pod가 노드에 맞으려면 이 선택기가 true여야 합니다.

tolerations: 빌드 Pod에 설정된 기존 허용 오차를 덮어쓰는 허용 오차 목록입니다.

BuildList

items: 표준 오브젝트의 메타데이터입니다.

2.12.2. 빌드 설정 구성

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

프로세스

  • build.config.openshift.io/cluster 리소스를 편집합니다. 

    $ oc edit build.config.openshift.io/cluster

    다음은 build.config.openshift.io/cluster 리소스의 예입니다. 

    apiVersion: config.openshift.io/v1
kind: Build1
metadata:
  annotations:
    release.openshift.io/create-only: "true"
  creationTimestamp: "2019-05-17T13:44:26Z"
  generation: 2
  name: cluster
  resourceVersion: "107233"
  selfLink: /apis/config.openshift.io/v1/builds/cluster
  uid: e2e9cc14-78a9-11e9-b92b-06d6c7da38dc
spec:
  buildDefaults:2
    defaultProxy:3
      httpProxy: http://proxy.com
      httpsProxy: https://proxy.com
      noProxy: internal.com
    env:4
    - name: envkey
      value: envvalue
    gitProxy:5
      httpProxy: http://gitproxy.com
      httpsProxy: https://gitproxy.com
      noProxy: internalgit.com
    imageLabels:6
    - name: labelkey
      value: labelvalue
    resources:7
      limits:
        cpu: 100m
        memory: 50Mi
      requests:
        cpu: 10m
        memory: 10Mi
  buildOverrides:8
    imageLabels:9
    - name: labelkey
      value: labelvalue
    nodeSelector:10
      selectorkey: selectorvalue
    tolerations:11
    - effect: NoSchedule
      key: node-role.kubernetes.io/builds
operator: Exists
    1
    Build: 빌드 처리 방법에 대한 클러스터 전체 정보가 들어 있습니다. 유일하게 유효한 정식 이름은 cluster입니다.
    2
    buildDefaults: 빌드의 기본 정보를 제어합니다.
    3
    defaultProxy: 이미지 가져오기 또는 내보내기 및 소스 다운로드를 포함하여 모든 빌드 작업에 대한 기본 프록시 설정이 포함됩니다.
    4
    env: 지정된 변수가 빌드에 존재하지 않는 경우 빌드에 적용되는 기본 환경 변수 집합입니다.
    5
    gitProxy: Git 작업에 대한 프록시 설정만 포함됩니다. 설정하는 경우 git clone과 같은 모든 Git 명령의 모든 프록시 설정을 덮어씁니다.
    6
    imageLabels: 결과 이미지에 적용되는 라벨 목록입니다. BuildConfig에 동일한 이름의 라벨을 제공하여 기본 라벨을 덮어쓸 수 있습니다.
    7
    resources: 빌드를 실행하는 데 필요한 리소스 요구 사항을 정의합니다.
    8
    buildOverrides: 빌드에 대한 덮어쓰기 설정을 제어합니다.
    9
    imageLabels: 결과 이미지에 적용되는 라벨 목록입니다. 이 표에 있는 것과 같은 이름이 있는 BuildConfig에 라벨을 제공한 경우 해당 라벨을 덮어씁니다.
    10
    nodeSelector: 빌드 Pod가 노드에 맞으려면 이 선택기가 true여야 합니다.
    11
    tolerations: 빌드 Pod에 설정된 기존 허용 오차를 덮어쓰는 허용 오차 목록입니다.

2.13. 빌드 문제 해결

다음을 사용하여 빌드 문제를 해결합니다.

2.13.1. 리소스에 대한 액세스 거부 문제 해결

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

문제
다음과 같은 메시지가 표시되고 빌드가 실패합니다. 
requested access to the resource is denied
해결
프로젝트에 설정된 이미지 할당량 중 하나를 초과했습니다. 현재 할당량을 확인하고 적용되는 제한과 사용 중인 스토리지를 확인합니다. 
$ oc describe quota

2.13.2. 서비스 인증서 생성 실패

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

문제
서비스 인증서 생성에 실패하는 경우(서비스의 service.beta.openshift.io/serving-cert-generation-error 주석에는 다음이 포함됩니다.

출력 예

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

해결
인증서를 생성한 서비스가 더 이상 존재하지 않거나 serviceUID가 다릅니다. 이전 보안을 제거하고 서비스에서 service.beta.openshift.io/serving-cert-generation-error 및 service.beta.openshift.io/serving-cert-generation-error -num 주석을 지워 인증서를 강제로 다시 생성해야 합니다. 
$ 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-
참고

주석을 제거하는 명령에는 제거할 주석 이름 뒤에 -가 있습니다.

2.14. 빌드에 대해 신뢰할 수 있는 추가 인증 기관 설정

이미지 레지스트리에서 이미지를 가져올 때 빌드에서 신뢰할 추가 CA(인증 기관)를 설정하려면 다음 섹션을 사용합니다.

이 절차를 수행하려면 클러스터 관리자가 ConfigMap을 생성하고 ConfigMap에 추가 CA를 키로 추가해야 합니다.

  • ConfigMap은 openshift-config 네임스페이스에 생성해야 합니다.

  • domain은 ConfigMap의 키이고 value는 PEM 형식으로 인코딩한 인증서입니다.

    • 각 CA는 도메인과 연결되어 있어야 합니다. 도메인 형식은 hostname[..port]입니다.
  • ConfigMap 이름은 image.config.openshift.io/cluster 클러스터 범위 구성 리소스의 spec.additionalTrustedCA 필드에 설정해야 합니다.

2.14.1. 클러스터에 인증 기관 추가

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

사전 요구 사항

  • 레지스트리의 공용 인증서(일반적으로 /etc/docker/certs.d/ 디렉터리에 있는 hostname/ca.crt 파일)에 액세스할 수 있어야 합니다.

절차

  1. 자체 서명 인증서를 사용하는 레지스트리의 경우 신뢰할 수 있는 인증서가 있는 openshift-config 네임스페이스에 ConfigMap을 생성합니다. 각 CA 파일에 대해 ConfigMap의 키가 hostname[..port] 형식의 레지스트리 호스트 이름인지 확인하십시오. 

    $ oc create configmap registry-cas -n openshift-config \
--from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \
--from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt

  2. 클러스터 이미지 구성을 업데이트합니다. 

    $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge

2.14.2. 추가 리소스

3장. 파이프라인

3.1. Red Hat OpenShift Pipelines 릴리스 정보

Red Hat OpenShift Pipelines는 다음을 제공하는 Tekton 프로젝트를 기반으로 하는 클라우드 네이티브 CI/CD 환경입니다.

  • 표준 CRD(Kubernetes 네이티브 Pipeline 정의)
  • CI 서버 관리 오버헤드가 없는 서버리스 Pipeline
  • S2I, Buildah, JIB 및 Kaniko와 같은 Kubernetes 도구를 사용하여 이미지를 빌드할 수 있는 확장성
  • 모든 Kubernetes 배포판에서 이식성
  • Pipeline과 상호 작용하기 위한 강력한 CLI
  • OpenShift Container Platform 웹 콘솔의 개발자 화면과 통합된 사용자 경험

Red Hat OpenShift Pipelines 개요는 OpenShift Pipelines 이해를 참조하십시오.

3.1.1. 호환성 및 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

아래 표에서 기능은 다음과 같은 상태로 표시되어 있습니다.

TP

기술 프리뷰

GA

정식 출시일 (GA)

표 3.1. 호환성 및 지원 매트릭스

Red Hat OpenShift Pipelines Version구성 요소 버전OpenShift 버전지원 상태

Operator

파이프라인

Trigger

CLI

카탈로그

체인

hub

Pipeline as Code

결과

  

1.11

0.47.x

0.24.x

0.31.x

해당 없음

0.16.x (GA)

1.13.x(TP)

0.19.x (GA)

0.6.x (TP)

4.12, 4.13, 4.14 (예정)

GA

1.10

0.44.x

0.23.x

0.30.x

해당 없음

0.15.x (TP)

1.12.x (TP)

0.17.x (GA)

해당 없음

4.10, 4.11, 4.12, 4.13

GA

1.9

0.41.x

0.22.x

0.28.x

해당 없음

0.13.x (TP)

1.11.x (TP)

0.15.x (GA)

해당 없음

4.10, 4.11, 4.12, 4.13

GA

1.8

0.37.x

0.20.x

0.24.x

해당 없음

0.9.0 (TP)

1.8.x (TP)

0.10.x(TP)

해당 없음

4.10, 4.11, 4.12

GA

1.7

0.33.x

0.19.x

0.23.x

0.33

0.8.0 (TP)

1.7.0 (TP)

0.5.x (TP)

해당 없음

4.9, 4.10, 4.11

GA

1.6

0.28.x

0.16.x

0.21.x

0.28

해당 없음

해당 없음

해당 없음

해당 없음

4.9

GA

1.5

0.24.x

0.14.x (TP)

0.19.x

0.24

해당 없음

해당 없음

해당 없음

해당 없음

4.8

GA

1.4

0.22.x

0.12.x (TP)

0.17.x

0.22

해당 없음

해당 없음

해당 없음

해당 없음

4.7

GA

질문이나 의견이 있으시면 제품팀에 이메일(pipelines-interest@redhat.com)로 보내주시기 바랍니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

3.1.3. Red Hat OpenShift Pipelines General Availability 1.11 릴리스 정보

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.11은 OpenShift Container Platform 4.12 이상 버전에서 사용할 수 있습니다.

3.1.3.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.11의 새로운 기능도 소개합니다.

참고

Red Hat OpenShift Pipelines Operator 1.11로 업그레이드하기 전에 클러스터에 최소 OpenShift Container Platform 4.12.19 또는 4.13.1 버전을 설치해야 합니다.

3.1.3.1.1. 파이프라인
  • 이번 업데이트를 통해 ARM 하드웨어에서 실행되는 OpenShift Container Platform 클러스터에서 Red Hat OpenShift Pipelines를 사용할 수 있습니다. 이미지를 사용할 수 있는 ClusterTask 리소스와 ARM 하드웨어에서 Tekton CLI 툴을 지원합니다.
  • 이번 업데이트에서는 TektonConfig CR에서 enable-api-fields 기능 플래그를 beta 값으로 설정할 때 결과, 오브젝트 매개변수, 배열 결과 및 인덱싱에 대한 지원이 추가되었습니다.
  • 이번 업데이트를 통해 전파된 매개변수는 이제 안정적인 기능의 일부입니다. 이 기능을 사용하면 포함된 사양의 매개변수를 보간하여 Tekton 리소스의 상세 정보 표시를 줄일 수 있습니다.
  • 이번 업데이트를 통해 전파된 작업 공간은 이제 안정적인 기능의 일부가 되었습니다. enable-api-fields 기능 플래그를 alpha 또는 beta 값으로 설정하여 전파된 작업 공간 기능을 활성화할 수 있습니다.
  • 이번 업데이트를 통해 Pod가 실행되지 않으면 TaskRun 오브젝트에서 사용자에게 init 컨테이너 실패 메시지를 가져와서 표시합니다.

  • 이번 업데이트를 통해 다음 지침에 따라 매트릭스를 구성하는 동안 매개변수, 결과 및 파이프라인 작업의 컨텍스트를 교체할 수 있습니다.

    • array 를 matrix.params 구성에서 문자열,array 또는 object 매개변수로 바꿉니다.
    • string을 matrix.include 구성의 문자열,array 또는 object 매개변수로 바꿉니다.
    • 파이프라인 작업의 컨텍스트를 matrix.include 구성의 다른 컨텍스트로 바꿉니다.
  • 이번 업데이트를 통해 TaskRun 리소스 검증 프로세스도 matrix.include 매개변수의 유효성을 검사합니다. 검증은 모든 매개변수에 값이 있고 지정된 유형과 일치하는지 확인하고 오브젝트 매개변수에는 필요한 모든 키가 있습니다.
  • 이번 업데이트에서는 default-configs 구성 맵에 새 default-resolver-type 필드가 추가되었습니다. 이 필드의 값을 설정하여 기본 확인자를 구성할 수 있습니다.
  • 이번 업데이트를 통해 pipelineRun.workspaces.subPath 구성에서 PipelineRun 컨텍스트 변수를 정의하고 사용할 수 있습니다.
  • 이번 업데이트를 통해 이제 ClusterResolver,BundleResolver,HubResolver 및 GitResolver 기능을 기본적으로 사용할 수 있습니다.
3.1.3.1.2. Trigger
  • 이번 업데이트를 통해 Tekton Triggers는 EventListener 사양에서 Affinity 및 TopologySpreadConstraints 값을 지원합니다. 이러한 값을 사용하여 EventListener 오브젝트에 대한 Kubernetes 및 사용자 정의 리소스를 구성할 수 있습니다.
  • 이번 업데이트에서는 Slack의 슬래시 명령을 사용하여 필드를 추출할 수 있는 Slack 인터셉터가 추가되었습니다. 추출된 필드는 HTTP 요청의 양식 data 섹션으로 전송됩니다.
3.1.3.1.3. Operator
  • 이번 업데이트를 통해 TektonConfig CR에서 prune-per-resource 부울 필드를 설정하여 각 PipelineRun 또는 TaskRun 리소스에 대한 정리를 구성할 수 있습니다. 해당 네임스페이스에 operator.tekton.dev/prune.prune-resource=true 주석을 추가하여 네임스페이스에서 각 PipelineRun 또는 TaskRun 리소스에 대한 정리를 구성할 수도 있습니다.
  • 이번 업데이트를 통해 OpenShift Container Platform 클러스터 전체 프록시에 변경 사항이 있는 경우 OLM(Operator Lifecycle Manager)은 Red Hat OpenShift Pipelines Operator를 다시 생성합니다.
  • 이번 업데이트를 통해 TektonConfig CR에서 config.pruner.disabled 필드의 값을 true 로 설정하여 pruner 기능을 비활성화할 수 있습니다.
3.1.3.1.4. Tekton 체인
  • 이번 업데이트를 통해 Tekton 체인은 이제 일반적으로 사용할 수 있습니다.
  • 이번 업데이트를 통해 Tekton 체인과 함께 skopeo 툴을 사용하여 cosign 서명 스키마에 사용되는 키를 생성할 수 있습니다.
  • Red Hat OpenShift Pipelines Operator 1.11로 업그레이드하면 이전 Tekton 체인 구성을 덮어쓰고 TektonConfig CR에서 다시 설정해야 합니다.
3.1.3.1.5. Tekton Hub
중요

Tekton Hub는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트에서는 리소스 API 응답에 새 resource/<catalog_name>/<kind>/<resource_name>/raw 끝점 및 새 resource URLPath 필드가 추가되었습니다. 이번 업데이트에서는 리소스의 최신 원시 YAML 파일을 가져오는 데 도움이 됩니다.
3.1.3.1.6. Tekton 결과
중요

Tekton 결과는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트에서는 Tekton Operator에 선택적 구성 요소로 Tekton Results가 추가되었습니다.
3.1.3.1.7. Pipeline as Code
  • 이번 업데이트를 통해 Pipelines as Code를 사용하면 params 필드를 사용하여 PipelineRun 리소스 내에서 사용자 정의 매개변수를 확장할 수 있습니다. Repository CR의 템플릿 내에 사용자 정의 매개변수 값을 지정할 수 있습니다. 지정된 값은 파이프라인 실행의 사용자 정의 매개변수를 대체합니다. 또한 사용자 지정 매개변수를 정의하고 지정된 조건이 CEL(Common Expression Language) 필터와 호환되는 경우에만 해당 확장을 사용할 수 있습니다.
  • 이번 업데이트를 통해 GitHub 인터페이스의 Checks 탭에서 Re-run all checks 버튼을 클릭하여 특정 파이프라인 또는 모든 파이프라인을 재실행할 수 있습니다.

  • 이번 업데이트에서는 코드 CLI로 Pipeline에 새로운 tkn pac info 명령이 추가되었습니다. 관리자는 tkn pac info 명령을 사용하여 코드 설치로 Pipeline에 대한 다음 세부 정보를 얻을 수 있습니다.

    • Pipeline as Code가 설치된 위치입니다.
    • 코드로 Pipeline의 버전 번호입니다.
    • 클러스터에 생성된 Repository CR의 개요 및 리포지토리와 연결된 URL입니다.

    • 설치된 GitHub 애플리케이션의 세부 정보입니다.

      이 명령을 사용하면 --github-api-url 인수를 사용하여 사용자 정의 GitHub API URL을 지정할 수도 있습니다.

  • 이번 업데이트에서는 기본적으로 모든 PipelineRun 리소스에 대한 오류 탐지를 활성화합니다. 코드로서 파이프라인은 PipelineRun 리소스 실행이 실패했는지 여부를 감지하고 오류의 마지막 몇 줄의 스니펫을 표시합니다. GitHub 애플리케이션의 경우 Code로서의 Pipeline은 컨테이너 로그에서 오류 메시지를 감지하고 가져오기 요청에 주석을 표시합니다.
  • 이번 업데이트를 통해 프라이빗 Git 리포지토리에 연결된 프라이빗 Tekton Hub 인스턴스에서 작업을 가져올 수 있습니다. 이 업데이트를 활성화하기 위해 코드로서 Pipeline은 GitHub 원시 URL을 사용하는 대신 개인 Tekton Hub 인스턴스의 내부 원시 URL을 사용합니다.
  • 이번 업데이트 이전에는 네임스페이스 세부 정보가 포함되지 않은 Code가 제공된 로그로 Pipeline을 제공했습니다. 이번 업데이트를 통해 Pipeline은 네임스페이스 정보를 파이프라인 로그에 추가하여 네임스페이스를 기반으로 필터링하고 디버그할 수 있습니다.
  • 이번 업데이트를 통해 PipelineRun 리소스 정의를 가져오는 신뢰할 수 있는 소스를 정의할 수 있습니다. 기본적으로 Code로서의 Pipeline은 이벤트가 트리거된 분기에서 PipelineRun 리소스 정의를 가져옵니다. 이제 GitHub에 구성된 리포지토리의 기본 분기에서 PipelineRun 리소스 정의를 가져오도록 pipelinerun_provenance 설정 값을 default_branch 로 구성할 수 있습니다.

  • 이번 업데이트를 통해 GitHub 토큰의 범위를 다음 수준에서 확장할 수 있습니다.

    • 리포지토리 수준: 이 수준을 사용하여 원래 리포지토리가 있는 동일한 네임스페이스에 있는 리포지토리로 범위를 확장합니다.
    • 글로벌 수준: 이 수준을 사용하여 다른 네임스페이스에 있는 리포지토리로 범위를 확장합니다.
  • 이번 업데이트를 통해 Code로 Pipeline은 소유자, 협력자 또는 공용 멤버가 아닌 사용자가 생성한 가져오기 요청에 대해 CI 파이프라인을 트리거하지만 소유자 파일에 나열되지 않지만 변경 사항을 리포지토리에 내보낼 수 있는 권한이 있습니다.
  • 이번 업데이트를 통해 사용자 정의 콘솔 설정을 사용하면 Repository CR의 사용자 정의 매개변수를 사용할 수 있습니다.
  • 이번 업데이트를 통해 코드로서의 Pipeline은 모든 PipelineRun 레이블을 PipelineRun 주석으로 변경합니다. PipelineRun 주석을 사용하여 PipelineRun 라벨을 사용하는 대신 Tekton 리소스를 표시할 수 있습니다.
  • 이번 업데이트를 통해 감시자 및 Webhook 리소스에 pac-config-logging 구성 맵을 사용할 수 있지만 Pipeline에는 코드 컨트롤러로 사용할 수 없습니다.

3.1.3.2. 변경 사항 중단

  • 이번 업데이트에서는 파이프라인 사양의 새로운 trusted-resources-verification-no-match-policy 플래그로 resource-verification-mode 기능 플래그를 대체합니다.
  • 이번 업데이트를 통해 Tekton 체인 CR을 편집할 수 없습니다. 대신 TektonConfig CR을 편집하여 Tekton 체인을 구성합니다.

3.1.3.3. 사용되지 않거나 삭제된 기능

  • 이번 업데이트에서는 Tekton CLI에서 PipelineResource 명령 및 참조에 대한 지원을 제거합니다.

    • 클러스터 작업에서 파이프라인 리소스 제거
    • 작업에서 파이프라인 리소스 제거
    • 파이프라인에서 파이프라인 리소스 제거
    • 리소스 명령 제거
    • clustertask describe 명령에서 입력 및 출력 리소스 제거
  • 이번 업데이트에서는 Tekton CLI에서 전체 임베디드 상태에 대한 지원을 제거합니다.
  • taskref.bundle 및 pipelineref.bundle 번들은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.
  • Red Hat OpenShift Pipelines 1.11에서는 PipelineResource CR에 대한 지원이 제거되어 Task CR을 대신 사용합니다.
  • Red Hat OpenShift Pipelines 1.11에서는 v1alpha1.Run 오브젝트에 대한 지원이 제거되었습니다. 이 릴리스로 업그레이드하기 전에 v1alpha1.Run 에서 v1beta1.CustomRun 으로 업그레이드해야 합니다.
  • Red Hat OpenShift Pipelines 1.11에서는 custom-task-version 기능 플래그가 제거되었습니다.
  • Red Hat OpenShift Pipelines 1.11에서 pipelinerun.status.taskRuns 및 pipelinerun.status.runs 필드가 embedded-status 기능 플래그와 함께 제거되었습니다. 대신 pipelinerun.status.childReferences 필드를 사용합니다.

3.1.3.4. 확인된 문제

  • prune-per-resource 부울 필드를 설정해도 pipeline 또는 task의 일부가 아닌 경우 PipelineRun 또는 TaskRun 리소스는 삭제되지 않습니다.
  • Tekton CLI에는 확인자를 사용하여 생성된 PipelineRun 리소스의 로그가 표시되지 않습니다.
  • order_by=created_time+desc&page_size=1 쿼리를 기반으로 파이프라인 결과를 필터링하면 출력에 nextPageToken 값이 없으면 0개의 레코드가 표시됩니다.
  • loglevel.pipelinesascode 필드의 값을 debug 로 설정하면 파이프라인에서 코드 컨트롤러 Pod로 디버깅 로그가 생성되지 않습니다. 이 문제를 해결하려면 Pipeline을 Code 컨트롤러 Pod로 다시 시작합니다.

3.1.3.5. 해결된 문제

  • 이번 업데이트 이전에는 PipelineRun CR에서 generateName 필드를 탐지하는 동안 Code로서의 Pipeline이 PipelineRun 리소스를 생성하지 못했습니다. 이번 업데이트를 통해 Code로 Pipeline은 PipelineRun CR에서 generateName 필드를 제공할 수 있습니다.
  • 이번 업데이트 이전에는 웹 콘솔에서 PipelineRun 리소스를 생성할 때 파이프라인에서 모든 주석이 복사되어 실행 중인 노드에 문제가 발생했습니다. 이번 업데이트에서는 이 문제가 해결되었습니다.
  • 이번 업데이트에서는 keep 플래그의 tkn pr delete 명령이 수정되었습니다. 이제 keep 플래그 값이 연결된 작업 실행 또는 파이프라인 실행 수와 동일한 경우 명령은 메시지와 함께 종료 코드 0 을 반환합니다.

  • 이번 업데이트 이전에는 Tekton Operator에서 사용자 정의에 대한 성능 구성 필드를 노출하지 않았습니다. 이번 업데이트를 통해 클러스터 관리자는 요구 사항에 따라 TektonConfig CR에서 다음 성능 구성 필드를 사용자 지정할 수 있습니다.

    • disable-ha
    • 버킷
    • kube-api-qps
    • kube-api-burst
    • threads-per-controller
  • 이번 업데이트에서는 번들의 dev.tekton.image.kind 주석 값으로 kind 필드의 대소문자를 구분하지 않는 비교를 수행하도록 원격 번들 확인자를 수정합니다.
  • 이번 업데이트 이전에는 대규모 Git 리포지토리를 복제할 때 메모리 부족으로 인해 원격 확인자를 위한 Pod가 종료되었습니다. 이번 업데이트에서는 이 문제가 해결되어 원격 해결 프로그램을 배포하기 위한 메모리 제한이 증가합니다.
  • 이번 업데이트를 통해 v1 유형의 작업 및 파이프라인 리소스가 원격 확인에서 지원됩니다.
  • 이번 업데이트에서는 API에서 포함된 TaskRun 상태를 되돌립니다. 이제 포함된 TaskRun 상태는 이전 버전의 client-server와의 호환성을 지원하는 더 이상 사용되지 않는 기능으로 사용할 수 있습니다.
  • 이번 업데이트 이전에는 실행에 필요하지 않은 경우에도 모든 주석이 PipelineRun 및 TaskRun 리소스에 병합되었습니다. 이번 업데이트를 통해 PipelineRun 및 TaskRun 리소스에 주석을 병합하면 last-applied-configuration 주석을 건너뜁니다.
  • 이번 업데이트에서는 회귀 문제가 해결되어 건너뛴 작업의 유효성 검사로 인해 파이프라인 결과가 발생합니다. 예를 들어, 파이프라인 결과가 건너뛴 PipelineTask 리소스를 참조하는 경우 파이프라인 결과가 배출되지 않고 결과가 누락되어 PipelineRun 실행이 실패하지 않습니다.
  • 이번 업데이트에서는 Pod 상태 메시지를 사용하여 Pod 종료 원인을 확인합니다.
  • 이번 업데이트 이전에는 finally 작업의 실행을 위해 기본 확인자가 설정되지 않았습니다. 이번 업데이트에서는 finally 작업에 대한 기본 확인자를 설정합니다.
  • 이번 업데이트를 통해 Red Hat OpenShift Pipelines는 원격 분석을 사용할 때 TaskRun 또는 PipelineRun 실행 실패를 방지할 수 있습니다.
  • 이번 업데이트 이전에는 시간 초과 후에도 긴 파이프라인 실행이 클러스터의 실행 중 상태로 유지되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다.
  • 이번 업데이트에서는 keep 플래그를 올바르게 사용하여 tkn pr delete 명령이 수정되었습니다. 이번 업데이트를 통해 keep 플래그의 값이 연결된 작업 실행 또는 파이프라인 실행 수와 동일한 경우 tkn pr delete 명령은 메시지와 함께 종료 코드 0 을 반환합니다.

3.1.3.6. Red Hat OpenShift Pipelines General Availability 1.11.1 릴리스 정보

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.11.1은 OpenShift Container Platform 4.12 이상 버전에서 사용할 수 있습니다.

3.1.3.6.1. 해결된 문제
  • 이번 업데이트 이전에는 실행 중이거나 보류 중인 Pod를 선점할 때 마운트 경로 오류 메시지와 함께 작업 실행이 실패할 수 있었습니다. 이번 업데이트를 통해 클러스터에서 Pod를 삭제하고 다시 생성할 때 작업 실행이 실패하지 않습니다.
  • 이번 업데이트 이전에는 작업의 쉘 스크립트를 root로 실행해야 했습니다. 이번 업데이트를 통해 쉘 스크립트 이미지에 루트가 아닌 사용자 ID가 설정되어 있으므로 Pod 내의 루트가 아닌 사용자로 git-clone 작업과 같은 작업을 실행할 수 있습니다.
  • 이번 업데이트 이전에는 Red Hat OpenShift Pipelines 1.11.0에서 파이프라인 실행이 코드로 정의되면 Git 리포지토리의 정의가 tekton.dev/v1beta1 API 버전을 참조하고 spec.pipelineRef.bundle 항목이 포함되어 있으며 번들 참조의 kind 매개변수가 Task 로 잘못 설정되었습니다. 이 문제는 이전 버전의 Red Hat OpenShift Pipelines에는 존재하지 않았습니다. 이번 업데이트를 통해 kind 매개변수가 올바르게 설정됩니다.
  • 이번 업데이트 이전에는 disable-ha 플래그가 tekton-pipelines 컨트롤러에 올바르게 전달되지 않아 Red Hat OpenShift Pipelines의 HA(고가용성) 기능을 활성화할 수 없었습니다. 이번 업데이트를 통해 disable-ha 플래그가 올바르게 전달되고 필요에 따라 HA 기능을 활성화할 수 있습니다.
  • 이번 업데이트 이전에는 hub resolver에 대한 Tekton Hub 및 Artifact Hub의 URL을 설정할 수 없으므로 Tekton Hub 및 Artifact Hub의 사전 설정 주소만 사용할 수 있었습니다. 이번 업데이트를 통해 hub resolver에 대한 Tekton Hub 및 Artifact Hub의 URL을 구성할 수 있습니다(예: 설치한 사용자 정의 Tekton Hub 인스턴스를 사용합니다.
  • 이번 업데이트를 통해 git-init 이미지의 SHA 다이제스트는 현재 릴리스된 이미지 버전인 1.10.5 버전에 해당합니다.
  • 이번 업데이트 이전에는 tekton-pipelines-controller 구성 요소에서 config- leader-election 이라는 구성 맵을 사용했습니다. 이 이름은 knative 컨트롤러의 기본값이므로 OpenShift Pipelines의 구성 프로세스는 다른 컨트롤러에 영향을 미칠 수 있으며 그 반대의 경우도 마찬가지입니다. 이번 업데이트를 통해 구성 요소는 고유한 구성 이름을 사용하므로 OpenShift Pipelines의 구성 프로세스는 다른 컨트롤러에 영향을 미치지 않으며 다른 컨트롤러의 영향을 받지 않습니다.
  • 이번 업데이트 이전에는 GitHub 리포지토리에 대한 쓰기 권한이 없는 사용자가 가져오기 요청을 열 때 코드 CI/CD 작업으로 Pipeline이 GitHub에 건너뛰 는 대로 표시되었습니다. 이번 업데이트를 통해 코드 CI/CD 작업인 Pipeline이 GitHub에 Pending 승인 으로 표시됩니다.
  • 이번 업데이트 이전에는 Code로서의 Pipeline이 구성된 분기 이름과 일치하는 분기에 모든 가져오기 요청에 대한 CI/CD 작업을 실행했습니다. 이번 업데이트를 통해 Code로 Pipeline은 가져오기 요청의 소스 분기가 정확히 구성된 분기 이름과 일치하는 경우에만 CI/CD 작업을 실행합니다.
  • 이번 업데이트 이전에는 OpenShift Container Platform 개발자 콘솔에 코드 컨트롤러로서의 Pipeline에 대한 메트릭이 표시되지 않았습니다. 이번 업데이트를 통해 개발자 콘솔에 코드 컨트롤러로서의 Pipeline에 대한 지표가 표시됩니다.
  • 이번 업데이트 이전에는 Red Hat OpenShift Pipelines 1.11.0에서 Operator가 항상 Tekton 체인을 설치했으며 Tekton Chains 구성 요소의 설치를 비활성화할 수 없었습니다. 이번 업데이트를 통해 TektonConfig CR에서 disabled 매개변수 값을 true 로 설정하여 설치 okindf Tekton Chains를 비활성화할 수 있습니다.
  • 이번 업데이트 이전에는 Tekton Cryostat CR을 사용하여 이전 버전의 OpenShift Pipelines에서 Tekton 체인을 구성한 후 OpenShift Pipelines 버전 1.11.0으로 업그레이드된 경우 구성 정보를 덮어씁니다. 이번 업데이트를 통해 이전 버전의 OpenShift Pipelines 및 Tekton 체인에서 업그레이드하는 경우 TektonConfig 가 설치된 동일한 네임스페이스에 구성된 경우 Tekton 체인 구성 정보가 유지됩니다.

3.1.4. Red Hat OpenShift Pipelines General Availability 1.10 릴리스 정보

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.10은 OpenShift Container Platform 4.11, 4.12 및 4.13에서 사용할 수 있습니다.

3.1.4.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.10의 새로운 기능도 소개합니다.

3.1.4.1.1. 파이프라인
  • 이번 업데이트를 통해 PipelineRun 또는 TaskRun Pod 템플릿에서 환경 변수를 지정하여 작업 또는 단계에 구성된 변수를 덮어쓰거나 추가할 수 있습니다. 또한 기본 Pod 템플릿에서 환경 변수를 지정하여 모든 PipelineRuns 및 TaskRuns 에 전역적으로 해당 변수를 사용할 수 있습니다. 이번 업데이트에서는 포드 템플릿에서 전파하면서 환경 변수를 필터링하기 위해 forbidden-envs 라는 새 기본 구성도 추가되었습니다.

  • 이번 업데이트를 통해 파이프라인의 사용자 지정 작업이 기본적으로 활성화됩니다.

    참고

    이 업데이트를 비활성화하려면 feature-flags 구성 사용자 정의 리소스에서 enable-custom-tasks 플래그를 false 로 설정합니다.

  • 이번 업데이트에서는 사용자 지정 작업에 v1beta1.CustomRun API 버전을 지원합니다.

  • 이번 업데이트에서는 PipelineRun 조정기 지원을 추가하여 사용자 정의 실행을 생성합니다. 예를 들어 PipelineRuns 에서 생성된 사용자 정의 TaskRuns 는 이제 기본 값 v1alpha1 이 아닌 v1beta1.CustomRun API 버전을 v1alpha1.Run 대신 v1beta -version 기능 플래그가 v1beta1 로 설정된 경우 사용할 수 있습니다.

    참고

    v1beta1.CustomRun 요청에 응답하기 위해 *v1alpha1.Run 대신 *v1beta1.CustomRun API 버전을 수신 대기하도록 사용자 정의 작업 컨트롤러를 업데이트해야 합니다.

  • 이번 업데이트에서는 v1beta1.TaskRun 및 v1.TaskRun 사양에 새 재시도 필드가 추가되었습니다.
3.1.4.1.2. Trigger
  • 이번 업데이트를 통해 트리거는 v1beta1 API 버전의 CustomRun 오브젝트와 함께 v1 API 버전의 Pipeline,Task,PipelineRuns 및 TaskRuns 오브젝트 생성을 지원합니다.

  • 이번 업데이트를 통해 GitHub Interceptor는 소유자가 호출하거나 소유자가 구성 가능한 주석으로 호출하지 않는 한 가져오기 요청 트리거가 실행되지 않도록 차단합니다.

    참고

    이 업데이트를 활성화하거나 비활성화하려면 GitHub Interceptor 구성 파일에서 githubOwners 매개변수 값을 true 또는 false 로 설정합니다.

  • 이번 업데이트를 통해 GitHub Interceptor는 push 및 pull request 이벤트에 대해 변경된 모든 파일의 쉼표로 구분된 목록을 추가할 수 있습니다. 변경된 파일 목록은 최상위 확장 필드의 이벤트 페이로드의 changed_files 속성에 추가됩니다.
  • 이번 업데이트에서는 TLS의 MinVersion 을 tls.VersionTLS12 로 변경하여 FIPS(Federal Information Processing Standards) 모드가 활성화될 때 OpenShift Container Platform에서 트리거가 실행됩니다.
3.1.4.1.3. CLI
  • 이번 업데이트에서는 Task,ClusterTask 또는 Pipeline 을 시작할 때 CSI(Container Storage Interface) 파일을 작업 공간으로 전달하는 지원이 추가되었습니다.
  • 이번 업데이트에서는 작업, 파이프라인, 파이프라인 실행 및 작업 실행 리소스와 관련된 모든 CLI 명령에 v1 API 지원이 추가되었습니다. Tekton CLI는 이러한 리소스에 대해 v1beta1 및 v1 API 모두에서 작동합니다.
  • 이번 업데이트에서는 start 및 describe 명령에서 오브젝트 유형 매개변수에 대한 지원이 추가되었습니다.
3.1.4.1.4. Operator
  • 이번 업데이트에서는 선택적 파이프라인 속성에 default-forbidden-env 매개변수를 추가합니다. 이 매개변수에는 Pod 템플릿을 통해 제공되는 경우 전파해서는 안 되는 금지된 환경 변수가 포함됩니다.
  • 이번 업데이트에서는 Tekton Hub UI에서 사용자 정의 로고에 대한 지원이 추가되었습니다. 사용자 지정 로고를 추가하려면 customLogo 매개변수 값을 Tekton Hub CR에서 base64로 인코딩된 로고 URI로 설정합니다.
  • 이번 업데이트에서는 git-clone 작업의 버전 번호가 0.9로 증가합니다.
3.1.4.1.5. Tekton 체인
중요

Tekton Chains는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트에서는 PipelineRun 및 TaskRun 관찰에 주석 및 라벨이 추가되었습니다.
  • 이번 업데이트에서는 in-to-to 형식으로 요청할 때 생성된 것과 동일한 검증 기능을 생성하는 slsa/v1 이라는 새 형식을 추가합니다.
  • 이번 업데이트를 통해 Sigstore 기능은 실험적 기능에서 벗어났습니다.
  • 이번 업데이트를 통해 predicate.materials 기능에는 TaskRun 오브젝트의 모든 단계 및 사이드카의 이미지 URI 및 다이제스트 정보가 포함됩니다.
3.1.4.1.6. Tekton Hub
중요

Tekton Hub는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트에서는 클러스터에서 v1 API 버전의 Tekton 리소스 설치, 업그레이드 또는 다운그레이드를 지원합니다.
  • 이번 업데이트에서는 UI에서 Tekton Hub 로고 대신 사용자 정의 로고 추가를 지원합니다.
  • 이번 업데이트에서는 Artifact Hub에서 리소스를 가져와서 클러스터에 설치하는 --type artifact 플래그를 추가하여 tkn hub install 명령 기능을 확장합니다.
  • 이번 업데이트에서는 지원 계층, 카탈로그 및 org 정보를 Artifact Hub에서 클러스터에 설치하는 리소스에 레이블로 추가합니다.
3.1.4.1.7. Pipeline as Code
  • 이번 업데이트에서는 수신 웹 후크 지원이 향상되었습니다. OpenShift Container Platform 클러스터에 설치된 GitHub 애플리케이션의 경우 들어오는 Webhook에 대한 git_provider 사양을 제공할 필요가 없습니다. 대신 Code로 Pipeline은 시크릿을 감지하고 들어오는 Webhook에 사용합니다.
  • 이번 업데이트를 통해 동일한 토큰을 사용하여 기본값이 아닌 분기가 있는 GitHub의 동일한 호스트에서 원격 작업을 가져올 수 있습니다.
  • 이번 업데이트를 통해 Code로 Pipeline은 Tekton v1 템플릿을 지원합니다. TRI(Code)가 OPEN 생성을 위해 읽는 v1 및 v1beta1 템플릿이 있을 수 있습니다. ScanSetting은 클러스터에서 v1 로 생성됩니다.
  • 이번 업데이트 이전에는 OpenShift 네임스페이스에 런타임 템플릿이 없는 경우 OpenShift 콘솔 UI에서 하드 코딩된 파이프라인 실행 템플릿을 폴백 템플릿으로 사용했습니다. pipelines-as-code 구성 맵에서 이 업데이트에서는 콘솔에서 사용할 pipelines-as-code-template-default 라는 새로운 기본 파이프라인 실행 템플릿을 제공합니다.
  • 이번 업데이트를 통해 Code로 Pipeline은 Tekton Pipelines 0.44.0 최소 상태를 지원합니다.
  • 이번 업데이트를 통해 Code로 Pipeline은 Tekton v1 API를 지원합니다. 즉 Code로서의 Pipelines는 Tekton v0.44 이상과 호환됩니다.
  • 이번 업데이트를 통해 k8s의 OpenShift 및 Tekton 대시보드 콘솔을 구성하는 것 외에도 사용자 정의 콘솔 대시보드를 구성할 수 있습니다.
  • 이번 업데이트를 통해 Code로 Pipeline이 tkn pac create repo 명령을 사용하여 시작된 GitHub 애플리케이션의 설치를 감지하고 이를 전역에 설치한 경우 GitHub Webhook가 필요하지 않습니다.
  • 이번 업데이트 이전에는 PipelineRun 실행에 오류가 있고 PipelineRun 에 연결된 작업에 오류가 있는 경우 Code에서 오류를 올바르게 보고하지 않았습니다. 이번 업데이트를 통해 파이프라인은 PipelineRun 을 생성할 수 없는 경우 GitHub 검사에서 오류를 올바르게 보고합니다.
  • 이번 업데이트를 통해 Code로 Pipeline에는 PipelineRun 이 실행되는 현재 실행 중인 네임스페이스로 확장되는 target_namespace 변수가 포함되어 있습니다.
  • 이번 업데이트를 통해 코드로 Pipeline을 사용하면 CLI 부트스트랩 GitHub 애플리케이션에서 GitHub 엔터프라이즈 질문을 바이패스할 수 있습니다.
  • 이번 업데이트를 통해 Code로 Pipeline은 리포지토리 CR을 찾을 수 없는 경우 오류를 보고하지 않습니다.
  • 이번 업데이트를 통해 동일한 이름으로 여러 파이프라인이 실행되는 경우 Code로 Pipeline에서 오류를 보고합니다.

3.1.4.2. 변경 사항 중단

  • 이번 업데이트에서는 이전 버전의 tkn 명령이 Red Hat OpenShift Pipelines 1.10과 호환되지 않습니다.
  • 이번 업데이트에서는 Tekton CLI에서 Cluster 및 CloudEvent 파이프라인 리소스를 지원하지 않습니다. tkn pipelineresource create 명령을 사용하여 파이프라인 리소스를 생성할 수 없습니다. 또한 작업, 클러스터 작업 또는 파이프라인의 start 명령에서 파이프라인 리소스가 더 이상 지원되지 않습니다.
  • 이번 업데이트에서는 Tekton Chains에서 tekton 을 검증 형식으로 제거합니다.

3.1.4.3. 사용되지 않거나 삭제된 기능

  • Red Hat OpenShift Pipelines 1.10에서는 ClusterTask 명령이 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 이 업데이트에서는 tkn task create 명령도 더 이상 사용되지 않습니다.
  • Red Hat OpenShift Pipelines 1.10에서는 v1 API에서 파이프라인 리소스를 지원하지 않기 때문에 tkn task start 명령과 함께 사용된 플래그 -i 및 -o 가 더 이상 사용되지 않습니다.
  • Red Hat OpenShift Pipelines 1.10에서는 v1 API가 파이프라인 리소스를 지원하지 않기 때문에 tkn pipeline start 명령과 함께 사용된 -r 플래그가 더 이상 사용되지 않습니다.
  • Red Hat OpenShift Pipelines 1.10 업데이트는 openshiftDefaultEmbeddedStatus 매개변수를 전체 및 최소 포함 상태로 설정합니다. 기본 포함 상태를 변경하는 플래그도 더 이상 사용되지 않으며 제거됩니다. 또한 파이프라인 기본 포함 상태는 향후 릴리스에서 최소로 변경됩니다.

3.1.4.4. 확인된 문제

  • 이번 업데이트에는 다음과 같은 이전 버전과 호환되지 않는 변경 사항이 포함됩니다.

    • PipelineResources 클러스터 제거
    • PipelineResources 클라우드 이벤트 제거

  • 클러스터 업그레이드 후 파이프라인 메트릭 기능이 작동하지 않는 경우 해결 방법으로 다음 명령을 실행합니다. 

    $ oc get tektoninstallersets.operator.tekton.dev | awk '/pipeline-main-static/ {print $1}' | xargs oc delete tektoninstallersets
  • 이번 업데이트를 통해 Crunchy PostgreSQL과 같은 외부 데이터베이스 사용은 IBM Power, IBM Z 및 IBM® LinuxONE에서 지원되지 않습니다. 대신 기본 Tekton Hub 데이터베이스를 사용합니다.

3.1.4.5. 해결된 문제

  • 이번 업데이트 이전에는 opc pac 명령에서 도움말을 표시하는 대신 런타임 오류를 생성했습니다. 이번 업데이트에서는 도움말 메시지를 표시하도록 opc pac 명령이 수정되었습니다.
  • 이번 업데이트 이전에는 tkn pac create repo 명령을 실행하려면 리포지토리를 생성하기 위한 Webhook 세부 정보가 필요했습니다. 이번 업데이트를 통해 GitHub 애플리케이션을 설치할 때 tkn-pac create repo 명령으로 Webhook를 설정하지 않습니다.
  • 이번 업데이트 이전에는 Tekton Pipelines에서 PipelineRun 리소스 생성에 문제가 있을 때 Code로 파이프라인 실행 생성 오류가 보고되지 않았습니다. 예를 들어 파이프라인 실행에 존재하지 않는 작업은 상태가 표시되지 않습니다. 이번 업데이트를 통해 Code로 파이프라인에 누락된 작업과 함께 Tekton Pipelines에서 발생하는 적절한 오류 메시지가 표시됩니다.
  • 이번 업데이트에서는 인증에 성공한 후 UI 페이지 리디렉션이 수정되었습니다. 이제 Tekton Hub에 로그인하려고 했던 동일한 페이지로 리디렉션됩니다.
  • 이번 업데이트에서는 클러스터 작업, 개별 작업 및 파이프라인의 경우 이러한 플래그 --all-namespaces 및 --output=yaml 플래그를 사용하여 list 명령을 수정합니다.
  • 이번 업데이트에서는 repo.spec.url URL 끝에 슬래시를 제거하여 GitHub의 URL과 일치시킵니다.
  • 이번 업데이트 이전에는 marshalJSON 함수가 오브젝트 목록을 마샬링하지 않았습니다. 이번 업데이트를 통해 marshalJSON 함수는 오브젝트 목록을 마샬링합니다.
  • 이번 업데이트를 통해 코드로 Pipeline을 사용하면 CLI 부트스트랩 GitHub 애플리케이션에서 GitHub 엔터프라이즈 질문을 바이패스할 수 있습니다.
  • 이번 업데이트에서는 리포지토리에 사용자가 100개 이상인 경우 GitHub 협력자 검사가 수정되었습니다.
  • 이번 업데이트를 통해 작업 또는 파이프라인에 대한 서명 및 확인 명령이 kubernetes 구성 파일 없이 작동합니다.
  • 이번 업데이트를 통해 네임스페이스에서 pruner를 건너뛰는 경우 Tekton Operator에서 남은 정리기 cron 작업을 정리합니다.
  • 이번 업데이트 이전에는 API ConfigMap 오브젝트가 카탈로그 새로 고침 간격에 대해 사용자가 구성한 값으로 업데이트되지 않았습니다. 이번 업데이트에서는 Tekon Hub CR에서 CATALOG_REFRESH_INTERVAL API가 수정되었습니다.

  • 이번 업데이트에서는 iPXEStatus 기능 플래그를 변경할 때 PipelineRunStatus 조정이 수정되었습니다. 이번 업데이트에서는 다음 매개 변수가 재설정됩니다.

    • status.runs 및 status.taskruns 매개변수는 최소 iPXEStatus를 사용하여 nil 에 대한 매개변수입니다.
    • status.childReferences 전체Status를 사용하여 nil 에 대한 매개변수
  • 이번 업데이트에서는 ResolutionRequest CRD에 변환 구성이 추가되었습니다. 이번 업데이트에서는 v1alpha1.ResolutionRequest 요청에서 v1beta1.ResolutionRequest 요청으로의 변환을 올바르게 구성합니다.
  • 이번 업데이트에서는 파이프라인 작업과 연결된 중복된 작업 공간을 확인합니다.
  • 이번 업데이트에서는 코드에서 해결자 활성화의 기본값이 수정되었습니다.
  • 이번 업데이트에서는 확인 프로그램을 사용하여 TaskRef 및 PipelineRef 이름 변환이 수정되었습니다.

3.1.4.6. Red Hat OpenShift Pipelines General Availability 1.10.1 릴리스 정보

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.10.1은 OpenShift Container Platform 4.11, 4.12 및 4.13에서 사용할 수 있습니다.

3.1.4.6.1. 코드로 Pipeline의 수정된 문제
  • 이번 업데이트 이전에는 페이로드에서 제공하는 소스 분기 정보에 refs/heads/ 가 포함되어 있지만 사용자가 구성된 대상 분기에 CEL 표현식의 기본 분기만 포함된 경우 푸시 요청이 실패합니다. 이번 업데이트를 통해 Code로 파이프라인이 내보내기 요청을 전달하고 페이로드에 기본 분기 또는 대상 분기 중 하나가 있는 경우 파이프라인을 트리거합니다.
  • 이번 업데이트 이전에는 PipelineRun 오브젝트를 생성할 수 없는 경우 Tekton 컨트롤러에서 수신한 오류가 사용자에게 보고되지 않았습니다. 이번 업데이트를 통해 Code로 파이프라인에서 오류 메시지를 GitHub 인터페이스에 보고하여 사용자가 오류 문제를 해결할 수 있습니다. Code로 파이프라인은 파이프라인 실행 중에 발생한 오류도 보고합니다.
  • 이번 업데이트를 통해 인프라 문제로 인해 OpenShift Container Platform 클러스터에 시크릿을 생성하지 못하는 경우 Code로 파이프라인이 GitHub 검사 인터페이스에 보안을 설정하지 않습니다.
  • 이번 업데이트에서는 Red Hat OpenShift Pipelines에서 더 이상 사용되지 않는 API를 제거합니다.

3.1.4.7. Red Hat OpenShift Pipelines General Availability 1.10.2 릴리스 정보

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.10.2는 OpenShift Container Platform 4.11, 4.12 및 4.13에서 사용할 수 있습니다.

3.1.4.7.1. 해결된 문제

이번 업데이트 이전에는 Tekton Operator의 문제로 인해 사용자가 enable-api-fields 플래그의 값을 beta 로 설정하지 못했습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 이제 TektonConfig CR에서 enable-api-fields 플래그 값을 beta 로 설정할 수 있습니다.

3.1.4.8. Red Hat OpenShift Pipelines General Availability 1.10.3 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.11, 4.12 및 4.13에서 Red Hat OpenShift Pipelines General Availability (GA) 1.10.3을 사용할 수 있습니다.

3.1.4.8.1. 해결된 문제

이번 업데이트 이전에는 Tekton Operator에서 사용자 정의에 대한 성능 구성 필드를 노출하지 않았습니다. 이번 업데이트를 통해 클러스터 관리자는 요구 사항에 따라 TektonConfig CR에서 다음 성능 구성 필드를 사용자 지정할 수 있습니다.

  • disable-ha
  • 버킷
  • kube-api-qps
  • kube-api-burst
  • threads-per-controller

3.1.4.9. Red Hat OpenShift Pipelines General Availability 1.10.4 릴리스 노트

이번 업데이트를 통해 OpenShift Container Platform 4.11, 4.12 및 4.13에서 Red Hat OpenShift Pipelines General Availability (GA) 1.10.4를 사용할 수 있습니다.

3.1.4.9.1. 해결된 문제
  • 이번 업데이트에서는 파이프라인 실행의 PipelineRef 필드에 대한 번들 확인자 변환 문제가 수정되었습니다. 이제 변환 기능은 변환 후 kind 필드의 값을 Pipeline 으로 설정합니다.
  • 이번 업데이트 이전에는 timeouts.tasks 및 timeouts.finally 값을 무시하고 pipelinerun.timeouts 필드가 timeouts.pipeline 값으로 재설정되었습니다. 이번 업데이트에서는 문제가 해결되어 PipelineRun 리소스에 대한 올바른 기본 시간 초과 값을 설정합니다.
  • 이번 업데이트 이전에는 컨트롤러 로그에 불필요한 데이터가 포함되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다.

3.1.4.10. Red Hat OpenShift Pipelines General Availability 1.10.5 릴리스 노트

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.10.5는 4.11, 4.12 및 4.13 외에도 OpenShift Container Platform 4.10에서 사용할 수 있습니다.

중요

Red Hat OpenShift Pipelines 1.10.5는 OpenShift Container Platform 4.10, 4.11, 4.12, 4.13의 pipelines-1.10 채널에서만 사용할 수 있습니다. OpenShift Container Platform 버전의 최신 채널에서는 사용할 수 없습니다.

3.1.4.10.1. 해결된 문제
  • 이번 업데이트 이전에는 oc 및 tkn 명령을 사용하여 대규모 파이프라인 실행이 나열되거나 삭제되지 않았습니다. 이번 업데이트에서는 이 문제를 유발한 대규모 주석을 압축하여 이 문제를 완화합니다. 압축 후에도 파이프라인 실행이 너무 크면 동일한 오류가 계속 반복된다는 점에 유의하십시오.
  • 이번 업데이트 이전에는 pipelineRun.spec.taskRunSpecs[].podTemplate 오브젝트에 지정된 Pod 템플릿만 파이프라인 실행에 고려되었습니다. 이번 업데이트를 통해 pipelineRun.spec.podTemplate 오브젝트에 지정된 Pod 템플릿도 pipelineRun.spec.taskRunSpecs[].podTemplate 오브젝트에 지정된 템플릿과 병합됩니다.

3.1.5. Red Hat OpenShift Pipelines General Availability 1.9 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.11, 4.12 및 4.13에서 Red Hat OpenShift Pipelines General Availability (GA) 1.9를 사용할 수 있습니다.

3.1.5.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.9의 새로운 기능도 소개합니다.

3.1.5.1.1. 파이프라인
  • 이번 업데이트를 통해 파이프라인 매개변수를 지정하고 배열 및 오브젝트 사전 양식을 생성할 수 있습니다.
  • 이번 업데이트에서는 작업 공간에 대한 CSI(Container Storage Interface) 및 예상 볼륨을 지원합니다.
  • 이번 업데이트를 통해 파이프라인 단계를 정의할 때 stdoutConfig 및 stderrConfig 매개변수를 지정할 수 있습니다. 이러한 매개변수를 정의하면 단계와 관련된 표준 출력 및 표준 오류를 로컬 파일에 캡처하는 데 도움이 됩니다.
  • 이번 업데이트를 통해 steps[].onError 이벤트 처리기에 변수를 추가할 수 있습니다(예: $(params.CONTINUE) ).
  • 이번 업데이트를 통해 PipelineResults 정의의 finally 작업의 출력을 사용할 수 있습니다. 예를 들어 $(finally.<pipelinetask-name>.result.<result-name>). 여기서 < pipelinetask-name >은 파이프라인 작업 이름을 나타내며 < result-name >은 결과 이름을 나타냅니다.
  • 이번 업데이트에서는 작업 실행에 대한 작업 수준 리소스 요구 사항을 지원합니다.
  • 이번 업데이트를 통해 파이프라인과 정의된 작업 간에 이름을 기반으로 공유되는 매개변수를 다시 생성할 필요가 없습니다. 이 업데이트는 개발자 프리뷰 기능의 일부입니다.
  • 이번 업데이트에서는 기본 제공 git, cluster, bundle, hub resolvers와 같은 원격 해결에 대한 지원이 추가되었습니다.
3.1.5.1.2. Trigger
  • 이번 업데이트에서는 Interceptor CRD를 추가하여 NamespacedInterceptor 를 정의합니다. 트리거 또는 EventListener 사양에서 interceptors 참조의 kind 섹션에서 NamespacedInterceptor 를 사용할 수 있습니다.
  • 이번 업데이트에서는 CloudEvents 를 활성화합니다.
  • 이번 업데이트를 통해 트리거를 정의할 때 Webhook 포트 번호를 구성할 수 있습니다.
  • 이번 업데이트에서는 trigger eventID 를 TriggerBinding 에 대한 입력으로 사용할 수 있습니다.

  • 이번 업데이트에서는 ClusterInterceptor 서버의 인증서 검증 및 교체를 지원합니다. 

    • 트리거는 코어 인터셉터에 대한 인증서 검증을 수행하고 인증서가 만료되면 새 인증서를 ClusterInterceptor 로 바꿉니다.
3.1.5.1.3. CLI 
  • 이번 업데이트에서는 describe 명령에 주석을 표시하는 기능을 지원합니다.
  • 이번 업데이트에서는 pr describe 명령에 파이프라인, 작업 및 시간 초과를 표시할 수 있습니다.
  • 이번 업데이트에서는 pipeline start 명령에서 파이프라인, 작업 및 타임아웃을 제공하는 플래그가 추가되었습니다.
  • 이번 업데이트에서는 작업 및 파이프라인의 describe 명령에 작업 공간(선택 사항 또는 필수)을 표시할 수 있습니다.
  • 이번 업데이트에서는 타임 스탬프 와 함께 로그를 표시하는 타임 스탬프 플래그가 추가되었습니다.
  • 이번 업데이트에서는 PipelineRun 과 연결된 TaskRun 삭제를 무시하는 새로운 플래그 --ignore-running-pipelinerun 이 추가되었습니다.
  • 이번 업데이트에서는 실험적 명령에 대한 지원이 추가되었습니다. 이번 업데이트에서는 tkn CLI 툴에 실험 하위 명령, 서명 및 검증 도 추가되었습니다.
  • 이번 업데이트에서는 파일을 생성하지 않고 Z 쉘(Zsh) 완료 기능을 사용할 수 있습니다.

  • 이번 업데이트에서는 opc 라는 새로운 CLI 툴이 도입되었습니다. 향후 릴리스에서 tkn CLI 툴을 opc 로 교체할 것으로 예상됩니다.

    중요
    • 새로운 CLI 툴 opc 는 기술 프리뷰 기능입니다.
    • OPC 는 tkn 에 적합하지 않은 추가 Red Hat OpenShift Pipelines 특정 기능이 포함된 tkn 을 대체합니다.
3.1.5.1.4. Operator

  • 이번 업데이트를 통해 기본적으로 코드로 Pipeline이 설치됩니다. -p 플래그를 사용하여 코드로 Pipeline을 비활성화할 수 있습니다. 

    $ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": false}}}}}'
  • 이번 업데이트를 통해 TektonConfig CRD에서 Pipeline을 코드 구성으로 수정할 수도 있습니다.
  • 이번 업데이트를 통해 개발자 화면을 비활성화하면 Operator에서 개발자 콘솔 관련 사용자 정의 리소스를 설치하지 않습니다.
  • 이번 업데이트에는 Bitbucket Server 및 Bitbucket Cloud에 대한 ClusterTriggerBinding 지원이 포함되며 전체 클러스터에서 TriggerBinding 을 재사용할 수 있습니다.
3.1.5.1.5. 해결 방법
중요

해결자는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트를 통해 TektonConfig CRD에서 파이프라인 확인자를 구성할 수 있습니다. 이러한 pipeline resolvers: enable-bundles-resolver,enable-cluster-resolver,enable-git-resolver, enable-hub-resolver. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true
...

    TektonConfig 에서 확인자 특정 구성을 제공할 수도 있습니다. 예를 들어 map[string]string 형식으로 다음 필드를 정의하여 개별 확인자에 대한 구성을 설정할 수 있습니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: test
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton
...
3.1.5.1.6. Tekton 체인
중요

Tekton Chains는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트 이전에는 내부 에이전트에서 TaskRun 의 출력으로 OCI(Open Container Initiative) 이미지만 지원되었습니다. 이번 업데이트에서는 이러한 접미사, ARTIFACT_URI 및 ARTIFACT_DIGEST 가 있는 출력으로 in-to provenance 메타데이터를 추가합니다.
  • 이번 업데이트 이전에는 TaskRun attestations만 지원됩니다. 이번 업데이트에서는 PipelineRun 인증도 지원합니다.
  • 이번 업데이트에서는 pod 템플릿에서 imgPullSecret 매개변수를 가져오기 위해 Tekton Chains에 대한 지원이 추가되었습니다. 이번 업데이트를 통해 서비스 계정을 수정하지 않고 각 파이프라인 실행 또는 작업 실행에 따라 리포지토리 인증을 구성할 수 있습니다.
3.1.5.1.7. Tekton Hub
중요

Tekton Hub는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트를 통해 관리자는 기본 Tekton Hub 데이터베이스를 사용하는 대신 Crunchy PostgreSQL with Tekton Hub와 같은 외부 데이터베이스를 사용할 수 있습니다. 이번 업데이트를 통해 다음 작업을 수행할 수 있습니다.

    • Tekton Hub에서 사용할 외부 데이터베이스의 좌표 지정
    • Operator에서 배포한 기본 Tekton Hub 데이터베이스 비활성화

  • 이번 업데이트에서는 외부 Git 리포지토리에서 config.yaml 의 종속성을 제거하고 전체 구성 데이터를 API ConfigMap 으로 이동합니다. 이번 업데이트를 통해 관리자는 다음 작업을 수행할 수 있습니다.

    • Tekton Hub 사용자 정의 리소스에 카테고리, 카탈로그, 범위 및 defaultScope와 같은 구성 데이터를 추가합니다.
    • 클러스터에서 Tekton Hub 구성 데이터를 수정합니다. 모든 수정 사항은 Operator 업그레이드 시 유지됩니다.
    • Tekton Hub의 카탈로그 목록을 업데이트

    • Tekton Hub의 카테고리 변경

      참고

      구성 데이터를 추가하지 않으면 Tekton Hub 구성의 API ConfigMap 에서 기본 데이터를 사용할 수 있습니다.

3.1.5.1.8. Pipeline as Code
  • 이번 업데이트에서는 Repository CRD에 동시성 제한에 대한 지원을 추가하여 한 번에 리포지토리에 대해 실행 중인 최대 PipelineRun 수를 정의합니다. 가져오기 요청 또는 내보내기 이벤트 의 PipelineRun 이 알파벳순으로 큐에 추가됩니다.
  • 이번 업데이트에서는 리포지토리에 대한 최신 파이프라인 실행 로그를 표시하는 새 명령 tkn pac logs 가 추가되었습니다.

  • 이번 업데이트에서는 GitHub 및 GitLab에 대한 푸시 및 가져오기 요청을 위해 파일 경로에서 고급 이벤트 일치를 지원합니다. 예를 들어, CEL(Common Expression Language)을 사용하여 docs 디렉터리의 모든 마크다운 파일에 대한 경로가 변경된 경우에만 파이프라인을 실행할 수 있습니다. 

      ...
  annotations:
     pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" && "docs/*.md".pathChanged()
  • 이번 업데이트를 통해 주석을 사용하여 pipelineRef: 오브젝트의 원격 파이프라인을 참조할 수 있습니다.
  • 이번 업데이트를 통해 Pipeline을 사용하여 새 GitHub 리포지토리를 Code로 자동 구성하여 네임스페이스를 설정하고 GitHub 리포지토리에 대한 Repository CRD를 생성할 수 있습니다.
  • 이번 업데이트를 통해 Pipeline이 공급자 정보를 사용하여 PipelineRuns 에 대한 지표를 생성합니다.

  • 이번 업데이트에서는 tkn-pac 플러그인에 다음과 같은 향상된 기능을 제공합니다.

    • 실행 중인 파이프라인을 올바르게 탐지
    • 실패 완료 시간이 없는 경우 기간을 표시하는 수정
    • 오류 스니펫을 표시하고 tkn-pac describe 명령에서 오류 정규식 패턴을 강조 표시합니다.
    • tkn-pac ls 및 tkn-pac describe 명령에 use-real-time 스위치 추가
    • tkn-pac 로그 문서 가져오기
    • tkn-pac ls 및 tkn-pac describe 명령에서 pipelineruntimeout 을 실패로 표시합니다.
    • --target-pipelinerun 옵션을 사용하여 특정 파이프라인 실행 실패를 표시합니다.
  • 이번 업데이트를 통해 GitHub 검사의 버전 제어 시스템(VCS) 주석 또는 작은 스니펫으로 파이프라인 실행 오류를 볼 수 있습니다.
  • 이번 업데이트를 통해 Pipeline as Code는 선택적으로 간단한 형식인 경우 작업 내에서 오류를 감지하고 GitHub에서 해당 작업을 주석으로 추가할 수 있습니다. 이 업데이트는 개발자 프리뷰 기능의 일부입니다.

  • 이번 업데이트에서는 다음과 같은 새 명령이 추가되었습니다.

    • tkn-pac webhook add: 리포지토리 설정에 Webhook를 추가하고 리포지토리를 업데이트하지 않고 기존 k8s Secret 오브젝트에서 webhook.secret 키를 업데이트합니다.
    • tkn-pac webhook update-token: 리포지토리를 업데이트하지 않고 기존 k8s Secret 오브젝트에 대한 업데이트 공급자 토큰입니다.
  • 이번 업데이트에서는 리포지토리 생성과 함께 GitHub, GitLab, BitbucketCloud에 대한 Webhook를 생성하고 구성하는 tkn-pac create repo 명령의 기능을 개선합니다.
  • 이번 업데이트를 통해 tkn-pac describe 명령은 최신 50개의 이벤트를 정렬된 순서로 표시합니다.
  • 이번 업데이트에서는 tkn-pac logs 명령에 --last 옵션이 추가되었습니다.
  • 이번 업데이트를 통해 tkn-pac resolve 명령으로 파일 템플릿에서 git_auth_secret 을 감지할 때 토큰을 입력하라는 메시지가 표시됩니다.
  • 이번 업데이트를 통해 Pipelines as Code hides secret from log snippets to avoid exposing secret in the GitHub interface.
  • 이번 업데이트를 통해 git_auth_secret 에 대해 자동으로 생성된 보안은 PipelineRun 이 있는 소유자 참조입니다. 파이프라인 실행 실행 후가 아닌 PipelineRun 을 사용하여 보안을 정리합니다.
  • 이번 업데이트에서는 /cancel 주석을 사용하여 파이프라인 실행을 취소하는 지원이 추가되었습니다.

  • 이번 업데이트 이전에는 GitHub 앱 토큰 범위 지정이 정의되지 않았으며 모든 리포지토리 설치에서 토큰이 사용됩니다. 이번 업데이트를 통해 다음 매개변수를 사용하여 GitHub 앱 토큰의 범위를 대상 리포지토리로 지정할 수 있습니다.

    • secret-github-app-token-scoped: 앱 설치에 액세스할 수 있는 모든 리포지토리가 아닌 대상 리포지토리에 앱 토큰을 범위를 지정합니다.
    • secret-github-app-scope-extra-repos: 추가 소유자 또는 리포지터리로 앱 토큰의 범위를 사용자 지정합니다.
  • 이번 업데이트를 통해 GitLab에서 호스팅되는 자체 Git 리포지토리가 있는 코드로 Pipeline을 사용할 수 있습니다.
  • 이번 업데이트를 통해 네임스페이스의 kubernetes 이벤트 형식으로 파이프라인 실행 세부 정보에 액세스할 수 있습니다. 이러한 세부 정보를 사용하면 관리자 네임스페이스에 액세스할 필요 없이 파이프라인 오류 문제를 해결할 수 있습니다.
  • 이번 업데이트에서는 Git 공급자를 사용하여 Pipeline에서 Code resolver로 URL 인증을 지원합니다.
  • 이번 업데이트를 통해 pipelines-as-code 구성 맵의 설정을 사용하여 hub 카탈로그의 이름을 설정할 수 있습니다.
  • 이번 업데이트를 통해 max-keep-run 매개변수의 최대 및 기본 제한을 설정할 수 있습니다.
  • 이번 업데이트에서는 Pipeline에 사용자 정의 SSL(Secure Sockets Layer) 인증서를 삽입하는 방법에 대한 문서가 추가되어 사용자 정의 인증서로 공급자 인스턴스에 연결할 수 있습니다.
  • 이번 업데이트를 통해 PipelineRun 리소스 정의에는 주석으로 포함된 로그 URL이 있습니다. 예를 들어 tkn-pac describe 명령은 PipelineRun 을 설명할 때 로그 링크를 표시합니다.
  • 이번 업데이트를 통해 tkn-pac logs에는 PipelineRun 이름이 아니라 리포지토리 이름이 표시됩니다.

3.1.5.2. 변경 사항 중단

  • 이번 업데이트를 통해 Conditions CRD(사용자 정의 리소스 정의) 유형이 제거되었습니다. 대신 WhenExpressions 를 사용하십시오.
  • 이번 업데이트를 통해 Pipeline, PipelineRun, Task, Clustertask 및 TaskRun과 같은 tekton.dev/v1alpha1 API 파이프라인 리소스가 제거되었습니다.
  • 이번 업데이트를 통해 tkn-pac setup 명령이 제거되었습니다. 대신 tkn-pac webhook add 명령을 사용하여 기존 Git 리포지토리에 Webhook를 다시 추가합니다. 또한 tkn-pac webhook update-token 명령을 사용하여 Git 리포지토리의 기존 Secret 오브젝트에 대한 개인 공급자 액세스 토큰을 업데이트합니다.
  • 이번 업데이트를 통해 기본 설정으로 파이프라인을 실행하는 네임스페이스는 pod-security.kubernetes.io/enforce: privileged 레이블을 워크로드에 적용하지 않습니다.

3.1.5.3. 사용되지 않거나 삭제된 기능

  • Red Hat OpenShift Pipelines 1.9.0 릴리스에서 ClusterTasks 는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 또는 Cluster Resolver 를 사용할 수 있습니다.
  • Red Hat OpenShift Pipelines 1.9.0 릴리스에서는 단일 EventListener 사양의 트리거 사용 및 namespaceSelector 필드가 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 다른 EventListener 사양에서 이러한 필드를 성공적으로 사용할 수 있습니다.
  • Red Hat OpenShift Pipelines 1.9.0 릴리스에서 tkn pipelinerun describe 명령은 PipelineRun 리소스에 대한 타임아웃을 표시하지 않습니다.
  • Red Hat OpenShift Pipelines 1.9.0 릴리스에서는 PipelineResource' CR(사용자 정의 리소스)이 더 이상 사용되지 않습니다. PipelineResource CR은 기술 프리뷰 기능이며 tekton.dev/v1alpha1 API의 일부입니다.
  • Red Hat OpenShift Pipelines 1.9.0 릴리스에서는 클러스터 작업의 사용자 정의 이미지 매개변수가 더 이상 사용되지 않습니다. 또는 클러스터 작업을 복사하고 사용자 정의 이미지를 사용할 수 있습니다.

3.1.5.4. 확인된 문제

  • chain-secret 및 chain-config 구성 맵은 Red Hat OpenShift Pipelines Operator를 제거한 후 제거됩니다. 여기에는 사용자 데이터가 포함되어 있으므로 보존해야 하며 삭제되지 않습니다.

  • Windows에서 tkn pac set of commands를 실행할 때 다음 오류 메시지가 표시될 수 있습니다. 명령이 Windows에서 지원되지 않는 오류 메시지가 표시될 수 있습니다.

    해결방법: NO_COLOR 환경 변수를 true 로 설정합니다.

  • tkn pac resolve -f <filename> | oc create -f 명령을 실행하면 tkn pac resolve 명령에서 templated 매개변수 값을 함수에 사용하는 경우 예상 결과를 제공하지 않을 수 있습니다.

    해결방법: 이 문제를 완화하려면 tkn pac resolve -f <filename> -o tempfile.yaml 명령을 실행하여 임시 파일에 tkn pac resolve 의 출력을 저장한 다음 oc create -f tempfile.yaml 명령을 실행합니다. 예를 들어 tkn pac resolve -f <filename> -o /tmp/pull-request-resolved.yaml && oc create -f /tmp/pull-request-resolved.yaml.

3.1.5.5. 해결된 문제

  • 이번 업데이트 이전에는 빈 배열을 교체한 후 원래 배열에서 paramaters 내부의 매개 변수가 유효하지 않은 빈 문자열을 반환했습니다. 이번 업데이트를 통해 이 문제가 해결되고 원래 배열이 빈 상태로 돌아갑니다.
  • 이번 업데이트 이전에는 파이프라인 실행을 위해 서비스 계정에 중복된 보안이 있는 경우 이로 인해 작업 Pod 생성이 실패했습니다. 이번 업데이트를 통해 이 문제가 해결되고 서비스 계정에 중복된 보안이 있더라도 작업 Pod가 성공적으로 생성됩니다.
  • 이번 업데이트 이전에는 TaskRun의 spec.StatusMessage 필드를 확인하여 사용자가 TaskRun 을 취소했는지 아니면 그 일부 PipelineRun 에 의해 취소되었는지 여부를 구분할 수 없었습니다. 이번 업데이트를 통해 이 문제가 해결되어 사용자는 TaskRun 의 spec.StatusMessage 필드를 확인하여 TaskRun의 상태를 구분할 수 있습니다.
  • 이번 업데이트 이전에는 이전 버전의 유효하지 않은 오브젝트를 삭제할 때 Webhook 검증이 제거되었습니다. 이번 업데이트를 통해 이 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 timeouts.pipeline 매개변수를 0 으로 설정하면 timeouts.tasks 매개변수 또는 timeouts.finally 매개변수를 설정할 수 없습니다. 이번 업데이트에서는 이러한 문제가 해결되었습니다. 이제 timeouts.pipeline 매개변수 값을 설정하면'timeouts.tasks' 매개변수 또는 timeouts.finally 매개변수 값을 설정할 수 있습니다. 예를 들면 다음과 같습니다. 

    yaml
kind: PipelineRun
spec:
  timeouts:
    pipeline: "0"  # No timeout
    tasks: "0h3m0s"
  • 이번 업데이트 이전에는 PipelineRun 또는 TaskRun에서 다른 툴에서 레이블 또는 주석을 업데이트한 경우 경쟁 조건이 발생할 수 있었습니다. 이번 업데이트를 통해 이 문제가 해결되어 라벨 또는 주석을 병합할 수 있습니다.
  • 이번 업데이트 이전에는 로그 키에 파이프라인 컨트롤러와 동일한 키가 없었습니다. 이번 업데이트를 통해 이 문제가 해결되었으며 파이프라인 컨트롤러의 로그 스트림과 일치하도록 로그 키가 업데이트되었습니다. 로그의 키가 "ts"에서 "timestamp", "level"에서 "severity"로 변경되었으며, "message"에서 "msg"로 변경되었습니다.
  • 이번 업데이트 이전에는 PipelineRun이 알 수 없는 상태로 삭제된 경우 오류 메시지가 생성되지 않았습니다. 이번 업데이트를 통해 이 문제가 해결되어 오류 메시지가 생성됩니다.
  • 이번 업데이트 이전에는 list 및 push 와 같은 번들 명령에 액세스하려면 kubeconfig 파일을 사용해야 했습니다. 이번 업데이트를 통해 이 문제가 해결되어 kubeconfig 파일이 번들 명령에 액세스할 필요가 없습니다.
  • 이번 업데이트 이전에는 TaskRun을 삭제하는 동안 상위 PipelineRun이 실행 중이면 TaskRuns가 삭제되었습니다. 이번 업데이트에서는 이 문제가 해결되어 상위 PipelineRun이 실행 중인 경우 TaskRuns가 삭제되지 않습니다.
  • 이번 업데이트 이전에는 사용자가 허용된 파이프라인 컨트롤러보다 더 많은 오브젝트가 있는 번들을 빌드하려고 하면 Tekton CLI에 오류 메시지가 표시되지 않았습니다. 이번 업데이트를 통해 이 문제가 해결되고 Tekton CLI에 사용자가 파이프라인 컨트롤러에 허용된 제한보다 더 많은 오브젝트가 있는 번들을 빌드하려고 하면 오류 메시지가 표시됩니다.
  • 이번 업데이트 이전에는 클러스터에서 네임스페이스가 제거된 경우 Operator에서 ClusterInterceptor ClusterRoleBinding 제목에서 네임스페이스를 제거하지 않았습니다. 이번 업데이트를 통해 이 문제가 해결되었으며 Operator는 ClusterInterceptor ClusterRoleBinding 제목에서 네임스페이스를 제거합니다.
  • 이번 업데이트 이전에는 Red Hat OpenShift Pipelines Operator의 기본 설치로 인해 클러스터에 남아 있는 pipelines-scc-rolebinding security context constraint (SCC) 역할 바인딩 리소스가 생성되었습니다. 이번 업데이트를 통해 Red Hat OpenShift Pipelines Operator의 기본 설치로 pipelines-scc-rolebinding security context constraint (SCC) 역할 바인딩 리소스 리소스가 클러스터에서 제거됩니다.
  • 이번 업데이트 이전에는 Code로 Pipeline이 Code ConfigMap 오브젝트로 Pipeline을 업데이트하지 않았습니다. 이번 업데이트를 통해 이 문제가 수정되었으며 Code ConfigMap 오브젝트로서 Pipeline에서 새로운 변경 사항을 찾습니다.
  • 이번 업데이트 이전에는 Code 컨트롤러로서 Pipeline이 tekton.dev/pipeline 레이블이 업데이트될 때까지 기다리지 않고 checkrun id 레이블을 추가하여 경쟁 조건이 발생했습니다. 이번 업데이트를 통해 Pipelines as Code 컨트롤러에서 tekton.dev/pipeline 레이블이 업데이트될 때까지 기다린 다음, 경쟁 조건을 방지하는 데 도움이 되는 checkrun id 레이블을 추가합니다.
  • 이번 업데이트 이전에는 tkn-pac create repo 명령이 git 리포지토리에 이미 존재하는 경우 PipelineRun 을 재정의하지 않았습니다. 이번 업데이트를 통해 tkn-pac create 명령이 git 리포지토리에 있는 경우 PipelineRun 을 재정의하도록 수정되어 문제가 성공적으로 해결됩니다.
  • 이번 업데이트 이전에는 tkn pac describe 명령이 모든 메시지에 대한 이유를 표시하지 않았습니다. 이번 업데이트에서는 이 문제가 해결되어 tkn pac describe 명령을 실행하면 모든 메시지에 대한 이유가 표시됩니다.
  • 이번 업데이트 이전에는 주석의 사용자가 regex 양식을 사용하여 값을 제공한 경우(예: refs/head/rel-* ) 가져오기 요청이 실패했습니다. 기본 분기에 refs/heads 가 누락되어 가져오기 요청이 실패했습니다. 이번 업데이트를 통해 접두사가 추가되고 일치하는지 확인합니다. 이렇게 하면 문제가 해결되고 가져오기 요청이 성공적으로 수행됩니다.

3.1.5.6. Red Hat OpenShift Pipelines General Availability 1.9.1 릴리스 정보

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.9.1은 OpenShift Container Platform 4.11, 4.12 및 4.13에서 사용할 수 있습니다.

3.1.5.7. 해결된 문제

  • 이번 업데이트 이전에는 tkn pac repo list 명령이 Microsoft Windows에서 실행되지 않았습니다. 이번 업데이트에서는 이 문제가 해결되어 이제 Microsoft Windows에서 tkn pac repo list 명령을 실행할 수 있습니다.
  • 이번 업데이트 이전에는 Code watcher로 Pipeline이 모든 구성 변경 이벤트를 수신하지 못했습니다. 이번 업데이트를 통해 Code watcher가 업데이트될 때 Pipeline이 업데이트되고 이제 Code watcher가 구성 변경 이벤트를 누락하지 않습니다.
  • 이번 업데이트 이전에는 TaskRuns 또는 PipelineRuns 와 같이 Pipeline에서 생성한 Pod가 클러스터의 사용자가 노출한 사용자 정의 인증서에 액세스할 수 없었습니다. 이번 업데이트에서는 문제가 해결되어 클러스터의 TaskRuns 또는 PipelineRuns Pod에서 사용자 정의 인증서에 액세스할 수 있습니다.
  • 이번 업데이트 이전에는 FIPS를 사용하여 활성화된 클러스터에서 Trigger 리소스에 사용된 tekton-triggers-core-interceptors 코어 인터셉터가 Pipelines Operator가 버전 1.9로 업그레이드된 후 작동하지 않았습니다. 이번 업데이트에서는 이러한 문제가 해결되었습니다. 이제 OpenShift는 모든 구성 요소에 MInTLS 1.2를 사용합니다. 결과적으로 tekton-triggers-core-interceptors 코어 인터셉터가 TLS 버전 1.2로 업데이트되고 해당 기능이 정확하게 실행됩니다.

  • 이번 업데이트 이전에는 내부 OpenShift 이미지 레지스트리와 함께 파이프라인 실행을 사용할 때 파이프라인 실행 정의에서 이미지의 URL을 하드 코딩해야 했습니다. 예를 들면 다음과 같습니다. 

    ...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/<test_namespace>/<test_pipelinerun>'
...

    파이프라인의 컨텍스트에서 Code로 파이프라인 실행을 사용하는 경우 이러한 하드 코딩된 값을 사용하면 파이프라인 실행 정의가 다른 클러스터 및 네임스페이스에서 사용되지 않습니다.

    이번 업데이트를 통해 네임스페이스 및 파이프라인 실행 이름을 하드 코딩하여 파이프라인 실행 정의를 일반화하는 대신 동적 템플릿 변수를 사용할 수 있습니다. 예를 들면 다음과 같습니다. 

    ...
  - name: IMAGE_NAME
    value: 'image-registry.openshift-image-registry.svc:5000/{{ target_namespace }}/$(context.pipelineRun.name)'
...
  • 이번 업데이트 이전에는 Code로 동일한 GitHub 토큰을 사용하여 기본 GitHub 분기에서만 동일한 호스트에서 사용 가능한 원격 작업을 가져옵니다. 이번 업데이트에서는 이러한 문제가 해결되었습니다. 이제 Code로 Pipeline은 동일한 GitHub 토큰을 사용하여 GitHub 분기에서 원격 작업을 가져옵니다.

3.1.5.8. 확인된 문제

  • Tekton Hub CR에 사용된 Hub API ConfigMap 오브젝트의 필드인 CATALOG_REFRESH_INTERVAL 값은 사용자가 제공하는 사용자 지정 값으로 업데이트되지 않습니다.

    해결방법: 없음. SRVKP-2854 문제를 추적할 수 있습니다.

3.1.5.9. 변경 사항 중단

  • 이번 업데이트를 통해 OLM 잘못된 구성 문제가 도입되어 OpenShift Container Platform 업그레이드가 수행되지 않습니다. 이 문제는 향후 릴리스에서 해결될 예정입니다.

3.1.5.10. Red Hat OpenShift Pipelines General Availability 1.9.2 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.11, 4.12 및 4.13에서 Red Hat OpenShift Pipelines General Availability (GA) 1.9.2를 사용할 수 있습니다.

3.1.5.11. 해결된 문제

  • 이번 업데이트 이전에는 이전 버전의 릴리스에서 OLM의 잘못된 구성 문제가 도입되어 OpenShift Container Platform이 업그레이드할 수 없었습니다. 이번 업데이트를 통해 이 잘못된 구성 문제가 수정되었습니다.

3.1.5.12. Red Hat OpenShift Pipelines General Availability 1.9.3 릴리스 노트

이번 업데이트를 통해 Red Hat OpenShift Pipelines General Availability (GA) 1.9.3은 4.11, 4.12 및 4.13 외에도 OpenShift Container Platform 4.10에서 사용할 수 있습니다.

3.1.5.13. 해결된 문제

  • 이번 업데이트에서는 대규모 파이프라인의 성능 문제가 해결되었습니다. 이제 CPU 사용량이 61% 감소하고 메모리 사용량이 44% 감소합니다.
  • 이번 업데이트 이전에는 when 표현식으로 인해 작업이 실행되지 않은 경우 파이프라인 실행이 실패했습니다. 이번 업데이트에서는 건너뛰기된 작업의 유효성 검사로 인해 파이프라인 결과가 발생하지 않도록하여 문제가 해결되었습니다. 이제 파이프라인 결과가 배출되지 않고 누락된 결과 때문에 파이프라인 실행이 실패하지 않습니다.
  • 이번 업데이트에서는 v1beta1 API의 bundle resolver로 pipelineref.bundle 변환이 수정되었습니다. 이제 변환 기능은 변환 후 kind 필드의 값을 Pipeline 으로 설정합니다.
  • 이번 업데이트 이전에는 OpenShift Pipelines Operator의 문제로 인해 사용자가 spec.pipeline.enable-api-fields 필드의 값을 beta 로 설정할 수 없었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 이제 TektonConfig 사용자 정의 리소스에서 alpha 및 stable 과 함께 값을 beta 로 설정할 수 있습니다.
  • 이번 업데이트 이전에는 클러스터 오류로 인해 Pipeline이 시크릿을 생성할 수 없는 경우 GitHub 검사 실행에 임시 토큰을 공용으로 표시했습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 이제 보안 생성에 실패하면 GitHub 검사 인터페이스에 토큰이 더 이상 표시되지 않습니다.

3.1.5.14. 확인된 문제

  • 현재 OpenShift Container Platform 웹 콘솔에서 파이프라인 실행 중지 옵션에 알려진 문제가 있습니다. 작업 드롭다운 목록의 중지 옵션이 예상대로 작동하지 않으며 파이프라인 실행을 취소하지 않습니다.

  • 현재 사용자 정의 리소스 정의 변환 실패로 인해 OpenShift Pipelines 버전 1.9.x로 업그레이드하는 데 알려진 문제가 있습니다.

    해결방법: OpenShift Pipelines 버전 1.9.x로 업그레이드하기 전에 Red Hat 고객 포털의 솔루션에 언급된 단계를 수행합니다.

3.1.6. Red Hat OpenShift Pipelines General Availability 1.8 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.10, 4.11, 4.12에서 Red Hat OpenShift Pipelines General Availability (GA) 1.8을 사용할 수 있습니다.

3.1.6.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.8의 새로운 기능도 소개합니다.

3.1.6.1.1. 파이프라인
  • 이번 업데이트를 통해 ARM 하드웨어에서 실행 중인 OpenShift Container Platform 클러스터에서 Red Hat OpenShift Pipelines GA 1.8 이상을 실행할 수 있습니다. 여기에는 ClusterTask 리소스 및 tkn CLI 툴 지원이 포함됩니다.
중요

ARM 하드웨어에서 Red Hat OpenShift Pipelines를 실행하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트에서는 TaskRun 리소스에 대한 Step 및 Sidecar 덮어쓰기를 구현합니다.

  • 이번 업데이트에서는 PipelineRun 상태 내에 최소 TaskRun 및 Run 상태가 추가되었습니다.

    이 기능을 활성화하려면 pipeline 섹션의 TektonConfig 사용자 지정 리소스 정의에서 enable-api-fields 필드를 alpha 로 설정해야 합니다.

  • 이번 업데이트를 통해 알파 기능에서 stable 기능으로 승격됩니다. 결과적으로 이전에 더 이상 사용되지 않는 PipelineRunCancelled 상태는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

    이 기능은 기본적으로 사용할 수 있으므로 더 이상 TektonConfig 사용자 정의 리소스 정의에서 pipeline.enable-api-fields 필드를 alpha 로 설정할 필요가 없습니다.

  • 이번 업데이트를 통해 작업 공간 이름을 사용하여 파이프라인 작업의 작업 영역을 지정할 수 있습니다. 이러한 변경을 통해 Pipeline 및 PipelineTask 리소스의 공유 작업 공간을 더 쉽게 지정할 수 있습니다. 또한 작업 공간을 명시적으로 매핑할 수도 있습니다.

    이 기능을 활성화하려면 pipeline 섹션의 TektonConfig 사용자 지정 리소스 정의에서 enable-api-fields 필드를 alpha 로 설정해야 합니다.

  • 이번 업데이트를 통해 포함된 사양의 매개변수가 변경 없이 전파됩니다.
  • 이번 업데이트를 통해 주석 및 라벨을 사용하여 PipelineRun 리소스에서 참조하는 Task 리소스의 필수 메타데이터를 지정할 수 있습니다. 이렇게 하면 파이프라인 실행 중에 실행 컨텍스트에 따라 Task 메타데이터를 사용할 수 있습니다.
  • 이번 업데이트에서는 params 및 results 값에 오브젝트 또는 사전 유형에 대한 지원이 추가되었습니다. 이 변경 사항은 이전 버전과의 호환성에 영향을 미치며 이전 클라이언트를 Red Hat OpenShift Pipelines 버전과 함께 사용하는 경우와 같이 이전 버전과의 호환성이 중단되는 경우가 있습니다. 이번 업데이트에서는 Go 언어 API를 라이브러리로 사용하는 프로젝트에 영향을 미치는 ArrayOrStruct 구조가 변경됩니다.
  • 이번 업데이트에서는 PipelineRun status 필드의 SkippedTasks 필드에 SkiECDHE Reason 값을 추가하여 사용자가 지정된 PipelineTask를 건너뛰는 이유를 알 수 있습니다.

  • 이번 업데이트에서는 Task 오브젝트에서 결과를 내보내는 데 배열 유형을 사용할 수 있는 알파 기능을 지원합니다. 결과 유형이 string 에서 ArrayOrString 으로 변경됩니다. 예를 들어 작업은 유형을 지정하여 배열 결과를 생성할 수 있습니다. 

    kind: Task
apiVersion: tekton.dev/v1beta1
metadata:
  name: write-array
  annotations:
    description: |
      A simple task that writes array
spec:
  results:
    - name: array-results
      type: array
      description: The array results
...

    또한 작업 스크립트를 실행하여 결과를 배열로 채울 수 있습니다. 

    $ echo -n "[\"hello\",\"world\"]" | tee $(results.array-results.path)

    이 기능을 활성화하려면 pipeline 섹션의 TektonConfig 사용자 지정 리소스 정의에서 enable-api-fields 필드를 alpha 로 설정해야 합니다.

    이 기능은 진행 중이며 TEP-0076의 일부입니다.

3.1.6.1.2. Trigger

  • 이번 업데이트에서는 EventListener 사양의 TriggerGroups 필드를 alpha 기능에서 stable 기능으로 전환합니다. 이 필드를 사용하여 트리거 그룹을 선택하고 실행하기 전에 인터셉터 세트를 지정할 수 있습니다.

    이 기능은 기본적으로 사용할 수 있으므로 더 이상 TektonConfig 사용자 정의 리소스 정의에서 pipeline.enable-api-fields 필드를 alpha 로 설정할 필요가 없습니다.

  • 이번 업데이트를 통해 Trigger 리소스는 HTTPS를 사용하여 ClusterInterceptor 서버를 실행하여 엔드 투 엔드 보안 연결을 지원합니다.
3.1.6.1.3. CLI
  • 이번 업데이트를 통해 tkn taskrun export 명령을 사용하여 클러스터에서 라이브 작업 실행을 YAML 파일로 내보낼 수 있습니다. 이 파일은 작업 실행을 다른 클러스터로 가져오는 데 사용할 수 있습니다.
  • 이번 업데이트를 통해 tkn pipeline start 명령에 -o name 플래그를 추가하여 시작 직후 파이프라인 실행 이름을 출력할 수 있습니다.
  • 이번 업데이트에서는 tkn --help 명령의 출력에 사용 가능한 플러그인 목록이 추가되었습니다.
  • 이번 업데이트를 통해 파이프라인 실행 또는 작업 실행을 삭제하는 동안 --keep 및 --keep-since 플래그를 함께 사용할 수 있습니다.
  • 이번 업데이트를 통해 더 이상 사용되지 않는 PipelineRunCancelled 값이 아닌 spec.status 필드의 값으로 Cancelled 를 사용할 수 있습니다.
3.1.6.1.4. Operator
  • 이번 업데이트를 통해 관리자는 기본 데이터베이스 대신 사용자 지정 데이터베이스를 사용하도록 로컬 Tekton Hub 인스턴스를 구성할 수 있습니다.

  • 이번 업데이트를 통해 클러스터 관리자는 로컬 Tekton Hub 인스턴스를 활성화하면 주기적으로 데이터베이스를 새로 고쳐 카탈로그 변경 사항이 Tekton Hub 웹 콘솔에 표시됩니다. 새로 고침 간격을 조정할 수 있습니다.

    이전에는 카탈로그의 작업 및 파이프라인을 데이터베이스에 추가하기 위해 해당 작업을 수동으로 수행하거나 cron 작업을 설정하여 작업을 수행할 수 있었습니다.

  • 이번 업데이트를 통해 최소한의 구성으로 Tekton Hub 인스턴스를 설치하고 실행할 수 있습니다. 이렇게 하면 팀과 협력하여 원하는 추가 사용자 정의를 결정할 수 있습니다.
  • 이번 업데이트에서는 git-clone 작업에 GIT_SSL_CAINFO 가 추가되어 보안 리포지토리를 복제할 수 있습니다.
3.1.6.1.5. Tekton 체인
중요

Tekton Chains는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트를 통해 정적 토큰이 아닌 OIDC를 사용하여 자격 증명 모음에 로그인할 수 있습니다. 이 변경으로 인해 Spire는 신뢰할 수 있는 워크로드만 자격 증명 모음에 로그인할 수 있도록 OIDC 인증 정보를 생성할 수 있습니다. 또한 자격 증명 모음 주소를 환경 변수로 삽입하지 않고 구성 값으로 전달할 수 있습니다.
  • Red Hat OpenShift Pipelines Operator를 사용하여 설치할 때 구성 맵을 직접 업데이트할 수 없기 때문에 openshift-pipelines 네임스페이스의 Tekton Chains에 대한 chain -config 구성 맵은 Red Hat OpenShift Pipelines Operator를 업그레이드한 후 자동으로 기본값으로 재설정됩니다. 그러나 이번 업데이트를 통해 TektonChain 사용자 정의 리소스를 사용하여 Tekton Chains를 구성할 수 있습니다. 이 기능을 사용하면 chain-config 구성 맵과 달리 업그레이드 후 구성을 유지할 수 있으며 업그레이드 중에 덮어쓸 수 있습니다.
3.1.6.1.6. Tekton Hub
중요

Tekton Hub는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트를 통해 Operator를 사용하여 Tekton Hub의 새 인스턴스를 설치하면 Tekton Hub 로그인이 기본적으로 비활성화됩니다. 로그인 및 등급 기능을 활성화하려면 Tekton Hub를 설치하는 동안 Hub API 시크릿을 생성해야 합니다.

    참고

    Red Hat OpenShift Pipelines 1.7에서 Tekton Hub 로그인이 기본적으로 활성화되어 있었기 때문에 Operator를 업그레이드하는 경우 Red Hat OpenShift Pipelines 1.8에서 로그인이 기본적으로 활성화됩니다. 이 로그인 을 비활성화하려면 OpenShift Pipelines 1.7.x에서 업그레이드한 후 Tekton Hub 로그인 비활성화를 참조하십시오. 1.8.x

  • 이번 업데이트를 통해 관리자는 기본 데이터베이스가 아닌 사용자 지정 PostgreSQL 13 데이터베이스를 사용하도록 로컬 Tekton Hub 인스턴스를 구성할 수 있습니다. 이를 위해 tekton-hub-db 라는 Secret 리소스를 생성합니다. 예를 들면 다음과 같습니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: tekton-hub-db
  labels:
    app: tekton-hub-db
type: Opaque
stringData:
  POSTGRES_HOST: <hostname>
  POSTGRES_DB: <database_name>
  POSTGRES_USER: <username>
  POSTGRES_PASSWORD: <password>
  POSTGRES_PORT: <listening_port_number>
  • 이번 업데이트를 통해 더 이상 카탈로그의 리소스를 데이터베이스에 추가하기 위해 Tekton Hub 웹 콘솔에 로그인할 필요가 없습니다. 이제 Tekton Hub API가 처음 실행을 시작할 때 이러한 리소스가 자동으로 추가됩니다.
  • 이번 업데이트에서는 카탈로그 새로 고침 API 작업을 호출하여 30분마다 카탈로그를 자동으로 새로 고칩니다. 이 간격은 user-configurable입니다.
3.1.6.1.7. Pipeline as Code
중요

Pipeline as Code (PAC)는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트를 통해 개발자는 코드 실행으로 Pipeline에 중복 리포지토리를 추가하려는 경우 tkn-pac CLI 툴에서 알림을 받습니다. tkn pac create repository 를 입력하면 각 리포지토리에 고유한 URL이 있어야 합니다. 이 알림은 또한 하이재킹 취약점을 방지하는 데 도움이 됩니다.
  • 이번 업데이트를 통해 개발자는 새로운 tkn-pac setup cli 명령을 사용하여 웹 후크 메커니즘을 사용하여 Pipeline에 Git 리포지토리를 코드로 추가할 수 있습니다. 이렇게 하면 GitHub 앱을 사용할 수 없는 경우에도 Pipeline을 코드로 사용할 수 있습니다. 이 기능에는 GitHub, GitLab, BitBucket의 리포지토리 지원이 포함됩니다.

  • 이번 업데이트를 통해 Pipeline as Code는 다음과 같은 기능과 GitLab 통합을 지원합니다.

    • 프로젝트 또는 그룹의 ACL (액세스 제어 목록)
    • 허용된 사용자의 /OK-to-test 지원
    • /retest 지원.

  • 이번 업데이트를 통해 CEL(Common Expression Language)으로 고급 파이프라인 필터링을 수행할 수 있습니다. CEL을 사용하면 PipelineRun 리소스의 주석을 사용하여 파이프라인 실행을 다른 Git 공급자 이벤트와 일치시킬 수 있습니다. 예를 들면 다음과 같습니다. 

      ...
  annotations:
     pipelinesascode.tekton.dev/on-cel-expression: |
      event == "pull_request" && target_branch == "main" && source_branch == "wip"
  • 이전 버전에서는 개발자로서 각 Git 이벤트에 대해 .tekton 디렉터리에 가져오기 요청과 같은 파이프라인 실행만 있을 수 있었습니다. 이번 업데이트를 통해 .tekton 디렉터리에 여러 파이프라인 실행이 있을 수 있습니다. 웹 콘솔에는 실행 상태 및 보고서가 표시됩니다. 파이프라인 실행은 병렬로 작동하며 Git 공급자 인터페이스로 다시 보고합니다.
  • 이번 업데이트를 통해 가져오기 요청에서 /test 또는 /retest 에 주석을 달아 파이프라인 실행을 테스트하거나 다시 테스트할 수 있습니다. 이름으로 파이프라인 실행을 지정할 수도 있습니다. 예를 들어 /test <pipelinerun_name > 또는 /retest <pipelinerun-name >을 입력할 수 있습니다.
  • 이번 업데이트를 통해 새 tkn-pac delete repository 명령을 사용하여 리포지토리 사용자 정의 리소스 및 관련 보안을 삭제할 수 있습니다.

3.1.6.2. 변경 사항 중단

  • 이번 업데이트에서는 TaskRun 및 PipelineRun 리소스의 기본 메트릭 수준을 다음 값으로 변경합니다. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: config-observability
  namespace: tekton-pipelines
  labels:
    app.kubernetes.io/instance: default
    app.kubernetes.io/part-of: tekton-pipelines
data:
  _example: |
  ...
    metrics.taskrun.level: "task"
    metrics.taskrun.duration-type: "histogram"
    metrics.pipelinerun.level: "pipeline"
    metrics.pipelinerun.duration-type: "histogram"
  • 이번 업데이트를 통해 Pipeline 및 PipelineRun 리소스에 주석 또는 라벨이 있는 경우 Run 유형의 값이 우선합니다. 주석 또는 레이블이 Task 및 TaskRun 리소스에 있는 경우에도 마찬가지입니다.
  • Red Hat OpenShift Pipelines 1.8에서 이전에 더 이상 사용되지 않는 PipelineRun.Spec.ServiceAccountNames 필드가 제거되었습니다. 대신 PipelineRun.Spec.TaskRunSpecs 필드를 사용합니다.
  • Red Hat OpenShift Pipelines 1.8에서 이전에 더 이상 사용되지 않는 TaskRun.Status.ResourceResults.ResourceRef 필드가 제거되었습니다. 대신 TaskRun.Status.ResourceResults.ResourceName 필드를 사용합니다.
  • Red Hat OpenShift Pipelines 1.8에서는 이전에 더 이상 사용되지 않는 Conditions 리소스 유형이 제거되었습니다. 이를 포함하는 Pipeline 리소스 정의에서 Conditions 리소스를 제거합니다. PipelineRun 정의에서 when 표현식을 대신 사용합니다.
  • Tekton Chains의 경우 tekton-provenance 형식이 이번 릴리스에서 제거되었습니다. Tektonchain 사용자 정의 리소스에서 "artifacts.taskrun.format": " in-toto "를 설정하여 in-to 형식을 사용합니다.

  • Red Hat OpenShift Pipelines 1.7.x는 Pipeline과 함께 0.5.x로 제공됩니다. 현재 업데이트는 Pipeline 0.10.x와 함께 제공됩니다. 이러한 변경으로 인해 새 컨트롤러에 대한 openshift-pipelines 네임스페이스에 새 경로가 생성됩니다. GitHub 앱 또는 Pipeline을 코드로 사용하는 Webhook에서 이 경로를 업데이트해야 합니다. 경로를 가져오려면 다음 명령을 사용합니다. 

    $ oc get route -n openshift-pipelines pipelines-as-code-controller \
  --template='https://{{ .spec.host }}'
  • 이번 업데이트를 통해 Pipelines는 Code에서 Repository CRD(사용자 정의 리소스 정의)의 기본 시크릿 키의 이름을 변경합니다. CRD에서 토큰을 provider. token 으로 바꾸고 보안을 webhook. secret 으로 바꿉니다.
  • 이번 업데이트를 통해 Pipeline as Code가 개인 리포지토리에 대해 여러 파이프라인 실행을 지원하는 특수 템플릿 변수를 대체합니다. 파이프라인 실행에서 secret: pac-git-basic-auth-{{repo_owner}}-{{repo_name}} 를 secret: {{ git_auth_secret }} 로 바꿉니다.

  • 이번 업데이트를 통해 Pipeline as Code는 tkn-pac CLI 툴에서 다음 명령을 업데이트합니다.

    • tkn pac 리포지토리 create를 tkn pac create 리포지토리로 교체합니다.
    • tkn pac repository delete 를 tkn pac delete 리포지토리로 교체합니다.
    • tkn pac 리포지토리 목록을 tkn pac list 로 교체합니다.

3.1.6.3. 사용되지 않거나 삭제된 기능

  • OpenShift Container Platform 4.11부터 Red Hat OpenShift Pipelines Operator 설치 및 업그레이드를 위한 프리뷰 및 안정적인 채널이 제거됩니다. Operator를 설치하고 업그레이드하려면 적절한 pipelines-<version > 채널을 사용하거나 안정적인 최신 버전의 최신 채널을 사용합니다. 예를 들어 OpenShift Pipelines Operator 버전 1.8.x 를 설치하려면 pipelines-1.8 채널을 사용합니다.

    참고

    OpenShift Container Platform 4.10 및 이전 버전에서는 Operator를 설치 및 업그레이드하기 위해 프리뷰 및 안정적인 채널을 사용할 수 있습니다.

  • Red Hat OpenShift Pipelines GA 1.6에서 더 이상 사용되지 않는 tekton.dev/v1alpha1 API 버전에 대한 지원은 향후 Red Hat OpenShift Pipelines GA 1.9 릴리스에서 제거될 예정입니다.

    이 변경 사항은 TaskRun,PipelineRun,Task,Pipeline, 유사한 tekton.dev/v1alpha1 리소스가 포함된 파이프라인 구성 요소에 영향을 미칩니다. 또는 Tekton v1 alpha1에서 Tekton v1beta1로 마이그레이션에 설명된 대로 apiVersion: tekton.dev/v1beta1 을 사용하도록 기존 리소스를 업데이트합니다.

    tekton.dev/v1alpha1 API 버전에 대한 버그 수정 및 지원은 현재 GA 1.8 라이프사이클이 종료되는 경우에만 제공됩니다.

    중요

    Tekton Operator 의 경우 operator.tekton.dev/v1alpha1 API 버전은 더 이상 사용되지 않습니다. 이 값을 변경할 필요가 없습니다.

  • Red Hat OpenShift Pipelines 1.8에서는 PipelineResource CR(사용자 정의 리소스)을 사용할 수 있지만 더 이상 지원되지 않습니다. PipelineResource CR은 기술 프리뷰 기능이며 더 이상 사용되지 않고 향후 Red Hat OpenShift Pipelines GA 1.9 릴리스에서 제거될 예정인 tekton.dev/v1alpha1 API의 일부입니다.
  • Red Hat OpenShift Pipelines 1.8에서 Condition CR(사용자 정의 리소스)이 제거됩니다. Condition CR은 더 이상 사용되지 않으며 향후 Red Hat OpenShift Pipelines GA 1.9 릴리스에서 제거될 예정인 tekton.dev/v1alpha1 API의 일부입니다.
  • Red Hat OpenShift Pipelines 1.8에서는 gsutil 의 gcr.io 이미지가 제거되었습니다. 이 제거로 인해 이 이미지에 종속된 Pipeline 리소스가 있는 클러스터가 손상될 수 있습니다. 버그 수정 및 지원은 Red Hat OpenShift Pipelines 1.7 라이프사이클 종료를 통해서만 제공됩니다.
  • Red Hat OpenShift Pipelines 1.8에서 PipelineRun.Status.TaskRuns 및 PipelineRun.Status.Runs 필드는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. PipelineRuns에서 TEP-0100:ECDHE TaskRuns 및 Runs Status 를 참조하십시오.

  • Red Hat OpenShift Pipelines 1.8에서는 pipelineRunCancelled 상태가 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 이제 PipelineRun 오브젝트의 정상 종료가 alpha 기능에서 stable 기능으로 승격됩니다. ( TEP-0058: Graceful Pipeline Run Termination 참조) 다른 방법으로 pipelineRunCancelled 상태를 대체하는 취소 상태를 사용할 수 있습니다.

    Pipeline 및 Task 리소스를 변경할 필요가 없습니다. 파이프라인 실행을 취소하는 툴이 있는 경우 다음 릴리스에서 툴을 업데이트해야 합니다. 이러한 변경 사항은 새로운 PipelineRun 상태를 지원하기 위해 CLI, IDE 확장 등과 같은 툴에도 영향을 미칩니다.

    이 기능은 기본적으로 사용할 수 있으므로 더 이상 TektonConfig 사용자 정의 리소스 정의에서 pipeline.enable-api-fields 필드를 alpha 로 설정할 필요가 없습니다.

  • Red Hat OpenShift Pipelines 1.8에서는 PipelineRun 의 시간 초과 필드가 더 이상 사용되지 않습니다. 대신 alpha 기능에서 stable 기능으로 승격된 PipelineRun.Timeouts 필드를 사용합니다.

    이 기능은 기본적으로 사용할 수 있으므로 더 이상 TektonConfig 사용자 정의 리소스 정의에서 pipeline.enable-api-fields 필드를 alpha 로 설정할 필요가 없습니다.

  • Red Hat OpenShift Pipelines 1.8에서는 init 컨테이너가 LimitRange 오브젝트의 기본 요청 계산에서 생략됩니다.

3.1.6.4. 확인된 문제

  • s2i-nodejs 파이프라인에서 nodejs:14-ubi8-minimal 이미지 스트림을 사용하여 S2I(Source-to-Image) 빌드를 수행할 수 없습니다. 해당 이미지 스트림을 사용하면 STEP "RUN /usr/libexec/s2i/assemble": exit status 127 메시지에서 오류가 발생합니다.

    해결방법: nodejs:14-ubi8-minimal 이미지 스트림 대신 nodejs:14-ubi8 을 사용합니다.

  • Maven 및 Jib-Maven 클러스터 작업을 실행하는 경우 기본 컨테이너 이미지는 Intel (x86) 아키텍처에서만 지원됩니다. 따라서 작업은 ARM, IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x) 클러스터에서 실패합니다.

    해결방법: MAVEN_IMAGE 매개변수 값을 maven:3.6.3-adoptopenjdk-11 로 설정하여 사용자 정의 이미지를 지정합니다.

    작은 정보

    tkn hub 를 사용하여 ARM, IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x)을 기반으로 하는 작업을 설치하기 전에 이러한 플랫폼에서 작업을 실행할 수 있는지 확인합니다. 작업 정보의 "Platforms" 섹션에 ppc64le 및 s390x 가 나열되어 있는지 확인하려면 tkn hub info task <name> 명령을 실행할 수 있습니다.

  • ARM, IBM Power Systems, IBM Z 및 LinuxONE에서는 s2i-dotnet 클러스터 작업이 지원되지 않습니다.
  • 암시적 매개변수 매핑은 최상위 Pipeline 또는 PipelineRun 정의의 매개변수를 taskRef 작업으로 잘못 전달합니다. 매핑은 최상위 리소스에서 인라인 taskSpec 사양이 있는 작업에만 적용되어야 합니다. 이 문제는 TektonConfig 사용자 정의 리소스 정의의 pipeline 섹션에서 enable-api-fields 필드를 alpha 로 설정하여 이 기능을 활성화한 클러스터에만 영향을 미칩니다.

3.1.6.5. 해결된 문제

  • 이번 업데이트 이전에는 웹 콘솔의 개발자 보기에서 파이프라인 실행 메트릭이 불완전하고 오래되었습니다. 이번 업데이트를 통해 지표가 올바르도록 문제가 해결되었습니다.
  • 이번 업데이트 이전에는 파이프라인에 실패한 병렬 작업이 두 개 있고 그 중 하나에 retries=2 가 있는 경우 마지막 작업이 실행되지 않고 파이프라인이 시간 초과되어 실행되지 않았습니다. 예를 들어 pipelines-operator-subscription 작업이 간헐적으로 실패하고 다음 오류 메시지가 표시됩니다. Unable to connect to the server: EOF. 이번 업데이트를 통해 최종 작업이 항상 실행되도록 문제가 해결되었습니다.
  • 이번 업데이트 이전에는 작업 실행이 실패하여 파이프라인 실행이 중지된 경우 다른 작업 실행이 재시도를 완료하지 못할 수 있습니다. 결과적으로 finally 작업이 예약되지 않아 파이프라인이 중단되었습니다. 이번 업데이트에서는 이러한 문제가 해결되었습니다. 정상적인 중지를 통해 파이프라인 실행이 중지된 경우에도 TaskRuns 및 Run 오브젝트를 다시 시도하여 파이프라인 실행이 완료될 수 있습니다.
  • 이번 업데이트에서는 TaskRun 오브젝트가 있는 네임스페이스에 하나 이상의 LimitRange 오브젝트가 있을 때 리소스 요구 사항이 계산된 방식을 변경합니다. 스케줄러는 이제 단계 컨테이너를 고려하고 LimitRange 오브젝트의 요청을 인수할 때 사이드카 컨테이너와 같은 다른 모든 앱 컨테이너를 제외합니다.
  • 이번 업데이트 이전에는 특정 조건에서 플래그 패키지가 이중 대시 플래그 종료자 -- 뒤에 있는 하위 명령을 잘못 구문 분석할 수 있습니다. 이 경우 실제 명령이 아닌 entrypoint 하위 명령을 실행했습니다. 이번 업데이트에서는 진입점이 올바른 명령을 실행하도록 이 플래그 구문 분석 문제가 해결되었습니다.
  • 이번 업데이트 이전에는 이미지를 가져오는 경우 컨트롤러가 여러 개의 패닉을 생성하거나 풀 상태가 불완전할 수 있습니다. 이번 업데이트에서는 status.TaskSpec 값이 아닌 step.ImageID 값을 확인하여 문제를 해결합니다.
  • 이번 업데이트 이전에는 예약되지 않은 사용자 정의 작업이 포함된 파이프라인 실행을 취소하여 PipelineRunCouldntCancel 오류가 발생했습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 해당 오류를 생성하지 않고 예약되지 않은 사용자 정의 작업이 포함된 파이프라인 실행을 취소할 수 있습니다.

  • 이번 업데이트 이전에는 $params["< NAME >"]의 <NAME > 또는 $params['<NAME>'] 에 점의 오른쪽에 있는 dot 문자(..)가 포함되어 있는 경우 점의 오른쪽에 있는 이름의 일부가 추출되지 않았습니다. 예를 들어 $params["org.ipsum.lorem"] 에서 org 만 추출되었습니다.

    이번 업데이트에서는 $params 가 전체 값을 가져오도록 문제를 해결합니다. 예를 들어 $params["org.ipsum.lorem"] 및 $params['org.ipsum.lorem'] 이 유효하고 전체 < NAME > , org.ipsum.lorem ]이 추출됩니다.

    < NAME >이 single 또는 double quotes로 묶지 않은 경우에도 오류가 발생합니다. 예를 들어 $params.org.ipsum.lorem 은 유효하지 않으며 유효성 검사 오류를 생성합니다.

  • 이번 업데이트를 통해 Trigger 리소스는 사용자 정의 인터셉터 서비스 포트를 지원하고 사용자 정의 인터셉터 서비스의 포트가 ClusterInterceptor 정의 파일의 포트와 동일한지 확인합니다.
  • 이번 업데이트 이전에는 Tekton Chains 및 Operator 구성 요소에 대한 tkn version 명령이 제대로 작동하지 않았습니다. 이번 업데이트에서는 명령이 올바르게 작동하도록 문제를 수정하고 해당 구성 요소의 버전 정보를 반환합니다.
  • 이번 업데이트 이전에는 tkn pr delete --ignore-running 명령을 실행하고 pipeline 실행에 status.condition 값이 없는 경우 tkn CLI 툴에 null-pointer 오류가 발생했습니다. 이번 업데이트에서는 CLI 툴에서 오류가 생성되고 여전히 실행 중인 파이프라인 실행을 올바르게 무시하도록 문제가 해결되었습니다.
  • 이번 업데이트 이전에는 tkn pr delete --keep <value > 또는 tkn tr delete --keep <value > 명령을 사용하고 파이프라인 실행 또는 작업 실행 수가 값보다 작으면 명령에서 오류가 예상대로 반환되지 않았습니다. 이번 업데이트에서는 문제가 해결되어 명령에서 이러한 조건에서 오류를 올바르게 반환합니다.
  • 이번 업데이트 이전에는 tkn pr delete 또는 tkn tr delete 명령을 --ignore-running 플래그와 함께 -p 또는 -t 플래그와 함께 사용하면 명령이 실행 중 또는 보류 중인 리소스를 잘못 삭제한 것입니다. 이번 업데이트에서는 이러한 명령이 실행 중 또는 보류 중인 리소스를 올바르게 무시하도록 문제가 해결되었습니다.
  • 이번 업데이트를 통해 TektonChain 사용자 정의 리소스를 사용하여 Tekton Chains를 구성할 수 있습니다. 이 기능을 사용하면 chain-config 구성 맵과 달리 업그레이드 후 구성을 유지할 수 있으며 업그레이드 중에 덮어쓸 수 있습니다.
  • 이번 업데이트를 통해 buildah 및 s2i 클러스터 작업을 제외하고 ClusterTask 리소스가 기본적으로 root로 실행되지 않습니다.
  • 이번 업데이트 이전에는 init 를 첫 번째 인수로 사용하고 두 개 이상의 인수를 사용할 때 Red Hat OpenShift Pipelines 1.7.1의 작업이 실패했습니다. 이번 업데이트를 통해 플래그가 올바르게 구문 분석되고 작업 실행이 성공적으로 수행됩니다.

  • 이번 업데이트 이전에는 다음 오류 메시지와 함께 OpenShift Container Platform 4.9 및 4.10에 Red Hat OpenShift Pipelines Operator를 설치할 때 유효하지 않은 역할 바인딩으로 인해 실패했습니다. 

    error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io
"openshift-operators-prometheus-k8s-read-binding" is invalid:
roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef

    이번 업데이트에서는 문제가 해결되어 더 이상 오류가 발생하지 않습니다.

  • 이전 버전에서는 Red Hat OpenShift Pipelines Operator 업그레이드로 인해 pipeline 서비스 계정이 다시 생성되어 서비스 계정에 연결된 시크릿이 손실되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 업그레이드하는 동안 Operator는 더 이상 pipeline 서비스 계정을 다시 생성하지 않습니다. 결과적으로 파이프라인 서비스 계정에 연결된 시크릿은 업그레이드 후에도 유지되며 리소스(tasks 및 파이프라인)는 계속 올바르게 작동합니다.
  • 이번 업데이트를 통해 인프라 노드 설정이 TektonConfig CR(사용자 정의 리소스)에 구성된 경우 Pipeline as Code Pod가 인프라 노드에서 실행됩니다.

  • 이전에는 resource pruner를 사용하여 각 네임스페이스 Operator에서 별도의 컨테이너에서 실행한 명령을 생성했습니다. 이 설계에서는 많은 네임스페이스가 있는 클러스터에서 리소스가 너무 많이 사용되었습니다. 예를 들어 단일 명령을 실행하려면 Pod에서 1000개의 컨테이너가 생성된 네임스페이스가 1000개인 클러스터입니다.

    이번 업데이트에서는 이 문제가 해결되었습니다. 모든 명령이 루프에서 하나의 컨테이너에서 실행되도록 네임스페이스 기반 구성을 작업에 전달합니다.

  • Tekton Chains에서 작업 및 이미지에 사용되는 키를 유지하려면 signing-secrets 라는 시크릿을 정의해야 합니다. 그러나 이번 업데이트 이전에는 Red Hat OpenShift Pipelines Operator를 업데이트하여 이 시크릿을 재설정하거나 덮어쓰고 키가 손실되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 이제 Operator를 통해 Tekton Chains를 설치한 후 시크릿을 구성한 경우 보안이 유지되고 업그레이드로 인해 덮어쓰지 않습니다.

  • 이번 업데이트 이전에는 다음 메시지와 유사한 오류로 인해 모든 S2I 빌드 작업이 실패했습니다. 

    Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted
time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted"
time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"

    이번 업데이트를 통해 pipelines-scc SCC(보안 컨텍스트 제약 조건)는 Buildah 및 S2I 클러스터 작업에 필요한 SETFCAP 기능과 호환됩니다. 결과적으로 Buildah 및 S2I 빌드 작업이 성공적으로 실행될 수 있습니다.

    다양한 언어 및 프레임워크로 작성된 애플리케이션에 대해 Buildah 클러스터 작업 및 S2I 빌드 작업을 성공적으로 실행하려면 빌드 및 푸시 와 같은 적절한 단계에 대해 다음 스니펫을 추가합니다. 

    securityContext:
  capabilities:
    add: ["SETFCAP"]
  • 이번 업데이트 이전에는 Red Hat OpenShift Pipelines Operator를 설치하는 데 예상보다 오래 걸렸습니다. 이번 업데이트에서는 일부 설정을 최적화하여 설치 프로세스 속도를 높입니다.
  • 이번 업데이트를 통해 Buildah 및 S2I 클러스터 작업은 이전 버전보다 적은 단계를 갖습니다. 일부 단계는 ResourceQuota 및 LimitRange 오브젝트에서 더 잘 작동하도록 단일 단계로 결합되었으며 필요한 것보다 더 많은 리소스가 필요하지 않습니다.
  • 이번 업데이트에서는 클러스터 작업에서 Buildah, tkn CLI 툴 및 skopeo CLI 툴 버전을 업그레이드합니다.
  • 이번 업데이트 이전에는 네임스페이스가 Terminating 상태인 경우 RBAC 리소스를 생성할 때 Operator가 실패했습니다. 이번 업데이트를 통해 Operator는 Terminating 상태의 네임스페이스를 무시하고 RBAC 리소스를 생성합니다.
  • 이번 업데이트 이전에는 정리 cronjobs의 Pod가 예상대로 인프라 노드에 예약되지 않았습니다. 대신 작업자 노드에 예약되었거나 전혀 예약되지 않았습니다. 이번 업데이트를 통해 TektonConfig CR(사용자 정의 리소스)에 구성된 경우 이러한 유형의 Pod를 인프라 노드에 예약할 수 있습니다.

3.1.6.6. Red Hat OpenShift Pipelines General Availability 1.8.1 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.10, 4.11, 4.12에서 Red Hat OpenShift Pipelines General Availability (GA) 1.8.1을 사용할 수 있습니다.

3.1.6.6.1. 확인된 문제

  • 기본적으로 컨테이너는 보안을 강화하기 위해 권한을 제한합니다. 제한된 권한은 Red Hat OpenShift Pipelines Operator의 모든 컨트롤러 Pod 및 일부 클러스터 작업에 적용됩니다. 제한된 권한으로 인해 특정 구성에서 git-clone 클러스터 작업이 실패합니다.

    해결방법: 없음. SRVKP-2634 문제를 추적할 수 있습니다.

  • 설치 프로그램 세트가 failed 상태인 경우 TektonConfig 사용자 지정 리소스의 상태가 False 대신 True 로 잘못 표시됩니다.

    예: 실패한 설치 프로그램 세트

    $ oc get tektoninstallerset
NAME                                     READY   REASON
addon-clustertasks-nx5xz                 False   Error
addon-communityclustertasks-cfb2p        True
addon-consolecli-ftrb8                   True
addon-openshift-67dj2                    True
addon-pac-cf7pz                          True
addon-pipelines-fvllm                    True
addon-triggers-b2wtt                     True
addon-versioned-clustertasks-1-8-hqhnw   False   Error
pipeline-w75ww                           True
postpipeline-lrs22                       True
prepipeline-ldlhw                        True
rhosp-rbac-4dmgb                         True
trigger-hfg64                            True
validating-mutating-webhoook-28rf7       True

    예: In incorrect TektonConfig status

    $ oc get tektonconfig config
NAME     VERSION   READY   REASON
config   1.8.1     True

3.1.6.6.2. 해결된 문제
  • 이번 업데이트 이전에는 실행 중인 파이프라인의 정리 작업 실행 작업이 다음 경고를 표시했습니다. 일부 작업은 완료되지 않고 완료된 것으로 표시되었습니다. 이번 업데이트를 통해 정리기에서 파이프라인 실행의 일부인 작업을 유지합니다.
  • 이번 업데이트 이전에는 pipeline-1.8 이 Red Hat OpenShift Pipelines Operator 1.8.x를 설치하기 위한 기본 채널이었습니다. 이번 업데이트를 통해 latest 가 기본 채널입니다.
  • 이번 업데이트 이전에는 Pipeline as Code 컨트롤러 Pod가 사용자가 노출한 인증서에 액세스할 수 없었습니다. 이번 업데이트를 통해 Pipeline as Code는 자체 서명된 또는 사용자 정의 인증서로 보호되는 경로 및 Git 리포지토리에 액세스할 수 있습니다.
  • 이번 업데이트 이전에는 Red Hat OpenShift Pipelines 1.7.2에서 1.8.0으로 업그레이드한 후 RBAC 오류로 인해 작업이 실패했습니다. 이번 업데이트를 통해 RBAC 오류 없이 작업이 성공적으로 실행됩니다.
  • 이번 업데이트 이전에는 tkn CLI 툴을 사용하여 유형이 배열된 결과 오브젝트가 포함된 작업 실행 및 파이프라인 실행을 제거할 수 없었습니다. 이번 업데이트를 통해 tkn CLI 툴을 사용하여 유형이 배열된 결과 오브젝트가 포함된 작업 실행 및 파이프라인 실행을 제거할 수 있습니다.
  • 이번 업데이트 이전에는 파이프라인 사양에 배열 유형의 ENV_VARS 매개변수가 있는 작업이 포함된 경우, pipeline run failed with the following error: invalid input params for task func-buildpacks: param types do not match the user-specified type: [ENV_VARS]. 이번 업데이트를 통해 이러한 파이프라인 및 작업 사양을 사용하여 파이프라인 실행이 실패하지 않습니다.
  • 이번 업데이트 이전에는 클러스터 관리자가 컨테이너 레지스트리에 액세스하기 위한 Buildah 클러스터 작업에 config.json 파일을 제공할 수 없었습니다. 이번 업데이트를 통해 클러스터 관리자는 dockerconfig 작업 공간을 사용하여 Buildah 클러스터 작업을 config.json 파일로 제공할 수 있습니다.

3.1.6.7. Red Hat OpenShift Pipelines General Availability 1.8.2 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.10, 4.11, 4.12에서 Red Hat OpenShift Pipelines General Availability (GA) 1.8.2를 사용할 수 있습니다.

3.1.6.7.1. 해결된 문제
  • 이번 업데이트 이전에는 SSH 키를 사용하여 리포지토리를 복제할 때 git-clone 작업이 실패했습니다. 이번 업데이트를 통해 git-init 작업에서 root가 아닌 사용자의 역할이 제거되고 SSH 프로그램은 $HOME/.ssh/ 디렉터리에서 올바른 키를 찾습니다.

3.1.7. Red Hat OpenShift Pipelines General Availability 1.7 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.9, 4.10, 4.11에서 Red Hat OpenShift Pipelines General Availability (GA) 1.7을 사용할 수 있습니다.

3.1.7.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.7의 새로운 기능도 소개합니다.

3.1.7.1.1. 파이프라인

  • 이번 업데이트를 통해 pipelines-<version >은 Red Hat OpenShift Pipelines Operator를 설치하는 기본 채널입니다. 예를 들어 OpenShift Pipelines Operator 버전 1.7 을 설치할 기본 채널은 pipelines-1.7 입니다. 클러스터 관리자는 최신 채널을 사용하여 최신 버전의 Operator를 설치할 수도 있습니다.

    참고

    preview 및 stable 채널은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.

  • 사용자 네임스페이스에서 명령을 실행하면 컨테이너가 root (사용자 ID 0)로 실행되지만 호스트에서 사용자 권한이 있습니다. 이번 업데이트를 통해 사용자 네임스페이스에서 Pod를 실행하려면 CRI-O 에 필요한 주석을 전달해야 합니다.

    • 모든 사용자에 대해 이러한 주석을 추가하려면 oc edit clustertask buildah 명령을 실행하고 buildah 클러스터 작업을 편집합니다.
    • 특정 네임스페이스에 주석을 추가하려면 클러스터 작업을 해당 네임스페이스에 작업으로 내보냅니다.

  • 이번 업데이트 이전에는 특정 조건이 충족되지 않은 경우 when 표현식에서 Task 오브젝트 및 해당 종속 작업을 건너뜁니다. 이번 업데이트를 통해 종속 작업이 아닌 Task 오브젝트만 보호하도록 when 표현식의 범위를 지정할 수 있습니다. 이 업데이트를 활성화하려면 TektonConfig CRD에서 scope-when-expressions-to-task 플래그를 true 로 설정합니다.

    참고

    scope-when-expressions-to-task 플래그는 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. OpenShift Pipelines의 모범 사례로, when 표현식 범위가 보호된 Task 로만 사용됩니다.

  • 이번 업데이트를 통해 작업 내의 작업 공간의 subPath 필드에 변수 대체를 사용할 수 있습니다.

  • 이번 업데이트를 통해 작은 따옴표 또는 이중 따옴표로 대괄호 표기법을 사용하여 매개변수와 결과를 참조할 수 있습니다. 이 업데이트 이전에는 점 표기법만 사용할 수 있었습니다. 예를 들어 다음은 다음과 같습니다.

    • $(param.myparam), $(param['myparam']), $(param["myparam"]).

      작은 따옴표 또는 이중 따옴표를 사용하여 문제가 있는 문자(예: ".")가 포함된 매개변수 이름을 묶을 수 있습니다. 예를 들면 $(param['my.param']) 및 $(param["my.param"]) 가 있습니다.

  • 이번 업데이트를 통해 enable-api-fields 플래그를 활성화하지 않고 작업 정의에 단계의 onError 매개변수를 포함할 수 있습니다.
3.1.7.1.2. Trigger
  • 이번 업데이트를 통해 feature-flag-triggers 구성 맵에 새 필드 labels-exclusion-pattern 이 있습니다. 이 필드의 값을 정규식(regex) 패턴으로 설정할 수 있습니다. 컨트롤러는 정규 표현식 패턴과 일치하는 라벨을 필터링하여 이벤트 리스너에서 이벤트 리스너에 대해 생성된 리소스로 전파합니다.
  • 이번 업데이트를 통해 TriggerGroups 필드가 EventListener 사양에 추가됩니다. 이 필드를 사용하여 트리거 그룹을 선택하고 실행하기 전에 실행할 인터셉터 세트를 지정할 수 있습니다. 이 기능을 활성화하려면 pipeline 섹션의 TektonConfig 사용자 지정 리소스 정의에서 enable-api-fields 필드를 alpha 로 설정해야 합니다.
  • 이번 업데이트를 통해 Trigger 리소스는 TriggerTemplate 템플릿에 정의된 사용자 정의 실행을 지원합니다.
  • 이번 업데이트를 통해 Triggers는 EventListener Pod에서 Kubernetes 이벤트를 발송할 수 있도록 지원합니다.
  • 이번 업데이트를 통해 ClusterInteceptor,EventListener,TriggerTemplate,ClusterTriggerBinding, TriggerBinding , TriggerBinding 오브젝트에 개수 메트릭을 사용할 수 있습니다.
  • 이번 업데이트에서는 Kubernetes 리소스에 ServicePort 사양이 추가되었습니다. 이 사양을 사용하여 이벤트 리스너 서비스를 노출하는 포트를 수정할 수 있습니다. 기본 포트는 8080 입니다.
  • 이번 업데이트를 통해 EventListener 사양의 targetURI 필드를 사용하여 트리거 처리 중에 클라우드 이벤트를 보낼 수 있습니다. 이 기능을 활성화하려면 pipeline 섹션의 TektonConfig 사용자 지정 리소스 정의에서 enable-api-fields 필드를 alpha 로 설정해야 합니다.
  • 이번 업데이트를 통해 tekton-triggers-eventlistener-roles 오브젝트에 이미 존재하는 create 동사 외에 패치 동사가 있습니다.
  • 이번 업데이트를 통해 securityContext.runAsUser 매개변수가 이벤트 리스너 배포에서 제거됩니다.
3.1.7.1.3. CLI

  • 이번 업데이트를 통해 tkn [pipeline | pipelinerun] 내보내기 명령은 파이프라인 또는 파이프라인 실행을 YAML 파일로 내보냅니다. 예를 들면 다음과 같습니다.

    • openshift-pipelines 네임스페이스에서 test_pipeline 이라는 파이프라인을 내보냅니다. 

      $ tkn pipeline export test_pipeline -n openshift-pipelines

    • openshift-pipelines 네임스페이스에서 test_pipeline_run 이라는 파이프라인 실행을 내보냅니다. 

      $ tkn pipelinerun export test_pipeline_run -n openshift-pipelines
  • 이번 업데이트를 통해 tkn pipelinerun cancel 에 --grace 옵션이 추가됩니다. --grace 옵션을 사용하여 종료를 강제 적용하는 대신 파이프라인 실행을 정상적으로 종료합니다. 이 기능을 활성화하려면 pipeline 섹션의 TektonConfig 사용자 지정 리소스 정의에서 enable-api-fields 필드를 alpha 로 설정해야 합니다.

  • 이번 업데이트에서는 tkn version 명령의 출력에 Operator 및 Chains 버전이 추가되었습니다.

    중요

    Tekton Chains는 기술 프리뷰 기능입니다.

  • 이번 업데이트를 통해 파이프라인 실행을 취소할 때 tkn pipelinerun describe 명령으로 취소된 모든 작업 실행을 표시합니다. 이번 수정 이전에는 하나의 작업 실행만 표시되었습니다.
  • 이번 업데이트를 통해 tkn [t | p | ct] start 명령을 --skip-optional-workspace 플래그를 사용하여 건너뛸 때 선택적 작업 공간에 대한 요청 사양 공급을 건너뛸 수 있습니다. 대화형 모드에서 실행할 때 건너뛸 수도 있습니다.

  • 이번 업데이트를 통해 tkn chain 명령을 사용하여 Tekton Chains를 관리할 수 있습니다. --chains-namespace 옵션을 사용하여 Tekton Chains를 설치할 네임스페이스를 지정할 수도 있습니다.

    중요

    Tekton Chains는 기술 프리뷰 기능입니다.

3.1.7.1.4. Operator

  • 이번 업데이트를 통해 Red Hat OpenShift Pipelines Operator를 사용하여 Tekton Hub 및 Tekton Chains를 설치 및 배포할 수 있습니다.

    중요

    Tekton Chains and deployment of Tekton Hub on a cluster는 기술 프리뷰 기능입니다.

  • 이번 업데이트를 통해 Pipeline을 코드(PAC)를 애드온 옵션으로 찾아 사용할 수 있습니다.

    중요

    코드로서의 파이프라인은 기술 프리뷰 기능입니다.

  • 이번 업데이트를 통해 communityClusterTasks 매개변수를 false 로 설정하여 커뮤니티 클러스터 작업 설치를 비활성화할 수 있습니다. 예를 들면 다음과 같습니다. 

    ...
spec:
  profile: all
  targetNamespace: openshift-pipelines
  addon:
    params:
    - name: clusterTasks
      value: "true"
    - name: pipelineTemplates
      value: "true"
    - name: communityClusterTasks
      value: "false"
...

  • 이번 업데이트를 통해 TektonConfig 사용자 지정 리소스의 enable-devconsole-integration 플래그를 false 로 설정하여 Developer 관점과 Tekton Hub의 통합을 비활성화할 수 있습니다. 예를 들면 다음과 같습니다. 

    ...
hub:
  params:
    - name: enable-devconsole-integration
      value: "true"
...
  • 이번 업데이트를 통해 operator-config.yaml 구성 맵을 사용하면 tkn version 명령의 출력이 Operator 버전을 표시할 수 있습니다.
  • 이번 업데이트를 통해 argocd-task-sync-and-wait 작업 버전이 v0.2 로 수정됩니다.
  • TektonConfig CRD로 업데이트되면 oc get tektonconfig 명령이ECDHEerator 버전을 표시합니다.
  • 이번 업데이트를 통해 Triggers 메트릭에 서비스 모니터가 추가되었습니다.
3.1.7.1.5. hub
중요

클러스터에 Tekton Hub를 배포하는 것은 기술 프리뷰 기능입니다.

Tekton Hub를 사용하면 CI/CD 워크플로에 사용할 수 있는 작업과 파이프라인을 검색, 검색 및 공유할 수 있습니다. Tekton Hub의 공용 인스턴스는 hub.tekton.dev 에서 사용할 수 있습니다.

Red Hat OpenShift Pipelines 1.7을 사용하면 클러스터 관리자가 엔터프라이즈 클러스터에 Tekton Hub의 사용자 지정 인스턴스를 설치하고 배포할 수 있습니다. 조직과 관련된 재사용 가능한 작업 및 파이프라인으로 카탈로그를 큐레이팅할 수 있습니다.

3.1.7.1.6. 체인
중요

Tekton Chains는 기술 프리뷰 기능입니다.

Tekton Chains는 Kubernetes CRD(Custom Resource Definition) 컨트롤러입니다. 이를 사용하여 Red Hat OpenShift Pipelines를 사용하여 생성된 작업 및 파이프라인의 공급망 보안을 관리할 수 있습니다.

기본적으로 Tekton Chains는 OpenShift Container Platform 클러스터에서 작업 실행을 모니터링합니다. 체인은 완료된 작업 실행의 스냅샷을 가져와서 하나 이상의 표준 페이로드 형식으로 변환하고 모든 아티팩트를 서명 및 저장합니다.

Tekton Chains는 다음 기능을 지원합니다.

  • 공동 서명과 같은 암호화 키 유형 및 서비스를 사용하여 작업 실행, 작업 실행 결과, OCI 레지스트리 이미지에 서명 할 수 있습니다.
  • in-toto 와 같은 증명 형식을 사용할 수 있습니다.
  • OCI 리포지토리를 스토리지 백엔드로 사용하여 서명 및 서명된 아티팩트를 안전하게 저장할 수 있습니다.
3.1.7.1.7. Pipeline as Code (PAC)
중요

코드로서의 파이프라인은 기술 프리뷰 기능입니다.

Pipeline을 Code로 사용하면 클러스터 관리자와 필요한 권한이 있는 사용자는 파이프라인 템플릿을 소스 코드 Git 리포지토리의 일부로 정의할 수 있습니다. 소스 코드 내보내기 또는 구성된 Git 리포지토리에 대한 가져오기 요청에 의해 트리거되면 기능은 파이프라인을 실행하고 상태를 보고합니다.

코드로서의 파이프라인은 다음과 같은 기능을 지원합니다.

  • 요청 상태를 가져옵니다. 가져오기 요청을 반복할 때 Git 리포지토리를 호스팅하는 플랫폼에서 가져오기 요청의 상태 및 제어가 수행됩니다.
  • GitHub에서 다시 점검을 포함하여 파이프라인 실행 상태를 설정하는 API를 확인합니다.
  • GitHub pull request 및 commit events
  • /retest 와 같은 주석으로 요청 작업을 가져옵니다.
  • Git 이벤트 필터링 및 각 이벤트에 대한 별도의 파이프라인.
  • 로컬 작업, Tekton Hub 및 원격 URL을 위한 OpenShift Pipelines의 자동 작업 확인
  • 구성 검색에 GitHub Blob 및 오브젝트 API를 사용합니다.
  • GitHub 조직을 통한 액세스 제어 목록(ACL) 또는 Prow 스타일 OWNER 파일을 사용합니다.
  • tkn CLI 툴용 tkn pac 플러그인은 파이프라인을 코드 리포지토리로 관리하고 부트스트랩하는 데 사용할 수 있습니다.
  • GitHub Application, GitHub Webhook, Bitbucket Server 및 Bitbucket Cloud 지원

3.1.7.2. 더 이상 사용되지 않는 기능

  • 변경 중단: 이번 업데이트에서는 TektonConfig CR(사용자 정의 리소스)에서 disable-working-directory-overwrite 및 disable-home-env-overwrite 필드가 제거됩니다. 결과적으로 TektonConfig CR에서 더 이상 $HOME 환경 변수 및 workingDir 매개변수를 자동으로 설정하지 않습니다. Task CRD(사용자 정의 리소스 정의)에서 env 및 workingDir 필드를 사용하여 $HOME 환경 변수 및 workingDir 매개변수를 설정할 수 있습니다.
  • Conditions CRD(사용자 정의 리소스 정의) 유형은 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. 대신 권장되는 When 표현식을 사용합니다.
  • 변경 중단: Triggers 리소스는 템플릿을 검증하고 EventListener 및 TriggerBinding 값을 지정하지 않으면 오류가 발생합니다.

3.1.7.3. 확인된 문제

  • Maven 및 Jib-Maven 클러스터 작업을 실행하는 경우 기본 컨테이너 이미지는 Intel (x86) 아키텍처에서만 지원됩니다. 따라서 작업은 ARM, IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x) 클러스터에서 실패합니다. 이 문제를 해결하려면 MAVEN_IMAGE 매개변수 값을 maven:3.6.3-adoptopenjdk-11 로 설정하여 사용자 정의 이미지를 지정할 수 있습니다.

    작은 정보

    tkn hub 를 사용하여 ARM, IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x)을 기반으로 하는 작업을 설치하기 전에 이러한 플랫폼에서 작업을 실행할 수 있는지 확인합니다. 작업 정보의 "Platforms" 섹션에 ppc64le 및 s390x 가 나열되어 있는지 확인하려면 tkn hub info task <name> 명령을 실행할 수 있습니다.

  • IBM Power Systems, IBM Z 및 LinuxONE에서는 s2i-dotnet 클러스터 작업이 지원되지 않습니다.

  • nodejs:14-ubi8-minimal 이미지 스트림을 사용할 수 없습니다. 이렇게 하면 다음과 같은 오류가 생성됩니다. 

    STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"
  • 암시적 매개변수 매핑은 최상위 Pipeline 또는 PipelineRun 정의의 매개변수를 taskRef 작업으로 잘못 전달합니다. 매핑은 최상위 리소스에서 인라인 taskSpec 사양이 있는 작업에만 적용되어야 합니다. 이 문제는 TektonConfig 사용자 정의 리소스 정의의 pipeline 섹션에서 enable-api-fields 필드를 alpha 로 설정하여 이 기능을 활성화한 클러스터에만 영향을 미칩니다.

3.1.7.4. 해결된 문제

  • 이번 업데이트를 통해 Pipeline 및 PipelineRun 오브젝트 정의 모두에 레이블 및 주석 과 같은 메타데이터가 있는 경우 PipelineRun 유형의 값이 우선합니다. Task 및 TaskRun 오브젝트에 대한 유사한 동작을 확인할 수 있습니다.
  • 이번 업데이트를 통해 timeouts.tasks 필드 또는 timeouts.finally 필드가 0 으로 설정된 경우 timeouts.pipeline 도 0 으로 설정됩니다.
  • 이번 업데이트를 통해hebang을 사용하지 않는 스크립트에서 -x set 플래그가 제거됩니다. 수정을 통해 스크립트 실행으로 데이터 누수를 줄일 수 있습니다.
  • 이번 업데이트를 통해 Git 자격 증명의 사용자 이름에 있는 백슬래시 문자가 .gitconfig 파일에 추가 백슬래시로 이스케이프됩니다.
  • 이번 업데이트를 통해 로깅 및 구성 맵을 정리하는 데 EventListener 오브젝트의 종료자 속성이 필요하지 않습니다.
  • 이번 업데이트를 통해 이벤트 리스너 서버와 연결된 기본 HTTP 클라이언트가 제거되고 사용자 정의 HTTP 클라이언트가 추가되었습니다. 결과적으로 시간 초과가 개선되었습니다.
  • 이번 업데이트를 통해 Triggers 클러스터 역할이 이제 소유자 참조에서 작동합니다.
  • 이번 업데이트를 통해 여러 인터셉터에서 확장을 반환할 때 이벤트 리스너의 경합 조건이 발생하지 않습니다.
  • 이번 업데이트를 통해 tkn pr delete 명령에서 ignore-running 플래그를 사용하여 파이프라인 실행을 삭제하지 않습니다.
  • 이번 업데이트를 통해 애드온 매개변수를 수정할 때 Operator Pod가 다시 시작되지 않습니다.
  • 이번 업데이트를 통해 서브스크립션 및 구성 사용자 정의 리소스에 구성되지 않은 경우 tkn service CLI Pod가 인프라 노드에 예약됩니다.
  • 이번 업데이트를 통해 지정된 버전의 클러스터 작업은 업그레이드 중에 삭제되지 않습니다.

3.1.7.5. Red Hat OpenShift Pipelines General Availability 1.7.1 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.9, 4.10, 4.11에서 Red Hat OpenShift Pipelines General Availability (GA) 1.7.1을 사용할 수 있습니다.

3.1.7.5.1. 해결된 문제
  • 이번 업데이트 이전에는 Red Hat OpenShift Pipelines Operator를 업그레이드하면 Tekton Hub와 연결된 데이터베이스의 데이터가 삭제되어 새 데이터베이스가 설치되었습니다. 이번 업데이트를 통해 Operator 업그레이드에서 데이터를 유지합니다.
  • 이번 업데이트 이전에는 클러스터 관리자만 OpenShift Container Platform 콘솔의 파이프라인 메트릭에 액세스할 수 있었습니다. 이번 업데이트를 통해 다른 클러스터 역할이 있는 사용자도 파이프라인 메트릭에 액세스할 수 있습니다.
  • 이번 업데이트 이전에는 대규모 종료 메시지를 내보내는 작업이 포함된 파이프라인 실행에 실패했습니다. Pod에 있는 모든 컨테이너의 종료 메시지의 총 크기는 12KB를 초과할 수 없기 때문에 파이프라인 실행이 실패했습니다. 이번 업데이트를 통해 동일한 이미지를 사용하는 place-tools 및 step-init 초기화 컨테이너가 병합되어 각 작업의 Pod에서 실행되는 컨테이너 수를 줄입니다. 이 솔루션을 사용하면 작업 Pod에서 실행되는 컨테이너 수를 최소화하여 파이프라인 실행 가능성을 줄일 수 있습니다. 그러나 종료 메시지의 최대 허용 크기의 제한은 제거되지 않습니다.
  • 이번 업데이트 이전에는 Tekton Hub 웹 콘솔에서 직접 리소스 URL에 액세스하려고 하면 Nginx 404 오류가 발생했습니다. 이번 업데이트를 통해 Tekton Hub 웹 콘솔 이미지가 수정되어 Tekton Hub 웹 콘솔에서 직접 리소스 URL에 액세스할 수 있습니다.
  • 이번 업데이트 이전에는 각 네임스페이스에 대해 리소스 정리기 작업에서 리소스를 정리할 별도의 컨테이너를 생성했습니다. 이번 업데이트를 통해 리소스 정리기 작업은 하나의 컨테이너에서 모든 네임스페이스에 대해 루프로 명령을 실행합니다.

3.1.7.6. Red Hat OpenShift Pipelines General Availability 1.7.2 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.9, 4.10 및 향후 버전에서 Red Hat OpenShift Pipelines General Availability (GA) 1.7.2를 사용할 수 있습니다.

3.1.7.6.1. 확인된 문제
  • openshift -pipelines 네임스페이스의 Tekton Chains의 chain-config 구성 맵은 Red Hat OpenShift Pipelines Operator를 업그레이드한 후 default로 자동 재설정됩니다. 현재 이 문제에 대한 해결방법이 없습니다.
3.1.7.6.2. 해결된 문제
  • 이번 업데이트 이전에는 OpenShift Pipelines 1.7.1의 작업이 첫 번째 인수로 init 를 사용한 다음 두 개 이상의 인수를 사용하지 못했습니다. 이번 업데이트를 통해 플래그가 올바르게 구문 분석되고 작업 실행이 성공적으로 수행됩니다.

  • 이번 업데이트 이전에는 다음 오류 메시지와 함께 OpenShift Container Platform 4.9 및 4.10에 Red Hat OpenShift Pipelines Operator를 설치하지 못했습니다. 

    error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io "openshift-operators-prometheus-k8s-read-binding" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef

    이번 업데이트를 통해 Red Hat OpenShift Pipelines Operator가 별도의 역할 바인딩 네임스페이스와 함께 설치하여 다른 Operator 설치와 충돌하지 않습니다.

  • 이번 업데이트 이전에는 Operator를 업그레이드하면 Tekton Chains의 signing-secrets secret 키가 기본값으로 재설정되었습니다. 이번 업데이트를 통해 Operator를 업그레이드한 후에도 사용자 정의 시크릿 키가 유지됩니다.

    참고

    Red Hat OpenShift Pipelines 1.7.2로 업그레이드하면 키가 재설정됩니다. 그러나 향후 릴리스로 업그레이드할 때 키는 계속될 것으로 예상됩니다.

  • 이번 업데이트 이전에는 다음 메시지와 유사한 오류로 인해 모든 S2I 빌드 작업이 실패했습니다. 

    Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted
time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted"
time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"

    이번 업데이트를 통해 pipelines-scc SCC(보안 컨텍스트 제약 조건)는 Buildah 및 S2I 클러스터 작업에 필요한 SETFCAP 기능과 호환됩니다. 결과적으로 Buildah 및 S2I 빌드 작업이 성공적으로 실행될 수 있습니다.

    다양한 언어 및 프레임워크로 작성된 애플리케이션에 대해 Buildah 클러스터 작업 및 S2I 빌드 작업을 성공적으로 실행하려면 빌드 및 푸시 와 같은 적절한 단계에 대해 다음 스니펫을 추가합니다. 

    securityContext:
  capabilities:
    add: ["SETFCAP"]

3.1.7.7. Red Hat OpenShift Pipelines General Availability 1.7.3 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.9, 4.10, 4.11에서 Red Hat OpenShift Pipelines General Availability (GA) 1.7.3을 사용할 수 있습니다.

3.1.7.7.1. 해결된 문제
  • 이번 업데이트 이전에는 네임스페이스가 Terminating 상태인 경우 RBAC 리소스를 생성할 때 Operator가 실패했습니다. 이번 업데이트를 통해 Operator는 Terminating 상태의 네임스페이스를 무시하고 RBAC 리소스를 생성합니다.
  • 이전 버전에서는 Red Hat OpenShift Pipelines Operator 업그레이드로 인해 pipeline 서비스 계정이 다시 생성되어 서비스 계정에 연결된 시크릿이 손실되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 업그레이드하는 동안 Operator는 더 이상 pipeline 서비스 계정을 다시 생성하지 않습니다. 결과적으로 파이프라인 서비스 계정에 연결된 시크릿은 업그레이드 후에도 유지되며 리소스(tasks 및 파이프라인)는 계속 올바르게 작동합니다.

3.1.8. Red Hat OpenShift Pipelines General Availability 1.6 릴리스 정보

이번 업데이트를 통해 OpenShift Container Platform 4.9에서 Red Hat OpenShift Pipelines General Availability (GA) 1.6을 사용할 수 있습니다.

3.1.8.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.6의 새로운 기능도 소개합니다.

  • 이번 업데이트를 통해 --output <string> , 여기서 <string>은 yaml 또는 json 을 사용하여 YAML 또는 JSON 형식의 문자열 을 반환하도록 pipeline 또는 task start 명령을 구성할 수 있습니다. 그렇지 않으면 --output 옵션 없이 다른 프로그램에서 구문 분석하기 어려운 사용자에게 친숙한 메시지를 반환합니다. YAML 또는 JSON 형식 문자열을 반환하는 것은 CI(지속적인 통합) 환경에 유용합니다. 예를 들어, 리소스가 생성되면 yq 또는 jq 를 사용하여 리소스에 대한 YAML 또는 JSON 형식의 메시지를 구문 분석하고 showlog 옵션을 사용하지 않고 해당 리소스가 종료될 때까지 기다릴 수 있습니다.
  • 이번 업데이트를 통해 Podman의 auth.json 인증 파일을 사용하여 레지스트리에 인증할 수 있습니다. 예를 들어, tkn bundle push 를 사용하여 Docker CLI 대신 Podman을 사용하여 원격 레지스트리로 푸시할 수 있습니다.
  • 이번 업데이트를 통해 tkn [taskrun | pipelinerun] delete --all 명령을 사용하는 경우 새 --keep-since <minutes > 옵션을 사용하여 지정된 수 분 이내의 실행을 유지할 수 있습니다. 예를 들어, 5분 미만의 실행을 유지하려면 tkn [taskrun | pipelinerun] delete -all --keep-since 5 를 입력합니다.
  • 이번 업데이트를 통해 작업 실행 또는 파이프라인 실행을 삭제할 때 --parent-resource 및 --keep-since 옵션을 함께 사용할 수 있습니다. 예를 들어 tkn pipelinerun delete --pipeline pipelinename --keep-since 5 명령은 상위 리소스의 이름이 pipelinename 이고 기간이 5분 이하인 파이프라인 실행을 유지합니다. tkn tr delete -t <taskname> --keep-since 5 및 tkn tr delete --clustertask <taskname> --keep-since 5 명령이 작업 실행에 유사하게 작동합니다.
  • 이번 업데이트에서는 트리거 리소스가 v1beta1 리소스로 작동하도록 지원을 추가합니다.
  • 이번 업데이트에서는 tkn pipelinerun delete 및 tkn taskrun delete 명령에 ignore-running 옵션이 추가되었습니다.
  • 이번 업데이트에서는 tkn 작업 및 tkn clustertask 명령에 create 하위 명령이 추가되었습니다.
  • 이번 업데이트를 통해 tkn pipelinerun delete --all 명령을 사용할 때 new --label <string > 옵션을 사용하여 파이프라인 실행을 라벨별로 필터링할 수 있습니다. 선택적으로 = 및 == 를 같음 연산자로 사용하거나 != 을 operator로 사용할 수 있습니다. 예를 들어 tkn pipelinerun delete --all --label asdf 및 tkn pipelinerun delete --all --label==asdf 명령 모두 asdf 레이블이 있는 모든 파이프라인 실행을 삭제합니다.
  • 이번 업데이트를 통해 구성 맵에서 설치된 Tekton 구성 요소 버전을 가져오거나 배포 컨트롤러에서 구성 맵이 없으면 해당 구성 맵을 가져올 수 있습니다.
  • 이번 업데이트를 통해 트리거는 feature-flags 및 config-defaults 구성 맵을 지원하여 기능 플래그를 구성하고 기본값을 각각 설정합니다.
  • 이번 업데이트에서는 EventListener 리소스에서 수신한 이벤트를 계산하는 데 사용할 수 있는 새 메트릭 eventlistener_event_count 가 추가되었습니다.

  • 이번 업데이트에서는 v1beta1 Go API 유형이 추가되었습니다. 이번 업데이트를 통해 이제 트리거가 v1beta1 API 버전을 지원합니다.

    현재 릴리스에서는 v1alpha1 기능이 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 대신 v1beta1 기능을 사용하십시오.

  • 현재 릴리스에서는 리소스의 자동 실행이 기본적으로 활성화됩니다. 또한 다음 새 주석을 사용하여 각 네임스페이스에 대해 작업 실행 및 파이프라인 실행 자동 실행을 별도로 구성할 수 있습니다.

    • operator.tekton.dev/prune.schedule: 이 주석의 값이 TektonConfig 사용자 지정 리소스 정의에 지정된 값과 다른 경우 해당 네임스페이스의 새 cron 작업이 생성됩니다.
    • operator.tekton.dev/prune.skip: true 로 설정하면 구성된 네임스페이스가 실행되지 않습니다.
    • operator.tekton.dev/prune.resources: 이 주석에는 쉼표로 구분된 리소스 목록을 사용할 수 있습니다. 파이프라인 실행과 같은 단일 리소스를 정리하려면 이 주석을 "pipelinerun" 으로 설정합니다. 작업 실행 및 파이프라인 실행과 같은 여러 리소스를 정리하려면 이 주석을 "taskrun, pipelinerun" 으로 설정합니다.
    • operator.tekton.dev/prune.keep: 이 주석을 사용하여 prunning 없이 리소스를 유지합니다.

    • operator.tekton.dev/prune.keep-since: 이 주석을 사용하여 수명에 따라 리소스를 유지합니다. 이 주석의 값은 리소스 사용 기간(분)과 같아야 합니다. 예를 들어 5일 전에 생성된 리소스를 유지하려면 keep-since 를 7200 으로 설정합니다.

      참고

      keep 및 keep-since 주석은 함께 사용할 수 없습니다. 모든 리소스에 대해 해당 리소스 중 하나만 구성해야 합니다.

    • operator.tekton.dev/prune.strategy: 이 주석의 값을 keep 또는 keep-since 로 설정합니다.
  • 관리자는 전체 클러스터에 대해 파이프라인 서비스 계정 생성을 비활성화하고 관련 SCC를 잘못 사용하여 권한 상승을 방지할 수 있습니다. 이는 anyuid 와 매우 유사합니다.
  • TektonConfig CR(사용자 정의 리소스) 및 개별 구성 요소(예: TektonPipeline 및 TektonTriggers )를 사용하여 기능 플래그 및 구성 요소를 구성할 수 있습니다. 이러한 수준의 세분성은 개별 구성 요소에 대한 Tekton OCI 번들과 같은 알파 기능을 사용자 지정하고 테스트하는 데 도움이 됩니다.
  • PipelineRun 리소스에 대한 선택적 Timeouts 필드를 구성할 수 있습니다. 예를 들어 파이프라인 실행, 각 작업 실행 및 finally 작업에 대해 시간 제한을 별도로 구성할 수 있습니다.
  • TaskRun 리소스에서 생성한 Pod는 이제 Pod의 activeDeadlineSeconds 필드를 설정합니다. 이를 통해 OpenShift에서 종료되는 것으로 간주할 수 있으며 Pod에 범위가 지정된 ResourceQuota 오브젝트를 사용할 수 있습니다.
  • configmaps를 사용하여 작업 실행, 파이프라인 실행, 작업 및 파이프라인에서 메트릭 태그 또는 라벨 유형을 제거할 수 있습니다. 또한 히스토그램, 게이지 또는 마지막 값과 같은 기간을 측정하기 위해 다양한 유형의 메트릭을 구성할 수 있습니다.
  • Pod에 대한 요청 및 제한을 일관되게 정의할 수 있습니다. Tekton은 Min,Max, Default , Default Request 필드를 고려하여 LimitRange 오브젝트를 완전히 지원합니다.

  • 다음과 같은 알파 기능이 도입되었습니다.

    • 이제 모든 작업 실행을 직접 중지하는 이전 동작이 아닌 finally 작업을 실행한 후 파이프라인 실행이 중지될 수 있습니다. 이번 업데이트에서는 다음과 같은 spec.status 값이 추가되었습니다.

      • StoppedRun finally는 완료된 후 현재 실행 중인 작업을 중지한 다음 finally 작업을 실행합니다.
      • CancelledRunFinally 는 실행 중인 작업을 즉시 취소한 다음 finally 작업을 실행합니다.

      • 취소됨 은 PipelineRunCancelled 상태에서 제공한 이전 동작을 유지합니다.

        참고

        취소된 상태는 v1 버전에서 제거될 더 이상 사용되지 않는 PipelineRunCancelled 상태를 대체합니다.

    • oc debug 명령을 사용하여 실행을 일시 중지하고 Pod의 특정 단계를 검사할 수 있는 디버그 모드에 작업 실행을 배치할 수 있습니다.
    • 단계의 onError 필드를 계속하려면 단계의 종료 코드가 기록되어 후속 단계로 전달됩니다. 그러나 작업 실행이 실패하지 않고 작업의 나머지 단계를 계속 실행합니다. 기존 동작을 유지하려면 onError 필드 값을 stopAndFail 로 설정할 수 있습니다.
    • 이제 작업에서 실제로 사용되는 것보다 더 많은 매개변수를 허용할 수 있습니다. alpha 기능 플래그가 활성화되면 매개변수는 암시적으로 인라인 사양으로 전파될 수 있습니다. 예를 들어 인라인 작업은 작업에 대한 각 매개변수를 명시적으로 정의하지 않고 상위 파이프라인 실행의 매개변수에 액세스할 수 있습니다.
    • alpha 기능에 대해 플래그를 활성화하면 When 표현식 아래의 조건이 직접 연결된 작업에만 적용되며 작업의 종속 항목은 적용되지 않습니다. 연결된 작업 및 해당 종속 작업에 When 표현식을 적용하려면 해당 표현식을 각 종속 작업과 별도로 연결해야 합니다. 앞으로 이 동작은 Tekton의 새로운 API 버전에 있는 When 표현식의 기본 동작입니다. 기존 기본 동작은 이 업데이트 대신 더 이상 사용되지 않습니다.

  • 현재 릴리스에서는 TektonConfig CR(사용자 정의 리소스)에 nodeSelector 및 tolerations 값을 지정하여 노드 선택을 구성할 수 있습니다. Operator는 이러한 값을 생성하는 모든 배포에 추가합니다.

    • Operator 컨트롤러 및 Webhook 배포에 대한 노드 선택을 구성하려면 Operator를 설치한 후 Subscription CR 사양에서 config.nodeSelector 및 config.tolerations 필드를 편집합니다.
    • 인프라 노드에 OpenShift Pipelines의 나머지 컨트롤 플레인 Pod를 배포하려면 TektonConfig CR을 nodeSelector 및 tolerations 필드로 업데이트합니다. 그런 다음 Operator에서 생성한 모든 Pod에 수정 사항이 적용됩니다.

3.1.8.2. 더 이상 사용되지 않는 기능

  • CLI 0.21.0에서는 clustertask,task,taskrun,pipeline, pipelinerun 명령에 대한 모든 v1alpha1 리소스에 대한 지원이 더 이상 사용되지 않습니다. 이러한 리소스는 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.

  • Tekton Triggers v0.16.0에서는 중복 상태 레이블이 EventListener 리소스의 메트릭에서 제거됩니다.

    중요

    중단 변경: status 레이블이 eventlistener_http_duration_seconds_* 메트릭에서 제거되었습니다. status 레이블을 기반으로 하는 쿼리를 제거합니다.

  • 현재 릴리스에서는 v1alpha1 기능이 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 이번 업데이트를 통해 대신 v1beta1 Go API 유형을 사용할 수 있습니다. 트리거는 이제 v1beta1 API 버전을 지원합니다.

  • 현재 릴리스에서는 트리거가 처리를 완료하기 전에 EventListener 리소스에서 응답을 보냅니다.

    중요

    변경 중단: 이 변경으로 EventListener 리소스는 리소스를 생성할 때 201 생성된 상태 코드로 응답을 중지합니다. 대신 202 허용 응답 코드로 응답합니다.

  • 현재 릴리스에서는 EventListener 리소스에서 podTemplate 필드를 제거합니다.

    중요

    변경 중단: #1100 의 일부로 더 이상 사용되지 않는 podTemplate 필드가 제거되었습니다.

  • 현재 릴리스에서는 EventListener 리소스의 사양에서 더 이상 사용되지 않는 replicas 필드를 제거합니다.

    중요

    변경 사항 중단: 더 이상 사용되지 않는 replicas 필드가 제거되었습니다.

  • Red Hat OpenShift Pipelines 1.6에서 HOME="/tekton/home" 및 workingDir="/workspace" 값은 Step 오브젝트의 사양에서 제거됩니다.

    대신 Red Hat OpenShift Pipelines는 HOME 및 workingDir 을 Step 오브젝트를 실행하는 컨테이너에서 정의한 값으로 설정합니다. Step 개체의 사양에서 이러한 값을 재정의할 수 있습니다.

    이전 동작을 사용하려면 TektonConfig CR의 disable-working-directory-overwrite 및 disable-home-env-overwrite 필드를 false 로 변경할 수 있습니다. 

    apiVersion: operator.tekton.dev/v1alpha1
  kind: TektonConfig
  metadata:
    name: config
  spec:
    pipeline:
      disable-working-directory-overwrite: false
      disable-home-env-overwrite: false
  ...
    중요

    TektonConfig CR의 disable-working-directory-overwrite 및 disable-home-env-overwrite 필드는 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.

3.1.8.3. 확인된 문제

  • Maven 및 Jib-Maven 클러스터 작업을 실행하는 경우 기본 컨테이너 이미지는 Intel (x86) 아키텍처에서만 지원됩니다. 따라서 작업은 IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x) 클러스터에서 실패합니다. 이 문제를 해결하려면 MAVEN_IMAGE 매개변수 값을 maven:3.6.3-adoptopenjdk-11 로 설정하여 사용자 정의 이미지를 지정할 수 있습니다.
  • IBM Power Systems, IBM Z 및 LinuxONE에서는 s2i-dotnet 클러스터 작업이 지원되지 않습니다.
  • tkn hub 를 사용하여 IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x)에 Tekton Catalog를 기반으로 작업을 설치하기 전에 이러한 플랫폼에서 작업을 실행할 수 있는지 확인합니다. 작업 정보의 "Platforms" 섹션에 ppc64le 및 s390x 가 나열되어 있는지 확인하려면 tkn hub info task <name> 명령을 실행할 수 있습니다.

  • nodejs:14-ubi8-minimal 이미지 스트림을 사용할 수 없습니다. 이렇게 하면 다음과 같은 오류가 생성됩니다. 

    STEP 7: RUN /usr/libexec/s2i/assemble
/bin/sh: /usr/libexec/s2i/assemble: No such file or directory
subprocess exited with status 127
subprocess exited with status 127
error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
time="2021-11-04T13:05:26Z" level=error msg="exit status 127"

3.1.8.4. 해결된 문제

  • 이제 tkn hub 명령이 IBM Power Systems, IBM Z 및 LinuxONE에서 지원됩니다.
  • 이번 업데이트 이전에는 사용자가 tkn 명령을 실행한 후 터미널을 사용할 수 없었고 재시도 가 지정된 경우에도 파이프라인 실행이 수행되었습니다. 작업 실행 또는 파이프라인 실행에 시간 초과를 지정하면 적용되지 않았습니다. 이번 업데이트에서는 명령을 실행한 후 터미널을 사용할 수 있도록 문제가 해결되었습니다.
  • 이번 업데이트 이전에는 tkn pipelinerun delete --all 을 실행하면 모든 리소스가 삭제되었습니다. 이번 업데이트에서는 실행 중인 상태의 리소스가 삭제되지 않습니다.
  • 이번 업데이트 이전에는 tkn version --component=<component> 명령을 사용하여 구성 요소 버전을 반환하지 않았습니다. 이번 업데이트에서는 이 명령이 구성 요소 버전을 반환하도록 문제가 해결되었습니다.
  • 이번 업데이트 이전에는 tkn pr logs 명령을 사용하면 파이프라인 출력 로그가 잘못된 작업 순서로 표시되었습니다. 이번 업데이트에서는 완료된 PipelineRuns 의 로그가 적절한 TaskRun 실행 순서에 나열되도록 문제를 해결합니다.
  • 이번 업데이트 이전에는 실행 중인 파이프라인의 사양을 편집하면 파이프라인 실행이 완료되면 파이프라인 실행이 중지되지 않을 수 있습니다. 이번 업데이트에서는 정의를 한 번만 가져온 다음 확인을 위해 상태에 저장된 사양을 사용하여 문제를 해결합니다. 이번 변경으로 PipelineRun 또는 TaskRun 이 실행 중인 동안 변경되는 Pipeline 또는 Task 를 참조할 때 경쟁 조건의 가능성이 줄어듭니다.
  • when 표현식 값에 값 : [$(params.arrayParam[*])] 와 같은 배열 매개변수 참조가 있을 수 있습니다.

3.1.8.5. Red Hat OpenShift Pipelines General Availability 1.6.1 릴리스 정보

3.1.8.5.1. 확인된 문제

  • 이전 버전에서 Red Hat OpenShift Pipelines 1.6.1로 업그레이드한 후 OpenShift Pipelines는 Tekton 리소스(tasks 및 Pipeline)에서 작업(create/delete/apply)을 수행할 수 없는 일관성 없는 상태가 될 수 있습니다. 예를 들어 리소스를 삭제하는 동안 다음 오류가 발생할 수 있습니다. 

    Error from server (InternalError): Internal error occurred: failed calling webhook "validation.webhook.pipeline.tekton.dev": Post "https://tekton-pipelines-webhook.openshift-pipelines.svc:443/resource-validation?timeout=10s": service "tekton-pipelines-webhook" not found.
3.1.8.5.2. 해결된 문제

  • Red Hat OpenShift Pipelines에서 설정한 SSL_CERT_DIR 환경 변수(/tekton-custom-certs)는 인증서 파일이 있는 다음 기본 시스템 디렉터리를 재정의하지 않습니다.

    • /etc/pki/tls/certs
    • /etc/ssl/certs
    • /system/etc/security/cacerts
  • Horizontal Pod Autoscaler는 Red Hat OpenShift Pipelines Operator가 제어하는 배포의 복제본 수를 관리할 수 있습니다. 이번 릴리스에서는 최종 사용자 또는 클러스터 에이전트가 개수를 변경하면 Red Hat OpenShift Pipelines Operator에서 관리하는 배포의 복제본 수를 재설정하지 않습니다. 그러나 Red Hat OpenShift Pipelines Operator를 업그레이드할 때 복제본이 재설정됩니다.
  • 이제 tkn CLI를 제공하는 Pod가 TektonConfig 사용자 지정 리소스에 지정된 노드 선택기 및 허용 오차 제한을 기반으로 노드에 예약됩니다.

3.1.8.6. Red Hat OpenShift Pipelines General Availability 1.6.2 릴리스 정보

3.1.8.6.1. 확인된 문제
  • 새 프로젝트를 생성하면 파이프라인 서비스 계정 생성이 지연되고 기존 클러스터 작업 및 파이프라인 템플릿을 제거하는 데 10분 이상 걸립니다.
3.1.8.6.2. 해결된 문제
  • 이번 업데이트 이전에는 이전 버전에서 Red Hat OpenShift Pipelines 1.6.1으로 업그레이드한 후 파이프라인에 대해 Tekton 설치 프로그램의 여러 인스턴스가 생성되었습니다. 이번 업데이트를 통해 Operator는 업그레이드 후 각 TektonInstallerSet 유형의 인스턴스가 하나만 있는지 확인합니다.
  • 이번 업데이트 이전에는 Operator의 모든 조정기를 사용하여 이전 버전에서 Red Hat OpenShift Pipelines 1.6.1으로 업그레이드하는 동안 구성 요소 버전을 사용했습니다. 이로 인해 구성 요소 버전이 업그레이드에서 변경되지 않은 리소스가 다시 생성되지 않았습니다. 이번 업데이트를 통해 Operator는 구성 요소 버전 대신 Operator 버전을 사용하여 업그레이드 중에 리소스 생성을 결정합니다.
  • 이번 업데이트 이전에는 업그레이드 후 클러스터에서 파이프라인 Webhook 서비스가 누락되었습니다. 이는 구성 맵의 업그레이드 교착 상태 때문입니다. 이번 업데이트를 통해 클러스터에 구성 맵이 없는 경우 Webhook 검증을 비활성화하기 위한 메커니즘이 추가되었습니다. 결과적으로 파이프라인 Webhook 서비스는 업그레이드 후 클러스터에서 유지됩니다.
  • 이번 업데이트 이전에는 네임스페이스의 구성이 변경된 후 자동 실행을 위한 cron 작업이 다시 생성되었습니다. 이번 업데이트를 통해 네임스페이스에 관련 주석이 변경된 경우에만 자동 실행 가져오기에 대한 cron 작업이 다시 생성됩니다.

  • Tekton Pipelines의 업스트림 버전은 다음과 같은 수정 사항이 있는 v0.28.3 으로 수정되었습니다.

    • 라벨 또는 주석 전파를 허용하도록 PipelineRun 또는 TaskRun 오브젝트를 수정합니다.

    • 암시적 매개변수의 경우:

      • PipelineSpec 매개변수를 TaskRefs 오브젝트에 적용하지 마십시오.
      • Pipeline 오브젝트에 대한 암시적 매개 변수 동작을 비활성화합니다.

3.1.8.7. Red Hat OpenShift Pipelines General Availability 1.6.3 릴리스 정보

3.1.8.7.1. 해결된 문제

  • 이번 업데이트 이전에는 Red Hat OpenShift Pipelines Operator가 Pipelines 및 Trigger와 같은 구성 요소에서 Pod 보안 정책을 설치했습니다. 그러나 구성 요소의 일부로 제공되는 Pod 보안 정책은 이전 릴리스에서 더 이상 사용되지 않았습니다. 이번 업데이트를 통해 Operator는 구성 요소에서 Pod 보안 정책 설치를 중지합니다. 결과적으로 다음과 같은 업그레이드 경로가 영향을 받습니다.

    • OpenShift Pipelines 1.6.1 또는 1.6.2에서 OpenShift Pipelines 1.6.3으로 업그레이드하면 Pipeline 및 Trigger 구성 요소의 Pod 보안 정책이 삭제됩니다.

    • OpenShift Pipelines 1.5.x에서 1.6.3으로 업그레이드하면 구성 요소에서 설치된 Pod 보안 정책이 유지됩니다. 클러스터 관리자는 수동으로 삭제할 수 있습니다.

      참고

      향후 릴리스로 업그레이드할 때 Red Hat OpenShift Pipelines Operator는 사용되지 않는 모든 Pod 보안 정책을 자동으로 삭제합니다.

  • 이번 업데이트 이전에는 클러스터 관리자만 OpenShift Container Platform 콘솔의 파이프라인 메트릭에 액세스할 수 있었습니다. 이번 업데이트를 통해 다른 클러스터 역할이 있는 사용자도 파이프라인 메트릭에 액세스할 수 있습니다.
  • 이번 업데이트 이전에는 OpenShift Pipelines Operator의 RBAC(역할 기반 액세스 제어) 문제로 인해 구성 요소를 업그레이드하거나 설치하는 데 문제가 발생했습니다. 이번 업데이트를 통해 다양한 Red Hat OpenShift Pipelines 구성 요소를 설치할 때 안정성과 일관성이 향상됩니다.
  • 이번 업데이트 이전에는 TektonConfig CR에서 clusterTasks 및 pipelineTemplates 필드를 false 로 설정하면 클러스터 작업 및 파이프라인 템플릿이 제거 속도가 느려졌습니다. 이번 업데이트를 통해 클러스터 작업 및 파이프라인 템플릿과 같은 Tekton 리소스의 라이프사이클 관리 속도가 향상됩니다.

3.1.8.8. Red Hat OpenShift Pipelines General Availability 1.6.4 릴리스 정보

3.1.8.8.1. 확인된 문제

  • Red Hat OpenShift Pipelines 1.5.2에서 1.6.4로 업그레이드한 후 이벤트 리스너 경로에 액세스하면 503 오류가 반환됩니다.

    해결방법: 이벤트 리스너의 경로에 대한 YAML 파일의 대상 포트를 수정합니다.

    1. 관련 네임스페이스의 경로 이름을 추출합니다. 

      $ oc get route -n <namespace>

    2. 경로를 편집하여 targetPort 필드의 값을 수정합니다. 

      $ oc edit route -n <namespace> <el-route_name>

      예: 기존 이벤트 리스너 경로

      ...
spec:
  host: el-event-listener-q8c3w5-test-upgrade1.apps.ve49aws.aws.ospqa.com
  port:
    targetPort: 8000
  to:
    kind: Service
    name: el-event-listener-q8c3w5
    weight: 100
  wildcardPolicy: None
...

      예: 수정된 이벤트 리스너 경로

      ...
spec:
  host: el-event-listener-q8c3w5-test-upgrade1.apps.ve49aws.aws.ospqa.com
  port:
    targetPort: http-listener
  to:
    kind: Service
    name: el-event-listener-q8c3w5
    weight: 100
  wildcardPolicy: None
...

3.1.8.8.2. 해결된 문제
  • 이번 업데이트 이전에는 네임스페이스가 Terminating 상태인 경우 RBAC 리소스를 생성할 때 Operator가 실패했습니다. 이번 업데이트를 통해 Operator는 Terminating 상태의 네임스페이스를 무시하고 RBAC 리소스를 생성합니다.
  • 이번 업데이트 이전에는 관련 Tekton 컨트롤러의 릴리스 버전을 지정하는 주석이 없기 때문에 작업이 실패하거나 다시 시작됩니다. 이번 업데이트를 통해 적절한 주석이 포함되어 자동화되고, 실패 또는 재시작 없이 작업이 실행됩니다.

3.1.9. Red Hat OpenShift Pipelines General Availability 1.5 릴리스 정보

Red Hat OpenShift Pipelines General Availability (GA) 1.5는 이제 OpenShift Container Platform 4.8에서 사용할 수 있습니다.

3.1.9.1. 호환성 및 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

아래 표에서 기능은 다음과 같은 상태로 표시되어 있습니다.

TP

기술 프리뷰

GA

정식 출시일 (GA)

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 3.2. 호환성 및 지원 매트릭스

기능버전지원 상태

파이프라인

0.24

GA

CLI

0.19

GA

카탈로그

0.24

GA

Trigger

0.14

TP

파이프 라인 리소스

-

TP

질문이나 의견이 있으시면 제품팀에 이메일(pipelines-interest@redhat.com)로 보내주시기 바랍니다.

3.1.9.2. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.5의 새로운 기능도 소개합니다.

  • 대상 네임스페이스의 cron 작업으로 파이프라인 실행 및 작업 실행이 자동으로 제거됩니다. cron 작업에서는 IMAGE_JOB_PRUNER_TKN 환경 변수를 사용하여 tkn image 값을 가져옵니다. 이번 개선된 기능을 통해 TektonConfig 사용자 정의 리소스에 다음 필드가 도입되었습니다. 

    ...
pruner:
  resources:
    - pipelinerun
    - taskrun
  schedule: "*/5 * * * *" # cron schedule
  keep: 2 # delete all keeping n
...

  • OpenShift Container Platform에서는 TektonConfig 사용자 정의 리소스의 새 매개변수 clusterTasks 및 pipelinesTemplates 값을 수정하여 Tekton 애드온 구성 요소 설치를 사용자 지정할 수 있습니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  addon:
    params:
    - name: clusterTasks
      value: "true"
    - name: pipelineTemplates
      value: "true"
...

    사용자 지정은 TektonConfig를 사용하여 애드온을 만들거나 Techton 애드온을 사용하여 직접 만드는 경우에 허용됩니다. 그러나 매개 변수가 전달되지 않으면 컨트롤러는 기본값을 사용하여 매개 변수를 추가합니다.

    참고
    • TektonConfig 사용자 지정 리소스를 사용하여 추가 기능이 생성되고 Addon 사용자 정의 리소스의 뒷부분에서 매개변수 값을 변경하면 TektonConfig 사용자 지정 리소스의 값이 변경 사항을 덮어씁니다.
    • clusterTasks 매개변수 값이 true인 경우에만 pipelinesTemplates 매개변수의 값을 true로 설정할 수 있습니다.

  • enableMetrics 매개변수는 TektonConfig 사용자 지정 리소스에 추가됩니다. 이를 사용하여 OpenShift Container Platform용 Tekton Pipelines의 일부인 서비스 모니터를 비활성화할 수 있습니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  profile: all
  targetNamespace: openshift-pipelines
  pipeline:
    params:
    - name: enableMetrics
      value: "true"
...
  • 프로세스 수준에서 메트릭을 캡처하는 EventListener OpenCensus 메트릭이 추가되었습니다.
  • 트리거에 레이블 선택기가 있습니다. 레이블을 사용하여 이벤트 리스너에 대한 트리거를 구성할 수 있습니다.

  • 인터셉터 등록에 대한 ClusterInterceptor 사용자 정의 리소스 정의가 추가되어 연결할 수 있는 새로운 Interceptor 유형을 등록할 수 있습니다. 또한 다음과 같은 관련 변경 사항이 적용됩니다.

    • 트리거 사양에서는 클러스터 인터셉터를 참조하기 위해 ref 필드를 포함하는 새 API를 사용하여 인터셉터를 구성할 수 있습니다. 또한 params 필드를 사용하여 처리를 위해 인터셉터에 전달되는 매개변수를 추가할 수 있습니다.
    • 번들 인터셉터 CEL, GitHub, GitLab, BitBucket이 마이그레이션되었습니다. 새 ClusterInterceptor 사용자 정의 리소스 정의를 사용하여 구현됩니다.
    • 코어 인터셉터는 새 형식으로 마이그레이션되고 이전 구문을 사용하여 생성된 새 트리거가 새 ref 또는 params 기반 구문으로 자동 전환됩니다.
  • 로그를 표시하는 동안 작업 이름 또는 단계의 접두사를 비활성화하려면 log 명령에 --prefix 옵션을 사용합니다.
  • 특정 구성 요소의 버전을 표시하려면 tkn version 명령에서 새 --component 플래그를 사용합니다.
  • tkn hub check-upgrade 명령이 추가되고 파이프라인 버전을 기반으로 다른 명령이 수정되었습니다. 또한 search 명령 출력에 카탈로그 이름이 표시됩니다.
  • 선택적 작업 공간에 대한 지원이 start 명령에 추가됩니다.
  • plugins 디렉토리에 플러그인이 없으면 현재 경로에서 검색됩니다.

  • tkn start [task | clustertask | pipeline] 명령은 대화식으로 시작하고 기본 매개변수를 지정하는 경우에도 params 값을 요청합니다. 대화식 프롬프트를 중지하려면 명령을 호출할 때 --use-param-defaults 플래그를 전달합니다. 예를 들면 다음과 같습니다. 

    $ tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-api \
    -p git-url=https://github.com/openshift/pipelines-vote-api.git \
    -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api \
    --use-param-defaults
  • version 필드는 tkn task describe 명령에 추가됩니다.
  • TriggerTemplate 또는 TriggerBinding 또는 ClusterTriggerBinding 또는 Eventlistener와 같은 리소스를 자동으로 선택하는 옵션은 하나만 있는 경우 describe 명령에 추가됩니다.
  • tkn pr describe 명령에 건너뛰는 작업의 섹션이 추가됩니다.
  • tkn clustertask logs에 대한 지원이 추가되었습니다.
  • config.yaml에서 YAML 병합 및 변수가 제거됩니다. 또한 kustomize 및 ytt와 같은 툴에서 release.yaml 파일을 더 쉽게 사용할 수 있습니다.
  • 리소스 이름에 점 문자(".")가 포함되도록 지원이 추가되었습니다.
  • PodTemplate 사양의 hostAliases 어레이는 호스트 이름 확인의 Pod 수준 재정의에 추가됩니다. 이를 위해 /etc/hosts 파일을 수정합니다.
  • $(tasks.status) 변수가 도입되어 작업의 집계 실행 상태에 액세스합니다.
  • Windows용 진입점 바이너리 빌드가 추가되었습니다.

3.1.9.3. 사용되지 않는 기능

  • when 표현식에서 작성된 필드에 대한 지원에서는 PascalCase가 제거되었습니다. when 표현식은 소문자로 작성된 필드만 지원합니다.

    참고

    Tekton Pipelines v0.16(Operator v 1.2.x )에서 when 표현식과 함께 파이프라인을 적용한 경우 다시 적용해야 합니다.

  • Red Hat OpenShift Pipelines Operator를 v1.5로 업그레이드하면 openshift-client 및 openshift-client-v-1-5-0 클러스터 작업에 SCRIPT 매개변수가 있습니다. 그러나 ARGS 매개변수와 git 리소스는 openshift-client 클러스터 작업의 사양에서 제거됩니다. 이는 중단된 변경 사항이며 ClusterTask 리소스의 name 필드에 특정 버전이 없는 클러스터 작업만 원활하게 업그레이드됩니다.

    파이프라인 실행이 중단되지 않도록 하려면 업그레이드 후 ARGS 매개변수에 지정된 값을 클러스터 작업의 SCRIPT 매개변수로 이동하기 때문에 SCRIPT 매개변수를 사용합니다. 예를 들면 다음과 같습니다. 

    ...
- name: deploy
  params:
  - name: SCRIPT
    value: oc rollout status <deployment-name>
  runAfter:
    - build
  taskRef:
    kind: ClusterTask
    name: openshift-client
...

  • Red Hat OpenShift Pipelines Operator v1.4에서 v1.5로 업그레이드하면 TektonConfig 사용자 정의 리소스가 설치된 프로필 이름이 변경됩니다.

    표 3.3. TektonConfig 사용자 정의 리소스의 프로필

    Pipeline 1.5의 프로필Pipelines 1.4의 해당 프로필설치된 Tekton 구성 요소

    모두(기본 프로필)

    모두(기본 프로필)

    파이프라인, 트리거, 애드온

    Basic

    Default

    파이프라인, 트리거

    Lite

    Basic

    파이프라인

    참고

    TektonConfig 사용자 정의 리소스의 config 인스턴스에서 profile: all을 사용한 경우 리소스 사양을 변경할 필요가 없습니다.

    그러나 설치된 Operator가 업그레이드 전에 Default 또는 Basic 프로필에 있는 경우 업그레이드 후 TektonConfig 사용자 정의 리소스의 config 인스턴스를 편집해야 합니다. 예를 들어 구성이 업그레이드 전에 profile: basic인 경우 Pipelines 1.5로 업그레이드한 후 profile: lite인지 확인합니다.

  • disable-home-env-overwrite 및 disable-working-dir-overwrite 필드는 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 이번 릴리스에서는 이전 버전과의 호환성을 위해 이러한 플래그의 기본값이 true로 설정됩니다.

    참고

    다음 릴리스에서는 HOME 환경 변수가 자동으로 /tekton/home으로 설정되지 않으며 작업 실행을 위해 기본 작업 디렉터리가 /workspace로 설정되지 않습니다. 이러한 기본값은 단계의 이미지 Dockerfile로 설정된 값과 충돌합니다.

  • ServiceType 및 podTemplate 필드는 EventListener 사양에서 제거됩니다.
  • 컨트롤러 서비스 계정은 더 이상 네임스페이스를 나열하고 감시하기 위한 클러스터 전체 권한을 요청하지 않습니다.

  • EventListener 리소스의 상태에는 Ready라는 새로운 조건이 있습니다.

    참고

    나중에 EventListener 리소스의 기타 상태 조건이 더 이상 사용되지 않고 Ready 상태 조건이 사용됩니다.

  • EventListener 응답의 eventListener 및 namespace 필드는 더 이상 사용되지 않습니다. 대신 eventListenerUID 필드를 사용합니다.

  • replicas 필드는 EventListener 사양에서 더 이상 사용되지 않습니다. 대신 spec.replicas 필드가 KubernetesResource 사양의 spec.resources.kubernetesResource.replicas로 이동됩니다.

    참고

    replicas 필드는 향후 릴리스에서 제거됩니다.

  • 코어 인터셉터를 구성하는 이전 방법은 더 이상 사용되지 않습니다. 그러나 향후 릴리스에서 제거될 때까지 계속 작동합니다. 대신 Trigger 리소스의 인터셉터가 새로운 ref 및 params 기반 구문을 사용하여 구성됩니다. 결과 기본 웹훅은 새 트리거에 대해 이전 구문의 사용법을 새 구문으로 자동 전환합니다.
  • ClusterRoleBinding 리소스에 대해 더 이상 사용되지 않는rbac.authorization.k8s.io/v1beta1 대신rbac.authorization.k8s.io/v1을 사용합니다.
  • 클러스터 역할에서는 serviceaccounts, secrets, configmaps, limitranges와 같은 리소스에 대한 클러스터 전체 쓰기 권한이 제거됩니다. 또한 deployments, statefulsets, deployment/finalizers와 같은 리소스에 대한 클러스터 전체 액세스도 제거됩니다.
  • caching.internal.knative.dev 그룹의 image 사용자 지정 리소스 정의는 Tekton에서 더 이상 사용하지 않으며 이 릴리스에서 제외되었습니다.

3.1.9.4. 확인된 문제

  • git-cli 클러스터 작업은 /root가 사용자의 홈 디렉터리로 예상되는 alpine/git 기본 이미지에서 빌드됩니다. 그러나 git-cli 클러스터 작업에는 명시적으로 설정되어 있지 않습니다.

    Tekton에서 달리 지정하지 않는 한, Tekton에서 기본 홈 디렉토리는 작업의 모든 단계에 대해 /tekton/home으로 덮어씁니다. 기본 이미지의 $HOME 환경 변수를 덮어쓰면 git-cli 클러스터 작업이 실패합니다.

    이 문제는 다음 릴리스에서 수정될 예정입니다. Red Hat OpenShift Pipelines 1.5 및 이전 버전의 경우 다음 해결 방법 중 하나를 사용하여 git-cli 클러스터 작업이 실패하지 않도록 할 수 있습니다.

    • 단계에서 $HOME 환경 변수를 설정하여 덮어쓰지 않도록 합니다.

      1. [선택 사항] Operator를 사용하여 Red Hat OpenShift Pipelines를 설치한 경우 git-cli 클러스터 작업을 별도의 작업에 복제합니다. 이 방법을 사용하면 Operator에서 클러스터 작업의 변경 사항을 덮어쓰지 않습니다.
      2. oc edit clustertasks git-cli 명령을 실행합니다.

      3. 예상되는 HOME 환경 변수를 단계 YAML에 추가합니다. 

        ...
steps:
  - name: git
    env:
    - name: HOME
      value: /root
    image: $(params.BASE_IMAGE)
    workingDir: $(workspaces.source.path)
...
        주의

        Operator가 설치한 Red Hat OpenShift Pipelines의 경우 HOME 환경 변수를 변경하기 전에 git-cli 클러스터 작업을 별도의 작업으로 복제하지 않으면 Operator 조정 중에 변경 사항을 덮어씁니다.

    • feature-flags 구성 맵에서 HOME 환경 변수 덮어쓰기를 비활성화합니다.

      1. oc edit -n openshift-pipelines configmap feature-flags 명령을 실행합니다.

      2. disable-home-env-overwrite 플래그 값을 true로 설정합니다.

        주의
        • Operator를 사용하여 Red Hat OpenShift Pipelines를 설치한 경우 Operator 조정 중에 변경 사항을 덮어씁니다.
        • disable-home-env-overwrite 플래그의 기본값을 수정하면 모든 작업의 기본 동작을 변경하므로 다른 작업과 클러스터 작업이 중단될 수 있습니다.

    • 파이프라인의 기본 서비스 계정이 사용될 때 HOME 환경 변수의 덮어쓰기가 수행되므로 git-cli 클러스터 작업에 다른 서비스 계정을 사용합니다.

      1. 새로운 서비스 계정을 생성합니다.
      2. 생성한 서비스 계정에 Git 시크릿을 연결합니다.
      3. 작업 또는 파이프라인을 실행하는 동안 서비스 계정을 사용합니다.
  • IBM Power Systems, IBM Z 및 LinuxONE에서 s2i-dotnet 클러스터 작업 및 tkn hub 명령은 지원되지 않습니다.
  • Maven 및 Jib-Maven 클러스터 작업을 실행하는 경우 기본 컨테이너 이미지는 Intel (x86) 아키텍처에서만 지원됩니다. 따라서 작업은 IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x) 클러스터에서 실패합니다. 이 문제를 해결하려면 MAVEN_IMAGE 매개변수 값을 maven:3.6.3-adoptopenjdk-11 로 설정하여 사용자 정의 이미지를 지정할 수 있습니다.

3.1.9.5. 해결된 문제

  • dag 작업의 when 표현식은 다른 작업의 실행상태 ($(tasks.<pipelineTask>.status))에 액세스하는 컨텍스트 변수를 지정할 수 없습니다.
  • PipelineRun 리소스가 신속하게 삭제되고 다시 생성되는 경우 volumeClaimTemplate PVC를 삭제하여 생성된 경쟁 조건을 방지할 수 있으므로 소유자 이름 대신 소유자 UID를 사용합니다.
  • 루트가 아닌 사용자가 트리거한 build-base 이미지의 pullrequest-init에 대한 새 Dockerfile이 추가됩니다.
  • 파이프라인 또는 작업을 -f 옵션으로 실행하고 정의의 param에 type이 정의되지 않은 경우 파이프라인 또는 작업 실행이 자동으로 실패하는 대신 유효성 검사 오류가 생성됩니다.
  • tkn start [task | pipeline | clustertask] 명령의 경우 --workspace 플래그에 대한 설명이 일관되게 표시됩니다.
  • 매개 변수를 구문 분석하는 동안 빈 배열이 발생하는 경우 해당 대화형 도움말이 빈 문자열로 표시됩니다.

3.1.10. Red Hat OpenShift Pipelines General Availability 1.4 릴리스 정보

Red Hat OpenShift Pipelines General Availability (GA)는 이제 OpenShift Container Platform 4.7에서 사용할 수 있습니다.

참고

안정적인 프리뷰 Operator 채널 외에도 Red Hat OpenShift Pipelines Operator 1.4.0에는 ocp-4.6, ocp-4.5 및 ocp-4.4 사용 중단 채널이 함께 제공됩니다. 이러한 더 이상 사용되지 않는 채널과 이에 대한 지원은 다음 Red Hat OpenShift Pipelines 릴리스에서 제거됩니다.

3.1.10.1. 호환성 및 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

아래 표에서 기능은 다음과 같은 상태로 표시되어 있습니다.

TP

기술 프리뷰

GA

정식 출시일 (GA)

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 3.4. 호환성 및 지원 매트릭스

기능버전지원 상태

파이프라인

0.22

GA

CLI

0.17

GA

카탈로그

0.22

GA

Trigger

0.12

TP

파이프 라인 리소스

-

TP

질문이나 의견이 있으시면 제품팀에 이메일(pipelines-interest@redhat.com)로 보내주시기 바랍니다.

3.1.10.2. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.4의 새로운 기능도 소개합니다.

  • 사용자 지정 작업에는 다음과 같은 향상된 기능이 있습니다.

    • 파이프라인 결과는 사용자 지정 작업에서 생성된 결과를 참조할 수 있습니다.
    • 사용자 지정 작업에서는 작업 영역, 서비스 계정 및 Pod 템플릿을 사용하여 더 복잡한 사용자 지정 작업을 빌드할 수 있습니다.

  • finally 작업에는 다음과 같은 향상된 기능이 있습니다.

    • finally 작업에서 when 표현식이 지원되므로 효율적으로 보호되는 실행 및 작업 재사용성을 개선할 수 있습니다.

    • finally 작업에서는 동일한 파이프라인 내의 모든 작업 결과를 사용하도록 구성할 수 있습니다.

      참고

      OpenShift Container Platform 4.7 웹 콘솔에서 when 표현식 및 finally 작업을 지원하지 않습니다.

  • dockercfg 또는 dockerconfigjson 유형의 여러 보안에 대한 지원이 런타임 시 인증에 추가되었습니다.
  • git-clone 작업을 사용하여 스파스-체크아웃을 지원하는 기능이 추가되었습니다. 이를 통해 리포지토리의 하위 집합만 로컬 복사본으로 복제할 수 있으며 복제된 리포지토리의 크기를 제한할 수 있습니다.
  • 실제로 시작하지 않고 보류 중인 상태에서 파이프라인 실행을 생성할 수 있습니다. 로드가 많은 클러스터에서 Operator는 파이프라인 실행 시작 시간을 제어할 수 있습니다.
  • 컨트롤러에 대해 SYSTEM_NAMESPACE 환경 변수를 수동으로 설정했는지 확인합니다. 이전에는 기본적으로 설정되었습니다.
  • 이제 루트가 아닌 사용자가 파이프라인의 빌드-기반 이미지에 추가되어 git-init가 루트가 아닌 사용자로 리포지토리를 복제할 수 있습니다.
  • 파이프라인 실행이 시작되기 전에 해결된 리소스 간 종속성을 확인하는 지원이 추가되어 있습니다. 파이프라인의 모든 결과 변수가 유효해야 하며 파이프라인의 선택적 작업 공간을 파이프라인 실행을 시작하기 위해 필요한 작업으로만 전달할 수 있습니다.
  • 컨트롤러 및 Webhook는 루트가 아닌 그룹으로 실행되며, 보안을 강화하기 위해 해당 기능이 제거되었습니다.
  • tkn pr logs 명령을 사용하여 재시도된 작업 실행에 대한 로그 스트림을 확인할 수 있습니다.
  • tkn tr delete 명령에서 --clustertask 옵션을 사용하여 특정 클러스터 작업과 연관된 모든 작업을 삭제할 수 있습니다.
  • 새 customResource 필드를 도입하여 EventListener 리소스와 함께 Knative 서비스 사용에 대한 지원이 추가되었습니다.
  • 이벤트 페이로드에서 JSON 형식을 사용하지 않으면 오류 메시지가 표시됩니다.
  • GitLab, BitBucket 및 GitHub와 같은 소스 제어 인터셉터는 이제 새로운 InterceptorRequest 또는 InterceptorResponse 유형 인터페이스를 사용합니다.
  • JSON 개체 또는 배열을 문자열에 인코딩할 수 있도록 새로운 CEL 함수 marshalJSON이 구현됩니다.
  • CEL 및 소스 제어 코어 인터셉터를 제공하는 HTTP 처리기가 추가되었습니다. tekton-pipelines 네임스페이스에 배포된 단일 HTTP 서버에 4개의 코어 인터셉터를 패키징합니다. EventListener 오브젝트는 HTTP 서버를 통해 이벤트를 인터셉터로 전달합니다. 각 인터셉터는 다른 경로에서 사용할 수 있습니다. 예를 들어 /cel 경로에서 CEL 인터셉터를 사용할 수 있습니다.

  • pipelines-scc SCC(Security Context Constraint)는 파이프라인의 기본 pipeline 서비스 계정과 함께 사용됩니다. 이 새 서비스 계정은 anyuid와 유사하지만 OpenShift Container Platform 4.7의 SCC에 대해 YAML에 정의된 것과 약간의 차이점이 있습니다. 

    fsGroup:
  type: MustRunAs

3.1.10.3. 사용되지 않는 기능

  • 파이프라인 리소스 스토리지의 build-gcs 하위 유형과 gcs-fetcher 이미지는 지원되지 않습니다.
  • 클러스터 작업의 taskRun 필드에서 tekton.dev/task 레이블이 제거됩니다.
  • Webhook의 경우 admissionReviewVersions 필드에 해당하는 v1beta1 값이 제거됩니다.
  • 빌드 및 배포를 위한 creds-init 도우미 이미지가 제거됩니다.

  • 트리거 사양 및 바인딩에서는 template.ref를 사용하도록 더 이상 사용되지 않는 필드 template.name이 제거됩니다. ref 필드를 사용하려면 모든 eventListener 정의를 업데이트해야 합니다.

    참고

    OpenShift Pipelines 1.3.x 및 이전 버전에서 OpenShift Pipelines 1.4.0으로 업그레이드하면 template.name 필드의 사용할 수 없으므로 이벤트 리스너가 중단됩니다. 이러한 경우 OpenShift Pipelines 1.4.1을 사용하여 복원된 template.name 필드를 사용할 수 있습니다.

  • EventListener 사용자 정의 리소스/개체의 경우 Resource가 사용되며 PodTemplate 및 ServiceType 필드는 더 이상 사용되지 않습니다.
  • 더 이상 사용되지 않는 사양 스타일 내장 바인딩이 제거됩니다.
  • spec 필드는 triggerSpecBinding에서 제거됩니다.
  • 이벤트 ID 표현은 5자의 임의의 문자열에서 UUID로 변경됩니다.

3.1.10.4. 확인된 문제

  • 개발자 화면에서 파이프라인 지표 및 트리거 기능은 OpenShift Container Platform 4.7.6 이상 버전에서만 사용할 수 있습니다.
  • IBM Power Systems, IBM Z 및 LinuxONE에서는 tkn hub 명령이 지원되지 않습니다.
  • IBM Power Systems(ppc64le), IBM Z 및 LinuxONE(s390x) 클러스터에서 Maven 및 Jib Maven 클러스터 작업을 실행하는 경우 MAVEN_IMAGE 매개변수 값을 maven:3.6.3-adoptopenjdk-11으로 설정합니다.

  • 트리거 바인딩에 다음 구성이 있는 경우 JSON 형식이 잘못 처리되어 발생하는 오류를 트리거합니다. 

    params:
  - name: github_json
    value: $(body)

    문제를 해결하려면 다음을 수행합니다.

    • 트리거 v0.11.0 이상을 사용하는 경우 marshalJSON CEL 함수를 사용하여 JSON 개체 또는 배열을 가져와 해당 오브젝트 또는 배열의 JSON 인코딩을 문자열로 반환합니다.

    • 이전 트리거 버전을 사용하는 경우 트리거 템플릿에 다음 주석을 추가합니다. 

      annotations:
  triggers.tekton.dev/old-escape-quotes: "true"
  • OpenShift Pipelines 1.3.x에서 1.4.x로 업그레이드하는 경우 경로를 다시 생성해야 합니다.

3.1.10.5. 해결된 문제

  • 이전에는 클러스터 작업의 작업 실행에서 tekton.dev/task 레이블이 제거되었으며 tekton.dev/clusterTask 레이블이 도입되었습니다. 해당 변경으로 인한 문제는 clustertask describe 및 delete 명령을 수정하여 해결됩니다. 또한 작업의 lastrun 기능이 수정되어 이전 버전의 파이프라인의 작업 실행에 적용되는 tekton.dev/task 레이블의 문제를 해결합니다.
  • 대화형 tkn pipeline start pipelinename을 수행할 때 PipelineResource가 대화형으로 생성됩니다. 리소스 상태가 nil이 아닌 경우 tkn p start 명령은 리소스 상태를 출력합니다.
  • 이전에는 tekton.dev/task=name 레이블이 클러스터 작업에서 생성된 작업 실행에서 제거되었습니다. 이번 수정에서는 tkn clustertask start 명령을 --last 플래그로 수정하여 생성된 작업 실행에서 tekton.dev/task=name 라벨을 확인합니다.
  • 작업에서 인라인 작업 사양을 사용하는 경우 이제 tkn pipeline describe 명령을 실행할 때 해당 작업 실행이 파이프라인에 포함되고, 작업 이름이 포함된 것으로 반환됩니다.
  • tkn version 명령은 구성된 kubeConfiguration namespace 또는 클러스터에 대한 액세스없이 설치된 Tekton CLI 툴 버전을 표시하도록 수정되었습니다.
  • 인수가 예기치 않은 것이거나 두 개 이상의 인수가 사용되는 경우 tkn completion 명령에서 오류가 발생합니다.
  • 이전에는 파이프라인 사양에 중첩된 finally 작업으로 인해 v1alpha1 버전으로 변환되고 v1beta1 버전으로 복원된 finally 작업이 손실되었습니다. 변환 중에 발생하는 이 오류는 잠재적인 데이터 손실을 방지하기 위해 수정되었습니다. 파이프라인은 이제 파이프라인 사양에 중첩된 finally 작업에서 실행되며 알파 버전에 저장되지만 나중에 역직렬화됩니다.
  • 이전에는 서비스 계정에 {}로 secret 필드가 있는 경우 Pod 생성에 오류가 발생했습니다. 빈 시크릿 이름을 가진 GET 요청이 오리소스 이름을 비워 둘 수 없다는 오류를 반환했기 때문에 이 작업은 CouldntGetTask로 실패합니다. 이 문제는 kubeclient GET 요청에서 시크릿 이름이 비어 있지 않도록 방지하여 해결되었습니다.
  • 이제 v1beta1 API 버전이 있는 파이프라인은 finally 작업을 손실하지 않고 v1alpha1 버전과 함께 요청할 수 있습니다. 반환된 v1alpha1 버전을 적용하면 리소스가 v1beta1로 저장되고 finally 섹션은 원래 상태로 복원됩니다.
  • 이전에는 컨트롤러의 설정되지 않은 selfLink 필드로 인해 Kubernetes v1.20 클러스터에서 오류가 발생했습니다. 임시 수정으로 CloudEvent 소스 필드는 자동으로 채워진 selfLink 필드의 값이 없이 현재 소스 URI와 일치하는 값으로 설정됩니다.
  • 이전에는 gcr.io와 같은 점이 있는 시크릿 이름으로 인해 작업 실행 생성에 실패했습니다. 이는 내부적으로 볼륨 마운트 이름의 일부로 사용되는 시크릿 이름 때문에 발생했습니다. 볼륨 마운트 이름은 RFC1123 DNS 레이블을 준수하고, 이름의 일부로 점을 허용하지 않습니다. 이 문제는 점을 대시로 대체하여 읽을 수 있는 이름을 만들어 해결되었습니다.
  • 이제 finally 작업에서 컨텍스트 변수의 유효성을 검사합니다.
  • 이전 버전에서는 작업 실행 조정기에서 생성된 Pod 이름을 포함하는 이전 상태 업데이트가 없는 작업 실행을 통과하면 작업 실행 조정기는 작업 실행과 연결된 Pod를 나열했습니다. 작업 실행 조정기에서는 Pod에 전파된 작업 실행 레이블을 사용하여 Pod를 찾았습니다. 작업 실행 중에 이러한 레이블을 변경하면 코드에서 기존 pod를 찾지 못했습니다. 결과적으로 중복된 pod가 생성되었습니다. 이 문제는 Pod를 찾을 때 작업 실행 조정기를 tekton.dev/taskRun Tekton- controlled 라벨만 사용하도록 변경하여 해결되었습니다.
  • 이전 버전에서는 파이프라인에서 선택적 작업 영역을 수락하여 파이프라인 작업으로 전달하면 누락된 작업 공간 바인딩이 선택적 작업 공간에 유효한 상태인 경우에도 작업 영역을 제공하지 않은 경우 실행 조정기가 중지되어 오류가 발생했습니다. 이 문제는 선택적 작업 영역을 제공하지 않아도 파이프라인 실행 조정기에서 작업 실행을 생성하지 못하도록 하여 해결되었습니다.
  • 단계 상태의 정렬 순서는 단계 컨테이너의 순서와 일치합니다.
  • 이전에는 Pod에 CreateContainerConfigError가 발생할 때 작업 실행 상태가 unknown으로 설정되어 이로 인해 Pod가 시간 초과될 때까지 작업 및 파이프라인이 실행되었습니다. 이 문제는 Pod에 CreateContainerConfigError 이유가 발생할 때 작업이 실패로 설정되도록 작업 실행 상태를 false로 설정하여 해결되었습니다.
  • 이전에는 파이프라인 실행이 완료된 후 첫 번째 조정 시 파이프라인 결과가 해결되었습니다. 이로 인해 해결에 실패하여 파이프라인 실행의 Succeeded 조건을 덮어쓸 수 있습니다. 결과적으로 최종 상태 정보가 손실되어 파이프라인의 작동 조건을 모니터링하는 모든 서비스에 혼란을 줄 수 있습니다. 이 문제는 파이프라인 실행이 Succeeded 또는 True 조건이 될 때 파이프라인 결과의 해결을 조정의 끝으로 이동하여 해결됩니다.
  • 이제 실행 상태 변수가 확인됩니다. 이렇게 하면 실행 상태에 액세스하기 위해 컨텍스트 변수를 검증하는 동안 작업 결과를 확인하는 것을 방지할 수 있습니다.
  • 이전 버전에서는 잘못된 변수가 포함된 파이프라인 결과가 변수의 리터럴 표현식을 그대로 사용하여 파이프라인 실행에 추가되었습니다. 따라서 결과가 올바르게 설정되어 있는지를 평가하는 것은 쉽지 않았습니다. 이 문제는 실패한 작업 실행을 참조하는 파이프 라인 실행 결과 필터링하여 해결되었습니다. 이제 잘못된 변수가 포함된 파이프라인 결과는 파이프라인 실행에서 전혀 배출되지 않습니다.
  • tkn eventlistener describe 명령이 템플릿 없이 충돌하지 않도록 수정되었습니다. 트리거 참조에 대한 세부 정보도 표시합니다.
  • OpenShift Pipelines 1.3.x 및 이전 버전에서 OpenShift Pipelines 1.4.0으로 업그레이드하면 template.name 을 사용할 수 없으므로 이벤트 리스너가 중단됩니다. OpenShift Pipelines 1.4.1에서는 트리거에서 이벤트 리스너 중단을 방지하기 위해 template.name 이 복원되었습니다.
  • OpenShift Pipelines 1.4.1에서는 OpenShift Container Platform 4.7 기능 및 동작에 맞게 ConsoleQuickStart 사용자 정의 리소스가 업데이트되었습니다.

3.1.11. Red Hat OpenShift Pipelines Technology Preview 1.3 릴리스 정보

3.1.11.1. 새로운 기능

이제 OpenShift Container Platform 4.7에서 Red Hat OpenShift Pipelines TP(Technology Preview) 1.3을 사용할 수 있습니다. 다음을 지원하도록 Red Hat OpenShift Pipelines TP 1.3이 업데이트되었습니다.

  • Tekton Pipelines 0.19.0
  • Tekton tkn CLI 0.15.0
  • Tekton Triggers 0.10.2
  • Tekton Catalog 0.19.0 기반 클러스터 작업
  • OpenShift Container Platform 4.7의 IBM Power Systems
  • OpenShift Container Platform 4.7의 IBM Z 및 LinuxONE

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.3의 새로운 기능도 소개합니다.

3.1.11.1.1. 파이프라인
  • S2I 및 Buildah 작업과 같은 이미지를 빌드하는 작업에서 이제 이미지 SHA를 포함하는 빌드된 이미지의 URL을 내보냅니다.
  • Conditions CRD(사용자 정의 리소스 정의)가 더 이상 사용되지 않기 때문에 사용자 정의 작업을 참조하는 파이프라인 작업에서 조건이 비활성화되었습니다.
  • spec.steps[].imagePullPolicy 및 spec.sidecar[].imagePullPolicy의 Task CRD에 변수 확장이 추가되었습니다.
  • disable-creds-init 기능 플래그를 true로 설정하여 Tekton의 기본 제공 자격 증명 메커니즘을 비활성화할 수 있습니다.
  • 해결된 When 표현식이 PipelineRun 구성의 Status 필드에 있는 Skipped Tasks 및 Task Runs 섹션에 나열됩니다.
  • git init 명령으로 재귀 하위 모듈을 복제할 수 있습니다.
  • Task CR 작성자가 Task 사양에 있는 단계의 타임아웃을 지정할 수 있습니다.
  • 진입점 이미지의 기반을 distroless/static:nonroot 이미지로 하여 기본 이미지에 있는 cp 명령에 의존하지 않고도 대상에 자체 복사 모드를 제공할 수 있습니다.
  • 구성 플래그 require-git-ssh-secret-known-hosts를 사용하여 Git SSH 보안에서 알려진 호스트를 생략하지 않도록 할 수 있습니다. 플래그 값이 true로 설정된 경우 Git SSH 보안에 known_host 필드를 포함해야 합니다. 플래그 기본값은 false 입니다.
  • 선택적 작업 공간의 개념이 도입되었습니다. 작업 또는 파이프라인에서 작업 공간을 선택적으로 선언하고 작업 공간 존재 여부에 따라 조건부로 동작을 변경할 수 있습니다. 작업 실행 또는 파이프라인 실행에서도 해당 작업 공간을 생략하여 작업 또는 파이프라인 동작을 수정할 수 있습니다. 기본 작업 실행 작업 공간은 생략된 선택적 작업 공간 대신 추가되지 않습니다.
  • Tekton의 자격 증명 초기화 과정에서 SSH가 아닌 URL과 함께 사용되는 SSH 자격 증명을 감지하고 Git 파이프라인 리소스에서 그 반대의 경우도 마찬가지이며, 단계 컨테이너에 경고를 기록합니다.
  • Pod 템플릿에서 지정한 유사성을 유사성 도우미에서 덮어쓰는 경우 작업 실행 컨트롤러에서 경고 이벤트를 내보냅니다.
  • 작업 실행이 완료되면 작업 실행 조정기에서 내보낸 클라우드 이벤트에 대한 지표를 기록합니다. 여기에는 재시도 횟수가 포함됩니다.
3.1.11.1.2. Pipeline CLI
  • tkn condition list, tkn triggerbinding list, tkn eventlistener list, tkn clustertask list, tkn clustertriggerbinding list 명령에 --no-headers flag에 대한 지원이 추가되었습니다.
  • --last 또는 --use 옵션은 함께 사용 시 --prefix-name 및 --timeout 옵션을 덮어씁니다.
  • EventListener 로그를 볼 수 있도록 tkn eventlistener logs 명령이 추가되었습니다.
  • tekton hub 명령이 tkn CLI에 통합되었습니다.
  • --nocolour 옵션이 --no-color로 변경되었습니다.
  • tkn triggertemplate list, tkn condition list, tkn triggerbinding list, tkn eventlistener list 명령에 --all-namespaces 플래그가 추가되었습니다.
3.1.11.1.3. Trigger
  • EventListener 템플릿에 리소스 정보를 지정할 수 있습니다.
  • EventListener 서비스 계정에 모든 트리거 리소스에 대한 get 동사 외에 list 및 watch 동사도 있어야 합니다. 따라서 Listers를 사용하여EventListener, Trigger, TriggerBinding, TriggerTemplate, ClusterTriggerBinding 리소스에서 데이터를 가져올 수 있습니다. 이 기능을 사용하여 여러 정보원을 지정하지 않고 Sink 오브젝트를 생성하고 API 서버에 직접 호출할 수 있습니다.
  • 변경 불가능한 입력 이벤트 본문을 지원하기 위해 새로운 Interceptor 인터페이스가 추가되었습니다. 인터셉터에서 새 extensions 필드에 데이터 또는 필드를 추가할 수는 있지만 입력 본문을 수정하여 변경 불가능으로 설정할 수는 없습니다. CEL 인터셉터는 이 새로운 Interceptor 인터페이스를 사용합니다.
  • namespaceSelector 필드가 EventListener 리소스에 추가되었습니다. 이 필드는 EventListener 리소스에서 이벤트 처리를 위해 Trigger 오브젝트를 가져올 수 있는 네임스페이스를 지정하는 데 사용합니다. namespaceSelector 필드를 사용하려면 EventListener 서비스 계정에 클러스터 역할이 있어야 합니다.
  • 트리거 EventListener 리소스에서 eventlistener Pod에 대한 종단 간 보안 연결을 지원합니다.
  • "를 \"로 교체하여 TriggerTemplates 리소스의 이스케이프 매개변수 동작이 제거되었습니다.
  • Kubernetes 리소스를 지원하는 새로운 resources 필드가 EventListener 사양의 일부로 도입되었습니다.
  • ASCII 문자열의 대문자 및 소문자를 지원하는 CEL 인터셉터의 새 기능이 추가되었습니다.
  • 트리거의 name 및 value 필드를 사용하거나 이벤트 리스너를 사용하여 TriggerBinding 리소스를 포함할 수 있습니다.
  • PodSecurityPolicy 구성이 제한된 환경에서 실행되도록 업데이트되었습니다. 따라서 컨테이너를 루트로 실행해서는 안 됩니다. 또한 Pod 보안 정책 사용을 위한 역할 기반 액세스 제어가 클러스터 범위에서 네임스페이스 범위로 이동했습니다. 그 결과 트리거에서 네임스페이스와 관련이 없는 다른 Pod 보안 정책을 사용할 수 없습니다.
  • 포함된 트리거 템플릿에 대한 지원이 추가되었습니다. name 필드를 사용하여 포함된 템플릿을 참조하거나 템플릿을 spec 필드 내에 포함할 수 있습니다.

3.1.11.2. 사용되지 않는 기능

  • PipelineResources CRD를 사용하는 파이프라인 템플릿이 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다.
  • template.name 필드가 더 이상 template.ref 필드 대신 사용되지 않으며 향후 릴리스에서 제거됩니다.
  • --check 명령에 대한 -c 약어가 제거되었습니다. 또한 전역 tkn 플래그가 version 명령에 추가되었습니다.

3.1.11.3. 확인된 문제

  • CEL 오버레이는 들어오는 이벤트 본문을 수정하는 대신 새로운 최상위 extensions 함수에 필드를 추가합니다. TriggerBinding 리소스는 $(extensions.<key>) 구문을 사용하여 이 새로운 extensions 함수 내의 값에 액세스할 수 있습니다. $(body.<overlay-key>) 구문 대신 $(extensions.<key>) 구문을 사용하도록 바인딩을 업데이트합니다.
  • "를 \"로 교체하여 이스케이프 매개변수 동작이 제거되었습니다. 이전 이스케이프 매개변수 동작을 유지해야 하는 경우 TriggerTemplate 사양에 tekton.dev/old-escape-quotes: true" 주석을 추가합니다.
  • 트리거 내부의 name 및 value 필드를 사용하거나 이벤트 리스너를 사용하여 TriggerBinding 리소스를 포함할 수 있습니다. 그러나 단일 바인딩에 name 및 ref 필드를 둘 다 지정할 수는 없습니다. ref 필드를 사용하여 포함된 바인딩의 TriggerBinding 리소스 및 name 필드를 참조합니다.
  • 인터셉터는 EventListener 리소스의 네임스페이스 외부에 있는 secret을 참조할 수 없습니다. ‘EventListener’ 리소스의 네임스페이스에 보안을 포함해야 합니다.
  • Triggers 0.9.0 이상에서는 본문 또는 헤더 기반 TriggerBinding 매개변수가 이벤트 페이로드에서 누락되거나 잘못된 형식으로 되어 있는 경우 오류를 표시하는 대신 기본값을 사용합니다.
  • Tekton Pipelines 0.16.x를 사용하여 WhenExpressions 개체로 생성된 작업 및 파이프라인을 다시 적용하여 JSON 주석을 수정해야 합니다.
  • 파이프라인에서 선택적 작업 영역을 수락하고 이를 작업에 제공할 때 작업 영역을 제공하지 않으면 파이프라인 실행이 중단됩니다.
  • 연결이 끊긴 환경에서 Buildah 클러스터 작업을 사용하려면 Dockerfile에서 내부 이미지 스트림을 기본 이미지로 사용하는지 확인한 다음 모든 S2I 클러스터 작업과 동일한 방식으로 사용합니다.

3.1.11.4. 해결된 문제

  • 이벤트 본문에 Extensions 필드를 추가하면 CEL 인터셉터에서 추가한 확장이 Webhook 인터셉터에 전달됩니다.
  • LogOptions 필드를 사용하여 로그 리더에 대한 활동 타임아웃을 구성할 수 있습니다. 그러나 10초 내의 기본 타임아웃 동작은 유지됩니다.
  • log 명령은 작업 실행 또는 파이프라인 실행이 완료되면 --follow 플래그를 무시하고 라이브 로그 대신 사용 가능한 로그를 읽습니다.
  • Tekton 리소스(EventListener, TriggerBinding, ClusterTriggerBinding, Condition, TriggerTemplate)에 대한 참조가 표준화되어 tkn 명령의 모든 사용자 대상 메시지에 일관되게 표시됩니다.
  • 이전에는 --use-taskrun <canceled-task-run-name>, --use-pipelinerun <canceled-pipeline-run-name> 또는 --last 플래그를 사용하여 취소된 작업 실행 또는 파이프라인 실행을 시작하면 새 실행이 취소되었습니다. 이 버그가 해결되었습니다.
  • 파이프라인이 조건에 따라 실행되는 경우 실패하지 않도록 tkn pr desc 명령이 향상되었습니다.
  • tkn tr delete 명령을 --task 옵션과 함께 사용하여 작업을 삭제하고 이름이 동일한 클러스터 작업이 있는 경우 클러스터 작업의 작업 실행도 삭제됩니다. 이 문제를 해결하려면 TaskRefKind 필드를 사용하여 작업을 필터링합니다.
  • tkn triggertemplate describe 명령을 실행하면 출력에 apiVersion 값의 일부만 표시됩니다. 예를 들어 triggers.tekton.dev/v1alpha1 대신 triggers.tekton.dev만 표시되었습니다. 이 버그가 해결되었습니다.
  • Webhook는 특정 조건에서 리스를 가져오지 못하고 제대로 작동하지 않습니다. 이 버그가 해결되었습니다.
  • v0.16.3에서 생성된 When 표현식이 있는 파이프라인을 v0.17.1 이상에서 실행할 수 있습니다. 주석의 첫 글자로 대문자와 소문자가 모두 지원되므로 업그레이드 후 이전 버전에서 생성한 파이프라인 정의를 다시 적용할 필요가 없습니다.
  • 기본적으로 고가용성을 위해 leader-election-ha 필드가 활성화됩니다. disable-ha 컨트롤러 플래그를 true로 설정하면 고가용성 지원이 비활성화됩니다.
  • 중복된 클라우드 이벤트 문제가 수정되었습니다. 조건으로 인해 상태, 이유 또는 메시지가 변경될 때만 클라우드 이벤트가 전송됩니다.
  • PipelineRun 또는 TaskRun 사양에 서비스 계정 이름이 없는 경우 컨트롤러는 config-defaults 구성 맵의 서비스 계정 이름을 사용합니다. config-defaults 구성 맵에도 서비스 계정 이름이 없으면 컨트롤러에서 사양에 서비스 계정 이름을 default로 설정합니다.
  • 동일한 영구 볼륨 클레임이 여러 작업 공간에 사용되지만 하위 경로가 다른 경우 유사성 도우미와의 호환성을 검증하는 기능이 지원됩니다.

3.1.12. Red Hat OpenShift Pipelines Technology Preview 1.2 릴리스 정보

3.1.12.1. 새로운 기능

이제 OpenShift Container Platform 4.6에서 Red Hat OpenShift Pipelines TP(Technology Preview) 1.2를 사용할 수 있습니다. 다음을 지원하도록 Red Hat OpenShift Pipelines TP 1.2가 업데이트되었습니다.

  • Tekton Pipelines 0.16.3
  • Tekton tkn CLI 0.13.1
  • Tekton Triggers 0.8.1
  • Tekton Catalog 0.16 기반 클러스터 작업
  • OpenShift Container Platform 4.6의 IBM Power Systems
  • OpenShift Container Platform 4.6의 IBM Z 및 LinuxONE

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.2의 새로운 기능도 소개합니다.

3.1.12.1.1. 파이프라인

  • 이 Red Hat OpenShift Pipelines 릴리스에서는 오프라인 설치를 지원합니다.

    참고

    제한된 환경에서의 설치는 현재 IBM Power Systems, IBM Z, LinuxONE에서 지원되지 않습니다.

  • 이제 conditions 리소스 대신when 필드를 사용하여 특정 기준이 충족될 때만 작업을 실행할 수 있습니다. WhenExpression 리소스의 주요 구성 요소는Input, Operator, Values입니다. 모든 표현식이 True로 평가되면 작업이 실행됩니다. When 표현식이 False로 평가되면 작업을 건너뜁니다.
  • 작업 실행이 취소되거나 타임아웃되는 경우 단계 상태가 업데이트됩니다.
  • git-init에서 사용하는 기본 이미지를 빌드하는 데 Git LFS(Large File Storage) 지원이 제공됩니다.
  • taskSpec 필드를 사용하여 작업이 파이프라인에 포함된 경우 라벨 및 주석과 같은 메타데이터를 지정할 수 있습니다.
  • 파이프라인 실행에서 클라우드 이벤트를 지원합니다. 클라우드 이벤트 파이프라인 리소스에서 보내는 클라우드 이벤트에 backoff를 통해 재시도할 수 있습니다.
  • Task 리소스에서 선언해도 TaskRun 리소스에서 명시적으로 제공하지 않는 모든 작업 공간에 기본 Workspace 구성을 설정할 수 있습니다.
  • PipelineRun 네임스페이스 및 TaskRun 네임스페이스에 대한 네임스페이스 변수 보간을 지원합니다.
  • TaskRun 리소스가 유사성 도우미와 연결되어 있을 때 여러 개의 영구 볼륨 클레임 작업 공간이 사용되지 않는지 확인하기 위해 TaskRun 오브젝트에 대한 검증 작업이 추가되었습니다. 영구 볼륨 클레임 작업 공간이 두 개 이상 사용되면 TaskRunValidationFailed 조건이 포함된 작업 실행이 실패합니다. 기본적으로 유사성 도우미는 Red Hat OpenShift Pipelines에서 비활성화되어 있으므로 이 도우미를 사용하려면 활성화해야 합니다.
3.1.12.1.2. Pipeline CLI

  • tkn task describe, tkn taskrun describe, tkn clustertask describe, tkn pipeline describe, tkn pipelinerun describe 명령에서 다음을 수행합니다.

    • Task, TaskRun, ClusterTask, Pipeline, PipelineRun 리소스 중 하나만 있는 경우 각 리소스를 자동으로 선택합니다.
    • Task, TaskRun, ClusterTask, Pipeline, PipelineRun 리소스의 결과를 출력에 각각 표시합니다.
    • Task, TaskRun, ClusterTask, Pipeline, PipelineRun 리소스에 선언된 작업 공간을 각각 표시합니다.
  • tkn clustertask start 명령에 --prefix-name 옵션을 사용하여 작업 실행 이름에 접두사를 지정할 수 있습니다.
  • tkn clustertask start 명령에 대화형 모드가 지원됩니다.
  • TaskRun 및 PipelineRun 오브젝트에 대한 로컬 또는 원격 파일 정의를 사용하여 파이프라인에서 지원하는 PodTemplate 속성을 지정할 수 있습니다.
  • tkn clustertask start 명령에 --use-params-defaults 옵션을 사용하여 ClusterTask 구성에 설정된 기본값을 사용하고 작업 실행을 생성할 수 있습니다.
  • 일부 매개변수에 기본값이 지정되지 않은 경우 tkn pipeline start 명령의 --use-param-defaults 플래그는 대화형 모드를 표시합니다.
3.1.12.1.3. Trigger
  • parseYAML이라는 CEL(Common Expression Language) 함수가 추가되어 YAML 문자열을 문자열 맵으로 구문 분석합니다.
  • CEL 표현식 구문 분석에 대한 오류 메시지가 개선되어 표현식을 평가하는 동안 그리고 평가 환경을 생성하기 위해 후크 본문을 구문 분석할 때 더 세부적인 내용이 표시됩니다.
  • 부울 값 및 맵이 CEL 오버레이 메커니즘에서 표현식 값으로 사용되는 경우 부울 값 및 맵 마샬링이 지원됩니다.

  • 다음 필드가 EventListener 오브젝트에 추가되었습니다.

    • replicas 필드를 사용하면 YAML 파일의 복제본 수를 지정하여 이벤트 리스너에서 여러 개의 Pod를 실행할 수 있습니다.
    • NodeSelector 필드를 사용하면 EventListener 오브젝트에서 이벤트 리스너 Pod를 특정 노드에 예약할 수 있습니다.
  • Webhook 인터셉터에서 EventListener-Request-URL 헤더를 구문 분석하여 이벤트 리스너로 처리 중인 원래 요청 URL에서 매개변수를 추출할 수 있습니다.
  • 이벤트 리스너에 있는 주석을 배포 Pod, 서비스 Pod 및 기타 Pod로 전파할 수 있습니다. 서비스 또는 배포에 대한 사용자 정의 주석을 덮어쓰므로 해당 주석을 전파하려면 이벤트 리스너 주석에 추가해야 합니다.
  • 사용자가 spec.replicas 값을 negative 또는 zero로 지정하는 경우에도 EventListener 사양의 복제본을 올바르게 검증할 수 있습니다.
  • TriggerRef 필드를 통해 EventListener 사양 내의 TriggerCRD 오브젝트를 참조로 지정하여 TriggerCRD 오브젝트를 별도로 생성한 다음 EventListener 사양 내에서 바인딩할 수 있습니다.
  • TriggerCRD 오브젝트에 검증을 수행하고 기본값을 사용할 수 있습니다.

3.1.12.2. 사용되지 않는 기능

  • 이제 resourcetemplate과 triggertemplate 리소스 매개변수를 혼동하지 않도록 $(params) 매개변수가 triggertemplate 리소스에서 제거되고 $(tt.params)로 대체되었습니다.
  • 선택적 EventListenerTrigger 기반 인증 수준의 ServiceAccount 참조가 오브젝트 참조에서 ServiceAccountName 문자열로 변경되었습니다. 이로 인해 ServiceAccount 참조가 EventListenerTrigger 오브젝트와 동일한 네임스페이스에 있습니다.
  • Conditions CRD(사용자 정의 리소스 정의)가 더 이상 사용되지 않습니다. 대신 WhenExpressions CRD를 사용합니다.
  • PipelineRun.Spec.ServiceAccountNames 오브젝트가 더 이상 사용되지 않고 PipelineRun.Spec.TaskRunSpec[].ServiceAccountName 오브젝트로 교체됩니다.

3.1.12.3. 확인된 문제

  • 이 Red Hat OpenShift Pipelines 릴리스에서는 오프라인 설치를 지원합니다. 그러나 클러스터 작업에서 사용하는 일부 이미지는 연결이 끊긴 클러스터에서 작업하려면 미러링해야 합니다.
  • openshift 네임스페이스의 파이프라인은 Red Hat OpenShift Pipelines Operator를 설치 제거한 후에도 삭제되지 않습니다. 이 파이프라인을 삭제하려면 oc delete pipelines -n openshift --all 명령을 사용합니다.

  • Red Hat OpenShift Pipelines Operator를 설치 제거해도 이벤트 리스너는 제거되지 않습니다.

    해결 방법은 EventListener 및 Pod CRD를 제거하는 것입니다.

    1. foregroundDeletion 종료자를 사용하여 EventListener 오브젝트를 다음과 같이 편집합니다. 

      $ oc patch el/<eventlistener_name> -p '{"metadata":{"finalizers":["foregroundDeletion"]}}' --type=merge

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

      $ oc patch el/github-listener-interceptor -p '{"metadata":{"finalizers":["foregroundDeletion"]}}' --type=merge

    2. EventListener CRD를 삭제합니다. 

      $ oc patch crd/eventlisteners.triggers.tekton.dev -p '{"metadata":{"finalizers":[]}}' --type=merge

  • IBM Power Systems(ppc64le) 또는 IBM Z(s390x) 클러스터에서 명령 사양 없이 다중 아키텍처 컨테이너 이미지 작업을 실행하면 TaskRun 리소스가 실패하고 다음 오류 메시지가 표시됩니다. 

    Error executing command: fork/exec /bin/bash: exec format error

    해결 방법은 아키텍처별 컨테이너 이미지를 사용하거나 sha256 다이제스트를 지정하여 올바른 아키텍처를 가리키는 것입니다. sha256 다이제스트를 가져오려면 다음을 입력합니다. 

    $ skopeo inspect --raw <image_name>| jq '.manifests[] | select(.platform.architecture == "<architecture>") | .digest'

3.1.12.4. 해결된 문제

  • CEL 필터, Webhook 유효성 검증기의 오버레이, 인터셉터의 표현식을 확인하는 간단한 구문 검증 기능이 추가되었습니다.
  • Trigger가 더 이상 기본 배포 및 서비스 오브젝트에 설정된 주석을 덮어쓰지 않습니다.
  • 이전에는 이벤트 리스너에서 이벤트 수락을 중지했습니다. 이 수정에서는 이 문제를 해결하기 위해 EventListener 싱크에 120초의 유휴 상태 타임아웃이 추가되었습니다.
  • 이전에는 Failed(Canceled) 상태로 파이프라인 실행을 취소하면 성공 메시지가 표시되었습니다. 이제 오류 메시지를 표시하도록 수정되었습니다.
  • tkn eventlistener list 명령에서 나열된 이벤트 리스너의 상태를 제공하므로 사용 가능한 리스너를 쉽게 확인할 수 있습니다.
  • 트리거가 설치되지 않았거나 리소스가 없는 경우 triggers list 및 triggers describe 명령에 대한 오류 메시지가 일관되게 표시됩니다.
  • 이전에는 클라우드 이벤트를 제공하는 동안 다수의 유휴 연결이 빌드되었습니다. 이 문제를 해결하기 위해 cloudeventclient 구성에 DisableKeepAlives: true 매개변수가 추가되었습니다. 따라서 모든 클라우드 이벤트에 대해 새로운 연결이 설정됩니다.
  • 이전에는 지정된 유형의 자격 증명이 제공되지 않은 경우에도 creds-init 코드에서 디스크에 빈 파일을 작성했습니다. 이번 수정에서는 올바른 주석이 있는 보안에서 실제로 마운트된 자격 증명이 있는 경우에만 파일을 작성하도록 creds-init 코드를 수정했습니다.

3.1.13. Red Hat OpenShift Pipelines Technology Preview 1.1 릴리스 정보

3.1.13.1. 새로운 기능

이제 OpenShift Container Platform 4.5에서 Red Hat OpenShift Pipelines TP(Technology Preview) 1.1을 사용할 수 있습니다. 다음을 지원하도록 Red Hat OpenShift Pipelines TP 1.1이 업데이트되었습니다.

  • Tekton Pipelines 0.14.3
  • Tekton tkn CLI 0.11.0
  • Tekton Triggers 0.6.1
  • Tekton Catalog 0.14 기반 클러스터 작업

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.1의 새로운 기능도 소개합니다.

3.1.13.1.1. 파이프라인
  • 이제 파이프라인 리소스 대신 작업 공간을 사용할 수 있습니다. 파이프라인 리소스는 디버그하기 어렵고 범위가 제한되며 작업의 재사용 가능성을 낮추기 때문에 OpenShift Pipelines에서 작업 공간을 사용할 것을 권장합니다. 작업 공간에 대한 자세한 내용은 OpenShift Pipelines 이해 섹션을 참조하십시오.

  • 볼륨 클레임 템플릿에 대한 작업 공간 지원이 추가되었습니다.

    • 이제 파이프 라인 실행 및 작업 실행에 대한 볼륨 클레임 템플릿을 작업 공간의 볼륨 소스로서 추가할 수 있습니다. 그런 다음 tekton-controller가 파이프라인의 모든 작업 실행에 대해 PVC로 표시되는 템플릿을 사용하여 PVC(PersistentVolumeClaim)를 생성합니다. 따라서 여러 Task에 걸쳐 있는 작업 공간을 바인드할 때마다 PVC 구성을 정의해야 합니다.
    • 볼륨 클레임 템플릿이 볼륨 소스로 사용될 때 PVC의 이름 검색 지원에서 이제 변수 대체를 사용할 수 있습니다.

  • 감사 개선 지원:

    • 이제 PipelineRun.Status 필드에 파이프라인의 모든 작업 실행 상태와 파이프라인 실행의 진행 상황을 모니터링하기 위해 파이프라인 실행을 인스턴스화하는 데 사용되는 파이프라인 사양이 포함됩니다.
    • Pipeline 결과가 Pipeline 사양 및 PipelineRun 상태에 추가되었습니다.
    • 이제 TaskRun.Status 필드에 TaskRun 리소스를 인스턴스화하는 데 사용되는 정확한 작업 사양이 포함됩니다.
  • 조건에 기본 매개변수 적용을 지원합니다.
  • 클러스터 작업을 참조하여 생성된 작업 실행이 이제 tekton.dev/task 레이블 대신 tekton.dev/clusterTask 레이블을 추가합니다.
  • 이제 kubeconfigwriter가 리소스 구조에 ClientKeyData 및 ClientCertificateData 구성을 추가하여 파이프라인 리소스 유형 클러스터를 kubeconfig-creator 작업으로 교체할 수 있습니다.
  • 이제 feature-flags 및 config-defaults 구성 맵의 이름을 이제 사용자 지정할 수 있습니다.
  • 작업 실행에서 사용하는 pod 템플릿에서 호스트 네트워크에 대한 지원을 사용할 수 있습니다.
  • 이제 Affinity Assistant를 사용하여 작업 공간 볼륨을 공유하는 작업 실행에서 노드 선호도를 지원할 수 있습니다. OpenShift Pipelines에서는 기본적으로 노드 선호도가 비활성화됩니다.
  • Pod 템플릿이 imagePullSecrets를 지정하도록 업데이트되어 Pod를 시작할 때 컨테이너 런타임에서 컨테이너 이미지 가져오기를 승인하는 데 사용할 보안을 확인합니다.
  • 컨트롤러가 작업 실행을 업데이트하지 못하는 경우 작업 실행 컨트롤러에서 경고 이벤트를 발송하도록 지원합니다.
  • 애플리케이션 또는 구성 요소에 속하는 리소스를 식별하도록 표준 또는 권장 k8s 레이블이 모든 리소스에 추가되었습니다.
  • 이제 Entrypoint 프로세스에 신호 알림이 전송되며, 이러한 신호는 Entrypoint 프로세스의 전용 PID Group을 사용하여 전파됩니다.
  • 이제 작업 실행 사양을 사용하여 런타임에 작업 수준에서 pod 템플릿을 설정할 수 있습니다.

  • Kubernetes 이벤트 발송 지원 :

    • 이제 컨트롤러가 추가 작업 실행 수명 주기 이벤트(taskrun started 및 taskrun running)에 대한 이벤트를 발송합니다.
    • 이제 파이프라인 실행 컨트롤러가 파이프라인이 시작될 때마다 이벤트를 발송합니다.
  • 이제 기본 Kubernetes 이벤트 외에 작업 실행에 대한 클라우드 이벤트 지원도 제공됩니다. 생성, 시작 및 실패와 같은 작업 실행 이벤트를 클라우드 이벤트로서 발송하도록 컨트롤러를 구성할 수 있습니다.
  • 파이프라인 실행 및 작업 실행에서 적절한 이름을 참조하도록 $context.<task|taskRun|pipeline|pipelineRun>.name 변수 사용을 지원합니다.
  • 이제 파이프라인 실행 매개변수에 대한 유효성 검사를 사용하여 파이프라인 실행에서 파이프라인에 필요한 모든 매개변수가 제공되는지 확인할 수 있습니다. 이를 통해 파이프라인 실행에서 필수 매개변수 외에 추가 매개변수도 제공할 수 있습니다.
  • 이제 파이프라인 YAML 파일의 finally 필드를 사용하여 모든 작업을 성공적으로 완료한 후 또는 파이프라인의 작업 중 하나가 실패한 후 파이프라인이 종료되기 전에 항상 실행될 파이프라인 내 작업을 지정할 수 있습니다.
  • 이제 git-clone 클러스터 작업을 사용할 수 있습니다.
3.1.13.1.2. Pipeline CLI
  • 이제 포함된 트리거 바인딩 지원을 tkn evenlistener describe 명령에 사용할 수 있습니다.
  • 하위 명령을 권장하고 잘못된 하위 명령을 사용할 때 의견을 제시하는 기능을 지원합니다.
  • 이제 파이프라인에 작업이 한 개뿐인 경우 tkn task describe 명령에 의해 작업이 자동으로 선택됩니다.
  • 이제 tkn task start 명령에 --use-param-defaults 플래그를 지정하여 기본 매개변수 값으로 작업을 시작할 수 있습니다.
  • 이제 tkn pipeline start 또는 tkn task start 명령과 함께 --workspace 옵션을 사용하여 파이프라인 실행 또는 작업 실행에 대한 볼륨 클레임 템플릿을 지정할 수 있습니다.
  • 이제 tkn pipelinerun logs 명령으로 finally 섹션에 나열된 최종 Task에 대한 로그를 표시할 수 있습니다.
  • 이제 tkn task start 명령과 함께 pipeline, pipelinerun, task, taskrun, clustertask, pipelineresource와 같은 tkn 리소스에 대한 describe 하위 명령에 대화형 모드가 지원됩니다.
  • 이제 tkn version 명령으로 클러스터에 설치된 트리거의 버전을 표시할 수 있습니다.
  • 이제 tkn pipeline describe 명령으로 파이프라인에 사용된 작업에 대해 지정된 매개변수 값과 시간초과 사항을 표시할 수 있습니다.
  • tkn pipelinerun describe 및 tkn taskrun describe 명령에 가장 최근 파이프라인 실행 또는 작업 실행을 각각 설명하는 --last 옵션에 대한 지원이 추가되었습니다.
  • 이제 tkn pipeline describe 명령으로 파이프라인의 작업에 적용 가능한 조건을 표시할 수 있습니다.
  • 이제 tkn resource list 명령과 함께 --no-headers 및 --all-namespaces 플래그를 사용할 수 있습니다.
3.1.13.1.3. Trigger

  • 이제 다음과 같은 CEL(Common Expression Language) 기능을 사용할 수 있습니다.

    • URL의 일부를 구문 분석하고 추출하기 위한 parseURL
    • deployment WebHook의 payload 필드에 있는 문자열에 포함된 JSON 값 유형을 구문 분석하는 parseJSON
  • Bitbucket의 WebHook에 대한 새로운 인터셉터가 추가되었습니다.
  • 이제 이벤트 리스너가 kubectl get 명령으로 나열될 때 추가 필드로 Address URL 및 Available status를 표시합니다.
  • 트리거 템플릿과 리소스 템플릿 매개변수 간의 혼동을 줄이기 위해 이제 트리거 템플릿 매개변수에 $(params.<paramName>) 대신 $(tt.params.<paramName>) 구문을 사용합니다.
  • 보안 또는 관리 문제로 인해 모든 노드가 오염된 경우에도 이벤트 리스너가 동일한 구성으로 배포되도록 EventListener CRD에 tolerations를 추가할 수 있습니다.
  • 이제 URL/live에서 이벤트 리스너 배포에 대한 준비 프로브를 추가할 수 있습니다.
  • 이벤트 리스너 트리거에 TriggerBinding 사양을 포함하기 위한 지원이 추가되었습니다.
  • 이제 권장 app.kubernetes.io 레이블을 사용하여 Trigger 리소스에 주석을 삽입할 수 있습니다.

3.1.13.2. 사용되지 않는 기능

이 릴리스에서는 더 이상 사용되지 않은 기능은 다음과 같습니다.

  • clustertask 및 clustertriggerbinding 명령을 포함하여 모든 클러스터 단위 명령에 --namespace 또는 -n 플래그는 더 이상 사용되지 않습니다. 향후 릴리스에서 제거됩니다.
  • 이벤트 리스너 내 triggers.bindings의 name 필드가 더 이상 사용되지 않고 향후 릴리스에서 제거될 것이며 ref 필드 사용을 권장합니다.
  • 파이프라인 변수 보간 구문과 혼동을 줄이기 위해 $(params)를 사용한 트리거 템플릿의 변수 보간은 더 이상 사용되지 않고, $(tt.params) 사용을 권장합니다. $(params.<paramName>) 구문은 향후 릴리스에서 제거됩니다.
  • 클러스터 작업에서 tekton.dev/task 레이블이 더 이상 사용되지 않습니다.
  • TaskRun.Status.ResourceResults.ResourceRef 필드가 더 이상 사용되지 않으며 제거됩니다.
  • tkn pipeline create, tkn task create 및 tkn resource create -f 하위 명령이 제거되었습니다.
  • tkn 명령에서 네임스페이스 유효성 검사가 제거되었습니다.
  • 기본 시간 초과 1h와 tkn ct start 명령에 대한 -t 플래그가 제거되었습니다.
  • s2i 클러스터 작업이 더 이상 사용되지 않습니다.

3.1.13.3. 확인된 문제

  • 조건에서 작업 공간을 지원하지 않습니다.
  • tkn clustertask start 명령에 --workspace 옵션과 대화형 모드가 지원되지 않습니다.
  • $(params.<paramName>) 구문의 역호환성 지원에 따라 파이프라인 특정 매개변수와 함께 트리거 템플릿을 사용하도록 수정되었습니다. 이는 트리거 WebHook에서 트리거 매개변수를 파이프라인 매개변수와 구별할 수 없기 때문입니다.
  • tekton_taskrun_count 및 tekton_taskrun_duration_seconds_count에 대한 promQL 쿼리를 실행할 때 Pipeline 메트릭이 잘못된 값을 보고합니다.
  • 작업 공간에 제공된 기존 PVC 이름이 없는 경우에도 파이프라인 실행 및 작업 실행이 Running 및 Running(Pending) 상태를 각각 유지합니다.

3.1.13.4. 해결된 문제

  • 이전에는 작업과 클러스터 작업 이름이 동일할 때 tkn task delete<name>--trs 명령으로 작업과 클러스터 작업이 모두 삭제되었습니다. 이번 수정에서는 이 명령으로 작업 <name>에 의해 생성된 작업 실행만 삭제됩니다.
  • 이전에는 tkn pr delete -p<name>--keep 2 명령을 --keep 플래그와 함께 사용할 때 -p 플래그가 무시되고 최근 두 개를 제외한 모든 파이프라인 실행이 삭제되었습니다. 이번 수정에서는 이 명령으로 최근 두 개를 제외하고 파이프라인 <name>에 의해 생성된 파이프라인 실행만 삭제됩니다.
  • 이제 tkn triggertemplate describe 출력에 YAML 형식 대신 테이블 형식으로 리소스 템플릿이 표시됩니다.
  • 전에는 컨테이너에 새 사용자를 추가할 때 buildah 클러스터 작업이 실패했습니다. 수정판에서는 이러한 문제가 해결되었습니다.

3.1.14. Red Hat OpenShift Pipelines Technology Preview 1.0 릴리스 정보

3.1.14.1. 새로운 기능

이제 OpenShift Container Platform 4.4에서 Red Hat OpenShift Pipelines TP(Technology Preview) 1.0을 사용할 수 있습니다. 다음을 지원하도록 Red Hat OpenShift Pipelines TP 1.0이 업데이트되었습니다.

  • Tekton Pipelines 0.11.3
  • Tekton tkn CLI 0.9.0
  • Tekton Triggers 0.4.0
  • Tekton Catalog 0.11 기반 클러스터 작업

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift Pipelines 1.0의 새로운 기능도 소개합니다.

3.1.14.1.1. 파이프라인
  • v1beta1 API 버전을 지원합니다.
  • 개선된 제한 범위를 지원합니다. 이전에는 작업 실행 및 파이프라인 실행에 대해서만 제한 범위를 지정했습니다. 이제 제한 범위를 명시적으로 지정할 필요가 없습니다. 네임스페이스의 최소 제한 범위가 사용됩니다.
  • 작업 결과 및 작업 매개 변수를 사용하여 작업 간 데이터 공유를 지원합니다.
  • 이제 HOME 환경 변수와 단계의 작업 디렉토리를 덮어쓰지 않도록 파이프라인을 구성할 수 있습니다.
  • 작업 단계와 유사하게 sidecars가 이제 스크립트 모드를 지원합니다.
  • 이제 작업 실행 podTemplate 리소스에서 다른 스케줄러 이름을 지정할 수 있습니다.
  • Star Array Notation을 사용한 변수 대체를 지원합니다.
  • 이제 개별 네임스페이스를 모니터링하도록 Tekton 컨트롤러를 구성할 수 있습니다.
  • 이제 새로운 설명 필드가 파이프라인, 작업, 클러스터 작업, 리소스 및 조건의 사양에 추가되었습니다.
  • Git 파이프라인 리소스에 프록시 매개변수를 추가합니다.
3.1.14.1.2. Pipeline CLI
  • 이제 EventListener, Condition, TriggerTemplate, ClusterTask, TriggerSBinding와 같은 tkn 리소스에 describe 하위 명령이 추가됩니다.
  • v1alpha1에 대한 이전 버전과의 호환성과 함께 ClusterTask, Task, Pipeline, PipelineRun, TaskRun 리소스에 v1beta1 지원이 추가되었습니다.

  • 이제 tkn task list,tkn pipeline list,tkn taskrun list,tkn pipelinerun list와 같은 --all-namespaces 플래그 옵션을 사용하여 모든 네임스페이스의 출력을 나열할 수 있습니다.

    --no-headers 플래그 옵션을 사용하면 명령의 출력에 헤더 없이 정보가 표시되도록 향상되었습니다.

  • 이제 tkn pipelines start 명령에서 --use-param-defaults 플래그를 지정하여 기본 매개변수 값을 사용하여 파이프라인을 시작할 수 있습니다.
  • 이제 tkn pipeline start 및 tkn task start 명령에 작업 공간에 대한 지원이 추가되었습니다.
  • describe, delete, list 하위 명령과 함께 이제 새로운 clustertriggerbinding 명령이 추가되었습니다.
  • 이제 로컬 또는 원격 yaml 파일을 사용하여 Pipeline Run을 직접 시작할 수 있습니다.
  • 이제 describe 하위 명령이 이제 보강되고 상세한 출력을 표시합니다. description, timeout, param description 및 sidecar status와 같은 새로운 필드가 추가되면서 특정 tkn 리소스에 대한 자세한 정보가 명령 출력에 제공됩니다.
  • 네임스페이스에 있는 작업이 한 개뿐인 경우 tkn task log 명령으로 바로 로그를 표시할 수 있습니다.
3.1.14.1.3. Trigger
  • 트리거 (Trigger)가 이제 v1alpha1 및 v1beta1 파이프라인 리소스를 모두 생성할 수 있습니다.
  • 새로운 CEL(Common Expression Language) 인터셉터 기능 -compareSecret 지원 이 기능은 보안을 유지하면서 문자열을 CEL 표현식의 보안과 비교합니다.
  • 이벤트 리스너 트리거 수준에서 인증 및 승인을 지원합니다.

3.1.14.2. 사용되지 않는 기능

이 릴리스에서는 더 이상 사용되지 않은 기능은 다음과 같습니다.

  • Steps 사양의 환경 변수 $HOME 및 변수 workingDir은 더 이상 사용되지 않으며 향후 릴리스에서 변경될 수 있습니다. 현재 Step 컨테이너의 HOME 및 workingDir 매개 변수가 /tekton/home과 /workspace을 각각 덮어씁니다.

    향후 릴리스에서 이 두 필드는 수정되지 않으며, 컨테이너 이미지 및 Task YAML에 정의된 값으로 설정될 것입니다. 이번 릴리스에서는 disable-home-env-overwrite 및 disable-working-directory-overwrite 플래그를 사용하여 HOME 및 workingDir 변수의 덮어쓰기 기능을 비활성화하십시오.

  • 다음 명령은 더 이상 사용되지 않는 명령들이며 향후 릴리스에서 제거될 수 있습니다: tkn pipeline create, tkn task create
  • tkn resource create 명령과 함께 -f 플래그가 더 이상 사용되지 않습니다. 향후 릴리스에서 제거될 수 있습니다.
  • tkn clustertask create 명령에서 -t 플래그와 --timeout 플래그(초 형식)가 더 이상 사용되지 않습니다. 이제 지속 시간 초과 형식만 지원됩니다(예: 1h30s). 더 이상 사용되지 않는 이러한 플래그는 향후 릴리스에서 제거될 수 있습니다.

3.1.14.3. 확인된 문제

  • 이전 버전의 Red Hat OpenShift Pipelines에서 업그레이드하는 경우 Red Hat OpenShift Pipelines 버전 1.0으로 업그레이드하기 전에 기존 배포를 삭제해야 합니다. 기존 배포를 삭제하려면 먼저 사용자 정의 리소스를 삭제한 다음 Red Hat OpenShift Pipelines Operator를 설치 제거해야 합니다. 자세한 내용은 Red Hat OpenShift Pipeline 설치 제거 섹션을 참조하십시오.
  • 동일한 v1alpha1 작업을 두 번 이상 제출하면 오류가 발생합니다. v1alpha1 작업을 다시 제출할 때 oc apply 대신 oc replace 명령을 사용하십시오.

  • 컨테이너에 사용자가 새로 추가되면 buildah 클러스터 작업이 작동하지 않습니다.

    Operator가 설치되면 buildah 클러스터 작업에 대한 --storage-driver 플래그가 지정되지 않으므로 플래그가 기본값으로 설정됩니다. 스토리지 드라이버가 잘못 설정되는 경우도 발생할 수 있습니다. 사용자가 새로 추가되면 잘못된 스토리지 드라이버로 인해 다음 오류가 발생되면서 buildah 클러스터 작업이 실패합니다. 

    useradd: /etc/passwd.8: lock file already used
useradd: cannot lock /etc/passwd; try again later.

    이 문제를 해결하려면 buildah-task.yaml 파일에서 --storage-driver 플래그 값을 overlay로 직접 설정하십시오.

    1. cluster-admin 권한으로 클러스터에 로그인합니다. 

      $ oc login -u <login> -p <password> https://openshift.example.com:6443

    2. oc edit 명령을 사용하여 buildah 클러스터 작업을 편집합니다. 

      $ oc edit clustertask buildah

      buildah clustertask YAML 파일의 현재 버전이 EDITOR 환경 변수에 의해 설정된 편집기에서 열립니다.

    3. Steps 필드에서 다음 command 필드를 찾습니다. 

       command: ['buildah', 'bud', '--format=$(params.FORMAT)', '--tls-verify=$(params.TLSVERIFY)', '--layers', '-f', '$(params.DOCKERFILE)', '-t', '$(resources.outputs.image.url)', '$(params.CONTEXT)']

    4. command 필드를 다음으로 변경합니다. 

       command: ['buildah', '--storage-driver=overlay', 'bud', '--format=$(params.FORMAT)', '--tls-verify=$(params.TLSVERIFY)', '--no-cache', '-f', '$(params.DOCKERFILE)', '-t', '$(params.IMAGE)', '$(params.CONTEXT)']
    5. 파일을 저장하고 종료합니다.

    또는 Pipelines → Cluster Tasks → buildah로 이동하여 웹 콘솔에서 직접 buildah 클러스터 작업 YAML 파일을 수정할 수도 있습니다. Actions 메뉴에서 Edit Cluster Task를 선택하고 이전 프로시저에서 안내한 대로 command 필드를 변경합니다.

3.1.14.4. 해결된 문제

  • 이전에는 이미지 빌드가 이미 진행 중인 경우에도 DeploymentConfig 작업이 새 배포 빌드를 트리거했습니다. 이로 인해 파이프라인 배포가 실패로 끝납니다. 수정판에서는 진행 중인 배포를 마칠 때까지 대기하는 oc rollout status 명령으로 이제 deploy task 명령을 대체합니다.
  • APP_NAME 매개변수에 대한 지원이 이제 파이프라인 템플릿에 추가됩니다.
  • 전에는 Java S2I용 파이프라인 템플릿이 레지스트리에서 이미지를 찾지 못했습니다. 수정판에서는 사용자가 제공한 IMAGE_NAME 매개변수 대신 기존 이미지 파이프라인 리소스를 사용하여 이미지를 검색합니다.
  • 이제 모든 OpenShift Pipelines 이미지가 Red Hat UBI(Universal Base Images, 범용 기본 이미지)를 기반으로 합니다.
  • 전에는 tekton-pipelines 이외 네임스페이스에 파이프라인을 설치했을 때 tkn version 명령에서 파이프라인 버전을 unknown으로 표시했습니다. 수정판에서는 tkn version 명령으로 이제 모든 네임스페이스에 올바른 파이프라인 버전을 표시할 수 있습니다.
  • tkn version 명령에 더 이상 -c 플래그가 지원되지 않습니다.
  • 관리자 권한이 없는 사용자도 이제 클러스터 트리거 비인딩 목록을 볼 수 있습니다.
  • CEL 인터셉터에 대한 이벤트 리스너 CompareSecret 기능이 수정되었습니다.
  • 작업과 클러스터 작업의 이름이 같은 경우 작업 및 클러스터 작업에 대한 list, describe 및 start 하위 명령의 출력이 이제 올바르게 표시됩니다.
  • 이전에는 OpenShift Pipelines Operator에서 권한이 필요한 SCC(보안 컨텍스트 제약 조건)를 수정하여 클러스터 업그레이드 도중 오류가 발생했습니다. 이 오류는 이제 수정되었습니다.
  • tekton-pipelines 네임스페이스에서 모든 작업 실행 및 파이프라인 실행의 시간 초과 값이 이제 구성 맵을 사용하여 default-timeout-minutes 필드 값으로 설정됩니다.
  • 전에는 관리자 권한이 없는 사용자에게는 웹 콘솔의 파이프라인 섹션이 표시되지 않았습니다. 이 문제는 이제 해결되었습니다.

3.2. OpenShift Pipelines 이해

Red Hat OpenShift Pipelines는 Kubernetes 리소스 기반의 클라우드 네이티브 CI/CD(연속 통합 및 연속 제공) 솔루션입니다. Tekton 빌딩 블록을 사용하여 기본 구현 세부 사항을 요약함으로써 여러 플랫폼에서 배포를 자동화합니다. Tekton은 Kubernetes 배포 전반에서 이식 가능한 CI/CD Pipeline을 정의하는 데 사용되는 여러 가지 표준 CRD(Custom Resource Definitions)를 도입합니다.

3.2.1. 주요 기능

  • Red Hat OpenShift Pipelines는 격리된 컨테이너에서 필요한 모든 종속 항목이 포함된 파이프라인을 실행하는 서버리스 CI/CD 시스템입니다.
  • Red Hat OpenShift Pipelines는 마이크로 서비스 기반 아키텍처에서 작업하는 분산된 팀을 위해 설계되었습니다.
  • Red Hat OpenShift Pipelines는 쉽게 확장하고 기존 Kubernetes 툴과 통합할 수 있는 표준 CI/CD 파이프라인 정의를 사용하므로 필요에 따라 스케일링할 수 있습니다.
  • Red Hat OpenShift Pipelines를 사용하면 모든 Kubernetes 플랫폼에서 이식 가능한 S2I(Source-to-Image), Buildah, Buildpacks, Kaniko 등의 Kubernetes 툴로 이미지를 빌드할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔 개발자 화면을 사용하여 Tekton 리소스를 생성하고, 파이프라인 실행 로그를 보고, OpenShift Container Platform 네임스페이스에서 파이프라인을 관리할 수 있습니다.

3.2.2. OpenShift Pipelines 개념

이 안내서에서는 다양한 파이프라인 개념을 소개합니다.

3.2.2.1. 작업

작업 리소스는 파이프라인 구성 블록이며 순차적으로 실행되는 단계로 구성됩니다. 기본적으로 입력 및 출력의 기능입니다. 개별적으로 또는 파이프라인의 일부로 작업을 실행할 수 있습니다. 작업은 재사용이 가능하며 여러 파이프라인에서 사용할 수 있습니다.

Steps 는 작업에서 순차적으로 실행하고 이미지 빌드와 같은 특정 목표를 달성하는 일련의 명령입니다. 모든 작업은 Pod로 실행되고 각 단계는 해당 Pod 내에서 컨테이너로 실행됩니다. 단계가 동일한 Pod 내에서 실행되므로 파일, 구성 맵 및 보안을 캐싱하기 위해 동일한 볼륨에 액세스할 수 있습니다.

다음 예제에서는 apply-manifests 작업을 보여줍니다. 

apiVersion: tekton.dev/v1beta1 1
kind: Task 2
metadata:
  name: apply-manifests 3
spec: 4
  workspaces:
  - name: source
  params:
    - name: manifest_dir
      description: The directory in source that contains yaml manifests
      type: string
      default: "k8s"
  steps:
    - name: apply
      image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
      workingDir: /workspace/source
      command: ["/bin/bash", "-c"]
      args:
        - |-
          echo Applying manifests in $(params.manifest_dir) directory
          oc apply -f $(params.manifest_dir)
          echo -----------------------------------
1
작업 API 버전 v1beta1.
2
Kubernetes 오브젝트 유형은 Task입니다.
3
이 작업의 고유 이름입니다.
4
작업의 매개 변수 및 단계 목록과 작업에서 사용하는 작업 공간입니다.

이 작업은 Pod를 시작하고 해당 Pod 내에서 지정된 이미지를 사용하여 컨테이너를 실행하여 지정된 명령을 실행합니다.

참고

OpenShift Pipelines 1.6부터 YAML 파일의 다음 기본값이 제거됩니다.

  • HOME 환경 변수는 기본적으로 /tekton/home 디렉터리가 아닙니다.
  • workingDir 필드는 기본적으로 /workspace 디렉터리가 아닙니다.

대신 단계의 컨테이너는 HOME 환경 변수와 workingDir 필드를 정의합니다. 그러나 단계에 YAML 파일에 사용자 지정 값을 지정하여 기본값을 덮어쓸 수 있습니다.

임시 조치로 이전 OpenShift Pipelines 버전과의 역호환성을 유지하기 위해 TektonConfig 사용자 정의 리소스 정의에서 다음 필드를 false 로 설정할 수 있습니다. 

spec:
  pipeline:
    disable-working-directory-overwrite: false
    disable-home-env-overwrite: false

3.2.2.2. when 표현식

When 표현식은 파이프라인 내에서 작업 실행 기준을 설정하여 작업 실행을 보호합니다. 여기에는 특정 기준이 충족될 때만 작업을 실행할 수 있는 구성 요소 목록이 포함되어 있습니다. when 표현식은 파이프라인 YAML 파일의 finally 필드를 사용하여 지정된 최종 작업 세트에서도 지원됩니다.

when 표현식의 주요 구성 요소는 다음과 같습니다.

  • input: 매개 변수, 작업 결과, 실행 상태와 같은 정적 입력 또는 변수를 지정합니다. 유효한 입력을 입력해야 합니다. 유효한 입력을 입력하지 않으면 기본값은 빈 문자열입니다.
  • operator: 일련의 values에 대한 입력의 관계를 지정합니다. Operator 값으로 in 또는 notin을 입력합니다.
  • values: 문자열 값 배열을 지정합니다. 매개 변수, 결과 및 바인딩된 작업 영역 상태와 같은 정적 값 또는 변수의 비어 있지 않은 배열을 입력합니다.

선언된 when 표현식은 작업이 실행되기 전에 평가됩니다. when 표현식 값이 True이면 작업이 실행됩니다. when 표현식 값이 False이면 작업을 건너뜁니다.

다양한 사용 사례에서 when 표현식을 사용할 수 있습니다. 예를 들면 다음과 같은 경우입니다.

  • 이전 작업의 결과는 예상대로 표시됩니다.
  • Git 리포지토리의 파일이 이전 커밋에서 변경되었습니다.
  • 레지스트리에 이미지가 있습니다.
  • 선택적 작업 영역을 사용할 수 있습니다.

다음 예제에서는 파이프라인 실행에 대한 when 표현식을 보여줍니다. 파이프라인 실행은 다음 기준이 충족되는 경우에만 create-file 작업을 실행합니다. path 매개 변수는 README.md이고, check-file 작업의 exists결과가 yes인 경우에만 echo-file-exists 작업이 실행됩니다. 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun 1
metadata:
  generateName: guarded-pr-
spec:
  serviceAccountName: 'pipeline'
  pipelineSpec:
    params:
      - name: path
        type: string
        description: The path of the file to be created
    workspaces:
      - name: source
        description: |
          This workspace is shared among all the pipeline tasks to read/write common resources
    tasks:
      - name: create-file 2
        when:
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        workspaces:
          - name: source
            workspace: source
        taskSpec:
          workspaces:
            - name: source
              description: The workspace to create the readme file in
          steps:
            - name: write-new-stuff
              image: ubuntu
              script: 'touch $(workspaces.source.path)/README.md'
      - name: check-file
        params:
          - name: path
            value: "$(params.path)"
        workspaces:
          - name: source
            workspace: source
        runAfter:
          - create-file
        taskSpec:
          params:
            - name: path
          workspaces:
            - name: source
              description: The workspace to check for the file
          results:
            - name: exists
              description: indicates whether the file exists or is missing
          steps:
            - name: check-file
              image: alpine
              script: |
                if test -f $(workspaces.source.path)/$(params.path); then
                  printf yes | tee /tekton/results/exists
                else
                  printf no | tee /tekton/results/exists
                fi
      - name: echo-file-exists
        when: 3
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo file exists'
...
      - name: task-should-be-skipped-1
        when: 4
          - input: "$(params.path)"
            operator: notin
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: exit 1
...
    finally:
      - name: finally-task-should-be-executed
        when: 5
          - input: "$(tasks.echo-file-exists.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.status)"
            operator: in
            values: ["Succeeded"]
          - input: "$(tasks.check-file.results.exists)"
            operator: in
            values: ["yes"]
          - input: "$(params.path)"
            operator: in
            values: ["README.md"]
        taskSpec:
          steps:
            - name: echo
              image: ubuntu
              script: 'echo finally done'
  params:
    - name: path
      value: README.md
  workspaces:
    - name: source
      volumeClaimTemplate:
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 16Mi
1
Kubernetes 개체의 유형을 지정합니다. 예에서는 PipelineRun입니다.
2
파이프라인에 사용된 작업 create-file 입니다.
3
check-file 작업에서 exists 결과가 yes인 경우에만 echo-file-exists 작업을 실행하도록 지정하는 when 표현식입니다.
4
path 매개 변수가 README.md인 경우에만 task-s shouldld-be-skipped-1 작업을 건너뛰도록 지정하는 When 표현식입니다.
5
echo-file-exists 작업의 실행 상태와 작업 상태가 Succeeded인 경우에만, finally-task-should-be-executed 작업을 실행하도록 지정하는 when 표현식은 check-file 작업의 exists 결과는 yes이고 path 매개 변수는 README.md입니다.

OpenShift Container Platform 웹 콘솔의 Pipeline Run 세부 정보 페이지에 다음과 같이 작업의 상태와 when 표현식이 표시됩니다.

  • 모든 기준이 충족됨: Task와 다이아몬드 모양으로 표시되는 when 표현식 기호는 녹색입니다.
  • 기준 중 하나가 충족되지 않음: 작업을 건너뜁니다. 건너뛰기된 작업 및 when 표현식 기호는 회색입니다.
  • 충족 기준이 없음: 작업을 건너뜁니다. 건너뛰기된 작업 및 when 표현식 기호는 회색입니다.
  • 작업 실행 실패: 실패한 작업 및 When 표현식 기호는 빨간색입니다.

3.2.2.3. finally 작업

finally 작업은 파이프라인 YAML 파일의 finally 필드를 사용하여 지정된 최종 작업 집합입니다. finally 작업은 파이프라인 실행이 성공적으로 실행되는지 여부에 관계없이 항상 파이프라인 내의 작업을 실행합니다. finally 작업은 해당 파이프라인이 종료되기 전에 모든 파이프라인 작업이 실행된 후 병렬로 실행됩니다.

finally 작업은 동일한 파이프라인 내의 모든 작업 결과를 사용하도록 구성할 수 있습니다. 이 접근 방식은 이 최종 작업이 실행되는 순서를 변경하지 않습니다. 모든 최종 작업이 실행된 후 다른 최종 작업과 동시에 실행됩니다.

다음 예제에서는 clone-cleanup-workspace 파이프라인의 코드 스니펫을 보여줍니다. 이 코드는 리포지토리를 공유 작업 공간으로 복제하고 작업 영역을 정리합니다. 파이프라인 작업을 실행한 후 파이프라인 YAML 파일의 finally 섹션에 지정된 cleanup 작업이 작업 영역을 정리합니다. 

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: clone-cleanup-workspace 1
spec:
  workspaces:
    - name: git-source 2
  tasks:
    - name: clone-app-repo 3
      taskRef:
        name: git-clone-from-catalog
      params:
        - name: url
          value: https://github.com/tektoncd/community.git
        - name: subdirectory
          value: application
      workspaces:
        - name: output
          workspace: git-source
  finally:
    - name: cleanup 4
      taskRef: 5
        name: cleanup-workspace
      workspaces: 6
        - name: source
          workspace: git-source
    - name: check-git-commit
      params: 7
        - name: commit
          value: $(tasks.clone-app-repo.results.commit)
      taskSpec: 8
        params:
          - name: commit
        steps:
          - name: check-commit-initialized
            image: alpine
            script: |
              if [[ ! $(params.commit) ]]; then
                exit 1
              fi
1
파이프라인의 고유한 이름입니다.
2
git 리포지토리가 복제되는 공유 작업 공간입니다.
3
애플리케이션 리포지토리를 공유 작업 영역에 복제하는 작업입니다.
4
공유 작업 영역을 정리하는 작업입니다.
5
작업 실행에서 실행할 작업에 대한 참조입니다.
6
파이프라인의 작업이 런타임에 입력을 수신하거나 출력을 제공하는 데 필요한 공유 스토리지 볼륨입니다.
7
작업에 필요한 매개 변수 목록입니다. 매개 변수에 암시적 기본값이 없는 경우 해당 값을 명시적으로 설정해야 합니다.
8
임베디드 작업 정의입니다.

3.2.2.4. TaskRun

TaskRun 은 클러스터에서 특정 입력, 출력 및 실행 매개변수를 사용하여 실행할 작업을 인스턴스화합니다. 자체 또는 파이프라인의 각 작업에 대해 파이프라인 실행의 일부로 호출할 수 있습니다.

작업은 컨테이너 이미지를 실행하는 하나 이상의 단계로 구성되며 각 컨테이너 이미지는 특정 빌드 작업을 수행합니다. 작업 실행은 모든 단계가 성공적으로 실행되거나 실패가 발생할 때까지 지정된 순서로 작업의 단계를 실행합니다. TaskRun 은 파이프라인의 각 작업에 대한 PipelineRun 에 의해 자동으로 생성됩니다.

다음 예제에서는 관련 입력 매개변수를 사용하여 apply-manifests 작업을 실행하는 작업 실행을 보여줍니다. 

apiVersion: tekton.dev/v1beta1 1
kind: TaskRun 2
metadata:
  name: apply-manifests-taskrun 3
spec: 4
  serviceAccountName: pipeline
  taskRef: 5
    kind: Task
    name: apply-manifests
  workspaces: 6
  - name: source
    persistentVolumeClaim:
      claimName: source-pvc
1
작업 실행 API 버전 v1beta1.
2
Kubernetes 개체의 유형을 지정합니다. 예에서는 TaskRun입니다.
3
이 작업 실행을 식별하는 고유한 이름입니다.
4
작업 실행의 정의입니다. 이 작업 실행에 작업 및 필요한 작업 공간이 지정됩니다.
5
이 작업 실행에 사용되는 작업 참조의 이름입니다. 이 작업 실행은 apply-manifests 작업을 실행합니다.
6
작업 실행에서 사용하는 Workspace입니다.

3.2.2.5. 파이프라인

Pipeline 은 특정 실행 순서로 정렬된 Task 리소스 컬렉션입니다. 애플리케이션 빌드, 배포 및 제공 작업을 자동화하는 복잡한 워크플로를 구성하기 위해 실행됩니다. 하나 이상의 작업이 포함된 파이프라인을 사용하여 애플리케이션에 대한 CI/CD 워크플로를 정의할 수 있습니다.

Pipeline 리소스 정의는 함께 사용하면 파이프라인에서 특정 목표를 달성할 수 있는 여러 필드 또는 특성으로 구성됩니다. 각 Pipeline 리소스 정의에는 특정 입력을 수집하고 특정 출력을 생성하는 Task가 하나 이상 포함되어야 합니다. 또한 파이프라인 정의에는 애플리케이션 요구 사항에 따라 Conditions, Workspaces, Parameters 또는 Resources가 선택적으로 포함될 수 있습니다.

다음 예제에서는 buildah ClusterTask 리소스를 사용하여 Git 리포지토리에서 애플리케이션 이미지를 빌드하는 build-and-deploy 파이프라인을 보여줍니다. 

apiVersion: tekton.dev/v1beta1 1
kind: Pipeline 2
metadata:
  name: build-and-deploy 3
spec: 4
  workspaces: 5
  - name: shared-workspace
  params: 6
  - name: deployment-name
    type: string
    description: name of the deployment to be patched
  - name: git-url
    type: string
    description: url of the git repo for the code of deployment
  - name: git-revision
    type: string
    description: revision to be used from repo of the code for deployment
    default: "pipelines-1.11"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks: 7
  - name: fetch-repository
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.git-url)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
    - name: revision
      value: $(params.git-revision)
  - name: build-image 8
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - fetch-repository
  - name: apply-manifests 9
    taskRef:
      name: apply-manifests
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter: 10
    - build-image
  - name: update-deployment
    taskRef:
      name: update-deployment
    workspaces:
    - name: source
      workspace: shared-workspace
    params:
    - name: deployment
      value: $(params.deployment-name)
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - apply-manifests
1
Pipeline API 버전은 v1beta1입니다.
2
Kubernetes 개체의 유형을 지정합니다. 예에서는 Pipeline입니다.
3
이 파이프라인의 고유한 이름입니다.
4
파이프라인의 정의 및 구조를 지정합니다.
5
파이프라인의 모든 작업에 사용되는 Workspace입니다.
6
파이프라인의 모든 작업에 사용되는 매개변수입니다.
7
파이프라인에 사용되는 작업 목록을 지정합니다.
8
buildah ClusterTask 를 사용하여 지정된 Git 리포지토리에서 애플리케이션 이미지를 빌드하는 Task build-image 입니다.
9
동일한 이름의 사용자 정의 작업을 사용하는 Task apply-manifests.
10
파이프라인에서 작업이 실행되는 순서를 지정합니다. 이 예에서 apply-manifests 작업은 build-image 작업이 완료된 후에만 실행됩니다.
참고

Red Hat OpenShift Pipelines Operator는 Buildah 클러스터 작업을 설치하고 이미지를 빌드하고 푸시할 수 있는 충분한 권한이 있는 파이프라인 서비스 계정을 생성합니다. 권한이 충분하지 않은 다른 서비스 계정과 연결된 경우 Buildah 클러스터 작업이 실패할 수 있습니다.

3.2.2.6. PipelineRun

PipelineRun 은 CI/CD 워크플로를 실행하기 위해 파이프라인, 작업 공간, 인증 정보 및 시나리오와 관련된 매개변수 값 집합을 바인딩하는 리소스 유형입니다.

PipelineRun 은 파이프라인의 실행 중인 인스턴스입니다. 클러스터에서 특정 입력, 출력 및 실행 매개변수를 사용하여 실행할 파이프라인을 인스턴스화합니다. 또한 파이프라인 실행의 각 작업에 대해 작업 실행을 생성합니다.

파이프라인은 작업이 완료되거나 작업이 실패할 때까지 순차적으로 작업을 실행합니다. status 필드는 각 작업 실행의 추적 및 진행 상황을 추적하고 모니터링 및 감사 목적으로 저장합니다.

다음 예제에서는 관련 리소스 및 매개변수를 사용하여 build-and-deploy 파이프라인을 실행합니다. 

apiVersion: tekton.dev/v1beta1 1
kind: PipelineRun 2
metadata:
  name: build-deploy-api-pipelinerun 3
spec:
  pipelineRef:
    name: build-and-deploy 4
  params: 5
  - name: deployment-name
    value: vote-api
  - name: git-url
    value: https://github.com/openshift-pipelines/vote-api.git
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/vote-api
  workspaces: 6
  - name: shared-workspace
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
1
pipeline run API version v1beta1.
2
Kubernetes 오브젝트 유형입니다. 예에서는 PipelineRun입니다.
3
이 파이프라인 실행을 식별하는 고유한 이름입니다.
4
실행할 파이프라인의 이름입니다. 예에서는 build-and-deploy입니다.
5
파이프라인을 실행하는 데 필요한 매개변수 목록입니다.
6
파이프라인 실행에서 사용하는 작업 공간입니다.

추가 리소스

3.2.2.7. Workspace

참고

PipelineResource CR은 디버그하기 어렵고 범위가 제한되며 작업의 재사용 가능성을 낮추기 때문에 Red Hat OpenShift Pipelines의 PipelineResource CR 대신 작업 공간을 사용하는 것이 좋습니다.

작업 공간은 입력을 수신하거나 출력을 제공하기 위해 런타임 시 파이프라인의 작업에 필요한 공유 스토리지 볼륨을 선언합니다. 볼륨의 실제 위치를 지정하는 대신 작업 공간을 사용하여 런타임 시 필요한 파일 시스템 또는 파일 시스템의 일부를 선언할 수 있습니다. 작업 또는 파이프라인은 작업 공간을 선언하고 볼륨의 특정 위치 세부 정보를 제공해야 합니다. 그런 다음 작업 실행 또는 파이프라인 실행에서 해당 작업 공간에 마운트됩니다. 이러한 방식으로 런타임 스토리지 볼륨과 볼륨 선언을 분리하면 사용자 환경에 관계없이 재사용 가능하고 유연한 작업을 수행할 수 있습니다.

작업 공간을 사용하면 다음을 수행할 수 있습니다.

  • 작업 입력 및 출력 저장
  • 작업 간 데이터 공유
  • 시크릿에 보관된 자격 증명의 마운트 지점으로 사용
  • 구성 맵에 보관된 구성의 마운트 지점으로 사용
  • 조직에서 공유하는 공통 도구의 마운트 지점으로 작업 공간 활용
  • 작업 속도를 높이는 빌드 아티팩트 캐시 생성

다음을 사용하여 TaskRun 또는 PipelineRun 에서 작업 공간을 지정할 수 있습니다.

  • 읽기 전용 구성 맵 또는 시크릿
  • 다른 작업과 공유되는 기존 영구 볼륨 클레임
  • 제공된 볼륨 클레임 템플릿의 영구 볼륨 클레임
  • 작업 실행이 완료되면 삭제되는 emptyDir

다음 예제에서는 파이프라인에 정의된 대로 build-image 및 apply-manifests 작업에 대한 shared-workspace 작업 공간을 선언하는 build-and-deploy 파이프라인의 코드 스니펫 예입니다. 

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces: 1
  - name: shared-workspace
  params:
...
  tasks: 2
  - name: build-image
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: TLSVERIFY
      value: "false"
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces: 3
    - name: source 4
      workspace: shared-workspace 5
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces: 6
    - name: source
      workspace: shared-workspace
    runAfter:
      - build-image
...
1
파이프라인에 정의된 작업 간에 공유되는 작업 공간 목록입니다. 파이프라인은 필요한 만큼의 작업 공간을 정의할 수 있습니다. 이 예에서는 shared-workspace 라는 하나의 작업 공간만 선언됩니다.
2
파이프라인에 사용되는 작업의 정의입니다. 이 스니펫은 공통 작업 공간을 공유하는 두 개의 작업인 build-image 및 apply-manifests 를 정의합니다.
3
build-image 작업에 사용되는 작업 공간 목록입니다. 작업 정의에는 필요한 만큼의 작업 공간을 포함할 수 있습니다. 그러나 작업에서 쓰기 가능한 작업 공간을 한 개 이상 사용하는 것이 좋습니다.
4
작업에 사용된 작업 공간을 고유하게 식별하는 이름입니다. 이 작업에서는 source 라는 작업 공간 하나를 사용합니다.
5
작업에서 사용하는 파이프라인 작업 공간의 이름입니다. 차례로 작업 공간 소스는 shared-workspace 라는 파이프라인 작업 공간을 사용합니다.
6
apply-manifests 작업에 사용되는 작업 공간 목록입니다. 이 작업은 소스 작업 공간을 build-image 작업과 공유합니다.

작업 공간을 사용하면 여러 작업에서 데이터를 공유하고 파이프라인의 각 작업을 실행하는 동안 필요한 하나 이상의 볼륨을 지정할 수 있습니다. 영구 볼륨 클레임을 생성하거나 사용자를 대신하여 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿을 제공할 수 있습니다.

다음의 build-deploy-api-pipelinerun 파이프라인 실행 코드 조각에서는 볼륨 클레임 템플릿을 사용하여 build-and-deploy 파이프라인에 사용된 shared-workspace 작업 공간의 스토리지 볼륨을 정의하는 영구 볼륨 클레임을 생성합니다. 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: build-deploy-api-pipelinerun
spec:
  pipelineRef:
    name: build-and-deploy
  params:
...

  workspaces: 1
  - name: shared-workspace 2
    volumeClaimTemplate: 3
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
1
파이프라인 실행에 볼륨 바인딩이 제공될 파이프라인 작업 공간 목록을 지정합니다.
2
볼륨이 제공될 파이프라인의 작업 공간의 이름입니다.
3
작업 공간의 스토리지 볼륨을 정의하기 위해 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿을 지정합니다.

3.2.2.8. Trigger

Kubernetes 리소스에서 전체 CI/CD 실행을 정의하는 완전한 CI/CD 시스템을 생성하려면 파이프라인과 함께 트리거를 사용합니다. 트리거는 Git 풀 요청과 같은 외부 이벤트를 캡처하고 처리하여 주요 정보를 추출합니다. 이 이벤트 데이터를 미리 정의된 매개변수 집합에 매핑하면 Kubernetes 리소스를 생성 및 배포하고 파이프라인을 인스턴스화할 수 있는 일련의 작업이 트리거됩니다.

애플리케이션에 Red Hat OpenShift Pipeline을 사용하여 CI/CD 워크플로를 정의하는 경우를 예로 들 수 있습니다. 새로운 변경 사항을 애플리케이션 리포지토리에 적용하려면 파이프라인을 시작해야 합니다. 트리거는 모든 변경 이벤트를 캡처하여 처리하고 최신 변경 사항이 적용된 새 이미지를 배포하는 파이프라인 실행을 트리거하는 방식으로 이 프로세스를 자동화합니다.

트리거는 함께 작동하여 재사용 가능하고 분리되고 자체 유지되는 CI/CD 시스템을 형성하는 다음과 같은 주요 리소스로 구성됩니다.

  • TriggerBinding 리소스는 이벤트 페이로드에서 필드를 추출한 다음 해당 필드를 매개변수로 저장합니다.

    다음은 수신된 이벤트 페이로드에서 Git 리포지토리 정보를 추출하는 TriggerBinding 리소스의 코드 조각 예입니다. 

    apiVersion: triggers.tekton.dev/v1beta1 1
kind: TriggerBinding 2
metadata:
  name: vote-app 3
spec:
  params: 4
  - name: git-repo-url
    value: $(body.repository.url)
  - name: git-repo-name
    value: $(body.repository.name)
  - name: git-revision
    value: $(body.head_commit.id)
    1
    TriggerBinding 리소스의 API 버전입니다. 예에서는 v1beta1 입니다.
    2
    Kubernetes 개체의 유형을 지정합니다. 예에서는 TriggerBinding입니다.
    3
    TriggerBinding 리소스를 확인하는 고유한 이름입니다.
    4
    수신한 이벤트 페이로드에서 추출하여 TriggerTemplate 리소스로 전달할 매개변수 목록입니다. 예에서는 Git 리포지토리 URL, 이름 및 개정 정보가 이벤트 페이로드의 본문에서 추출됩니다.

  • TriggerTemplate 리소스는 리소스를 생성해야 하는 방법에 대해 표준 역할을 합니다. TriggerBinding 리소스에서 매개변수화된 데이터를 사용하는 방식을 지정합니다. 트리거 템플릿은 트리거 바인딩을 통해 입력을 수신한 다음 새 파이프라인 리소스를 생성하고 새 파이프라인 실행을 시작하는 일련의 작업을 수행합니다.

    다음은 방금 생성한 TriggerBinding 리소스에서 수신한 Git 리포지토리 정보를 사용하여 애플리케이션을 생성하는 TriggerTemplate 리소스의 코드 조각입니다. 

    apiVersion: triggers.tekton.dev/v1beta1 1
kind: TriggerTemplate 2
metadata:
  name: vote-app 3
spec:
  params: 4
  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: pipelines-1.11
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates: 5
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      name: build-deploy-$(tt.params.git-repo-name)-$(uid)
    spec:
      serviceAccountName: pipeline
      pipelineRef:
        name: build-and-deploy
      params:
      - name: deployment-name
        value: $(tt.params.git-repo-name)
      - name: git-url
        value: $(tt.params.git-repo-url)
      - name: git-revision
        value: $(tt.params.git-revision)
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/$(tt.params.git-repo-name)
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
         spec:
          accessModes:
           - ReadWriteOnce
          resources:
            requests:
              storage: 500Mi
    1
    TriggerTemplate 리소스의 API 버전입니다. 예에서는 v1beta1 입니다.
    2
    Kubernetes 개체의 유형을 지정합니다. 예에서는 TriggerTemplate입니다.
    3
    TriggerTemplate 리소스를 식별하는 고유 이름입니다.
    4
    TriggerBinding 리소스에서 제공되는 매개변수입니다.
    5
    TriggerBinding 또는 EventListener 리소스를 통해 수신한 매개변수를 사용하여 리소스를 생성해야 하는 방법을 지정하는 템플릿 목록입니다.

  • Trigger 리소스는 TriggerBinding 및 TriggerTemplate 리소스를 결합하고 선택적으로 interceptors 이벤트 프로세서를 결합합니다.

    인터셉터는 TriggerBinding 리소스 전에 실행되는 특정 플랫폼의 모든 이벤트를 처리합니다. 인터셉터를 사용하여 페이로드를 필터링하고, 이벤트를 확인하고, 트리거 조건을 정의 및 테스트하고, 기타 유용한 처리를 구현할 수 있습니다. 인터셉터는 이벤트 확인을 위해 시크릿을 사용합니다. 이벤트 데이터가 인터셉터를 통과하면 페이로드 데이터를 트리거 바인딩에 전달하기 전에 트리거로 이동합니다. 인터셉터를 사용하여 EventListener 사양에서 참조된 관련 트리거의 동작을 수정할 수도 있습니다.

    다음 예제는 TriggerBinding 및 TriggerTemplate 리소스와 interceptors 이벤트 프로세서를 연결하는 vote-trigger라는 Trigger 리소스의 코드 조각을 보여줍니다. 

    apiVersion: triggers.tekton.dev/v1beta1 1
kind: Trigger 2
metadata:
  name: vote-trigger 3
spec:
  serviceAccountName: pipeline 4
  interceptors:
    - ref:
        name: "github" 5
      params: 6
        - name: "secretRef"
          value:
            secretName: github-secret
            secretKey: secretToken
        - name: "eventTypes"
          value: ["push"]
  bindings:
    - ref: vote-app 7
  template: 8
     ref: vote-app
---
apiVersion: v1
kind: Secret 9
metadata:
  name: github-secret
type: Opaque
stringData:
  secretToken: "1234567"
    1
    Trigger 리소스의 API 버전입니다. 예에서는 v1beta1 입니다.
    2
    Kubernetes 개체의 유형을 지정합니다. 이 예제에서는 Trigger입니다.
    3
    Trigger 리소스를 식별하는 고유 이름입니다.
    4
    사용할 서비스 계정 이름입니다.
    5
    참조할 인터셉터 이름입니다. 예에서는 github입니다.
    6
    지정할 매개 변수입니다.
    7
    TriggerTemplate 리소스에 연결할 TriggerBinding 리소스의 이름입니다.
    8
    TriggerBinding 리소스에 연결할 TriggerTemplate 리소스의 이름입니다.
    9
    이벤트를 확인하는 데 사용할 시크릿입니다.

  • EventListener 리소스는 JSON 페이로드와 함께 들어오는 HTTP 기반 이벤트를 수신 대기하는 끝점 또는 이벤트 싱크를 제공합니다. 각 TriggerBinding 리소스에서 이벤트 매개변수를 추출한 다음 이 데이터를 처리하여 해당 TriggerTemplate 리소스에서 지정하는 Kubernetes 리소스를 생성합니다. 또한 EventListener 리소스는 페이로드 유형을 확인하고 선택적으로 수정하는 이벤트 interceptors를 사용하여 페이로드에 대한 간단한 이벤트 처리 또는 기본 필터링 작업을 수행합니다. 현재 파이프라인 트리거는 Webhook Interceptors, GitHub Interceptors, GitLab Interceptors, Bitbucket Interceptors, Common Expression Language (CEL) Interceptors의 5 가지 유형의 인터셉터를 지원합니다.

    다음 예제에서는 vote-trigger라는 Trigger 리소스를 참조하는 EventListener 리소스를 보여줍니다. 

    apiVersion: triggers.tekton.dev/v1beta1 1
kind: EventListener 2
metadata:
  name: vote-app 3
spec:
  serviceAccountName: pipeline 4
  triggers:
    - triggerRef: vote-trigger 5
    1
    EventListener 리소스의 API 버전입니다. 예에서는 v1beta1 입니다.
    2
    Kubernetes 개체의 유형을 지정합니다. 예에서는 EventListener입니다.
    3
    EventListener 리소스를 식별하는 고유 이름입니다.
    4
    사용할 서비스 계정 이름입니다.
    5
    EventListener 리소스에서 참조하는 Trigger 리소스의 이름입니다.

3.2.3. 추가 리소스

3.3. OpenShift Pipelines 설치

이 가이드에서는 클러스터 관리자에게 Red Hat OpenShift Pipelines Operator를 OpenShift Container Platform 클러스터에 설치하는 프로세스를 안내합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • oc CLI를 설치했습니다.
  • 로컬 시스템에 tkn) CLI 를 설치했습니다.
  • 클러스터에 Marketplace 기능이 활성화되었거나 Red Hat Operator 카탈로그 소스가 수동으로 구성되어 있습니다.

3.3.1. 웹 콘솔에서 Red Hat OpenShift Pipelines Operator 설치

OpenShift Container Platform OperatorHub에 나열된 Operator를 사용하여 Red Hat OpenShift Pipelines를 설치할 수 있습니다. Red Hat OpenShift Pipelines Operator를 설치하면 파이프라인 구성에 필요한 CR(사용자 정의 리소스)이 Operator와 함께 자동으로 설치됩니다.

기본 Operator CRD(사용자 정의 리소스 정의) config.operator.tekton.dev가 tektonconfigs.operator.tekton.dev로 교체되었습니다. 또한 Operator에서 OpenShift Pipelines 구성 요소를 개별적으로 관리하기 위해 추가 CRD인 tektonpipelines.operator.tekton.dev, tektontriggers.operator.tekton.dev, tektonaddons.operator.tekton.dev를 제공합니다.

OpenShift Pipelines가 클러스터에 이미 설치되어 있는 경우 기존 설치가 원활하게 업그레이드됩니다. Operator는 필요에 따라 클러스터의 config.operator.tekton.dev 인스턴스를 tektonconfigs.operator.tekton.dev 인스턴스 및 기타 CRD의 추가 오브젝트로 교체합니다.

주의

resource name - cluster 필드를 변경하여 config.operator.tekton.dev CRD 인스턴스의 타겟 네임스페이스를 변경하는 등 기존 설치를 수동으로 변경한 경우 업그레이드 경로가 제대로 작동하지 않습니다. 이러한 경우 권장되는 워크플로는 설치를 제거한 후 Red Hat OpenShift Pipelines Operator를 다시 설치하는 것입니다.

Red Hat OpenShift Pipelines Operator는 이제 TektonConfig CR(사용자 정의 리소스)의 일부로 프로필을 지정하여 설치할 구성 요소를 선택할 수 있는 옵션을 제공합니다. Operator가 설치되면 TektonConfig CR이 자동으로 설치됩니다. 지원되는 프로필은 다음과 같습니다.

  • Lite: Tekton 파이프라인만 설치합니다.
  • Basic: Tekton 파이프라인, Tekton 트리거 및 Tekton 체인을 설치합니다.
  • 모두: TektonConfig CR을 설치할 때 사용하는 기본 프로필입니다. 이 프로필은 Tekton Pipelines, Tekton Triggers, Tekton Chains, Pipelines as Code 및 Tekton Addons를 포함한 모든 Tekton 구성 요소를 설치합니다. Tekton Addons에는 ClusterTasks,ClusterTriggerBindings,ConsoleCLIDownload,ConsoleQuickStart, ConsoleYAMLSample 리소스가 포함됩니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator → OperatorHub로 이동합니다.
  2. 키워드로 필터링 박스를 사용하여 카탈로그에서 Red Hat OpenShift Pipelines Operator를 검색합니다. Red Hat OpenShift Pipelines Operator 타일을 클릭합니다.
  3. Red Hat OpenShift Pipelines Operator 페이지에서 Operator에 대한 간략한 설명을 확인합니다. 설치를 클릭합니다.

  4. Operator 설치 페이지에서 다음을 수행합니다.

    1. Installation Mode로 All namespaces on the cluste(default)를 선택합니다. 이 모드에서는 기본 openshift-operators 네임스페이스에 Operator가 설치되므로 Operator가 클러스터의 모든 네임스페이스를 감시하고 사용 가능하게 만들 수 있습니다.
    2. Approval Strategy으로 Automatic을 선택합니다. 그러면 Operator에 향후 지원되는 업그레이드가 OLM(Operator Lifecycle Manager)에 의해 자동으로 처리됩니다. Manual 승인 전략을 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

    3. Update Channel을 선택합니다.

      • 최신 채널을 사용하면 Red Hat OpenShift Pipelines Operator의 최신 안정적인 버전을 설치할 수 있습니다. 현재 Red Hat OpenShift Pipelines Operator를 설치하는 기본 채널입니다.

      • 특정 버전의 Red Hat OpenShift Pipelines Operator를 설치하기 위해 클러스터 관리자는 해당 pipelines-<version > 채널을 사용할 수 있습니다. 예를 들어 Red Hat OpenShift Pipelines Operator 버전 1.8.x 를 설치하려면 pipelines-1.8 채널을 사용할 수 있습니다.

        참고

        OpenShift Container Platform 4.11부터 Red Hat OpenShift Pipelines Operator 설치 및 업그레이드를 위한 프리뷰 및 안정적인 채널을 사용할 수 없습니다. 그러나 OpenShift Container Platform 4.10 및 이전 버전에서는 Operator를 설치 및 업그레이드하기 위해 프리뷰 및 안정적인 채널을 사용할 수 있습니다.

  5. 설치를 클릭합니다. Installed Operators 페이지의 목록에 해당 Operator가 나타납니다.

    참고

    Operator는 openshift-operators 네임스페이스에 자동으로 설치됩니다.

  6. Red Hat OpenShift Pipelines Operator가 성공적으로 설치되었는지 확인하려면 상태가 최신 업데이트 완료로 설정되어 있는지 확인합니다.

    주의

    다른 구성 요소를 설치하는 경우에도 성공 상태가 최신 업데이트됨으로 표시될 수 있습니다. 따라서 터미널에서 수동으로 설치를 확인하는 것이 중요합니다.

  7. Red Hat OpenShift Pipelines Operator의 모든 구성 요소가 성공적으로 설치되었는지 확인합니다. 터미널에서 클러스터에 로그인하고 다음 명령을 실행합니다. 

    $ oc get tektonconfig config

    출력 예

    NAME     VERSION   READY   REASON
config   1.11.0     True

    READY 조건이 True 이면 Operator 및 해당 구성 요소가 성공적으로 설치되었습니다.

    추가 사항: 다음 명령을 실행하여 구성 요소의 버전을 확인합니다. 

    $ oc get tektonpipeline,tektontrigger,tektonchain,tektonaddon,pac

    출력 예

    NAME                                          VERSION   READY   REASON
tektonpipeline.operator.tekton.dev/pipeline   v0.47.0   True

NAME                                        VERSION   READY   REASON
tektontrigger.operator.tekton.dev/trigger   v0.23.1   True

NAME                                    VERSION   READY   REASON
tektonchain.operator.tekton.dev/chain   v0.16.0   True

NAME                                    VERSION   READY   REASON
tektonaddon.operator.tekton.dev/addon   1.11.0     True

NAME                                                             VERSION   READY   REASON
openshiftpipelinesascode.operator.tekton.dev/pipelines-as-code   v0.19.0   True

3.3.2. CLI를 사용하여 OpenShift Pipelines Operator 설치

CLI를 사용하여 OperatorHub에서 Red Hat OpenShift Pipelines Operator를 설치할 수 있습니다.

프로세스

  1. 서브스크립션 오브젝트 YAML 파일을 생성하여 Red Hat OpenShift Pipelines Operator에 네임스페이스를 서브스크립션합니다(예: sub.yaml).

    서브스크립션의 예

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-pipelines-operator
  namespace: openshift-operators
spec:
  channel:  <channel name> 1
  name: openshift-pipelines-operator-rh 2
  source: redhat-operators 3
  sourceNamespace: openshift-marketplace 4

    1
    Operator의 채널 이름입니다. pipelines-<version > 채널이 기본 채널입니다. 예를 들어 Red Hat OpenShift Pipelines Operator 버전 1.7 의 기본 채널은 pipelines-1.7 입니다. 최신 채널을 사용하면 Red Hat OpenShift Pipelines Operator의 최신 안정적인 버전을 설치할 수 있습니다.
    2
    등록할 Operator의 이름입니다.
    3
    Operator를 제공하는 CatalogSource의 이름입니다.
    4
    CatalogSource의 네임스페이스입니다. 기본 OperatorHub CatalogSources에는 openshift-marketplace를 사용합니다.

  2. 서브스크립션 오브젝트를 생성합니다. 

    $ oc apply -f sub.yaml

    이제 Red Hat OpenShift Pipelines Operator가 기본 타겟 네임스페이스인 openshift-operators에 설치되었습니다.

3.3.3. 제한된 환경의 Red Hat OpenShift Pipelines Operator

Red Hat OpenShift Pipelines Operator는 제한된 네트워크 환경에서 파이프라인 설치를 지원합니다.

Operator는 cluster 프록시 오브젝트를 기반으로 tekton-controller에서 생성한 Pod의 컨테이너에 프록시 환경 변수를 설정하는 프록시 Webhook를 설치합니다. 또한 TektonPipelines, TektonTriggers, Controllers, Webhooks, Operator Proxy Webhook 리소스에서 프록시 환경 변수를 설정합니다.

기본적으로 프록시 Webhook는 openshift-pipelines 네임스페이스에 대해 비활성화되어 있습니다. 다른 네임스페이스에 대해 비활성화하려면 namespace 오브젝트에 operator.tekton.dev/disable-proxy: true 라벨을 추가하면 됩니다.

3.3.4. TektonConfig CR을 사용한 성능 튜닝

TektonConfig CR(사용자 정의 리소스)의 .spec.pipeline.performance 매개변수 아래에 있는 필드를 수정하여 OpenShift Pipelines 컨트롤러의 HA(고가용성) 지원 및 성능 구성을 변경할 수 있습니다.

TektonConfig 성능 필드의 예

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    performance:
      disable-ha: false
      buckets: 1
      threads-per-controller: 2
      kube-api-qps: 5.0
      kube-api-burst: 10

필드는 선택 사항입니다. 이를 설정하면 Red Hat OpenShift Pipelines Operator에 대부분의 필드가 openshift-pipelines-controller 컨테이너의 openshift-pipelines-controller 배포에 인수로 포함됩니다. OpenShift Pipelines Operator는 openshift-pipelines 네임스페이스의 config-leader-election 구성 맵의 buckets 필드도 업데이트합니다.

값을 지정하지 않으면 OpenShift Pipelines Operator에서 해당 필드를 업데이트하지 않고 OpenShift Pipelines 컨트롤러의 기본값을 적용합니다.

참고

성능 필드를 수정하거나 제거하는 경우 OpenShift Pipelines Operator는 openshift-pipelines-controller 배포 및 config-leader-election 구성 맵( buckets 필드가 변경된 경우) 구성 맵을 업데이트하고 openshift-pipelines-controller Pod를 다시 생성합니다.

표 3.5. OpenShift Pipelines 성능 튜닝을 위한 수정 가능한 필드

이름설명OpenShift Pipelines 컨트롤러의 기본값

disable-ha

HA(고가용성) 지원을 활성화하거나 비활성화합니다. 기본적으로 HA 지원은 활성화되어 있습니다.

false

버킷

각 조정기의 키 공간을 분할하는 데 사용되는 버킷 수입니다.

각 복제본에서는 이러한 버킷을 사용합니다. 버킷을 소유한 인스턴스는 해당 버킷으로 분할된 키를 조정합니다. 최대값은 10입니다.

1

threads-per-controller

OpenShift Pipelines 컨트롤러의 작업 대기열이 처리될 때 사용할 스레드(작업자) 수입니다.

2

kube-api-qps

REST 클라이언트에서 클러스터 마스터에 대한 초당 최대 쿼리(QPS)입니다.

5.0

kube-api-burst

스로틀의 최대 버스트입니다.

10

참고

OpenShift Pipelines Operator는 OpenShift Pipelines 컨트롤러의 복제본 수를 제어하지 않습니다. 배포의 replicas 설정에 따라 복제본 수가 결정됩니다. 예를 들어 복제본 수를 3으로 변경하려면 다음 명령을 입력합니다. 

$ oc --namespace openshift-pipelines scale deployment openshift-pipelines-controller --replicas=3
중요

OpenShift Pipelines 컨트롤러에서 kube-api-qps 및 kube-api-burst 필드에 2를 곱합니다. 예를 들어 kube-api-qps 및 kube-api-burst 값이 10 이면 실제 QPS 및 burst 값은 20 이 됩니다.

3.3.5. 추가 리소스

3.4. OpenShift Pipelines 설치 제거

클러스터 관리자는 다음 단계를 수행하여 Red Hat OpenShift Pipelines Operator를 설치 제거할 수 있습니다.

  1. Red Hat OpenShift Pipelines Operator를 설치할 때 기본적으로 추가된 CR(Custom Resource)을 삭제합니다.

  2. Operator에 종속된 Tekton Chains와 같은 선택적 구성 요소의 CR을 삭제합니다.

    경고

    선택적 구성 요소의 CR을 제거하지 않고 Operator를 설치 제거하는 경우 나중에 제거할 수 없습니다.

  3. Red Hat OpenShift Pipelines Operator를 설치 제거합니다.

Operator를 설치 제거하는 것만으로 설치 과정에서 기본적으로 생성된 Red Hat OpenShift Pipelines 구성 요소가 제거되지는 않습니다.

3.4.1. Red Hat OpenShift Pipelines 구성 요소 및 사용자 정의 리소스 삭제

Red Hat OpenShift Pipelines Operator 설치 과정에서 기본적으로 생성된 CR(사용자 정의 리소스)을 삭제합니다.

절차

  1. 웹 콘솔의 관리자 화면에서 Administration → Custom Resource Definition로 이동합니다.
  2. 이름으로 필터링 박스에 config.operator.tekton.dev를 입력하여 Red Hat OpenShift Pipelines Operator CR을 검색합니다.
  3. CRD Config을 클릭하여 Custom Resource Definition Details 페이지를 엽니다.

  4. Actions 드롭다운 메뉴를 클릭하고 Delete Custom Resource Definition를 선택합니다.

    참고

    CR을 삭제하면 Red Hat OpenShift Pipelines 구성 요소가 삭제되고 클러스터의 모든 작업 및 파이프라인이 손실됩니다.

  5. Delete를 클릭하여 CR 삭제를 확인합니다.
중요

이 절차를 반복하여 Operator를 제거하기 전에 Tekton Chains와 같은 선택적 구성 요소의 CR을 찾아서 제거합니다. 선택적 구성 요소의 CR을 제거하지 않고 Operator를 설치 제거하는 경우 나중에 제거할 수 없습니다.

3.4.2. Red Hat OpenShift Pipelines Operator 설치 제거

웹 콘솔의 관리자 화면을 사용하여 Red Hat OpenShift Pipelines Operator를 설치 제거할 수 있습니다.

절차

  1. Operators → OperatorHub 페이지에서 Filter by keyword 상자를 사용하여 Red Hat OpenShift Pipelines Operator를 검색합니다.
  2. Red Hat OpenShift Pipelines Operator 타일을 클릭합니다. Operator 타일은 Operator가 설치되었음을 나타냅니다.
  3. Red Hat OpenShift Pipelines Operator 설명 페이지에서 제거를 클릭합니다.

추가 리소스

3.5. OpenShift Pipelines를 사용하여 애플리케이션용 CI/CD 솔루션 작성

Red Hat OpenShift Pipelines를 사용하면 애플리케이션을 빌드, 테스트, 배포하는 사용자 정의 CI/CD 솔루션을 생성할 수 있습니다.

애플리케이션에 사용할 완전한 셀프 서비스 CI/CD 파이프라인을 생성하려면 다음 작업을 수행합니다.

  • 사용자 정의 작업을 생성하거나 재사용 가능한 기존 작업을 설치합니다.
  • 애플리케이션용 제공 파이프라인을 생성하고 정의합니다.

  • 다음 접근 방법 중 하나를 사용하여 파이프라인 실행을 위해 작업 공간에 연결된 스토리지 볼륨 또는 파일 시스템을 제공합니다.

    • 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿 지정
    • 영구 볼륨 클레임 지정
  • 파이프라인을 인스턴스화하고 호출할 PipelineRun 오브젝트를 생성합니다.
  • 소스 리포지토리의 이벤트를 캡처하는 트리거를 추가합니다.

여기서는 pipelines-tutorial 예제를 사용하여 선행 Task들을 보여줍니다. 예에서는 다음으로 구성된 간단한 애플리케이션을 사용합니다.

  • pipelines-vote-ui Git 리포지토리에 소스 코드가 있는 프런트 엔드 인터페이스 pipelines-vote-ui.
  • pipelines-vote-api Git 리포지토리에 소스 코드가 있는 백엔드 인터페이스 pipelines-vote-api.
  • pipelines-tutorial Git 리포지토리의 apply-manifests 및 update-deployment 작업입니다.

3.5.1. 사전 요구 사항

  • OpenShift Container Platform 클러스터에 액세스 권한을 보유합니다.
  • OpenShift OperatorHub에 나열된 Red Hat OpenShift Pipelines Operator를 사용하여 OpenShift Pipelines를 설치했습니다. 설치를 마친 후 전체 클러스터에 적용할 수 있습니다.
  • OpenShift Pipelines CLI 를 설치했습니다.
  • GitHub ID를 사용하여 프런트 엔드 pipelines-vote-ui 및 백엔드 pipelines-vote-api Git 리포지토리를 분기했으며 이러한 리포지토리에 대한 관리자 액세스 권한이 있습니다.
  • 선택 사항: pipelines-tutorial Git 리포지토리를 복제했습니다.

3.5.2. 프로젝트 생성 및 파이프라인 서비스 계정 검사

프로세스

  1. OpenShift Container Platform 클러스터에 로그인합니다. 

    $ oc login -u <login> -p <password> https://openshift.example.com:6443

  2. 샘플 애플리케이션용 프로젝트를 생성합니다. 예시 워크플로에서는 pipelines-tutorial 프로젝트를 생성합니다. 

    $ oc new-project pipelines-tutorial
    참고

    다른 이름으로 프로젝트를 생성하는 경우, 예시에 사용된 리소스 URL을 사용자의 프로젝트 이름으로 업데이트하십시오.

  3. pipeline 서비스 계정을 표시합니다.

    Red Hat OpenShift Pipelines Operator는 이미지를 빌드하고 내보내기에 충분한 권한이 있는 pipeline이라는 서비스 계정을 추가하고 구성합니다. 이 서비스 계정은 PipelineRun 오브젝트에서 사용합니다. 

    $ oc get serviceaccount pipeline

3.5.3. 파이프라인 작업 생성

절차

  1. 파이프라인의 재사용 가능한 작업 목록이 포함된 pipelines-tutorial 리포지토리에서 apply-manifests 및 update-deployment 작업을 설치합니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/01_pipeline/01_apply_manifest_task.yaml
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/01_pipeline/02_update_deployment_task.yaml

  2. tkn task list 명령을 사용하여 생성한 작업 목록을 표시합니다. 

    $ tkn task list

    apply-manifest 및 update-deployment 작업 리소스가 생성된 것이 출력에서 확인됩니다. 

    NAME                DESCRIPTION   AGE
apply-manifests                   1 minute ago
update-deployment                 48 seconds ago

  3. tkn clustertasks list 명령을 사용하여 Operator에서 설치한 추가 클러스터 작업 목록을 표시합니다(예: buildah 및 s2i-python-3).

    참고

    제한된 환경에서 buildah 클러스터 작업을 사용하려면 Dockerfile에서 내부 이미지 스트림을 기본 이미지로 사용해야 합니다. 

    $ tkn clustertasks list

    Operator에서 설치한 ClusterTask 리소스가 출력에 나열됩니다. 

    NAME                       DESCRIPTION   AGE
buildah                                  1 day ago
git-clone                                1 day ago
s2i-python                               1 day ago
tkn                                      1 day ago
중요

Red Hat OpenShift Pipelines 1.10에서는 클러스터 작업 기능이 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

추가 리소스

3.5.4. 파이프라인 조립

파이프라인은 CI/CD 흐름을 나타내며 실행할 작업들로 정의됩니다. 여러 애플리케이션 및 환경에서 포괄적으로 적용되고 재사용 가능하도록 설계되었습니다.

파이프라인은 from 및 runAfter 매개변수를 사용하여 작업들이 상호 작용하는 방법과 실행 순서를 지정합니다. 그리고 workspaces 필드를 사용하여 파이프라인의 각 작업 실행 중 필요한 하나 이상의 볼륨을 지정합니다.

이 섹션에서는 GitHub에서 애플리케이션의 소스 코드를 가져와 OpenShift Container Platform에서 빌드 및 배포하는 파이프라인을 생성합니다.

파이프라인은 백엔드 애플리케이션 pipelines-vote-api 및 프런트 엔드 애플리케이션 pipelines-vote-ui에 대해 다음 작업을 수행합니다.

  • git-url 및 git-revision 매개변수를 참조하여 Git 리포지토리에서 애플리케이션의 소스 코드를 복제합니다.
  • buildah 클러스터 작업 사용하여 컨테이너 이미지를 빌드합니다.
  • image 매개변수를 참조하여 OpenShift 이미지 레지스트리로 이미지를 푸시합니다.
  • apply-manifests 및 update-deployment 작업을 사용하여 OpenShift Container Platform에 새 이미지를 배포합니다.

절차

  1. 다음 샘플 파이프라인 YAML 파일의 내용을 복사하여 저장합니다. 

    apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: build-and-deploy
spec:
  workspaces:
  - name: shared-workspace
  params:
  - name: deployment-name
    type: string
    description: name of the deployment to be patched
  - name: git-url
    type: string
    description: url of the git repo for the code of deployment
  - name: git-revision
    type: string
    description: revision to be used from repo of the code for deployment
    default: "pipelines-1.11"
  - name: IMAGE
    type: string
    description: image to be built from the code
  tasks:
  - name: fetch-repository
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.git-url)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
    - name: revision
      value: $(params.git-revision)
  - name: build-image
    taskRef:
      name: buildah
      kind: ClusterTask
    params:
    - name: IMAGE
      value: $(params.IMAGE)
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - fetch-repository
  - name: apply-manifests
    taskRef:
      name: apply-manifests
    workspaces:
    - name: source
      workspace: shared-workspace
    runAfter:
    - build-image
  - name: update-deployment
    taskRef:
      name: update-deployment
    params:
    - name: deployment
      value: $(params.deployment-name)
    - name: IMAGE
      value: $(params.IMAGE)
    runAfter:
    - apply-manifests

    파이프라인 정의는 Git 소스 리포지토리 및 이미지 레지스트리의 세부 사항을 요약합니다. 이러한 세부 사항은 파이프라인이 트리거되고 실행될 때 params로 추가됩니다.

  2. 파이프라인을 생성합니다. 

    $ oc create -f <pipeline-yaml-file-name.yaml>

    또는 Git 리포지토리에서 직접 YAML 파일을 실행할 수도 있습니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/01_pipeline/04_pipeline.yaml

  3. tkn pipeline list 명령을 사용하여 파이프라인이 애플리케이션에 추가되었는지 확인합니다. 

    $ tkn pipeline list

    출력에서 build-and-deploy 파이프라인이 생성되었는지 확인합니다. 

    NAME               AGE            LAST RUN   STARTED   DURATION   STATUS
build-and-deploy   1 minute ago   ---        ---       ---        ---

3.5.5. 제한된 환경에서 파이프라인을 실행하도록 이미지 미러링

연결이 끊긴 클러스터 또는 제한된 환경에서 프로비저닝된 클러스터에서 OpenShift Pipelines를 실행하려면 Samples Operator가 제한된 네트워크용으로 구성되었는지 또는 클러스터 관리자가 미러링된 레지스트리가 있는 클러스터를 생성했는지 확인해야 합니다.

다음 절차에서는 pipelines-tutorial 예제를 사용하여 미러링된 레지스트리가 있는 클러스터를 사용하여 제한된 환경에서 애플리케이션에 대한 파이프라인을 생성합니다. pipelines-tutorial 예제가 제한된 환경에서 작동하도록 하려면 프런트 엔드 인터페이스 pipelines-vote-ui, 백엔드 인터페이스 pipelines-vote-api, cli의 미러 레지스트리에서 해당 빌더 이미지를 미러링해야 합니다.

절차

  1. 프런트 엔드 인터페이스 pipelines-vote-ui의 미러 레지스트리에서 빌더 이미지를 미러링합니다.

    1. 필요한 이미지 태그를 가져오지 않았는지 확인합니다. 

      $ oc describe imagestream python -n openshift

      출력 예

      Name:			python
Namespace:		openshift
[...]

3.8-ubi9 (latest)
  tagged from registry.redhat.io/ubi9/python-38:latest
    prefer registry pullthrough when referencing this tag

  Build and run Python 3.8 applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/s2i-python-container/blob/master/3.8/README.md.
  Tags: builder, python
  Supports: python:3.8, python
  Example Repo: https://github.com/sclorg/django-ex.git

[...]

    2. 지원되는 이미지 태그를 프라이빗 레지스트리로 미러링합니다. 

      $ oc image mirror registry.redhat.io/ubi9/python-39:latest <mirror-registry>:<port>/ubi9/python-39

    3. 이미지를 가져옵니다. 

      $ oc tag <mirror-registry>:<port>/ubi9/python-39 python:latest --scheduled -n openshift

      이미지는 정기적으로 다시 가져와야 합니다. --scheduled 플래그를 사용하면 자동으로 이미지를 다시 가져올 수 있습니다.

    4. 지정된 태그가 있는 이미지를 가져왔는지 확인합니다. 

      $ oc describe imagestream python -n openshift

      출력 예

      Name:			python
Namespace:		openshift
[...]

latest
  updates automatically from registry  <mirror-registry>:<port>/ubi9/python-39

  *  <mirror-registry>:<port>/ubi9/python-39@sha256:3ee...

[...]

  2. 백엔드 인터페이스 pipelines-vote-api의 미러 레지스트리에서 빌더 이미지를 미러링합니다.

    1. 필요한 이미지 태그를 가져오지 않았는지 확인합니다. 

      $ oc describe imagestream golang -n openshift

      출력 예

      Name:			golang
Namespace:		openshift
[...]

1.14.7-ubi8 (latest)
  tagged from registry.redhat.io/ubi8/go-toolset:1.14.7
    prefer registry pullthrough when referencing this tag

  Build and run Go applications on UBI 8. For more information about using this builder image, including OpenShift considerations, see https://github.com/sclorg/golang-container/blob/master/README.md.
  Tags: builder, golang, go
  Supports: golang
  Example Repo: https://github.com/sclorg/golang-ex.git

[...]

    2. 지원되는 이미지 태그를 프라이빗 레지스트리로 미러링합니다. 

      $ oc image mirror registry.redhat.io/ubi9/go-toolset:latest <mirror-registry>:<port>/ubi9/go-toolset

    3. 이미지를 가져옵니다. 

      $ oc tag <mirror-registry>:<port>/ubi9/go-toolset golang:latest --scheduled -n openshift

      이미지는 정기적으로 다시 가져와야 합니다. --scheduled 플래그를 사용하면 자동으로 이미지를 다시 가져올 수 있습니다.

    4. 지정된 태그가 있는 이미지를 가져왔는지 확인합니다. 

      $ oc describe imagestream golang -n openshift

      출력 예

      Name:			golang
Namespace:		openshift
[...]

latest
  updates automatically from registry <mirror-registry>:<port>/ubi9/go-toolset

  * <mirror-registry>:<port>/ubi9/go-toolset@sha256:59a74d581df3a2bd63ab55f7ac106677694bf612a1fe9e7e3e1487f55c421b37

[...]

  3. cli의 미러 레지스트리에서 빌더 이미지를 미러링합니다.

    1. 필요한 이미지 태그를 가져오지 않았는지 확인합니다. 

      $ oc describe imagestream cli -n openshift

      출력 예

      Name:                   cli
Namespace:              openshift
[...]

latest
  updates automatically from registry quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551

  * quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551

[...]

    2. 지원되는 이미지 태그를 프라이빗 레지스트리로 미러링합니다. 

      $ oc image mirror quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551 <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev:latest

    3. 이미지를 가져옵니다. 

      $ oc tag <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev cli:latest --scheduled -n openshift

      이미지는 정기적으로 다시 가져와야 합니다. --scheduled 플래그를 사용하면 자동으로 이미지를 다시 가져올 수 있습니다.

    4. 지정된 태그가 있는 이미지를 가져왔는지 확인합니다. 

      $ oc describe imagestream cli -n openshift

      출력 예

      Name:                   cli
Namespace:              openshift
[...]

latest
  updates automatically from registry <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev

  * <mirror-registry>:<port>/openshift-release-dev/ocp-v4.0-art-dev@sha256:65c68e8c22487375c4c6ce6f18ed5485915f2bf612e41fef6d41cbfcdb143551

[...]

추가 리소스

3.5.6. 파이프라인 실행

PipelineRun 리소스는 파이프라인을 시작하고 특정 호출에 사용해야 하는 Git 및 이미지 리소스에 연결합니다. 그리고 파이프라인의 각 작업에 대해 TaskRun 리소스를 자동으로 생성하고 시작합니다.

절차

  1. 백엔드 애플리케이션의 파이프라인을 시작합니다. 

    $ tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-api \
    -p git-url=https://github.com/openshift/pipelines-vote-api.git \
    -p IMAGE='image-registry.openshift-image-registry.svc:5000/$(context.pipelineRun.namespace)/pipelines-vote-api' \
    --use-param-defaults

    위 명령은 파이프라인 실행을 위한 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿을 사용합니다.

  2. 파이프라인 실행의 진행 상황을 추적하려면 다음 명령을 입력합니다. 

    $ tkn pipelinerun logs <pipelinerun_id> -f

    위 명령의 <pipelinerun_id>는 이전 명령의 출력에서 반환된 PipelineRun의 ID입니다.

  3. 프런트 엔드 애플리케이션의 파이프라인을 시작합니다. 

    $ tkn pipeline start build-and-deploy \
    -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/01_pipeline/03_persistent_volume_claim.yaml \
    -p deployment-name=pipelines-vote-ui \
    -p git-url=https://github.com/openshift/pipelines-vote-ui.git \
    -p IMAGE='image-registry.openshift-image-registry.svc:5000/$(context.pipelineRun.namespace)/pipelines-vote-ui' \
    --use-param-defaults

  4. 파이프라인 실행의 진행 상황을 추적하려면 다음 명령을 입력합니다. 

    $ tkn pipelinerun logs <pipelinerun_id> -f

    위 명령의 <pipelinerun_id>는 이전 명령의 출력에서 반환된 PipelineRun의 ID입니다.

  5. 몇 분 후에 tkn pipelinerun list 명령을 사용하여 모든 파이프라인 실행을 나열하여 파이프라인이 성공적으로 실행되었는지 확인합니다. 

    $ tkn pipelinerun list

    파이프라인 실행 목록이 출력됩니다. 

     NAME                         STARTED      DURATION     STATUS
 build-and-deploy-run-xy7rw   1 hour ago   2 minutes    Succeeded
 build-and-deploy-run-z2rz8   1 hour ago   19 minutes   Succeeded

  6. 애플리케이션 경로를 가져옵니다. 

    $ oc get route pipelines-vote-ui --template='http://{{.spec.host}}'

    이전 명령의 출력에 주목하십시오. 이 경로를 사용하여 애플리케이션에 액세스할 수 있습니다.

  7. 이전 파이프라인의 파이프라인 리소스 및 서비스 계정을 사용하여 마지막 파이프라인 실행을 다시 실행하려면 다음을 실행합니다. 

    $ tkn pipeline start build-and-deploy --last

추가 리소스

3.5.7. 파이프라인에 트리거 추가

트리거를 사용하면 파이프라인에서 내보내기 이벤트 및 가져오기 요청 등의 외부 GitHub 이벤트에 응답할 수 있습니다. 애플리케이션에 대한 파이프라인을 어셈블하고 시작한 후 TriggerBinding, TriggerTemplate, Trigger, EventListener 리소스를 추가하여 GitHub 이벤트를 캡처합니다.

절차

  1. 다음 샘플 TriggerBinding YAML 파일의 내용을 복사하여 저장합니다. 

    apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerBinding
metadata:
  name: vote-app
spec:
  params:
  - name: git-repo-url
    value: $(body.repository.url)
  - name: git-repo-name
    value: $(body.repository.name)
  - name: git-revision
    value: $(body.head_commit.id)

  2. TriggerBinding 리소스를 생성합니다. 

    $ oc create -f <triggerbinding-yaml-file-name.yaml>

    또는 pipelines-tutorial Git 리포지토리에서 직접 TriggerBinding 리소스를 생성할 수 있습니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/03_triggers/01_binding.yaml

  3. 다음 샘플 TriggerTemplate YAML 파일의 내용을 복사하여 저장합니다. 

    apiVersion: triggers.tekton.dev/v1beta1
kind: TriggerTemplate
metadata:
  name: vote-app
spec:
  params:
  - name: git-repo-url
    description: The git repository url
  - name: git-revision
    description: The git revision
    default: pipelines-1.11
  - name: git-repo-name
    description: The name of the deployment to be created / patched

  resourcetemplates:
  - apiVersion: tekton.dev/v1beta1
    kind: PipelineRun
    metadata:
      generateName: build-deploy-$(tt.params.git-repo-name)-
    spec:
      serviceAccountName: pipeline
      pipelineRef:
        name: build-and-deploy
      params:
      - name: deployment-name
        value: $(tt.params.git-repo-name)
      - name: git-url
        value: $(tt.params.git-repo-url)
      - name: git-revision
        value: $(tt.params.git-revision)
      - name: IMAGE
        value: image-registry.openshift-image-registry.svc:5000/$(context.pipelineRun.namespace)/$(tt.params.git-repo-name)
      workspaces:
      - name: shared-workspace
        volumeClaimTemplate:
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 500Mi

    템플릿은 작업 영역의 스토리지 볼륨을 정의하기 위해 영구 볼륨 클레임을 생성하는 볼륨 클레임 템플릿을 지정합니다. 따라서 데이터 스토리지를 제공하기 위해 영구 볼륨 클레임을 생성할 필요가 없습니다.

  4. TriggerTemplate 리소스를 생성합니다. 

    $ oc create -f <triggertemplate-yaml-file-name.yaml>

    또는 pipelines-tutorial Git 리포지토리에서 직접 TriggerTemplate 리소스를 생성할 수도 있습니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/03_triggers/02_template.yaml

  5. 다음 샘플 Trigger YAML 파일의 콘텐츠를 복사하여 저장합니다. 

    apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: vote-trigger
spec:
  serviceAccountName: pipeline
  bindings:
    - ref: vote-app
  template:
    ref: vote-app

  6. Trigger 리소스를 생성합니다. 

    $ oc create -f <trigger-yaml-file-name.yaml>

    또는 pipelines-tutorial Git 리포지토리에서 직접 Trigger 리소스를 생성할 수도 있습니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/03_triggers/03_trigger.yaml

  7. 다음 샘플 EventListener YAML 파일의 내용을 복사하여 저장합니다. 

    apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: vote-app
spec:
  serviceAccountName: pipeline
  triggers:
    - triggerRef: vote-trigger

    또는 트리거 사용자 정의 리소스를 정의하지 않은 경우 트리거 이름을 참조하는 대신 바인딩 및 템플릿 사양을 EventListener YAML 파일에 추가합니다. 

    apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: vote-app
spec:
  serviceAccountName: pipeline
  triggers:
  - bindings:
    - ref: vote-app
    template:
      ref: vote-app

  8. 다음 단계를 수행하여 EventListener 리소스를 생성합니다.

    • 보안 HTTPS 연결을 사용하여 EventListener 리소스를 생성하려면 다음을 수행합니다.

      1. Eventlistener 리소스에 대한 보안 HTTPS 연결을 활성화하려면 레이블을 추가합니다. 

        $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled

      2. EventListener 리소스를 생성합니다. 

        $ oc create -f <eventlistener-yaml-file-name.yaml>

        또는 pipelines-tutorial Git 리포지토리에서 직접 EvenListener 리소스를 생성할 수도 있습니다. 

        $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.11/03_triggers/04_event_listener.yaml

      3. 재암호화 TLS 종료로 경로를 생성합니다. 

        $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>

        또는 재암호화 TLS 종료 YAML 파일을 만들어 보안 경로를 만들 수도 있습니다.

        보안 경로의 TLS 종료 YAML에 대한 재암호화의 예

        apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured 1
spec:
  host: <hostname>
  to:
    kind: Service
    name: frontend 2
  tls:
    termination: reencrypt         3
    key: [as in edge termination]
    certificate: [as in edge termination]
    caCertificate: [as in edge termination]
    destinationCACertificate: |-   4
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

        1 2
        63자로 제한되는 개체의 이름입니다.
        3
        termination 필드는 reencrypt로 설정됩니다. 이 필드는 유일한 필수 tls 필드입니다.
        4
        재암호화에 필요합니다. destinationCACertificate는 엔드포인트 인증서의 유효성을 검사하고 라우터에서 대상 pod로의 연결을 보호합니다. 서비스에서 서비스 서명 인증서를 사용 중이거나 관리자가 라우터의 기본 CA 인증서를 지정하고 서비스에 해당 CA에서 서명한 인증서가 있는 경우 이 필드를 생략할 수 있습니다.

        자세한 옵션은 oc create route reencrypt --help를 참조하십시오.

    • 비보안 HTTP 연결을 사용하여 EventListener 리소스를 생성하려면 다음을 수행합니다.

      1. EventListener 리소스를 생성합니다.

      2. EventListener 서비스에 공개 액세스가 가능하도록 이 서비스를 OpenShift Container Platform 경로로 노출합니다. 

        $ oc expose svc el-vote-app

3.5.8. 여러 네임스페이스를 제공하도록 이벤트 리스너 구성

참고

기본 CI/CD 파이프라인을 생성하려면 이 섹션을 건너뛸 수 있습니다. 그러나 배포 전략에 여러 네임스페이스가 포함된 경우 여러 네임스페이스를 제공하도록 이벤트 리스너를 구성할 수 있습니다.

EvenListener 오브젝트의 재사용성을 높이기 위해 클러스터 관리자는 여러 네임스페이스를 제공하는 다중 테넌트 이벤트 리스너로 구성하고 배포할 수 있습니다.

절차

  1. 이벤트 리스너에 대한 클러스터 전체 가져오기 권한을 구성합니다.

    1. ClusterRoleBinding 및 EventListener 오브젝트에 사용할 서비스 계정 이름을 설정합니다. 예를 들면 el-sa 입니다.

      ServiceAccount.yaml예

      apiVersion: v1
kind: ServiceAccount
metadata:
  name: el-sa
---

    2. ClusterRole.yaml 파일의 rules 섹션에서 모든 이벤트 리스너 배포에 대한 적절한 권한을 클러스터 전체에서 작동하도록 설정합니다.

      예 ClusterRole.yaml

      kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: el-sel-clusterrole
rules:
- apiGroups: ["triggers.tekton.dev"]
  resources: ["eventlisteners", "clustertriggerbindings", "clusterinterceptors", "triggerbindings", "triggertemplates", "triggers"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["impersonate"]
...

    3. 적절한 서비스 계정 이름 및 클러스터 역할 이름으로 클러스터 역할 바인딩을 구성합니다.

      예 ClusterRoleBinding.yaml

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: el-mul-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: el-sa
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: el-sel-clusterrole
...

  2. 이벤트 리스너의 spec 매개변수에서 서비스 계정 이름을 추가합니다(예: el-sa ). 이벤트 리스너가 제공하려는 네임스페이스의 이름으로 namespaceSelector 매개변수를 채웁니다.

    예제 EventListener.yaml

    apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: namespace-selector-listener
spec:
  serviceAccountName: el-sa
  namespaceSelector:
    matchNames:
    - default
    - foo
...

  3. 필요한 권한으로 서비스 계정을 생성합니다(예: foo-trigger-sa ). 트리거를 역할 바인딩에 사용합니다.

    ServiceAccount.yaml예

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: foo-trigger-sa
  namespace: foo
...

    RoleBinding.yaml의 예

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: triggercr-rolebinding
  namespace: foo
subjects:
- kind: ServiceAccount
  name: foo-trigger-sa
  namespace: foo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: tekton-triggers-eventlistener-roles
...

  4. 적절한 트리거 템플릿, 트리거 바인딩 및 서비스 계정 이름을 사용하여 트리거를 생성합니다.

    Trigger.yaml의 예

    apiVersion: triggers.tekton.dev/v1beta1
kind: Trigger
metadata:
  name: trigger
  namespace: foo
spec:
  serviceAccountName: foo-trigger-sa
  interceptors:
    - ref:
        name: "github"
      params:
        - name: "secretRef"
          value:
            secretName: github-secret
            secretKey: secretToken
        - name: "eventTypes"
          value: ["push"]
  bindings:
    - ref: vote-app
  template:
    ref: vote-app
...

3.5.9. Webhook 생성

Webhooks는 리포지토리에 구성된 이벤트가 발생할 때마다 이벤트 리스너가 수신하는 HTTP POST 메시지입니다. 이어서 이벤트 페이로드가 트리거 바인딩에 매핑되고 트리거 템플릿에 의해 처리됩니다. 트리거 템플릿은 최종적으로 Kubernetes 리소스를 생성 및 배포를 수행할 하나 이상의 파이프라인 실행을 시작합니다.

여기서는 분기된 Git 리포지토리 pipelines-vote-ui와 pipelines-vote-api에 대한 Webhook URL을 구성합니다. 이 URL은 공개 액세스 가능한 EventListener 서비스 경로를 가리킵니다.

참고

Webhook를 추가하려면 리포지토리에 대한 관리자 권한이 필요합니다. 리포지토리에 대한 관리자 액세스 권한이 없으면 시스템 관리자에게 요청하여 Webhook을 추가하십시오.

절차

  1. Webhook URL을 가져옵니다.

    • 보안 HTTPS 연결의 경우 다음을 수행합니다. 

      $ echo "URL: $(oc  get route el-vote-app --template='https://{{.spec.host}}')"

    • HTTP(비보안) 연결의 경우 다음을 수행합니다. 

      $ echo "URL: $(oc  get route el-vote-app --template='http://{{.spec.host}}')"

      출력에서 가져온 URL을 기록해 둡니다.

  2. 프런트 엔드 리포지토리에서 수동으로 Webhook을 구성합니다.

    1. 브라우저에서 프런트 엔드 Git 리포지토리 pipelines-vote-ui를 엽니다.
    2. Settings → Webhook → Webhook 추가를 클릭합니다.

    3. Webhooks/Add Webhook 페이지에서:

      1. Payload URL 필드에 1단계의 Webhook URL을 입력합니다.
      2. Content type으로 application/json을 선택합니다.
      3. Secret 필드에 시크릿을 지정합니다.
      4. Just the push event이 선택되어 있는지 확인합니다.
      5. Active를 선택하십시오
      6. Add Webhook를 클릭합니다.
  3. 백엔드 리포지토리 pipelines-vote-api에 대해 2단계를 반복합니다.

3.5.10. 파이프라인 실행 트리거

Git 리포지토리에서 push 이벤트가 발생할 때마다 구성된 Webhook에서 공개 노출된 EventListener 서비스 경로로 이벤트 페이로드를 보냅니다. 애플리케이션의 EventListener 서비스는 페이로드를 처리하여 관련 TriggerBinding 및 TriggerTemplate 쌍으로 전달합니다. TriggerBinding 리소스는 매개변수를 추출하고 TriggerTemplate 리소스는 이러한 매개변수를 사용하여 리소스 생성 방식을 지정합니다. 그리고 애플리케이션을 다시 빌드 및 배포할 수도 있습니다.

이 섹션에서는 비어 있는 커밋을 프런트 엔드 pipelines-vote-ui 리포지토리로 내보냅니다. 그러면 파이프라인 실행이 트리거됩니다.

절차

  1. 터미널에서 분기된 Git 리포지토리 pipelines-vote-ui를 복제합니다. 

    $ git clone git@github.com:<your GitHub ID>/pipelines-vote-ui.git -b pipelines-1.11

  2. 비어 있는 커밋을 푸시합니다. 

    $ git commit -m "empty-commit" --allow-empty && git push origin pipelines-1.11

  3. 파이프라인 실행이 트리거되었는지 확인합니다. 

    $ tkn pipelinerun list

    새로운 파이프라인 실행이 시작되었습니다.

3.5.11. 사용자 정의 프로젝트에 대한 트리거에 대한 이벤트 리스너 모니터링 활성화

클러스터 관리자는 사용자 정의 프로젝트에서 Triggers 서비스에 대한 이벤트 리스너 지표를 수집하고 OpenShift Container Platform 웹 콘솔에 표시하려면 각 이벤트 리스너에 대한 서비스 모니터를 생성할 수 있습니다. HTTP 요청을 수신할 때 Triggers 서비스에 대한 이벤트 리스너는 3개의 metrics - eventlistener_http_duration_seconds,eventlistener_event_count, eventlistener_triggered_resources 를 반환합니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 로그인했습니다.
  • Red Hat OpenShift Pipelines Operator가 설치되어 있습니다.
  • 사용자 정의 프로젝트에 대한 모니터링을 활성화했습니다.

절차

  1. 각 이벤트 리스너에 대해 서비스 모니터를 생성합니다. 예를 들어 테스트 네임스페이스에서 github-listener 이벤트 리스너에 대한 지표를 보려면 다음 서비스 모니터를 생성합니다. 

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    app.kubernetes.io/managed-by: EventListener
    app.kubernetes.io/part-of: Triggers
    eventlistener: github-listener
  annotations:
    networkoperator.openshift.io/ignore-errors: ""
  name: el-monitor
  namespace: test
spec:
  endpoints:
    - interval: 10s
      port: http-metrics
  jobLabel: name
  namespaceSelector:
    matchNames:
      - test
  selector:
    matchLabels:
      app.kubernetes.io/managed-by: EventListener
      app.kubernetes.io/part-of: Triggers
      eventlistener: github-listener
...

  2. 이벤트 리스너로 요청을 전송하여 서비스 모니터를 테스트합니다. 예를 들어 빈 커밋을 내보냅니다. 

    $ git commit -m "empty-commit" --allow-empty && git push origin main
  3. OpenShift Container Platform 웹 콘솔에서 Administrator → Observe → Metrics 로 이동합니다.
  4. 지표를 보려면 이름으로 검색합니다. 예를 들어 github-listener 이벤트 리스너에 대한 eventlistener_http_resources 메트릭의 세부 정보를 보려면 eventlistener_http_resources 키워드를 사용하여 검색합니다.

추가 리소스

3.5.12. GitHub Interceptor에서 가져오기 요청 기능 구성

GitHub Interceptor를 사용하면 GitHub Webhook를 검증하고 필터링하는 논리를 생성할 수 있습니다. 예를 들어 웹 후크의 출처를 확인하고 지정된 기준에 따라 들어오는 이벤트를 필터링할 수 있습니다. GitHub Interceptor를 사용하여 이벤트 데이터를 필터링할 때 Interceptor에서 필드에 허용할 수 있는 이벤트 유형을 지정할 수 있습니다. Red Hat OpenShift Pipelines에서는 GitHub Interceptor의 다음 기능을 사용할 수 있습니다.

  • 변경된 파일에 따라 가져오기 요청 이벤트를 필터링합니다.
  • 구성된 GitHub 소유자를 기반으로 풀 요청 검증

3.5.12.1. GitHub Interceptor를 사용하여 가져오기 요청 필터링

푸시 및 가져오기 이벤트에 대해 변경된 파일을 기반으로 GitHub 이벤트를 필터링할 수 있습니다. 이를 통해 Git 리포지토리의 관련 변경 사항에 대해서만 파이프라인을 실행할 수 있습니다. GitHub Interceptor는 변경된 모든 파일의 쉼표로 구분된 목록을 추가하고 CEL 인터셉터를 사용하여 변경된 파일을 기반으로 들어오는 이벤트를 필터링합니다. 변경된 파일 목록은 최상위 확장 필드의 이벤트 페이로드의 changed_files 속성에 추가됩니다.

사전 요구 사항

  • Red Hat OpenShift Pipelines Operator가 설치되어 있습니다.

절차

  1. 다음 중 하나를 실행합니다.

    • 공용 GitHub 리포지토리의 경우 아래 표시된 YAML 구성 파일에서 addChangedFiles 매개변수 값을 true 로 설정합니다. 

      apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-add-changed-files-pr-listener
spec:
  triggers:
    - name: github-listener
      interceptors:
        - ref:
            name: "github"
            kind: ClusterInterceptor
            apiVersion: triggers.tekton.dev
          params:
          - name: "secretRef"
            value:
              secretName: github-secret
              secretKey: secretToken
          - name: "eventTypes"
            value: ["pull_request", "push"]
          - name: "addChangedFiles"
            value:
              enabled: true
        - ref:
            name: cel
          params:
          - name: filter
            value: extensions.changed_files.matches('controllers/')
...

    • 프라이빗 GitHub 리포지토리의 경우 addChangedFiles 매개변수 값을 true 로 설정하고 아래에 표시된 YAML 구성 파일에 액세스 토큰 세부 정보 secretName 및 secretKey 를 제공합니다. 

      apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-add-changed-files-pr-listener
spec:
  triggers:
    - name: github-listener
      interceptors:
        - ref:
            name: "github"
            kind: ClusterInterceptor
            apiVersion: triggers.tekton.dev
          params:
          - name: "secretRef"
            value:
              secretName: github-secret
              secretKey: secretToken
          - name: "eventTypes"
            value: ["pull_request", "push"]
          - name: "addChangedFiles"
            value:
              enabled: true
              personalAccessToken:
                secretName: github-pat
                secretKey: token
        - ref:
            name: cel
          params:
          - name: filter
            value: extensions.changed_files.matches('controllers/')
...
  2. 구성 파일을 저장합니다.

3.5.12.2. GitHub Interceptors를 사용하여 가져오기 요청 검증

GitHub Interceptor를 사용하여 리포지토리에 대해 구성된 GitHub 소유자를 기반으로 가져오기 요청 처리의 유효성을 확인할 수 있습니다. 이 검증을 사용하면 PipelineRun 또는 TaskRun 오브젝트를 불필요한 실행을 방지할 수 있습니다. GitHub Interceptor는 사용자 이름이 소유자로 나열되거나 리포지토리 소유자가 구성 가능한 댓글을 발행하는 경우에만 가져오기 요청을 처리합니다. 예를 들어 가져오기 요청에서 /ok-to-test 를 소유자로 언급하면 PipelineRun 또는 TaskRun 이 트리거됩니다.

참고

소유자는 리포지토리의 루트에 있는 OWNERS 파일에 구성됩니다.

사전 요구 사항

  • Red Hat OpenShift Pipelines Operator가 설치되어 있습니다.

절차

  1. 시크릿 문자열 값을 생성합니다.
  2. 해당 값으로 GitHub Webhook를 구성합니다.
  3. secret 값이 포함된 secretRef 라는 Kubernetes 시크릿을 생성합니다.
  4. Kubernetes 시크릿을 GitHub Interceptor에 대한 참조로 전달합니다.
  5. 소유자 파일을 만들고 승인자 목록을 승인자 섹션에 추가합니다.

  6. 다음 중 하나를 실행합니다.

    • 공용 GitHub 리포지토리의 경우 아래 YAML 구성 파일에서 githubOwners 매개변수 값을 true 로 설정합니다. 

      apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-owners-listener
spec:
  triggers:
    - name: github-listener
      interceptors:
        - ref:
            name: "github"
            kind: ClusterInterceptor
            apiVersion: triggers.tekton.dev
          params:
            - name: "secretRef"
              value:
                secretName: github-secret
                secretKey: secretToken
            - name: "eventTypes"
              value: ["pull_request", "issue_comment"]
            - name: "githubOwners"
              value:
                enabled: true
                checkType: none
...

    • 프라이빗 GitHub 리포지토리의 경우 githubOwners 매개변수 값을 true 로 설정하고 아래에 표시된 YAML 구성 파일에 액세스 토큰 세부 정보 secretName 및 secretKey 를 제공합니다. 

      apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
  name: github-owners-listener
spec:
  triggers:
    - name: github-listener
      interceptors:
        - ref:
            name: "github"
            kind: ClusterInterceptor
            apiVersion: triggers.tekton.dev
          params:
            - name: "secretRef"
              value:
                secretName: github-secret
                secretKey: secretToken
            - name: "eventTypes"
              value: ["pull_request", "issue_comment"]
            - name: "githubOwners"
              value:
                enabled: true
                personalAccessToken:
                  secretName: github-token
                  secretKey: secretToken
                checkType: all
...
      참고

      checkType 매개변수는 인증이 필요한 GitHub 소유자를 지정하는 데 사용됩니다. 해당 값을 orgMembers,repoMembers 또는 all 으로 설정할 수 있습니다.

  7. 구성 파일을 저장합니다.

3.5.13. 추가 리소스

3.6. 버전이 지정되지 않은 클러스터 작업 관리

클러스터 관리자는 Red Hat OpenShift Pipelines Operator를 설치하면 버전 지정된 클러스터 작업(VCT) 및 버전이 없는 클러스터 작업 (NVCT)이라는 각 기본 클러스터 작업의 변형이 생성됩니다. 예를 들어 Red Hat OpenShift Pipelines Operator v1.7을 설치하면 buildah-1-7-0 VCT 및 buildah NVCT가 생성됩니다.

NVCT와 VCT는 둘 다 params,작업 공간 및 단계를 포함하여 동일한 메타데이터, 동작 및 사양을 갖습니다. 그러나 비활성화하거나 Operator를 업그레이드할 때 다르게 작동합니다.

중요

Red Hat OpenShift Pipelines 1.10에서는 클러스터 작업 기능이 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

3.6.1. 버전이 지정되지 않은 클러스터 작업과 버전이 지정된 클러스터 작업 간의 차이점

버전이 지정되지 않은 클러스터 작업에는 다른 이름 지정 규칙이 있습니다. 또한 Red Hat OpenShift Pipelines Operator는 이를 다르게 업그레이드합니다.

표 3.6. 버전이 지정되지 않은 클러스터 작업과 버전이 지정된 클러스터 작업 간의 차이점

 버전이 없는 클러스터 작업버전이 지정된 클러스터 작업

nomenclature

NVCT에는 클러스터 작업의 이름만 포함됩니다. 예를 들어 Operator v1.7과 함께 설치된 Buildah의 NVCT 이름은 buildah 입니다.

VCT에는 클러스터 작업의 이름이 포함되고 그 뒤에 접미사로 버전이 있습니다. 예를 들어 Operator v1.7과 함께 설치된 Buildah의 VCT 이름은 buildah-1-7-0 입니다.

업그레이드

Operator를 업그레이드하면 버전이 아닌 클러스터 작업을 최신 변경 사항으로 업데이트합니다. NVCT의 이름은 변경되지 않은 상태로 유지됩니다.

Operator 업그레이드는 최신 버전의 VCT를 설치하고 이전 버전을 유지합니다. VCT의 최신 버전은 업그레이드된 Operator에 해당합니다. 예를 들어, Operator 1.7을 설치하면 buildah-1-7-0 을 설치하고 buildah-1-6-0 을 유지합니다.

3.6.2. 버전이 지정되지 않은 클러스터 작업의 이점 및 버전 지정

프로덕션 환경에서 버전이 지정되지 않거나 버전이 지정된 클러스터 작업을 프로덕션 환경의 표준으로 채택하기 전에 클러스터 관리자가 이러한 이점과 이점을 고려할 수 있습니다.

표 3.7. 버전이 지정되지 않은 클러스터 작업의 이점 및 버전 지정

클러스터 작업이점경화

버전이 지정되지 않은 클러스터 작업(NVCT)

  • 최신 업데이트 및 버그 수정이 포함된 파이프라인 배포를 선호하는 경우 NVCT를 사용합니다.
  • Operator 업그레이드는 버전이 없는 클러스터 작업을 업그레이드하여 여러 버전의 클러스터 작업보다 적은 리소스를 사용합니다.

NVCT를 사용하는 파이프라인을 배포하는 경우 자동으로 업그레이드된 클러스터 작업이 이전 버전과 호환되지 않는 경우 Operator 업그레이드 후 중단될 수 있습니다.

버전 지정된 클러스터 작업(VCT)

  • 프로덕션 환경에서 안정적인 파이프라인을 선호하는 경우 VCT를 사용하십시오.
  • 클러스터 작업의 최신 버전이 설치된 후에도 이전 버전이 클러스터에 유지됩니다. 이전 클러스터 작업을 계속 사용할 수 있습니다.
  • 이전 버전의 클러스터 작업을 계속 사용하는 경우 최신 기능 및 중요 보안 업데이트가 누락될 수 있습니다.
  • 작동하지 않는 이전 버전의 클러스터 작업은 클러스터 리소스를 사용합니다.
  • * 업그레이드 후에는 Operator가 이전 VCT를 관리할 수 없습니다. oc delete clustertask 명령을 사용하여 이전 VCT를 수동으로 삭제할 수 있지만 복원할 수는 없습니다.

3.6.3. 버전이 지정되지 않은 클러스터 작업 비활성화

클러스터 관리자는 OpenShift Pipelines Operator가 설치한 클러스터 작업을 비활성화할 수 있습니다.

절차

  1. 버전이 지정되지 않은 클러스터 작업 및 최신 버전 클러스터 작업을 삭제하려면 TektonConfig CRD(사용자 정의 리소스 정의)를 편집하고 spec.addon.params 의 clusterTasks 매개변수를 false 로 설정합니다.

    TektonConfig CR의 예

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  params:
  - name: createRbacResource
    value: "false"
  profile: all
  targetNamespace: openshift-pipelines
  addon:
    params:
    - name: clusterTasks
      value: "false"
...

    클러스터 작업을 비활성화하면 Operator는 버전이 지정되지 않은 모든 클러스터 작업을 제거하고 클러스터에서 버전 지정된 클러스터 작업의 최신 버전만 제거합니다.

    참고

    클러스터 작업을 다시 활성화하면 버전이 없는 클러스터 작업이 설치됩니다.

  2. 선택 사항: 버전 지정된 클러스터 작업의 이전 버전을 삭제하려면 다음 방법 중 하나를 사용합니다.

    1. 이전의 개별 클러스터 작업을 삭제하려면 oc delete clustertask 명령 다음에 버전이 지정된 클러스터 작업 이름을 사용합니다. 예를 들면 다음과 같습니다. 

      $ oc delete clustertask buildah-1-6-0

    2. 이전 버전의 Operator에서 생성한 모든 버전 클러스터 작업을 삭제하려면 해당 설치 프로그램 세트를 삭제할 수 있습니다. 예를 들면 다음과 같습니다. 

      $ oc delete tektoninstallerset versioned-clustertask-1-6-k98as
      경고

      이전 버전의 클러스터 작업을 삭제하면 복원할 수 없습니다. 현재 버전의 Operator가 생성한 버전 및 버전이 없는 클러스터 작업만 복원할 수 있습니다.

3.7. OpenShift Pipelines에서 Tekton Hub 사용

중요

Tekton Hub는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

Tekton Hub를 사용하면 CI/CD 워크플로에 사용할 수 있는 작업과 파이프라인을 검색, 검색 및 공유할 수 있습니다. Tekton Hub의 공용 인스턴스는 hub.tekton.dev 에서 사용할 수 있습니다. 클러스터 관리자는 TektonHub CR(사용자 정의 리소스)의 구성을 수정하여 Tekton Hub의 사용자 지정 인스턴스를 설치하고 배포할 수도 있습니다.

3.7.1. OpenShift Container Platform 클러스터에 Tekton Hub 설치 및 배포

Tekton Hub는 선택적 구성 요소입니다. 클러스터 관리자는 TektonConfig CR(사용자 정의 리소스)을 사용하여 설치할 수 없습니다. Tekton Hub를 설치하고 관리하려면 TektonHub CR을 사용합니다.

다음 두 가지 모드를 사용하여 클러스터에 Tekton Hub를 설치할 수 있습니다.

  • Tekton Hub 아티팩트에 대한 로그인 권한 부여 및 평가 없음
  • Tekton Hub 아티팩트에 대한 로그인 권한 부여 및 등급 사용
참고

Github Enterprise 또는 Gitlab Enterprise를 사용하는 경우 엔터프라이즈 서버와 동일한 네트워크에 Tekton Hub를 설치 및 배포합니다. 예를 들어 엔터프라이즈 서버가 VPN에서 실행되는 경우 VPN 뒤에도 있는 클러스터에 Tekton Hub를 배포합니다.

3.7.1.1. 로그인 및 등급 없이 Tekton Hub 설치

기본 구성으로 클러스터에 Tekton Hub를 자동으로 설치할 수 있습니다. 기본 구성을 사용하는 경우 Tekton Hub는 Tekton Hub 아티팩트에 대한 권한 부여 및 등급으로 로그인을 지원하지 않습니다.

사전 요구 사항

  • Red Hat OpenShift Pipelines Operator가 클러스터의 기본 openshift-pipelines 네임스페이스에 설치되어 있는지 확인합니다.

절차

  1. 다음 예와 유사한 TektonHub CR을 생성합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace: openshift-pipelines 1
  db:                      # Optional: If you want to use custom database
    secret: tekton-hub-db  # Name of db secret should be `tekton-hub-db`

  categories:              # Optional: If you want to use custom categories
    - Automation
    - Build Tools
    - CLI
    - Cloud
    - Code Quality
    - ...

  catalogs:                # Optional: If you want to use custom catalogs
    - name: tekton
      org: tektoncd
      type: community
      provider: github
      url: https://github.com/tektoncd/catalog
      revision: main

  scopes:                   # Optional: If you want to add new users
    - name: agent:create
      users: [abc, qwe, pqr]
    - name: catalog:refresh
      users: [abc, qwe, pqr]
    - name: config:refresh
      users: [abc, qwe, pqr]

  default:                   # Optional: If you want to add custom default scopes
    scopes:
      - rating:read
      - rating:write

  api:
    catalogRefreshInterval: 30m 2
    1
    Tekton Hub를 설치해야 하는 네임스페이스입니다. 기본값은 openshift-pipelines 입니다.
    2
    카탈로그가 자동으로 새로 고침되는 시간 간격입니다. 지원되는 시간 단위는 초(s), 분(m), 시간(h), 일(d), 주(w)입니다. 기본 간격은 30분입니다.
    참고

    TektonHub CR에서 선택적 필드에 대한 사용자 정의 값을 제공하지 않으면 Tekton Hub API 구성 맵에 구성된 기본값이 사용됩니다.

  2. TektonHub CR을 적용합니다. 

    $ oc apply -f <tekton-hub-cr>.yaml

  3. 설치 상태를 확인합니다. TektonHub CR은 안정적인 상태를 유지하는 데 시간이 걸릴 수 있습니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                    UIURL
hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

3.7.1.2. 로그인 및 등급을 사용하여 Tekton Hub 설치

Tekton Hub 아티팩트에 대한 권한 부여 및 등급으로 로그인을 지원하는 사용자 지정 구성으로 클러스터에 Tekton Hub를 설치할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift Pipelines Operator가 클러스터의 기본 openshift-pipelines 네임스페이스에 설치되어 있는지 확인합니다.

절차

  1. Git 리포지토리 호스팅 공급자를 사용하여 OAuth 애플리케이션을 생성하고 클라이언트 ID 및 클라이언트 보안을 기록해 둡니다. 지원되는 공급자는 GitHub, GitLab, BitBucket입니다.

  2. Tekton Hub API 시크릿을 포함하도록 < tekton_hub_root>/config/02-api/20-api-secret.yaml 파일을 편집합니다. 예를 들면 다음과 같습니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: tekton-hub-api
  namespace: openshift-pipelines
type: Opaque
stringData:
  GH_CLIENT_ID: 1
  GH_CLIENT_SECRET: 2
  GL_CLIENT_ID: 3
  GL_CLIENT_SECRET: 4
  BB_CLIENT_ID: 5
  BB_CLIENT_SECRET: 6
  JWT_SIGNING_KEY: 7
  ACCESS_JWT_EXPIRES_IN: 8
  REFRESH_JWT_EXPIRES_IN: 9
  AUTH_BASE_URL: 10
  GHE_URL: 11
  GLE_URL: 12
    1
    GitHub OAuth 애플리케이션의 클라이언트 ID입니다.
    2
    GitHub OAuth 애플리케이션의 클라이언트 시크릿.
    3
    GitLab OAuth 애플리케이션의 클라이언트 ID.
    4
    GitLab OAuth 애플리케이션의 클라이언트 시크릿.
    5
    BitBucket OAuth 애플리케이션의 클라이언트 ID입니다.
    6
    BitBucket OAuth 애플리케이션의 클라이언트 시크릿.
    7
    사용자가 생성한 JSON 웹 토큰(JWT)에 서명하는 데 사용되는 긴 임의 문자열입니다.
    8
    액세스 토큰이 만료된 후 시간 제한을 추가합니다. 예를 들어 1m. 여기서 m은 분을 나타냅니다. 지원되는 시간 단위는 초(s), 분(m), 시간(h), 일(d), 주(w)입니다.
    9
    새로 고침 토큰이 만료된 후 시간 제한을 추가합니다. 예를 들어 1m. 여기서 m 은 분을 나타냅니다. 지원되는 시간 단위는 초(s), 분(m), 시간(h), 일(d), 주(w)입니다. 토큰 새로 고침에 설정된 만료 시간이 토큰 액세스에 설정된 만료 시간보다 큰지 확인합니다.
    10
    OAuth 애플리케이션의 경로 URL입니다.
    11
    GitHub Enterprise URL: GitHub Enterprise를 사용하여 인증하는 경우. 카탈로그에 이 필드의 값으로 URL을 제공하지 마십시오.
    12
    GitLab Enterprise URL: GitLab Enterprise를 사용하여 인증하는 경우. 카탈로그에 이 필드의 값으로 URL을 제공하지 마십시오.
    참고

    배포에 관련이 없는 Git 리포지토리 호스팅 서비스 공급자에 대해 사용되지 않은 필드를 삭제할 수 있습니다.

  3. 다음 예와 유사한 TektonHub CR을 생성합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace: openshift-pipelines 1
  db: 2
    secret: tekton-hub-db 3

  categories: 4
    - Automation
    - Build Tools
    - CLI
    - Cloud
    - Code Quality
      ...

  catalogs: 5
    - name: tekton
      org: tektoncd
      type: community
      provider: github
      url: https://github.com/tektoncd/catalog
      revision: main

  scopes: 6
    - name: agent:create
      users: [<username>]
    - name: catalog:refresh
      users: [<username>]
    - name: config:refresh
      users: [<username>]

  default: 7
    scopes:
      - rating:read
      - rating:write

  api:
    catalogRefreshInterval: 30m 8
    1
    Tekton Hub를 설치해야 하는 네임스페이스입니다. 기본값은 openshift-pipelines 입니다.
    2
    선택사항: Crunchy Postgres 데이터베이스와 같은 사용자 지정 데이터베이스입니다.
    3
    데이터베이스 시크릿의 이름은 tekton-hub-db 여야 합니다.
    4
    선택사항: Tekton Hub의 작업 및 파이프라인에 맞게 사용자 지정된 카테고리입니다.
    5
    선택사항: Tekton Hub용 카탈로그 사용자 지정.
    6
    선택사항: 추가 사용자입니다. [<username_1>, <username_2>, <username_3>] 과 같은 여러 사용자를 처리할 수 있습니다.
    7
    선택 사항: 사용자 지정된 기본 범위입니다.
    8
    카탈로그가 자동으로 새로 고침되는 시간 간격입니다. 지원되는 시간 단위는 초(s), 분(m), 시간(h), 일(d), 주(w)입니다. 기본 간격은 30분입니다.
    참고

    TektonHub CR에서 선택적 필드에 대한 사용자 정의 값을 제공하지 않으면 Tekton Hub API 구성 맵에 구성된 기본값이 사용됩니다.

  4. TektonHub CR을 적용합니다. 

    $ oc apply -f <tekton-hub-cr>.yaml

  5. 설치 상태를 확인합니다. TektonHub CR은 안정적인 상태를 유지하는 데 시간이 걸릴 수 있습니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                    UIURL
hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

3.7.2. 선택 사항: Tekton Hub에서 사용자 지정 데이터베이스 사용

클러스터 관리자는 Operator가 설치한 기본 PostgreSQL 데이터베이스 대신 Tekton Hub에서 사용자 지정 데이터베이스를 사용할 수 있습니다. 설치 시 사용자 지정 데이터베이스를 연결하고 Tekton Hub에서 제공하는 db-migration,api, ui 인터페이스와 함께 사용할 수 있습니다. 또는 기본 데이터베이스와 함께 설치가 완료된 후에도 사용자 지정 데이터베이스를 Tekton Hub와 연결할 수 있습니다.

절차

  1. 다음 키를 사용하여 대상 네임스페이스에 tekton-hub-db 라는 시크릿을 생성합니다.

    • POSTGRES_HOST
    • POSTGRES_DB
    • POSTGRES_USER
    • POSTGRES_PASSWORD

    • POSTGRES_PORT

      예: 사용자 정의 데이터베이스 보안

      apiVersion: v1
kind: Secret
metadata:
  name: tekton-hub-db
  labels:
    app: tekton-hub-db
type: Opaque
stringData:
  POSTGRES_HOST: <The name of the host of the database>
  POSTGRES_DB: <Name of the database>
  POSTGRES_USER: <username>
  POSTGRES_PASSWORD: <password>
  POSTGRES_PORT: <The port that the database is listening on>
...

      참고

      기본 대상 네임스페이스는 openshift-pipelines 입니다.

  2. TektonHub CR에서 데이터베이스 secret 특성 값을 tekton-hub-db 로 설정합니다.

    예: 사용자 정의 데이터베이스 시크릿 추가

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace: openshift-pipelines
  db:
    secret: tekton-hub-db
  api:
    hubConfigUrl: https://raw.githubusercontent.com/tektoncd/hub/main/config.yaml
    catalogRefreshInterval: 30m
...

  3. 업데이트된 TektonHub CR을 사용하여 사용자 지정 데이터베이스를 Tekton Hub와 연결합니다.

    1. 클러스터에 Tekton Hub를 설치할 때 사용자 지정 데이터베이스를 연결하는 경우 업데이트된 TektonHub CR을 적용합니다. 

      $ oc apply -f <tekton-hub-cr>.yaml

    2. 또는 Tekton Hub 설치 완료 후 사용자 지정 데이터베이스를 연결하는 경우 기존 TektonHub CR을 업데이트된 TektonHub CR로 교체합니다. 

      $ oc replace -f <tekton-hub-cr>.yaml

  4. 설치 상태를 확인합니다. TektonHub CR은 안정적인 상태를 유지하는 데 시간이 걸릴 수 있습니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                    UIURL
hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

3.7.2.1. 선택사항: Crunchy Postgres 데이터베이스 및 Tekton Hub 설치

클러스터 관리자는 Crunchy Postgres 데이터베이스를 설치하고 기본 데이터베이스 대신 Tekton Hub를 사용하도록 구성할 수 있습니다.

사전 요구 사항

  • Operator Hub에서 Crunchy Postgres Operator를 설치합니다.
  • Crunchy Postgres 데이터베이스를 시작하는 Postgres 인스턴스를 생성합니다.

절차

  1. Crunchy Postgres Pod로 이동합니다.

    예: test-instance1-m7h-0 Pod 로 이동

    $ oc exec -it -n openshift-operators test-instance1-m7hh-0 -- /bin/sh

Defaulting container name to database.
Use 'oc describe pod/test-instance1-m7hh-0 -n openshift-operators' to see all of the containers in this pod.
sh-4.4$ psql -U postgres
psql (14.4)
Type "help" for help.

  2. pg_hba.conf 파일을 찾습니다. 

    postgres=# SHOW hba_file;
         hba_file
--------------------------
 /pgdata/pg14/pg_hba.conf
(1 row)

postgres=#
  3. 데이터베이스를 종료합니다.

  4. pg_hba.conf 파일에 모든 0.0.0.0/0 md5 , 들어오는 모든 연결에 액세스하는 데 필요한 항목 호스트가 있는지 확인합니다. 또한 pg_hba.conf 파일의 끝에 항목을 추가합니다.

    예: pg_hba.conf 파일

    sh-4.4$ cat /pgdata/pg14/pg_hba.conf

# Do not edit this file manually!
# It will be overwritten by Patroni!
local all "postgres" peer
hostssl replication "_crunchyrepl" all cert
hostssl "postgres" "_crunchyrepl" all cert
host all "_crunchyrepl" all reject
hostssl all all all md5
host  all  all 0.0.0.0/0 md5

  5. pg_hba.conf 파일을 저장하고 데이터베이스를 다시 로드합니다. 

    sh-4.4$ psql -U postgres
psql (14.4)
Type "help" for help.

postgres=# SHOW hba_file;
         hba_file
--------------------------
 /pgdata/pg14/pg_hba.conf
(1 row)

postgres=# SELECT pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)
  6. 데이터베이스를 종료합니다.

  7. Crunchy Postgres 호스트의 시크릿 값을 디코딩합니다.

    예: Crunchy Postgres 호스트의 시크릿 값 디코딩

    $ echo 'aGlwcG8tcHJpbWFyeS5vcGVuc2hpZnQtb3BlcmF0b3JzLnN2YyA=' | base64 --decode
test-primary.openshift-operators.svc

  8. 다음 키를 사용하여 대상 네임스페이스에 tekton-hub-db 라는 시크릿을 생성합니다.

    • POSTGRES_HOST
    • POSTGRES_DB
    • POSTGRES_USER
    • POSTGRES_PASSWORD

    • POSTGRES_PORT

      예: 사용자 정의 데이터베이스 보안

      apiVersion: v1
kind: Secret
metadata:
  name: tekton-hub-db
  labels:
    app: tekton-hub-db
type: Opaque
stringData:
  POSTGRES_HOST: test-primary.openshift-operators.svc
  POSTGRES_DB: test
  POSTGRES_USER: <username>
  POSTGRES_PASSWORD: <password>
  POSTGRES_PORT: '5432'
...

    참고

    기본 대상 네임스페이스는 openshift-pipelines 입니다.

  9. TektonHub CR에서 데이터베이스 secret 특성 값을 tekton-hub-db 로 설정합니다.

    예: 사용자 정의 데이터베이스 시크릿 추가

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace: openshift-pipelines
  db:
    secret: tekton-hub-db
...

  10. 업데이트된 TektonHub CR을 사용하여 사용자 지정 데이터베이스를 Tekton Hub와 연결합니다. 

    $ oc apply -f <tekton-hub-cr>.yaml

  11. 설치 상태를 확인합니다. TektonHub CR은 정상 상태를 늘리는 데 약간의 시간이 걸릴 수 있습니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                    UIURL
hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

3.7.2.2. 선택사항: Tekton Hub 데이터를 기존 Crunchy Postgres 데이터베이스로 마이그레이션

Tekton Hub는 Crunchy Postgres를 사용자 정의 데이터베이스로 사용할 수 있도록 지원합니다. 기본 데이터베이스가 있는 사전 설치된 Tekton Hub의 경우 클러스터 관리자는 내부 또는 기본 데이터베이스에서 외부 Crunchy Postgres 데이터베이스로 Tekton Hub 데이터를 마이그레이션한 후 Crunchy Postgres를 사용자 정의 데이터베이스로 사용할 수 있습니다.

절차

  1. 내부 또는 기본 데이터베이스의 기존 데이터를 포드의 파일로 덤프합니다.

    예: 덤프 데이터

    $ pg_dump -Ft -h localhost -U postgres hub -f /tmp/hub.dump

  2. 데이터가 포함된 파일을 로컬 시스템에 복사합니다.

    명령 형식

    $ oc cp -n <namespace> <podName>:<path-to-hub.dump> <path-to-local-system>

    예제

    $ oc cp -n openshift-pipelines tekton-hub-db-7d6d888c67-p7mdr:/tmp/hub.dump /home/test_user/Downloads/hub.dump

  3. 로컬 시스템의 데이터 덤프가 포함된 파일을 외부 Crunchy Postgres 데이터베이스를 실행하는 pod로 복사합니다.

    명령 형식

    $ oc cp -n <namespace> <path-to-local-system> <podName>:<path-to-hub.dump>

    예제

    $ oc cp -n openshift-operators /home/test_user/Downloads/hub.dump test-instance1-spnz-0:/tmp/hub.dump

  4. Crunchy Postgres 데이터베이스에서 데이터를 복원합니다.

    명령 형식

    $ pg_restore -d <database-name> -h localhost -U postgres <path-where-file-is-copied>

    예제

    $ pg_restore -d test -h localhost -U postgres /tmp/hub.dump

  5. Crunchy Postgres Pod로 들어갑니다. .Example: test-instance1-m7hh-0 Pod로 가져오기 

    $ oc exec -it -n openshift-operators test-instance1-m7hh-0 -- /bin/sh

Defaulting container name to database.
Use 'oc describe pod/test-instance1-m7hh-0 -n openshift-operators' to see all of the containers in this pod.
sh-4.4$ psql -U postgres
psql (14.4)
Type "help" for help.

  6. pg_hba.conf 파일을 찾습니다. 

    postgres=# SHOW hba_file;
         hba_file
--------------------------
 /pgdata/pg14/pg_hba.conf
(1 row)

postgres=#
  7. 데이터베이스를 종료합니다.

  8. pg_hba.conf 파일에 모든 0.0.0.0/0 md5 .d5 항목이 있는지 확인합니다. 이 항목은 들어오는 모든 연결에 액세스하는 데 필요합니다. 필요한 경우 pg_hba.conf 파일의 끝에 항목을 추가합니다.

    예: pg_hba.conf 파일

    sh-4.4$ cat /pgdata/pg14/pg_hba.conf

# Do not edit this file manually!
# It will be overwritten by Patroni!
local all "postgres" peer
hostssl replication "_crunchyrepl" all cert
hostssl "postgres" "_crunchyrepl" all cert
host all "_crunchyrepl" all reject
hostssl all all all md5
host  all  all 0.0.0.0/0 md5

  9. pg_hba.conf 파일을 저장하고 데이터베이스를 다시 로드합니다. 

    sh-4.4$ psql -U postgres
psql (14.4)
Type "help" for help.

postgres=# SHOW hba_file;
         hba_file
--------------------------
 /pgdata/pg14/pg_hba.conf
(1 row)

postgres=# SELECT pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)
  10. 데이터베이스를 종료합니다.

  11. 대상 네임스페이스의 tekton-hub-db 라는 보안에 다음 키가 있는지 확인합니다.

    • POSTGRES_HOST
    • POSTGRES_DB
    • POSTGRES_USER
    • POSTGRES_PASSWORD

    • POSTGRES_PORT

      예: 사용자 정의 데이터베이스 보안

      apiVersion: v1
kind: Secret
metadata:
  name: tekton-hub-db
  labels:
    app: tekton-hub-db
type: Opaque
stringData:
  POSTGRES_HOST: test-primary.openshift-operators.svc
  POSTGRES_DB: test
  POSTGRES_USER: test
  POSTGRES_PASSWORD: woXOisU5>ocJiTF7y{{;1[Q(
  POSTGRES_PORT: '5432'
...

      참고

      POSTGRES_HOST 필드의 값은 시크릿으로 인코딩됩니다. 다음 예제를 사용하여 Crunchy Postgres 호스트의 값을 디코딩할 수 있습니다.

      예: Crunchy Postgres 호스트의 시크릿 값 디코딩

      $ echo 'aGlwcG8tcHJpbWFyeS5vcGVuc2hpZnQtb3BlcmF0b3JzLnN2YyA=' | base64 --decode
test-primary.openshift-operators.svc

  12. TektonHub CR에서 데이터베이스 시크릿 속성 값이 tekton-hub-db 인지 확인합니다.

    예: 데이터베이스 시크릿 이름이 있는 TektonHub CR

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace: openshift-pipelines
  db:
    secret: tekton-hub-db
...

  13. 외부 Crunchy Postgres 데이터베이스를 Tekton Hub와 연결하려면 기존 TektonHub CR을 업데이트된 TektonHub CR로 교체합니다. 

    $ oc replace -f <updated-tekton-hub-cr>.yaml

  14. Tekton Hub의 상태를 확인합니다. 업데이트된 TektonHub CR은 정상 상태를 늘리는 데 약간의 시간이 걸릴 수 있습니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                    UIURL
hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

3.7.3. 사용자 정의 카테고리 및 카탈로그를 사용하여 Tekton Hub 업데이트

클러스터 관리자는 조직의 컨텍스트를 반영하는 사용자 정의 카테고리, 카탈로그, 범위 및 기본 범위를 사용하여 Tekton Hub를 업데이트할 수 있습니다.

절차

  1. 선택 사항: Tekton Hub CR에서 카테고리,카탈로그, 범위 및 default:scopes 필드를 편집합니다.

    참고

    카테고리, 카탈로그, 범위 및 기본 범위에 대한 기본 정보는 Tekton Hub API 구성 맵에서 가져옵니다. TektonHub CR에 사용자 지정 값을 제공하는 경우 기본값을 덮어씁니다.

  2. Tekton Hub CR을 적용합니다. 

    $ oc apply -f <tekton-hub-cr>.yaml

  3. Tekton Hub 상태를 관찰합니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                  UIURL
hub    v1.9.0    True             https://api.route.url   https://ui.route.url

3.7.4. Tekton Hub의 카탈로그 새로 고침 간격 수정

Tekton Hub의 기본 카탈로그 새로 고침 간격은 30분입니다. 클러스터 관리자는 TektonHub CR의 catalogRefreshInterval 필드의 값을 수정하여 자동 카탈로그 새로 고침 간격을 수정할 수 있습니다.

절차

  1. TektonHub CR에서 catalogRefreshInterval 필드의 값을 수정합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonHub
metadata:
  name: hub
spec:
  targetNamespace: openshift-pipelines 1
  api:
    catalogRefreshInterval: 30m 2
    1
    Tekton Hub가 설치된 네임스페이스입니다. 기본값은 openshift-pipelines 입니다.
    2
    카탈로그가 자동으로 새로 고침되는 시간 간격입니다. 지원되는 시간 단위는 초(s), 분(m), 시간(h), 일(d), 주(w)입니다. 기본 간격은 30분입니다.

  2. TektonHub CR을 적용합니다. 

    $ oc apply -f <tekton-hub-cr>.yaml

  3. 설치 상태를 확인합니다. TektonHub CR은 안정적인 상태를 유지하는 데 시간이 걸릴 수 있습니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                    UIURL
hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

3.7.5. Tekton Hub 구성에서 새 사용자 추가

클러스터 관리자는 다양한 범위를 사용하여 Tekton Hub에 새 사용자를 추가할 수 있습니다.

절차

  1. TektonHub CR을 수정하여 범위가 다른 새 사용자를 추가합니다. 

    ...
scopes:
  - name: agent:create
    users: [<username_1>, <username_2>] 1
  - name: catalog:refresh
    users: [<username_3>, <username_4>]
  - name: config:refresh
    users: [<username_5>, <username_6>]

default:
  scopes:
    - rating:read
    - rating:write
...
    1
    Git 리포지토리 호스팅 서비스 공급자에 등록된 사용자 이름입니다.
    참고

    Tekton Hub에 처음 로그인하는 새 사용자는 기본 범위만 갖습니다. 추가 범위를 활성화하려면 TektonHub CR의 scopes 필드에 사용자의 사용자 이름이 추가되었는지 확인합니다.

  2. 업데이트된 TektonHub CR을 적용합니다. 

    $ oc apply -f <tekton-hub-cr>.yaml

  3. Tekton Hub의 상태를 확인합니다. 업데이트된 TektonHub CR은 정상 상태를 늘리는 데 약간의 시간이 걸릴 수 있습니다. 

    $ oc get tektonhub.operator.tekton.dev

    샘플 출력

    NAME   VERSION   READY   REASON   APIURL                    UIURL
hub    v1.9.0    True             https://api.route.url/    https://ui.route.url/

  4. 구성을 새로 고칩니다. 

    $ curl -X POST -H "Authorization: <access-token>" \ 1
    --header "Content-Type: application/json" \
    --data '{"force": true} \
    <api-route>/system/config/refresh
    1
    JWT 토큰입니다.

3.7.6. Red Hat OpenShift Pipelines Operator를 1.7에서 1.8로 업그레이드한 후 Tekton Hub 권한 비활성화

Red Hat OpenShift Pipelines Operator 1.8을 사용하여 Tekton Hub를 설치하면 기본 설치에 대해 Tekton Hub 아티팩트에 대한 로그인 권한 부여 및 등급이 비활성화됩니다. 그러나 Operator를 1.7에서 1.8로 업그레이드할 때 클러스터의 Tekton Hub 인스턴스에서 로그인 권한 부여 및 등급이 자동으로 비활성화되지 않습니다.

Operator를 1.7에서 1.8로 업그레이드한 후 Tekton Hub에 대한 로그인 권한 부여 및 등급을 비활성화하려면 다음 절차의 단계를 수행합니다.

사전 요구 사항

  • Red Hat OpenShift Pipelines Operator가 클러스터의 기본 openshift-pipelines 네임스페이스에 설치되어 있는지 확인합니다.

절차

  1. Operator 1.7용 Tekton Hub를 수동으로 설치하는 동안 생성한 기존 Tekton Hub API 시크릿을 삭제합니다. 

    $ oc delete secret tekton-hub-api -n <targetNamespace> 1
    1
    Tekton Hub API 시크릿 및 Tekton Hub CR의 공통 네임스페이스입니다. 기본적으로 대상 네임스페이스는 openshift-pipelines 입니다.

  2. Tekton Hub API의 TektonInstallerSet 오브젝트를 삭제합니다. 

    $ oc get tektoninstallerset -o name | grep tekton-hub-api | xargs oc delete
    참고

    삭제 후 Operator는 새 Tekton Hub API 설치 프로그램이 자동으로 설정됩니다.

    기다린 후 Tekton Hub의 상태를 확인합니다. READY 열에 True 가 표시되면 다음 단계를 진행합니다. 

    $ oc get tektonhub hub

    샘플 출력

    NAME   VERSION        READY   REASON   APIURL                                                                                                  UIURL
hub    1.8.0          True             https://tekton-hub-api-openshift-pipelines.apps.example.com   https://tekton-hub-ui-openshift-pipelines.apps.example.com

  3. Tekton Hub UI의 ConfigMap 오브젝트를 삭제합니다. 

    $ oc delete configmap tekton-hub-ui -n <targetNamespace> 1
    1
    Tekton Hub UI 및 Tekton Hub CR의 공통 네임스페이스입니다. 기본적으로 대상 네임스페이스는 openshift-pipelines 입니다.

  4. Tekton Hub UI의 TektonInstallerSet 오브젝트를 삭제합니다. 

    $ oc get tektoninstallerset -o name | grep tekton-hub-ui | xargs oc delete
    참고

    삭제 후 Operator는 새 Tekton Hub UI 설치 프로그램이 설정된 새 Tekton Hub UI 설치 프로그램을 자동으로 생성합니다.

    기다린 후 Tekton Hub의 상태를 확인합니다. READY 열에 True 가 표시되면 다음 단계를 진행합니다. 

    $ oc get tektonhub hub

    샘플 출력

    NAME   VERSION        READY   REASON   APIURL                                                                                                  UIURL
hub    1.8.0          True             https://tekton-hub-api-openshift-pipelines.apps.example.com   https://tekton-hub-ui-openshift-pipelines.apps.example.com

3.7.7. 추가 리소스

3.8. 해결자를 사용하여 원격 파이프라인 및 작업 지정

파이프라인 및 작업은 CI/CD 프로세스에 재사용 가능한 블록입니다. 이전에 개발했거나 다른 사용자가 개발한 파이프라인 또는 작업을 재사용하여 정의를 복사하여 붙여넣을 필요 없이 재사용할 수 있습니다. 이러한 파이프라인 또는 작업은 클러스터의 다른 네임스페이스에서 공용 카탈로그에 이르기까지 여러 유형의 소스에서 사용할 수 있습니다.

파이프라인 실행 리소스에서 기존 소스의 파이프라인을 지정할 수 있습니다. 파이프라인 리소스 또는 작업 실행 리소스에서 기존 소스의 작업을 지정할 수 있습니다.

이러한 경우 Red Hat OpenShift Pipelines 의 해결자는 런타임 시 지정된 소스에서 파이프라인 또는 작업 정의를 검색합니다.

다음 해결자는 Red Hat OpenShift Pipelines의 기본 설치 프로그램에서 사용할 수 있습니다.

hub resolver
Artifact Hub 또는 Tekton Hub에서 사용할 수 있는 Pipelines Catalog에서 작업 또는 파이프라인을 검색합니다.
bundles resolver
OpenShift 컨테이너 리포지토리와 같은 OCI 리포지토리에서 사용할 수 있는 OCI 이미지인 Tekton 번들에서 작업 또는 파이프라인을 검색합니다.
클러스터 확인자
특정 네임스페이스의 동일한 OpenShift Container Platform 클러스터에서 이미 생성된 작업 또는 파이프라인을 검색합니다.
git resolver
Git 리포지토리에서 작업 또는 파이프라인 바인딩을 검색합니다. 리포지토리, 분기 및 경로를 지정해야 합니다.

3.8.1. Tekton 카탈로그에서 원격 파이프라인 또는 작업 지정

hub resolver를 사용하여 Artifact Hub 의 공용 Tekton 카탈로그 또는 Tekton Hub 인스턴스에 정의된 원격 파이프라인 또는 작업을 지정할 수 있습니다.

중요

Artifact Hub 프로젝트는 Red Hat OpenShift Pipelines에서 지원되지 않습니다. Artifact Hub의 구성만 지원됩니다.

3.8.1.1. hub resolver 구성

hub resolver를 구성하여 리소스 가져오기에 대한 기본 허브와 기본 카탈로그 설정을 변경할 수 있습니다.

프로세스

  1. TektonConfig 사용자 지정 리소스를 편집하려면 다음 명령을 입력합니다. 

    $ oc edit TektonConfig config

  2. TektonConfig 사용자 정의 리소스에서 pipeline.hub-resolver-config 사양을 편집합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    hub-resolver-config:
      default-tekton-hub-catalog: Tekton 1
      default-artifact-hub-task-catalog: tekton-catalog-tasks 2
      default-artifact-hub-pipeline-catalog: tekton-catalog-pipelines 3
      defailt-kind: pipeline 4
      default-type: tekton 5
      tekton-hub-api: "https://my-custom-tekton-hub.example.com" 6
      artifact-hub-api: "https://my-custom-artifact-hub.example.com" 7
    1
    리소스를 가져오는 기본 Tekton Hub 카탈로그입니다.
    2
    작업 리소스를 가져오는 기본 Artifact Hub 카탈로그입니다.
    3
    파이프라인 리소스를 가져오는 기본 Artifact Hub 카탈로그입니다.
    4
    참조의 기본 오브젝트 종류입니다.
    5
    Artifact Hub의 아티팩트 또는 Tekton Hub의 경우 tekton 중 하나로 리소스를 가져오는 기본 허브입니다.
    6
    default-type 옵션이 tekton 로 설정된 경우 사용되는 Tekton Hub API입니다.
    7
    선택 사항: default-type 옵션이 artifact 로 설정된 경우 사용되는 Artifact Hub API입니다.
    중요

    default-type 옵션을 tekton 로 설정하는 경우 tekton -hub-api 값을 설정하여 Tekton Hub의 고유 인스턴스를 구성해야 합니다.

    default-type 옵션을 artifact 로 설정하면 확인자는 기본적으로 https://artifacthub.io/ 에서 공용 허브 API를 사용합니다. artifact-hub-api 값을 설정하여 고유한 Artifact Hub API를 구성할 수 있습니다.

3.8.1.2. hub resolver를 사용하여 원격 파이프라인 또는 작업 지정

파이프라인 실행을 생성할 때 Artifact Hub 또는 Tekton Hub에서 원격 파이프라인을 지정할 수 있습니다. 파이프라인 또는 작업 실행을 생성할 때 Artifact Hub 또는 Tekton Hub에서 원격 작업을 지정할 수 있습니다.

프로세스

  • Artifact Hub 또는 Tekton Hub에서 원격 파이프라인 또는 작업을 지정하려면 pipelineRef 또는 taskRef 사양에 다음 참조 형식을 사용합니다. 

    # ...
  resolver: hub
  params:
  - name: catalog
    value: <catalog>
  - name: type
    value: <catalog_type>
  - name: kind
    value: [pipeline|task]
  - name: name
    value: <resource_name>
  - name: version
    value: <resource_version>
# ...

    표 3.8. hub resolver에 대해 지원되는 매개변수

    매개변수설명예시 값

    catalog

    리소스를 가져올 카탈로그입니다.

    기본값: tekton-catalog-tasks ( 작업 종류용), tekton-catalog- pipeline s (파이너 종류용).

    type

    리소스를 가져오는 카탈로그 유형입니다. Artifact Hub의 아티팩트 또는 Tekton Hub의 tekton 중 하나입니다.

    기본값: artifact

    kind

    작업 또는 파이프라인 중 하나입니다.

    기본값: task

    name

    허브에서 가져올 작업 또는 파이프라인의 이름입니다.

    golang-build

    버전

    허브에서 가져올 작업 또는 파이프라인 버전입니다. 숫자 주위에 따옴표(')를 사용해야 합니다.

    "0.5.0"

    파이프라인 또는 작업에 추가 매개변수가 필요한 경우 이러한 매개변수를 매개변수에 제공합니다.

다음 예제 파이프라인 실행은 카탈로그의 원격 파이프라인을 참조합니다. 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: hub-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: hub
    params:
    - name: catalog
      value: tekton-catalog-pipelines
    - name: type
      value: artifact
    - name: kind
      value: pipeline
    - name: name
      value: example-pipeline
    - name: version
      value: "0.1"
    - name: sample-pipeline-parameter
      value: test

카탈로그의 원격 작업을 참조하는 다음 예제 파이프라인입니다. 

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-cluster-task-reference-demo
spec:
  tasks:
  - name: "cluster-task-reference-demo"
    taskRef:
      resolver: hub
      params:
      - name: catalog
        value: tekton-catalog-tasks
      - name: type
        value: artifact
      - name: kind
        value: task
      - name: name
        value: example-task
      - name: version
        value: "0.6"
      - name: sample-task-parameter
        value: test

카탈로그의 원격 작업을 참조하는 다음 예제 작업 실행 

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: cluster-task-reference-demo
spec:
  taskRef:
    resolver: hub
    params:
    - name: catalog
      value: tekton-catalog-tasks
    - name: type
      value: artifact
    - name: kind
      value: task
    - name: name
      value: example-task
    - name: version
      value: "0.6"
    - name: sample-task-parameter
      value: test

3.8.2. Tekton 번들에서 원격 파이프라인 또는 작업 지정

bundles resolver를 사용하여 Tekton 번들에서 원격 파이프라인 또는 작업을 지정할 수 있습니다. Tekton 번들은 OpenShift 컨테이너 리포지토리와 같은 OCI 리포지토리에서 사용할 수 있는 OCI 이미지입니다.

3.8.2.1. 번들 확인 프로그램 구성

bundles 확인자를 구성하여 Tekton 번들에서 리소스를 가져오는 기본 서비스 계정 이름 및 기본 유형을 변경할 수 있습니다.

프로세스

  1. TektonConfig 사용자 지정 리소스를 편집하려면 다음 명령을 입력합니다. 

    $ oc edit TektonConfig config

  2. TektonConfig 사용자 정의 리소스에서 pipeline.bundles-resolver-config 사양을 편집합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines 1
      default-kind: task 2
    1
    번들 요청에 사용할 기본 서비스 계정 이름입니다.
    2
    번들 이미지의 기본 계층 종류입니다.

3.8.2.2. 번들 확인기를 사용하여 원격 파이프라인 또는 작업 지정

파이프라인 실행을 생성할 때 Tekton 번들에서 원격 파이프라인을 지정할 수 있습니다. 파이프라인 또는 작업 실행을 생성할 때 Tekton 번들에서 원격 작업을 지정할 수 있습니다.

프로세스

  • Tekton 번들에서 원격 파이프라인 또는 작업을 지정하려면 pipelineRef 또는 taskRef 사양에 다음 참조 형식을 사용합니다. 

    # ...
  resolver: bundles
  params:
  - name: bundle
    value: <fully_qualified_image_name>
  - name: name
    value: <resource_name>
  - name: kind
    value: [pipeline|task]
# ...

    표 3.9. bundles resolver에서 지원되는 매개변수

    매개변수설명예시 값

    serviceAccount

    레지스트리 인증 정보를 구성할 때 사용할 서비스 계정의 이름입니다.

    default

    번들

    가져올 이미지를 가리키는 번들 URL입니다.

    gcr.io/tekton-releases/catalog/upstream/golang-build:0.1

    name

    번들에서 가져올 리소스의 이름입니다.

    golang-build

    kind

    번들에서 제거할 리소스의 종류입니다.

    task

    파이프라인 또는 작업에 추가 매개변수가 필요한 경우 이러한 매개변수를 매개변수에 제공합니다.

다음 예제 파이프라인 실행은 Tekton 번들의 원격 파이프라인을 참조합니다. 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: bundle-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: bundles
    params:
    - name: bundle
      value: registry.example.com:5000/simple/pipeline:latest
    - name: name
      value: hello-pipeline
    - name: kind
      value: pipeline
    - name: sample-pipeline-parameter
      value: test
  params:
  - name: username
    value: "pipelines"

다음 예제 파이프라인은 Tekton 번들의 원격 작업을 참조합니다. 

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-bundle-task-reference-demo
spec:
  tasks:
  - name: "bundle-task-demo"
    taskRef:
      resolver: bundles
      params:
      - name: bundle
        value: registry.example.com:5000/advanced/task:latest
      - name: name
        value: hello-world
      - name: kind
        value: task
      - name: sample-task-parameter
        value: test

다음 예제 작업 실행에서는 Tekton 번들의 원격 작업을 참조합니다. 

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: bundle-task-reference-demo
spec:
  taskRef:
    resolver: bundles
    params:
    - name: bundle
      value: registry.example.com:5000/simple/new_task:latest
    - name: name
      value: hello-world
    - name: kind
      value: task
    - name: sample-task-parameter
      value: test

3.8.3. 동일한 클러스터에서 원격 파이프라인 또는 작업 지정

클러스터 확인자를 사용하여 Red Hat OpenShift Pipelines가 실행 중인 OpenShift Container Platform 클러스터의 네임스페이스에 정의된 원격 파이프라인 또는 작업을 지정할 수 있습니다.

3.8.3.1. 클러스터 확인 프로그램 구성

클러스터 확인자의 기본 종류 및 네임스페이스를 변경하거나 클러스터 확인자가 사용할 수 있는 네임스페이스를 제한할 수 있습니다.

프로세스

  1. TektonConfig 사용자 지정 리소스를 편집하려면 다음 명령을 입력합니다. 

    $ oc edit TektonConfig config

  2. TektonConfig 사용자 정의 리소스에서 pipeline.cluster-resolver-config 사양을 편집합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    cluster-resolver-config:
      default-kind: pipeline 1
      default-namespace: namespace1 2
      allowed-namespaces: namespace1, namespace2 3
      blocked-namespaces: namespace3, namespace4 4
    1
    매개변수에 지정되지 않은 경우 가져올 기본 리소스 유형입니다.
    2
    매개변수에 지정되지 않은 경우 리소스를 가져오는 기본 네임스페이스입니다.
    3
    확인자가 액세스할 수 있는 쉼표로 구분된 네임스페이스 목록입니다. 이 키가 정의되지 않은 경우 모든 네임스페이스가 허용됩니다.
    4
    확인자가 액세스할 수 없는 네임스페이스의 선택적 쉼표로 구분된 목록입니다. 이 키가 정의되지 않은 경우 모든 네임스페이스가 허용됩니다.

3.8.3.2. 클러스터 확인자를 사용하여 원격 파이프라인 또는 작업 지정

파이프라인 실행을 생성할 때 동일한 클러스터의 원격 파이프라인을 지정할 수 있습니다. 파이프라인 또는 작업 실행을 생성할 때 동일한 클러스터에서 원격 작업을 지정할 수 있습니다.

프로세스

  • 동일한 클러스터의 원격 파이프라인 또는 작업을 지정하려면 pipelineRef 또는 taskRef 사양에 다음 참조 형식을 사용합니다. 

    # ...
  resolver: cluster
  params:
  - name: name
    value: <name>
  - name: namespace
    value: <namespace>
  - name: kind
    value: [pipeline|task]
# ...

    표 3.10. 클러스터 확인기에서 지원되는 매개변수

    매개변수설명예시 값

    name

    가져올 리소스의 이름입니다.

    some-pipeline

    namespace

    리소스가 포함된 클러스터의 네임스페이스입니다.

    other-namespace

    kind

    가져올 리소스의 종류입니다.

    pipeline

    파이프라인 또는 작업에 추가 매개변수가 필요한 경우 이러한 매개변수를 매개변수에 제공합니다.

다음 예제 파이프라인 실행은 동일한 클러스터의 원격 파이프라인을 참조합니다. 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: cluster-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: cluster
    params:
    - name: name
      value: some-pipeline
    - name: namespace
      value: test-namespace
    - name: kind
      value: pipeline
    - name: sample-pipeline-parameter
      value: test

다음 예제 파이프라인은 동일한 클러스터의 원격 작업을 참조합니다. 

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-cluster-task-reference-demo
spec:
  tasks:
  - name: "cluster-task-reference-demo"
    taskRef:
      resolver: cluster
      params:
      - name: name
        value: some-task
      - name: namespace
        value: test-namespace
      - name: kind
        value: task
      - name: sample-task-parameter
        value: test

다음 예제 작업 실행에서는 동일한 클러스터의 원격 작업을 참조합니다. 

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: cluster-task-reference-demo
spec:
  taskRef:
    resolver: cluster
    params:
    - name: name
      value: some-task
    - name: namespace
      value: test-namespace
    - name: kind
      value: task
    - name: sample-task-parameter
      value: test

3.8.4. Git 리포지토리에서 원격 파이프라인 또는 작업 지정

Git 확인자를 사용하여 Git repostory에서 원격 파이프라인 또는 작업을 지정할 수 있습니다. 리포지토리에는 파이프라인 또는 작업을 정의하는 YAML 파일이 포함되어야 합니다. Git 확인자는 Ansible을 복제하거나 인증된 SCM API를 사용하여 리포지토리에 액세스할 수 있습니다.

3.8.4.1. 익명 Git 복제에 대한 Git 확인자 구성

익명 Git 복제를 사용하려면 Git 리포지토리에서 원격 파이프라인 및 작업을 가져오기 위해 기본 Git 버전, 시간 초과 및 기본 리포지토리 URL을 구성할 수 있습니다.

프로세스

  1. TektonConfig 사용자 지정 리소스를 편집하려면 다음 명령을 입력합니다. 

    $ oc edit TektonConfig config

  2. TektonConfig 사용자 정의 리소스에서 pipeline.git-resolver-config 사양을 편집합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    git-resolver-config:
      default-revision: main 1
      fetch-timeout: 1m 2
      default-url: https://github.com/tektoncd/catalog.git 3
    1
    지정되지 않은 경우 사용할 기본 Git 버전입니다.
    2
    단일 Git 복제 확인에 최대 시간이 걸릴 수 있습니다(예: 1m,2s,700ms ). Red Hat OpenShift Pipelines는 모든 해결 요청에 대해 글로벌 최대 시간 초과를 1분으로 적용합니다.
    3
    없음이 지정되지 않은 경우 익명 복제의 기본 Git 리포지토리 URL입니다.

3.8.4.2. 인증된 SCM API에 대한 Git 확인 프로그램 구성

인증된 SCM API의 경우 인증된 Git 연결에 대한 구성을 설정해야 합니다.

go-scm 라이브러리에서 지원하는 Git 리포지토리 공급자를 사용할 수 있습니다. 모든 go-scm 구현이 Git 리졸버에서 테스트된 것은 아니지만 다음 공급자가 작동하는 것으로 알려져 있습니다.

  • GitHub.com 및 GitHub Enterprise
  • GitLab.com 및 자체 호스팅 Gitlab
  • Gitea
  • BitBucket Server
  • Bitbucket 클라우드
참고
  • 클러스터에 대해 인증된 SCM API를 사용하여 하나의 Git 연결만 구성할 수 있습니다. 이 연결은 클러스터의 모든 사용자가 사용할 수 있게 됩니다. 클러스터의 모든 사용자는 연결에 대해 구성하는 보안 토큰을 사용하여 리포지토리에 액세스할 수 있습니다.
  • 인증된 SCM API를 사용하도록 Git 확인자를 구성하는 경우 익명 Git 복제 참조를 사용하여 파이프라인 및 작업을 검색할 수도 있습니다.

프로세스

  1. TektonConfig 사용자 지정 리소스를 편집하려면 다음 명령을 입력합니다. 

    $ oc edit TektonConfig config

  2. TektonConfig 사용자 정의 리소스에서 pipeline.git-resolver-config 사양을 편집합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    git-resolver-config:
      default-revision: main 1
      fetch-timeout: 1m 2
      scm-type: github 3
      server-url: api.internal-github.com 4
      api-token-secret-name: github-auth-secret 5
      api-token-secret-key: github-auth-key 6
      api-token-secret-namespace: github-auth-namespace 7
      default-org: tektoncd 8
    1
    지정되지 않은 경우 사용할 기본 Git 버전입니다.
    2
    단일 Git 복제 확인에 최대 시간이 걸릴 수 있습니다(예: 1m,2s,700ms ). Red Hat OpenShift Pipelines는 모든 해결 요청에 대해 글로벌 최대 시간 초과를 1분으로 적용합니다.
    3
    SCM 공급자 유형입니다.
    4
    인증된 SCM API와 함께 사용할 기본 URL입니다. github.com,gitlab.com 또는 BitBucket Cloud를 사용하는 경우에는 이 설정이 필요하지 않습니다.
    5
    SCM 공급자 API 토큰이 포함된 시크릿의 이름입니다.
    6
    토큰이 포함된 토큰 시크릿 내의 키입니다.
    7
    토큰 시크릿이 포함된 네임스페이스가 기본값이 아닌 경우입니다.
    8
    선택 사항: 인증된 API를 사용하는 경우 리포지토리의 기본 조직입니다. 이 조직은 확인자 매개변수에 조직을 지정하지 않는 경우 사용됩니다.
참고

인증된 SCM API를 사용하려면 scm-type,api-token-secret-name, api-token-secret-key 설정이 필요합니다.

3.8.4.3. Git 확인자를 사용하여 원격 파이프라인 또는 작업 지정

파이프라인 실행을 생성할 때 Git 리포지토리에서 원격 파이프라인을 지정할 수 있습니다. 파이프라인 또는 작업 실행을 생성할 때 Git 리포지토리에서 원격 작업을 지정할 수 있습니다.

사전 요구 사항

  • 인증된 SCM API를 사용하려면 Git 확인자에 대해 인증된 Git 연결을 구성해야 합니다.

프로세스

  1. Git 리포지토리에서 원격 파이프라인 또는 작업을 지정하려면 pipelineRef 또는 taskRef 사양에 다음 참조 형식을 사용합니다. 

    # ...
  resolver: git
  params:
  - name: url
    value: <git_repository_url>
  - name: revision
    value: <branch_name>
  - name: pathInRepo
    value: <path_in_repository>
# ...

    표 3.11. Git 확인자에 지원되는 매개변수

    매개변수설명예시 값

    url

    익명 복제를 사용하는 경우 리포지토리의 URL입니다.

    https://github.com/tektoncd/catalog.git

    리포지토리

    인증된 SCM API를 사용하는 경우 리포지토리 이름입니다.

    test-infra

    조직

    인증된 SCM API를 사용하는 경우 리포지토리의 조직입니다.

    tektoncd

    버전

    리포지토리의 Git 버전입니다. 분기 이름, 태그 이름 또는 커밋 SHA 해시를 지정할 수 있습니다.

    aeb957601cf41c012be462827053a21a420befca
    main
    v0.38.2

    pathInRepo

    리포지토리에 있는 YAML 파일의 경로 이름입니다.

    task/golang-build/0.3/golang-build.yaml

    참고

    리포지토리를 복제 및 가져오려면 url 매개변수를 사용합니다. 인증된 SCM API를 사용하려면 repo 매개변수를 사용합니다. url 매개변수와 repo 매개변수를 함께 지정하지 마십시오.

    파이프라인 또는 작업에 추가 매개변수가 필요한 경우 이러한 매개변수를 매개변수에 제공합니다.

다음 예제 파이프라인 실행은 Git 리포지토리의 원격 파이프라인을 참조합니다. 

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: git-pipeline-reference-demo
spec:
  pipelineRef:
    resolver: git
    params:
    - name: url
      value: https://github.com/tektoncd/catalog.git
    - name: revision
      value: main
    - name: pathInRepo
      value: pipeline/simple/0.1/simple.yaml
    - name: sample-pipeline-parameter
      value: test
  params:
  - name: name
    value: "testPipelineRun"

다음 예제 파이프라인은 Git 리포지토리의 원격 작업을 참조합니다. 

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: pipeline-with-git-task-reference-demo
spec:
  tasks:
  - name: "git-task-reference-demo"
    taskRef:
      resolver: git
      params:
      - name: url
        value: https://github.com/tektoncd/catalog.git
      - name: revision
        value: main
      - name: pathInRepo
        value: task/git-clone/0.6/git-clone.yaml
      - name: sample-task-parameter
        value: test

다음 예제 작업 실행에서는 Git 리포지토리의 원격 작업을 참조합니다. 

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: git-task-reference-demo
spec:
  taskRef:
    resolver: git
    params:
    - name: url
      value: https://github.com/tektoncd/catalog.git
    - name: revision
      value: main
    - name: pathInRepo
      value: task/git-clone/0.6/git-clone.yaml
    - name: sample-task-parameter
      value: test

3.8.5. 추가 리소스

3.9. Pipeline을 코드로 사용

Pipeline을 Code로 사용하면 클러스터 관리자와 필요한 권한이 있는 사용자는 파이프라인 템플릿을 소스 코드 Git 리포지토리의 일부로 정의할 수 있습니다. 소스 코드 푸시 또는 구성된 Git 리포지토리에 대한 가져오기 요청에 의해 트리거되는 경우 Code로 Pipeline이 파이프라인을 실행하고 상태를 보고합니다.

3.9.1. 주요 기능

코드로서의 파이프라인은 다음과 같은 기능을 지원합니다.

  • Git 리포지토리를 호스팅하는 플랫폼에서 요청 상태를 가져오고 제어합니다.
  • GitHub Checks API to set the status of a pipeline run, including rechecks.
  • GitHub pull request 및 commit events
  • /retest 와 같은 주석으로 요청 작업을 가져옵니다.
  • Git 이벤트 필터링 및 각 이벤트에 대한 별도의 파이프라인.
  • 로컬 작업, Tekton Hub 및 원격 URL을 포함하여 OpenShift Pipelines의 자동 작업 확인
  • GitHub Blob 및 오브젝트 API를 사용하여 구성 검색
  • GitHub 조직을 통한 액세스 제어 목록(ACL) 또는 Prow 스타일 OWNER 파일을 사용합니다.
  • 부트스트랩 및 Pipeline을 코드 리포지토리로 관리하기 위한 tkn pac CLI 플러그인.
  • GitHub App, GitHub Webhook, Bitbucket Server 및 Bitbucket Cloud 지원

3.9.2. OpenShift Container Platform에서 Pipeline을 코드로 설치

Red Hat OpenShift Pipelines Operator를 설치할 때 openshift-pipelines 네임스페이스에 Code로 Pipeline이 설치됩니다. 자세한 내용은 추가 리소스 섹션에 OpenShift Pipelines 설치 섹션을 참조하십시오.

Operator를 사용하여 Code로 Pipeline의 기본 설치를 비활성화하려면 TektonConfig 사용자 정의 리소스에서 enable 매개변수의 값을 false 로 설정합니다. 

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  platforms:
    openshift:
      pipelinesAsCode:
        enable: false
        settings:
          application-name: Pipelines as Code CI
          auto-configure-new-github-repo: "false"
          bitbucket-cloud-check-source-ip: "true"
          hub-catalog-name: tekton
          hub-url: https://api.hub.tekton.dev/v1
          remote-tasks: "true"
          secret-auto-create: "true"
# ...

선택적으로 다음 명령을 실행할 수 있습니다. 

$ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": false}}}}}'

Red Hat OpenShift Pipelines Operator를 사용하여 Code로 Pipeline의 기본 설치를 활성화하려면 TektonConfig 사용자 정의 리소스에서 enable 매개변수 값을 true 로 설정합니다. 

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  platforms:
    openshift:
      pipelinesAsCode:
        enable: true
        settings:
          application-name: Pipelines as Code CI
          auto-configure-new-github-repo: "false"
          bitbucket-cloud-check-source-ip: "true"
          hub-catalog-name: tekton
          hub-url: https://api.hub.tekton.dev/v1
          remote-tasks: "true"
          secret-auto-create: "true"
# ...

선택적으로 다음 명령을 실행할 수 있습니다. 

$ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": true}}}}}'

3.9.3. Pipeline을 코드 CLI로 설치

클러스터 관리자는 로컬 머신의 tkn pac 및 opc CLI 툴을 사용하거나 테스트를 위한 컨테이너로 사용할 수 있습니다. Red Hat OpenShift Pipelines용 tkn CLI를 설치할 때 tkn pac 및 opc CLI 도구가 자동으로 설치됩니다.

지원되는 플랫폼에 대해 tkn pac 및 opc 버전 1.11.0 바이너리를 설치할 수 있습니다.

3.9.4. Git 리포지토리 호스팅 서비스 공급자와 함께 파이프라인을 코드로 사용

Pipeline을 Code로 설치한 후 클러스터 관리자는 서비스 공급자를 호스팅하는 Git 리포지토리를 구성할 수 있습니다. 현재 다음 서비스가 지원됩니다.

  • GitHub App
  • GitHub Webhook
  • GitLab
  • Bitbucket 서버
  • Bitbucket Cloud
참고

GitHub App은 파이프라인과 함께 코드로 사용하는 데 권장되는 서비스입니다.

3.9.5. GitHub App에서 파이프라인을 코드로 사용

GitHub Apps는 Red Hat OpenShift Pipelines와의 통합 지점 역할을 하며 Git 기반 워크플로를 OpenShift Pipelines에 제공합니다. 클러스터 관리자는 모든 클러스터 사용자를 위해 단일 GitHub 앱을 구성할 수 있습니다. GitHub Apps가 코드로 Pipeline을 사용하려면 GitHub 앱의 Webhook가 GitHub 이벤트를 수신하는 Code 이벤트 리스너 경로(또는 ingress endpoint)로 Pipeline을 가리키는지 확인합니다.

참고

Git에서 가져오기를 사용하여 애플리케이션을 가져오고 Git 리포지토리에 .tekton 디렉터리가 있는 경우 애플리케이션에 대한 pipelines-as-code 를 구성할 수 있습니다.

3.9.5.1. GitHub 앱 구성

클러스터 관리자는 다음 명령을 실행하여 GitHub 앱을 만들 수 있습니다. 

$ tkn pac bootstrap github-app

tkn pac CLI 플러그인이 설치되지 않은 경우 GitHub 앱을 수동으로 생성할 수 있습니다.

절차

Pipeline에 대한 GitHub 앱을 수동으로 생성 및 구성하려면 다음 단계를 수행합니다.

  1. GitHub 계정에 로그인합니다.
  2. Settings → Developer settings → GitHub Apps 로 이동하여 새 GitHub 앱을 클릭합니다.

  3. GitHub 앱 양식에 다음 정보를 입력합니다.

    • GitHub 애플리케이션 이름:OpenShift Pipelines
    • 홈페이지 URL: OpenShift 콘솔 URL

    • Webhook URL: 파이프라인을 코드 경로 또는 수신 URL로 지정합니다. 다음 명령을 실행하여 찾을 수 있습니다. 

      $ echo https://$(oc get route -n openshift-pipelines pipelines-as-code-controller -o jsonpath='{.spec.host}')

    • Webhook 보안: 임의의 시크릿입니다. 다음 명령을 실행하여 보안을 생성할 수 있습니다. 

      $ openssl rand -hex 20

  4. 다음 Repository 권한을 선택합니다.

    • Checking:읽기 & 쓰기
    • 내용:읽기 및 쓰기
    • 문제:읽기 및 쓰기
    • metadata:읽기 전용
    • Pull request:읽기 & 쓰기

  5. 다음 조직 권한을 선택합니다.

    • 멤버:읽기 전용
    • 계획:읽기 전용

  6. 다음 사용자 권한을 선택합니다.

    • Check run
    • 문제 댓글
    • 가져오기 요청
    • push
  7. GitHub 앱 만들기를 클릭합니다.
  8. 새로 생성된 GitHub 앱의 세부 정보 페이지에서 상단에 표시된 앱 ID 를 기록해 둡니다.
  9. 개인 키 섹션에서 개인 키 생성 을 클릭하여 GitHub 앱의 개인 키를 자동으로 생성하고 다운로드합니다. 향후 참조 및 사용을 위해 개인 키를 안전하게 저장합니다.
  10. Pipeline과 함께 사용할 리포지토리에 생성된 앱을 코드로 설치합니다.

3.9.5.2. GitHub 앱에 액세스하기 위한 코드로 Pipeline 구성

새로 생성된 GitHub 앱에 액세스하도록 Pipeline을 코드로 구성하려면 다음 명령을 실행합니다. 

$ oc -n openshift-pipelines create secret generic pipelines-as-code-secret \
        --from-literal github-private-key="$(cat <PATH_PRIVATE_KEY>)" \ 1
        --from-literal github-application-id="<APP_ID>" \ 2
        --from-literal webhook.secret="<WEBHOOK_SECRET>" 3
1
GitHub 앱을 구성하는 동안 다운로드한 개인 키의 경로입니다.
2
GitHub 앱의 앱 ID 입니다.
3
GitHub 앱을 생성할 때 제공되는 Webhook 시크릿입니다.
참고

Pipeline as Code는 GitHub Enterprise에서 설정된 헤더를 감지하고 GitHub Enterprise API 권한 부여 URL에 이를 사용하여 GitHub Enterprise에서 자동으로 작동합니다.

3.9.5.3. 관리자 화면에서 GitHub 앱 생성

클러스터 관리자는 Pipeline을 코드로 사용하도록 OpenShift Container Platform 클러스터를 사용하여 GitHub 앱을 구성할 수 있습니다. 이 구성을 사용하면 빌드 배포에 필요한 작업 세트를 실행할 수 있습니다.

사전 요구 사항

Operator Hub에서 Red Hat OpenShift Pipelines pipelines-1.11 Operator를 설치했습니다.

절차

  1. 관리자 화면에서 탐색 창을 사용하여 Pipelines 로 이동합니다.
  2. 파이프라인 페이지에서 GitHub 앱 설정을 클릭합니다.
  3. GitHub 앱 이름을 입력합니다. 예를 들어 pipelines-ci-clustername-testui.
  4. 설정 을 클릭합니다.
  5. 브라우저에 메시지가 표시되면 Git 암호를 입력합니다.
  6. Create GitHub App for <username>, 여기서 < username >은 GitHub 사용자 이름입니다.

검증

GitHub 앱을 성공적으로 생성하면 OpenShift Container Platform 웹 콘솔이 열리고 애플리케이션에 대한 세부 정보가 표시됩니다.

GitHub 앱 세부 정보

GitHub 앱의 세부 정보는 openShift-pipelines 네임스페이스에 시크릿으로 저장됩니다.

GitHub 애플리케이션과 관련된 이름, 링크 및 시크릿과 같은 세부 정보를 보려면 Pipelines 로 이동하여 GitHub 앱 보기를 클릭합니다.

3.9.5.4. GitHub 토큰을 추가 리포지토리로 범위 지정

코드로서의 파이프라인은 GitHub 앱을 사용하여 GitHub 액세스 토큰을 생성합니다. 코드로서의 파이프라인은 이 토큰을 사용하여 리포지토리에서 파이프라인 페이로드를 검색하고 CI/CD 프로세스가 GitHub 리포지토리와 상호 작용할 수 있도록 합니다.

기본적으로 액세스 토큰은 Pipeline이 파이프라인 정의를 검색하는 리포지토리에만 범위가 지정됩니다. 경우에 따라 토큰이 추가 리포지토리에 액세스할 수 있도록 할 수 있습니다. 예를 들어 .tekton/pr.yaml 파일 및 소스 페이로드가 있는 CI 리포지토리가 있을 수 있지만 pr.yaml 에 정의된 빌드 프로세스는 별도의 개인 CD 리포지토리에서 작업을 가져옵니다.

다음 두 가지 방법으로 GitHub 토큰의 범위를 확장할 수 있습니다.

  • 글로벌 구성: GitHub 토큰을 다른 네임스페이스의 리포지토리 목록으로 확장할 수 있습니다. 이 구성을 설정하려면 관리 권한이 있어야 합니다.
  • 리포지토리 수준 구성: GitHub 토큰을 원래 리포지토리와 동일한 네임스페이스에 있는 리포지토리 목록으로 확장할 수 있습니다. 이 구성을 설정하는 데 관리자 권한이 필요하지 않습니다.

절차

  1. TektonConfig CR(사용자 정의 리소스)에서 pipelinesAsCode.settings 사양의 secret-github-app-token-scoped 매개변수를 false 로 설정합니다. 이 설정을 사용하면 GitHub 토큰의 범위를 글로벌 및 리포지토리 수준 구성에 나열된 프라이빗 및 공용 리포지토리로 지정할 수 있습니다.

  2. GitHub 토큰 범위를 지정하는 글로벌 구성을 설정하려면 pipelinesAsCode.settings 사양의 TektonConfig CR에서 다음 예와 같이 secret-github-app-scope-extra-repos 매개변수에 추가 리포지토리를 지정합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  platforms:
    openshift:
      pipelinesAsCode:
        enable: true
        settings:
          secret-github-app-token-scoped: false
          secret-github-app-scope-extra-repos: "owner2/project2, owner3/project3"

  3. GitHub 토큰 범위를 지정하는 리포지토리 수준 구성을 설정하려면 다음 예와 같이 Repository CR의 github_app_token_scope_repos 매개변수에 추가 리포지토리를 지정합니다. 

    apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: test
  namespace: test-repo
spec:
  url: "https://github.com/linda/project"
  settings:
    github_app_token_scope_repos:
    - "owner/project"
    - "owner1/project1"

    이 예제에서 Repository 사용자 지정 리소스는 test-repo 네임스페이스의 linda/project 리포지토리와 연결됩니다. 생성된 GitHub 토큰의 범위는 owner/project 및 owner1/project1 리포지토리와 linda/project 리포지토리로 확장됩니다. 이러한 리포지토리는 test-repo 네임스페이스에 있어야 합니다.

    참고

    추가 리포지토리는 공용 또는 개인 리포지토리일 수 있지만 리포지토리 리소스가 연결된 리포지토리와 동일한 네임스페이스에 있어야 합니다.

    네임스페이스에 리포지토리가 없는 경우 GitHub 토큰의 범위가 오류 메시지와 함께 실패합니다. 

    failed to scope GitHub token as repo owner1/project1 does not exist in namespace test-repo

결과

생성된 GitHub 토큰을 사용하면 글로벌 및 리포지토리 수준 구성에 구성한 추가 리포지토리와 Pipeline as Code 페이로드 파일이 있는 원본 리포지토리에 액세스할 수 있습니다.

글로벌 구성 및 리포지토리 수준 구성을 모두 제공하는 경우 다음 예와 같이 두 구성의 모든 리포지토리에 범위가 지정됩니다.

TektonConfig 사용자 정의 리소스

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  platforms:
    openshift:
      pipelinesAsCode:
        enable: true
        settings:
          secret-github-app-token-scoped: false
          secret-github-app-scope-extra-repos: "owner2/project2, owner3/project3"

리포지토리 사용자 정의 리소스

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
 name: test
 namespace: test-repo
spec:
 url: "https://github.com/linda/project"
 settings:
   github_app_token_scope_repos:
   - "owner/project"
   - "owner1/project1"

GitHub 토큰의 범위는 owner/project,owner1/project1,owner2/project2,owner3/project3 및 linda/project respositories로 지정됩니다.

3.9.6. GitHub Webhook에서 코드로 Pipeline 사용

GitHub 앱을 만들 수 없는 경우 리포지토리에서 GitHub Webhook를 사용하여 파이프라인을 코드로 사용합니다. 그러나 GitHub Webhook에서 Code로 Pipeline을 사용하면 GitHub Check Runs API에 액세스할 수 없습니다. 작업의 상태는 가져오기 요청에 대한 주석으로 추가되며 확인 탭에서 사용할 수 없습니다.

참고

GitHub Webhook를 사용한 Code인 파이프라인은 /retest 및 /ok-to-test 와 같은 GitOps 주석을 지원하지 않습니다. 연속 통합(CI)을 다시 시작하려면 리포지토리에 대한 새 커밋을 생성합니다. 예를 들어 변경 없이 새 커밋을 생성하려면 다음 명령을 사용할 수 있습니다. 

$ git --amend -a --no-edit && git push --force-with-lease <origin> <branchname>

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.

  • 인증을 위해 GitHub에서 개인 액세스 토큰을 생성합니다.

    • 안전하고 세분화된 토큰을 생성하려면 범위를 특정 리포지토리로 제한하고 다음 권한을 부여합니다.

      표 3.12. 세분화된 토큰에 대한 권한

      이름액세스

      관리

      읽기 전용

      메타데이터

      읽기 전용

      콘텐츠

      읽기 전용

      커밋 상태

      읽기 및 쓰기

      pull request

      읽기 및 쓰기

      Webhook

      읽기 및 쓰기

    • 클래식 토큰을 사용하려면 범위를 공개 리포지토리의 public_ repo 및 프라이빗 리포지토리에 대한 리포지토리로 설정합니다. 또한 짧은 토큰 만료 기간을 제공하고 토큰을 대체 위치에 기록하십시오.

      참고

      tkn pac CLI를 사용하여 Webhook를 구성하려면 admin:repo_hook 범위를 추가합니다.

프로세스

  1. Webhook를 구성하고 Repository CR(사용자 정의 리소스)을 생성합니다.

    • tkn pac CLI 툴을 사용하여 Webhook를 구성하고 Repository CR을 자동으로 생성하려면 다음 명령을 사용합니다. 

      $ tkn pac create repo

      대화형 출력 샘플

      ? Enter the Git repository url (default: https://github.com/owner/repo):
? Please enter the namespace where the pipeline should run (default: repo-pipelines):
! Namespace repo-pipelines is not found
? Would you like me to create the namespace repo-pipelines? Yes
✓ Repository owner-repo has been created in repo-pipelines namespace
✓ Setting up GitHub Webhook for Repository https://github.com/owner/repo
👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
? Do you want me to use it? Yes
? Please enter the secret to configure the webhook for payload validation (default: sJNwdmTifHTs):  sJNwdmTifHTs
ℹ ️You now need to create a GitHub personal access token, please checkout the docs at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token for the required scopes
? Please enter the GitHub access token:  ****************************************
✓ Webhook has been created on repository owner/repo
🔑 Webhook Secret owner-repo has been created in the repo-pipelines namespace.
🔑 Repository CR owner-repo has been updated with webhook secret in the repo-pipelines namespace
ℹ Directory .tekton has been created.
✓ We have detected your repository using the programming language Go.
✓ A basic template has been created in /home/Go/src/github.com/owner/repo/.tekton/pipelinerun.yaml, feel free to customize it.

    • 웹 후크를 구성하고 수동으로 Repository CR을 생성하려면 다음 단계를 수행합니다.

      1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다. 

        $ echo https://$(oc get route -n openshift-pipelines pipelines-as-code-controller -o jsonpath='{.spec.host}')

      2. GitHub 리포지토리 또는 조직에서 다음 단계를 수행합니다.

        1. Settings > Webhooks 로 이동하여 Webhook 추가 를 클릭합니다.
        2. Payload URL 을 코드 컨트롤러 공용 URL로 Pipeline에 설정합니다.
        3. 콘텐츠 유형을 application/json 으로 선택합니다.

        4. 웹 후크 시크릿을 추가하고 대체 위치에 기록해 둡니다. openssl 이 로컬 시스템에 설치되어 있으면 임의의 시크릿을 생성합니다. 

          $ openssl rand -hex 20
        5. Let me select individual events and select these events: Commit 댓글,Issue comments ,Pull request, Pushes 를 선택합니다.
        6. Webhook 추가를 클릭합니다.

      3. OpenShift 클러스터에서 개인 액세스 토큰 및 웹 후크 시크릿을 사용하여 Secret 오브젝트를 생성합니다. 

        $ oc -n target-namespace create secret generic github-webhook-config \
  --from-literal provider.token="<GITHUB_PERSONAL_ACCESS_TOKEN>" \
  --from-literal webhook.secret="<WEBHOOK_SECRET>"

      4. 리포지토리 CR을 생성합니다.

        예: 리포지토리 CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
  url: "https://github.com/owner/repo"
  git_provider:
    secret:
      name: "github-webhook-config"
      key: "provider.token" # Set this if you have a different key in your secret
    webhook_secret:
      name: "github-webhook-config"
      key: "webhook.secret" # Set this if you have a different key for your secret

        참고

        Code로 파이프라인은 OpenShift Secret 오브젝트 및 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.

  2. 선택 사항: 기존 리포지토리 CR의 경우 여러 GitHub Webhook 보안을 추가하거나 삭제된 보안을 대신 제공합니다.

    1. tkn pac CLI 툴을 사용하여 Webhook를 추가합니다.

      예: tkn pac CLI를 사용한 추가 Webhook

      $ tkn pac webhook add -n repo-pipelines

      대화형 출력 샘플

      ✓ Setting up GitHub Webhook for Repository https://github.com/owner/repo
👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
? Do you want me to use it? Yes
? Please enter the secret to configure the webhook for payload validation (default: AeHdHTJVfAeH):  AeHdHTJVfAeH
✓ Webhook has been created on repository owner/repo
🔑 Secret owner-repo has been updated with webhook secert in the repo-pipelines namespace.

    2. 기존 OpenShift Secret 오브젝트에서 webhook.secret 키를 업데이트합니다.

  3. 선택 사항: 기존 리포지토리 CR의 경우 개인 액세스 토큰을 업데이트합니다.

    • tkn pac CLI 툴을 사용하여 개인 액세스 토큰을 업데이트합니다.

      예: tkn pac CLI를 사용하여 개인 액세스 토큰 업데이트

      $ tkn pac webhook update-token -n repo-pipelines

      대화형 출력 샘플

      ? Please enter your personal access token:  ****************************************
🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

    • 또는 Repository CR을 수정하여 개인 액세스 토큰을 업데이트합니다.

      1. 리포지토리 CR에서 시크릿 이름을 찾습니다. 

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
# ...
  git_provider:
    secret:
      name: "github-webhook-config"
# ...

      2. oc patch 명령을 사용하여 $target_namespace 네임스페이스에서 $NEW_TOKEN 값을 업데이트합니다. 

        $ oc -n $target_namespace patch secret github-webhook-config -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

추가 리소스

3.9.7. GitLab에서 코드로 파이프라인 사용

조직 또는 프로젝트에서 GitLab을 기본 플랫폼으로 사용하는 경우 GitLab에서 Webhook와 함께 파이프라인을 리포지토리의 코드로 사용할 수 있습니다.

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.

  • 인증을 위해 GitLab의 프로젝트 또는 조직 관리자로 개인 액세스 토큰을 생성합니다.

    참고
    • tkn pac CLI를 사용하여 Webhook를 구성하려면 admin:repo_hook 범위를 토큰에 추가합니다.
    • 특정 프로젝트에 대해 토큰 범위를 사용하면 분기된 리포지토리에서 전송된MR(분산 요청)에 API 액세스 권한을 제공할 수 없습니다. 이러한 경우 Code로 파이프라인은 MR에 대한 주석으로 파이프라인의 결과를 표시합니다.

프로세스

  1. Webhook를 구성하고 Repository CR(사용자 정의 리소스)을 생성합니다.

    • tkn pac CLI 툴을 사용하여 Webhook를 구성하고 Repository CR을 자동으로 생성하려면 다음 명령을 사용합니다. 

      $ tkn pac create repo

      대화형 출력 샘플

      ? Enter the Git repository url (default: https://gitlab.com/owner/repo):
? Please enter the namespace where the pipeline should run (default: repo-pipelines):
! Namespace repo-pipelines is not found
? Would you like me to create the namespace repo-pipelines? Yes
✓ Repository repositories-project has been created in repo-pipelines namespace
✓ Setting up GitLab Webhook for Repository https://gitlab.com/owner/repo
? Please enter the project ID for the repository you want to be configured,
  project ID refers to an unique ID (e.g. 34405323) shown at the top of your GitLab project : 17103
👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
? Do you want me to use it? Yes
? Please enter the secret to configure the webhook for payload validation (default: lFjHIEcaGFlF):  lFjHIEcaGFlF
ℹ ️You now need to create a GitLab personal access token with `api` scope
ℹ ️Go to this URL to generate one https://gitlab.com/-/profile/personal_access_tokens, see https://is.gd/rOEo9B for documentation
? Please enter the GitLab access token:  **************************
? Please enter your GitLab API URL::  https://gitlab.com
✓ Webhook has been created on your repository
🔑 Webhook Secret repositories-project has been created in the repo-pipelines namespace.
🔑 Repository CR repositories-project has been updated with webhook secret in the repo-pipelines namespace
ℹ Directory .tekton has been created.
✓ A basic template has been created in /home/Go/src/gitlab.com/repositories/project/.tekton/pipelinerun.yaml, feel free to customize it.

    • 웹 후크를 구성하고 수동으로 Repository CR을 생성하려면 다음 단계를 수행합니다.

      1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다. 

        $ echo https://$(oc get route -n openshift-pipelines pipelines-as-code-controller -o jsonpath='{.spec.host}')

      2. GitLab 프로젝트에서 다음 단계를 수행합니다.

        1. 왼쪽 사이드바를 사용하여 Settings > Webhooks 로 이동합니다.
        2. URL 을 코드 컨트롤러 공용 URL로 파이프라인에 설정합니다.

        3. 웹 후크 시크릿을 추가하고 대체 위치에 기록해 둡니다. openssl 이 로컬 시스템에 설치되어 있으면 임의의 시크릿을 생성합니다. 

          $ openssl rand -hex 20
        4. Let me select individual events and select these events: Commit 댓글,Issue comments ,Pull request, Pushes 를 선택합니다.
        5. 변경 사항 저장을 클릭합니다.

      3. OpenShift 클러스터에서 개인 액세스 토큰 및 웹 후크 시크릿을 사용하여 Secret 오브젝트를 생성합니다. 

        $ oc -n target-namespace create secret generic gitlab-webhook-config \
  --from-literal provider.token="<GITLAB_PERSONAL_ACCESS_TOKEN>" \
  --from-literal webhook.secret="<WEBHOOK_SECRET>"

      4. 리포지토리 CR을 생성합니다.

        예: 리포지토리 CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
  url: "https://gitlab.com/owner/repo" 1
  git_provider:
    secret:
      name: "gitlab-webhook-config"
      key: "provider.token" # Set this if you have a different key in your secret
    webhook_secret:
      name: "gitlab-webhook-config"
      key: "webhook.secret" # Set this if you have a different key for your secret

        1
        현재 코드로는 GitLab에 대한 개인 인스턴스를 자동으로 탐지하지 않습니다. 이 경우 git_provider.url 사양 아래에 API URL을 지정합니다. 일반적으로 git_provider.url 사양을 사용하여 API URL을 수동으로 덮어쓸 수 있습니다.
    참고
    • Code로 파이프라인은 OpenShift Secret 오브젝트 및 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.

  2. 선택 사항: 기존 리포지토리 CR의 경우 여러 GitLab Webhook 보안을 추가하거나 삭제된 보안을 대신 제공합니다.

    1. tkn pac CLI 툴을 사용하여 Webhook를 추가합니다.

      예: tkn pac CLI를 사용하여 추가 Webhook 추가

      $ tkn pac webhook add -n repo-pipelines

      대화형 출력 샘플

      ✓ Setting up GitLab Webhook for Repository https://gitlab.com/owner/repo
👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
? Do you want me to use it? Yes
? Please enter the secret to configure the webhook for payload validation (default: AeHdHTJVfAeH):  AeHdHTJVfAeH
✓ Webhook has been created on repository owner/repo
🔑 Secret owner-repo has been updated with webhook secert in the repo-pipelines namespace.

    2. 기존 OpenShift Secret 오브젝트에서 webhook.secret 키를 업데이트합니다.

  3. 선택 사항: 기존 리포지토리 CR의 경우 개인 액세스 토큰을 업데이트합니다.

    • tkn pac CLI 툴을 사용하여 개인 액세스 토큰을 업데이트합니다.

      예: tkn pac CLI를 사용하여 개인 액세스 토큰 업데이트

      $ tkn pac webhook update-token -n repo-pipelines

      대화형 출력 샘플

      ? Please enter your personal access token:  ****************************************
🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

    • 또는 Repository CR을 수정하여 개인 액세스 토큰을 업데이트합니다.

      1. 리포지토리 CR에서 시크릿 이름을 찾습니다. 

        ...
spec:
  git_provider:
    secret:
      name: "gitlab-webhook-config"
...

      2. oc patch 명령을 사용하여 $target_namespace 네임스페이스에서 $NEW_TOKEN 값을 업데이트합니다. 

        $ oc -n $target_namespace patch secret gitlab-webhook-config -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

추가 리소스

3.9.8. Bitbucket Cloud에서 코드로 Pipeline 사용

조직 또는 프로젝트에서 Bitbucket Cloud를 기본 플랫폼으로 사용하는 경우 Bitbucket Cloud에서 Webhook와 함께 리포지토리에 대한 코드로 Pipeline을 사용할 수 있습니다.

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.

  • Bitbucket Cloud에서 앱 암호를 만듭니다.

    • 다음 확인란을 선택하여 토큰에 적절한 권한을 추가합니다.

      • 계정: 이메일,읽기
      • 작업 공간 멤버십: 읽기,쓰기
      • 프로젝트: 읽기,쓰기
      • 문제: 읽기,쓰기

      • pull requests: Read,Write

        참고
        • tkn pac CLI를 사용하여 Webhook를 구성하려면 토큰에 Webhooks:Read 및 Write 권한을 추가합니다.
        • 생성된 암호 또는 토큰 사본을 대체 위치에 저장합니다.

프로세스

  1. Webhook를 구성하고 Repository CR을 생성합니다.

    • tkn pac CLI 툴을 사용하여 Webhook를 구성하고 Repository CR을 자동으로 생성하려면 다음 명령을 사용합니다. 

      $ tkn pac create repo

      대화형 출력 샘플

      ? Enter the Git repository url (default: https://bitbucket.org/workspace/repo):
? Please enter the namespace where the pipeline should run (default: repo-pipelines):
! Namespace repo-pipelines is not found
? Would you like me to create the namespace repo-pipelines? Yes
✓ Repository workspace-repo has been created in repo-pipelines namespace
✓ Setting up Bitbucket Webhook for Repository https://bitbucket.org/workspace/repo
? Please enter your bitbucket cloud username:  <username>
ℹ ️You now need to create a Bitbucket Cloud app password, please checkout the docs at https://is.gd/fqMHiJ for the required permissions
? Please enter the Bitbucket Cloud app password:  ************************************
👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
? Do you want me to use it? Yes
✓ Webhook has been created on repository workspace/repo
🔑 Webhook Secret workspace-repo has been created in the repo-pipelines namespace.
🔑 Repository CR workspace-repo has been updated with webhook secret in the repo-pipelines namespace
ℹ Directory .tekton has been created.
✓ A basic template has been created in /home/Go/src/bitbucket/repo/.tekton/pipelinerun.yaml, feel free to customize it.

    • 웹 후크를 구성하고 수동으로 Repository CR을 생성하려면 다음 단계를 수행합니다.

      1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다. 

        $ echo https://$(oc get route -n openshift-pipelines pipelines-as-code-controller -o jsonpath='{.spec.host}')

      2. Bitbucket Cloud에서 다음 단계를 수행합니다.

        1. Bitbucket Cloud 리포지토리의 왼쪽 탐색 창을 사용하여 Repository settings > Webhooks 로 이동하고 Webhook 추가 를 클릭합니다.
        2. 제목을 설정합니다. 예를 들면 "Pipelines as Code"입니다.
        3. URL 을 코드 컨트롤러 공용 URL로 파이프라인에 설정합니다.
        4. 다음 이벤트를 선택합니다. 리포지토리: 내보내기 요청,Pull Request: Created,Pull Request: Updated, Pull Request: Comment created.
        5. 저장을 클릭합니다.

      3. OpenShift 클러스터에서 대상 네임스페이스에 app 암호를 사용하여 Secret 오브젝트를 생성합니다. 

        $ oc -n target-namespace create secret generic bitbucket-cloud-token \
  --from-literal provider.token="<BITBUCKET_APP_PASSWORD>"

      4. 리포지토리 CR을 생성합니다.

        예: 리포지토리 CR

        apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
  url: "https://bitbucket.com/workspace/repo"
  branch: "main"
  git_provider:
    user: "<BITBUCKET_USERNAME>" 1
    secret:
      name: "bitbucket-cloud-token" 2
      key: "provider.token" # Set this if you have a different key in your secret

        1
        소유자 파일에서 ACCOUNT_ID 만 사용자를 참조할 수 있습니다.
        2
        코드 파이프라인은 git_provider.secret 사양에서 참조하는 시크릿과 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.
    참고
    • Bitbucket Cloud에서는 tkn pac create 및 tkn pac 부트스트랩 명령이 지원되지 않습니다.

    • Bitbucket Cloud는 Webhook 시크릿을 지원하지 않습니다. 페이로드를 보호하고 CI의 하이재킹을 방지하기 위해 코드로 된 Pipelines는 Bitbucket Cloud IP 주소 목록을 가져와서 웹 후크 수신이 해당 IP 주소에서만 수신되도록 합니다.

      • 기본 동작을 비활성화하려면 pipelinesAsCode.settings 사양에서 TektonConfig 사용자 정의 리소스에서 bitbucket-cloud-check-source-ip 매개변수를 false 로 설정합니다.
      • 추가 안전 IP 주소 또는 네트워크를 허용하려면 pipelinesAsCode.settings 사양에서 TektonConfig 사용자 정의 리소스의 bitbucket-cloud-additional-source-ip 매개변수에 쉼표로 구분된 값으로 추가합니다.

  2. 선택 사항: 기존 리포지토리 CR의 경우 여러 Bitbucket Cloud Webhook 시크릿을 추가하거나 삭제된 보안을 대신 제공합니다.

    1. tkn pac CLI 툴을 사용하여 Webhook를 추가합니다.

      예: tkn pac CLI를 사용하여 추가 Webhook 추가

      $ tkn pac webhook add -n repo-pipelines

      대화형 출력 샘플

      ✓ Setting up Bitbucket Webhook for Repository https://bitbucket.org/workspace/repo
? Please enter your bitbucket cloud username:  <username>
👀 I have detected a controller url: https://pipelines-as-code-controller-openshift-pipelines.apps.example.com
? Do you want me to use it? Yes
✓ Webhook has been created on repository workspace/repo
🔑 Secret workspace-repo has been updated with webhook secret in the repo-pipelines namespace.

      참고

      tkn pac webhook add 명령에 [-n <namespace>] 옵션을 기본 네임스페이스 이외의 네임스페이스에 있는 경우에만 사용합니다.

    2. 기존 OpenShift Secret 오브젝트에서 webhook.secret 키를 업데이트합니다.

  3. 선택 사항: 기존 리포지토리 CR의 경우 개인 액세스 토큰을 업데이트합니다.

    • tkn pac CLI 툴을 사용하여 개인 액세스 토큰을 업데이트합니다.

      예: tkn pac CLI를 사용하여 개인 액세스 토큰 업데이트

      $ tkn pac webhook update-token -n repo-pipelines

      대화형 출력 샘플

      ? Please enter your personal access token:  ****************************************
🔑 Secret owner-repo has been updated with new personal access token in the repo-pipelines namespace.

      참고

      기본 네임스페이스 이외의 네임스페이스에 Repository CR이 있는 경우에만 tkn pac webhook update-token 명령에 [-n <namespace>] 옵션을 사용합니다.

    • 또는 Repository CR을 수정하여 개인 액세스 토큰을 업데이트합니다.

      1. 리포지토리 CR에서 시크릿 이름을 찾습니다. 

        ...
spec:
  git_provider:
    user: "<BITBUCKET_USERNAME>"
    secret:
      name: "bitbucket-cloud-token"
      key: "provider.token"
...

      2. oc patch 명령을 사용하여 $target_namespace 네임스페이스에서 $password 값을 업데이트합니다. 

        $ oc -n $target_namespace patch secret bitbucket-cloud-token -p "{\"data\": {\"provider.token\": \"$(echo -n $NEW_TOKEN|base64 -w0)\"}}"

추가 리소스

3.9.9. Pipeline을 Bitbucket Server에서 Code로 사용

조직 또는 프로젝트에서 Bitbucket Server를 기본 플랫폼으로 사용하는 경우 Bitbucket Server에서 Webhook와 함께 리포지토리에 대한 코드로 Pipeline을 사용할 수 있습니다.

사전 요구 사항

  • 코드로 Pipeline이 클러스터에 설치되어 있는지 확인합니다.

  • Bitbucket Server에서 프로젝트 관리자로서 개인 액세스 토큰을 생성하고 사본을 대체 위치에 저장합니다.

    참고
    • 토큰에는 PROJECT_ADMIN 및 REPOSITORY_ADMIN 권한이 있어야 합니다.
    • 토큰은 가져오기 요청에서 분기된 리포지토리에 액세스할 수 있어야 합니다.

프로세스

  1. OpenShift 클러스터에서 코드 컨트롤러로 Pipeline의 공용 URL을 추출합니다. 

    $ echo https://$(oc get route -n openshift-pipelines pipelines-as-code-controller -o jsonpath='{.spec.host}')

  2. Bitbucket Server에서 다음 단계를 수행합니다.

    1. Bitbucket Data Center 리포지토리의 왼쪽 탐색 창을 사용하여 Repository settings > Webhooks 로 이동하고 Webhook 추가 를 클릭합니다.
    2. 제목을 설정합니다. 예를 들면 "Pipelines as Code"입니다.
    3. URL 을 코드 컨트롤러 공용 URL로 파이프라인에 설정합니다.

    4. 웹 후크 보안을 추가하고 사본을 대체 위치에 저장합니다. 로컬 시스템에 openssl 이 설치된 경우 다음 명령을 사용하여 임의의 시크릿을 생성합니다. 

      $ openssl rand -hex 20

    5. 다음 이벤트를 선택합니다.

      • 리포지토리: 푸시
      • repository: 수정
      • 가져오기 요청: 열기
      • 가져오기 요청: 소스 분기 업데이트
      • 풀 요청: 주석 추가
    6. 저장을 클릭합니다.

  3. OpenShift 클러스터에서 대상 네임스페이스에 app 암호를 사용하여 Secret 오브젝트를 생성합니다. 

    $ oc -n target-namespace create secret generic bitbucket-server-webhook-config \
  --from-literal provider.token="<PERSONAL_TOKEN>" \
  --from-literal webhook.secret="<WEBHOOK_SECRET>"

  4. 리포지토리 CR을 생성합니다.

    예: 리포지토리 CR

    apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
  url: "https://bitbucket.com/workspace/repo"
  git_provider:
    url: "https://bitbucket.server.api.url/rest" 1
    user: "<BITBUCKET_USERNAME>" 2
    secret: 3
      name: "bitbucket-server-webhook-config"
      key: "provider.token" # Set this if you have a different key in your secret
    webhook_secret:
      name: "bitbucket-server-webhook-config"
      key: "webhook.secret" # Set this if you have a different key for your secret

    1
    /api/v1.0 접미사가 없는 올바른 Bitbucket Server API URL이 있는지 확인합니다. 일반적으로 기본 설치에는 /rest 접미사가 있습니다.
    2
    소유자 파일에서 ACCOUNT_ID 만 사용자를 참조할 수 있습니다.
    3
    코드 파이프라인은 git_provider.secret 사양에서 참조하는 시크릿과 Repository CR이 동일한 네임스페이스에 있다고 가정합니다.
    참고

    Bitbucket Server에서 tkn pac create 및 tkn pac 부트스트랩 명령이 지원되지 않습니다.

추가 리소스

3.9.10. 사용자 정의 인증서를 사용하여 파이프라인을 Code로 연결

개인 서명 또는 사용자 정의 인증서로 액세스할 수 있는 Git 리포지토리를 사용하여 코드로 Pipeline을 구성하려면 인증서를 코드로 노출할 수 있습니다.

프로세스

  • Red Hat OpenShift Pipelines Operator를 사용하여 코드로 Pipeline을 설치한 경우 프록시 오브젝트를 사용하여 사용자 정의 인증서를 클러스터에 추가할 수 있습니다. Operator는 Pipeline을 Code로 포함하여 모든 Red Hat OpenShift Pipelines 구성 요소 및 워크로드에서 인증서를 노출합니다.

추가 리소스

3.9.11. Pipeline과 함께 Repository CRD(사용자 정의 리소스 정의) 사용

Repository CR(사용자 정의 리소스)에는 다음과 같은 주요 기능이 있습니다.

  • URL의 이벤트 처리에 대해 파이프라인을 코드로 알립니다.
  • Pipeline을 코드로 파이프라인 실행의 네임스페이스에 대해 알립니다.
  • Webhook 메서드를 사용하는 경우 Git 공급자 플랫폼에 필요한 API 시크릿, 사용자 이름 또는 API URL을 참조합니다.
  • 리포지토리의 마지막 파이프라인 실행 상태를 제공합니다.

tkn pac CLI 또는 기타 대체 방법을 사용하여 대상 네임스페이스 내에 Repository CR을 생성할 수 있습니다. 예를 들면 다음과 같습니다. 

cat <<EOF|kubectl create -n my-pipeline-ci -f- 1

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: project-repository
spec:
  url: "https://github.com/<repository>/<project>"
EOF
1
my-pipeline-ci 는 대상 네임스페이스입니다.

https://github.com/<repository>/<project >와 같은 URL에서 발생하는 이벤트가 있을 때마다 코드로서 Pipeline이 이를 일치시키고 파이프라인 실행이 .tekton / 디렉터리의 콘텐츠와 일치하도록 <repository>/<project > 리포지토리의 콘텐츠를 확인하기 시작합니다.

참고
  • 소스 코드 리포지토리와 연결된 파이프라인이 실행되는 동일한 네임스페이스에 Repository CRD를 생성해야 합니다. 다른 네임스페이스를 대상으로 지정할 수 없습니다.
  • 여러 Repository CRD가 동일한 이벤트와 일치하는 경우 Code로 Pipeline은 가장 오래된 이벤트만 처리합니다. 특정 네임스페이스와 일치해야 하는 경우 pipelinesascode.tekton.dev/target-namespace: "<mynamespace>" 주석을 추가합니다. 이러한 명시적 대상 지정을 통해 악의적인 작업자가 액세스 권한이 없는 네임스페이스에서 파이프라인 실행을 실행할 수 없습니다.

3.9.11.1. 동시성 제한 설정

Repository CRD(사용자 정의 리소스 정의)에서 concurrency_limit 사양을 사용하여 리포지토리에 대해 동시에 실행되는 최대 파이프라인 실행 수를 정의할 수 있습니다. 

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
# ...
  concurrency_limit: <number>
# ...

이벤트와 일치하는 파이프라인 실행이 여러 개인 경우 이벤트 시작과 일치하는 파이프라인이 알파벳순으로 실행됩니다.

예를 들어 .tekton 디렉터리에 세 개의 파이프라인 실행이 있고 리포지토리 구성에서 concurrency_limit 가 1 인 가져오기 요청을 생성하는 경우 모든 파이프라인 실행이 알파벳순으로 실행됩니다. 언제든지 한 개의 파이프라인 실행만 실행 중이고 나머지는 대기열에 있습니다.

3.9.11.2. 파이프라인 정의의 소스 분기 변경

기본적으로 푸시 이벤트 또는 가져오기 요청 이벤트를 처리할 때 Pipeline은 이벤트를 트리거한 분기에서 파이프라인 정의를 가져옵니다. Repository CRD(사용자 정의 리소스 정의)에서 pipelinerun_provenance 설정을 사용하여 기본 ,master 또는 trunk 와 같은 Git 리포지토리 공급자에 구성된 기본 분기에서 정의를 가져올 수 있습니다. 

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: my-repo
  namespace: target-namespace
spec:
# ...
  settings:
    pipelinerun_provenance: "default_branch"
# ...
참고

이 설정을 보안 예방 조치로 사용할 수 있습니다. 기본 동작으로 코드로서의 파이프라인은 제출된 가져오기 요청에서 파이프라인 정의를 사용합니다. default-branch 설정을 사용하면 파이프라인 정의를 실행하기 전에 기본 분기에 병합해야 합니다. 이 요구 사항은 병합 검토 중에 변경 사항을 가능한 최대로 확인합니다.

3.9.11.3. 사용자 정의 매개변수 확장

Pipeline을 코드로 사용하여 params 필드를 사용하여 PipelineRun 리소스 내에서 사용자 정의 매개변수를 확장할 수 있습니다. Repository CR(사용자 정의 리소스) 템플릿 내에 사용자 정의 매개변수 값을 지정할 수 있습니다. 지정된 값은 파이프라인 실행의 사용자 정의 매개변수를 대체합니다.

다음 시나리오에서는 사용자 지정 매개변수를 사용할 수 있습니다.

  • 푸시 또는 가져오기 요청에 따라 다른 레지스트리 URL과 같은 URL 매개변수를 정의하려면 다음을 수행합니다.
  • 관리자가 Git 리포지토리에서 PipelineRun 실행을 변경하지 않고도 관리할 수 있는 계정 UUID와 같은 매개변수를 정의하려면 다음을 수행합니다.
참고

Tekton 매개변수가 Pipeline 리소스에 정의되어 Git 리포지토리 내에서 함께 사용자 정의되므로 Tekton PipelineRun 매개변수를 사용할 수 없는 경우에만 사용자 정의 매개변수 확장 기능을 사용합니다. 그러나 사용자 지정 매개변수는 Repository CR이 있는 경우 정의 및 사용자 지정됩니다. 따라서 CI/CD 파이프라인을 단일 지점에서 관리할 수 없습니다.

다음 예제에서는 Repository CR에서 company 라는 사용자 정의 매개변수를 보여줍니다. 

...
spec:
  params:
    - name: company
      value: "ABC Company"
...

value Cryo stat Company 는 파이프라인 실행 및 원격으로 가져온 작업에서 매개 변수 이름 회사로 대체됩니다.

다음 예와 같이 Kubernetes 시크릿에서 사용자 정의 매개변수 값을 검색할 수도 있습니다. 

...
spec:
  params:
    - name: company
      secretRef:
        name: my-secret
        key: companyname
...

코드화로 파이프라인은 다음과 같은 방식으로 사용자 지정 매개변수를 구문 분석하고 사용합니다.

  • 값 과 secretRef 가 정의된 경우 코드로 Pipeline은 값을 사용합니다.
  • params 섹션에 이름이 없는 경우 Code로 Pipeline이 매개변수를 구문 분석하지 않습니다.
  • 이름이 붙은 매개변수가 여러 개 있는 경우 Code와 Pipelines는 마지막 매개변수를 사용합니다.

사용자 지정 매개변수를 정의하고 지정된 조건이 CEL 필터에 일치하는 경우에만 확장을 사용할 수 있습니다. 다음 예제에서는 pull request 이벤트가 트리거될 때 company 라는 사용자 지정 매개변수에 적용 가능한 CEL 필터를 보여줍니다. 

...
spec:
  params:
    - name: company
      value: "ABC Company"
      filter:
        - name: event
          value: |
      pac.event_type == "pull_request"
...
참고

이름과 다른 필터가 여러 개 있는 경우 Code와 Pipeline은 필터와 일치하는 첫 번째 매개변수를 사용합니다. 따라서 Pipeline as Code를 사용하면 다양한 이벤트 유형에 따라 매개변수를 확장할 수 있습니다. 예를 들어 push 및 pull request 이벤트를 결합할 수 있습니다.

3.9.12. Pipeline을 코드 확인기로 사용

코드 확인 프로그램으로 Pipeline을 사용하면 실행 중인 파이프라인 실행이 다른 파이프라인과 충돌하지 않습니다.

파이프라인 및 파이프라인 실행을 분할하려면 파일을 .tekton/ 디렉터리 또는 해당 하위 디렉터리에 저장합니다.

코드로서 파이프라인이 .tekton/ 디렉터리에 있는 YAML 파일에 있는 작업 또는 파이프라인에 대한 참조로 파이프라인 실행을 관찰하는 경우 코드로는 참조된 작업을 자동으로 해결하여 PipelineRun 오브젝트에 포함된 사양으로 단일 파이프라인 실행을 제공합니다.

코드로 Pipeline 또는 PipelineSpec 정의에서 참조된 작업을 확인할 수 없는 경우 클러스터에 변경 사항을 적용하기 전에 실행이 실패합니다. Git 공급자 플랫폼에서 문제와 Repository CR이 있는 대상 네임스페이스의 이벤트 내부에서 확인할 수 있습니다.

해결자는 다음 유형의 작업을 관찰하는 경우 확인을 건너뜁니다.

  • 클러스터 작업에 대한 참조입니다.
  • 작업 또는 파이프라인 번들입니다.
  • tekton.dev/ 접두사가 없는 API 버전이 있는 사용자 지정 작업입니다.

해결자는 변환 없이 이러한 작업을 문자 그대로 사용합니다.

가져오기 요청에 보내기 전에 파이프라인 실행을 로컬에서 테스트하려면 tkn pac resolve 명령을 사용합니다.

원격 파이프라인 및 작업을 참조할 수도 있습니다.

3.9.12.1. 파이프라인에서 코드로 원격 작업 주석 사용

코드로 파이프라인은 파이프라인 실행에서 주석을 사용하여 원격 작업 또는 파이프라인 가져오기를 지원합니다. 파이프라인 실행에서 원격 작업 또는 PipelineRun 또는 PipelineSpec 오브젝트의 파이프라인을 참조하는 경우, Code resolver로서 Pipeline이 자동으로 포함됩니다. 원격 작업을 가져오거나 구문 분석하는 동안 오류가 있는 경우 코드로 인해 작업 처리가 중지됩니다.

원격 작업을 포함하려면 주석의 다음 예제를 참조하십시오.

Tekton Hub에서 원격 작업 참조

  • Tekton Hub에서 단일 원격 작업을 참조합니다. 

    ...
  pipelinesascode.tekton.dev/task: "git-clone" 1
...
    1
    Code로 파이프라인에는 Tekton Hub의 최신 버전의 작업이 포함됩니다.

  • Tekton Hub에서 여러 원격 작업 참조 

    ...
  pipelinesascode.tekton.dev/task: "[git-clone, golang-test, tkn]"
...

  • -<NUMBER > 접미사를 사용하여 Tekton Hub에서 여러 원격 작업을 참조합니다. 

    ...
  pipelinesascode.tekton.dev/task: "git-clone"
  pipelinesascode.tekton.dev/task-1: "golang-test"
  pipelinesascode.tekton.dev/task-2: "tkn" 1
...
    1
    기본적으로 Code로 Pipeline은 Tekton Hub에서 가져올 최신 작업으로 문자열을 해석합니다.

  • Tekton Hub에서 특정 버전의 원격 작업을 참조합니다. 

    ...
  pipelinesascode.tekton.dev/task: "[git-clone:0.1]" 1
...
    1
    Tekton Hub에서 git-clone 원격 작업의 0.1 버전을 나타냅니다.

URL을 사용하는 원격 작업

...
  pipelinesascode.tekton.dev/task: "<https://remote.url/task.yaml>" 1
...

1
원격 작업의 공용 URL입니다.
참고

리포지토리 내부의 YAML 파일에서 작업을 참조합니다.

...
pipelinesascode.tekton.dev/task: "<share/tasks/git-clone.yaml>" 1
...

1
작업 정의가 포함된 로컬 파일의 상대 경로입니다.

3.9.12.2. 파이프라인에서 코드로 원격 파이프라인 주석 사용

원격 파이프라인 주석을 사용하여 여러 리포지토리에 파이프라인 정의를 공유할 수 있습니다. 

...
    pipelinesascode.tekton.dev/pipeline: "<https://git.provider/raw/pipeline.yaml>" 1
...
1
원격 파이프라인 정의에 대한 URL입니다. 동일한 리포지토리 내에 있는 파일의 위치를 제공할 수도 있습니다.
참고

주석을 사용하여 하나의 파이프라인 정의만 참조할 수 있습니다.

3.9.13. 파이프라인을 코드로 사용하여 파이프라인 실행 생성

코드로 Pipeline을 사용하여 파이프라인을 실행하려면 리포지토리의 .tekton/ 디렉터리에서 파이프라인 정의 또는 템플릿을 YAML 파일로 생성할 수 있습니다. 원격 URL을 사용하여 다른 리포지토리의 YAML 파일을 참조할 수 있지만 파이프라인 실행은 .tekton/ 디렉터리가 포함된 리포지토리의 이벤트에 의해서만 트리거됩니다.

코드 확인자인 파이프라인은 외부 종속 항목 없이 단일 파이프라인 실행으로 모든 작업과 함께 실행되는 번들입니다.

참고
  • 파이프라인의 경우 사양 또는 분리된 Pipeline 오브젝트와 함께 하나 이상의 파이프라인 실행을 사용합니다.
  • 작업의 경우 파이프라인 내부에 작업 사양을 포함하거나 이를 Task 오브젝트로 별도로 정의합니다.

커밋 및 URL 매개 변수화

{{<var>}} 형식으로 동적, 확장 가능한 변수를 사용하여 커밋 및 URL의 매개변수를 지정할 수 있습니다. 현재 다음 변수를 사용할 수 있습니다.

  • {{repo_owner}}: 리포지토리 소유자입니다.
  • {{REPO_NAME}}: 저장소 이름입니다.
  • {{repo_url}}: 리포지토리 전체 URL입니다.
  • {{revision}}: 커밋의 전체 SHA 리버전입니다.
  • {{sender}}: 커밋 발신자의 사용자 이름 또는 계정 ID입니다.
  • {{source_branch}}: 이벤트가 시작된 분기 이름입니다.
  • {{target_branch}}: 이벤트 대상이 되는 분기 이름입니다. 푸시 이벤트의 경우 source_branch 와 동일합니다.
  • {{pull_request_number}}: pull_request 이벤트 유형에 대해서만 정의된 가져오기 또는 병합 요청 번호입니다.
  • {{git_auth_secret}}: 개인 리포지터리를 확인하기 위해 Git 공급자의 토큰으로 자동 생성된 시크릿 이름입니다.

파이프라인 실행에 이벤트 일치

파이프라인 실행에서 특수 주석을 사용하여 각 파이프라인과 다른 Git 공급자 이벤트를 일치시킬 수 있습니다. 이벤트와 일치하는 Pipeline이 여러 개 있는 경우 Code가 병렬로 실행되고 파이프라인 실행이 완료되면 Pipeline이 Git 공급자에 결과를 게시합니다.

파이프라인 실행에 가져오기 이벤트 일치

다음 예제를 사용하여 기본 분기를 대상으로 하는 pull_request 이벤트와 pipeline-pr- main 파이프라인을 일치시킬 수 있습니다. 

...
  metadata:
    name: pipeline-pr-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[main]" 1
    pipelinesascode.tekton.dev/on-event: "[pull_request]"
...
1
쉼표로 구분된 항목을 추가하여 여러 분기를 지정할 수 있습니다. 예: "[main, release-nightly]" 입니다. 또한 다음을 지정할 수 있습니다.
  • "refs/heads/main"과 같은 분기에 대한 전체 참조
  • "refs/heads/\*"와 같은 패턴 일치가 있는 글러
  • "refs/tags/1.\*"와 같은 태그

파이프라인 실행에 푸시 이벤트 일치

다음 예제를 사용하여 refs/heads/main 브랜치를 대상으로 하는 push 이벤트와 pipeline-push-on-main 파이프라인을 일치시킬 수 있습니다. 

...
  metadata:
    name: pipeline-push-on-main
  annotations:
    pipelinesascode.tekton.dev/on-target-branch: "[refs/heads/main]" 1
    pipelinesascode.tekton.dev/on-event: "[push]"
...
1
쉼표로 구분된 항목을 추가하여 여러 분기를 지정할 수 있습니다. 예: "[main, release-nightly]" 입니다. 또한 다음을 지정할 수 있습니다.
  • "refs/heads/main"과 같은 분기에 대한 전체 참조
  • "refs/heads/\*"와 같은 패턴 일치가 있는 글러
  • "refs/tags/1.\*"와 같은 태그

고급 이벤트 일치

코드인 파이프라인은 고급 이벤트 일치에 대한 CEL(Common Expression Language) 기반 필터링 사용을 지원합니다. 파이프라인 실행에 pipelinesascode.tekton.dev/on-cel-expression 주석이 있는 경우 Code로 Pipeline은 CEL 표현식을 사용하고 on-target-branch 주석을 건너뜁니다. 간단한 on-target-branch 주석 일치와 비교하여 CEL 표현식은 복잡한 필터링 및 부정을 허용합니다.

파이프라인과 함께 CEL 기반 필터링을 코드로 사용하려면 주석의 다음 예를 고려하십시오.

  • 기본 분기를 대상으로 pull_request 이벤트를 일치시키고 wip 분기에서 들어오는 경우 다음을 수행합니다. 

    ...
  pipelinesascode.tekton.dev/on-cel-expression: |
    event == "pull_request" && target_branch == "main" && source_branch == "wip"
...

  • 경로가 변경된 경우에만 파이프라인을 실행하려면 .pathChanged 접미사 함수를 와일드카드 패턴과 함께 사용하면 됩니다. 

    ...
  pipelinesascode.tekton.dev/on-cel-expression: |
    event == "pull_request" && "docs/\*.md".pathChanged() 1
...
    1
    docs 디렉터리의 모든 마크다운 파일과 일치합니다.

  • 제목 [DOWNSTREAM] 으로 시작하는 모든 풀 요청을 일치시킵니다. 

    ...
  pipelinesascode.tekton.dev/on-cel-expression: |
    event == "pull_request && event_title.startsWith("[DOWNSTREAM]")
...

  • pull_request 이벤트에서 파이프라인을 실행하되 실험적인 분기를 건너뛰려면 다음을 수행합니다. 

    ...
  pipelinesascode.tekton.dev/on-cel-expression: |
    event == "pull_request" && target_branch != experimental"
...

코드로 Pipeline을 사용하는 동안 고급 CEL 기반 필터링의 경우 다음 필드 및 접미사 함수를 사용할 수 있습니다.

  • 이벤트: push 또는 pull_request 이벤트
  • target_branch: 대상 분기입니다.
  • source_branch: pull_request 이벤트의 origin 분기입니다. 푸시 이벤트의 경우 target_branch 와 동일합니다.
  • event_title: 푸시 이벤트의 커밋 제목과 pull_request 이벤트에 대한 풀 또는 병합 요청의 제목과 같은 이벤트의 제목을 찾습니다. 현재는 GitHub, Gitlab, Bitbucket Cloud만 지원되는 공급업체입니다.
  • .pathChanged: 문자열에 대한 접미사 함수입니다. 문자열은 경로가 변경되었는지 확인하는 경로의 glob일 수 있습니다. 현재는 GitHub 및 Gitlab만 공급업체로 지원됩니다.

Github API 작업에 임시 GitHub 앱 토큰 사용

Pipeline에서 생성한 임시 설치 토큰을 GitHub App에서 Code로 사용하여 GitHub API에 액세스할 수 있습니다. 토큰 값은 git-provider-token 키의 개인 리포지토리에 대해 생성된 임시 {{git_auth_secret}} 동적 변수에 저장됩니다.

예를 들어 가져오기 요청에 주석을 추가하려면 Pipelines를 코드 주석으로 사용하여 Tekton Hub의 github-add-comment 작업을 사용할 수 있습니다. 

...
  pipelinesascode.tekton.dev/task: "github-add-comment"
...

그런 다음 tasks 섹션에 작업을 추가하거나 파이프라인 실행 정의의 finally 작업에 추가할 수 있습니다. 

[...]
tasks:
  - name:
      taskRef:
        name: github-add-comment
      params:
        - name: REQUEST_URL
          value: "{{ repo_url }}/pull/{{ pull_request_number }}" 1
        - name: COMMENT_OR_FILE
          value: "Pipelines as Code IS GREAT!"
        - name: GITHUB_TOKEN_SECRET_NAME
          value: "{{ git_auth_secret }}"
        - name: GITHUB_TOKEN_SECRET_KEY
          value: "git-provider-token"
...
1
동적 변수를 사용하면 리포지토리에서 가져오기 요청에 이 스니펫 템플릿을 재사용할 수 있습니다.
참고

GitHub 앱에서 생성된 설치 토큰은 8시간 동안 사용할 수 있으며 클러스터에서 다르게 구성되지 않는 한 이벤트가 시작된 리포지토리에 범위가 지정됩니다.

추가 리소스

3.9.14. 파이프라인을 코드로 사용하여 파이프라인 실행 실행

기본 구성을 사용하면 코드에서 파이프라인은 가져오기 요청 또는 푸시와 같은 지정된 이벤트가 리포지터리에서 발생하는 경우 리포지토리의 기본 리포지토리 분기의 .tekton/ 디렉터리에서 모든 파이프라인을 실행합니다. 예를 들어 기본 분기에서 파이프라인 실행의 주석 pipelinesascode.tekton.dev/on-event: "[pull_request]" 가 있는 경우 가져오기 요청 이벤트가 발생할 때마다 실행됩니다.

가져오기 요청 또는 병합 요청이 있는 경우 Code로 Pipeline은 가져오기 요청 작성자가 다음 조건을 충족하는 경우 기본 분기 이외의 분기에서 파이프라인도 실행합니다.

  • 작성자는 리포지토리의 소유자입니다.
  • 작성자는 리포지토리의 협업자입니다.
  • 작성자는 리포지토리 조직의 공개 멤버입니다.
  • 가져오기 요청 작성자는 리포지토리의 GitHub 구성에 정의된 대로 기본 분기의 리포지토리 루트에 있는 OWNER 파일에 나열됩니다. 또한 가져오기 요청 작성자가 승인 자 또는 검토자 섹션에 추가됩니다. 예를 들어 작성자가 승인자 섹션에 나열되면 해당 작성자가 생성한 가져오기 요청이 파이프라인 실행을 시작합니다. 
...
  approvers:
    - approved
...

가져오기 요청 작성자가 요구 사항을 충족하지 않으면 요구 사항을 충족하는 다른 사용자가 가져오기 요청에 대해 /ok-to-test 를 처리하고 파이프라인 실행을 시작할 수 있습니다.

파이프라인 실행 실행

파이프라인 실행은 이벤트를 생성한 리포지토리와 연결된 Repository CRD(사용자 정의 리소스 정의)의 네임스페이스에서 항상 실행됩니다.

tkn pac CLI 툴을 사용하여 파이프라인 실행의 실행을 확인할 수 있습니다.

  • 마지막 파이프라인 실행을 추적하려면 다음 예제를 사용합니다. 

    $ tkn pac logs -n <my-pipeline-ci> -L 1
    1
    my-pipeline-ci 는 Repository CRD의 네임스페이스입니다.

  • 대화형으로 실행되는 모든 파이프라인 실행을 추적하려면 다음 예제를 사용합니다. 

    $ tkn pac logs -n <my-pipeline-ci> 1
    1
    my-pipeline-ci 는 Repository CRD의 네임스페이스입니다. 마지막이 아닌 다른 파이프라인 실행을 확인해야 하는 경우 tkn pac logs 명령을 사용하여 리포지토리에 연결된 PipelineRun 을 선택할 수 있습니다.

GitHub App을 사용하여 파이프라인을 코드로 구성한 경우 코드로 파이프라인은 GitHub 앱의 검사 탭에 URL을 게시합니다. URL을 클릭하고 파이프라인 실행을 따를 수 있습니다.

파이프라인 실행 다시 시작

새 커밋을 분기에 전송하거나 가져오기 요청을 높이는 등 이벤트 없이 파이프라인 실행을 재시작할 수 있습니다. GitHub 앱에서 확인 탭으로 이동하여 다시 실행을 클릭합니다.

가져오기 또는 병합 요청을 대상으로 하는 경우 가져오기 요청 내부에 다음 주석을 사용하여 모든 또는 특정 파이프라인 실행을 다시 시작합니다.

  • /retest 주석은 모든 파이프라인 실행을 재시작합니다.
  • /retest <pipelinerun-name> 주석에서 특정 파이프라인 실행을 다시 시작합니다.
  • /cancel 주석은 모든 파이프라인 실행이 취소됩니다.
  • /cancel <pipelinerun-name&gt; 주석은 특정 파이프라인 실행이 취소됩니다.

주석의 결과는 GitHub 앱의 확인 탭에 표시됩니다.

3.9.15. 파이프라인을 코드로 사용하여 파이프라인 실행 상태 모니터링

컨텍스트 및 지원되는 툴에 따라 다양한 방법으로 파이프라인 실행 상태를 모니터링할 수 있습니다.

GitHub 앱의 상태

파이프라인 실행이 완료되면 Check 탭에 파이프라인의 각 작업이 수행된 기간 및 tkn pipelinerun describe 명령의 출력에 대한 제한된 정보가 포함되어 있습니다.

로그 오류 스니펫

코드로 파이프라인 작업 중 하나에서 오류를 감지하면 첫 번째 실패한 작업의 작업 분류에 있는 마지막 3행으로 구성된 작은 스니펫이 표시됩니다.

참고

코드로 파이프라인을 사용하면 파이프라인 실행을 살펴보고 시크릿 값을 숨겨진 문자로 교체하여 시크릿 누출을 방지할 수 있습니다. 그러나 코드로 Pipeline은 작업 공간 및 envFrom 소스에서 발생하는 시크릿을 숨길 수 없습니다.

로그 오류 조각에 대한 주석

TektonConfig 사용자 지정 리소스의 pipelinesAsCode.settings 사양에서 error-detection-from-container-logs 매개변수를 true 로 설정할 수 있습니다. 이 경우 코드로서의 파이프라인은 컨테이너 로그의 오류를 감지하고 오류가 발생한 가져오기 요청에 주석을 추가합니다.

중요

로그 오류 스니펫에 대한 주석을 추가하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

현재 코드로 Pipeline은 오류가 makefile 또는 다음 형식의 grep 출력과 같은 간단한 사례만 지원합니다. 

<filename>:<line>:<column>: <error message>

error-detection-simple-regexp 매개변수를 사용하여 오류를 감지하는 데 사용되는 정규식을 사용자 지정할 수 있습니다. 정규식에서는 이름이 지정된 그룹을 사용하여 일치 항목을 지정하는 방법에 대한 유연성을 제공합니다. 일치에 필요한 그룹은 파일 이름,행, 오류입니다. 기본 정규식에 대한 코드 구성 맵으로 Pipeline을 볼 수 있습니다.

참고

기본적으로 코드인 Pipeline은 컨테이너 로그의 마지막 50행만 검사합니다. error-detection-max-number-of-lines 필드에서 이 값을 늘리거나 무제한 행 수에 대해 -1 을 설정할 수 있습니다. 그러나 이러한 구성은 감시자의 메모리 사용량을 늘릴 수 있습니다.

Webhook 상태

Webhook의 경우 이벤트가 가져오기 요청인 경우 가져오기 또는 병합 요청에 대한 주석으로 상태가 추가됩니다.

실패

네임스페이스가 Repository CRD(사용자 정의 리소스 정의)와 일치하는 경우 코드로서의 Pipeline은 네임스페이스 내부의 Kubernetes 이벤트에서 실패 로그 메시지를 내보냅니다.

Repository CRD와 관련된 상태

파이프라인 실행에 대한 마지막 5개의 상태 메시지는 Repository 사용자 정의 리소스 내부에 저장됩니다. 

$ oc get repo -n <pipelines-as-code-ci>
NAME                  URL                                                        NAMESPACE             SUCCEEDED   REASON      STARTTIME   COMPLETIONTIME
pipelines-as-code-ci   https://github.com/openshift-pipelines/pipelines-as-code   pipelines-as-code-ci   True        Succeeded   59m         56m

tkn pac describe 명령을 사용하면 리포지토리 및 해당 메타데이터와 연결된 실행 상태를 추출할 수 있습니다.

알림

코드로 파이프라인은 알림을 관리하지 않습니다. 알림이 필요한 경우 파이프라인의 finally 기능을 사용하십시오.

추가 리소스

3.9.16. 파이프라인을 코드로 사용하여 개인 리포지토리 사용

코드로 파이프라인은 사용자 토큰으로 대상 네임스페이스에서 보안을 생성하거나 업데이트하여 개인 리포지토리를 지원합니다. Tekton Hub의 git-clone 작업은 사용자 토큰을 사용하여 개인 리포지토리를 복제합니다.

코드로서 파이프라인이 대상 네임스페이스에서 새 파이프라인 실행을 생성할 때마다 pac-gitauth-<REPOSITORY_OWNER>-<REPOSITORY_NAME>-<RANDOM_STRING > 형식으로 시크릿을 생성하거나 업데이트합니다.

그런 다음 파이프라인 실행 및 파이프라인 정의에서 basic-auth 작업 영역을 사용하여 보안을 참조해야 합니다. 그러면 git-clone 작업으로 전달됩니다. 

...
  workspace:
  - name: basic-auth
    secret:
      secretName: "{{ git_auth_secret }}"
...

파이프라인에서는 재사용할 git-clone 작업의 basic-auth 작업 영역을 참조할 수 있습니다. 

...
workspaces:
  - name basic-auth
params:
    - name: repo_url
    - name: revision
...
tasks:
  workspaces:
    - name: basic-auth
      workspace: basic-auth
  ...
  tasks:
  - name: git-clone-from-catalog
      taskRef:
        name: git-clone 1
      params:
        - name: url
          value: $(params.repo_url)
        - name: revision
          value: $(params.revision)
...
1
git-clone 작업은 basic-auth 작업 영역을 선택하고 이를 사용하여 개인 리포지토리를 복제합니다.

pipelinesAsCode.settings 사양의 TektonConfig 사용자 지정 리소스에서 필요에 따라 secret-auto-create 매개변수를 false 또는 true 값으로 설정하여 이 구성을 수정할 수 있습니다.

추가 리소스

3.9.17. 파이프라인을 코드로 사용하여 파이프라인 실행 정리

사용자 네임스페이스에는 많은 파이프라인 실행이 있을 수 있습니다. max-keep-runs 주석을 설정하면 이벤트와 일치하는 제한된 수의 파이프라인 실행을 유지하도록 파이프라인을 Code로 구성할 수 있습니다. 예를 들면 다음과 같습니다. 

...
  pipelinesascode.tekton.dev/max-keep-runs: "<max_number>" 1
...
1
코드로서 파이프라인은 성공적인 실행이 완료된 직후 정리를 시작하여 주석을 사용하여 구성된 최대 파이프라인 실행 수만 유지합니다.
참고
  • 코드로 파이프라인은 실행 중인 파이프라인 정리를 생략하지만 파이프라인은 알 수 없는 상태로 실행됩니다.
  • 코드로 파이프라인은 실패한 가져오기 요청 정리를 건너뜁니다.

3.9.18. 파이프라인에서 코드로 들어오는 Webhook 사용

들어오는 웹 후크 URL과 공유 보안을 사용하여 리포지토리에서 파이프라인 실행을 시작할 수 있습니다.

들어오는 Webhook를 사용하려면 Repository CRD(사용자 정의 리소스 정의)의 spec 섹션에서 다음을 지정합니다.

  • 코드로 Pipeline이 일치하는 들어오는 웹 후크 URL입니다.

  • Git 공급자 및 사용자 토큰입니다. 현재 코드로 Pipeline은 github,gitlab, bitbucket-cloud 를 지원합니다.

    참고

    GitHub 앱의 컨텍스트에서 들어오는 Webhook URL을 사용하는 경우 토큰을 지정해야 합니다.

  • 대상 분기와 들어오는 Webhook URL의 시크릿입니다.

예: 수신 Webhook가 있는 Repository CRD

apiVersion: "pipelinesascode.tekton.dev/v1alpha1"
kind: Repository
metadata:
  name: repo
  namespace: ns
spec:
  url: "https://github.com/owner/repo"
  git_provider:
    type: github
    secret:
      name: "owner-token"
  incoming:
    - targets:
      - main
      secret:
        name: repo-incoming-secret
      type: webhook-url

예: 들어오는 Webhook의 repo-incoming-secret 보안

apiVersion: v1
kind: Secret
metadata:
  name: repo-incoming-secret
  namespace: ns
type: Opaque
stringData:
  secret: <very-secure-shared-secret>

Git 리포지토리의 .tekton 디렉터리에 있는 파이프라인 실행을 트리거하려면 다음 명령을 사용합니다. 

$ curl -X POST 'https://control.pac.url/incoming?secret=very-secure-shared-secret&repository=repo&branch=main&pipelinerun=target_pipelinerun'

코드인 파이프라인은 들어오는 URL과 일치하고 푸시 이벤트로 처리합니다. 그러나 코드로 파이프라인은 이 명령으로 트리거된 파이프라인 실행의 상태를 보고하지 않습니다.

보고서 또는 알림을 가져오려면 파이프라인에 finally 작업과 함께 직접 추가합니다. 또는 tkn pac CLI 툴을 사용하여 Repository CRD를 검사할 수도 있습니다.

3.9.19. 코드 구성으로 Pipeline 사용자 정의

클러스터 관리자는 Pipelines를 코드로 사용자 정의하기 위해 pipelinesAsCode.settings 사양의 TektonConfig 사용자 정의 리소스에서 다음 매개변수를 구성할 수 있습니다.

표 3.13. 코드 구성으로 Pipeline 사용자 정의

매개변수설명Default

application-name

애플리케이션 이름입니다. 예를 들어 GitHub Checks 라벨에 표시되는 이름입니다.

"pipelines as Code CI"

secret-auto-create

GitHub 애플리케이션에서 생성된 토큰을 사용하여 시크릿을 자동으로 생성할지 여부를 나타냅니다. 그러면 이 시크릿을 프라이빗 리포지토리와 함께 사용할 수 있습니다.

enabled

remote-tasks

활성화하면 파이프라인 실행 주석에서 원격 작업을 허용합니다.

enabled

hub-url

Tekton Hub API 의 기본 URL입니다.

https://hub.tekton.dev/

hub-catalog-name

Tekton Hub 카탈로그 이름입니다.

tekton

tekton-dashboard-url

Tekton Hub 대시보드의 URL입니다. Pipeline as Code는 이 URL을 사용하여 Tekton Hub 대시보드에서 PipelineRun URL을 생성합니다.

해당 없음

bitbucket-cloud-check-source-ip

공용 Bitbucket의 IP 범위를 쿼리하여 서비스 요청의 보안 여부를 나타냅니다. 매개변수의 기본값을 변경하면 보안 문제가 발생할 수 있습니다.

enabled

bitbucket-cloud-additional-source-ip

쉼표로 구분된 추가 IP 범위 또는 네트워크 세트를 제공할지 여부를 나타냅니다.

해당 없음

max-keep-run-up-limit

파이프라인 실행의 max-keep-run 값에 대한 최대 제한입니다.

해당 없음

default-max-keep-runs

파이프라인 실행의 max-keep-run 값에 대한 기본 제한입니다. 정의된 경우 max-keep-run 주석이 없는 모든 파이프라인 실행에 값이 적용됩니다.

해당 없음

auto-configure-new-github-repo

새 GitHub 리포지토리를 자동으로 구성합니다. Code로 Pipeline은 네임스페이스를 설정하고 리포지토리에 대한 사용자 정의 리소스를 생성합니다. 이 매개변수는 GitHub 애플리케이션에서만 지원됩니다.

disabled

auto-configure-repo-namespace-template

auto-configure-new-github-repo 가 활성화된 경우 새 리포지토리의 네임스페이스를 자동으로 생성하도록 템플릿을 구성합니다.

{repo_name}-pipelines

error-log-snippet

파이프라인의 오류와 함께 실패한 작업에 대한 로그 스니펫 보기를 활성화하거나 비활성화합니다. 파이프라인에서 데이터 누출의 경우 이 매개변수를 비활성화할 수 있습니다.

true

error-detection-from-container-logs

컨테이너 로그 검사를 활성화하거나 비활성화하여 오류 메시지를 감지하고 가져오기 요청에 주석으로 노출합니다. 이 설정은 GitHub 앱을 사용하는 경우에만 적용됩니다.

true

error-detection-max-number-of-lines

컨테이너 로그에서 검사한 최대 행 수로 오류 메시지를 검색합니다. 무제한의 행 수를 검사하려면 -1 로 설정합니다.

50

secret-github-app-token-scoped

true 로 설정하면 GitHub 앱을 사용하여 Pipeline이 생성하는 GitHub 액세스 토큰의 범위는 Code에서 Pipeline 정의를 가져오는 리포지토리에만 범위가 지정됩니다. false 로 설정하면 TektonConfig 사용자 정의 리소스와 Repository 사용자 정의 리소스를 모두 사용하여 토큰의 범위를 추가 리포지토리로 지정할 수 있습니다.

true

secret-github-app-scope-extra-repos

생성된 GitHub 액세스 토큰의 범위를 지정하는 추가 리포지토리입니다.

 

3.9.20. 코드 명령 참조로 Pipeline

tkn pac CLI 툴에서는 다음과 같은 기능을 제공합니다.

  • 코드 설치 및 구성으로 부트스트랩 Pipeline입니다.
  • 새 Pipeline을 코드 리포지토리로 생성합니다.
  • 모든 Pipeline을 코드 리포지토리로 나열합니다.
  • Pipeline을 코드 리포지토리 및 관련 실행으로 설명합니다.
  • 시작할 간단한 파이프라인 실행을 생성합니다.
  • Pipeline에서 코드로 실행한 것처럼 파이프라인 실행을 해결합니다.
작은 정보

테스트 및 실험 기능에 해당하는 명령을 사용할 수 있으므로 애플리케이션 소스 코드가 포함된 Git 리포지토리를 변경할 필요가 없습니다.

3.9.20.1. 기본 구문

$ tkn pac [command or options] [arguments]

3.9.20.2. 글로벌 옵션

$ tkn pac --help

3.9.20.3. 유틸리티 명령

3.9.20.3.1. bootstrap

표 3.14. 코드 설치 및 구성으로 Pipeline 부트스트랩

명령설명

tkn pac bootstrap

GitHub 및 GitHub Enterprise와 같은 Git 리포지토리 호스팅 서비스 공급자의 코드로 Pipeline을 설치하고 구성합니다.

tkn pac bootstrap --nightly

파이프라인의 Nightly build를 코드로 설치합니다.

tkn pac bootstrap --route-url <public_url_to_ingress_spec>

OpenShift 경로 URL을 덮어씁니다.

기본적으로 tkn pac 부트스트랩 은 Pipeline 컨트롤러 서비스로 자동으로 연결된 OpenShift 경로를 감지합니다.

OpenShift Container Platform 클러스터가 없는 경우 수신 끝점을 가리키는 공용 URL을 요청합니다.

tkn pac bootstrap github-app

openshift-pipelines 네임스페이스에 GitHub 애플리케이션 및 시크릿을 생성합니다.

3.9.20.3.2. 리포지터리

표 3.15. Pipeline을 코드 리포지토리로 관리

명령설명

tkn pac create repository

새 Pipeline을 코드 리포지토리로 생성하고 파이프라인 실행 템플릿을 기반으로 네임스페이스를 생성합니다.

tkn pac list

모든 Pipeline을 코드 리포지토리로 나열하고 관련 실행의 마지막 상태를 표시합니다.

tkn pac repo describe

Pipeline을 코드 리포지토리 및 관련 실행으로 설명합니다.

3.9.20.3.3. generate

표 3.16. Pipeline을 코드로 사용하여 파이프라인 실행 생성

명령설명

tkn pac generate

간단한 파이프라인 실행을 생성합니다.

소스 코드가 포함된 디렉터리에서 실행되는 경우 현재 Git 정보를 자동으로 탐지합니다.

또한 기본 언어 탐지 기능을 사용하고 언어에 따라 추가 작업을 추가합니다.

예를 들어 리포지토리 루트에서 setup.py 파일을 감지하면 pECDHE int 작업이 생성된 파이프라인 실행에 자동으로 추가됩니다.

3.9.20.3.4. resolve

표 3.17. Pipeline을 코드로 사용하여 파이프라인 실행 확인 및 실행

명령설명

tkn pac resolve

파이프라인 실행이 서비스의 Code로 Pipeline에 속하는 것처럼 실행합니다.

tkn pac resolve -f .tekton/pull-request.yaml | oc apply -f -

.tekton/pull-request.yaml 에서 템플릿을 사용하는 라이브 파이프라인 실행의 상태를 표시합니다.

로컬 머신에서 실행 중인 Kubernetes 설치와 결합하면 새 커밋을 생성하지 않고도 파이프라인 실행을 확인할 수 있습니다.

소스 코드 리포지토리에서 명령을 실행하는 경우 현재 Git 정보를 감지하고 현재 리버전 또는 분기와 같은 매개변수를 자동으로 해결합니다.

tkn pac resolve -f .tekton/pr.yaml -p revision=main -p repo_name=<repository_name>

Git 리포지토리에서 파생된 기본 매개변수 값을 재정의하여 파이프라인 실행을 실행합니다.

-f 옵션은 디렉터리 경로를 수락하고 해당 디렉터리의 모든 .yaml 또는 .yml 파일에 tkn pac resolve 명령을 적용할 수도 있습니다. 동일한 명령에서 -f 플래그를 여러 번 사용할 수도 있습니다.

-p 옵션을 사용하여 매개변수 값을 지정하여 Git 리포지토리에서 수집한 기본 정보를 덮어쓸 수 있습니다. 예를 들어 Git 분기를 버전 및 다른 리포지토리 이름으로 사용할 수 있습니다.

3.9.21. 네임스페이스별 Pipeline을 코드 로그로 분할

로그에는 로그를 필터링하거나 특정 네임스페이스로 로그를 분할할 수 있는 네임스페이스 정보가 포함되어 있습니다. 예를 들어 mynamespace 네임스페이스와 관련된 로그를 보려면 다음 명령을 입력합니다. 

$ oc logs pipelines-as-code-controller-<unique-id> -n openshift-pipelines | grep mynamespace 1
1
pipelines-as-code-controller-<unique-id >를 코드 컨트롤러 이름으로 Pipeline으로 바꿉니다.

3.9.22. 추가 리소스

3.10. 개발자 화면을 사용하여 Red Hat OpenShift Pipelines 작업

OpenShift Container Platform 웹 콘솔의 개발자 화면을 사용하여 소프트웨어 제공 프로세스를 위한 CI/CD Pipeline을 생성할 수 있습니다.

개발자 화면에서:

  • Add → Pipeline → Pipeline builder 옵션을 사용하여 애플리케이션에 사용자 지정된 파이프라인을 생성합니다.
  • Add → From Git 옵션을 사용하여 OpenShift Container Platform에서 애플리케이션을 생성하는 동안 operator 설치 파이프라인 템플릿과 리소스를 이용해 파이프라인을 생성합니다.

애플리케이션의 파이프라인을 생성한 후 Pipelines 보기에서 배포된 파이프라인을 보면서 시각적으로 상호 작용할 수 있습니다. Topology 보기에서도 From Git 옵션을 사용하여 생성된 파이프라인과 상호 작용할 수 있습니다. Topology 보기에서 볼 수 있으려면 Pipeline 빌더를 사용하여 생성된 파이프라인에 사용자 정의 레이블을 적용해야 합니다.

사전 요구 사항

3.10.1. Pipeline 빌더를 사용하여 파이프라인 구성

콘솔의 개발자 화면에서 +추가 → 파이프라인 → 파이프라인 빌더 옵션을 사용하여 다음을 수행할 수 있습니다.

  • 파이프라인 빌더 또는 YAML 보기를 사용하여 파이프라인을 구성합니다.
  • 기존 작업 및 클러스터 작업을 사용하여 파이프라인 흐름을 구성합니다. OpenShift Pipelines Operator를 설치하면 재사용 가능한 파이프라인 클러스터 작업이 클러스터에 추가됩니다.
중요

Red Hat OpenShift Pipelines 1.10에서는 클러스터 작업 기능이 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

  • 파이프라인 실행에 필요한 리소스 유형을 지정하고, 필요한 경우 파이프라인에 매개변수를 추가합니다.
  • 파이프라인의 각 작업에서 이러한 파이프라인 리소스를 입력 및 출력 리소스로 참조합니다.
  • 필요한 경우 작업의 파이프라인에 추가된 매개변수를 참조합니다. 작업 매개변수는 작업 사양에 따라 미리 채워집니다.
  • Operator에서 설치한 재사용 가능 조각과 샘플을 사용하여 세부 파이프라인을 생성합니다.
  • 구성된 로컬 Tekton Hub 인스턴스에서 작업을 검색하고 추가합니다.
중요

개발자 관점에서 고유한 큐레이션 작업 세트를 사용하여 사용자 지정 파이프라인을 생성할 수 있습니다. 개발자 콘솔에서 직접 작업을 검색, 설치 및 업그레이드하려면 클러스터 관리자가 로컬 Tekton Hub 인스턴스를 설치 및 배포하고 해당 허브를 OpenShift Container Platform 클러스터에 연결해야 합니다. 자세한 내용은 추가 리소스 섹션에서 Tekton Hub with OpenShift Pipelines 를 참조하십시오. 기본적으로 로컬 Tekton Hub 인스턴스를 배포하지 않으면 클러스터 작업, 네임스페이스 작업 및 공용 Tekton Hub 작업에만 액세스할 수 있습니다.

절차

  1. 개발자 화면의 +추가 보기에서 파이프라인 타일을 클릭하여 파이프라인 빌더 페이지를 표시합니다.

  2. 파이프라인 빌더 보기 또는 YAML 보기를 사용하여 파이프라인을 구성합니다.

    참고

    파이프라인 빌더 보기에서는 제한된 수의 필드를 지원하는 반면 YAML 보기는 사용 가능한 모든 필드를 지원합니다. 필요한 경우 Operator에서 설치한 재사용 가능 조각과 샘플을 사용하여 세부 파이프라인을 생성할 수도 있습니다.

    그림 3.1. YAML보기

    op pipeline yaml

  3. 파이프라인 빌더를 사용하여 파이프라인 을 구성합니다.

    1. 이름 필드에 파이프라인의 고유 이름을 입력합니다.

    2. 작업 섹션에서 다음을 수행합니다.

      1. 작업 추가를 클릭합니다.
      2. 빠른 검색 필드를 사용하여 작업을 검색하고 표시된 목록에서 필요한 작업을 선택합니다.

      3. 추가 또는 설치를 클릭하고 추가를 추가합니다. 이 예제에서는 s2i-nodejs 작업을 사용합니다.

        참고

        검색 목록에는 클러스터에서 사용 가능한 모든 Tekton Hub 작업 및 작업이 포함되어 있습니다. 또한 작업이 이미 설치되어 있으면 Add to add the task while it will show Install and add to install and add the task가 표시됩니다. Update 및 add when you add the same task with an updated version을 표시합니다.

        • 파이프라인에 순차 작업을 추가하려면 다음을 수행합니다.

          • 작업 오른쪽 또는 왼쪽에 있는 더하기 아이콘을 클릭하고 작업 추가를 클릭합니다.
          • 빠른 검색 필드를 사용하여 작업을 검색하고 표시된 목록에서 필요한 작업을 선택합니다.

          • 추가 또는 설치를 클릭하고 추가를 추가합니다.

            그림 3.2. Pipeline 빌더

            op Pipeline 빌더

        • 최종 작업을 추가하려면 다음을 수행합니다.

          • Add finally 작업 → Add task 를 클릭합니다.
          • 빠른 검색 필드를 사용하여 작업을 검색하고 표시된 목록에서 필요한 작업을 선택합니다.
          • 추가 또는 설치를 클릭하고 추가를 추가합니다.

    3. 리소스 섹션에서 리소스 추가를 클릭하여 파이프라인 실행에 사용할 리소스의 이름 및 유형을 지정합니다. 그러면 파이프라인의 작업에서 이러한 리소스를 입력 및 출력으로 사용합니다. 예시의 경우:

      1. 입력 리소스를 추가합니다. 이름 필드에 Source를 입력하고 리소스 유형 드롭다운 목록에서 Git을 선택합니다.

      2. 출력 리소스를 추가합니다. 이름 필드에 Img를 입력하고 리소스 유형 드롭다운 목록에서 이미지를 선택합니다.

        참고

        리소스가 누락된 경우 작업 옆에 빨간색 아이콘이 표시됩니다.

    4. 선택 사항: 작업의 매개변수는 작업 사양에 따라 미리 채워집니다. 필요에 따라 매개 변수 섹션에 있는 매개 변수 추가 링크를 사용하여 매개변수를 더 추가합니다.
    5. 작업 공간 섹션에서 작업 공간 추가를 클릭하고 이름 필드에 고유한 작업 공간 이름을 입력합니다. 파이프라인에 여러 개의 작업 공간을 추가할 수 있습니다.

    6. 작업 섹선에서 s2i-nodejs 작업을 클릭하여 작업 세부 정보가 있는 측면 패널을 확인합니다. 작업 측면 패널에서 s2i-nodejs 작업에 대한 리소스 및 매개변수를 지정합니다.

      1. 필요에 따라 매개 변수 섹션에서 $(params.<param-name>) 구문을 사용하여 기본 매개변수에 매개변수를 더 추가합니다.
      2. 이미지 섹션에서 리소스 섹션에 지정된 대로 Img를 입력합니다.
      3. 작업 공간 섹션의 소스 드롭다운에서 작업 공간을 선택합니다.
    7. 리소스, 매개 변수 및 작업 공간을 openshift-client 작업에 추가합니다.
  4. 생성을 클릭하여 파이프라인 세부 정보 페이지에서 파이프라인을 생성하고 봅니다.
  5. 작업 드롭다운 메뉴를 클릭한 다음 시작을 클릭하여 파이프라인 시작 페이지를 확인합니다.
  6. 작업 공간 섹션에는 이전에 생성한 작업 공간이 나열됩니다. 각 드롭다운을 사용하여 작업 공간의 볼륨 소스를 지정합니다. 빈 디렉토리,구성 맵,시크릿, 영구 볼륨 클레임, 볼륨 클레임 템플릿 옵션이 있습니다.

3.10.2. 애플리케이션과 함께 OpenShift Pipelines 생성

애플리케이션과 함께 파이프라인을 생성하려면 개발자 화면의 Add+ 보기에서 From Git 옵션을 사용합니다. 사용 가능한 모든 파이프라인을 보고 코드를 가져오거나 이미지를 배포하는 동안 애플리케이션을 생성하는 데 사용할 파이프라인을 선택할 수 있습니다.

Tekton Hub Integration은 기본적으로 활성화되어 있으며 클러스터에서 지원하는 Tekton Hub의 작업을 확인할 수 있습니다. 관리자는 Tekton Hub 통합을 옵트아웃할 수 있으며 Tekton Hub 작업은 더 이상 표시되지 않습니다. 생성된 파이프라인에 Webhook URL이 있는지 확인할 수도 있습니다. +추가 흐름을 사용하여 생성된 파이프라인에 대한 기본 Webhook가 추가되고, 해당 URL은 토폴로지 보기에서 선택한 리소스의 측면 패널에 표시됩니다.

자세한 내용은 개발자 화면을 사용하여 애플리케이션 생성을 참조하십시오.

3.10.3. 파이프라인을 포함하는 GitHub 리포지토리 추가

개발자 화면에서 파이프라인을 포함하는 GitHub 리포지토리를 OpenShift Container Platform 클러스터에 추가할 수 있습니다. 이를 통해 푸시 또는 가져오기 요청과 같은 관련 Git 이벤트가 트리거되면 클러스터의 GitHub 리포지토리에서 파이프라인 및 작업을 실행할 수 있습니다.

참고

퍼블릭 및 프라이빗 GitHub 리포지토리를 모두 추가할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자가 관리자 관점에서 필요한 GitHub 애플리케이션을 구성했는지 확인합니다.

프로세스

  1. 개발자 화면에서 GitHub 리포지토리를 추가할 네임스페이스 또는 프로젝트를 선택합니다.
  2. 왼쪽 탐색 창을 사용하여 Pipelines 로 이동합니다.
  3. 파이프라인 페이지 오른쪽에 있는 생성 → 리포지터리를 클릭합니다.
  4. Git Repo URL 을 입력하고 콘솔에서 리포지토리 이름을 자동으로 가져옵니다.

  5. 설정 옵션 표시를 클릭합니다. 기본적으로 웹 후크를 설정하는 옵션은 하나만 표시됩니다. GitHub 애플리케이션이 구성된 경우 다음 두 가지 옵션이 표시됩니다.

    • GitHub 앱 사용: 이 옵션을 선택하여 리포지토리에 GitHub 애플리케이션을 설치합니다.
    • 웹 후크 설정: GitHub 애플리케이션에 Webhook를 추가하려면 이 옵션을 선택합니다.

  6. Secret 섹션의 다음 옵션 중 하나를 사용하여 Webhook를 설정합니다.

    • Git 액세스 토큰 을 사용하여 Webhook를 설정합니다.

      1. 개인 액세스 토큰을 입력합니다.

      2. Webhook secret 필드에 해당하는 Generate 를 클릭하여 새 Webhook 보안을 생성합니다.

        Git 액세스 토큰
        참고

        개인 액세스 토큰이 없고 새 액세스 토큰을 생성하려는 경우 Git 액세스 토큰 필드 아래의 링크를 클릭할 수 있습니다.

    • Git 액세스 토큰 시크릿 을 사용하여 Webhook를 설정합니다.

      • 드롭다운 목록에서 네임스페이스에서 시크릿을 선택합니다. 선택한 보안에 따라 Webhook 보안이 자동으로 생성됩니다.

        Git 액세스 토큰 시크릿

  7. GitHub 리포지토리에 Webhook 시크릿 세부 정보를 추가합니다.

    1. Webhook URL 을 복사하고 GitHub 리포지토리 설정으로 이동합니다.
    2. Webhooks → Webhook 추가를 클릭합니다.
    3. 개발자 콘솔에서 Webhook URL 을 복사하여 GitHub 리포지토리 설정의 Payload URL 필드에 붙여넣습니다.
    4. 콘텐츠 유형을 선택합니다.
    5. 개발자 콘솔에서 Webhook 시크릿 을 복사하여 GitHub 리포지토리 설정의 Secret 필드에 붙여넣습니다.
    6. SSL 확인 옵션 중 하나를 선택합니다.
    7. 이 Webhook를 트리거할 이벤트를 선택합니다.
    8. Webhook 추가를 클릭합니다.
  8. 개발자 콘솔로 다시 이동하여 추가를 클릭합니다.
  9. 수행해야 하는 단계에 대한 세부 정보를 읽고 닫기 를 클릭합니다.
  10. 방금 생성한 리포지토리의 세부 정보를 확인합니다.
참고

Git에서 가져오기를 사용하여 애플리케이션을 가져오고 Git 리포지토리에 .tekton 디렉터리가 있는 경우 애플리케이션에 대한 pipelines-as-code 를 구성할 수 있습니다.

3.10.4. 개발자 화면을 사용하여 파이프라인과 상호 작용

개발자 화면의 파이프라인 보기에는 다음 세부 정보와 함께 프로젝트의 모든 파이프라인이 나열됩니다.

  • 파이프라인이 생성된 네임스페이스
  • 마지막 파이프라인 실행
  • 파이프라인 실행 시 작업 상태
  • 파이프라인 실행의 상태
  • 마지막 파이프라인 실행 생성 시간

프로세스

  1. 개발자 화면의 파이프라인 보기에서 프로젝트 드롭다운 목록에 있는 프로젝트를 선택하여 해당 프로젝트의 파이프라인을 확인합니다.

  2. 필요한 파이프라인을 클릭하여 파이프라인 세부 정보 페이지를 확인합니다.

    기본적으로 세부 정보 탭에는 모든 직렬 작업, 병렬 작업, finally 작업 및 파이프라인의 When 표현식의 시각적 표현이 표시됩니다. 작업 및 finally 작업은 페이지 오른쪽 하단 목록에 표시됩니다.

    작업 세부 정보를 보려면 나열된 Task 및 Finally 작업을 클릭합니다. 또한 다음을 수행할 수 있습니다.

    • 파이프라인 세부 정보 시각화의 왼쪽 아래에 표시된 표준 아이콘을 사용하여 확대/축소, 화면에 적합하며 보기 기능을 다시 설정합니다.
    • 마우스를 사용하여 파이프라인 시각화의 확대/축소 요인을 변경합니다.

    • 작업 위로 마우스를 이동하여 작업 세부 정보를 확인합니다.

      그림 3.3. 파이프 라인 세부 정보

      파이프 라인 세부 정보

  3. 선택 사항: 파이프 라인 세부 정보 페이지에서 Metrics 탭을 클릭하여 파이프라인에 대한 다음 정보를 확인합니다.

    • 파이프 라인 성공률
    • 파이프 라인 실행 수
    • 파이프 라인 실행 기간

    • 작업 실행 기간

      이 정보를 사용하여 파이프라인 라이프사이클 초기에 파이프라인 워크플로를 개선하고 문제를 제거할 수 있습니다.

  4. 선택 사항: YAML 탭을 클릭하여 파이프라인의 YAML 파일을 편집합니다.

  5. 선택 사항: 파이프라인 실행 탭을 클릭하여 파이프라인 실행 상태가 완료, 실행 중 또는 실패인지 확인합니다.

    파이프라인 실행 탭에는 파이프라인 실행, 작업 상태 및 실패한 파이프라인 실행 디버그 링크에 대한 세부 정보가 있습니다. 옵션 메뉴 kebab 를 사용하여 실행 중인 파이프라인을 중지하거나, 이전 파이프라인 실행과 동일한 매개변수 및 리소스를 사용하여 파이프라인을 재실행하거나, 파이프라인 실행을 삭제합니다.

    • 필요한 파이프라인 실행을 클릭하여 파이프라인 실행 세부 정보 페이지를 확인합니다. 기본적으로 세부 정보 탭에는 모든 직렬 작업, 병렬 작업, finally 작업 및 파이프라인 실행의 When 표현식의 시각적 표현이 표시됩니다. 성공적인 실행 결과는 페이지 하단의 파이프라인 실행 결과 창에 표시됩니다. 또한 클러스터에서 지원하는 Tekton Hub의 작업만 볼 수 있습니다. 작업을 보는 동안 해당 링크 옆에 있는 링크를 클릭하여 작업 문서로 이동할 수 있습니다.

      참고

      파이프라인 실행 세부 정보 페이지의 세부 정보 섹션에는 실패한 파이프라인 실행에 대한 로그 조각이 표시됩니다. 로그 조각에는 일반적인 오류 메시지와 해당 로그의 조각이 있습니다. 로그 섹션 링크를 사용하면 실패한 실행에 대한 세부 정보에 빠르게 액세스할 수 있습니다.

    • 파이프라인 실행 세부 정보 페이지에서 작업 실행 탭을 클릭하여 작업 상태가 완료, 실행 중 또는 실패인지 확인합니다.

      작업 실행 탭은 해당 작업 및 pod에 대한 링크, 작업 실행 상태 및 기간과 함께 작업 실행에 대한 정보를 제공합니다. 옵션 메뉴 kebab 를 사용하여 작업 실행을 삭제합니다.

    • 필요한 작업 실행을 클릭하여 작업 실행 세부 정보 페이지를 확인합니다. 성공적으로 실행된 결과는 페이지 하단에 있는 작업 실행 결과 창에 표시됩니다.

      참고

      작업 실행 세부 정보 페이지의 세부 정보 섹션에는 실패한 작업 실행에 대한 로그 조각이 표시됩니다. 로그 조각에는 일반적인 오류 메시지와 해당 로그의 조각이 있습니다. 로그 섹션 링크를 사용하면 실패한 작업 실행에 대한 세부 정보에 빠르게 액세스할 수 있습니다.

  6. 매개변수 탭을 클릭하여 파이프라인에 정의된 매개변수를 확인합니다. 필요에 따라 매개변수를 추가하거나 편집할 수도 있습니다.
  7. 리소스 탭을 클릭하여 파이프라인에 정의된 리소스를 확인합니다. 필요에 따라 리소스를 추가하거나 편집할 수도 있습니다.

3.10.5. Git 리포지토리에서 애플리케이션 생성 및 배포에 사용자 지정 파이프라인 템플릿 사용

클러스터 관리자는 Git 리포지토리에서 애플리케이션을 생성하고 배포하기 위해 Red Hat OpenShift Pipelines 1.5 이상에서 제공하는 기본 파이프라인 템플릿을 재정의하는 사용자 지정 파이프라인 템플릿을 사용할 수 있습니다.

참고

이 기능은 Red Hat OpenShift Pipelines 1.4 및 이전 버전에서 사용할 수 없습니다.

사전 요구 사항

Red Hat OpenShift Pipelines 1.5 이상이 설치되어 있고 모든 네임스페이스에서 사용할 수 있는지 확인합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.

  2. 관리자 화면에서 왼쪽 탐색 패널을 사용하여 파이프라인 섹션으로 이동합니다.

    1. 프로젝트 드롭다운 메뉴에서 openshift 프로젝트를 선택합니다. 이렇게 하면 후속 단계가 openshift 네임스페이스에서 수행됩니다.

    2. 사용 가능한 파이프라인 목록에서 애플리케이션을 빌드하고 배포하는 데 적합한 파이프라인을 선택합니다. 예를 들어 애플리케이션에 node.js 런타임 환경이 필요한 경우 s2i-nodejs 파이프라인을 선택합니다.

      참고

      기본 파이프라인 템플릿을 편집하지 마십시오. UI 및 백엔드와 호환되지 않을 수 있습니다.

    3. 선택한 파이프라인의 YAML 탭에서 YAML 파일을 다운로드하여 로컬 시스템에 저장합니다. 사용자 지정 구성 파일에 오류가 발생하면 이 복사본을 사용하여 작동 중인 구성을 복원할 수 있습니다.

  3. 기본 파이프라인 템플릿을 비활성화(삭제)합니다.

    1. 왼쪽 탐색 패널을 사용하여 Operator → 설치된 Operator로 이동합니다.
    2. Red Hat OpenShift Pipelines → Tekton Configuration 탭 → config → YAML 탭을 클릭합니다.

    3. openshift 네임스페이스에서 기본 파이프라인 템플릿을 비활성화(삭제)하려면 TektonConfig 사용자 지정 리소스 YAML에서 pipelineTemplates 매개변수를 false로 설정하고 저장합니다. 

      apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
profile: all
targetNamespace: openshift-pipelines
addon:
  params:
  - name: clusterTasks
    value: "true"
  - name: pipelineTemplates
    value: "false"
...
      참고

      기본 파이프라인 템플릿을 수동으로 삭제하는 경우 Operator는 업그레이드 중에 기본값을 복원합니다.

      주의

      클러스터 관리자는 Operator 구성에서 기본 파이프라인 템플릿 설치를 비활성화할 수 있습니다. 그러나 이러한 구성은 사용자 지정하려는 템플릿뿐만 아니라 모든 기본 파이프라인 템플릿을 삭제합니다.

  4. 사용자 정의 파이프라인 템플릿을 생성합니다.

    1. 왼쪽 탐색 패널을 사용하여 파이프라인 섹션으로 이동합니다.
    2. 생성 드롭다운 메뉴에서 파이프라인을 선택합니다.

    3. openshift 네임스페이스에 필요한 파이프라인을 생성합니다. 기본 이름(예: custom-nodejs)과는 다른 이름을 지정합니다. 다운로드한 기본 파이프라인 템플릿을 시작점으로 사용하고 사용자 지정할 수 있습니다.

      참고

      openshift는 Operator가 설치한 파이프라인 템플릿에서 사용하는 기본 네임스페이스이므로 openshift 네임스페이스에서 사용자 지정 파이프라인 템플릿을 생성해야 합니다. 애플리케이션에서 파이프라인 템플릿을 사용하면 템플릿이 해당 프로젝트의 네임스페이스에 자동으로 복사됩니다.

    4. 생성된 파이프라인의 세부 정보 탭에서 사용자 지정 템플릿의 레이블이 기본 파이프라인의 레이블과 일치하는지 확인합니다. 사용자 지정 파이프라인 템플릿에는 애플리케이션의 런타임, 유형 및 전략에 대한 올바른 레이블이 있어야 합니다. 예를 들어 OpenShift Container Platform에 배포된 node.js 애플리케이션의 필수 레이블은 다음과 같습니다. 

      ...
pipeline.openshift.io/runtime: nodejs
pipeline.openshift.io/type: openshift
...
      참고

      런타임 환경 및 배포 유형의 각 조합에 대해 하나의 파이프라인 템플릿만 사용할 수 있습니다.

  5. 개발자 화면에서 +추가 → Git 리포지토리 → Git에서 옵션을 사용하여 생성 및 배포할 애플리케이션 유형을 선택합니다. 애플리케이션의 필수 런타임 및 유형에 따라 사용자 지정 템플릿이 자동으로 선택됩니다.

3.10.6. Pipelines 보기에서 파이프라인 시작

파이프라인을 생성한 후 포함된 작업을 정의된 순서로 실행하려면 파이프라인을 시작해야 합니다. 파이프라인 보기, 파이프라인 세부 정보 페이지 또는 토폴로지 보기에서 파이프라인을 시작할 수 있습니다.

절차

파이프라인 보기를 사용하여 파이프라인을 시작하려면 다음을 수행합니다.

  1. 개발자 화면의 Pipelines 보기에서 파이프라인 옆에 있는 Options kebab 메뉴를 클릭하고 시작을 선택합니다.

  2. 파이프라인 정의에 따라 파이프라인 시작 대화 상자에 Git 리소스 및 이미지 리소스가 표시됩니다.

    참고

    Git에서 옵션을 사용하여 생성한 파이프라인의 경우 파이프라인 시작 대화 상자의 매개변수 섹션에 APP_NAME 필드도 표시되며, 대화 상자의 모든 필드가 파이프라인 템플릿에 의해 미리 채워집니다.

    1. 네임스페이스에 리소스가 있는 경우 Git Resources 및 Image Resources 필드에 해당 리소스가 미리 채워집니다. 필요한 경우 드롭다운 목록을 사용하여 필요한 리소스를 선택하거나 생성한 다음 파이프라인 실행 인스턴스를 사용자 정의합니다.

  3. 선택 사항: 고급 옵션을 수정하여 지정된 프라이빗 Git 서버 또는 이미지 레지스트리를 인증하는 자격 증명을 추가합니다.

    1. Advanced Options에서 Show Credentials Options를 클릭하고 Add Secret을 선택합니다.

    2. Create Source Secre 섹션에서 다음 사항을 지정합니다.

      1. 보안에 대한 고유한 보안 이름입니다.
      2. Designated provider to be authenticated 섹션에서 Access to 필드에 인증할 공급자를 지정하고 기본 Server URL을 지정합니다.

      3. Authentication Type을 선택하고 자격 증명을 제공합니다.

        • 인증 유형 Image Registry Crendentials의 경우 인증할 레지스트리 서버 주소를 지정하고 사용자 이름, 암호, 이메일 필드에 자격 증명을 제공합니다.

          추가 Registry Server Address를 지정하려면 Add Credentials를 선택하십시오.

        • Authentication Type Basic Authentication의 경우 UserName 및 Password or Token 필드 값을 지정합니다.

        • 인증 유형 SSH Keys의 경우 SSH 개인 키 필드 값을 지정합니다.

          참고

          기본 인증 및 SSH 인증의 경우 다음과 같은 주석을 사용할 수 있습니다.

      4. 확인 표시를 선택하여 보안을 추가합니다.

    파이프라인의 리소스 수에 따라 여러 개의 보안을 추가할 수 있습니다.

  4. 시작을 클릭하여 파이프라인을 시작합니다.

  5. PipelineRun 세부 정보 페이지에 실행 중인 파이프라인이 표시됩니다. 파이프라인이 시작된 후 작업과 각 작업 내 단계가 실행됩니다. 다음을 수행할 수 있습니다.

    • PipelineRun 세부 정보 페이지 시각화의 왼쪽 아래에 있는 표준 아이콘을 사용하여 확대/축소, 화면에 적합하며 보기 기능을 재설정합니다.
    • 마우스를 사용하여 pipelinerun 시각화의 확대/축소 비율을 변경합니다. 특정 확대/축소 요인에서 작업의 배경색이 변경되어 오류 또는 경고 상태를 나타냅니다.
    • 작업 위로 커서를 이동하여 각 단계, 작업 이름, 작업 상태를 실행하는 데 걸린 시간과 같은 세부 정보를 확인합니다.
    • 작업 배지 위로 커서를 이동하여 완료된 총 작업 수 및 작업 수를 확인합니다.
    • 작업을 클릭하여 각 작업 단계에 대한 로그를 확인합니다.
    • 로그 탭을 클릭하여 작업 실행 순서와 관련된 로그를 확인합니다. 관련 버튼을 사용하여 창을 확장하고 로그를 개별적 또는 일괄적으로 다운로드할 수도 있습니다.

    • 이벤트 탭을 클릭하여 파이프라인 실행으로 생성된 이벤트 스트림을 확인합니다.

      작업 실행, 로그, 이벤트 탭을 사용하면 실패한 파이프라인 실행 또는 실패한 작업 실행을 디버깅하는 데 도움이 될 수 있습니다.

      그림 3.4. ‘파이프 라인 실행' 세부 정보

      ‘파이프 라인 실행' 세부 정보

3.10.7. 토폴로지 보기에서 파이프라인 시작

Git에서 옵션을 사용하여 생성한 파이프라인의 경우 토폴로지 보기를 사용하여 파이프라인을 시작한 후 상호 작용할 수 있습니다.

참고

토폴로지 보기에서 파이프라인 빌더를 사용하여 생성한 파이프라인 을 보려면 파이프라인 레이블을 사용자 정의하여 파이프라인을 애플리케이션 워크로드에 연결합니다.

절차

  1. 왼쪽 탐색 패널에서 Topology 를 클릭합니다.
  2. 애플리케이션을 클릭하여 측면 패널에 파이프라인 실행 을 표시합니다.

  3. 파이프라인 실행 에서 마지막 실행 시작을 클릭하여 이전 파이프라인과 동일한 매개변수 및 리소스로 새 파이프라인 실행을 시작합니다. 파이프라인 실행이 시작되지 않은 경우 이 옵션이 비활성화되어 있습니다. 파이프라인 실행을 생성할 때 실행할 수도 있습니다.

    그림 3.5. 토폴로지 보기의 파이프라인

    토폴로지 보기의 파이프라인

토폴로지 페이지에서 애플리케이션 왼쪽으로 커서를 이동하여 파이프라인 실행 상태를 확인합니다. 파이프라인이 추가되면 왼쪽 하단 아이콘은 연결된 파이프라인이 있음을 나타냅니다.

3.10.8. 토폴로지 보기에서 파이프라인과 상호 작용

토폴로지 페이지에 있는 애플리케이션 노드의 측면 패널에 파이프라인 실행의 상태가 표시되고 상호 작용할 수 있습니다.

  • 파이프라인 실행이 자동으로 시작되지 않으면 측면 패널에 파이프라인을 자동으로 시작할 수 없는 메시지가 표시됩니다. 따라서 수동으로 시작해야 합니다.
  • 파이프라인이 생성되었지만 사용자가 파이프라인을 시작하지 않은 경우 해당 상태가 시작되지 않습니다. 사용자가 Not started (시작되지 않음) 상태 아이콘을 클릭하면 Topology (토폴로지) 보기에서 시작 대화 상자가 열립니다.
  • 파이프라인에 빌드 또는 빌드 구성이 없는 경우 Builds 섹션이 표시되지 않습니다. 파이프라인 및 빌드 구성이 있는 경우 빌드 섹션이 표시됩니다.
  • 파이프라인 실행이 특정 작업 실행에서 실패하면 측면 패널에 로그 조각이 표시됩니다. 로그 조각은 리소스 탭의 파이프라인 실행 섹션에서 확인할 수 있습니다. 일반 오류 메시지와 로그 스니펫을 제공합니다. 로그 섹션 링크를 사용하면 실패한 실행에 대한 세부 정보에 빠르게 액세스할 수 있습니다.

3.10.9. 파이프라인 편집

웹 콘솔의 개발자 화면을 사용하여 클러스터의 파이프라인을 편집할 수 있습니다.

절차

  1. 개발자 화면의 파이프라인 보기에서 편집할 파이프라인을 선택하여 파이프라인의 세부 정보를 확인합니다. Pipeline Details 페이지에서 Actions를 클릭하고 Edit Pipelin을 선택합니다.

  2. Pipeline 빌더 페이지에서 다음 작업을 수행할 수 있습니다.

    • 파이프라인에 추가 작업, 매개변수 또는 리소스를 추가합니다.
    • 수정할 작업을 클릭하여 측면 패널에서 작업 세부 정보를 확인하고 표시 이름, 매개변수 및 리소스와 같은 필요한 작업 세부 정보를 수정합니다.
    • 또는 작업을 삭제하려면 작업을 클릭하고 측면 패널에서 Actions 를 클릭하고 Remove Task 를 선택합니다.
  3. Save 를 클릭하여 수정된 파이프라인을 저장합니다.

3.10.10. 파이프라인 삭제

웹 콘솔의 개발자 화면을 사용하여 클러스터의 파이프라인을 삭제할 수 있습니다.

절차

  1. 개발자 화면의 Pipelines 보기에서 Pipeline 옆에 있는 Options kebab 메뉴를 클릭하고 Delete Pipeline 을 선택합니다.
  2. Delete Pipeline 확인 프롬프트에서 Delete를 클릭하여 삭제를 확인합니다.

3.10.11. 추가 리소스

3.11. TektonConfig 사용자 정의 리소스에서 구성 사용자 정의

Red Hat OpenShift Pipelines에서는 TektonConfig CR(사용자 정의 리소스)을 사용하여 다음 구성을 사용자 지정할 수 있습니다.

  • Red Hat OpenShift Pipelines Control Plane 구성
  • 기본 서비스 계정 변경
  • 서비스 모니터 비활성화
  • 파이프라인 확인기 구성
  • 클러스터 작업 및 파이프라인 템플릿 비활성화
  • Tekton Hub 통합 비활성화
  • RBAC 리소스의 자동 생성 비활성화
  • 작업 실행 및 파이프라인 실행 정리

3.11.1. 사전 요구 사항

  • Red Hat OpenShift Pipelines Operator가 설치되어 있습니다.

3.11.2. Red Hat OpenShift Pipelines Control Plane 구성

TektonConfig CR(사용자 정의 리소스)에서 구성 필드를 편집하여 OpenShift Pipelines 컨트롤 플레인을 사용자 지정할 수 있습니다. Red Hat OpenShift Pipelines Operator는 OpenShift Pipelines 컨트롤 플레인을 사용할 수 있도록 기본값을 사용하여 구성 필드를 자동으로 추가합니다.

절차

  1. 웹 콘솔의 관리자 화면에서 Administration → CustomResourceDefinitions 로 이동합니다.
  2. 이름으로 검색 상자를 사용하여 tektonconfigs.operator.tekton.dev CRD(사용자 정의 리소스 정의)를 검색합니다. TektonConfig 를 클릭하여 CRD 세부 정보 페이지를 확인합니다.
  3. Instances 탭을 클릭합니다.
  4. config 인스턴스를 클릭하여 TektonConfig CR 세부 정보를 확인합니다.
  5. YAML 탭을 클릭합니다.

  6. 요구 사항에 따라 TektonConfig YAML 파일을 편집합니다.

    기본값이 있는 TektonConfig CR의 예

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    running-in-environment-with-injected-sidecars: true
    metrics.taskrun.duration-type: histogram
    metrics.pipelinerun.duration-type: histogram
    await-sidecar-readiness: true
    params:
      - name: enableMetrics
        value: 'true'
    default-service-account: pipeline
    require-git-ssh-secret-known-hosts: false
    enable-tekton-oci-bundles: false
    metrics.taskrun.level: task
    metrics.pipelinerun.level: pipeline
    enable-api-fields: stable
    enable-provenance-in-status: false
    enable-custom-tasks: true
    disable-creds-init: false
    disable-affinity-assistant: true

3.11.2.1. 기본값을 사용하여 수정 가능한 필드

다음 목록에는 TektonConfig CR에 기본값이 있는 모든 수정 가능한 필드가 포함되어 있습니다.

  • running-in-environment-with-injected-sidecars (기본값: true): Istio와 같은 삽입된 사이드카를 사용하지 않는 클러스터에서 파이프라인이 실행되는 경우 이 필드를 false 로 설정합니다. false 로 설정하면 파이프라인이 작업 실행을 시작하는 데 걸리는 시간이 줄어듭니다.

    참고

    삽입된 사이드카를 사용하는 클러스터의 경우 이 필드를 false 로 설정하면 예기치 않은 동작이 발생할 수 있습니다.

  • await-sidecar-readiness (기본값: true): OpenShift Pipelines가 작동을 시작하기 전에 TaskRun 사이드카 컨테이너가 실행될 때까지 대기하지 못하도록 이 필드를 false 로 설정합니다. 이를 통해 DownwardAPI 볼륨 유형을 지원하지 않는 환경에서 작업을 실행할 수 있습니다.
  • default-service-account (기본값: pipeline): 이 필드에는 TaskRun 및 PipelineRun 리소스에 사용할 기본 서비스 계정 이름이 포함되어 있습니다.

  • require-git-ssh-secret-known-hosts (기본값: false): 이 필드를 true 로 설정하려면 Git SSH 시크릿에 known_hosts 필드를 포함해야 합니다.

    • Git SSH 시크릿 구성에 대한 자세한 내용은 추가 리소스 섹션에서 Git에 대한 SSH 인증 구성 을 참조하십시오.
  • enable-tekton-oci-bundles (기본값: false): Tekton OCI 번들이라는 실험적인 알파 기능을 사용할 수 있도록 이 필드를 true 로 설정합니다.

  • enable-api-fields (기본값: stable): 이 필드를 설정하면 활성화된 기능이 결정됩니다. 허용 가능한 값은 stable,beta 또는 alpha 입니다.

    참고

    Red Hat OpenShift Pipelines는 알파 값을 지원하지 않습니다.

  • enable-provenance-in-status (기본값: false): TaskRun 및 PipelineRun 상태의 검증 필드를 채울 수 있도록 이 필드를 true 로 설정합니다. provenance 필드에 는 원격 작업 또는 파이프라인 정의가 가져온 소스의 소스와 같이 작업 실행 및 파이프라인 실행에 사용되는 리소스에 대한 메타데이터가 포함되어 있습니다.
  • enable-custom-tasks (기본값: true): 파이프라인에서 사용자 지정 작업 사용을 비활성화하려면 이 필드를 false 로 설정합니다.
  • disable-creds-init (기본값: false): OpenShift Pipelines에서 연결된 서비스 계정을 스캔하고 단계에 인증 정보를 삽입하지 못하도록 이 필드를 true 로 설정합니다.
  • disable-affinity-assistant (기본값: true): 영구 볼륨 클레임 작업 공간을 공유하는 각 TaskRun 리소스의 선호도 도우미를 활성화하려면 이 필드를 false 로 설정합니다.

메트릭 옵션

TektonConfig CR에서 다음 메트릭 필드의 기본값을 수정할 수 있습니다.

  • metrics.taskrun.duration-type 및 metrics.pipelinerun.duration-type (기본값: 히스토그램): 이러한 필드를 설정하면 작업 또는 파이프라인 실행의 기간 유형이 결정됩니다. 허용 가능한 값은 게이지 또는 히스토그램입니다.
  • metrics.taskrun.level (기본값: 작업): 이 필드는 작업 실행 메트릭의 수준을 결정합니다. 허용 가능한 값은 taskrun,task 또는 namespace 입니다.
  • metrics.pipelinerun.level (기본값: pipeline): 이 필드는 파이프라인 실행 메트릭의 수준을 결정합니다. 허용되는 값은 pipelinerun,pipeline 또는 namespace 입니다.

3.11.2.2. 선택적 구성 필드

다음 필드에는 기본값이 없으며 구성하는 경우에만 간주됩니다. 기본적으로 Operator는 TektonConfig CR(사용자 정의 리소스)에서 이러한 필드를 추가하고 구성하지 않습니다.

  • default-timeout-minutes: 이 필드는 생성할 때 지정되지 않은 경우 TaskRun 및 PipelineRun 리소스에 대한 기본 시간 초과를 설정합니다. 작업 실행 또는 파이프라인 실행이 설정된 시간(분)보다 더 많은 시간이 걸리면 작업 실행 또는 파이프라인 실행이 시간 초과되고 취소됩니다. 예를 들어 default-timeout-minutes: 60 은 60분을 기본값으로 설정합니다.
  • default-managed-by-label-value: 이 필드에는 모든 TaskRun Pod에 적용되는 app.kubernetes.io/managed-by 라벨에 지정된 기본값이 포함되어 있습니다. 예: default-managed-by-label-value: tekton-pipelines.
  • default-pod-template: 이 필드는 지정되지 않은 경우 기본 TaskRun 및 PipelineRun Pod 템플릿을 설정합니다.
  • default-cloud-events-sink: 이 필드는 지정되지 않은 경우 TaskRun 및 PipelineRun 리소스에 사용되는 기본 CloudEvents 싱크를 설정합니다.
  • default-task-run-workspace-binding: 이 필드에는 Task 리소스에서 선언하는 작업 공간에 대한 기본 작업 공간 구성이 포함되어 있지만 TaskRun 리소스는 명시적으로 선언하지 않습니다.
  • default-affinity-assistant-pod-template: 이 필드는 유사성 도우미 Pod에 사용되는 기본 PipelineRun Pod 템플릿을 설정합니다.
  • default-max-matrix-combinations-count: 이 필드에는 매트릭스에서 생성된 기본 최대 조합 수가 포함됩니다.

3.11.3. OpenShift Pipelines의 기본 서비스 계정 변경

.spec.pipeline 및 .spec.trigger 사양에서 default-service-account 필드를 편집하여 OpenShift Pipelines의 기본 서비스 계정을 변경할 수 있습니다. 기본 서비스 계정 이름은 pipeline 입니다.

예제

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    default-service-account: pipeline
  trigger:
    default-service-account: pipeline
    enable-api-fields: stable

3.11.4. 서비스 모니터 비활성화

OpenShift Pipelines의 일부인 서비스 모니터를 비활성화하여 Telemetry 데이터를 노출할 수 있습니다. 서비스 모니터를 비활성화하려면 TektonConfig CR(사용자 정의 리소스)의 .spec.pipeline 사양에서 enableMetrics 매개변수를 false 로 설정합니다.

예제

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    params:
       - name: enableMetrics
         value: 'false'

3.11.5. 파이프라인 확인기 구성

TektonConfig CR(사용자 정의 리소스)에서 파이프라인 해석기를 구성할 수 있습니다. 이러한 파이프라인 확인기를 활성화하거나 비활성화할 수 있습니다.

  • enable-bundles-resolver
  • enable-cluster-resolver
  • enable-git-resolver
  • enable-hub-resolver

예제

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    enable-bundles-resolver: true
    enable-cluster-resolver: true
    enable-git-resolver: true
    enable-hub-resolver: true

TektonConfig CR에 해결자 특정 구성을 제공할 수도 있습니다. 예를 들어 map[string]string 형식으로 다음 필드를 정의하여 각 파이프라인 확인자에 대한 구성을 설정합니다.

예제

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  pipeline:
    bundles-resolver-config:
      default-service-account: pipelines
    cluster-resolver-config:
      default-namespace: test
    git-resolver-config:
      server-url: localhost.com
    hub-resolver-config:
      default-tekton-hub-catalog: tekton

3.11.6. 클러스터 작업 및 파이프라인 템플릿 비활성화

기본적으로 TektonAddon CR(사용자 정의 리소스)은 클러스터의 OpenShift Pipelines와 함께 clusterTasks 및 pipelineTemplates 리소스를 설치합니다.

.spec.addon 사양에서 매개변수 값을 false 로 설정하여 clusterTasks 및 pipelineTemplates 리소스 설치를 비활성화할 수 있습니다. 또한 communityClusterTasks 매개변수를 비활성화할 수 있습니다.

예제

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  addon:
    params:
      - name: clusterTasks
        value: 'false'
      - name: pipelineTemplates
        value: 'false'
      - name: communityClusterTasks
        value: 'true'

3.11.7. Tekton Hub 통합 비활성화

TektonConfig CR(사용자 정의 리소스)에서 enable-devconsole-integration 매개변수를 false 로 설정하여 웹 콘솔 개발자 화면에서 Tekton Hub의 통합을 비활성화할 수 있습니다.

Tekton Hub 비활성화 예

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  hub:
    params:
      - name: enable-devconsole-integration
        value: false

3.11.8. RBAC 리소스의 자동 생성 비활성화

Red Hat OpenShift Pipelines Operator의 기본 설치는 ^(openshift|kube)-* 정규식 패턴과 일치하는 네임스페이스를 제외하고 클러스터의 모든 네임스페이스에 대해 여러 개의 RBAC(역할 기반 액세스 제어) 리소스를 생성합니다. 이러한 RBAC 리소스 중에서 pipelines-scc-rolebinding SCC(보안 컨텍스트 제약 조건) 역할 바인딩 리소스는 연결된 pipelines-scc SCC에 RunAsAny 권한이 있으므로 잠재적인 보안 문제입니다.

Red Hat OpenShift Pipelines Operator가 설치된 후 클러스터 전체 RBAC 리소스의 자동 생성을 비활성화하려면 클러스터 관리자가 클러스터 수준 TektonConfig CR(사용자 정의 리소스)에서 createRbacResource 매개변수를 false 로 설정할 수 있습니다.

TektonConfig CR의 예

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  params:
  - name: createRbacResource
    value: "false"
...

주의

클러스터 관리자 또는 적절한 권한이 있는 사용자는 모든 네임스페이스에 대한 RBAC 리소스 자동 생성을 비활성화하면 기본 ClusterTask 리소스가 작동하지 않습니다. ClusterTask 리소스가 작동하려면 의도한 각 네임스페이스에 대해 RBAC 리소스를 수동으로 생성해야 합니다.

3.11.9. 작업 실행 및 파이프라인 실행 자동 정리

오래된 TaskRun 및 PipelineRun 오브젝트와 실행된 인스턴스는 활성 실행에 사용할 수 있는 물리적 리소스를 차지합니다. 이러한 리소스를 최적으로 사용하기 위해 Red Hat OpenShift Pipelines는 다양한 네임스페이스에서 사용하지 않는 오브젝트와 해당 인스턴스를 자동으로 제거하는 정리기 구성 요소를 제공합니다.

참고

TektonConfig 사용자 정의 리소스를 사용하여 전체 설치에 대한 정리기를 구성하고 네임스페이스 주석을 사용하여 네임스페이스 구성을 수정할 수 있습니다. 그러나 네임스페이스에서 개별 작업 실행 또는 파이프라인 실행을 선택적으로 자동 실행할 수 없습니다.

3.11.9.1. pruner 구성

TektonConfig 사용자 지정 리소스를 사용하여 파이프라인 실행 및 작업 실행과 관련된 리소스의 주기적 정리를 구성할 수 있습니다.

다음 예제는 기본 구성에 해당합니다.

정리기 구성의 예

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
# ...
spec:
  pruner:
    resources:
      - taskrun
      - pipelinerun
    keep: 100
    prune-per-resource: false
    schedule: "* 8 * * *"
# ...

표 3.18. 정리기 구성에 지원되는 매개변수

매개변수설명

스케줄

정리 프로세스 실행을 위한 Cron 스케줄입니다. 기본 일정은 매일 08:00에 프로세스를 실행합니다. Cron 일정 구문에 대한 자세한 내용은 Kubernetes 문서의 Cron schedule 구문을 참조하십시오.

resources

pruner가 적용되는 리소스 유형입니다. 사용 가능한 리소스 유형은 taskrun 및 pipelinerun입니다.

keep

유지할 모든 유형의 최근 리소스 수입니다.

prune-per-resource

false 로 설정하면 keep 매개변수의 값이 총 작업 실행 또는 파이프라인 실행 수를 나타냅니다. 예를 들어 keep 가 100 으로 설정된 경우 pruner는 최신 작업 실행 및 100개의 최신 파이프라인 실행과 기타 모든 리소스를 제거합니다.

true 로 설정하면 각 파이프라인을 참조하는 파이프라인 실행과 각 작업을 참조하는 작업 실행에 대해 keep 매개변수의 값이 별도로 계산됩니다. 예를 들어 keep 가 100 으로 설정된 경우 pruner는 Pipeline1 에 대해 최신 파이프라인 실행 100개, Pipeline2 용 최신 파이프라인 실행, Task1 에 대한 최신 작업 실행 100개를 유지하고 다른 모든 리소스를 제거합니다.

keep-since

리소스를 유지할 최대 시간(분)입니다. 예를 들어 5일 전에 생성된 리소스를 유지하려면 keep-since 를 7200 으로 설정합니다.

참고

keep 및 keep-since 매개변수는 함께 사용할 수 없습니다. 구성에 해당 중 하나만 사용합니다.

3.11.9.2. 작업 실행 및 파이프라인 실행을 자동으로 정리하기 위한 주석

네임스페이스에서 작업 실행 및 파이프라인 실행 자동 정리 구성을 수정하려면 네임스페이스에 주석을 설정할 수 있습니다.

다음 namespace 주석은 TektonConfig 사용자 정의 리소스의 해당 키와 동일한 의미를 갖습니다.

  • operator.tekton.dev/prune.schedule
  • operator.tekton.dev/prune.resources
  • operator.tekton.dev/prune.keep
  • operator.tekton.dev/prune.prune-per-resource
  • operator.tekton.dev/prune.keep-since
참고

operator.tekton.dev/prune.resources 주석은 쉼표로 구분된 목록을 허용합니다. 작업 실행 및 파이프라인 실행을 모두 정리하려면 이 주석을 "taskrun, pipelinerun" 으로 설정합니다.

다음과 같은 추가 네임스페이스 주석을 사용할 수 있습니다.

  • operator.tekton.dev/prune.skip: true 로 설정하면 주석이 구성된 네임스페이스가 정리되지 않습니다.
  • operator.tekton.dev/prune.strategy: 이 주석의 값을 keep 또는 keep-since 로 설정합니다.

예를 들어 다음 주석은 지난 5일 동안 생성된 모든 작업 실행 및 파이프라인 실행을 유지하고 이전 리소스를 삭제합니다.

자동 실행 주석의 예

kind: Namespace
apiVersion: v1
# ...
spec:
  annotations:
    operator.tekton.dev/prune.resources: "taskrun, pipelinerun"
    operator.tekton.dev/prune.keep-since: 7200
# ...

3.11.10. 추가 리소스

3.12. OpenShift Pipelines의 리소스 사용량 감소

멀티 테넌트 환경에서 클러스터를 사용하는 경우 각 프로젝트 및 Kubernetes 오브젝트에 대한 CPU, 메모리 및 스토리지 리소스의 사용을 제어해야 합니다. 따라서 하나의 애플리케이션이 너무 많은 리소스를 소비하고 다른 애플리케이션에 영향을 주지 않도록 방지할 수 있습니다.

결과 pod에 설정된 최종 리소스 제한을 정의하기 위해 Red Hat OpenShift Pipelines는 리소스 할당량 제한 및 해당 Pod가 실행되는 프로젝트의 제한 범위를 사용합니다.

프로젝트의 리소스 사용을 제한하려면 다음을 수행할 수 있습니다.

3.12.1. 파이프라인에서 리소스 사용 이해

각 작업은 Task 리소스의 steps 필드에 정의된 특정 순서로 실행하는 데 필요한 여러 단계로 구성됩니다. 모든 작업은 Pod로 실행되고 각 단계는 해당 Pod 내에서 컨테이너로 실행됩니다.

단계는 한 번에 하나씩 실행됩니다. 작업을 실행하는 Pod는 한 번에 작업에서 단일 컨테이너 이미지(단계)를 실행하기에 충분한 리소스만 요청하므로 작업의 모든 단계에 대한 리소스를 저장하지 않습니다.

spec 단계의 Resources 필드는 리소스 소비에 대한 제한을 지정합니다. 기본적으로 CPU, 메모리, 임시 스토리지에 대한 리소스 요청은 BestEffort (zero) 값으로 설정되거나 해당 프로젝트에서 제한 범위를 통해 설정된 최소값으로 설정됩니다.

리소스 요청 구성 및 단계 제한의 예

spec:
  steps:
  - name: <step_name>
    resources:
      requests:
        memory: 2Gi
        cpu: 600m
      limits:
        memory: 4Gi
        cpu: 900m

LimitRange 매개변수 및 컨테이너 리소스 요청에 대한 최소 값이 Pipeline 및 작업을 실행하는 프로젝트에 지정되면 Red Hat OpenShift Pipelines는 프로젝트의 모든 LimitRange 값을 살펴보고 0 대신 최소 값을 사용합니다.

프로젝트 수준에서 제한 범위 매개변수 구성 예

apiVersion: v1
kind: LimitRange
metadata:
  name: <limit_container_resource>
spec:
  limits:
  - max:
      cpu: "600m"
      memory: "2Gi"
    min:
      cpu: "200m"
      memory: "100Mi"
    default:
      cpu: "500m"
      memory: "800Mi"
    defaultRequest:
      cpu: "100m"
      memory: "100Mi"
    type: Container
...

3.12.2. 파이프라인에서 추가 리소스 소비 완화

Pod의 컨테이너에 리소스 제한이 설정된 경우 OpenShift Container Platform은 모든 컨테이너가 동시에 실행될 때 요청된 리소스 제한을 합계합니다.

호출된 작업에서 한 번에 한 단계를 실행하는 데 필요한 최소 리소스 양을 사용하기 위해 Red Hat OpenShift Pipelines는 가장 많은 리소스 양이 필요한 단계에 지정된 대로 최대 CPU, 메모리 및 임시 스토리지를 요청합니다. 이렇게 하면 모든 단계의 리소스 요구 사항이 충족됩니다. 최대 값 이외의 요청은 0으로 설정됩니다.

그러나 이 동작으로 인해 리소스 사용량이 필요 이상으로 증가할 수 있습니다. 리소스 할당량을 사용하는 경우 Pod를 예약할 수 없게 될 수도 있습니다.

예를 들어 스크립트를 사용하고 리소스 제한과 요청을 정의하지 않는 두 단계로 이루어진 작업을 살펴보겠습니다. 결과 pod에는 두 개의 init 컨테이너(한 개는 진입점 복사용, 다른 하나는 스크립트 작성용)와 두 개의 컨테이너(단계 당 하나씩)가 있습니다.

OpenShift Container Platform은 프로젝트에 필요한 리소스 요청 및 제한을 계산하기 위해 설정된 제한 범위를 사용합니다. 이 예에서는 프로젝트에서 다음 제한 범위를 설정합니다. 

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-min-max-demo-lr
spec:
  limits:
  - max:
      memory: 1Gi
    min:
      memory: 500Mi
    type: Container

이 시나리오에서 각 init 컨테이너는 1Gi의 요청 메모리 (제한 범위의 최대 제한)를 사용하고 각 컨테이너는 500Mi의 요청 메모리를 사용합니다. 따라서 Pod의 총 메모리 요청은 2Gi입니다.

10단계의 작업에 동일한 제한 범위를 사용하는 경우 최종 메모리 요청은 5Gi로 각 단계에서 실제로 필요한 것보다 높은 500Mi입니다 (각 단계가 차례로 실행되기 때문).

따라서 리소스의 리소스 사용량을 줄이기 위해 다음을 수행할 수 있습니다.

  • 스크립트 기능 및 동일한 이미지를 사용하여 서로 다른 단계를 한 단계로 그룹화하여 지정된 작업의 단계 수를 줄입니다. 이렇게 하면 요청된 최소 리소스가 줄어듭니다.
  • 서로 상대적으로 독립적이며 자체적으로 실행할 수 있는 단계를 단일 작업 대신 여러 작업에 분산합니다. 이렇게 하면 각 작업의 단계 수가 줄어들어 각 작업에 대한 요청이 줄어들며, 리소스가 사용 가능할 때 스케줄러가 해당 단계를 실행할 수 있습니다.

3.12.3. 추가 리소스

3.13. OpenShift Pipelines에 대한 컴퓨팅 리소스 할당량 설정

Red Hat OpenShift Pipelines의 ResourceQuota 오브젝트는 네임스페이스당 총 리소스 사용량을 제어합니다. 이를 사용하여 오브젝트 유형에 따라 네임스페이스에서 생성된 오브젝트 수를 제한할 수 있습니다. 또한 컴퓨팅 리소스 할당량을 지정하여 네임스페이스에서 소비되는 총 컴퓨팅 리소스 양을 제한할 수 있습니다.

그러나 전체 네임스페이스에 할당량을 설정하지 않고 파이프라인 실행으로 인해 Pod에서 사용하는 컴퓨팅 리소스의 양을 제한할 수 있습니다. 현재 Red Hat OpenShift Pipelines에서는 파이프라인에 대한 컴퓨팅 리소스 할당량을 직접 지정할 수 없습니다.

3.13.1. OpenShift Pipelines에서 컴퓨팅 리소스 사용을 제한하는 대체 방법

파이프라인에서 컴퓨팅 리소스 사용에 대한 어느 정도 제어하려면 다음과 같은 대체 방법을 고려하십시오.

  • 작업의 각 단계에 대한 리소스 요청 및 제한을 설정합니다.

    예: 작업의 각 단계에 대한 리소스 요청 및 제한 설정.

    ...
spec:
  steps:
    - name: step-with-limts
      resources:
        requests:
          memory: 1Gi
          cpu: 500m
        limits:
          memory: 2Gi
          cpu: 800m
...

  • LimitRange 오브젝트의 값을 지정하여 리소스 제한을 설정합니다. LimitRange 에 대한 자세한 내용은 제한 범위가 있는 리소스 사용 제한에서 참조하십시오.
  • 파이프라인 리소스 사용량을 줄입니다.
  • 프로젝트당 리소스 할당량을 설정하고 관리합니다.
  • 파이프라인의 컴퓨팅 리소스 할당량은 파이프라인 실행에서 동시에 실행 중인 Pod에서 사용하는 총 컴퓨팅 리소스 할당량과 동일해야 합니다. 그러나 작업을 실행하는 Pod는 사용 사례에 따라 컴퓨팅 리소스를 사용합니다. 예를 들어 Maven 빌드 작업에 빌드하는 다른 애플리케이션에 대해 다른 컴퓨팅 리소스가 필요할 수 있습니다. 따라서 일반 파이프라인의 작업에 대한 컴퓨팅 리소스 할당량을 사전 정의할 수 없습니다. 더 큰 예측 가능성과 컴퓨팅 리소스 사용에 대한 제어 제어는 다양한 애플리케이션에 대해 사용자 지정 파이프라인을 사용합니다.
참고

ResourceQuota 오브젝트로 구성된 네임스페이스에서 Red Hat OpenShift Pipelines를 사용하는 경우 작업 실행으로 생성된 Pod 및 파이프라인 실행이 오류와 함께 실패할 수 있습니다(예: failed quota: <quota name>은 cpu, memory )을 지정해야 합니다.

이 오류를 방지하려면 다음 중 하나를 수행하십시오.

  • (권장) 네임스페이스의 제한 범위를 지정합니다.
  • 모든 컨테이너에 대한 요청 및 제한을 명시적으로 정의합니다.

자세한 내용은 문제 및 해결 방법을 참조하십시오.

이러한 방식으로 사용 사례를 처리하지 않는 경우 우선순위 클래스에 리소스 할당량을 사용하여 해결방법을 구현할 수 있습니다.

3.13.2. 우선순위 클래스를 사용하여 파이프라인 리소스 할당량 지정

PriorityClass 오브젝트는 우선순위 클래스 이름을 상대적 우선순위를 나타내는 정수 값에 매핑합니다. 값이 클수록 클래스의 우선순위가 증가합니다. 우선순위 클래스를 생성한 후에는 사양에 우선순위 클래스 이름을 지정하는 Pod를 생성할 수 있습니다. 또한 Pod의 우선 순위에 따라 시스템 리소스의 Pod 사용을 제어할 수 있습니다.

파이프라인에 리소스 할당량을 지정하는 것은 파이프라인 실행을 통해 생성된 Pod의 하위 집합에 대한 리소스 할당량을 설정하는 것과 유사합니다. 다음 단계에서는 우선순위 클래스를 기반으로 리소스 할당량을 지정하여 해결 방법의 예를 제공합니다.

절차

  1. 파이프라인에 대한 우선순위 클래스를 생성합니다.

    예: 파이프라인의 우선 순위 클래스

    apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: pipeline1-pc
value: 1000000
description: "Priority class for pipeline1"

  2. 파이프라인에 대한 리소스 할당량을 생성합니다.

    예: 파이프라인에 대한 리소스 할당량

    apiVersion: v1
kind: ResourceQuota
metadata:
  name: pipeline1-rq
spec:
  hard:
    cpu: "1000"
    memory: 200Gi
    pods: "10"
  scopeSelector:
    matchExpressions:
    - operator : In
      scopeName: PriorityClass
      values: ["pipeline1-pc"]

  3. 파이프라인의 리소스 할당량 사용량을 확인합니다.

    예: 파이프라인에 대한 리소스 할당량 사용 확인

    $ oc describe quota

    샘플 출력

    Name:       pipeline1-rq
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     1k
memory      0     200Gi
pods        0     10

    Pod가 실행 중이 아니므로 할당량이 사용되지 않습니다.

  4. 파이프라인 및 작업을 생성합니다.

    예: 파이프라인의 YAML

    apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: maven-build
spec:
  workspaces:
  - name: local-maven-repo
  resources:
  - name: app-git
    type: git
  tasks:
  - name: build
    taskRef:
      name: mvn
    resources:
      inputs:
      - name: source
        resource: app-git
    params:
    - name: GOALS
      value: ["package"]
    workspaces:
    - name: maven-repo
      workspace: local-maven-repo
  - name: int-test
    taskRef:
      name: mvn
    runAfter: ["build"]
    resources:
      inputs:
      - name: source
        resource: app-git
    params:
    - name: GOALS
      value: ["verify"]
    workspaces:
    - name: maven-repo
      workspace: local-maven-repo
  - name: gen-report
    taskRef:
      name: mvn
    runAfter: ["build"]
    resources:
      inputs:
      - name: source
        resource: app-git
    params:
    - name: GOALS
      value: ["site"]
    workspaces:
    - name: maven-repo
      workspace: local-maven-repo

    예: 파이프라인의 작업에 대한 YAML

    apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: mvn
spec:
  workspaces:
  - name: maven-repo
  resources:
    inputs:
    - name: source
      type: git
  params:
  - name: GOALS
    description: The Maven goals to run
    type: array
    default: ["package"]
  steps:
    - name: mvn
      image: gcr.io/cloud-builders/mvn
      workingDir: /workspace/source
      command: ["/usr/bin/mvn"]
      args:
        - -Dmaven.repo.local=$(workspaces.maven-repo.path)
        - "$(params.GOALS)"

  5. 파이프라인 실행을 생성하고 시작합니다.

    예: 파이프라인 실행을 위한 YAML

    apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: petclinic-run-
spec:
  pipelineRef:
    name: maven-build
  podTemplate:
    priorityClassName: pipeline1-pc
  workspaces:
  - name: local-maven-repo
    emptyDir: {}
  resources:
  - name: app-git
    resourceSpec:
      type: git
      params:
        - name: url
          value: https://github.com/spring-projects/spring-petclinic

    참고

    파이프라인 실행이 실패하고 할당량 실패: <quota name>에서 cpu, memory를 지정해야 합니다.

    이 오류를 방지하려면 네임스페이스에 대한 제한 범위를 설정합니다. 여기서 LimitRange 오브젝트의 기본값은 빌드 프로세스 중 생성된 Pod에 적용됩니다.

    제한 범위 설정에 대한 자세한 내용은 Additional resources 섹션에서 제한 범위를 사용하여 리소스 소비 제한 을 참조하십시오.

  6. Pod가 생성되면 파이프라인 실행에 대한 리소스 할당량 사용량을 확인합니다.

    예: 파이프라인에 대한 리소스 할당량 사용 확인

    $ oc describe quota

    샘플 출력

    Name:       pipeline1-rq
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         500m  1k
memory      10Gi  200Gi
pods        1     10

    출력에서는 우선순위 클래스당 리소스 할당량을 지정하여 우선순위 클래스에 속하는 모든 동시 실행 중인 Pod에 대해 결합된 리소스 할당량을 관리할 수 있음을 나타냅니다.

3.13.3. 추가 리소스

3.14. 권한 있는 보안 컨텍스트에서 Pod 사용

OpenShift Pipelines 1.3.x 이상 버전의 기본 구성에서는 파이프라인 실행 또는 작업 실행으로 인해 pod가 실행된 경우 권한 있는 보안 컨텍스트로 Pod를 실행할 수 없습니다. 이러한 Pod의 경우 기본 서비스 계정은 pipeline 이고 pipeline 서비스 계정과 연결된 SCC(보안 컨텍스트 제약 조건)는 pipelines-scc 입니다. pipelines-scc SCC는 anyuid SCC와 유사하지만 파이프라인 SCC의 YAML 파일에 정의된 것과 약간의 차이점이 있습니다.

pipelines-scc.yaml 스니펫 예

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
...
allowedCapabilities:
  - SETFCAP
...
fsGroup:
  type: MustRunAs
...

또한 OpenShift Pipelines의 일부로 제공되는 Buildah 클러스터 작업은 vfs를 기본 스토리지 드라이버로 사용합니다.

3.14.1. 파이프라인 실행 및 작업 실행 권한이 있는 보안 컨텍스트에서 Pod 실행

절차

privileged있는 보안 컨텍스트를 사용하여 Pod(파이프라인 실행 또는 작업 실행)를 실행하려면 다음 수정 작업을 수행합니다.

  • 명시적 SCC를 갖도록 연결된 사용자 계정 또는 서비스 계정을 구성합니다. 다음 방법을 사용하여 구성을 수행할 수 있습니다.

    • 다음 명령을 실행합니다. 

      $ oc adm policy add-scc-to-user <scc-name> -z <service-account-name>

    • 또는 RoleBinding 및 Role 또는 ClusterRole에 대한 YAML 파일을 수정합니다.

      RoleBinding 오브젝트의 예

      apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: service-account-name 1
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pipelines-scc-clusterrole 2
subjects:
- kind: ServiceAccount
  name: pipeline
  namespace: default

      1
      적절한 서비스 계정 이름으로 바꿉니다.
      2
      사용하는 역할 바인딩에 따라 적절한 클러스터 역할로 바꿉니다.

      ClusterRole 오브젝트의 예

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-scc-clusterrole 1
rules:
- apiGroups:
  - security.openshift.io
  resourceNames:
  - nonroot
  resources:
  - securitycontextconstraints
  verbs:
  - use

      1
      사용하는 역할 바인딩에 따라 적절한 클러스터 역할로 바꿉니다.
    참고

    기본 YAML 파일의 복사본을 만들고 중복 파일을 변경하는 것이 좋습니다.

  • vfs 스토리지 드라이버를 사용하지 않는 경우 작업 실행 또는 파이프라인 실행과 연결된 서비스 계정을 구성하여 권한 있는 SCC를 구성하고 보안 컨텍스트를 privileged: true로 설정합니다.

3.14.2. 사용자 정의 SCC 및 사용자 정의 서비스 계정을 사용하여 파이프라인 실행 및 작업 실행

기본 파이프라인 서비스 계정과 연결된 pipelines-scc 보안 컨텍스트 제약 조건(SCC) 을 사용하는 경우 파이프라인 실행 및 작업 실행 Pod가 시간 초과될 수 있습니다. 이는 기본 pipelines-scc SCC에서 fsGroup.type 매개변수가 MustRunAs 로 설정되어 있기 때문에 발생합니다.

참고

Pod 타임아웃에 대한 자세한 내용은 BZ#1995779 를 참조하십시오.

Pod 타임아웃을 방지하기 위해 fsGroup.type 매개변수를 RunAsAny 로 설정하여 사용자 정의 SCC를 생성하여 사용자 정의 서비스 계정과 연결할 수 있습니다.

참고

모범 사례로 파이프라인 실행 및 작업 실행을 위해 사용자 정의 SCC 및 사용자 정의 서비스 계정을 사용합니다. 이 방법을 사용하면 유연성이 향상되고 업그레이드 중에 기본값이 수정될 때 실행을 중단하지 않습니다.

절차

  1. fsGroup.type 매개변수를 RunAsAny 로 설정하여 사용자 지정 SCC를 정의합니다.

    예: 사용자 정의 SCC

    apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: my-scc is a close replica of anyuid scc. pipelines-scc has fsGroup - RunAsAny.
  name: my-scc
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
groups:
- system:cluster-admins
priority: 10
readOnlyRootFilesystem: false
requiredDropCapabilities:
- MKNOD
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret

  2. 사용자 정의 SCC를 만듭니다.

    예: my-scc SCC 생성

    $ oc create -f my-scc.yaml

  3. 사용자 정의 서비스 계정을 생성합니다.

    예: fsgroup-runasany 서비스 계정 생성

    $ oc create serviceaccount fsgroup-runasany

  4. 사용자 정의 SCC를 사용자 정의 서비스 계정과 연결합니다.

    예: my-scc SCC와 fsgroup-runasany 서비스 계정 연결

    $ oc adm policy add-scc-to-user my-scc -z fsgroup-runasany

    권한 있는 작업에 사용자 정의 서비스 계정을 사용하려면 다음 명령을 실행하여 권한 있는 SCC를 사용자 정의 서비스 계정과 연결할 수 있습니다.

    예: 권한이 있는 SCC와 fsgroup-runasany 서비스 계정 연결

    $ oc adm policy add-scc-to-user privileged -z fsgroup-runasany

  5. 파이프라인 실행 및 작업 실행에서 사용자 정의 서비스 계정을 사용합니다.

    예: 파이프라인에서 fsgroup-runasany 사용자 지정 서비스 계정을 사용하여 YAML 실행

    apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: <pipeline-run-name>
spec:
  pipelineRef:
    name: <pipeline-cluster-task-name>
  serviceAccountName: 'fsgroup-runasany'

    예: fsgroup-runasany 사용자 지정 서비스 계정을 사용하여 YAML 실행

    apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: <task-run-name>
spec:
  taskRef:
    name: <cluster-task-name>
  serviceAccountName: 'fsgroup-runasany'

3.14.3. 추가 리소스

3.15. 이벤트 리스너로 Webhook 보안

관리자는 이벤트 리스너를 사용하여 Webhook를 보호할 수 있습니다. 네임스페이스를 생성한 후 네임스페이스에 operator.tekton.dev/enable-annotation=enabled 레이블을 추가하여 Eventlistener 리소스의 HTTPS를 활성화합니다. 그런 다음 재암호화 TLS 종료를 사용하여 Trigger 리소스 및 보안 경로를 생성합니다.

Red Hat OpenShift Pipelines에서 트리거는 Eventlistener 리소스에 대한 비보안 HTTP 및 보안 HTTPS 연결을 모두 지원합니다. HTTPS는 클러스터 내부 및 외부의 연결을 보호합니다.

Red Hat OpenShift Pipelines는 네임스페이스의 레이블을 감시하는 tekton-operator-proxy-webhook Pod를 실행합니다. 네임스페이스에 라벨을 추가하면 Webhook에서 EventListener 오브젝트에 service.beta.openshift.io/serving-cert-secret-name=<secret_name> 주석을 설정합니다. 이를 통해 시크릿과 필수 인증서를 생성합니다. 

service.beta.openshift.io/serving-cert-secret-name=<secret_name>

또한 생성된 시크릿을 Eventlistener pod 마운트하여 요청을 보호할 수 있습니다.

3.15.1. OpenShift 경로와의 보안 연결 제공

재암호화 TLS 종료로 경로를 생성합니다. 

$ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>

또는 재암호화된 TLS 종료 YAML 파일을 만들어 보안 경로를 만들 수도 있습니다.

보안 경로를 생성하기 위해 TLS 종료 YAML을 재암호화하는 예

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-passthrough-secured  1
spec:
  host: <hostname>
  to:
    kind: Service
    name: frontend 2
  tls:
    termination: reencrypt 3
    key: [as in edge termination]
    certificate: [as in edge termination]
    caCertificate: [as in edge termination]
    destinationCACertificate: |- 4
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

1 2
63자로 제한되는 개체의 이름입니다.
3
종료 필드는 reencrypt로 설정됩니다. 이 필드는 유일한 필수 TLS 필드입니다.
4
이는 재암호화에 필요합니다. destinationCACertificate 필드는 엔드포인트 인증서의 유효성을 검사하고 라우터에서 대상 pod로의 연결을 보호합니다. 다음 시나리오 중 하나에서 이 필드를 생략할 수 있습니다.
  • 서비스는 서비스 서명 인증서를 사용합니다.
  • 관리자는 라우터의 기본 CA 인증서를 지정하고 서비스에는 해당 CA에서 서명한 인증서가 있습니다.

oc create route reencrypt --help 명령을 실행하여 더 많은 옵션을 표시할 수 있습니다.

3.15.2. 보안 HTTPS 연결을 사용하여 샘플 EventListener 리소스 생성

이 섹션에서는 pipelines-tutorial 예제를 사용하여 보안 HTTPS 연결을 사용하여 샘플 EventListener 리소스 생성을 만드는 방법을 보여줍니다.

절차

  1. pipelines-tutorial 리포지토리에서 사용 가능한 YAML 파일에서 TriggerBinding 리소스를 생성합니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/01_binding.yaml

  2. pipelines-tutorial 리포지토리에서 직접 TriggerTemplate 리소스를 생성합니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/02_template.yaml

  3. pipelines-tutorial 리포지토리에서 직접 Trigger 리소스를 생성합니다. 

    $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/03_trigger.yaml

  4. 보안 HTTPS 연결을 사용하여 EventListener 리소스를 생성합니다.

    1. Eventlistener 리소스에 대한 보안 HTTPS 연결을 활성화하려면 레이블을 추가합니다. 

      $ oc label namespace <ns-name> operator.tekton.dev/enable-annotation=enabled

    2. pipelines-tutorial 리포지토리에서 사용 가능한 YAML 파일에서 EventListener 리소스를 생성합니다. 

      $ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/master/03_triggers/04_event_listener.yaml

    3. 재암호화 TLS 종료로 경로를 생성합니다. 

      $ oc create route reencrypt --service=<svc-name> --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=<hostname>

3.16. git secret을 사용하여 파이프라인 인증

Git 시크릿은 Git 리포지토리와 안전하게 상호 작용할 수 있는 자격 증명으로 구성되며 인증을 자동화하는 데 자주 사용됩니다. Red Hat OpenShift Pipelines에서는 Git 시크릿을 사용하여 실행 중에 Git 리포지토리와 상호 작용하는 파이프라인 실행 및 작업 실행을 인증할 수 있습니다.

파이프라인 실행 또는 작업 실행은 연결된 서비스 계정을 통해 보안에 대한 액세스 권한을 얻습니다. OpenShift Pipelines는 기본 인증 및 SSH 기반 인증을 위한 주석(키-값 쌍)으로 Git 시크릿 사용을 지원합니다.

3.16.1. 인증 정보 선택

파이프라인 실행 또는 작업 실행에 다른 Git 리포지토리에 액세스하려면 여러 인증이 필요할 수 있습니다. OpenShift Pipelines가 인증 정보를 사용할 수 있는 도메인으로 각 시크릿에 주석을 답니다.

Git 시크릿의 인증 정보 주석 키는 tekton.dev/git- 로 시작해야 하며 값은 OpenShift Pipelines가 해당 인증 정보를 사용할 호스트의 URL입니다.

다음 예에서 OpenShift Pipelines는 사용자 이름과 암호를 사용하는 basic-auth 시크릿을 사용하여 github.com 및 gitlab.com 의 리포지토리에 액세스합니다.

예: 기본 인증을 위한 여러 인증 정보

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: github.com
    tekton.dev/git-1: gitlab.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> 1
  password: <password> 2

1
저장소의 사용자 이름
2
리포지토리의 암호 또는 개인 액세스 토큰

ssh-auth 보안(개인 키)을 사용하여 Git 리포지토리에 액세스할 수도 있습니다.

예: SSH 기반 인증을 위한 개인 키

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: 1

1
SSH 개인 키 파일의 콘텐츠입니다.

3.16.2. Git의 기본 인증 구성

암호로 보호된 리포지토리에서 리소스를 검색하는 파이프라인의 경우 해당 파이프라인에 대한 기본 인증을 구성해야 합니다.

파이프라인에 대한 기본 인증을 구성하려면 secret.yaml,serviceaccount.yaml, 지정된 리포지토리에 대한 Git 시크릿의 인증 정보를 사용하여. yaml 파일을 업데이트합니다. 이 프로세스를 완료하면 OpenShift Pipelines에서 해당 정보를 사용하여 지정된 파이프라인 리소스를 검색할 수 있습니다.

참고

GitHub의 경우 일반 암호를 사용한 인증은 더 이상 사용되지 않습니다. 대신 개인 액세스 토큰 을 사용합니다.

절차

  1. secret.yaml 파일에서 대상 Git 리포지토리에 액세스할 사용자 이름과 암호 또는 GitHub 개인 액세스 토큰 을 지정합니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: basic-user-pass 1
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> 2
  password: <password> 3
    1
    보안의 이름입니다. 예에서는 basic-user-pass 입니다.
    2
    Git 리포지토리의 사용자 이름입니다.
    3
    Git 리포지토리의 암호입니다.

  2. serviceaccount.yaml 파일에서 시크릿을 적절한 서비스 계정과 연결합니다. 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot 1
secrets:
  - name: basic-user-pass 2
    1
    서비스 계정의 이름입니다. 이 예에서는 build-bot.
    2
    보안의 이름입니다. 예에서는 basic-user-pass 입니다.

  3. run.yaml 파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다.

    • 서비스 계정을 작업 실행과 연결합니다. 

      apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: build-push-task-run-2 1
spec:
  serviceAccountName: build-bot 2
  taskRef:
    name: build-push 3
      1
      작업 실행의 이름입니다. 예에서는 build-push-task-run-2.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot.
      3
      작업 이름입니다. 예에서는 build-push 입니다.

    • 서비스 계정을 PipelineRun 리소스와 연결합니다. 

      apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: demo-pipeline 1
  namespace: default
spec:
  serviceAccountName: build-bot 2
  pipelineRef:
    name: demo-pipeline 3
      1
      파이프라인 실행의 이름입니다. 예에서는 demo-pipeline.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot.
      3
      파이프라인의 이름입니다. 예에서는 demo-pipeline.

  4. 변경 사항을 적용합니다. 

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

3.16.3. Git에 대한 SSH 인증 구성

SSH 키로 구성된 리포지토리에서 리소스를 검색하는 파이프라인의 경우 해당 파이프라인에 대한 SSH 기반 인증을 구성해야 합니다.

파이프라인에 대한 SSH 기반 인증을 구성하려면 secret.yaml,serviceaccount.yaml, 지정된 리포지토리의 SSH 개인 키의 인증 정보를 사용하여. yaml 파일을 업데이트합니다. 이 프로세스를 완료하면 OpenShift Pipelines에서 해당 정보를 사용하여 지정된 파이프라인 리소스를 검색할 수 있습니다.

참고

기본 인증 대신 SSH 기반 인증을 사용하는 것이 좋습니다.

절차

  1. SSH 개인 키 를 생성하거나 일반적으로 ~/.ssh/id_rsa 파일에서 사용할 수 있는 기존 개인 키를 복사합니다.

  2. secret.yaml 파일에서 ssh-privatekey 값을 SSH 개인 키 파일의 콘텐츠로 설정하고 known_hosts 값을 알려진 호스트 파일의 콘텐츠로 설정합니다. 

    apiVersion: v1
kind: Secret
metadata:
  name: ssh-key 1
  annotations:
    tekton.dev/git-0: github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: 2
  known_hosts: 3
    1
    SSH 개인 키가 포함된 보안의 이름입니다. 이 예에서는 ssh-key.
    2
    SSH 개인 키 파일의 콘텐츠입니다.
    3
    알려진 호스트 파일의 내용입니다.
    경고

    개인 키를 생략하면 OpenShift Pipelines는 모든 서버의 공개 키를 허용합니다.

  3. 선택 사항: 사용자 지정 SSH 포트를 지정하려면 주석 값 끝에 :<port number >를 추가합니다. 예를 들면 tekton.dev/git-0: github.com:2222 입니다.

  4. serviceaccount.yaml 파일에서 ssh-key 시크릿을 build-bot 서비스 계정과 연결합니다. 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot 1
secrets:
  - name: ssh-key 2
    1
    서비스 계정의 이름입니다. 이 예에서는 build-bot.
    2
    SSH 개인 키가 포함된 보안의 이름입니다. 이 예에서는 ssh-key.

  5. run.yaml 파일에서 서비스 계정을 작업 실행 또는 파이프라인 실행과 연결합니다.

    • 서비스 계정을 작업 실행과 연결합니다. 

      apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: build-push-task-run-2 1
spec:
  serviceAccountName: build-bot 2
  taskRef:
    name: build-push 3
      1
      작업 실행의 이름입니다. 예에서는 build-push-task-run-2.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot.
      3
      작업 이름입니다. 예에서는 build-push 입니다.

    • 서비스 계정을 파이프라인 실행과 연결합니다. 

      apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: demo-pipeline 1
  namespace: default
spec:
  serviceAccountName: build-bot 2
  pipelineRef:
    name: demo-pipeline 3
      1
      파이프라인 실행의 이름입니다. 예에서는 demo-pipeline.
      2
      서비스 계정의 이름입니다. 이 예에서는 build-bot.
      3
      파이프라인의 이름입니다. 예에서는 demo-pipeline.

  6. 변경 사항을 적용합니다. 

    $ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

3.16.4. git type 작업에서 SSH 인증 사용

Git 명령을 호출할 때 작업 단계에서 직접 SSH 인증을 사용할 수 있습니다. SSH 인증은 $HOME 변수를 무시하고 /etc/passwd 파일에 지정된 사용자의 홈 디렉터리만 사용합니다. 따라서 작업의 각 단계는 연결된 사용자의 홈 디렉터리에 /tekton/home/.ssh 디렉터리를 심볼릭 링크해야 합니다.

그러나 git 유형의 파이프라인 리소스 또는 Tekton 카탈로그에서 사용 가능한 git-clone 작업을 사용하는 경우에는 명시적 심볼릭 링크가 필요하지 않습니다.

git 유형 작업에서 SSH 인증을 사용하는 예는 authentication -git-commands.yaml 을 참조하십시오.

3.16.5. root가 아닌 사용자로 보안 사용

다음과 같은 특정 시나리오에서는 루트가 아닌 사용자로 보안을 사용해야 할 수 있습니다.

  • 컨테이너가 실행하는 데 사용하는 사용자 및 그룹은 플랫폼에 의해 무작위화됩니다.
  • 작업의 단계는 루트가 아닌 보안 컨텍스트를 정의합니다.
  • 작업은 루트가 아닌 글로벌 보안 컨텍스트를 지정합니다. 이 컨텍스트는 작업의 모든 단계에 적용됩니다.

이러한 시나리오에서는 작업 실행 및 파이프라인 실행을 루트가 아닌 사용자로 실행하는 다음 측면을 고려하십시오.

  • Git에 대한 SSH 인증을 사용하려면 사용자가 /etc/passwd 디렉터리에 유효한 홈 디렉터리를 구성해야 합니다. 유효한 홈 디렉터리가 없는 UID를 지정하면 인증에 실패합니다.
  • SSH 인증은 $HOME 환경 변수를 무시합니다. 따라서 OpenShift Pipelines(/tekton/home)에서 루트가 아닌 사용자의 유효한 홈 디렉터리에 정의된 $HOME 디렉터리의 적절한 시크릿 파일을 또는 심볼릭 링크로 설정해야 합니다.

또한 루트가 아닌 보안 컨텍스트에서 SSH 인증을 구성하려면 git 명령 인증 예제를 참조하십시오.

3.16.6. 시크릿 액세스 제한 특정 단계

기본적으로 OpenShift Pipelines의 보안은 $HOME/tekton/home 디렉터리에 저장되며 작업의 모든 단계에서 사용할 수 있습니다.

보안을 특정 단계로 제한하려면 보안 정의를 사용하여 볼륨을 지정하고 특정 단계에서 볼륨을 마운트합니다.

3.17. OpenShift Pipelines 공급망 보안에 Tekton 체인 사용

Tekton Chains는 Kubernetes CRD(Custom Resource Definition) 컨트롤러입니다. 이를 사용하여 Red Hat OpenShift Pipelines를 사용하여 생성된 작업 및 파이프라인의 공급망 보안을 관리할 수 있습니다.

기본적으로 Tekton Chains는 OpenShift Container Platform 클러스터에서 모든 작업 실행 실행을 관찰합니다. 작업이 완료되면 Tekton Chains는 작업 실행 스냅샷을 사용합니다. 그런 다음 스냅샷을 하나 이상의 표준 페이로드 형식으로 변환하고 마지막으로 모든 아티팩트에 서명하고 저장합니다.

작업 실행에 대한 정보를 캡처하기 위해 Tekton 체인은 Result 오브젝트를 사용합니다. 오브젝트를 사용할 수 없는 경우 Tekton은 OCI 이미지의 URL 및 인증된 다이제스트를 조작합니다.

3.17.1. 주요 기능

  • cosign 및 skopeo 와 같은 툴을 통해 생성된 암호화 키를 사용하여 작업 실행, 작업 실행 결과, OCI 레지스트리 이미지에 서명할 수 있습니다.
  • in-toto 와 같은 증명 형식을 사용할 수 있습니다.
  • OCI 리포지토리를 스토리지 백엔드로 사용하여 서명 및 서명된 아티팩트를 안전하게 저장할 수 있습니다.

3.17.2. Tekton 체인 구성

Red Hat OpenShift Pipelines Operator는 기본적으로 Tekton 체인을 설치합니다. TektonConfig 사용자 정의 리소스를 수정하여 Tekton 체인을 구성할 수 있습니다. Operator는 이 사용자 정의 리소스에서 변경한 사항을 자동으로 적용합니다.

사용자 정의 리소스를 편집하려면 다음 명령을 사용합니다. 

$ oc edit TektonConfig config

사용자 정의 리소스에는 체인 배열이 포함됩니다. 다음 예와 같이 지원되는 모든 구성 매개변수를 이 배열에 추가할 수 있습니다. 

apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
  addon: {}
  chain:
    artifacts.taskrun.format: tekton
  config: {}

3.17.2.1. Tekton 체인 구성에 지원되는 매개변수

클러스터 관리자는 지원되는 다양한 매개변수 키와 값을 사용하여 작업 실행, OCI 이미지 및 스토리지에 대한 사양을 구성할 수 있습니다.

3.17.2.1.1. 작업 실행 아티팩트에 지원되는 매개변수

표 3.19. 체인 구성: 작업 실행 아티팩트에 대해 지원되는 매개변수

키설명지원되는 값기본값

artifacts.taskrun.format

작업 실행 페이로드를 저장하는 형식입니다.

in-toto, slsa/v1

in-toto

artifacts.taskrun.storage

작업 실행 서명의 스토리지 백엔드입니다. 여러 백엔드를 "tekton,oci" 와 같은 쉼표로 구분된 목록으로 지정할 수 있습니다. 작업 실행 아티팩트 저장을 비활성화하려면 빈 문자열 "" 를 제공합니다.

tekton, oci, gcs, docdb, grafeas

tekton

artifacts.taskrun.signer

작업 실행 페이로드에 서명하기 위한 서명 백엔드입니다.

x509,kms

x509

참고

slsa/v1 은 이전 버전과의 호환성을 위해 In-to 의 별칭입니다.

3.17.2.1.2. 파이프라인 실행 아티팩트에 지원되는 매개변수

표 3.20. 체인 구성: 파이프라인 실행 아티팩트에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

artifacts.pipelinerun.format

파이프라인 실행 페이로드를 저장하는 형식입니다.

in-toto, slsa/v1

in-toto

artifacts.pipelinerun.storage

파이프라인 실행 서명을 저장하기 위한 스토리지 백엔드입니다. 여러 백엔드를 "tekton,oci" 와 같은 쉼표로 구분된 목록으로 지정할 수 있습니다. 파이프라인 실행 아티팩트 저장을 비활성화하려면 빈 문자열 "" 를 제공합니다.

tekton, oci, gcs, docdb, grafeas

tekton

artifacts.pipelinerun.signer

파이프라인 실행 페이로드에 서명하기 위한 서명 백엔드입니다.

x509, kms

x509

참고
  • slsa/v1 은 이전 버전과의 호환성을 위해 In-to 의 별칭입니다.
  • grafeas 스토리지 백엔드의 경우 컨테이너 분석만 지원됩니다. Tekton 체인의 현재 버전에서는 grafeas 서버 주소를 구성할 수 없습니다.
3.17.2.1.3. OCI 아티팩트에 지원되는 매개변수

표 3.21. 체인 구성: OCI 아티팩트에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

artifacts.oci.format

OCI 페이로드를 저장하는 형식입니다.

simplesigning

simplesigning

artifacts.oci.storage

OCI 서명을 저장하기 위한 스토리지 백엔드입니다. 여러 백엔드를 "oci,tekton" 과 같은 쉼표로 구분된 목록으로 지정할 수 있습니다. OCI 아티팩트 저장을 비활성화하려면 빈 문자열 "" 를 제공합니다.

tekton, oci, gcs, docdb, grafeas

oci

artifacts.oci.signer

OCI 페이로드에 서명하기 위한 서명 백엔드입니다.

x509, kms

x509

3.17.2.1.4. KMS 서명자에서 지원되는 매개변수

표 3.22. 체인 설정: KMS 서명자에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

signers.kms.kmsref

kms 서명자에서 사용할 KMS 서비스에 대한 URI 참조입니다.

지원되는 스키마: gcpkms://, awskms://, azurekms://, hashivault://. 자세한 내용은 Sigstore 설명서의 KMS 지원을 참조하십시오.

 
3.17.2.1.5. 스토리지에 지원되는 매개변수

표 3.23. 체인 구성: 스토리지에 지원되는 매개변수

매개변수설명지원되는 값기본값

storage.gcs.bucket

스토리지를 위한 GCS 버킷

  

artifacts.oci.repository

OCI 서명 및 인증을 저장하기 위한 OCI 리포지토리입니다.

아티팩트 스토리지 백엔드 중 하나를 oci 로 구성하고 이 키를 정의하지 않으면 Tekton 체인은 저장된 OCI 아티팩트 자체와 함께 인증 정보를 저장합니다. 이 키를 정의하면 인증 정보는 OCI 아티팩트와 함께 저장되지 않으며 대신 지정된 위치에 저장됩니다. 자세한 내용은 cosign 문서를 참조하십시오.

 

builder.id

인증 정보용으로 설정할 빌더 ID

 

https://tekton.dev/chains/v2

docdb 스토리지 방법이 아티팩트에 해당하는 경우 docstore 스토리지 옵션을 구성합니다. go-cloud docstore URI 형식에 대한 자세한 내용은 docstore 패키지 설명서 를 참조하십시오. Red Hat OpenShift Pipelines는 다음 문서 서비스를 지원합니다.

  • Firestore
  • dynamodb

표 3.24. 체인 구성: docstore 스토리지에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

storage.docdb.url

docstore 컬렉션에 대한 go-cloud URI 참조입니다. 모든 아티팩트에 대해 docdb 스토리지 방법이 활성화된 경우 사용됩니다.

Firestore://projects/[PROJECT]/databases/(default)/documents/[COLLECTION]?name_field=name

 

아티팩트에 대해 grafeas 스토리지 방법을 활성화하면 Grafeas 스토리지 옵션을 구성합니다. Grafeas 노트 및 발생에 대한 자세한 내용은 Grafeas 개념을 참조하십시오.

발생을 생성하기 위해 Red Hat OpenShift Pipelines는 먼저 발생을 연결하는 데 사용되는 노트를 생성해야 합니다. Red Hat OpenShift Pipelines는 두 가지 유형인 ATTESTATION Occurrence 및 BUILD Occurrence를 생성합니다.

Red Hat OpenShift Pipelines는 구성 가능한 noteid 를 노트 이름의 접두사로 사용합니다. ATTESTATION 노트에 대한 접미사 -simplesigning 과 BUILD note의 접미사 -intoto 를 추가합니다. noteid 필드가 구성되지 않은 경우 Red Hat OpenShift Pipelines는 tekton-<NAMESPACE >를 접두사로 사용합니다.

표 3.25. 체인 구성: Grafeas 스토리지에 지원되는 매개변수

매개변수설명지원되는 값기본값

storage.grafeas.projectid

발생을 저장하기 위한 Grafeas 서버가 있는 OpenShift Container Platform 프로젝트입니다.

  

storage.grafeas.noteid

선택 사항: 생성된 모든 노트의 이름에 사용할 접두사입니다.

공백이 없는 문자열입니다.

 

storage.grafeas.notehint

선택 사항: Grafeas ATTESTATION 참고 사항의 human_readable_name 필드입니다.

 

이 인증 노트는 Tekton 체인에 의해 생성되었습니다.

선택적으로 바이너리 투명성 증명의 추가 업로드를 활성화할 수 있습니다.

표 3.26. 체인 구성: 투명성 강화 스토리지를 위한 지원되는 매개변수

매개변수설명지원되는 값기본값

transparency.enabled

자동 바이너리 투명도 업로드를 활성화하거나 비활성화합니다.

true,false,manual

false

transparency.url

활성화된 경우 바이너리 투명도를 업로드하기 위한 URL입니다.

 

https://rekor.sigstore.dev

참고

transparency.enabled 를 수동 으로 설정하면 다음 주석이 있는 작업 실행 및 파이프라인 실행만 투명 로그에 업로드됩니다. 

chains.tekton.dev/transparency-upload: "true"

x509 서명 백엔드를 구성하는 경우 Fulcio를 사용하여 키 없이 서명을 선택적으로 활성화할 수 있습니다.

표 3.27. 체인 구성: Fulcio를 사용한 x509 키 없이 서명에 대해 지원되는 매개변수

매개변수설명지원되는 값기본값

signers.x509.fulcio.enabled

Fulcio에서 자동 인증서 요청 요청을 활성화하거나 비활성화합니다.

true, false

false

signers.x509.fulcio.address

활성화된 경우 인증서를 요청하는 Fulcio 주소입니다.

 

https://v1.fulcio.sigstore.dev

signers.x509.fulcio.issuer

예상되는 OIDC 발행자

 

https://oauth2.sigstore.dev/auth

signers.x509.fulcio.provider

ID 토큰을 요청할 공급자입니다.

Google,spiffe,github,파일 시스템

Red Hat OpenShift Pipelines는 모든 공급자를 사용하려고 합니다.

signers.x509.identity.token.file

ID 토큰이 포함된 파일의 경로입니다.

  

signers.x509.tuf.mirror.url

TUF 서버의 URL입니다. $TUF_URL/root.json 이 있어야 합니다.

 

https://sigstore-tuf-root.storage.googleapis.com

kms 서명 백엔드를 구성하는 경우 필요에 따라 OIDC 및 Spire를 포함한 KMS 구성을 설정합니다.

표 3.28. 체인 구성: KMS 서명에 지원되는 매개변수

매개변수설명지원되는 값기본값

signers.kms.auth.address

KMS 서버의 URI( VAULT_ADDR값 ).

signers.kms.auth.token

KMS 서버의 인증 토큰( VAULT_TOKEN값 ).

signers.kms.auth.oidc.path

OIDC 인증 경로(예: Vault의 경우 jwt )입니다.

signers.kms.auth.oidc.role

OIDC 인증의 역할입니다.

signers.kms.auth.spire.sock

KMS 토큰에 대한 Spire 소켓의 URI입니다(예: unix:///tmp/spire-agent/public/api.sock).

signers.kms.auth.spire.audience

SVID를 Spire에서 요청하는 대상입니다.

3.17.3. Tekton 체인에서 데이터에 서명하기 위한 보안

클러스터 관리자는 키 쌍을 생성하고 Tekton Chains를 사용하여 Kubernetes 시크릿을 사용하여 아티팩트에 서명할 수 있습니다. Tekton 체인이 작동하려면 암호화된 키의 개인 키와 암호가 openshift-pipelines 네임스페이스에 signing-secrets 시크릿의 일부로 존재해야 합니다.

현재 Tekton Chains는 x509 및 cosign 서명 체계를 지원합니다.

참고

지원되는 서명 체계 중 하나만 사용하십시오.

Tekton Chains와 함께 x509 서명 스키마를 사용하려면 ed25519 또는 ecdsa 유형의 x509.pem 개인 키를 signing-secrets Kubernetes 시크릿에 저장합니다.

3.17.3.1. cosign을 사용하여 서명

cosign 툴을 사용하여 Tekton 체인에 공동 서명 스키마를 사용할 수 있습니다.

사전 요구 사항

  • cosign 툴을 설치했습니다.

절차

  1. 다음 명령을 실행하여 cosign.key 및 cosign.pub 키 쌍을 생성합니다. 

    $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets

    cosign은 암호를 입력하라는 메시지를 표시한 다음 Kubernetes 시크릿을 생성합니다.

  2. signing-secrets Kubernetes 시크릿에 암호화된 cosign.key 개인 키와 cosign.password 암호 해독 암호를 저장합니다. 개인 키가 ENCRYPTED COSIGN PRIVATE KEY 유형의 암호화된 PEM 파일로 저장되었는지 확인합니다.

3.17.3.2. skopeo를 사용하여 서명

skopeo 툴을 사용하여 키를 생성하고 Tekton 체인과 함께 cosign 서명 스키마에 사용할 수 있습니다.

사전 요구 사항

  • skopeo 툴을 설치했습니다.

절차

  1. 다음 명령을 실행하여 공개/개인 키 쌍을 생성합니다. 

    $ skopeo generate-sigstore-key --output-prefix <mykey> 1
    1
    & lt;mykey >를 선택한 키 이름으로 바꿉니다.

    Skopeo는 개인 키에 대한 암호를 입력하라는 메시지를 표시한 다음 <mykey> .private 및 <mykey > .pub 라는 키 파일을 만듭니다.

  2. 다음 명령을 실행하여 base64 툴을 사용하여 < mykey>.pub 파일을 인코딩합니다. 

    $ base64 -w 0 <mykey>.pub > b64.pub

  3. 다음 명령을 실행하여 base64 툴을 사용하여 < mykey>.private 파일을 인코딩합니다. 

    $ base64 -w 0 <mykey>.private > b64.private

  4. 다음 명령을 실행하여 base64 툴을 사용하여 passhprase를 인코딩합니다. 

    $ echo -n '<passphrase>' | base64 -w 0 > b64.passphrase 1
    1
    & lt;passphrase& gt;를 키 쌍에 사용한 암호로 바꿉니다.

  5. 다음 명령을 실행하여 openshift-pipelines 네임스페이스에 signing-secrets 시크릿을 생성합니다. 

    $ oc create secret generic signing-secrets -n openshift-pipelines

  6. 다음 명령을 실행하여 signing-secrets 시크릿을 편집합니다. 

    $ oc edit secret -n openshift-pipelines signing-secrets

    다음과 같은 방식으로 시크릿 데이터에 인코딩된 키를 추가합니다. 

    apiVersion: v1
data:
  cosign.key: <Encoded <mykey>.private> 1
  cosign.password: <Encoded passphrase> 2
  cosign.pub: <Encoded <mykey>.pub> 3
immutable: true
kind: Secret
metadata:
  name: signing-secrets
# ...
type: Opaque
    1
    & lt;Encoded <mykey>.private >을 b64.private 파일의 내용으로 바꿉니다.
    2
    & lt;Encoded passphrase& gt;를 b64.passphrase 파일의 콘텐츠로 바꿉니다.
    3
    & lt;Encoded <mykey>.pub >를 b64.pub 파일의 내용으로 바꿉니다.

3.17.3.3. "비밀번호가 이미 있음" 오류 해결

signing-secret 시크릿이 이미 채워진 경우 이 보안을 생성하는 명령에서 다음 오류 메시지를 출력할 수 있습니다. 

Error from server (AlreadyExists): secrets "signing-secrets" already exists

보안을 삭제하여 이 오류를 해결할 수 있습니다.

절차

  1. 다음 명령을 실행하여 signing-secret 시크릿을 삭제합니다. 

    $ oc delete secret signing-secrets -n openshift-pipelines
  2. 키 쌍을 다시 생성하여 선호하는 서명 스키마를 사용하여 시크릿에 저장합니다.

3.17.4. OCI 레지스트리에 인증

클러스터 관리자는 OCI 레지스트리로 서명을 푸시하기 전에 레지스트리에 인증하도록 Tekton Chains를 구성해야 합니다. Tekton Chains 컨트롤러는 작업을 실행하는 동일한 서비스 계정을 사용합니다. 서명을 OCI 레지스트리로 푸시하는 데 필요한 자격 증명으로 서비스 계정을 설정하려면 다음 단계를 수행합니다.

절차

  1. Kubernetes 서비스 계정의 네임스페이스 및 이름을 설정합니다. 

    $ export NAMESPACE=<namespace> 1
$ export SERVICE_ACCOUNT_NAME=<service_account> 2
    1
    서비스 계정과 연결된 네임스페이스입니다.
    2
    서비스 계정의 이름입니다.

  2. Kubernetes 시크릿을 생성합니다. 

    $ oc create secret registry-credentials \
  --from-file=.dockerconfigjson \ 1
  --type=kubernetes.io/dockerconfigjson \
  -n $NAMESPACE
    1
    Docker 구성 파일의 경로로 바꿉니다. 기본 경로는 ~/.docker/config.json 입니다.

  3. 시크릿에 서비스 계정 액세스 권한을 부여합니다. 

    $ oc patch serviceaccount $SERVICE_ACCOUNT_NAME \
  -p "{\"imagePullSecrets\": [{\"name\": \"registry-credentials\"}]}" -n $NAMESPACE

    Red Hat OpenShift Pipelines가 모든 작업 실행에 할당하는 기본 파이프라인 서비스 계정을 패치하면 Red Hat OpenShift Pipelines Operator가 서비스 계정을 재정의합니다. 모범 사례로 다음 단계를 수행할 수 있습니다.

    1. 사용자 작업 실행에 할당할 별도의 서비스 계정을 생성합니다. 

      $ oc create serviceaccount <service_account_name>

    2. 작업 실행 템플릿에서 serviceaccountname 필드의 값을 설정하여 서비스 계정을 작업 실행에 연결합니다. 

      apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
name: build-push-task-run-2
spec:
serviceAccountName: build-bot 1
taskRef:
  name: build-push
...
      1
      새로 생성된 서비스 계정의 이름으로 바꿉니다.

3.17.5. 추가 인증없이 작업 실행 서명 생성 및 확인

추가 인증과 함께 Tekton Chains를 사용하여 작업 실행 서명을 확인하려면 다음 작업을 수행합니다.

  • 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.
  • Tekton 체인 백엔드 스토리지를 구성합니다.
  • 작업 실행을 생성하고 서명하고, 작업 실행 자체에 서명 및 페이로드를 주석으로 저장합니다.
  • 서명된 작업 실행에서 서명 및 페이로드를 검색합니다.
  • 작업 실행 서명을 확인합니다.

사전 요구 사항

다음 구성 요소가 클러스터에 설치되어 있는지 확인합니다.

  • Red Hat OpenShift Pipelines Operator
  • Tekton 체인
  • cosign

절차

  1. 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다. 키 쌍을 생성하여 시크릿으로 저장하는 방법에 대한 자세한 내용은 " Tekton 체인에서 시크릿 서명"을 참조하십시오.

  2. Tekton Chains 구성에서 OCI 스토리지를 비활성화하고 작업 실행 스토리지 및 형식을 tekton 로 설정합니다. TektonConfig 사용자 지정 리소스에서 다음 값을 설정합니다. 

    apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
  name: config
spec:
# ...
    chain:
      artifacts.oci.storage: ""
      artifacts.taskrun.format: tekton
      artifacts.taskrun.storage: tekton
# ...

    TektonConfig 사용자 지정 리소스를 사용하여 Tekton 체인 구성에 대한 자세한 내용은 " Tekton 체인 구성"을 참조하십시오.

  3. Tekton 체인 컨트롤러를 다시 시작하여 수정된 구성이 적용되었는지 확인하려면 다음 명령을 입력합니다. 

    $ oc delete po -n openshift-pipelines -l app=tekton-chains-controller

  4. 다음 명령을 입력하여 작업 실행을 생성합니다. 

    $ oc create -f https://raw.githubusercontent.com/tektoncd/chains/main/examples/taskruns/task-output-image.yaml 1
    1
    예제 URI를 작업 실행을 가리키는 URI 또는 파일 경로로 바꿉니다.

    출력 예

    taskrun.tekton.dev/build-push-run-output-image-qbjvh created

  5. 다음 명령을 입력하여 단계의 상태를 확인합니다. 프로세스가 완료될 때까지 기다립니다. 

    $ tkn tr describe --last

    출력 예

    [...truncated output...]
NAME                            STATUS
∙ create-dir-builtimage-9467f   Completed
∙ git-source-sourcerepo-p2sk8   Completed
∙ build-and-push                Completed
∙ echo                          Completed
∙ image-digest-exporter-xlkn7   Completed

  6. base64 로 인코딩된 주석으로 저장된 오브젝트에서 서명을 검색하려면 다음 명령을 입력합니다. 

    $ tkn tr describe --last -o jsonpath="{.metadata.annotations.chains\.tekton\.dev/signature-taskrun-$TASKRUN_UID}" | base64 -d > sig
    $ export TASKRUN_UID=$(tkn tr describe --last -o  jsonpath='{.metadata.uid}')
  7. 생성한 공개 키를 사용하여 서명을 확인하려면 다음 명령을 입력합니다. 
$ cosign verify-blob-attestation --insecure-ignore-tlog --key path/to/cosign.pub --signature sig --type slsaprovenance --check-claims=false /dev/null 1
1
path/to/cosign.pub 를 공개 키 파일의 경로 이름으로 바꿉니다.

출력 예

Verified OK

3.17.5.1. 추가 리소스

3.17.6. Tekton Chains를 사용하여 이미지 및 검증에 서명 및 확인

클러스터 관리자는 다음 작업을 수행하여 Tekton Chains를 사용하여 이미지와 검증에 서명하고 검증할 수 있습니다.

  • 암호화된 x509 키 쌍을 생성하여 Kubernetes 시크릿으로 저장합니다.
  • 이미지, 이미지 서명 및 서명된 이미지 인증서를 저장할 OCI 레지스트리에 대한 인증을 설정합니다.
  • Tekton Chains를 구성하고 서명할 수 있도록 구성합니다.
  • 작업 실행에서 Kaniko로 이미지를 만듭니다.
  • 서명된 이미지와 서명된 검증 정보를 확인합니다.

사전 요구 사항

클러스터에 다음이 설치되어 있는지 확인합니다.

  • Red Hat OpenShift Pipelines Operator
  • Tekton 체인
  • cosign
  • Rekor
  • jq

절차

  1. 암호화된 x509 키 쌍을 생성하고 Kubernetes 시크릿으로 저장합니다. 

    $ cosign generate-key-pair k8s://openshift-pipelines/signing-secrets

    메시지가 표시되면 암호를 입력합니다. cosign은 생성된 개인 키를 openshift-pipelines 네임스페이스에 signing-secrets Kubernetes 시크릿의 일부로 저장하고 공개 키를 cosign.pub 로컬 파일에 씁니다.

  2. 이미지 레지스트리에 대한 인증을 구성합니다.

    1. 서명을 OCI 레지스트리로 푸시하도록 Tekton Chains 컨트롤러를 구성하려면 작업 실행의 서비스 계정과 연결된 자격 증명을 사용합니다. 자세한 내용은 "COO 레지스트리에 대한 인증" 섹션을 참조하십시오.

    2. 이미지를 빌드하고 레지스트리로 푸시하는 Kaniko 작업에 대한 인증을 구성하려면 필요한 인증 정보가 포함된 docker config.json 파일의 Kubernetes 시크릿을 생성합니다. 

      $ oc create secret generic <docker_config_secret_name> \ 1
  --from-file <path_to_config.json> 2
      1
      docker 구성 보안의 이름으로 바꿉니다.
      2
      docker config.json 파일의 경로로 바꿉니다.

  3. chain-config 오브젝트에서 artifacts.taskrun.format,artifacts.taskrun.storage, transparency.enabled 매개변수를 설정하여 Tekton 체인 을 구성합니다. 

    $ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.format": "in-toto"}}'

$ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"artifacts.taskrun.storage": "oci"}}'

$ oc patch configmap chains-config -n openshift-pipelines -p='{"data":{"transparency.enabled": "true"}}'

  4. Kaniko 작업을 시작합니다.

    1. Kaniko 작업을 클러스터에 적용합니다. 

      $ oc apply -f examples/kaniko/kaniko.yaml 1
      1
      Kaniko 작업의 URI 또는 파일 경로로 바꿉니다.

    2. 적절한 환경 변수를 설정합니다. 

      $ export REGISTRY=<url_of_registry> 1

$ export DOCKERCONFIG_SECRET_NAME=<name_of_the_secret_in_docker_config_json> 2
      1
      이미지를 푸시하려는 레지스트리의 URL로 바꿉니다.
      2
      docker config.json 파일에서 보안 이름으로 바꿉니다.

    3. Kaniko 작업을 시작합니다. 

      $ tkn task start --param IMAGE=$REGISTRY/kaniko-chains --use-param-defaults --workspace name=source,emptyDir="" --workspace name=dockerconfig,secret=$DOCKERCONFIG_SECRET_NAME kaniko-chains

      모든 단계가 완료될 때까지 이 작업의 로그를 관찰합니다. 인증에 성공하면 최종 이미지가 $REGISTRY/kaniko-chains 로 푸시됩니다.

  5. Tekton Chains가 이를 생성하고 서명할 수 있도록 1분 정도 기다린 다음 작업 실행에서 chain.tekton.dev/signed=true 주석의 가용성을 확인합니다. 

    $ oc get tr <task_run_name> \ 1
-o json | jq -r .metadata.annotations

{
  "chains.tekton.dev/signed": "true",
  ...
}
    1
    작업 실행 이름으로 바꿉니다.

  6. 이미지와 attestation을 확인합니다. 

    $ cosign verify --key cosign.pub $REGISTRY/kaniko-chains

$ cosign verify-attestation --key cosign.pub $REGISTRY/kaniko-chains

  7. Rekor에서 이미지의 입증된 정보를 찾으십시오.

    1. $REGISTRY/kaniko-chains 이미지의 다이제스트를 가져옵니다. 작업 실행을 검색하거나 이미지를 가져와서 다이제스트를 추출할 수 있습니다.

    2. Rekor를 검색하여 이미지의 sha256 다이제스트와 일치하는 모든 항목을 찾습니다. 

      $ rekor-cli search --sha <image_digest> 1

<uuid_1> 2
<uuid_2> 3
...
      1
      이미지 sha256 다이제스트로 바꿉니다.
      2
      처음 일치하는 UUID(Universally unique identifier)입니다.
      3
      두 번째와 일치하는 UUID입니다.

      검색 결과에는 일치하는 항목의 UUID가 표시됩니다. 이러한 UUID 중 하나에는 검증이 있습니다.

    3. 인증서를 확인하십시오. 

      $ rekor-cli get --uuid <uuid> --format json | jq -r .Attestation | base64 --decode | jq

3.17.7. 추가 리소스

3.18. OpenShift Logging Operator를 사용하여 파이프라인 로그 보기

파이프라인 실행, 작업 실행, 이벤트 리스너로 생성된 로그는 해당 Pod에 저장됩니다. 문제 해결 및 감사의 로그를 검토하고 분석하는 것이 유용합니다.

그러나 Pod를 무기한 유지하면 불필요한 리소스 소비 및 세분화된 네임스페이스가 발생합니다.

파이프라인 로그를 보기 위해 Pod에 대한 종속성을 제거하려면 OpenShift Elasticsearch Operator 및 OpenShift Logging Operator를 사용할 수 있습니다. 이러한 Operator를 사용하면 로그가 포함된 Pod를 삭제한 후에도 Elasticsearch Kibana 스택을 사용하여 파이프라인 로그를 볼 수 있습니다.

3.18.1. 사전 요구 사항

Kibana 대시보드에서 파이프라인 로그를 보기 전에 다음을 확인하십시오.

  • 단계는 클러스터 관리자가 수행합니다.
  • 파이프라인 실행 및 작업 실행에 대한 로그를 사용할 수 있습니다.
  • OpenShift Elasticsearch Operator 및 OpenShift Logging Operator가 설치되어 있습니다.

3.18.2. Kibana에서 파이프라인 로그 보기

Kibana 웹 콘솔에서 파이프라인 로그를 보려면 다음을 수행합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 메뉴 표시줄의 오른쪽 상단에서 Grid icon → Observability → Logging 을 클릭합니다. Kibana 웹 콘솔이 표시됩니다.

  3. 인덱스 패턴을 생성합니다.

    1. Kibana 웹 콘솔의 왼쪽 탐색 패널에서 관리를 클릭합니다.
    2. 인덱스 패턴 만들기를 클릭합니다.
    3. 2 단계: 인덱스 패턴 → 인덱스 패턴 정의 패턴 에서 * 패턴을 입력하고 다음 단계를 클릭합니다.
    4. 2 단계 : 설정 → 시간 필터 필드 이름 구성, 드롭다운 메뉴에서 @timestamp 를 선택하고 인덱스 패턴 만들기를 클릭합니다.

  4. 필터를 추가합니다.

    1. Kibana 웹 콘솔의 왼쪽 탐색 패널에서 Discover 를 클릭합니다.

    2. 필터 추가 + → 쿼리 DSL 편집 을 클릭합니다.

      참고
      • 다음 각 예제 필터에 대해 쿼리를 편집하고 저장을 클릭합니다.
      • 필터가 차례로 적용됩니다.

      1. 파이프라인과 관련된 컨테이너를 필터링합니다.

        파이프라인 컨테이너를 필터링하기 위한 쿼리 예

        {
  "query": {
	"match": {
  	"kubernetes.flat_labels": {
    	"query": "app_kubernetes_io/managed-by=tekton-pipelines",
    	"type": "phrase"
  	}
	}
  }
}

      2. tools 컨테이너가 아닌 모든 컨테이너를 필터링합니다. 쿼리 DSL을 편집하는 대신 그래픽 드롭다운 메뉴를 사용하는 방법을 보여줍니다.

        그림 3.6. 드롭다운 필드를 사용하여 필터링의 예

        place-tools가 아님

      3. 강조 표시를 위해 라벨에 pipelinerun 을 필터링합니다.

        강조를 위해 라벨에서 pipelinerun 을 필터링하는 쿼리의 예

        {
  "query": {
	"match": {
  	"kubernetes.flat_labels": {
    	"query": "tekton_dev/pipelineRun=",
    	"type": "phrase"
  	}
	}
  }
}

      4. 강조 표시를 위해 라벨에서 파이프라인 을 필터링합니다.

        강조 표시에 대해 라벨에서 파이프라인 을 필터링하는 쿼리의 예

        {
  "query": {
	"match": {
  	"kubernetes.flat_labels": {
    	"query": "tekton_dev/pipeline=",
    	"type": "phrase"
  	}
	}
  }
}

    3. Available 필드 목록에서 다음 필드를 선택합니다.

      • kubernetes.flat_labels

      • message

        선택한 필드가 Selected fields 목록에 표시되는지 확인합니다.

    4. 로그는 message 필드 아래에 표시됩니다.

      그림 3.7. 필터링된 메시지

      필터링된 메시지

3.18.3. 추가 리소스

3.19. Buildah를 루트가 아닌 사용자로 사용하여 컨테이너 이미지 빌드

컨테이너에서 root 사용자로 OpenShift Pipelines를 실행하면 컨테이너 프로세스 및 호스트를 다른 악성 리소스에 노출할 수 있습니다. 워크로드를 컨테이너에서 루트가 아닌 특정 사용자로 실행하여 이러한 유형의 노출을 줄일 수 있습니다. Buildah를 루트가 아닌 사용자로 사용하여 컨테이너 이미지의 빌드를 실행하려면 다음 단계를 수행할 수 있습니다.

  • SA(사용자 정의 서비스 계정) 및 SCC(보안 컨텍스트 제약 조건)를 정의합니다.
  • ID 1000 으로 빌드 사용자를 사용하도록 Buildah를 구성합니다.
  • 사용자 정의 구성 맵을 사용하여 작업 실행을 시작하거나 파이프라인 실행과 통합합니다.

3.19.1. 사용자 정의 서비스 계정 및 보안 컨텍스트 제약 조건 구성

기본 파이프라인 SA를 사용하면 네임스페이스 범위 외부에서 사용자 ID를 사용할 수 있습니다. 기본 SA에 대한 종속성을 줄이기 위해 사용자 ID가 1000 인 빌드 사용자에 대해 필요한 클러스터 역할 및 역할 바인딩을 사용하여 사용자 정의 SA 및 SCC를 정의할 수 있습니다.

중요

현재 컨테이너에서 Buildah를 성공적으로 실행하려면 allowPrivilegeEscalation 설정을 활성화해야 합니다. 이 설정을 통해 Buildah는 루트가 아닌 사용자로 실행할 때 SETUID 및 SETGID 기능을 활용할 수 있습니다.

절차

  • 필요한 클러스터 역할 및 역할 바인딩을 사용하여 사용자 지정 SA 및 SCC를 만듭니다.

    예: ID 1000을 사용하는 사용자 정의 SA 및 SCC

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipelines-sa-userid-1000 1
---
kind: SecurityContextConstraints
metadata:
  annotations:
  name: pipelines-scc-userid-1000 2
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true 3
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: MustRunAs
groups:
- system:cluster-admins
priority: 10
readOnlyRootFilesystem: false
requiredDropCapabilities:
- MKNOD
- KILL
runAsUser: 4
  type: MustRunAs
  uid: 1000
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
users: []
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-scc-userid-1000-clusterrole 5
rules:
- apiGroups:
  - security.openshift.io
  resourceNames:
  - pipelines-scc-userid-1000
  resources:
  - securitycontextconstraints
  verbs:
  - use
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pipelines-scc-userid-1000-rolebinding 6
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pipelines-scc-userid-1000-clusterrole
subjects:
- kind: ServiceAccount
  name: pipelines-sa-userid-1000

1
사용자 정의 SA를 정의합니다.
2
수정된 runAsUser 필드를 사용하여 제한된 권한을 기반으로 생성된 사용자 정의 SCC를 정의합니다.
3
현재 컨테이너에서 Buildah를 성공적으로 실행하려면 allowPrivilegeEscalation 설정을 활성화해야 합니다. 이 설정을 통해 Buildah는 루트가 아닌 사용자로 실행할 때 SETUID 및 SETGID 기능을 활용할 수 있습니다.
4
사용자 지정 SA를 통해 사용자 정의 SCC와 연결된 모든 Pod를 제한하여 사용자 ID 1000 으로 실행합니다.
5
사용자 지정 SCC를 사용하는 클러스터 역할을 정의합니다.
6
사용자 지정 SCC를 사용하는 클러스터 역할을 사용자 지정 SA에 바인딩합니다.

3.19.2. 빌드 사용자를 사용하도록 Buildah 구성

사용자 ID 1000 으로 빌드 사용자를 사용하도록 Buildah 작업을 정의할 수 있습니다.

절차

  1. buildah 클러스터 작업의 사본을 일반 작업으로 생성합니다. 

    $ oc get clustertask buildah -o yaml | yq '. |= (del .metadata |= with_entries(select(.key == "name" )))' | yq '.kind="Task"' | yq '.metadata.name="buildah-as-user"' | oc create -f -

  2. 복사한 buildah 작업을 편집합니다. 

    $ oc edit task buildah-as-user

    예: 빌드 사용자가 포함된 Modified Buildah 작업

    apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: buildah-as-user
spec:
  description: >-
    Buildah task builds source into a container image and
    then pushes it to a container registry.
    Buildah Task builds source into a container image using Project Atomic's
    Buildah build tool.It uses Buildah's support for building from Dockerfiles,
    using its buildah bud command.This command executes the directives in the
    Dockerfile to assemble a container image, then pushes that image to a
    container registry.
  params:
  - name: IMAGE
    description: Reference of the image buildah will produce.
  - name: BUILDER_IMAGE
    description: The location of the buildah builder image.
    default: registry.redhat.io/rhel8/buildah@sha256:99cae35f40c7ec050fed3765b2b27e0b8bbea2aa2da7c16408e2ca13c60ff8ee
  - name: STORAGE_DRIVER
    description: Set buildah storage driver
    default: vfs
  - name: DOCKERFILE
    description: Path to the Dockerfile to build.
    default: ./Dockerfile
  - name: CONTEXT
    description: Path to the directory to use as context.
    default: .
  - name: TLSVERIFY
    description: Verify the TLS on the registry endpoint (for push/pull to a non-TLS registry)
    default: "true"
  - name: FORMAT
    description: The format of the built container, oci or docker
    default: "oci"
  - name: BUILD_EXTRA_ARGS
    description: Extra parameters passed for the build command when building images.
    default: ""
  - description: Extra parameters passed for the push command when pushing images.
    name: PUSH_EXTRA_ARGS
    type: string
    default: ""
  - description: Skip pushing the built image
    name: SKIP_PUSH
    type: string
    default: "false"
  results:
  - description: Digest of the image just built.
    name: IMAGE_DIGEST
    type: string
  workspaces:
  - name: source
  steps:
  - name: build
    securityContext:
      runAsUser: 1000 1
    image: $(params.BUILDER_IMAGE)
    workingDir: $(workspaces.source.path)
    script: |
      echo "Running as USER ID `id`" 2
      buildah --storage-driver=$(params.STORAGE_DRIVER) bud \
        $(params.BUILD_EXTRA_ARGS) --format=$(params.FORMAT) \
        --tls-verify=$(params.TLSVERIFY) --no-cache \
        -f $(params.DOCKERFILE) -t $(params.IMAGE) $(params.CONTEXT)
      [[ "$(params.SKIP_PUSH)" == "true" ]] && echo "Push skipped" && exit 0
      buildah --storage-driver=$(params.STORAGE_DRIVER) push \
        $(params.PUSH_EXTRA_ARGS) --tls-verify=$(params.TLSVERIFY) \
        --digestfile $(workspaces.source.path)/image-digest $(params.IMAGE) \
        docker://$(params.IMAGE)
      cat $(workspaces.source.path)/image-digest | tee /tekton/results/IMAGE_DIGEST
    volumeMounts:
    - name: varlibcontainers
      mountPath: /home/build/.local/share/containers 3
  volumes:
  - name: varlibcontainers
    emptyDir: {}

    1
    Buildah 이미지의 빌드 사용자에 해당하는 사용자 ID 1000 으로 명시적으로 컨테이너를 실행합니다.
    2
    사용자 ID를 표시하여 프로세스가 사용자 ID 1000 으로 실행 중인지 확인합니다.
    3
    필요에 따라 볼륨 마운트의 경로를 변경할 수 있습니다.

3.19.3. 사용자 정의 구성 맵 또는 파이프라인 실행을 사용하여 작업 실행 시작

사용자 정의 Buildah 클러스터 작업을 정의한 후 사용자 ID가 1000 인 빌드 사용자로 이미지를 빌드하는 TaskRun 오브젝트를 생성할 수 있습니다. 또한 TaskRun 오브젝트를 PipelineRun 오브젝트의 일부로 통합할 수 있습니다.

절차

  1. 사용자 정의 ConfigMap 및 Dockerfile 오브젝트를 사용하여 TaskRun 오브젝트를 생성합니다.

    예: 사용자 ID 1000으로 Buildah를 실행하는 작업 실행

    apiVersion: v1
data:
  Dockerfile: |
    ARG BASE_IMG=registry.access.redhat.com/ubi9/ubi
    FROM $BASE_IMG AS buildah-runner
    RUN dnf -y update && \
        dnf -y install git && \
        dnf clean all
    CMD git
kind: ConfigMap
metadata:
  name: dockerfile 1
---
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: buildah-as-user-1000
spec:
  serviceAccountName: pipelines-sa-userid-1000 2
  params:
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
  taskRef:
    kind: Task
    name: buildah-as-user
  workspaces:
  - configMap:
      name: dockerfile 3
    name: source

    1
    Dockerfile을 사용하여 일부 소스를 가져오는 이전 작업 없이 작업 실행에 중점을 두므로 구성 맵을 사용합니다.
    2
    생성한 서비스 계정의 이름입니다.
    3
    구성 맵을 buildah-as-user 작업의 소스 작업 공간으로 마운트합니다.

  2. (선택 사항) 파이프라인 및 해당 파이프라인 실행을 생성합니다.

    예: 파이프라인 및 해당 파이프라인 실행

    apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: pipeline-buildah-as-user-1000
spec:
  params:
  - name: IMAGE
  - name: URL
  workspaces:
  - name: shared-workspace
  - name: sslcertdir
    optional: true
  tasks:
  - name: fetch-repository 1
    taskRef:
      name: git-clone
      kind: ClusterTask
    workspaces:
    - name: output
      workspace: shared-workspace
    params:
    - name: url
      value: $(params.URL)
    - name: subdirectory
      value: ""
    - name: deleteExisting
      value: "true"
  - name: buildah
    taskRef:
      name: buildah-as-user 2
    runAfter:
    - fetch-repository
    workspaces:
    - name: source
      workspace: shared-workspace
    - name: sslcertdir
      workspace: sslcertdir
    params:
    - name: IMAGE
      value: $(params.IMAGE)
---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: pipelinerun-buildah-as-user-1000
spec:
  taskRunSpecs:
    - pipelineTaskName: buildah
      taskServiceAccountName: pipelines-sa-userid-1000 3
  params:
  - name: URL
    value: https://github.com/openshift/pipelines-vote-api
  - name: IMAGE
    value: image-registry.openshift-image-registry.svc:5000/test/buildahuser
  pipelineRef:
    name: pipeline-buildah-as-user-1000
  workspaces:
  - name: shared-workspace 4
    volumeClaimTemplate:
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 100Mi

    1
    git-clone 클러스터 작업을 사용하여 Dockerfile이 포함된 소스를 가져와서 수정된 Buildah 작업을 사용하여 빌드합니다.
    2
    수정된 Buildah 작업을 참조하십시오.
    3
    Buildah 작업에 대해 생성한 서비스 계정을 사용합니다.
    4
    컨트롤러에서 자동으로 생성한 PVC(영구 볼륨 클레임)를 사용하여 git-clone 작업과 수정된 Buildah 작업 간 데이터를 공유합니다.
  3. 작업 실행 또는 파이프라인 실행을 시작합니다.

3.19.4. 권한이 없는 빌드의 제한

권한이 없는 빌드의 프로세스는 대부분의 Dockerfile 오브젝트에서 작동합니다. 그러나 몇 가지 알려진 제한으로 인해 빌드가 실패할 수 있습니다.

  • 필요한 권한 문제가 없기 때문에 --mount=type=cache 옵션을 사용하지 못할 수 있습니다. 자세한 내용은 이 문서 를 참조하십시오.
  • 마운트 리소스에는 사용자 정의 SCC에서 제공하지 않는 추가 기능이 필요하므로 --mount=type=secret 옵션을 사용할 수 없습니다.

추가 리소스

4장. GitOps

4.1. Red Hat OpenShift GitOps 릴리스 정보

Red Hat OpenShift GitOps는 클라우드 네이티브 애플리케이션에 대한 연속 배포를 구현하는 선언적 방법입니다. Red Hat OpenShift GitOps를 사용하면 개발, 스테이징, 프로덕션과 같은 다양한 환경의 다양한 클러스터에 애플리케이션을 배포할 때 애플리케이션의 일관성을 유지할 수 있습니다. Red Hat OpenShift GitOps는 다음 작업을 자동화하는 데 도움이 됩니다.

  • 클러스터의 구성, 모니터링, 스토리지 상태가 비슷한지 확인
  • 알려진 상태에서 클러스터 복구 또는 재생성
  • 여러 OpenShift Container Platform 클러스터에 구성 변경 사항 적용 또는 되돌리기
  • 템플릿 구성을 다른 환경과 연결
  • 스테이징에서 프로덕션까지 클러스터 전체에서 애플리케이션 승격

Red Hat OpenShift GitOps 개요는 OpenShift GitOps 이해를 참조하십시오.

4.1.1. 호환성 및 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

아래 표에서 기능은 다음과 같은 상태로 표시되어 있습니다.

  • TP: 기술 프리뷰
  • GA: 상용 버전
  • IRQ:해당되지 않음
중요

OpenShift Container Platform 4.13에서는 stable 채널이 제거되었습니다. OpenShift Container Platform 4.13으로 업그레이드하기 전에 이미 stable 채널에 있는 경우 적절한 채널을 선택하고 전환합니다.

OpenShift GitOps구성 요소 버전OpenShift 버전

버전

kam

Helm

kustomize

Argo CD

ApplicationSet

dex

RH SSO

 

1.9.0

0.0.49 TP

3.11.2 GA

5.0.1 GA

2.7.2 GA

해당 없음

2.35.1 GA

7.5.1 GA

4.12-4.13

1.8.0

0.0.47 TP

3.10.0 GA

4.5.7 GA

2.6.3 GA

해당 없음

2.35.1 GA

7.5.1 GA

4.10-4.13

1.7.0

0.0.46 TP

3.10.0 GA

4.5.7 GA

2.5.4 GA

해당 없음

2.35.1 GA

7.5.1 GA

4.10-4.12

1.6.0

0.0.46 TP

3.8.1 GA

4.4.1 GA

2.4.5 GA

GA 및 ArgoCD 구성 요소에 포함

2.30.3 GA

7.5.1 GA

4.8-4.11

1.5.0

0.0.42 TP

3.8.0 GA

4.4.1 GA

2.3.3 GA

0.4.1 TP

2.30.3 GA

7.5.1 GA

4.8-4.11

1.4.0

0.0.41 TP

3.7.1 GA

4.2.0 GA

2.2.2 GA

0.2.0 TP

2.30.0 GA

7.4.0 GA

4.7-4.10

1.3.0

0.0.40 TP

3.6.0 GA

4.2.0 GA

2.1.2 GA

0.2.0 TP

2.28.0 GA

7.4.0 GA

4.7-4.9, 4.6 제한 GA 지원

1.2.0

0.0.38 TP

3.5.0 GA

3.9.4 GA

2.0.5 GA

0.1.0 TP

해당 없음

7.4.0 GA

4.8

1.1.0

0.0.32 TP

3.5.0 GA

3.9.4 GA

2.0.0 GA

해당 없음

해당 없음

해당 없음

4.7

  • Kam 은 Red Hat OpenShift GitOps Application Manager CLI(명령줄 인터페이스)입니다.
  • RH SSO는 Red Hat SSO의 약어입니다.

4.1.1.1. 기술 프리뷰 기능

다음 표에 언급된 기능은 현재 TP(기술 프리뷰)에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

표 4.1. 기술 프리뷰

기능Red Hat OpenShift GitOps 버전의 TPRed Hat OpenShift GitOps 버전의 GA

사용자 정의 must-gather 툴

1.9.0

해당 없음

Argo Rollouts

1.9.0

해당 없음

ApplicationSet Progressive Rollout 전략

1.8.0

해당 없음

애플리케이션에 대한 여러 소스

1.8.0

해당 없음

비 컨트롤 플레인 네임스페이스의 Argo CD 애플리케이션

1.7.0

해당 없음

Argo CD 알림 컨트롤러

1.6.0

해당 없음

OpenShift Container Platform 웹 콘솔의 개발자 화면에 있는 Red Hat OpenShift GitOps 환경 페이지 

1.1.0

해당 없음

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

4.1.3. Red Hat OpenShift GitOps 1.9.1 릴리스 노트

Red Hat OpenShift GitOps 1.9.1은 이제 OpenShift Container Platform 4.12 및 4.13에서 사용할 수 있습니다.

4.1.3.1. 에라타 업데이트

4.1.3.1.1. RHSA-2023:3591 및 RHBA-2023:4117 - Red Hat OpenShift GitOps 1.9.1 보안 업데이트 권고

출시 날짜: 2023-07-17

이 릴리스에 포함된 보안 수정 목록은 다음 권고에 설명되어 있습니다.

Red Hat OpenShift GitOps Operator를 설치한 경우 다음 명령을 실행하여 이 릴리스의 컨테이너 이미지를 확인합니다. 

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

4.1.3.2. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 업데이트를 통해 번들된 Argo CD가 버전 2.7.6으로 업데이트되었습니다.

4.1.3.3. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 네임스페이스 및 애플리케이션이 증가할 때 Argo CD가 응답하지 않고 있었습니다. 이번 업데이트에서는 교착 상태를 제거하여 문제가 해결되었습니다. 교착 상태는 두 기능이 리소스에 대해 경쟁할 때 발생합니다. 이제 네임스페이스 또는 애플리케이션이 증가하면 충돌이 발생하거나 응답하지 않아야 합니다. GITOPS-2782
  • 이번 업데이트 이전에는 애플리케이션을 다시 동기화할 때 Argo CD 애플리케이션 컨트롤러 리소스가 갑자기 작동을 중지할 수 있었습니다. 이번 업데이트에서는 클러스터 캐시 교착 상태를 방지하기 위해 논리를 추가하여 문제를 해결합니다. 이제 교착 상태가 발생하지 않아야 하며 애플리케이션이 성공적으로 재동기화되어야 합니다. GITOPS-2880
  • 이번 업데이트 이전에는 argocd-ssh-known-hosts-cm 구성 맵의 알려진 호스트에 대한 RSA 키에 일치하지 않았습니다. 이번 업데이트에서는 RSA 키와 업스트림 프로젝트와 일치하여 문제가 해결되었습니다. 이제 기본 배포에서 기본 RSA 키를 사용할 수 있습니다. GITOPS-3042
  • 이번 업데이트 이전에는 argocd-cm 구성 맵의 조정 시간 초과 설정이 Argo CD 애플리케이션 컨트롤러 리소스에 올바르게 적용되지 않았습니다. 이번 업데이트에서는 argocd-cm 구성 맵에서 조정 시간 초과 설정을 올바르게 읽고 적용하여 문제를 해결합니다. 이제 문제 없이 AppSync 설정에서 조정 제한 시간 값을 수정할 수 있습니다. GITOPS-2810

4.1.4. Red Hat OpenShift GitOps 1.9.0 릴리스 노트

Red Hat OpenShift GitOps 1.9.0은 이제 OpenShift Container Platform 4.12 및 4.13에서 사용할 수 있습니다.

4.1.4.1. 에라타 업데이트

4.1.4.1.1. RHSA-2023:3557 - Red Hat OpenShift GitOps 1.9.0 보안 업데이트 권고

출시 날짜: 2023-06-09

이 릴리스에 포함된 보안 수정 목록은 다음 권고에 설명되어 있습니다.

Red Hat OpenShift GitOps Operator를 설치한 경우 다음 명령을 실행하여 이 릴리스의 컨테이너 이미지를 확인합니다. 

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

4.1.4.2. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 업데이트를 통해 사용자 정의 must-gather 툴을 사용하여 프로젝트 수준 리소스, 클러스터 수준 리소스 및 Red Hat OpenShift GitOps 구성 요소에 대한 진단 정보를 수집할 수 있습니다. 이 툴은 분석을 위해 Red Hat 지원 팀과 공유할 수 있는 Red Hat OpenShift GitOps와 관련된 클러스터에 대한 디버깅 정보를 제공합니다. GITOPS-2797

    중요

    사용자 정의 must-gather 툴은 기술 프리뷰 기능입니다.

  • 이번 업데이트를 통해 Argo Rollouts를 사용하여 점진적인 제공에 지원을 추가할 수 있습니다. 현재 지원되는 트래픽 관리자는 Red Hat OpenShift Service Mesh입니다. GITOPS-959

    중요

    Argo Rollouts는 기술 프리뷰 기능입니다.

추가 리소스

4.1.4.3. 사용되지 않거나 삭제된 기능

  • Red Hat OpenShift GitOps 1.7.0에서는 .spec.resourceCustomizations 매개변수가 더 이상 사용되지 않습니다. 더 이상 사용되지 않는 .spec.resourceCustomizations 매개변수는 향후 Red Hat OpenShift GitOps GA v1.10.0 릴리스에서 제거될 예정입니다. 새 형식 spec.ResourceHealthChecks,spec.ResourceIgnoreDifferences, spec.ResourceActions 를 대신 사용할 수 있습니다. GITOPS-2890

  • 이번 업데이트를 통해 다음 더 이상 사용되지 않는 sso 및 dex 필드에 대한 지원이 향후 Red Hat OpenShift GitOps GA v1.10.0 릴리스까지 확장됩니다.

    • .spec.sso.image,.spec.sso.version,.spec.sso.resources .spec.sso.verifyTLS 필드입니다.

    • DISABLE_DEX 와 함께 .spec.dex 매개변수입니다.

      더 이상 사용되지 않는 이전 sso 및 dex 필드는 Red Hat OpenShift GitOps v1.9.0 릴리스에서 제거될 예정이었지만 이제 Red Hat OpenShift GitOps GA v1.10.0 릴리스에서 제거될 예정입니다. GITOPS-2904

4.1.4.4. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 argocd-server-tls 시크릿이 새 인증서 Argo CD로 업데이트되었을 때 항상 이 시크릿을 선택하지는 않았습니다. 그 결과 이전 만료된 인증서가 표시되었습니다. 이번 업데이트에서는 새로운 GetCertificate 함수의 문제가 해결되어 최신 버전의 인증서가 사용 중인지 확인합니다. 새 인증서를 추가할 때 Argo CD는 사용자가 argocd-server Pod를 다시 시작할 필요 없이 자동으로 선택합니다. GITOPS-2375
  • 이번 업데이트 이전에는 서명된 Git 태그를 가리키는 targetRevision 정수에 대해 GPG 서명 확인을 적용할 때 Git에서 대상 리버전이 서명되지 않은 오류가 발생했습니다. 이번 업데이트에서는 이 문제가 해결되어 사용자가 서명된 Git 태그에 대해 GPG 서명 확인을 적용할 수 있습니다. GITOPS-2418
  • 이번 업데이트 이전에는 Operator에서 배포한 Argo CD를 통해 Microsoft Team Foundation Server(TFS) 유형 Git 리포지토리에 연결할 수 없었습니다. 이번 업데이트에서는 Operator에서 Git 버전을 2.39.3으로 업데이트하여 문제를 해결합니다. GITOPS-2768
  • 이번 업데이트 이전에는 HA(고가용성) 기능이 활성화된 상태에서 Operator를 배포하고 실행할 때 .spec.ha.resources 필드에서 리소스 제한을 설정하면 Redis HA Pod에 영향을 미치지 않았습니다. 이번 업데이트에서는 Redis 조정 코드에 검사를 추가하여 조정이 수정되었습니다. 이러한 검사를 통해 Argo CD CR(사용자 정의 리소스)의 spec.ha.resources 필드가 업데이트되었는지 확인합니다. Argo CD CR이 HA의 새 CPU 및 메모리 요청 또는 제한 값으로 업데이트되면 이제 이러한 변경 사항이 Redis HA 포드에 적용됩니다. GITOPS-2404
  • 이번 업데이트 이전에는 managed-by 레이블을 사용하여 네임스페이스 범위의 Argo CD 인스턴스에서 여러 네임스페이스를 관리하고 있고 관리된 네임스페이스 중 하나가 Terminating 상태인 경우 Argo CD 인스턴스는 리소스를 다른 모든 관리 네임스페이스에 배포할 수 없었습니다. 이번 업데이트에서는 Operator에서 이전에 관리되는 이제 네임스페이스 종료에서 managed-by 레이블을 제거할 수 있으므로 이 문제가 해결되었습니다. 이제 네임스페이스 범위의 Argo CD 인스턴스에서 관리하는 종료 네임스페이스가 다른 관리 네임스페이스에 대한 리소스 배포를 차단하지 않습니다. GITOPS-2627

4.1.4.5. 확인된 문제

  • 현재 Argo CD는 argocd-tls-certs-cm 구성 맵에 지정된 경로에서 TLS(Transport Layer Security) 인증서를 읽지 않으므로 알 수 없는 권한 오류로 인해 x509: 인증서가 서명됩니다.

    해결방법: 다음 단계를 수행합니다.

    1. SSL_CERT_DIR 환경 변수를 추가합니다.

      Argo CD 사용자 정의 리소스의 예

      apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: repo
spec:
   ...
  repo:
    env:
      - name: SSL_CERT_DIR
        value: /tmp/sslcertdir
    volumeMounts:
      - name: ssl
        mountPath: /tmp/sslcertdir
    volumes:
      - name: ssl
        configMap:
          name: user-ca-bundle
   ...

    2. Operator의 서브스크립션이 존재하고 다음 라벨을 포함하는 네임스페이스에 빈 구성 맵을 생성합니다.

      구성 맵 예

      apiVersion: v1
kind: ConfigMap
metadata:
  name: user-ca-bundle 1
  labels:
    config.openshift.io/inject-trusted-cabundle: "true" 2

      1
      구성 맵의 이름입니다.
      2
      CNO(Cluster Network Operator)에 병합된 번들을 삽입하도록 요청합니다.

      이 구성 맵을 생성하면 openshift-config 네임스페이스의 user-ca-bundle 콘텐츠가 이 구성 맵에 자동으로 삽입되어 시스템 ca-bundle과 병합됩니다. GITOPS-1482

추가 리소스

4.1.5. Red Hat OpenShift GitOps 1.8.4 릴리스 노트

Red Hat OpenShift GitOps 1.8.4는 이제 OpenShift Container Platform 4.10, 4.11, 4.12 및 4.13에서 사용할 수 있습니다.

4.1.5.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 업데이트를 통해 번들된 Argo CD가 버전 2.6.13으로 업데이트되었습니다.

4.1.5.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 네임스페이스 및 애플리케이션이 증가할 때 Argo CD가 응답하지 않고 있었습니다. 리소스에 대해 경쟁하는 기능으로 인해 교착 상태가 발생합니다. 이번 업데이트에서는 교착 상태를 제거하여 문제가 해결되었습니다. 이제 네임스페이스 또는 애플리케이션이 증가하면 충돌이 발생하거나 응답하지 않아야 합니다. GITOPS-3192
  • 이번 업데이트 이전에는 애플리케이션을 다시 동기화할 때 Argo CD 애플리케이션 컨트롤러 리소스가 갑자기 작동을 중지할 수 있었습니다. 이번 업데이트에서는 클러스터 캐시 교착 상태를 방지하기 위해 논리를 추가하여 문제를 해결합니다. 이제 애플리케이션이 성공적으로 다시 동기화됩니다. GITOPS-3052
  • 이번 업데이트 이전에는 argocd-ssh-known-hosts-cm 구성 맵의 알려진 호스트에 대한 RSA 키에 일치하지 않았습니다. 이번 업데이트에서는 RSA 키와 업스트림 프로젝트와 일치하여 문제가 해결되었습니다. 이제 기본 배포에서 기본 RSA 키를 사용할 수 있습니다. GITOPS-3144
  • 이번 업데이트 이전에는 Red Hat OpenShift GitOps Operator를 배포할 때 이전 Redis 이미지 버전이 사용되어 취약점이 발생했습니다. 이번 업데이트에서는 최신 버전의 registry.redhat.io/rhel-8/redis-6 이미지로 업그레이드하여 Redis의 취약점을 수정합니다. GITOPS-3069
  • 이번 업데이트 이전에는 Operator에서 배포한 Argo CD를 통해 Microsoft Team Foundation Server(TFS) 유형 Git 리포지토리에 연결할 수 없었습니다. 이번 업데이트에서는 Operator에서 Git 버전을 2.39.3으로 업데이트하여 문제를 해결합니다. 이제 리포지토리 구성 중에 TFS 유형 Git 리포지토리를 사용하여 연결하도록 Force HTTP 기본 auth 플래그를 설정할 수 있습니다. GITOPS-1315

4.1.5.3. 확인된 문제

  • 현재 Red Hat OpenShift GitOps 1.8.4는 OpenShift Container Platform 4.10 및 4.11의 최신 채널에서 제공되지 않습니다. 최신 채널은 GitOps 1.9.z에서 가져온 것으로, OpenShift Container Platform 4.12 이상 버전에서만 릴리스됩니다.

    이 문제를 해결하려면 gitops-1.8 채널로 전환하여 새 업데이트를 가져옵니다. GITOPS-3158

4.1.6. Red Hat OpenShift GitOps 1.8.3 릴리스 노트

Red Hat OpenShift GitOps 1.8.3은 이제 OpenShift Container Platform 4.10, 4.11, 4.12, 4.13에서 사용할 수 있습니다.

4.1.6.1. 에라타 업데이트

4.1.6.1.1. RHBA-2023:3206 및 RHSA-2023:3229 - Red Hat OpenShift GitOps 1.8.3 보안 업데이트 권고

출시 날짜: 2023-05-18

이 릴리스에 포함된 보안 수정 목록은 다음 권고에 설명되어 있습니다.

Red Hat OpenShift GitOps Operator를 설치한 경우 다음 명령을 실행하여 이 릴리스의 컨테이너 이미지를 확인합니다. 

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

4.1.6.2. 해결된 문제

  • 이번 업데이트 이전에는 Autoscale 이 활성화되고 HPA(수평 Pod 자동 스케일러) 컨트롤러에서 서버 배포의 복제본 설정을 편집하려고 하면 Operator가 이를 덮어씁니다. 또한 자동 스케일러 매개변수에 지정된 모든 변경 사항이 클러스터의 HPA에 올바르게 전달되지 않았습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 이제 Operator는 Autoscale 이 비활성화되고 HPA 매개변수가 올바르게 업데이트되는 경우에만 복제본 드리프트에 맞게 조정합니다. GITOPS-2629

4.1.7. Red Hat OpenShift GitOps 1.8.2 릴리스 노트

Red Hat OpenShift GitOps 1.8.2는 이제 OpenShift Container Platform 4.10, 4.11, 4.12, 4.13에서 사용할 수 있습니다.

4.1.7.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 .spec.dex 매개변수를 사용하여 Dex를 구성하고 LOG IN VIA OPENSHIFT 옵션을 사용하여 Argo CD UI에 로그인하려고 하면 로그인할 수 없었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다.

    중요

    ArgoCD CR의 spec.dex 매개변수는 더 이상 사용되지 않습니다. Red Hat OpenShift GitOps v1.9의 향후 릴리스에서는 ArgoCD CR의 spec.dex 매개변수를 사용하여 Dex를 설정할 예정입니다. 대신 .spec.sso 매개변수를 사용하는 것이 좋습니다. ".spec.sso를 사용하여 Dex 활성화 또는 비활성화"를 참조하십시오. GITOPS-2761

  • 이번 업데이트 이전에는 OpenShift Container Platform 4.10 클러스터에 Red Hat OpenShift GitOps v1.8.0을 새로 설치하여 클러스터 및 kam CLI Pod가 시작되지 않았습니다. 이번 업데이트에서는 문제가 해결되어 이제 모든 Pod가 예상대로 실행됩니다. GITOPS-2762

4.1.8. Red Hat OpenShift GitOps 1.8.1 릴리스 노트

Red Hat OpenShift GitOps 1.8.1은 이제 OpenShift Container Platform 4.10, 4.11, 4.12 및 4.13에서 사용할 수 있습니다.

4.1.8.1. 에라타 업데이트

4.1.8.1.1. RHSA-2023:1452 - Red Hat OpenShift GitOps 1.8.1 보안 업데이트 권고

출시 날짜: 2023-03-23

이 릴리스에 포함된 보안 수정 목록은 RHSA-2023:1452 권고에 설명되어 있습니다.

Red Hat OpenShift GitOps Operator를 설치한 경우 다음 명령을 실행하여 이 릴리스의 컨테이너 이미지를 확인합니다. 

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

4.1.9. Red Hat OpenShift GitOps 1.8.0 릴리스 노트

Red Hat OpenShift GitOps 1.8.0은 이제 OpenShift Container Platform 4.10, 4.11, 4.12 및 4.13에서 사용할 수 있습니다.

4.1.9.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 업데이트를 통해 ApplicationSet Progressive Rollout Strategy 기능에 대한 지원을 추가할 수 있습니다. 이 기능을 사용하면 ArgoCD ApplicationSet 리소스를 개선하여 ApplicationSet 사양 또는 애플리케이션 템플릿을 수정한 후 프로그레시브 애플리케이션 리소스 업데이트에 대한 롤아웃 전략을 포함할 수 있습니다. 이 기능을 사용하면 애플리케이션이 동시에 대신 선언적 순서로 업데이트됩니다. GITOPS-956

    중요

    ApplicationSet Progressive Rollout Strategy는 기술 프리뷰 기능입니다.

  • 이번 업데이트를 통해 OpenShift Container Platform 웹 콘솔의 개발자 화면에 있는 애플리케이션 환경 페이지가 Red Hat OpenShift GitOps Application Manager CLI(명령줄 인터페이스), kam 에서 분리됩니다. kam CLI를 사용하여 환경에 대한 애플리케이션 환경 매니페스트를 생성하여 OpenShift Container Platform 웹 콘솔의 개발자 화면에 표시할 필요가 없습니다. 자체 매니페스트를 사용할 수 있지만 환경을 계속 네임스페이스로 표시해야 합니다. 또한 특정 레이블 및 주석이 필요합니다. GITOPS-1785

  • 이번 업데이트를 통해 OpenShift Container Platform의 ARM 아키텍처에서 Red Hat OpenShift GitOps Operator 및 kam CLI를 사용할 수 있습니다. GITOPS-1688

    중요

    spec.sso.provider: keycloak 은 아직 ARM에서 지원되지 않습니다.

  • 이번 업데이트를 통해 .spec.monitoring.enabled 플래그 값을 true 로 설정하여 특정 Argo CD 인스턴스에 대한 워크로드 모니터링을 활성화할 수 있습니다. 결과적으로 Operator는 각 Argo CD 구성 요소에 대한 경고 규칙이 포함된 PrometheusRule 오브젝트를 생성합니다. 이러한 경고 규칙은 해당 구성 요소의 복제본 수가 일정 기간 동안 원하는 상태에서 변경될 때 경고를 트리거합니다. Operator는 사용자가 PrometheusRule 오브젝트에 대한 변경 사항을 덮어쓰지 않습니다. GITOPS-2459

  • 이번 업데이트를 통해 Argo CD CR을 사용하여 command 인수를 리포지토리 서버 배포에 전달할 수 있습니다. GITOPS-2445

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

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  repo:
    extraRepoCommandArgs:
      - --max.combined.directory.manifests.size
      - 10M

4.1.9.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 openshift-gitops-repo-server Pod에서만 ARGOCD_GIT_MODULES_ENABLED 환경 변수를 설정하고 ApplicationSet 컨트롤러 Pod에는 설정할 수 있습니다. 그 결과 Git 생성기를 사용할 때 ApplicationSet Controller 환경에서 변수가 누락되어 하위 애플리케이션 생성 중에 Git 하위 모듈이 복제되었습니다. 또한 이러한 하위 모듈을 복제하는 데 필요한 인증 정보가 ArgoCD에 구성되지 않은 경우 애플리케이션 생성에 실패했습니다. 이번 업데이트에서는 Argo CD CR을 사용하여 ArgoCD_GIT_MODULES_ENABLED 와 같은 환경 변수를 ApplicationSet 컨트롤러 Pod에 추가할 수 있습니다. 그러면 ApplicationSet 컨트롤러 Pod가 복제된 리포지토리에서 하위 애플리케이션을 생성하고 프로세스에서 하위 모듈이 복제되지 않습니다. GITOPS-2399

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

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  applicationSet:
    env:
     - name: ARGOCD_GIT_MODULES_ENABLED
       value: "true"
  • 이번 업데이트 이전에는 Red Hat OpenShift GitOps Operator v1.7.0을 설치하는 동안 Dex 인증을 위해 생성된 기본 argocd-cm.yml 구성 맵 파일에 key:value 쌍 형식의 base64 인코딩 클라이언트 시크릿이 포함되어 있었습니다. 이번 업데이트에서는 클라이언트 시크릿을 기본 argocd-cm.yml 구성 맵 파일에 저장하지 않고 이 문제를 해결합니다. 대신 클라이언트 보안은 이제 argocd-secret 오브젝트에 있으며 구성 맵 내에서 시크릿 이름으로 참조할 수 있습니다. GITOPS-2570

4.1.9.3. 확인된 문제

  • kam CLI를 사용하지 않고 매니페스트를 사용하여 애플리케이션을 배포하고 OpenShift Container Platform 웹 콘솔의 개발자 화면에 있는 애플리케이션 환경 페이지에서 애플리케이션을 보는 경우 해당 애플리케이션에 대한 Argo CD URL은 카드의 Argo CD 아이콘에서 예상대로 페이지를 로드하지 않습니다. GITOPS-2736

4.1.10. Red Hat OpenShift GitOps 1.7.3 릴리스 노트

Red Hat OpenShift GitOps 1.7.3은 이제 OpenShift Container Platform 4.10, 4.11, 4.12에서 사용할 수 있습니다.

4.1.10.1. 에라타 업데이트

4.1.10.1.1. RHSA-2023:1454 - Red Hat OpenShift GitOps 1.7.3 보안 업데이트 권고

출시 날짜: 2023-03-23

이 릴리스에 포함된 보안 수정 목록은 RHSA-2023:1454 권고에 설명되어 있습니다.

Red Hat OpenShift GitOps Operator를 설치한 경우 다음 명령을 실행하여 이 릴리스의 컨테이너 이미지를 확인합니다. 

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

4.1.11. Red Hat OpenShift GitOps 1.7.1 릴리스 노트

Red Hat OpenShift GitOps 1.7.1은 이제 OpenShift Container Platform 4.10, 4.11, 4.12에서 사용할 수 있습니다.

4.1.11.1. 에라타 업데이트

4.1.11.1.1. RHSA-2023:0467 - Red Hat OpenShift GitOps 1.7.1 보안 업데이트 권고

출시 날짜: 2023-01-25

이 릴리스에 포함된 보안 수정 목록은 RHSA-2023:0467 권고에 설명되어 있습니다.

Red Hat OpenShift GitOps Operator를 설치한 경우 다음 명령을 실행하여 이 릴리스의 컨테이너 이미지를 확인합니다. 

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

4.1.12. Red Hat OpenShift GitOps 1.7.0 릴리스 노트

Red Hat OpenShift GitOps 1.7.0은 이제 OpenShift Container Platform 4.10, 4.11, 4.12에서 사용할 수 있습니다.

4.1.12.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 업데이트를 통해 알림 컨트롤러에 환경 변수를 추가할 수 있습니다. GITOPS-2313
  • 이번 업데이트를 통해 기본 nodeSelector "kubernetes.io/os": "linux" 키-값 쌍이 Linux 노드에서만 예약되도록 모든 워크로드에 추가됩니다. 또한 모든 사용자 정의 노드 선택기가 기본값에 추가되고 동일한 키가 있는 경우 우선합니다. GITOPS-2215
  • 이번 업데이트를 통해 GitopsService 사용자 정의 리소스를 편집하여 Operator 워크로드에서 사용자 정의 노드 선택기를 설정할 수 있습니다. GITOPS-2164
  • 이번 업데이트를 통해 RBAC 정책 일치 모드를 사용하여 glob (default) 및 regex.GITOPS-1975옵션 중에서 선택할 수 있습니다.

  • 이번 업데이트를 통해 다음 추가 하위 키를 사용하여 리소스 동작을 사용자 지정할 수 있습니다.

    하위 키주요 양식argocd-cm의 매핑된 필드

    resourceHealthChecks

    resource.customizations.health.<group_kind>

    resource.customizations.health

    resourceIgnoreDifferences

    resource.customizations.ignoreDifferences.<group_kind>

    resource.customizations.ignoreDifferences

    resourceActions

    resource.customizations.actions.<group_kind>

    resource.customizations.actions

    GITOPS-1561

    참고

    향후 릴리스에서는 하위 키가 아닌 resourceCustomization만 사용하여 리소스 동작을 사용자 정의하는 이전 방법을 사용 중단할 수 있습니다.

  • 이번 업데이트를 통해 개발자 화면에서 환경 페이지를 사용하려면 1.7 및 OpenShift Container Platform 4.15 이전의 Red Hat OpenShift GitOps 버전을 사용하는 경우 업그레이드해야 합니다. GITOPS-2415

  • 이번 업데이트를 통해 동일한 클러스터의 모든 네임스페이스에서 동일한 컨트롤 플레인 Argo CD 인스턴스에서 관리하는 애플리케이션을 생성할 수 있습니다. 관리자로 다음 작업을 수행하여 이 업데이트를 활성화합니다.

    • 애플리케이션을 관리하는 클러스터 범위의 Argo CD 인스턴스의 .spec.sourceNamespaces 속성에 네임스페이스를 추가합니다.

    • 애플리케이션과 연결된 AppProject 사용자 정의 리소스의 .spec.sourceNamespaces 속성에 네임스페이스를 추가합니다. 

      GITOPS-2341

중요

컨트롤 플레인이 아닌 네임스페이스의 Argo CD 애플리케이션은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트를 통해 Argo CD는 Server-Side Apply 기능을 지원하므로 사용자가 다음 작업을 수행할 수 있습니다.

    • 262144바이트의 허용된 주석 크기에 비해 너무 큰 리소스를 관리합니다.

    • Argo CD에서 관리하거나 배포하지 않는 기존 리소스를 패치합니다.

      애플리케이션 또는 리소스 수준에서 이 기능을 구성할 수 있습니다. GITOPS-2340

4.1.12.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 anyuid SCC가 Dex 서비스 계정에 할당되었을 때 Dex Pod 문제로 인해 CreateContainerConfigError 오류가 발생했습니다. 이번 업데이트에서는 기본 사용자 ID를 Dex 컨테이너에 할당하여 문제를 해결합니다. GITOPS-2235
  • 이번 업데이트 이전에는 Red Hat OpenShift GitOps가 Dex 외에도 OIDC를 통해 RHSSO(Keycloak)를 사용했습니다. 그러나 최근 보안 수정으로 인해 잘 알려진 인증 기관 중 하나에서 서명하지 않은 인증서로 구성된 경우 RHSSO의 인증서를 검증할 수 없었습니다. 이번 업데이트에서는 이 문제가 해결되어 이제 사용자 정의 인증서를 제공하여 통신할 때 KeyCloak의 TLS 인증서를 확인할 수 있습니다. 또한 Argo CD 사용자 지정 리소스 .spec.keycloak. rootCA 필드에 rootCA 를 추가할 수 있습니다. Operator는 이러한 변경 사항을 조정하며 PEM 인코딩 루트 인증서로 argocd-cm 구성 맵의 oidc.config 를 업데이트합니다. GITOPS-2214

Keycloak 구성이 있는 Argo CD의 예: 

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  sso:
    keycloak:
      rootCA: '<PEM encoded root certificate>'
    provider: keycloak
.......
.......
  • 이번 업데이트 이전에는 활성 프로브의 응답하지 않아 애플리케이션 컨트롤러가 여러 번 재시작되었습니다. 이번 업데이트에서는 statefulset 애플리케이션 컨트롤러에서 활성 프로브를 제거하여 문제를 해결합니다. GITOPS-2153

4.1.12.3. 확인된 문제

  • 이번 업데이트 이전에는 Operator에서 리포지토리 서버의 mountsatoken 및 ServiceAccount 설정을 조정하지 않았습니다. 이 문제가 해결되었지만 서비스 계정 삭제는 기본값으로 되돌아가지 않습니다. GITOPS-1873
  • 해결방법: spec.repo.serviceaccountfield를 기본 서비스 계정으로 수동으로 설정합니다. GITOPS-2452

4.1.13. Red Hat OpenShift GitOps 1.6.4 릴리스 노트

Red Hat OpenShift GitOps 1.6.4는 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.13.1. 해결된 문제

  • 이번 업데이트 이전에는 모든 Argo CD v1.8.2 이상 버전이 잘못된 인증 버그에 취약했습니다. 결과적으로 Argo CD는 클러스터에 액세스하려고 하지 않는 대상의 토큰을 허용합니다. 이제 이 문제가 해결되었습니다. CVE-2023-22482

4.1.14. Red Hat OpenShift GitOps 1.6.2 릴리스 노트

Red Hat OpenShift GitOps 1.6.2는 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.14.1. 새로운 기능

  • 이 릴리스에서는 openshift-gitops-operator CSV 파일에서 DISABLE_DEX 환경 변수를 제거합니다. 따라서 Red Hat OpenShift GitOps 신규 설치를 수행할 때 이 환경 변수가 더 이상 설정되지 않습니다. GITOPS-2360

4.1.14.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 프로젝트에 Operator 5개 이상을 설치할 때 누락된 InstallPlan 에 대한 서브스크립션 상태 점검이 성능이 저하 되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. GITOPS-2018
  • 이번 업데이트 이전에는 Red Hat OpenShift GitOps Operator에서 Argo CD 인스턴스가 더 이상 사용되지 않는 필드를 사용했음을 탐지할 때마다 사용 중단 알림 경고와 함께 클러스터를 스팸했습니다. 이번 업데이트에서는 이 문제를 해결했으며 필드를 감지하는 각 인스턴스에 대해 하나의 경고 이벤트만 표시합니다. GITOPS-2230
  • OpenShift Container Platform 4.12에서는 콘솔을 설치하는 것이 선택 사항입니다. 이번 수정을 통해 콘솔이 설치되지 않은 경우 Operator에 오류가 발생하지 않도록 Red Hat OpenShift GitOps Operator가 업데이트되었습니다. GITOPS-2352

4.1.15. Red Hat OpenShift GitOps 1.6.1 릴리스 노트

Red Hat OpenShift GitOps 1.6.1은 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.15.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 활성 프로브의 응답하지 않아 애플리케이션 컨트롤러가 여러 번 재시작되었습니다. 이번 업데이트에서는 애플리케이션 컨트롤러 StatefulSet 오브젝트에서 활성 프로브를 제거하여 문제를 해결합니다. GITOPS-2153

  • 이번 업데이트 이전에는 인증 기관에서 서명하지 않은 인증서로 설정된 경우 RHSSO 인증서를 검증할 수 없습니다. 이번 업데이트에서는 이 문제가 해결되어 이제 통신할 때 Keycloak의 TLS 인증서를 확인하는 데 사용되는 사용자 정의 인증서를 제공할 수 있습니다. rootCA 를 Argo CD 사용자 지정 리소스 .spec.keycloak.rootCA 필드에 추가할 수 있습니다. Operator는 이 변경 사항을 조정하고 PEM 인코딩 루트 인증서로 argocd-cm ConfigMap 의 oidc.config 필드를 업데이트합니다. GITOPS-2214

    참고

    .spec.keycloak.rootCA 필드를 업데이트한 후 Argo CD 서버 Pod를 다시 시작합니다.

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

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true
  • 이번 업데이트 이전에는 Argo CD에서 관리하는 종료 네임스페이스로 인해 다른 관리 네임스페이스의 역할 및 기타 구성 생성이 차단되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. GITOPS-2277
  • 이번 업데이트 이전에는 anyuid 의 SCC가 Dex ServiceAccount 리소스에 할당되면 Dex Pod를 CreateContainerConfigError 로 시작하지 못했습니다. 이번 업데이트에서는 기본 사용자 ID를 Dex 컨테이너에 할당하여 이 문제를 해결합니다. GITOPS-2235

4.1.16. Red Hat OpenShift GitOps 1.6.0 릴리스 노트

Red Hat OpenShift GitOps 1.6.0은 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.16.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이전에는 Argo CD ApplicationSet 컨트롤러가 TP(기술 프리뷰) 기능이었습니다. 이번 업데이트를 통해 GA(일반 가용성) 기능입니다. GITOPS-1958
  • 이번 업데이트를 통해 Red Hat OpenShift GitOps의 최신 릴리스는 최신 및 버전 기반 채널에서 사용할 수 있습니다. 이러한 업그레이드를 가져오려면 Subscription 오브젝트 YAML 파일의 channel 매개변수를 업데이트합니다. 값을 stable 에서 latest 또는 gitops-1.6 과 같은 버전 기반 채널로 변경합니다. GITOPS-1791
  • 이번 업데이트를 통해 keycloak 구성을 제어하는 spec.sso 필드의 매개변수가 .spec.sso.keycloak 으로 이동합니다. .spec.dex 필드의 매개변수가 .spec.sso.dex 에 추가되었습니다. .spec.sso.provider 를 사용하여 Dex를 활성화 또는 비활성화합니다. .spec.dex 매개변수는 더 이상 사용되지 않으며 버전 1.9에서 키클로크 구성에 대한 DISABLE_DEX 및 .spec.sso 필드와 함께 제거될 예정입니다. GITOPS-1983
  • 이번 업데이트를 통해 Argo CD 알림 컨트롤러는 Argo CD 사용자 정의 리소스의 .spec.notifications.enabled 매개변수를 사용하여 활성화 또는 비활성화할 수 있는 선택적 워크로드로 사용할 수 있습니다. Argo CD 알림 컨트롤러는 기술 프리뷰 기능으로 사용할 수 있습니다. GITOPS-1917
중요

Argo CD 알림 컨트롤러는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

  • 이번 업데이트를 통해 Tekton 파이프라인 실행 및 작업 실행에 대한 리소스 제외가 기본적으로 추가됩니다. Argo CD는 기본적으로 이러한 리소스를 정리합니다. 이러한 리소스 제외는 OpenShift Container Platform에서 생성된 새로운 Argo CD 인스턴스에 추가됩니다. CLI에서 인스턴스가 생성되면 리소스가 추가되지 않습니다. GITOPS-1876
  • 이번 업데이트를 통해 Operand 사양에 resourceECDHEingMethod 매개변수를 설정하여 Argo CD에서 사용하는 추적 방법을 선택할 수 있습니다. GITOPS-1862
  • 이번 업데이트를 통해 Red Hat OpenShift GitOps Argo CD 사용자 정의 리소스의 extraConfig 필드를 사용하여 argocd-cm configMap에 항목을 추가할 수 있습니다. 지정된 항목은 검증 없이 라이브 config-cm configMap과 조정됩니다. GITOPS-1964
  • 이번 업데이트를 통해 OpenShift Container Platform 4.11에서 개발자 화면의 Red Hat OpenShift GitOps 환경 페이지에는 각 배포의 리버전 링크와 함께 애플리케이션 환경의 성공적인 배포 기록이 표시됩니다. GITOPS-1269
  • 이번 업데이트를 통해 Operator가 템플릿 리소스 또는 "소스"로 사용하는 Argo CD로 리소스를 관리할 수 있습니다. GITOPS-982
  • 이번 업데이트를 통해 Operator는 Kubernetes 1.24에 활성화된 Pod Security Admission을 충족하기 위해 올바른 권한으로 Argo CD 워크로드를 구성합니다. GITOPS-2026
  • 이번 업데이트를 통해 Config Management Plugins 2.0이 지원됩니다. Argo CD 사용자 지정 리소스를 사용하여 리포지토리 서버의 사이드바 컨테이너를 지정할 수 있습니다. GITOPS-776
  • 이번 업데이트를 통해 Argo CD 구성 요소와 Redis 캐시 간의 모든 통신이 최신 TLS 암호화를 사용하여 올바르게 보호됩니다. GITOPS-720
  • 이번 Red Hat OpenShift GitOps 릴리스에는 OpenShift Container Platform 4.10에서 IBM Z 및 IBM Power에 대한 지원이 추가되었습니다. 현재 제한된 환경에서의 설치는 IBM Z 및 IBM Power에서 지원되지 않습니다.

4.1.16.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 webapps-dev 네임스페이스의 system:serviceaccount:argocd:gitops-argocd-application-application-controller 에서 API 그룹 monitoring.coreos.com 에서 "prometheusrules" 리소스를 생성할 수 없습니다. 이번 업데이트에서는 이 문제가 해결되어 Red Hat OpenShift GitOps에서 monitoring.coreos.com API 그룹에서 모든 리소스를 관리할 수 있습니다. GITOPS-1638
  • 이번 업데이트 이전에는 클러스터 권한을 조정하면서 시크릿이 클러스터 구성 인스턴스에 속하는 경우 삭제되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. 이제 보안의 namespaces 필드가 시크릿 대신 삭제됩니다. GITOPS-1777
  • 이번 업데이트 이전에는 Operator를 통해 Argo CD의 HA 변형을 설치한 경우 Operator에서 Pod AntiAffinity 규칙 대신 podAffinity 규칙을 사용하여 Redis StatefulSet 오브젝트를 생성했습니다. 이번 업데이트에서는 이 문제가 해결되어 이제 Operator에서 podAntiAffinity 규칙을 사용하여 Redis StatefulSet 을 생성합니다. GITOPS-1645
  • 이번 업데이트 이전에는 Argo CD ApplicationSet 에 너무 많은 ssh Zombie 프로세스가 있었습니다. 이번 업데이트에서는 프로세스를 생성하고 좀비를 가져오는 간단한 init 데몬인 tini를 ApplicationSet 컨트롤러에 추가합니다. 이렇게 하면 SIGTERM 신호가 실행 중인 프로세스에 올바르게 전달되어 좀비 프로세스가 되지 않습니다. GITOPS-2108

4.1.16.3. 확인된 문제

  • Red Hat OpenShift GitOps Operator는 Dex 외에도 OIDC를 통해 RHSSO(KeyCloak)를 사용할 수 있습니다. 그러나 최근 보안 수정이 적용된 경우 일부 시나리오에서는 RHSSO 인증서를 확인할 수 없습니다. GITOPS-2214

    이 문제를 해결하려면 ArgoCD 사양에서 OIDC(Keycloak/RHSSO) 끝점에 대한 TLS 검증을 비활성화합니다. 

spec:
  extraConfig:
    oidc.tls.insecure.skip.verify: "true"
...

4.1.17. Red Hat OpenShift GitOps 1.5.9 릴리스 노트

Red Hat OpenShift GitOps 1.5.9는 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.17.1. 해결된 문제

  • 이번 업데이트 이전에는 모든 Argo CD v1.8.2 이상 버전이 잘못된 인증 버그에 취약했습니다. 결과적으로 Argo CD는 클러스터에 액세스할 권한이 없는 사용자의 토큰을 허용합니다. 이제 이 문제가 해결되었습니다. CVE-2023-22482

4.1.18. Red Hat OpenShift GitOps 1.5.7 릴리스 노트

Red Hat OpenShift GitOps 1.5.7은 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.18.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • OpenShift Container Platform 4.12에서는 콘솔을 설치하는 것이 선택 사항입니다. 이번 수정을 통해 콘솔이 설치되지 않은 경우 Operator에 오류가 발생하지 않도록 Red Hat OpenShift GitOps Operator가 업데이트되었습니다. GITOPS-2353

4.1.19. Red Hat OpenShift GitOps 1.5.6 릴리스 노트

Red Hat OpenShift GitOps 1.5.6은 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.19.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 활성 프로브의 응답하지 않아 애플리케이션 컨트롤러가 여러 번 재시작되었습니다. 이번 업데이트에서는 애플리케이션 컨트롤러 StatefulSet 오브젝트에서 활성 프로브를 제거하여 문제를 해결합니다. GITOPS-2153

  • 이번 업데이트 이전에는 인증 기관에서 서명하지 않은 인증서로 설정된 경우 RHSSO 인증서를 검증할 수 없습니다. 이번 업데이트에서는 이 문제가 해결되어 이제 통신할 때 Keycloak의 TLS 인증서를 확인하는 데 사용되는 사용자 정의 인증서를 제공할 수 있습니다. rootCA 를 Argo CD 사용자 지정 리소스 .spec.keycloak.rootCA 필드에 추가할 수 있습니다. Operator는 이 변경 사항을 조정하고 PEM 인코딩 루트 인증서로 argocd-cm ConfigMap 의 oidc.config 필드를 업데이트합니다. GITOPS-2214

    참고

    .spec.keycloak.rootCA 필드를 업데이트한 후 Argo CD 서버 Pod를 다시 시작합니다.

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

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true
  • 이번 업데이트 이전에는 Argo CD에서 관리하는 종료 네임스페이스로 인해 다른 관리 네임스페이스의 역할 및 기타 구성 생성이 차단되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. GITOPS-2278
  • 이번 업데이트 이전에는 anyuid 의 SCC가 Dex ServiceAccount 리소스에 할당되면 Dex Pod를 CreateContainerConfigError 로 시작하지 못했습니다. 이번 업데이트에서는 기본 사용자 ID를 Dex 컨테이너에 할당하여 이 문제를 해결합니다. GITOPS-2235

4.1.20. Red Hat OpenShift GitOps 1.5.5 릴리스 노트

Red Hat OpenShift GitOps 1.5.5는 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.20.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 업데이트를 통해 번들 Argo CD가 버전 2.3.7로 업데이트되었습니다.

4.1.20.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 클러스터에 더 제한적인 SCC가 있는 경우 ArgoCD 인스턴스의 redis-ha-haproxy Pod가 실패했습니다. 이번 업데이트에서는 워크로드의 보안 컨텍스트를 업데이트하여 문제를 해결합니다. GITOPS-2034

4.1.20.3. 확인된 문제

  • Red Hat OpenShift GitOps Operator는 OIDC 및 Dex와 함께 RHSSO(KeyCloak)를 사용할 수 있습니다. 그러나 최근 보안 수정이 적용된 경우 Operator는 일부 시나리오에서는 RHSSO 인증서를 검증할 수 없습니다. GITOPS-2214

    이 문제를 해결하려면 ArgoCD 사양에서 OIDC(Keycloak/RHSSO) 끝점에 대한 TLS 검증을 비활성화합니다. 

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

4.1.21. Red Hat OpenShift GitOps 1.5.4 릴리스 노트

Red Hat OpenShift GitOps 1.5.4는 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.21.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 Red Hat OpenShift GitOps에서 이전 버전의 REDIS 5 이미지 태그를 사용했습니다. 이번 업데이트에서는 rhel8/redis-5 이미지 태그를 업데이트하고 업그레이드합니다. GITOPS-2037

4.1.22. Red Hat OpenShift GitOps 1.5.3 릴리스 노트

Red Hat OpenShift GitOps 1.5.3은 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.22.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 패치되지 않은 모든 Argo CD v1.0.0 버전이 사이트 간 스크립팅 버그에 취약했습니다. 그 결과 권한이 없는 사용자는 UI에 javascript 링크를 삽입할 수 있습니다. 이제 이 문제가 해결되었습니다. CVE-2022-31035
  • 이번 업데이트 이전에는 모든 Argo CD v0.11.0 버전이 Argo CD CLI 또는 UI에서 SSO 로그인이 시작될 때 여러 공격에 취약했습니다. 이제 이 문제가 해결되었습니다. CVE-2022-31034
  • 이번 업데이트 이전에는 패치되지 않은 모든 Argo CD v0.7 버전이 메모리 소비 버그에 취약했습니다. 결과적으로 권한이 없는 사용자는 Argo CD의 repo-server를 충돌시킬 수 있습니다. 이제 이 문제가 해결되었습니다. CVE-2022-31016
  • 이번 업데이트 이전에는 패치되지 않은 모든 Argo CD v1.3.0 이상의 버전이 symlink-following 버그에 취약합니다. 결과적으로 리포지토리 쓰기 액세스 권한이 있는 권한이 없는 사용자는 Argo CD의 repo-server에서 중요한 YAML 파일을 유출할 수 있었습니다. 이제 이 문제가 해결되었습니다. CVE-2022-31036

4.1.23. Red Hat OpenShift GitOps 1.5.2 릴리스 노트

Red Hat OpenShift GitOps 1.5.2는 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.23.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 redhat-operator-index 에서 참조하는 이미지가 누락되었습니다. 이제 이 문제가 해결되었습니다. GITOPS-2036

4.1.24. Red Hat OpenShift GitOps 1.5.1 릴리스 노트

Red Hat OpenShift GitOps 1.5.1은 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.24.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 Argo CD의 익명 액세스가 활성화된 경우 인증되지 않은 사용자는 JWT 토큰을 작성하고 Argo CD 인스턴스에 대한 전체 액세스 권한을 얻을 수 있었습니다. 이 문제는 이제 해결되었습니다. CVE-2022-29165
  • 이번 업데이트 이전에는 인증되지 않은 사용자가 SSO가 활성화된 동안 로그인 화면에 오류 메시지를 표시할 수 있었습니다. 이제 이 문제가 해결되었습니다. CVE-2022-24905
  • 이번 업데이트 이전에는 패치되지 않은 모든 Argo CD v0.7.0 이상의 버전이 symlink-following 버그에 취약합니다. 결과적으로 리포지토리 쓰기 액세스 권한이 있는 권한이 없는 사용자는 Argo CD의 repo-server에서 중요한 파일을 유출할 수 있었습니다. 이제 이 문제가 해결되었습니다. CVE-2022-24904

4.1.25. Red Hat OpenShift GitOps 1.5.0 릴리스 노트

Red Hat OpenShift GitOps 1.5.0은 이제 OpenShift Container Platform 4.8, 4.9, 4.10 및 4.11에서 사용할 수 있습니다.

4.1.25.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 개선된 기능은 Argo CD를 버전 2.3.3 으로 업그레이드합니다. GITOPS-1708
  • 이번 개선된 기능은 Dex를 2.30.3 버전으로 업그레이드합니다. GITOPS-1850
  • 이번 개선된 기능을 통해 Helm을 버전 3.8.0 으로 업그레이드합니다. GITOPS-1709
  • 이번 개선된 기능은 Kustomize를 버전 4.4.1 로 업그레이드합니다. GITOPS-1710
  • 이번 개선된 기능은 애플리케이션 세트를 버전 0.4.1 로 업그레이드합니다.
  • 이번 업데이트를 통해 Red Hat OpenShift GitOps의 최신 릴리스를 제공하는 latest 이름의 새 채널이 추가되었습니다. GitOps v1.5.0의 경우 Operator는 gitops-1.5,latest 채널 및 기존 stable 채널로 푸시됩니다. GitOps v1.6에서 모든 최신 릴리스는 stable 채널이 아닌 최신 채널로만 푸시됩니다. GITOPS-1791
  • 이번 업데이트를 통해 새 CSV는 olm.skipRange: '>=1.0.0 <1.5.0' 주석을 추가합니다. 결과적으로 모든 이전 릴리스 버전을 건너뜁니다. Operator는 v1.5.0으로 직접 업그레이드합니다. GITOPS-1787

  • 이번 업데이트를 통해 Operator는 다음과 같은 향상된 기능을 포함하여 RH-SSO(Red Hat Single Sign-On)를 버전 vECDHE.1로 업데이트합니다.

    • kube:admin 인증 정보를 포함하여 OpenShift 인증 정보를 사용하여 Argo CD에 로그인할 수 있습니다.
    • RH-SSO는 OpenShift 그룹을 사용하여 역할 기반 액세스 제어(RBAC)에 대한 Argo CD 인스턴스를 지원하고 구성합니다.

    • RH-SSO는 HTTP_Proxy 환경 변수를 따릅니다. 프록시 뒤에서 실행되는 Argo CD의 SSO로 RH-SSO를 사용할 수 있습니다.

      GITOPS-1330

  • 이번 업데이트를 통해 Argo CD 피연산자의 .status 필드에 새로운 .host URL 필드가 추가됩니다. 라우팅에 지정된 우선 순위로 경로 또는 수신이 활성화되면 새 URL 필드에 경로가 표시됩니다. 경로 또는 수신에서 URL을 제공하지 않으면 .host 필드가 표시되지 않습니다.

    경로 또는 수신이 구성되었지만 해당 컨트롤러가 올바르게 설정되지 않고 Ready 상태가 아니거나 해당 URL을 전파하지 않는 경우 피연산자의 .status.host 필드의 값은 URL을 표시하는 대신 Pending 로 표시됩니다. 이는 Available 대신 Pending 상태로 설정하여 피연산자의 전체 상태에 영향을 미칩니다. GITOPS-654

4.1.25.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 AppProjects 와 관련된 RBAC 규칙에서 역할의 subject 필드에 쉼표를 사용하지 않아 LDAP 계정에 대한 바인딩이 발생하지 않았습니다. 이번 업데이트에서는 이 문제가 해결되어 이제 AppProject 특정 RBAC 규칙에서 복잡한 역할 바인딩을 지정할 수 있습니다. GITOPS-1771
  • 이번 업데이트 이전에는 DeploymentConfig 리소스를 0 으로 스케일링할 때 Argo CD에 "복제 컨트롤러 실행 대기 중" 상태 메시지와 함께 진행 중인 상태가 표시되었습니다. 이번 업데이트에서는 엣지 케이스를 수정하고 상태 점검에서 DeploymentConfig 리소스의 올바른 상태를 보고합니다. GITOPS-1738
  • 이번 업데이트 이전에는 ArgoCD CR 사양 tls.initialCerts 필드에 인증서가 구성되지 않은 한 Red Hat OpenShift GitOps에서 argocd-tls-certs-cm 구성 맵의 TLS 인증서가 삭제되었습니다. 이 문제는 이제 해결되었습니다. GITOPS-1725
  • 이번 업데이트 이전에는 managed-by 레이블을 사용하여 네임스페이스를 생성하는 동안 새 네임스페이스에 많은 RoleBinding 리소스가 생성되었습니다. 이번 업데이트에서는 문제가 해결되어 이제 Red Hat OpenShift GitOps에서 이전 버전에서 생성한 관련 역할 및 RoleBinding 리소스를 제거합니다. GITOPS-1550
  • 이번 업데이트 이전에는 통과 모드에서 경로의 TLS 인증서에 CA 이름이 없었습니다. 그 결과 Firefox 94 이상 오류 코드ECDHE _ERROR_BAD_DER 를 사용하여 Argo CD UI에 연결할 수 없었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. < openshift-gitops-ca> 시크릿 을 삭제하고 다시 생성해야 합니다. 그런 다음 < openshift-gitops-tls > 시크릿을 삭제해야 합니다. Red Hat OpenShift GitOps가 다시 생성한 후 Firefox에서 Argo CD UI에 다시 액세스할 수 있습니다. GITOPS-1548

4.1.25.3. 확인된 문제

  • Argo CD .status.host 필드는 OpenShift 클러스터에서 Route 리소스 대신 Ingress 리소스가 사용 중일 때 업데이트되지 않습니다. GITOPS-1920

4.1.26. Red Hat OpenShift GitOps 1.4.13 릴리스 노트

Red Hat OpenShift GitOps 1.4.13은 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.26.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • OpenShift Container Platform 4.12에서는 콘솔을 설치하는 것이 선택 사항입니다. 이번 수정을 통해 콘솔이 설치되지 않은 경우 Operator에 오류가 발생하지 않도록 Red Hat OpenShift GitOps Operator가 업데이트되었습니다. GITOPS-2354

4.1.27. Red Hat OpenShift GitOps 1.4.12 릴리스 노트

Red Hat OpenShift GitOps 1.4.12는 이제 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.27.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 활성 프로브의 응답하지 않아 애플리케이션 컨트롤러가 여러 번 재시작되었습니다. 이번 업데이트에서는 애플리케이션 컨트롤러 StatefulSet 오브젝트에서 활성 프로브를 제거하여 문제를 해결합니다. GITOPS-2153

  • 이번 업데이트 이전에는 인증 기관에서 서명하지 않은 인증서로 설정된 경우 RHSSO 인증서를 검증할 수 없습니다. 이번 업데이트에서는 이 문제가 해결되어 이제 통신할 때 Keycloak의 TLS 인증서를 확인하는 데 사용되는 사용자 정의 인증서를 제공할 수 있습니다. rootCA 를 Argo CD 사용자 지정 리소스 .spec.keycloak.rootCA 필드에 추가할 수 있습니다. Operator는 이 변경 사항을 조정하고 PEM 인코딩 루트 인증서로 argocd-cm ConfigMap 의 oidc.config 필드를 업데이트합니다. GITOPS-2214

    참고

    .spec.keycloak.rootCA 필드를 업데이트한 후 Argo CD 서버 Pod를 다시 시작합니다.

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

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
     rootCA: |
       ---- BEGIN CERTIFICATE ----
       This is a dummy certificate
       Please place this section with appropriate rootCA
       ---- END CERTIFICATE ----
  server:
    route:
      enabled: true
  • 이번 업데이트 이전에는 Argo CD에서 관리하는 종료 네임스페이스로 인해 다른 관리 네임스페이스의 역할 및 기타 구성 생성이 차단되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. GITOPS-2276
  • 이번 업데이트 이전에는 anyuid 의 SCC가 Dex ServiceAccount 리소스에 할당되면 Dex Pod를 CreateContainerConfigError 로 시작하지 못했습니다. 이번 업데이트에서는 기본 사용자 ID를 Dex 컨테이너에 할당하여 이 문제를 해결합니다. GITOPS-2235

4.1.28. Red Hat OpenShift GitOps 1.4.11 릴리스 노트

Red Hat OpenShift GitOps 1.4.11은 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.28.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 업데이트를 통해 번들 Argo CD가 2.2.12 버전으로 업데이트되었습니다.

4.1.28.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 클러스터에 더 제한적인 SCC가 있는 경우 ArgoCD 인스턴스의 redis-ha-haproxy Pod가 실패했습니다. 이번 업데이트에서는 워크로드의 보안 컨텍스트를 업데이트하여 문제를 해결합니다. GITOPS-2034

4.1.28.3. 확인된 문제

  • Red Hat OpenShift GitOps Operator는 OIDC 및 Dex와 함께 RHSSO(KeyCloak)를 사용할 수 있습니다. 그러나 최근 보안 수정이 적용된 경우 Operator는 일부 시나리오에서는 RHSSO 인증서를 검증할 수 없습니다. GITOPS-2214

    이 문제를 해결하려면 ArgoCD 사양에서 OIDC(Keycloak/RHSSO) 끝점에 대한 TLS 검증을 비활성화합니다. 

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  extraConfig:
    "admin.enabled": "true"
...

4.1.29. Red Hat OpenShift GitOps 1.4.6 릴리스 노트

Red Hat OpenShift GitOps 1.4.6은 이제 OpenShift Container Platform 4.7, 4.8, 4.9, 4.10에서 사용할 수 있습니다.

4.1.29.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 기본 이미지는 OpenSSL 결함 링크를 피하기 위해 최신 버전으로 업데이트됩니다. (CVE-2022-0778)
참고

현재 Red Hat OpenShift GitOps 1.4 릴리스를 설치하고 제품 라이프 사이클 동안 추가 업데이트를 받으려면 GitOps-1.4 채널로 전환합니다.

4.1.30. Red Hat OpenShift GitOps 1.4.5 릴리스 노트

Red Hat OpenShift GitOps 1.4.5는 이제 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.30.1. 해결된 문제

주의

Red Hat OpenShift GitOps v1.4.3에서 Red Hat OpenShift GitOps v1.4.5로 직접 업그레이드해야 합니다. 프로덕션 환경에서는 Red Hat OpenShift GitOps v1.4.4를 사용하지 마십시오. Red Hat OpenShift GitOps v1.4.4에 영향을 받는 주요 문제는 Red Hat OpenShift GitOps 1.4.5에서 수정되었습니다.

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 Argo CD Pod가 ErrImagePullBackOff 상태에 있었습니다. 다음과 같은 오류 메시지가 표시되었습니다. 
reason: ErrImagePull
          message: >-
            rpc error: code = Unknown desc = reading manifest
            sha256:ff4ad30752cf0d321cd6c2c6fd4490b716607ea2960558347440f2f370a586a8
            in registry.redhat.io/openshift-gitops-1/argocd-rhel8: StatusCode:
            404, <HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>

이제 이 문제가 해결되었습니다. GITOPS-1848

4.1.31. Red Hat OpenShift GitOps 1.4.3 릴리스 노트

Red Hat OpenShift GitOps 1.4.3은 이제 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.31.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 ArgoCD CR 사양 tls.initialCerts 필드에 인증서가 구성되지 않은 한 Red Hat OpenShift GitOps에서 argocd-tls-certs-cm 구성 맵의 TLS 인증서가 삭제되었습니다. 이번 업데이트에서는 이 문제가 해결되었습니다. GITOPS-1725

4.1.32. Red Hat OpenShift GitOps 1.4.2 릴리스 노트

Red Hat OpenShift GitOps 1.4.2는 이제 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.32.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 하나 이상의 Ingress 가 경로에 연결된 경우 경로 리소스가 Progressing Health 상태가 되었습니다. 이번 업데이트에서는 상태 점검을 수정하고 Route 리소스의 올바른 상태를 보고합니다. GITOPS-1751

4.1.33. Red Hat OpenShift GitOps 1.4.1 릴리스 노트

Red Hat OpenShift GitOps 1.4.1은 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.33.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • Red Hat OpenShift GitOps Operator v1.4.0에서는 다음 CRD에 대한 spec 에서 description 필드를 제거하는 회귀 문제가 도입되었습니다.

    • argoproj.io_applications.yaml
    • argoproj.io_appprojects.yaml

    • argoproj.io_argocds.yaml

      이번 업데이트 이전에는 oc create 명령을 사용하여 AppProject 리소스를 생성할 때 누락된 설명 필드로 인해 리소스가 동기화되지 않았습니다. 이번 업데이트에서는 이전 CRD에서 누락된 설명 필드를 복원합니다. GITOPS-1721

4.1.34. Red Hat OpenShift GitOps 1.4.0 릴리스 노트

Red Hat OpenShift GitOps 1.4.0은 이제 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.10에서 사용할 수 있습니다.

4.1.34.1. 새로운 기능

현재 릴리스에는 다음과 같은 개선 사항이 추가되었습니다.

  • 이번 개선된 기능에는 Red Hat OpenShift GitOps Application Manager CLI(kam)가 0.0.41 버전으로 업그레이드되었습니다. GITOPS-1669
  • 이번 개선된 기능은 Argo CD를 버전 2.2.2 로 업그레이드합니다. GITOPS-1532
  • 이번 개선된 기능은 Helm을 버전 3.7.1 로 업그레이드합니다. GITOPS-1530
  • 이번 개선된 기능에는 DeploymentConfig,Route, OLM Operator 항목의 상태가 Argo CD 대시보드 및 OpenShift Container Platform 웹 콘솔에 추가되었습니다. 이 정보는 애플리케이션의 전반적인 상태를 모니터링하는 데 도움이 됩니다. GITOPS-655, GITOPS-915, GITOPS-916, GITOPS-1110
  • 이번 업데이트를 통해 Argo CD 사용자 정의 리소스에 .spec.server.replicas 및 .spec.repo.replicas 특성을 설정하여 argocd-server 및 argocd-repo-server 구성 요소에 대해 원하는 복제본 수를 지정할 수 있습니다. argocd-server 구성 요소에 HPA(수평 Pod 자동 스케일러)를 구성하는 경우 Argo CD 사용자 정의 리소스 속성보다 우선합니다. GITOPS-1245

  • 관리 사용자로 argocd.argoproj.io/managed-by 레이블을 사용하여 Argo CD 액세스 권한을 부여하면 namespace-admin 권한을 가정합니다. 이러한 권한은 관리자가 아닌 사용자가 네트워크 정책과 같은 오브젝트를 수정할 수 있기 때문에 개발 팀과 같은 관리자가 아닌 관리자에게 네임스페이스를 제공하는 관리자에게 문제가 됩니다.

    이번 업데이트를 통해 관리자는 모든 관리 네임스페이스에 대한 공통 클러스터 역할을 구성할 수 있습니다. Argo CD 애플리케이션 컨트롤러의 역할 바인딩에서 Operator는 CONTROLLER_CLUSTER_ROLE 환경 변수를 참조합니다. Argo CD 서버의 역할 바인딩에서 Operator는 SERVER_CLUSTER_ROLE 환경 변수를 참조합니다. 이러한 환경 변수에 사용자 정의 역할이 포함된 경우 Operator는 기본 admin 역할을 생성하지 않습니다. 대신 모든 관리 네임스페이스에 기존 사용자 지정 역할을 사용합니다. GITOPS-1290

  • 이번 업데이트를 통해 OpenShift Container Platform 개발자 화면의 환경 페이지에 진행 중 상태의 상태,Missing, Unknown 을 제외한 성능이 저하된 리소스를 나타내는 손상된 하트 아이콘이 표시됩니다. 콘솔에는 동기화되지 않은 리소스를 나타내는 노란색 유효 기호 아이콘이 표시됩니다. GITOPS-1307

4.1.34.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 URL에 경로를 지정하지 않고 Red Hat OpenShift GitOps Application Manager CLI(kam)로의 경로에 액세스하면 유용한 정보가 없는 기본 페이지가 사용자에게 표시되었습니다. 이번 업데이트에서는 기본 페이지에 kam CLI에 대한 다운로드 링크가 표시되도록 문제가 해결되었습니다. GITOPS-923
  • 이번 업데이트 이전에는 Argo CD 사용자 정의 리소스의 네임스페이스에 리소스 할당량을 설정하면 RH SSO(Red Hat SSO) 인스턴스 설정이 실패할 수 있습니다. 이번 업데이트에서는 RH SSO 배포 포드에 대한 최소 리소스 요청을 설정하여 이 문제를 해결합니다. GITOPS-1297
  • 이번 업데이트 이전에는 argocd-repo-server 워크로드의 로그 수준을 변경한 경우 Operator가 이 설정을 조정하지 않았습니다. 해결방법은 Operator가 새 로그 수준으로 다시 생성되도록 배포 리소스를 삭제하는 것이었습니다. 이번 업데이트를 통해 기존 argocd-repo-server 워크로드에 대한 로그 수준이 올바르게 조정됩니다. GITOPS-1387
  • 이번 업데이트 이전에는 Operator에서 argocd-secret Secret의 .data 필드가 없는 Argo CD 인스턴스를 관리하면 해당 인스턴스의 Operator가 충돌했습니다. 이번 업데이트에서는 .data 필드가 누락될 때 Operator가 충돌하지 않도록 문제를 해결합니다. 대신 보안이 다시 생성되고 gitops-operator-controller-manager 리소스가 재배포됩니다. GITOPS-1402
  • 이번 업데이트 이전에는 gitopsservice 서비스에 내부 오브젝트로 주석이 달렸습니다. 이번 업데이트에서는 주석을 제거하므로 기본 Argo CD 인스턴스를 업데이트하거나 삭제하고 UI를 사용하여 인프라 노드에서 GitOps 워크로드를 실행할 수 있습니다. GITOPS-1429

4.1.34.3. 확인된 문제

다음은 현재 릴리스에서 알려진 문제입니다.

  • Dex 인증 공급자에서 Keycloak 공급자로 마이그레이션하는 경우 Keycloak에 로그인 문제가 발생할 수 있습니다.

    이 문제를 방지하려면 Argo CD 사용자 정의 리소스에서 .spec.dex 섹션을 제거하여 Dex를 제거합니다. Dex가 완전히 제거될 때까지 몇 분 정도 기다립니다. 그런 다음 Argo CD 사용자 정의 리소스에 .spec.sso.provider: keycloak 을 추가하여 Keycloak을 설치합니다.

    해결 방법으로 .spec.sso.provider: keycloak 을 제거하여 Keycloak을 제거합니다. 그런 다음 다시 설치하십시오. GITOPS-1450, GITOPS-1331

4.1.35. Red Hat OpenShift GitOps 1.3.7 릴리스 노트

Red Hat OpenShift GitOps 1.3.7은 이제 제한된 GA 지원이 포함된 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.6에서 사용할 수 있습니다.

4.1.35.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이번 업데이트 이전에는 OpenSSL에서 취약점이 발견되었습니다. 이번 업데이트에서는 OpenSSL 결함이 발생하지 않도록 기본 이미지를 최신 버전으로 업데이트하여 문제를 해결합니다. (CVE-2022-0778).
참고

현재 Red Hat OpenShift GitOps 1.3 릴리스를 설치하고 제품 라이프 사이클 동안 추가 업데이트를 받으려면 GitOps-1.3 채널로 전환합니다.

4.1.36. Red Hat OpenShift GitOps 1.3.6 릴리스 노트

Red Hat OpenShift GitOps 1.3.6은 이제 제한된 GA 지원이 포함된 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.6에서 사용할 수 있습니다.

4.1.36.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • Red Hat OpenShift GitOps에서 부적절한 액세스 제어는 관리자 권한 상승 (CVE-2022-1025) 을 허용합니다. 이번 업데이트에서는 이 문제가 해결되었습니다.
  • 경로 문제 취약점으로 인해 아웃 오브 바운드 파일 (CVE-2022-24731) 이 유출될 수 있습니다. 이번 업데이트에서는 이 문제가 해결되었습니다.
  • 경로 문제 취약점 및 부적절한 액세스 제어로 인해 아웃 오브 바운드 파일 (CVE-2022-24730) 이 유출될 수 있습니다. 이번 업데이트에서는 이 문제가 해결되었습니다.

4.1.37. Red Hat OpenShift GitOps 1.3.2 릴리스 노트

Red Hat OpenShift GitOps 1.3.2는 이제 제한된 GA 지원이 포함된 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.6에서 사용할 수 있습니다.

4.1.37.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift GitOps 1.3.2의 새로운 기능도 소개합니다.

  • Argo CD를 버전 2.1.8로 업그레이드
  • 버전 2.30.0으로 업그레이드 Dex

4.1.37.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이전 버전에서는 인프라 기능 섹션의 OperatorHub UI에서 연결되지 않은 경우 Operator에 CSV 파일에 관련 주석이 설정되지 않았기 때문에 Red Hat OpenShift GitOps Operator가 검색 결과에 표시되지 않았습니다. 이번 업데이트를 통해 Red Hat OpenShift GitOps Operator에 인프라 기능으로 연결되지 않은 Cluster 주석이 추가되었습니다. GITOPS-1539

  • 네임스페이스 범위의 Argo CD 인스턴스를 사용하는 경우 예를 들어 클러스터에서 모든 Namepsaces 로 지정되지 않은 Argo CD 인스턴스인 Red Hat OpenShift GitOps는 관리 네임스페이스 목록을 동적으로 유지합니다. 이러한 네임스페이스에는 argocd.argoproj.io/managed-by 레이블이 포함됩니다. 이 네임스페이스 목록은 Argo CD → 설정 → 클러스터 → "클러스터" → NAMESPACES 의 캐시에 저장됩니다. 이번 업데이트 이전에는 이러한 네임스페이스 중 하나를 삭제한 경우 Operator에서 이를 무시하고 네임스페이스가 목록에 남아 있었습니다. 이로 인해 클러스터 구성에서 CONNECTION STATE 가 중단되고 모든 동기화 시도에 오류가 발생했습니다. 예를 들면 다음과 같습니다. 

    Argo service account does not have <random_verb> on <random_resource_type> in namespace <the_namespace_you_deleted>.

    이 버그가 수정되었습니다. GITOPS-1521

  • 이번 업데이트를 통해 Red Hat OpenShift GitOps Operator에 Deep Insights 기능 수준이 주석이 추가되었습니다. GITOPS-1519
  • 이전에는 Argo CD Operator가 resource.exclusion 필드를 자체적으로 관리했지만 resource.inclusion 필드를 무시했습니다. 이로 인해 Argo CD CR에 구성된 resource.inclusion 필드가 argocd-cm 구성 맵에 생성되지 않았습니다. 이 버그가 수정되었습니다. GITOPS-1518

4.1.38. Red Hat OpenShift GitOps 1.3.1 릴리스 노트

Red Hat OpenShift GitOps 1.3.1은 이제 제한된 GA 지원이 포함된 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.6에서 사용할 수 있습니다.

4.1.38.1. 해결된 문제

  • v1.3.0으로 업그레이드하는 경우 Operator는 정렬된 환경 변수 슬라이스를 반환하지 않습니다. 결과적으로 조정기가 실패하여 프록시 뒤에서 실행되는 OpenShift Container Platform 클러스터에서 Argo CD Pod를 자주 다시 생성합니다. 이번 업데이트에서는 Argo CD Pod가 다시 생성되지 않도록 문제가 해결되었습니다. GITOPS-1489

4.1.39. Red Hat OpenShift GitOps 1.3 릴리스 노트

Red Hat OpenShift GitOps 1.3은 이제 제한된 GA 지원이 포함된 OpenShift Container Platform 4.7, 4.8, 4.9 및 4.6에서 사용할 수 있습니다.

4.1.39.1. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift GitOps 1.3.0의 새로운 기능도 소개합니다.

  • v1.3.0의 새로 설치의 경우 Dex가 자동으로 구성됩니다. OpenShift 또는 kubeadmin 인증 정보를 사용하여 openshift-gitops 네임스페이스에서 기본 Argo CD 인스턴스에 로그인할 수 있습니다. 관리자는 Operator가 설치된 후 Dex 설치를 비활성화할 수 있습니다. 그러면 openshift-gitops 네임스페이스에서 Dex 배포를 제거할 수 있습니다.
  • Operator가 설치한 기본 Argo CD 인스턴스 및 함께 제공되는 컨트롤러는 이제 간단한 구성 토글을 설정하여 클러스터의 인프라 노드에서 실행할 수 있습니다.
  • Argo CD의 내부 통신은 TLS 및 OpenShift 클러스터 인증서를 사용하여 보호할 수 있습니다. Argo CD 경로는 cert-manager와 같은 외부 인증서 관리자를 사용하는 것 외에도 OpenShift 클러스터 인증서를 활용할 수 있습니다.
  • 콘솔 4.9의 개발자 화면에서 향상된 환경 페이지를 사용하여 GitOps 환경에 대한 인사이트를 얻을 수 있습니다.
  • 이제 DeploymentConfig 리소스, Route 리소스 및 OLM을 사용하여 설치한 Operator의 Argo CD에서 사용자 정의 상태 점검에 액세스할 수 있습니다.

  • GitOps Operator는 이제 최신 Operator-SDK에서 권장하는 이름 지정 규칙을 준수합니다.

    • 접두사 gitops-operator- 는 모든 리소스에 추가
    • 서비스 계정 이름이 gitops-operator-controller-manager로 변경되었습니다.

4.1.39.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이전 버전에서는 Argo CD의 새 인스턴스에서 관리할 새 네임스페이스를 설정하면 Operator가 해당 새 네임스페이스를 관리하기 위해 생성하는 새 역할 및 바인딩으로 인해 즉시 동기화 되지 않았습니다. 이 동작은 수정되었습니다. GITOPS-1384

4.1.39.3. 확인된 문제

  • Dex 인증 공급자에서 Keycloak 공급자로 마이그레이션하는 동안 Keycloak에 로그인 문제가 발생할 수 있습니다. GITOPS-1450

    위의 문제를 방지하려면 Argo CD 사용자 정의 리소스에 있는 .spec.dex 섹션을 제거하여 Dex를 설치 제거합니다. Dex가 완전히 제거될 때까지 몇 분 정도 기다린 다음 Argo CD 사용자 정의 리소스에 .spec.sso.provider: keycloak 을 추가하여 Keycloak을 설치합니다.

    해결 방법으로 .spec.sso.provider: keycloak 을 제거한 다음 다시 설치하여 Keycloak을 제거합니다.

4.1.40. Red Hat OpenShift GitOps 1.2.2 릴리스 노트

Red Hat OpenShift GitOps 1.2.2는 이제 OpenShift Container Platform 4.8에서 사용할 수 있습니다.

4.1.40.1. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • Argo CD의 모든 버전은 Helm 차트에서 사용할 임의의 값을 전달할 수 있는 경로 트래임 버그에 취약합니다. 이번 업데이트에서는 Helm 값 파일을 전달할 때 CVE-2022-24348 gitops 오류, path traversal 및 역참조의 심볼릭 링크를 수정합니다. GITOPS-1756

4.1.41. Red Hat OpenShift GitOps 1.2.1 릴리스 노트

Red Hat OpenShift GitOps 1.2.1은 이제 OpenShift Container Platform 4.8에서 사용할 수 있습니다.

4.1.41.1. 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

기술 프리뷰 기능 지원 범위

아래 표에서 기능은 다음 상태로 표시됩니다.

  • TP: 기술 프리뷰
  • GA: 상용 버전

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 4.2. 지원 매트릭스

기능Red Hat OpenShift GitOps 1.2.1

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager CLI(kam)

TP

4.1.41.2. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이전에는 시작 시 애플리케이션 컨트롤러에서 대용량 메모리 급증이 관찰되었습니다. 애플리케이션 컨트롤러에 대한 --kubectl-parallelism-limit 는 기본적으로 10으로 설정되어 있지만 Argo CD CR 사양에 .spec.controller.kubeParallelismLimit 에 대한 번호를 지정하여 이 값을 덮어쓸 수 있습니다. GITOPS-1255
  • 최신 Triggers API로 인해 kam bootstrap 명령을 사용할 때 kustomization.yaml의 중복 항목으로 인해 Kubernetes 빌드 오류가 발생했습니다. 이 문제를 해결하기 위해 Pipelines 및 Tekton 트리거 구성 요소가 각각 v0.24.2 및 v0.14.2로 업데이트되었습니다. GITOPS-1273
  • 소스 네임스페이스의 Argo CD 인스턴스가 삭제되면 이제 RBAC 역할 및 바인딩이 대상 네임스페이스에서 자동으로 제거됩니다. GITOPS-1228
  • 이전에는 Argo CD 인스턴스를 네임스페이스에 배포할 때 Argo CD 인스턴스가 "managed-by" 라벨이 자체 네임스페이스로 변경되었습니다. 이번 수정으로 네임스페이스에 대해 필요한 RBAC 역할 및 바인딩이 생성되고 삭제되도록 하는 동안 네임스페이스의 레이블이 지정되지 않았습니다. GITOPS-1247
  • 이전에는 repo-server 및 애플리케이션 컨트롤러의 경우 Argo CD 워크로드의 기본 리소스 요청 제한이 매우 제한적인 것으로 확인되었습니다. 이제 기존 리소스 할당량이 제거되었으며 repo 서버에서 기본 메모리 제한이 1024M로 증가했습니다. 이 변경 사항은 새 설치에만 영향을 미칩니다. 기존 Argo CD 인스턴스 워크로드는 영향을 받지 않습니다. GITOPS-1274

4.1.42. Red Hat OpenShift GitOps 1.2 릴리스 노트

Red Hat OpenShift GitOps 1.2는 이제 OpenShift Container Platform 4.8에서 사용할 수 있습니다.

4.1.42.1. 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

기술 프리뷰 기능 지원 범위

아래 표에서 기능은 다음 상태로 표시됩니다.

  • TP: 기술 프리뷰
  • GA: 상용 버전

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 4.3. 지원 매트릭스

기능Red Hat OpenShift GitOps 1.2

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager CLI(kam)

TP

4.1.42.2. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift GitOps 1.2의 새로운 기능도 소개합니다.

  • openshift-gitops 네임스페이스에 대한 읽기 또는 쓰기 권한이 없는 경우 이제 GitOps Operator에서 DISABLE_DEFAULT_ARGOCD_INSTANCE 환경 변수를 사용하고 기본 Argo CD 인스턴스가 openshift-gitops 네임스페이스에서 시작되지 않도록 TRUE로 설정할 수 있습니다.
  • 이제 리소스 요청 및 제한이 Argo CD 워크로드에서 구성됩니다. openshift-gitops 네임스페이스에서 리소스 할당량이 활성화됩니다. 결과적으로 openshift-gitops 네임스페이스에 수동으로 배포된 대역 외 워크로드는 리소스 요청 및 제한을 사용하여 구성해야 하며 리소스 할당량을 늘려야 할 수 있습니다.

  • Argo CD 인증은 이제 Red Hat SSO와 통합되며 클러스터의 OpenShift 4 ID 공급자로 자동으로 구성됩니다. 이 기능은 기본적으로 비활성화되어 있습니다. Red Hat SSO를 활성화하려면 다음과 같이 ArgoCD CR에 SSO 구성을 추가합니다. 현재keycloak은 지원되는 유일한 공급자입니다. 

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
  server:
    route:
     enabled: true

  • 라우터 샤딩을 지원하기 위해 경로 레이블을 사용하여 호스트 이름을 정의할 수 있습니다. 이제 server (argocd server), grafana, prometheus 경로에서 레이블 설정 지원을 사용할 수 있습니다. 경로에 레이블을 설정하려면 ArgoCD CR의 서버에 대한 경로 구성 아래에 labels를 추가합니다.

    argocd 서버에 라벨을 설정하는 ArgoCD CR YAML의 예

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  server:
    route:
     enabled: true
     labels:
       key1: value1
       key2: value2

  • GitOps Operator는 레이블을 적용하여 대상 네임스페이스의 리소스를 관리할 수 있도록 Argo CD 인스턴스에 권한을 자동으로 부여합니다. 사용자는 argocd.argoproj.io/managed-by: <source-namespace> 라벨을 사용하여 대상 네임스페이스에 레이블을 지정할 수 있습니다. 여기서 source-namespace는 argocd 인스턴스가 배포된 네임스페이스입니다.

4.1.42.3. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이전 버전에서는 사용자가 openshift-gitops 네임스페이스에서 기본 클러스터 인스턴스에서 관리하는 Argo CD의 추가 인스턴스를 생성한 경우 새 Argo CD 인스턴스를 담당하는 애플리케이션이 OutOfSync 상태로 중단되었습니다. 이 문제는 클러스터 시크릿에 소유자 참조를 추가하여 해결되었습니다. GITOPS-1025

4.1.42.4. 확인된 문제

이는 Red Hat OpenShift GitOps 1.2에서 알려진 문제입니다.

  • 소스 네임스페이스에서 Argo CD 인스턴스가 삭제되면 대상 네임스페이스의 argocd.argoproj.io/managed-by 레이블이 제거되지 않습니다. GITOPS-1228

  • Red Hat OpenShift GitOps 1.2의 openshift-gitops 네임스페이스에서 리소스 할당량이 활성화되었습니다. 이는 수동으로 배포된 대역 외 워크로드 및 openshift-gitops 네임스페이스의 기본 Argo CD 인스턴스에서 배포한 워크로드에 영향을 미칠 수 있습니다. Red Hat OpenShift GitOps v1.1.2에서 v1.2로 업그레이드하는 경우 리소스 요청 및 제한을 사용하여 워크로드를 구성해야 합니다. 추가 워크로드가 있는 경우 openshift-gitops 네임스페이스의 리소스 할당량을 늘려야 합니다.

    openshift-gitops 네임스페이스의 현재 리소스 할당량입니다.

    리소스요구 사항제한

    CPU

    6688m

    13750m

    메모리

    4544Mi

    9070Mi

    아래 명령을 사용하여 CPU 제한을 업데이트할 수 있습니다. 

    $ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'

    아래 명령을 사용하여 CPU 요청을 업데이트할 수 있습니다. 

    $ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]

    위의 명령의 경로를 cpu에서 memory로 교체하여 메모리를 업데이트할 수 있습니다.

4.1.43. Red Hat OpenShift GitOps 1.1 릴리스 노트

Red Hat OpenShift GitOps 1.1은 이제 OpenShift 컨테이너 플랫폼 4.7에서 사용할 수 있습니다.

4.1.43.1. 지원 매트릭스

이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다.

기술 프리뷰 기능 지원 범위

아래 표에서 기능은 다음 상태로 표시됩니다.

  • TP: 기술 프리뷰
  • GA: 상용 버전

해당 기능은 Red Hat Customer Portal의 지원 범위를 참조하십시오.

표 4.4. 지원 매트릭스

기능Red Hat OpenShift GitOps 1.1

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager CLI(kam)

TP

4.1.43.2. 새로운 기능

다음 섹션에서는 수정 및 안정성 개선 사항 외에 Red Hat OpenShift GitOps 1.1의 새로운 기능도 소개합니다.

  • 이제 ApplicationSet 기능이 추가되었습니다(기술 프리뷰). ApplicationSet 기능을 사용하면 Argo CD 애플리케이션을 다수의 클러스터와 monorepos 내에서 관리할 때 자동화와 유연성을 모두 사용할 수 있습니다. 또한 멀티테넌트 Kubernetes 클러스터에서 셀프 서비스를 사용할 수 있습니다.
  • Argo CD는 이제 클러스터 로깅 스택 및 OpenShift Container Platform 모니터링 및 경고 기능과 통합되었습니다.
  • Argo CD 인증이 OpenShift Container Platform과 통합되었습니다.
  • Argo CD 애플리케이션 컨트롤러는 이제 수평 크기 조정을 지원합니다.
  • Argo CD Redis 서버는 이제 HA(고가용성)를 지원합니다.

4.1.43.3. 해결된 문제

현재 릴리스에서 다음 문제가 해결되었습니다.

  • 이전에는 활성 글로벌 프록시 설정을 사용하여 프록시 서버 설정에서 Red Hat OpenShift GitOps가 예상대로 작동하지 않았습니다. 이 문제는 해결되었으며 이제 Red Hat OpenShift GitOps Operator가 Argo CD는 Pod에 FQDN(정규화된 도메인 이름)을 사용하여 구성 요소 간 통신을 활성화하도록 구성되어 있습니다. GITOPS-703
  • Red Hat OpenShift GitOps 백엔드는 Red Hat OpenShift GitOps URL의?ref= 쿼리 매개 변수를 사용하여 API를 호출합니다. 이전에는 이 매개변수를 URL에서 읽지 않아 백엔드에서 항상 기본 참조를 고려했습니다. 이 문제는 해결되어 Red Hat OpenShift GitOps 백엔드에서 Red Hat OpenShift GitOps URL에서 참조 쿼리 매개 변수를 추출하고 입력 참조가 제공되지 않은 경우에만 기본 참조를 사용합니다. GITOPS-817
  • 이전에는 Red Hat OpenShift GitOps 백엔드에서 유효한 GitLab 리포지토리를 찾지 못했습니다. 이는 Red Hat OpenShift GitOps 백엔드가 GitLab 리포지토리의 master 대신 main 분기 참조로 확인되었기 때문입니다. 이 문제는 이제 해결되었습니다. GITOPS-768
  • OpenShift Container Platform 웹 콘솔의 개발자 화면에 있는 환경 페이지에 애플리케이션 목록과 환경 수가 표시됩니다. 이 페이지에는 모든 애플리케이션을 나열하는 Argo CD 애플리케이션 페이지로 이동하는 Argo CD 링크도 표시됩니다. Argo CD 애플리케이션 페이지에는 선택한 애플리케이션만 필터링할 수 있는 LABELS (예: app.kubernetes.io/name=appName)가 있습니다. GITOPS-544

4.1.43.4. 확인된 문제

이는 Red Hat OpenShift GitOps 1.1에서 알려진 문제입니다.

  • Red Hat OpenShift GitOps는 Helm v2 및 ksonnet을 지원하지 않습니다.
  • RH SSO(Red Hat SSO) Operator는 연결이 끊긴 클러스터에서 지원되지 않습니다. 결과적으로 연결이 끊긴 클러스터에서 Red Hat OpenShift GitOps Operator 및 RH SSO 통합이 지원되지 않습니다.
  • OpenShift Container Platform 웹 콘솔에서 Argo CD 애플리케이션을 삭제하면 사용자 인터페이스에서 Argo CD 애플리케이션이 삭제되지만 배포는 여전히 클러스터에 있습니다. 해결 방법으로 Argo CD 콘솔에서 Argo CD 애플리케이션을 삭제합니다. GITOPS-830

4.1.43.5. 변경 사항 중단

4.1.43.5.1. Red Hat OpenShift GitOps v1.0.1에서 업그레이드

Red Hat OpenShift GitOps v1.0.1에서 v1.1으로 업그레이드하는 경우 Red Hat OpenShift GitOps Operator는 openshift-gitops 네임스페이스에 생성된 기본 Argo CD 인스턴스 이름을 argocd-cluster에서 openshift-gitops로 변경합니다.

이는 변경 사항이 중단되어 업그레이드 전에 수동으로 다음 단계를 수행해야 합니다.

  1. OpenShift Container Platform 웹 콘솔로 이동하여 openshift-gitops 네임스페이스에 있는 argocd-cm.yml 구성 맵 파일의 콘텐츠를 로컬 파일에 복사합니다. 내용은 다음 예와 같을 수 있습니다.

    argocd 구성 맵 YAML의 예

    kind: ConfigMap
apiVersion: v1
metadata:
selfLink: /api/v1/namespaces/openshift-gitops/configmaps/argocd-cm
resourceVersion: '112532'
name: argocd-cm
uid: f5226fbc-883d-47db-8b53-b5e363f007af
creationTimestamp: '2021-04-16T19:24:08Z'
managedFields:
...
namespace: openshift-gitops
labels:
  app.kubernetes.io/managed-by: argocd-cluster
  app.kubernetes.io/name: argocd-cm
  app.kubernetes.io/part-of: argocd
data: "" 1
admin.enabled: 'true'
statusbadge.enabled: 'false'
resource.exclusions: |
  - apiGroups:
    - tekton.dev
    clusters:
    - '*'
    kinds:
    - TaskRun
    - PipelineRun
ga.trackingid: ''
repositories: |
  - type: git
    url: https://github.com/user-name/argocd-example-apps
ga.anonymizeusers: 'false'
help.chatUrl: ''
url: >-
  https://argocd-cluster-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com   "" 2
help.chatText: ''
kustomize.buildOptions: ''
resource.inclusions: ''
repository.credentials: ''
users.anonymous.enabled: 'false'
configManagementPlugins: ''
application.instanceLabelKey: ''

    1
    argocd-cm.yml 구성 맵 파일의 data 섹션만 수동으로 복원합니다.
    2
    구성 맵 항목의 URL 값을 새 인스턴스 이름 openshift-gitops로 바꿉니다.
  2. 기본 argocd-cluster 인스턴스를 삭제합니다.
  3. 새 argocd-cm.yml 구성 맵 파일을 편집하여 전체 data 섹션을 수동으로 복원합니다.

  4. 구성 맵 항목의 URL 값을 새 인스턴스 이름 openshift-gitops로 바꿉니다. 예를 들어 위 예제에서 URL 값을 다음 URL 값으로 바꿉니다. 

    url: >-
  https://openshift-gitops-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com
  5. Argo CD 클러스터에 로그인하고 이전 구성이 있는지 확인합니다.

4.2. OpenShift GitOps 이해

4.2.1. GitOps 정보

GitOps는 클라우드 네이티브 애플리케이션에 대한 연속 배포를 구현하는 선언적 방법입니다. GitOps를 사용하여 다중 클러스터 Kubernetes 환경에서 OpenShift Container Platform 클러스터 및 애플리케이션을 관리하기 위해 반복 가능한 프로세스를 생성할 수 있습니다. GitOps는 복잡한 배포를 빠른 속도로 처리하고 자동화하여 배포 및 릴리스 주기 동안 시간을 절약합니다.

GitOps 워크플로는 개발, 테스트, 스테이징, 프로덕션 단계를 통해 애플리케이션을 내보냅니다. GitOps는 새 애플리케이션을 배포하거나 기존 애플리케이션을 업데이트하므로 리포지토리만 업데이트하면 됩니다. 기타 모든 작업은 GitOps에서 자동으로 처리합니다.

GitOps는 Git 가져오기 요청을 사용하여 인프라 및 애플리케이션 구성을 관리하는 일련의 관행입니다. GitOps의 Git 리포지토리는 시스템 및 애플리케이션 구성에 사용하는 단일 정보 소스입니다. 이 Git 리포지토리에는 지정된 환경에서 필요한 인프라에 대한 선언적 설명과 환경을 설명된 상태에 맞게 조정하는 자동화된 프로세스가 포함되어 있습니다. 또한 시스템의 전체 상태가 포함되므로 시스템 상태에 대한 변경 내역을 보고 감사할 수 있습니다. GitOps를 사용하면 인프라 및 애플리케이션 구성 확산 문제를 해결할 수 있습니다.

GitOps는 인프라 및 애플리케이션 정의를 코드로 정의합니다. 그런 다음 이 코드를 사용하여 여러 작업 공간과 클러스터를 관리하여 인프라 및 애플리케이션 구성 생성 작업을 단순화합니다. 코드 원칙을 따라 Git 리포지토리에 클러스터 및 애플리케이션 구성을 저장한 다음 Git 워크플로를 따라 이러한 리포지토리를 선택한 클러스터에 적용할 수 있습니다. Git 리포지토리에서 소프트웨어 개발 및 유지보수의 핵심 원칙을 클러스터 및 애플리케이션 구성 파일의 생성 및 관리에 적용할 수 있습니다.

4.2.2. Red Hat OpenShift GitOps 정보

Red Hat OpenShift GitOps를 사용하면 개발, 스테이징, 프로덕션과 같은 다양한 환경의 다양한 클러스터에 애플리케이션을 배포할 때 애플리케이션의 일관성을 유지할 수 있습니다. Red Hat OpenShift GitOps는 구성 리포지토리를 중심으로 배포 프로세스를 구성한 후 이 프로세스를 중심 요소로 만듭니다. 항상 두 개 이상의 리포지토리가 있습니다.

  1. 소스 코드가 있는 애플리케이션 리포지토리
  2. 원하는 애플리케이션 상태를 정의하는 환경 구성 리포지토리

이러한 리포지토리에는 지정된 환경에서 필요한 인프라에 대한 선언적 설명이 포함되어 있습니다. 또한 환경을 설명된 상태에 맞게 조정하는 자동화된 프로세스가 포함되어 있습니다.

Red Hat OpenShift GitOps는 Argo CD를 사용하여 클러스터 리소스를 유지합니다. Argo CD는 애플리케이션의 CI/CD(연속 통합 및 연속 배포)에 사용되는 오픈 소스 선언 도구입니다. Red Hat OpenShift GitOps는 Argo CD를 컨트롤러로 구현하여 Git 리포지토리에 정의된 애플리케이션 정의 및 구성을 지속적으로 모니터링합니다. 그러면 Argo CD에서 이러한 구성의 지정된 상태를 클러스터의 라이브 상태와 비교합니다.

Argo CD는 지정된 상태에서 벗어난 모든 구성을 보고합니다. 이러한 보고서를 통해 관리자는 자동 또는 수동으로 구성을 정의된 상태로 다시 동기화할 수 있습니다 따라서 Argo CD를 사용하면 OpenShift Container Platform 클러스터를 구성하는 데 사용하는 리소스와 같이 글로벌 사용자 정의 리소스를 제공할 수 있습니다.

4.2.2.1. 주요 기능

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

  • 클러스터의 구성, 모니터링, 스토리지 상태가 비슷한지 확인
  • 여러 OpenShift Container Platform 클러스터에 구성 변경 사항 적용 또는 되돌리기
  • 템플릿 구성을 다른 환경과 연결
  • 스테이징에서 프로덕션까지 클러스터 전체에서 애플리케이션 승격

4.3. Installing Red Hat OpenShift GitOps

Red Hat OpenShift GitOps는 Argo CD를 사용하여 클러스터 Operator, 선택적 OLM(Operator Lifecycle Manager) Operator 및 사용자 관리를 포함한 특정 클러스터 범위 리소스를 관리합니다.

사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • cluster-admin 역할을 가진 사용자로 로그인했습니다.
  • OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.
  • 클러스터에 Marketplace 기능이 활성화되었거나 Red Hat Operator 카탈로그 소스가 수동으로 구성되어 있습니다.
주의

Argo CD Operator의 커뮤니티 버전을 이미 설치한 경우 Red Hat OpenShift GitOps Operator를 설치하기 전에 Argo CD Community Operator를 제거하십시오.

이 가이드에서는 Red Hat OpenShift GitOps Operator를 OpenShift Container Platform 클러스터에 설치하고 Argo CD 인스턴스에 로그인하는 방법을 설명합니다.

중요

최신 채널을 사용하면 Red Hat OpenShift GitOps Operator의 최신 안정적인 버전을 설치할 수 있습니다. 현재 이 채널은 Red Hat OpenShift GitOps Operator를 설치하는 기본 채널입니다.

특정 버전의 Red Hat OpenShift GitOps Operator를 설치하기 위해 클러스터 관리자는 해당 gitops-<version > 채널을 사용할 수 있습니다. 예를 들어 Red Hat OpenShift GitOps Operator 버전 1.8.x를 설치하려면 gitops-1.8 채널을 사용할 수 있습니다.

4.3.1. 웹 콘솔에서 Red Hat OpenShift GitOps Operator 설치

프로세스

  1. 왼쪽 메뉴에 있는 웹 콘솔의 관리자 화면을 열고Operator → OperatorHub로 이동합니다.

  2. OpenShift GitOps 를 검색하고 Red Hat OpenShift GitOps 타일을 클릭한 다음 설치를 클릭합니다.

    Red Hat OpenShift GitOps는 클러스터의 모든 네임스페이스에 설치됩니다.

Red Hat OpenShift GitOps Operator를 설치한 후 openshift-gitops 네임스페이스에서 제공되는 즉시 사용 가능한 Argo CD 인스턴스가 자동으로 설정되고 콘솔 도구 모음에 Argo CD 아이콘이 표시됩니다. 프로젝트에서 애플리케이션에 대한 후속 Argo CD 인스턴스를 생성할 수 있습니다.

4.3.2. CLI를 사용하여 Red Hat OpenShift GitOps Operator 설치

CLI를 사용하여 OperatorHub에서 Red Hat OpenShift GitOps Operator를 설치할 수 있습니다.

프로세스

  1. 서브스크립션 오브젝트 YAML 파일을 생성하여 Red Hat OpenShift GitOps에 네임스페이스를 등록합니다(예: sub.yaml ).

    서브스크립션의 예

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-operators
spec:
  channel: latest 1
  installPlanApproval: Automatic
  name: openshift-gitops-operator 2
  source: redhat-operators 3
  sourceNamespace: openshift-marketplace 4

    1
    Operator를 서브스크립션할 채널 이름을 지정합니다.
    2
    등록할 Operator의 이름을 지정합니다.
    3
    Operator를 제공하는 CatalogSource의 이름을 지정합니다.
    4
    CatalogSource의 네임스페이스입니다. 기본 OperatorHub CatalogSources에는 openshift-marketplace를 사용합니다.

  2. 클러스터에 서브스크립션을 적용합니다. 

    $ oc apply -f openshift-gitops-sub.yaml

  3. 설치가 완료되면 openshift-gitops 네임스페이스의 모든 Pod가 실행 중인지 확인합니다. 

    $ oc get pods -n openshift-gitops

    출력 예

    NAME                                                      	READY   STATUS	RESTARTS   AGE
cluster-b5798d6f9-zr576                                   	1/1 	Running   0      	65m
kam-69866d7c48-8nsjv                                      	1/1 	Running   0      	65m
openshift-gitops-application-controller-0                 	1/1 	Running   0      	53m
openshift-gitops-applicationset-controller-6447b8dfdd-5ckgh 1/1 	Running   0      	65m
openshift-gitops-redis-74bd8d7d96-49bjf                   	1/1 	Running   0      	65m
openshift-gitops-repo-server-c999f75d5-l4rsg              	1/1 	Running   0      	65m
openshift-gitops-server-5785f7668b-wj57t                  	1/1 	Running   0      	53m

4.3.3. Argo CD 관리자 계정을 사용하여 Argo CD 인스턴스에 로그인

Red Hat OpenShift GitOps Operator는 openshift-gitops 네임스페이스에서 사용할 수 있는 즉시 사용 가능한 Argo CD 인스턴스를 자동으로 생성합니다.

사전 요구 사항

  • 클러스터에 Red Hat OpenShift GitOps Operator가 설치되어 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator → 설치된 Operator로 이동하여 Red Hat OpenShift GitOps Operator가 설치되어 있는지 확인합니다.
  2. red hat applications menu icon 메뉴 → OpenShift GitOps → 클러스터 Argo CD 로 이동합니다. Argo CD UI의 로그인 페이지가 새 창에 표시됩니다.

  3. Argo CD 인스턴스의 암호를 가져옵니다.

    1. 콘솔의 왼쪽 패널에서 모드 전환기를 사용하여 개발자 화면으로 전환합니다.
    2. 프로젝트 드롭다운 목록을 사용하고 openshift-gitops 프로젝트를 선택합니다.
    3. 왼쪽 탐색 패널을 사용하여 시크릿 페이지로 이동합니다.
    4. 암호를 표시할 argocd-cluster-cluster 인스턴스를 선택합니다.

    5. 암호를 복사합니다.

      참고

      OpenShift Container Platform 인증 정보로 로그인하려면 Argo CD 사용자 인터페이스에서 LOG IN VIA OPENSHIFT 옵션을 선택합니다.

  4. 이 암호와 admin을 사용자 이름으로 사용하여 새 창에서 Argo CD UI에 로그인합니다.
참고

동일한 네임스페이스에 두 개의 Argo CD CR을 생성할 수 없습니다.

4.4. OpenShift GitOps 설치 제거

Red Hat OpenShift GitOps Operator 설치 제거는 2단계 프로세스입니다.

  1. Red Hat OpenShift GitOps Operator의 기본 네임스페이스에 추가된 Argo CD 인스턴스를 삭제합니다.
  2. Red Hat OpenShift GitOps Operator를 설치 제거합니다.

Operator만 설치 제거해도 생성된 Argo CD 인스턴스가 제거되지 않습니다.

4.4.1. Argo CD 인스턴스 삭제

GitOps Operator의 네임스페이스에 추가된 Argo CD 인스턴스를 삭제합니다.

프로세스

  1. 터미널에서 다음 명령을 입력합니다. 
$ oc delete gitopsservice cluster -n openshift-gitops
참고

웹 콘솔 UI에서 Argo CD 클러스터를 삭제할 수 없습니다.

명령이 성공적으로 실행되면 openshift-gitops 네임스페이스에서 모든 Argo CD 인스턴스가 삭제됩니다.

동일한 명령을 사용하여 다른 네임스페이스에서 다른 Argo CD 인스턴스를 삭제합니다. 

$ oc delete gitopsservice cluster -n <namespace>

4.4.2. GitOps Operator 설치 제거

프로세스

  1. Operators → OperatorHub 페이지에서 키워드로 필터링 상자를 사용하여 Red Hat OpenShift GitOps Operator 타일을 검색합니다.
  2. Red Hat OpenShift GitOps Operator 타일을 클릭합니다. Operator 타일은 Operator가 설치되었음을 나타냅니다.
  3. Red Hat OpenShift GitOps Operator 설명자 페이지에서 설치 제거를 클릭합니다.

추가 리소스

4.5. Argo CD 인스턴스 설정

기본적으로 Red Hat OpenShift GitOps는 특정 클러스터 범위 리소스를 관리하는 데 필요한 추가 권한이 있는 openshift-gitops 네임스페이스에 Argo CD 인스턴스를 설치합니다. 클러스터 구성을 관리하거나 애플리케이션을 배포하려면 새 Argo CD 인스턴스를 설치하고 배포할 수 있습니다. 기본적으로 모든 새 인스턴스에는 배포된 네임스페이스에서만 리소스를 관리할 수 있는 권한이 있습니다.

4.5.1. Argo CD 설치

클러스터 구성을 관리하거나 애플리케이션을 배포하려면 새 Argo CD 인스턴스를 설치하고 배포할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Operators → 설치된 Operators를 클릭합니다.
  3. 프로젝트 드롭다운 메뉴에서 Argo CD 인스턴스를 설치할 프로젝트를 생성하거나 선택합니다.
  4. 설치된 Operator에서 OpenShift GitOps Operator 를 선택하고 Argo CD 탭을 선택합니다.

  5. 생성 을 클릭하여 매개변수를 구성합니다.

    1. 인스턴스의 이름을 입력합니다. 기본적으로 이름은 argocd 로 설정됩니다.
    2. Argo CD 서버에 액세스할 외부 OS 경로를 생성합니다. 서버 → 경로를 클릭하고 Enabled 를 확인합니다.
  6. Argo CD 웹 UI를 시작하려면 Argo CD 인스턴스가 설치된 프로젝트에서 네트워킹 → 경로 → <instance name>-server 로 이동하여 경로를 클릭합니다.

4.5.2. Argo CD 서버 및 저장소 서버의 복제본 활성화

Argo CD-server 및 Argo CD-repo-server 워크로드는 상태 비저장입니다. Pod 간에 워크로드를 더 효과적으로 배포하기 위해 Argo CD-server 및 Argo CD-repo-server 복제본 수를 늘릴 수 있습니다. 그러나 Argo CD-server에서 수평 자동 스케일러가 활성화된 경우 설정한 복제본 수를 덮어씁니다.

프로세스

  • 리포지토리 및 서버 사양에 대한 replicas 매개변수를 실행하려는 복제본 수로 설정합니다.

    Argo CD 사용자 정의 리소스의 예

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: repo
spec:
  repo:
    replicas: <number_of_replicas>
  server:
    replicas: <number_of_replicas>
    route:
      enabled: true
      path: /
      tls:
        insecureEdgeTerminationPolicy: Redirect
        termination: passthrough
      wildcardPolicy: None

4.5.3. 다른 네임스페이스에 리소스 배포

Argo CD가 설치된 위치와 별도로 다른 네임스페이스에서 리소스를 관리할 수 있도록 하려면 대상 네임스페이스를 argocd.argoproj.io/managed-by 라벨을 사용하여 구성합니다.

프로세스

  • 네임스페이스를 구성합니다. 

    $ oc label namespace <namespace> \
argocd.argoproj.io/managed-by=<namespace> 1
    1
    Argo CD가 설치된 네임스페이스입니다.

4.6. 점진적 배포 전달을 위해 Argo Rollouts 사용

중요

Argo 롤아웃은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

점진적인 제공은 제품 업데이트를 제어 및 점진적으로 배포하는 프로세스입니다. 점진적인 제공으로 인해 새 버전의 제품 업데이트를 처음에 사용자의 하위 집합에만 노출하여 릴리스의 위험을 줄일 수 있습니다. 이 프로세스에는 이 새 버전을 지속적으로 관찰 및 분석하여 해당 동작이 요구 사항 및 기대치와 일치하는지 확인해야 합니다. 이 검증은 프로세스가 제품 업데이트를 더 넓고 광범위한 대상에게 점진적으로 노출함에 따라 계속됩니다.

OpenShift Container Platform에서는 경로를 사용하여 다른 서비스 간에 트래픽을 분할하여 점진적인 제공 기능을 제공하지만 일반적으로 수동 개입과 관리가 필요합니다.

Argo Rollouts를 사용하면 자동화 및 메트릭 분석을 사용하여 점진적 배포 전달을 지원하고 새로운 버전의 애플리케이션을 자동 롤아웃 또는 롤백할 수 있습니다. Argo Rollouts는 고급 배포 기능을 제공하고 Ingress 컨트롤러 및 서비스 메시와의 통합을 활성화합니다. Argo Rollouts를 사용하여 배포된 애플리케이션의 다른 버전을 나타내는 여러 복제본 세트를 관리할 수 있습니다. 배포 전략에 따라 기존 트래픽 형성 기능을 최적화하고 트래픽을 새 버전으로 점진적으로 전환하여 업데이트 중에 이러한 버전으로의 트래픽을 처리할 수 있습니다. Argo 롤아웃은 Prometheus와 같은 메트릭 공급자와 결합하여 매개변수 세트를 기반으로 메트릭 기반 및 정책 기반 롤아웃 및 롤백을 수행할 수 있습니다.

4.6.1. 사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • Red Hat OpenShift GitOps 1.9.0 또는 최신 버전이 클러스터에 설치되어 있습니다.

4.6.2. Argo 롤아웃의 이점

기존 인프라에서 고급 배포 전략을 관리하고 조정하려면 오랜 유지 관리 기간이 필요한 경우가 많습니다. OpenShift Container Platform 및 Red Hat OpenShift GitOps와 같은 툴을 사용한 자동화는 이러한 창을 줄일 수 있지만 이러한 전략을 설정하는 것은 여전히 어려울 수 있습니다. Argo Rollouts를 사용하면 애플리케이션 팀이 롤아웃 전략을 선언적으로 정의할 수 있으므로 이 프로세스를 단순화할 수 있습니다. 팀은 더 이상 여러 배포 및 서비스를 정의하거나 트래픽 형성 및 테스트 통합을 위한 자동화를 생성할 필요가 없습니다. Argo Rollouts를 사용하면 선언적 롤아웃 전략에 필요한 모든 정의를 캡슐화하고 프로세스를 자동화하고 관리할 수 있습니다.

Red Hat OpenShift GitOps의 기본 워크로드로 Argo 롤아웃을 사용하면 다음과 같은 이점이 있습니다.

  • GitOps 워크플로우의 일부로 점진적인 자동 제공
  • 고급 배포 기능
  • Blue-green 또는 카나리아와 같은 기존 고급 배포 전략 최적화
  • 배포를 위한 제로 다운타임 업데이트
  • 세분화되고 가중된 트래픽 전환
  • 새 트래픽이 프로덕션 환경에 도달하지 않고 테스트할 수 있음
  • 자동 롤백 및 승격
  • 수동 판단
  • 비즈니스 핵심 성과 지표 (KPI)의 사용자 정의 메트릭 쿼리 및 분석
  • 고급 트래픽 라우팅을 위한 수신 컨트롤러 및 Red Hat OpenShift Service Mesh와의 통합
  • 배포 전략 분석을 위한 메트릭 공급자와 통합
  • 여러 공급자 사용

Argo Rollouts를 사용하면 최종 사용자 환경에서 점진적인 제공을 보다 쉽게 채택할 수 있습니다. 이를 통해 팀은 트래픽 관리자와 복잡한 인프라에 대해 배울 필요 없이 구조와 지침을 제공합니다. Red Hat OpenShift GitOps Operator는 자동 롤아웃을 통해 최종 사용자 환경에 보안을 제공하고 리소스, 비용 및 시간을 효과적으로 관리하는 데 도움이 됩니다. 보안 및 자동화된 배포와 함께 Argo CD를 사용하는 기존 사용자는 프로세스 초기에 피드백을 얻고 영향을 미치는 문제를 방지합니다.

4.6.3. RolloutManager 사용자 정의 리소스 및 사양 정보

Argo 롤아웃을 사용하려면 클러스터에 Red Hat OpenShift GitOps Operator를 설치한 다음 선택한 네임스페이스의 Operator에 RolloutManager CR(사용자 정의 리소스)을 생성하고 제출해야 합니다. 단일 네임스페이스 또는 여러 네임스페이스에 대해 RolloutManager CR의 범위를 지정할 수 있습니다. Operator는 다음과 같은 네임스페이스 범위 지원 리소스를 사용하여 argo-rollouts 인스턴스를 생성합니다.

  • Argo Rollouts 컨트롤러
  • Argo Rollouts 메트릭 서비스
  • Argo Rollouts 서비스 계정
  • Argo 롤아웃 역할
  • Argo Rollouts 역할 바인딩
  • Argo Rollouts 시크릿

RolloutsManager CR의 사양에 Argo Rollouts 컨트롤러 리소스에 대해 명령 인수, 환경 변수, 사용자 정의 이미지 이름 등을 지정할 수 있습니다. RolloutManager CR 사양은 Argo Rollouts의 원하는 상태를 정의합니다.

예: RolloutManager CR

apiVersion: argoproj.io/v1alpha1
kind: RolloutManager
metadata:
  name: argo-rollout
  labels:
    example: basic
spec: {}

4.6.3.1. Argo Rollouts 컨트롤러

Argo Rollouts 컨트롤러 리소스를 사용하면 네임스페이스에서 프로그레시브 애플리케이션 제공을 관리할 수 있습니다. Argo Rollouts 컨트롤러 리소스는 클러스터에 이벤트를 모니터링하고 Argo Rollouts와 관련된 모든 리소스가 변경될 때마다 반응합니다. 컨트롤러는 모든 롤아웃 세부 정보를 읽고 롤아웃 정의에 설명된 것과 동일한 상태로 클러스터를 가져옵니다.

추가 리소스

RolloutManager 사용자 정의 리소스 사양

4.6.4. RolloutManager 사용자 정의 리소스 생성

Red Hat OpenShift GitOps에서 Argo Rollouts를 사용하여 배포를 점진적으로 제공하려면 선택한 네임스페이스에서 RolloutManager CR(사용자 정의 리소스)을 생성하고 구성해야 합니다. 기본적으로 모든 새 argo-rollouts 인스턴스에는 배포된 네임스페이스에서만 리소스를 관리할 수 있는 권한이 있지만 필요에 따라 여러 네임스페이스에서 Argo Rollouts를 사용할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift GitOps 1.9.0 또는 최신 버전이 클러스터에 설치되어 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 관리자 화면에서 Operator → 설치된 Operator 를 클릭합니다.
  3. 프로젝트 드롭다운 메뉴에서 RolloutManager CR(사용자 정의 리소스)을 생성하고 구성할 프로젝트를 생성하거나 선택합니다.
  4. 설치된 Operator에서 OpenShift GitOps Operator 를 선택합니다.
  5. 세부 정보 탭의 제공된 API 섹션에서 RolloutManager 창에서 인스턴스 생성 을 클릭합니다.

  6. RolloutManager 생성 페이지에서 YAML 보기를 선택하고 기본 YAML을 사용하거나 요구 사항에 따라 편집합니다.

    예: RolloutManager CR

    apiVersion: argoproj.io/v1alpha1
kind: RolloutManager
metadata:
  name: argo-rollout
  labels:
    example: basic
spec: {}

  7. 생성을 클릭합니다.
  8. RolloutManager 탭의 RolloutManagers 섹션에서 RolloutManager 인스턴스의 Status 필드가 Phase: Available 로 표시되는지 확인합니다.

  9. 왼쪽 탐색 창에서 네임스페이스 범위 지원 리소스 생성을 확인합니다.

    • 워크로드 → 배포를 클릭하여 argo-rollouts 배포를 실행 중인 1개의 Pod 중 1 개로 표시된 상태에서 사용할 수 있는지 확인합니다.
    • 워크로드 → 시크릿을 클릭하여 argo-rollouts-notification-secret 시크릿을 사용할 수 있는지 확인합니다.
    • 네트워킹 → 서비스를 클릭하여 argo-rollouts-metrics 서비스를 사용할 수 있는지 확인합니다.
    • 사용자 관리 → 역할을 클릭하여 argo-rollouts 역할 및 argo-rollouts-aggregate-to-admin,argo-rollouts-aggregate-to-edit, argo-rollouts-aggregate-to-view 클러스터 역할을 사용할 수 있는지 확인합니다.
    • 사용자 관리 → RoleBindings 를 클릭하여 argo-rollouts 역할 바인딩을 사용할 수 있는지 확인합니다.

추가 리소스

4.6.5. RolloutManager 사용자 정의 리소스 삭제

Red Hat OpenShift GitOps Operator를 설치 제거해도 설치 중에 생성된 리소스는 제거되지 않습니다. Red Hat OpenShift GitOps Operator를 제거하기 전에 RolloutManager CR(사용자 정의 리소스)을 수동으로 삭제해야 합니다.

사전 요구 사항

  • Red Hat OpenShift GitOps 1.9.0 또는 최신 버전이 클러스터에 설치되어 있습니다.
  • 네임스페이스에 RolloutManager CR이 있습니다.

절차

  1. OpenShift Container Platform 웹 콘솔에 클러스터 관리자로 로그인합니다.
  2. 관리자 화면에서 Operator → 설치된 Operator 를 클릭합니다.
  3. 프로젝트 드롭다운 메뉴를 클릭하고 RolloutManager CR이 포함된 프로젝트를 선택합니다.
  4. 설치된 Operator에서 OpenShift GitOps Operator 를 선택합니다.
  5. RolloutManager 탭을 클릭하여 RolloutManagers 섹션에서 RolloutManager 인스턴스를 찾습니다.
  6. 인스턴스를 클릭합니다.
  7. 드롭다운 메뉴에서 작업 → 롤아웃 삭제 를 클릭하고 삭제 를 클릭하여 대화 상자에서 확인합니다.
  8. RolloutManager 탭의 RolloutManagers 섹션에서 RolloutManager 인스턴스를 더 이상 사용할 수 없는지 확인합니다.

  9. 왼쪽 탐색 창에서 네임스페이스 범위의 지원 리소스가 삭제되었는지 확인합니다.

    • 워크로드 → 배포를 클릭하여 argo-rollouts 배포가 삭제되었는지 확인합니다.
    • 워크로드 → 시크릿을 클릭하여 argo-rollouts-notification-secret 시크릿이 삭제되었는지 확인합니다.
    • 네트워킹 → 서비스를 클릭하여 argo-rollouts-metrics 서비스가 삭제되었는지 확인합니다.
    • 사용자 관리 → 역할을 클릭하여 argo-rollouts 역할 및 argo-rollouts-aggregate-to-admin,argo-rollouts-aggregate-to-edit, argo-rollouts-aggregate-to-view 클러스터 역할이 삭제되었는지 확인합니다.
    • 사용자 관리 → RoleBindings 를 클릭하여 argo-rollouts 역할 바인딩이 삭제되었는지 확인합니다.

4.6.6. 추가 리소스

4.7. 클러스터 구성으로 애플리케이션을 배포하여 OpenShift 클러스터 구성

Red Hat OpenShift GitOps를 사용하면 Argo CD를 구성하여 Git 디렉터리의 콘텐츠를 클러스터의 사용자 지정 구성이 포함된 애플리케이션과 반복적으로 동기화할 수 있습니다.

사전 요구 사항

  • 관리자로 OpenShift Container Platform 클러스터에 로그인했습니다.
  • 클러스터에 Red Hat OpenShift GitOps Operator가 설치되어 있습니다.
  • Argo CD 인스턴스에 로그인했습니다.

4.7.1. Argo CD 인스턴스를 사용하여 클러스터 범위 리소스 관리

클러스터 범위 리소스를 관리하려면 Red Hat OpenShift GitOps Operator의 기존 Subscription 오브젝트를 업데이트하고 Argo CD 인스턴스의 네임스페이스를 spec 섹션의 ARGOCD_CLUSTER_CONFIG_NAMESPACES 환경 변수에 추가합니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator → 설치된 Operator → Red Hat OpenShift GitOps → 서브스크립션으로 이동합니다.
  2. 작업 드롭다운 메뉴를 클릭한 다음 서브스크립션 편집 을 클릭합니다.

  3. openshift-gitops-operator Subscription 세부 정보 페이지의 YAML 탭에서 Argo CD 인스턴스의 네임스페이스를 spec 섹션의 ARGOCD_CLUSTER_CONFIG_NAMESPACES 환경 변수에 추가하여 서브스크립션 YAML 파일을 편집합니다. 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-operators
...
spec:
  config:
    env:
    - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES
      value: openshift-gitops, <list of namespaces of cluster-scoped Argo CD instances>
...

  4. Argo 인스턴스가 클러스터 역할로 구성되어 클러스터 범위 리소스를 관리하는지 확인하려면 다음 단계를 수행합니다.

    1. 사용자 관리 → 역할로 이동하고 필터 드롭다운 메뉴에서 클러스터 전체 역할을 선택합니다.

    2. 이름으로 검색 필드를 사용하여 argocd-application-controller 를 검색합니다.

      Roles (역할) 페이지에 생성된 클러스터 역할이 표시됩니다.

      작은 정보

      또는 OpenShift CLI에서 다음 명령을 실행합니다. 

      oc auth can-i create oauth -n openshift-gitops --as system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller

      출력 yes 는 클러스터 범위 리소스를 관리하기 위해 Argo 인스턴스가 클러스터 역할로 구성되었는지 확인합니다. 구성을 확인하고 필요에 따라 필요한 단계를 수행합니다.

4.7.2. Argocd 인스턴스의 기본 권한

기본적으로 Argo CD 인스턴스에는 다음 권한이 있습니다.

  • Argo CD 인스턴스에는 배포된 네임스페이스에서만 리소스를 관리할 수 있는 관리자 권한이 있습니다. 예를 들어 foo 네임스페이스에 배포된 Argo CD 인스턴스에는 해당 네임스페이스에 대해서만 리소스를 관리할 수 있는 관리자 권한이 있습니다.

  • Argo CD에는 리소스에 대한 클러스터 전체 읽기 권한이 있어야 제대로 작동하기 때문에 Argo CD에는 다음과 같은 클러스터 범위 권한이 있습니다. 

    - verbs:
    - get
    - list
    - watch
   apiGroups:
    - '*'
   resources:
    - '*'
 - verbs:
    - get
    - list
   nonResourceURLs:
    - '*'
참고

  • Argo CD가 관리하려는 네임스페이스와 리소스로만 쓰기 권한이 제한되도록 Argo CD 및 argocd-server 및 argocd-application-controller 구성 요소에서 사용하는 클러스터 역할을 편집할 수 있습니다. 

    $ oc edit clusterrole argocd-server
$ oc edit clusterrole argocd-application-controller

4.7.3. 클러스터 수준에서 Argo CD 인스턴스 실행

이제 간단한 구성 토글을 설정하여 클러스터의 인프라 노드에서 기본 Argo CD 인스턴스 및 관련 컨트롤러를 실행할 수 있습니다.

프로세스

  1. 기존 노드에 레이블을 지정합니다. 

    $ oc label node <node-name> node-role.kubernetes.io/infra=""

  2. 선택 사항: 필요한 경우 테인트를 적용하고 인프라 노드의 워크로드를 격리하고 다른 워크로드가 이러한 노드에서 예약되지 않도록 할 수도 있습니다. 

    $ oc adm taint nodes -l node-role.kubernetes.io/infra \
infra=reserved:NoSchedule infra=reserved:NoExecute

  3. GitOpsService 사용자 정의 리소스에 runOnInfra 토글을 추가합니다. 

    apiVersion: pipelines.openshift.io/v1alpha1
kind: GitopsService
metadata:
  name: cluster
spec:
  runOnInfra: true

  4. 선택 사항: 테인트가 노드에 추가된 경우 GitOpsService 사용자 정의 리소스에 허용 오차 를 추가합니다. 예를 들면 다음과 같습니다. 

      spec:
    runOnInfra: true
    tolerations:
    - effect: NoSchedule
      key: infra
      value: reserved
    - effect: NoExecute
      key: infra
      value: reserved
  5. 콘솔 UI에서 Pod → Pod 세부 정보를 확인하여 openshift-gitops 네임스페이스의 워크로드가 인프라 노드에 예약되었는지 확인합니다.
참고

기본 Argo CD 사용자 정의 리소스에 수동으로 추가된 nodeSelector 및 허용 오차 는 GitOpsService 사용자 정의 리소스의 토글 및 허용 오차 를 통해 덮어씁니다.

추가 리소스

4.7.4. Argo CD 대시보드를 사용하여 애플리케이션 생성

Argo CD는 애플리케이션을 만들 수 있는 대시보드를 제공합니다.

이 샘플 워크플로에서는 Argo CD를 구성하여 cluster 디렉터리의 콘텐츠를 cluster-configs 애플리케이션과 반복적으로 동기화하는 프로세스를 보여줍니다. 디렉터리는 웹 콘솔의 red hat applications menu icon 메뉴에 있는 Red Hat 개발자 블로그에 링크를 추가하는 OpenShift Container Platform 웹 콘솔 클러스터 구성을 정의하고 클러스터에 spring-petclinic 네임스페이스를 정의합니다.

프로세스

  1. Argo CD 대시보드에서 새 APP를 클릭하여 새 Argo CD 애플리케이션을 추가합니다.

  2. 이 워크플로의 경우 다음 구성을 사용하여 cluster-configs 애플리케이션을 생성합니다.

    애플리케이션 이름
    cluster-configs
    프로젝트
    default
    동기화 정책
    수동
    리포지터리 URL
    https://github.com/redhat-developer/openshift-gitops-getting-started
    버전
    HEAD
    경로
    cluster
    대상
    https://kubernetes.default.svc
    네임스페이스
    spring-petclinic
    디렉토리 반복
    checked
  3. CREATE 를 클릭하여 애플리케이션을 생성합니다.
  4. 웹 콘솔의 관리자 화면을 열고 왼쪽 메뉴에 있는 관리 → 네임스페이스 로 이동합니다.
  5. 네임스페이스를 검색하고 선택한 다음 Label 필드에 argocd.argoproj.io/managed-by=openshift-gitops 를 입력하여 openshift-gitops 네임스페이스의 Argo CD 인스턴스가 네임스페이스를 관리할 수 있도록 합니다.

4.7.5. oc 툴을 사용하여 애플리케이션 생성

oc 툴을 사용하여 터미널에서 Argo CD 애플리케이션을 생성할 수 있습니다.

프로세스

  1. 샘플 애플리케이션을 다운로드합니다. 

    $ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git

  2. 애플리케이션을 생성합니다. 

    $ oc create -f openshift-gitops-getting-started/argo/app.yaml

  3. oc get 명령을 실행하여 생성된 애플리케이션을 검토합니다. 

    $ oc get application -n openshift-gitops

  4. 애플리케이션이 배포된 네임스페이스에 레이블을 추가하여 openshift-gitops 네임스페이스의 Argo CD 인스턴스에서 관리할 수 있습니다. 

    $ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops

4.7.6. Git 리포지토리와 애플리케이션 동기화

프로세스

  1. Argo CD 대시보드에서 cluster-configs Argo CD 애플리케이션은 Missing 및 OutOfSync 상태입니다. 애플리케이션이 수동 동기화 정책으로 구성되었으므로 Argo CD는 자동으로 동기화되지 않습니다.
  2. cluster-configs 타일에서 SYNC 를 클릭하고 변경 사항을 검토한 다음 SYNCHRONIZE 를 클릭합니다. Argo CD는 Git 리포지토리의 모든 변경 사항을 자동으로 감지합니다. 구성이 변경되면 Argo CD는 cluster-configs의 상태를 OutOfSync로 변경합니다. Argo CD의 동기화 정책을 수정하여 Git 리포지토리에서 클러스터에 변경 사항을 자동으로 적용할 수 있습니다.
  3. cluster-configs Argo CD 애플리케이션이 이제 Healthy 및 Synced 상태가 됩니다. cluster-configs 타일을 클릭하여 동기화된 리소스의 세부 정보와 클러스터의 상태를 확인합니다.
  4. OpenShift Container Platform 웹 콘솔로 이동하여 red hat applications menu icon 을 클릭하여 Red Hat 개발자 블로그 - Kubernetes 에 대한 링크가 있는지 확인합니다.

  5. 프로젝트 페이지로 이동하여 spring-petclinic 네임스페이스를 검색하여 클러스터에 추가되었는지 확인합니다.

    클러스터 구성이 클러스터에 성공적으로 동기화됩니다.

4.7.7. 클러스터 구성에 대한 내장 권한

기본적으로 Argo CD 인스턴스에는 클러스터 Operator, 선택적 OLM Operator 및 사용자 관리와 같은 특정 클러스터 범위 리소스를 관리할 수 있는 권한이 있습니다.

참고

Argo CD에는 cluster-admin 권한이 없습니다.

Argo CD 인스턴스에 대한 권한:

Resources

설명

리소스 그룹

사용자 또는 관리자 구성

operators.coreos.com

OLM에서 관리하는 선택적 Operator

user.openshift.io , rbac.authorization.k8s.io

그룹, 사용자 및 권한

config.openshift.io

클러스터 전체 빌드 구성, 레지스트리 구성 및 스케줄러 정책을 구성하는 데 사용되는 CVO에서 관리하는 컨트롤 플레인 Operator

storage.k8s.io

스토리지

console.openshift.io

콘솔 사용자 지정

4.7.8. 클러스터 구성에 대한 권한 추가

클러스터 구성을 관리하기 위해 Argo CD 인스턴스에 대한 권한을 부여할 수 있습니다. 추가 권한으로 클러스터 역할을 생성한 다음 새 클러스터 역할 바인딩을 생성하여 클러스터 역할을 서비스 계정과 연결합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에 관리자로 로그인합니다.

  2. 웹 콘솔에서 사용자 관리 → 역할 → 역할 만들기를 선택합니다. 다음 ClusterRole YAML 템플릿을 사용하여 추가 권한을 지정하는 규칙을 추가합니다. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secrets-cluster-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["*"]
  3. 생성 을 클릭하여 클러스터 역할을 추가합니다.
  4. 이제 클러스터 역할 바인딩을 생성합니다. 웹 콘솔에서 사용자 관리 → 역할 바인딩 → 바인딩 생성 을 선택합니다.
  5. 프로젝트 드롭다운에서 모든 프로젝트를 선택합니다.
  6. 바인딩 생성을 클릭합니다.
  7. 바인딩 유형을 Cluster-wide 역할 바인딩(ClusterRoleBinding) 으로 선택합니다.
  8. RoleBinding 이름의 고유 값을 입력합니다.
  9. 드롭다운 목록에서 새로 생성된 클러스터 역할 또는 기존 클러스터 역할을 선택합니다.

  10. Subject as ServiceAccount 및 provide the Subject namespace and name 을 선택합니다.

    1. 제목 네임스페이스:openshift-gitops
    2. 제목 이름:openshift-gitops-argocd-application-controller

  11. 생성을 클릭합니다. ClusterRoleBinding 오브젝트의 YAML 파일은 다음과 같습니다. 

    kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cluster-role-binding
subjects:
  - kind: ServiceAccount
    name: openshift-gitops-argocd-application-controller
    namespace: openshift-gitops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin

4.7.9. Red Hat OpenShift GitOps를 사용하여 OLM Operator 설치

클러스터 구성을 사용하는 Red Hat OpenShift GitOps는 특정 클러스터 범위 리소스를 관리하고 클러스터 Operator 또는 네임스페이스 범위 OLM Operator를 설치합니다.

클러스터 관리자로서 Tekton과 같은 OLM Operator를 설치해야 하는 경우를 고려하십시오. OpenShift Container Platform 웹 콘솔을 사용하여 Tekton Operator 또는 OpenShift CLI를 수동으로 설치하여 클러스터에 Tekton 서브스크립션 및 Tekton Operator group을 수동으로 설치합니다.

Red Hat OpenShift GitOps는 Kubernetes 리소스를 Git 리포지토리에 배치합니다. 클러스터 관리자는 Red Hat OpenShift GitOps를 사용하여 수동 절차 없이 다른 OLM Operator의 설치를 관리하고 자동화합니다. 예를 들어 Red Hat OpenShift GitOps를 사용하여 Git 리포지토리에 Tekton 서브스크립션을 배치한 후 Red Hat OpenShift GitOps는 Git 리포지토리에서 이 Tekton 서브스크립션을 자동으로 가져와서 클러스터에 Tekton Operator를 설치합니다.

4.7.9.1. 클러스터 범위 Operator 설치

OLM(Operator Lifecycle Manager)은 클러스터 범위 Operator에 openshift-operators 네임스페이스에서 기본 global-operators Operator group을 사용합니다. 따라서 Gitops 리포지토리에서 OperatorGroup 리소스를 관리할 필요가 없습니다. 그러나 네임스페이스 범위 Operator의 경우 해당 네임스페이스의 OperatorGroup 리소스를 관리해야 합니다.

클러스터 범위 Operator를 설치하려면 Git 리포지토리에 필요한 Operator의 Subscription 리소스를 생성하고 배치합니다.

예: Grafana Operator 서브스크립션

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: grafana
spec:
  channel: v4
  installPlanApproval: Automatic
  name: grafana-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

4.7.9.2. namepace-scoped Operator 설치

네임스페이스 범위 Operator를 설치하려면 Git 리포지토리에 필요한 Operator의 Subscription 및 OperatorGroup 리소스를 생성하고 배치합니다.

예: Ansible Automation Platform Resource Operator

...
apiVersion: v1
kind: Namespace
metadata:
  labels:
    openshift.io/cluster-monitoring: "true"
  name: ansible-automation-platform
...
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ansible-automation-platform-operator
  namespace: ansible-automation-platform
spec:
  targetNamespaces:
    - ansible-automation-platform
...
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ansible-automation-platform
  namespace: ansible-automation-platform
spec:
  channel: patch-me
  installPlanApproval: Automatic
  name: ansible-automation-platform-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
...

중요

Red Hat OpenShift GitOps를 사용하여 여러 Operator를 배포하는 경우 해당 네임스페이스에 단일 Operator 그룹만 생성해야 합니다. 단일 네임스페이스에 두 개 이상의 Operator group이 있는 경우 해당 네임스페이스에서 생성된 모든 CSV는 TooManyOperatorGroups 이유와 함께 실패 상태로 전환됩니다. 해당 네임스페이스의 Operator groups 수가 1에 도달하면 이전 실패 상태 CSV가 모두 pending 상태로 전환됩니다. Operator 설치를 완료하려면 보류 중인 설치 계획을 수동으로 승인해야 합니다.

4.8. Argo CD로 Spring Boot 애플리케이션 배포

Argo CD를 사용하면 Argo CD 대시보드를 사용하거나 oc 툴을 사용하여 애플리케이션을 OpenShift 클러스터에 배포할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift GitOps가 클러스터에 설치되어 있습니다.
  • Argo CD 인스턴스에 로그인합니다.

4.8.1. Argo CD 대시보드를 사용하여 애플리케이션 생성

Argo CD는 애플리케이션을 만들 수 있는 대시보드를 제공합니다.

이 샘플 워크플로에서는 Argo CD를 구성하여 cluster 디렉터리의 콘텐츠를 cluster-configs 애플리케이션과 반복적으로 동기화하는 프로세스를 보여줍니다. 디렉터리는 웹 콘솔의 red hat applications menu icon 메뉴에 있는 Red Hat 개발자 블로그에 링크를 추가하는 OpenShift Container Platform 웹 콘솔 클러스터 구성을 정의하고 클러스터에 spring-petclinic 네임스페이스를 정의합니다.

절차

  1. Argo CD 대시보드에서 새 APP를 클릭하여 새 Argo CD 애플리케이션을 추가합니다.

  2. 이 워크플로의 경우 다음 구성을 사용하여 cluster-configs 애플리케이션을 생성합니다.

    애플리케이션 이름
    cluster-configs
    프로젝트
    default
    동기화 정책
    수동
    리포지터리 URL
    https://github.com/redhat-developer/openshift-gitops-getting-started
    버전
    HEAD
    경로
    cluster
    대상
    https://kubernetes.default.svc
    네임스페이스
    spring-petclinic
    디렉토리 반복
    checked

  3. 이 워크플로의 경우 다음 구성을 사용하여 Spring-petclinic 애플리케이션을 생성합니다.

    애플리케이션 이름
    spring-petclinic
    프로젝트
    default
    동기화 정책
    자동
    리포지터리 URL
    https://github.com/redhat-developer/openshift-gitops-getting-started
    버전
    HEAD
    경로
    app
    대상
    https://kubernetes.default.svc
    네임스페이스
    spring-petclinic
  4. CREATE 를 클릭하여 애플리케이션을 생성합니다.
  5. 웹 콘솔의 관리자 화면을 열고 왼쪽 메뉴에 있는 관리 → 네임스페이스 로 이동합니다.
  6. 네임스페이스를 검색하고 선택한 다음 Label 필드에 argocd.argoproj.io/managed-by=openshift-gitops 를 입력하여 openshift-gitops 네임스페이스의 Argo CD 인스턴스가 네임스페이스를 관리할 수 있도록 합니다.

4.8.2. oc 툴을 사용하여 애플리케이션 생성

oc 툴을 사용하여 터미널에서 Argo CD 애플리케이션을 생성할 수 있습니다.

절차

  1. 샘플 애플리케이션을 다운로드합니다. 

    $ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git

  2. 애플리케이션을 생성합니다. 

    $ oc create -f openshift-gitops-getting-started/argo/app.yaml
    $ oc create -f openshift-gitops-getting-started/argo/app.yaml

  3. oc get 명령을 실행하여 생성된 애플리케이션을 검토합니다. 

    $ oc get application -n openshift-gitops

  4. 애플리케이션이 배포된 네임스페이스에 레이블을 추가하여 openshift-gitops 네임스페이스의 Argo CD 인스턴스에서 관리할 수 있습니다. 

    $ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
    $ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops

4.8.3. Argo CD 자동 복구 동작 확인

Argo CD는 배포된 애플리케이션의 상태를 지속적으로 모니터링하고, Git에서 지정된 매니페스트와 클러스터의 실시간 변경 사항 간의 차이점을 감지한 다음 자동으로 수정합니다. 이 동작을 자동 복구라고 합니다.

Argo CD에서 자동 복구 동작을 테스트하고 관찰할 수 있습니다.

사전 요구 사항

  • 샘플 app-spring-petclinic 애플리케이션이 배포 및 구성되어 있습니다.

절차

  1. Argo CD 대시보드에서 애플리케이션에 Synced 상태가 있는지 확인합니다.
  2. Argo CD 대시보드에서 app-spring-petclinic 타일을 클릭하여 클러스터에 배포된 애플리케이션 리소스를 확인합니다.
  3. OpenShift Container Platform 웹 콘솔에서 개발자 화면으로 이동합니다.

  4. Spring PetClinic 배포를 수정하고 Git 리포지토리의 app/ 디렉터리에 대한 변경 사항을 커밋합니다. Argo CD는 클러스터에 변경 사항을 자동으로 배포합니다.

    1. OpenShift GitOps가 시작하는 리포지토리를 분기 합니다.
    2. deployment.yaml 파일에서 failureThreshold 값을 5 로 변경합니다.

    3. 배포 클러스터에서 다음 명령을 실행하여 failureThreshold 필드의 변경된 값을 확인합니다. 

      $ oc edit deployment spring-petclinic -n spring-petclinic

  5. OpenShift Container Platform 웹 콘솔에서 애플리케이션을 모니터링하면서 클러스터에서 배포를 수정하고 2개의 pod로 확장하여 자동 복구 동작을 테스트합니다.

    1. 다음 명령을 실행하여 배포 상태를 확인합니다. 

      $ oc scale deployment spring-petclinic --replicas 2  -n spring-petclinic
    2. OpenShift Container Platform 웹 콘솔에서 배포는 두 개의 pod로 확장되었다가 즉시 하나의 pod로 축소됩니다. Argo CD는 Git 리포지토리와 차이점을 감지하고 OpenShift Container Platform 클러스터에서 애플리케이션을 자동 복구했습니다.
  6. Argo CD 대시보드에서 app-spring-petclinic 타일 → APP DETAILS →ECDHEENTS를 클릭합니다. FlexVolume ENT S 탭에는 다음 이벤트가 표시됩니다. Argo CD에서 클러스터의 동기화되지 않은 배포 리소스를 감지한 다음 Git 리포지토리를 다시 동기화하여 수정합니다.

4.9. Argo CD Operator

ArgoCD 사용자 정의 리소스는 Argo CD 클러스터를 구성하는 구성 요소를 구성할 수 있는 지정된 Argo CD 클러스터에 대해 원하는 상태를 설명하는 Kubernetes CRD(Custom Resource)입니다.

4.9.1. Argo CD CLI 툴

Argo CD CLI 툴은 명령줄을 통해 Argo CD를 구성하는 데 사용되는 툴입니다. Red Hat OpenShift GitOps는 이 바이너리를 지원하지 않습니다. OpenShift 콘솔을 사용하여 Argo CD를 구성합니다.

4.9.2. Argo CD 사용자 정의 리소스 속성

Argo CD 사용자 정의 리소스는 다음 속성으로 구성됩니다.

이름

설명

Default

속성

ApplicationInstanceLabelKey

Argo CD가 앱 이름을 추적 레이블로 삽입하는 metadata.label 키 이름입니다.

app.kubernetes.io/instance

 

ApplicationSet

ApplicationSet 컨트롤러 구성 옵션.

<Object>

  • &lt ; image> - ApplicationSet 컨트롤러의 컨테이너 이미지입니다. 이렇게 하면 ARGOCD_APPLICATIONSET_IMAGE 환경 변수가 재정의됩니다.
  • &lt ; version> - ApplicationSet 컨테이너 이미지에 사용할 태그입니다.
  • < resources > - 컨테이너 컴퓨팅 리소스입니다.
  • <loglevel> - Argo CD 애플리케이션 컨트롤러 구성 요소에서 사용하는 로그 수준 입니다. 유효한 옵션은 debug,info,error 및 warn 입니다.
  • < LogFormat > - Argo CD 애플리케이션 컨트롤러 구성 요소에서 사용하는 로그 형식입니다. 유효한 옵션은 text 또는 json 입니다.
  • <PrallelismLimit > - 컨트롤러에 대해 설정할 kubectl 병렬 처리 제한 (-kubectl-parallelism-limit 플래그).

ConfigManagementPlugins

구성 관리 플러그인을 추가합니다.

<empty>

 

컨트롤러

Argo CD 애플리케이션 컨트롤러 옵션.

<Object>

  • <processors.Operation > - 작업 프로세서 수
  • <processors.Status > - 상태 프로세서 수
  • < resources > - 컨테이너 컴퓨팅 리소스입니다.
  • <loglevel> - Argo CD 애플리케이션 컨트롤러 구성 요소에서 사용하는 로그 수준 입니다. 유효한 옵션은 debug,info,error 및 warn 입니다.
  • <AppSync > - AppSync는 Argo CD 애플리케이션의 동기화 빈도를 제어하는 데 사용됩니다.
  • <sharding.enabled> - Argo CD 애플리케이션 컨트롤러 구성 요소에서 샤 딩을 활성화합니다. 이 속성은 컨트롤러 구성 요소에서 메모리 부족을 완화하기 위해 다수의 클러스터를 관리하는 데 사용됩니다.
  • <sharding.replicas > - Argo CD 애플리케이션 컨트롤러의 분할을 지원하는 데 사용할 복제본 수입니다.
  • <env > - 애플리케이션 컨트롤러 워크로드에 대해 설정할 환경입니다.

DisableAdmin

기본 제공 admin 사용자를 비활성화합니다.

false

 

GATrackingID

Google analytics 추적 ID를 사용하십시오.

<empty>

 

GAAnonymizeusers

Google 분석으로 전송된 해시된 사용자 이름을 활성화합니다.

false

 

HA

높은 가용성 옵션.

<Object>

  • <enabled > - Argo CD에 대해 전 세계적으로 고가용성 지원을 토글합니다.
  • <RedisProxyImage > - Redis HAProxy 컨테이너 이미지입니다. 이는 ARGOCD_REDIS_HA_PROXY_IMAGE 환경 변수를 덮어씁니다.
  • <RedisProxyVersion > - Redis HAProxy 컨테이너 이미지에 사용할 태그입니다.

HelpChatURL

채팅 도움말을 받기 위한 URL(일반적으로 지원용 Slack 채널)입니다.

https://mycorp.slack.com/argo-cd

 

HelpChatECDHE

채팅 도움말을 받기 위한 텍스트 상자에 표시됩니다.

지금 채팅!

 

Image

모든 Argo CD 구성 요소의 컨테이너 이미지입니다. 이렇게 하면 ARGOCD_IMAGE 환경 변수가 재정의됩니다.

argoproj/argocd

 

Ingress

Ingress 구성 옵션입니다.

<Object>

 

InitialRepositories

클러스터를 생성할 때 사용할 Argo CD를 구성하는 초기 Git 리포지토리입니다.

<empty>

 

알림

알림 컨트롤러 구성 옵션.

<Object>

  • < enabled > - notifications-controller를 시작하기 위한 토글입니다.
  • <image> - 모든 Argo CD 구성 요소의 컨테이너 이미지입니다. 이렇게 하면 ARGOCD_IMAGE 환경 변수가 재정의됩니다.
  • < version > - 알림 컨테이너 이미지와 함께 사용할 태그입니다.
  • < resources > - 컨테이너 컴퓨팅 리소스입니다.
  • <loglevel> - Argo CD 애플리케이션 컨트롤러 구성 요소에서 사용하는 로그 수준 입니다. 유효한 옵션은 debug,info,error 및 warn 입니다.

RepositoryCredentials

클러스터를 생성할 때 사용하도록 Argo CD를 구성하는 Git 리포지토리 인증 정보 템플릿입니다.

<empty>

 

InitialSSHKnownHosts

Argo CD의 초기 SSH 알려진 호스트는 클러스터 생성 시 사용할 수 있습니다.

<default_Argo_CD_Known_Hosts>

 

KustomizeBuildOptions

kustomize 빌드와 함께 사용할 빌드 옵션 및 매개변수입니다.

<empty>

 

OIDCConfig

OIDC 구성은 Dex 대안으로서입니다.

<empty>

 

nodePlacement

nodeSelector 및 허용 오차 를 추가합니다.

<empty>

 

Prometheus

Prometheus 구성 옵션.

<Object>

  • & lt;enabled& gt; - Argo CD에 대한 전역적으로 Prometheus 지원을 토글합니다.
  • < host > - Ingress 또는 Route 리소스에 사용할 호스트 이름입니다.
  • <Ingress > - Prometheus의 Ingress를 토글합니다.
  • <route > - 경로 구성 옵션입니다.
  • &lt ;size > - Prometheus StatefulSet 의 복제본 수입니다.

RBAC

RBAC 구성 옵션

<Object>

  • < DefaultPolicy > - argocd-rbac-cm 구성 맵의 policy.default 속성입니다. API 요청을 승인할 때 Argo CD가 다시 대체되는 기본 역할의 이름입니다.
  • <policy> - argocd-rbac-cm 구성 맵의 policy.csv 속성입니다. 사용자 정의 RBAC 정책 및 역할 정의가 포함된 CSV 데이터
  • < scopes > - argocd-rbac-cm 구성 맵의 scopes 속성입니다. RBAC 적용 중 검사할 OIDC 범위를 제어합니다(하위 범위 포함).

Redis

Redis 설정 옵션.

<Object>

  • <AutoTLS > - 공급자를 사용하여 Redis 서버의 TLS 인증서( openshift 중 하나)를 생성합니다. 현재 OpenShift Container Platform에서만 사용할 수 있습니다.
  • <DisableTLSVerification > - 엄격한 TLS 검증을 사용하여 Redis 서버에 액세스해야 하는지 여부를 정의합니다.
  • &lt ;image > - Redis의 컨테이너 이미지입니다. 이렇게 하면 ARGOCD_REDIS_IMAGE 환경 변수가 재정의됩니다.
  • < resources > - 컨테이너 컴퓨팅 리소스입니다.
  • &lt ; version> - Redis 컨테이너 이미지에 사용할 태그입니다.

ResourceCustomizations

리소스 동작을 사용자 정의합니다.

<empty>

 

ResourceExclusions

전체 리소스 그룹의 클래스를 완전히 무시합니다.

<empty>

 

ResourceInclusions

적용되는 리소스 그룹/종료를 구성하는 구성입니다.

<empty>

 

서버

Argo CD 서버 구성 옵션.

<Object>

  • <autoscale& gt; - 서버 자동 스케일링 구성 옵션.
  • <ExtraCommandArgs > - Operator가 설정한 기존 인수에 추가된 인수 목록입니다.
  • <GRPC > - GRPC 구성 옵션
  • < host > - Ingress 또는 Route 리소스에 사용되는 호스트 이름입니다.
  • <Ingress > - Argo CD 서버 구성 요소에 대한 Ingress 구성입니다.
  • <insecure > - Argo CD 서버에 대한 비보안 플래그를 토글합니다.
  • < resources > - 컨테이너 컴퓨팅 리소스입니다.
  • &lt ;replicas > - Argo CD 서버의 복제본 수입니다. 0 보다 크거나 같아야 합니다. Autoscale 이 활성화되면 Replicas 가 무시됩니다.
  • <route > - 경로 구성 옵션입니다.
  • <service .Type > - 서비스 리소스에 사용된 ServiceType 입니다.
  • <loglevel> - Argo CD 서버 구성 요소에서 사용할 로그 수준 입니다. 유효한 옵션은 debug,info,error 및 warn 입니다.
  • < LogFormat > - Argo CD 애플리케이션 컨트롤러 구성 요소에서 사용하는 로그 형식입니다. 유효한 옵션은 text 또는 json 입니다.
  • < env> - 서버 워크로드에 설정할 환경입니다.

SSO

SSO(Single Sign-On) 옵션.

<Object>

  • &lt ; image> - Keycloak의 컨테이너 이미지입니다. 이렇게 하면 ARGOCD_KEYCLOAK_IMAGE 환경 변수가 재정의됩니다.
  • <Keycloak > - Keycloak SSO 공급자에 대한 구성 옵션
  • <DEX& gt; - Dex SSO 공급자의 설정 옵션
  • <provider> - Single Sign-on을 구성하는 데 사용되는 공급자의 이름입니다. 현재 지원되는 옵션은 Dex 및 Keycloak입니다.
  • < resources > - 컨테이너 컴퓨팅 리소스입니다.
  • <VerifyTLS > - Keycloak 서비스와 통신할 때 엄격한 TLS 검사를 실행할지 여부입니다.
  • &lt ; version> - Keycloak 컨테이너 이미지에 사용할 태그입니다.

StatusBadgeEnabled

애플리케이션 상태 배지를 활성화합니다.

true

 

TLS

TLS 구성 옵션.

<Object>

  • <CA.ConfigMapName > - CA 인증서가 포함된 ConfigMap 의 이름입니다.
  • < CA.SecretName > - CA 인증서 및 키가 포함된 시크릿의 이름입니다.
  • <InitialCerts > - HTTPS를 통해 Git 리포지토리를 연결하기 위한 argocd-tls-certs-cm 구성 맵의 초기 인증서 세트입니다.

UserAnonyousEnabled

익명 사용자 액세스를 활성화합니다.

true

 

버전

모든 Argo CD 구성 요소의 컨테이너 이미지와 함께 사용할 태그입니다.

최신 Argo CD 버전

 

Banner

UI 배너 메시지를 추가합니다.

<Object>

  • <banner .Content> - 배너 메시지 콘텐츠(Banner 가 표시되는 경우 필수)입니다.
  • <banner.URL.SecretName& gt; - 배너 메시지 링크 URL(선택 사항)

4.9.3. 리포지토리 서버 속성

Repo 서버 구성 요소를 구성하는 데 사용할 수 있는 속성은 다음과 같습니다.

이름

Default

설명

Resources

<empty>

컨테이너 컴퓨팅 리소스입니다.

MountSAToken

false

ServiceAccount 토큰이 repo-server Pod에 마운트되어야 하는지의 여부입니다.

ServiceAccount

""

repo-server Pod에 사용할 ServiceAccount 의 이름입니다.

VerifyTLS

false

repo 서버와 통신할 때 모든 구성 요소에서 엄격한 TLS 검사를 적용할지 여부입니다.

AutoTLS

""

TLS를 설정하는 데 사용하는 공급자는 repo-server의 gRPC TLS 인증서( openshift 중 하나)를 설정합니다. 현재 OpenShift에서만 사용할 수 있습니다.

Image

argoproj/argocd

Argo CD Repo 서버의 컨테이너 이미지입니다. 이렇게 하면 ARGOCD_REPOSERVER_IMAGE 환경 변수가 재정의됩니다.

버전

same as .spec.Version

Argo CD Repo 서버와 함께 사용할 태그입니다.

LogLevel

info

Argo CD Repo 서버에서 사용하는 로그 수준입니다. 유효한 옵션은 debug, info, error, warn입니다.

LogFormat

text

Argo CD Repo 서버에서 사용할 로그 형식입니다. 유효한 옵션은 text 또는 json입니다.

ExecTimeout

180

렌더링 툴(예: Helm, Kustomize)의 실행 제한 시간(초)입니다.

env

<empty>

리포지토리 서버 워크로드에 설정할 환경입니다.

replicas

<empty>

Argo CD Repo 서버의 복제본 수입니다. 0 보다 크거나 같아야 합니다.

4.9.4. Argo CD 인스턴스를 사용하여 알림 활성화

Argo CD 알림 컨트롤러를 활성화하거나 비활성화하려면 Argo CD 사용자 정의 리소스에서 매개변수를 설정합니다. 기본적으로 알림은 비활성화되어 있습니다. 알림을 활성화하려면 .yaml 파일에서 enabled 매개변수를 true 로 설정합니다.

프로세스

  1. enabled 매개변수를 true 로 설정합니다. 
apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  notifications:
    enabled: true

4.10. Redis를 사용하여 보안 통신 구성

Red Hat OpenShift GitOps와 함께 TLS(Transport Layer Security) 암호화를 사용하면 Argo CD 구성 요소와 Redis 캐시 간의 통신을 보호하고 전송 시 중요한 데이터를 보호할 수 있습니다.

다음 구성 중 하나를 사용하여 Redis와의 통신을 보호할 수 있습니다.

  • autotls 설정을 활성화하여 TLS 암호화에 적절한 인증서를 발급합니다.
  • 키 및 인증서 쌍으로 argocd-operator-redis-tls 시크릿을 생성하여 TLS 암호화를 수동으로 구성합니다.

두 구성 모두 HA(고가용성)를 활성화하거나 사용하지 않고 사용할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • Red Hat OpenShift GitOps Operator가 클러스터에 설치되어 있습니다.

4.10.1. autotls가 활성화된 Redis의 TLS 구성

새 또는 기존 Argo CD 인스턴스에서 autotls 설정을 활성화하여 Redis에 대한 TLS 암호화를 구성할 수 있습니다. 이 구성은 argocd-operator-redis-tls 시크릿을 자동으로 프로비저닝하고 추가 단계가 필요하지 않습니다. 현재 OpenShift Container Platform은 지원되는 유일한 시크릿 공급자입니다.

참고

기본적으로 autotls 설정은 비활성화되어 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.

  2. autotls 가 활성화된 Argo CD 인스턴스를 생성합니다.

    1. 웹 콘솔의 관리자 화면에서 왼쪽 탐색 패널을 사용하여 Administration → CustomResourceDefinitions 로 이동합니다.
    2. argocds.argoproj.io 를 검색하고 ArgoCD CRD(사용자 정의 리소스 정의)를 클릭합니다.
    3. CustomResourceDefinition 세부 정보 페이지에서 Instances 탭을 클릭한 다음 Create ArgoCD 를 클릭합니다.

    4. 다음 예와 유사한 YAML을 편집하거나 교체합니다.

      autotls가 활성화된 Argo CD CR의 예

      apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: argocd 1
  namespace: openshift-gitops 2
spec:
  redis:
    autotls: openshift 3
  ha:
    enabled: true 4

      1
      Argo CD 인스턴스의 이름입니다.
      2
      Argo CD 인스턴스를 실행할 네임스페이스입니다.
      3
      autotls 설정을 활성화하고 Redis에 대한 TLS 인증서를 생성하는 플래그입니다.
      4
      HA 기능을 활성화하는 플래그 값입니다. HA를 활성화하지 않으려면 이 행을 포함하지 않거나 플래그 값을 false 로 설정합니다.
      작은 정보

      또는 다음 명령을 실행하여 기존 Argo CD 인스턴스에서 autotls 설정을 활성화할 수 있습니다. 

      $ oc patch argocds.argoproj.io <instance-name> --type=merge -p '{"spec":{"redis":{"autotls":"openshift"}}}'
    5. 생성을 클릭합니다.

    6. Argo CD Pod가 준비되어 실행 중인지 확인합니다. 

      $ oc get pods -n <namespace> 1
      1
      Argo CD 인스턴스가 실행 중인 네임스페이스를 지정합니다(예: openshift-gitops ).

      HA가 비활성화된 출력 예

      NAME                                  READY   STATUS    RESTARTS   AGE
argocd-application-controller-0       1/1     Running   0          26s
argocd-redis-84b77d4f58-vp6zm         1/1     Running   0          37s
argocd-repo-server-5b959b57f4-znxjq   1/1     Running   0          37s
argocd-server-6b8787d686-wv9zh        1/1     Running   0          37s

      참고

      HA 지원 TLS 구성에는 작업자 노드가 3개 이상인 클러스터가 필요합니다. HA 구성으로 Argo CD 인스턴스를 활성화한 경우 출력이 표시되는 데 몇 분이 걸릴 수 있습니다.

      HA가 활성화된 출력 예

      NAME                                       READY   STATUS    RESTARTS   AGE
argocd-application-controller-0            1/1     Running   0          10m
argocd-redis-ha-haproxy-669757fdb7-5xg8h   1/1     Running   0          10m
argocd-redis-ha-server-0                   2/2     Running   0          9m9s
argocd-redis-ha-server-1                   2/2     Running   0          98s
argocd-redis-ha-server-2                   2/2     Running   0          53s
argocd-repo-server-576499d46d-8hgbh        1/1     Running   0          10m
argocd-server-9486f88b7-dk2ks              1/1     Running   0          10m

  3. argocd-operator-redis-tls 보안이 생성되었는지 확인합니다. 

    $ oc get secrets argocd-operator-redis-tls -n <namespace> 1
    1
    Argo CD 인스턴스가 실행 중인 네임스페이스를 지정합니다(예: openshift-gitops ).

    출력 예

    NAME                        TYPE                DATA   AGE
argocd-operator-redis-tls   kubernetes.io/tls   2      30s

    시크릿은 kubernetes.io/tls 유형이어야 하며 크기는 2 여야 합니다.

4.10.2. autotls가 비활성화된 상태로 Redis의 TLS 구성

키 및 인증서 쌍으로 argocd-operator-redis-tls 시크릿을 생성하여 Redis에 대한 TLS 암호화를 수동으로 구성할 수 있습니다. 또한 적절한 Argo CD 인스턴스에 속해 있음을 나타내려면 시크릿에 주석을 달아야 합니다. 인증서 및 보안을 생성하는 단계는 HA(고가용성)가 활성화된 인스턴스에 따라 다릅니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.

  2. Argo CD 인스턴스를 생성합니다.

    1. 웹 콘솔의 관리자 화면에서 왼쪽 탐색 패널을 사용하여 Administration → CustomResourceDefinitions 로 이동합니다.
    2. argocds.argoproj.io 를 검색하고 ArgoCD CRD(사용자 정의 리소스 정의)를 클릭합니다.
    3. CustomResourceDefinition 세부 정보 페이지에서 Instances 탭을 클릭한 다음 Create ArgoCD 를 클릭합니다.

    4. 다음 예와 유사한 YAML을 편집하거나 교체합니다.

      autotls가 비활성화된 ArgoCD CR의 예

      apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: argocd 1
  namespace: openshift-gitops 2
spec:
  ha:
    enabled: true 3

      1
      Argo CD 인스턴스의 이름입니다.
      2
      Argo CD 인스턴스를 실행할 네임스페이스입니다.
      3
      HA 기능을 활성화하는 플래그 값입니다. HA를 활성화하지 않으려면 이 행을 포함하지 않거나 플래그 값을 false 로 설정합니다.
    5. 생성을 클릭합니다.

    6. Argo CD Pod가 준비되어 실행 중인지 확인합니다. 

      $ oc get pods -n <namespace> 1
      1
      Argo CD 인스턴스가 실행 중인 네임스페이스를 지정합니다(예: openshift-gitops ).

      HA가 비활성화된 출력 예

      NAME                                  READY   STATUS    RESTARTS   AGE
argocd-application-controller-0       1/1     Running   0          26s
argocd-redis-84b77d4f58-vp6zm         1/1     Running   0          37s
argocd-repo-server-5b959b57f4-znxjq   1/1     Running   0          37s
argocd-server-6b8787d686-wv9zh        1/1     Running   0          37s

      참고

      HA 지원 TLS 구성에는 작업자 노드가 3개 이상인 클러스터가 필요합니다. HA 구성으로 Argo CD 인스턴스를 활성화한 경우 출력이 표시되는 데 몇 분이 걸릴 수 있습니다.

      HA가 활성화된 출력 예

      NAME                                       READY   STATUS    RESTARTS   AGE
argocd-application-controller-0            1/1     Running   0          10m
argocd-redis-ha-haproxy-669757fdb7-5xg8h   1/1     Running   0          10m
argocd-redis-ha-server-0                   2/2     Running   0          9m9s
argocd-redis-ha-server-1                   2/2     Running   0          98s
argocd-redis-ha-server-2                   2/2     Running   0          53s
argocd-repo-server-576499d46d-8hgbh        1/1     Running   0          10m
argocd-server-9486f88b7-dk2ks              1/1     Running   0          10m

  3. HA 구성에 따라 다음 옵션 중 하나를 사용하여 Redis 서버에 대한 자체 서명 인증서를 생성합니다.

    • HA가 비활성화된 Argo CD 인스턴스의 경우 다음 명령을 실행합니다. 

      $ openssl req -new -x509 -sha256 \
  -subj "/C=XX/ST=XX/O=Testing/CN=redis" \
  -reqexts SAN -extensions SAN \
  -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1
  -keyout /tmp/redis.key \
  -out /tmp/redis.crt \
  -newkey rsa:4096 \
  -nodes \
  -sha256 \
  -days 10
      1
      Argo CD 인스턴스가 실행 중인 네임스페이스를 지정합니다(예: openshift-gitops ).

      출력 예

      Generating a RSA private key
...............++++
............................++++
writing new private key to '/tmp/redis.key'

    • HA가 활성화된 Argo CD 인스턴스의 경우 다음 명령을 실행합니다. 

      $ openssl req -new -x509 -sha256 \
  -subj "/C=XX/ST=XX/O=Testing/CN=redis" \
  -reqexts SAN -extensions SAN \
  -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis-ha-haproxy.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1
  -keyout /tmp/redis-ha.key \
  -out /tmp/redis-ha.crt \
  -newkey rsa:4096 \
  -nodes \
  -sha256 \
  -days 10
      1
      Argo CD 인스턴스가 실행 중인 네임스페이스를 지정합니다(예: openshift-gitops ).

      출력 예

      Generating a RSA private key
...............++++
............................++++
writing new private key to '/tmp/redis-ha.key'

  4. 다음 명령을 실행하여 생성된 인증서 및 키를 /tmp 디렉토리에서 사용할 수 있는지 확인합니다. 

    $ cd /tmp
    $ ls

    HA가 비활성화된 출력 예

    ...
redis.crt
redis.key
...

    HA가 활성화된 출력 예

    ...
redis-ha.crt
redis-ha.key
...

  5. HA 구성에 따라 다음 옵션 중 하나를 사용하여 argocd-operator-redis-tls 시크릿을 생성합니다.

    • HA가 비활성화된 Argo CD 인스턴스의 경우 다음 명령을 실행합니다. 

      $ oc create secret tls argocd-operator-redis-tls --key=/tmp/redis.key --cert=/tmp/redis.crt

    • HA가 활성화된 Argo CD 인스턴스의 경우 다음 명령을 실행합니다. 

      $ oc create secret tls argocd-operator-redis-tls --key=/tmp/redis-ha.key --cert=/tmp/redis-ha.crt

      출력 예

      secret/argocd-operator-redis-tls created

  6. Argo CD CR에 속함을 나타내기 위해 보안에 주석을 답니다. 

    $ oc annotate secret argocd-operator-redis-tls argocds.argoproj.io/name=<instance-name> 1
    1
    Argo CD 인스턴스의 이름을 지정합니다(예: argocd ).

    출력 예

    secret/argocd-operator-redis-tls annotated

  7. Argo CD Pod가 준비되어 실행 중인지 확인합니다. 

    $ oc get pods -n <namespace> 1
    1
    Argo CD 인스턴스가 실행 중인 네임스페이스를 지정합니다(예: openshift-gitops ).

    HA가 비활성화된 출력 예

    NAME                                  READY   STATUS    RESTARTS   AGE
argocd-application-controller-0       1/1     Running   0          26s
argocd-redis-84b77d4f58-vp6zm         1/1     Running   0          37s
argocd-repo-server-5b959b57f4-znxjq   1/1     Running   0          37s
argocd-server-6b8787d686-wv9zh        1/1     Running   0          37s

    참고

    HA 구성으로 Argo CD 인스턴스를 활성화한 경우 출력이 표시되는 데 몇 분이 걸릴 수 있습니다.

    HA가 활성화된 출력 예

    NAME                                       READY   STATUS    RESTARTS   AGE
argocd-application-controller-0            1/1     Running   0          10m
argocd-redis-ha-haproxy-669757fdb7-5xg8h   1/1     Running   0          10m
argocd-redis-ha-server-0                   2/2     Running   0          9m9s
argocd-redis-ha-server-1                   2/2     Running   0          98s
argocd-redis-ha-server-2                   2/2     Running   0          53s
argocd-repo-server-576499d46d-8hgbh        1/1     Running   0          10m
argocd-server-9486f88b7-dk2ks              1/1     Running   0          10m

4.11. 애플리케이션 리소스 및 배포의 상태 정보 모니터링

OpenShift Container Platform 웹 콘솔의 개발자 화면에 있는 Red Hat OpenShift GitOps 환경 페이지에는 각 배포의 리버전 링크와 함께 애플리케이션 환경의 성공적인 배포 목록이 표시됩니다.

OpenShift Container Platform 웹 콘솔의 개발자 화면에 있는 애플리케이션 환경 페이지에는 경로, 동기화 상태, 배포 구성 및 배포 기록과 같은 애플리케이션 리소스의 상태가 표시됩니다.

OpenShift Container Platform 웹 콘솔의 개발자 화면에 있는 환경 페이지는 Red Hat OpenShift GitOps Application Manager CLI(명령줄 인터페이스), kam 에서 분리됩니다. kam 을 사용하여 환경에 OpenShift Container Platform 웹 콘솔의 개발자 화면에 표시할 수 있는 애플리케이션 환경 매니페스트를 생성할 필요가 없습니다. 자체 매니페스트를 사용할 수 있지만 환경을 계속 네임스페이스로 표시해야 합니다. 또한 특정 레이블 및 주석이 필요합니다.

4.11.1. 상태 정보 확인

Red Hat OpenShift GitOps Operator는 GitOps 백엔드 서비스를 openshift-gitops 네임스페이스에 설치합니다.

사전 요구 사항

  • Red Hat OpenShift GitOps Operator는 OperatorHub 에서 설치됩니다.
  • 애플리케이션이 Argo CD에 의해 동기화되었는지 확인합니다.

프로세스

  1. 개발자 화면에서 환경을 클릭합니다. 환경 페이지에 환경 상태와 함께 애플리케이션 목록이 표시됩니다.
  2. 환경 상태 열 아래의 아이콘 위로 커서를 이동하여 모든 환경의 동기화 상태를 확인합니다.
  3. 목록에서 애플리케이션 이름을 클릭하여 특정 애플리케이션의 세부 정보를 확인합니다.

  4. 애플리케이션 환경 페이지의 개요 탭의 리소스 섹션에 아이콘이 표시되면 아이콘 위에 커서를 이동하여 상태 세부 정보를 가져옵니다.

    • 손상된 키는 리소스 문제가 애플리케이션의 성능이 저하되었음을 나타냅니다.
    • 노란색 산출 기호는 리소스 문제가 애플리케이션 상태에 대한 데이터가 지연되었음을 나타냅니다.
  5. 애플리케이션의 배포 내역을 보려면 배포 내역 탭을 클릭합니다. 페이지에는 Last deployment,Description (commit message), Environment,Author, Revision 과 같은 세부 정보가 포함되어 있습니다.

4.12. Dex를 사용하여 Argo CD에 대한 SSO 구성

Red Hat OpenShift GitOps Operator가 설치되면 Argo CD에서 admin 권한이 있는 사용자를 자동으로 생성합니다. 클러스터 관리자는 여러 사용자를 관리하기 위해 Argo CD를 사용하여 SSO(Single Sign-On)를 구성할 수 있습니다.

중요

ArgoCD CR의 spec.dex 매개변수는 더 이상 사용되지 않습니다. 향후 Red Hat OpenShift GitOps v1.10.0 릴리스에서는 ArgoCD CR에서 spec.dex 매개변수를 사용하여 Dex를 구성할 예정입니다. 대신 .spec.sso 매개변수를 사용하는 것이 좋습니다.

4.12.1. Dex OpenShift OAuth Connector 활성화

DEX는 플랫폼에서 제공하는 OAuth 서버를 확인하여 OpenShift 내에 정의된 사용자 및 그룹을 사용합니다. 다음 예제에서는 예제 구성과 함께 Dex의 속성을 보여줍니다. 

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: openshift-oauth
spec:
  dex:
    openShiftOAuth: true 1
    groups:2
     - default
  rbac:3
    defaultPolicy: 'role:readonly'
    policy: |
      g, cluster-admins, role:admin
    scopes: '[groups]'
1
openShiftOAuth 속성은 값이 true 로 설정된 경우 Operator에서 기본 제공 OpenShift OAuth 서버를 자동으로 구성하도록 트리거합니다.
2
groups 속성을 사용하면 지정된 그룹의 사용자가 로그인할 수 있습니다.
3
RBAC 정책 속성은 Argo CD 클러스터의 admin 역할을 OpenShift cluster-admins 그룹의 사용자에게 할당합니다.

4.12.1.1. 사용자를 특정 역할에 매핑

Argo CD는 직접 ClusterRoleBinding 역할이 있는 경우 사용자를 특정 역할에 매핑할 수 없습니다. OpenShift를 통해 SSO에서 role:admin 으로 역할을 수동으로 변경할 수 있습니다.

프로세스

  1. cluster-admins 라는 그룹을 만듭니다. 

    $ oc adm groups new cluster-admins

  2. 사용자를 그룹에 추가합니다. 

    $ oc adm groups add-users cluster-admins USER

  3. cluster-admin ClusterRole 을 그룹에 적용합니다. 

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admins

4.12.2. Dex 비활성화

DEX는 Operator가 생성한 모든 Argo CD 인스턴스에 기본적으로 설치됩니다. .spec.dex 매개변수를 설정하여 Dex를 SSO 인증 공급자로 사용하도록 Red Hat OpenShift GitOps를 구성할 수 있습니다.

중요

Red Hat OpenShift GitOps v1.6.0에서 DISABLE_DEX 는 더 이상 사용되지 않으며 Red Hat OpenShift GitOps v1.10.0에서 제거될 예정입니다. 대신 .spec.sso.dex 매개변수를 사용하는 것이 좋습니다. ".spec.sso를 사용하여 Dex 활성화 또는 비활성화"를 참조하십시오.

프로세스

  • Operator의 YAML 리소스에서 환경 변수 DISABLE_DEX 를 true 로 설정합니다. 

    ...
spec:
  config:
    env:
    - name: DISABLE_DEX
      value: "true"
...

4.12.3. .spec.sso를 사용하여 Dex 활성화 또는 비활성화

.spec.sso 매개변수를 설정하여 Dex를 SSO 인증 공급자로 사용하도록 Red Hat OpenShift GitOps를 구성할 수 있습니다.

프로세스

  1. Dex를 활성화하려면 Operator의 YAML 리소스에 .spec.sso.provider: dex 매개변수를 설정합니다. 

    ...
spec:
  sso:
    provider: dex
    dex:
      openShiftOAuth: true
...
  2. dex를 비활성화하려면 Argo CD 사용자 정의 리소스에서 spec.sso 요소를 제거하거나 다른 SSO 공급자를 지정합니다.

4.13. Keycloak을 사용하여 Argo CD에 대한 SSO 구성

Red Hat OpenShift GitOps Operator가 설치되면 Argo CD에서 admin 권한이 있는 사용자를 자동으로 생성합니다. 클러스터 관리자는 여러 사용자를 관리하기 위해 Argo CD를 사용하여 SSO(Single Sign-On)를 구성할 수 있습니다.

사전 요구 사항

  • Red Hat SSO가 클러스터에 설치되어 있습니다.
  • Red Hat OpenShift GitOps Operator가 클러스터에 설치되어 있습니다.
  • Argo CD가 클러스터에 설치되어 있습니다.

4.13.1. Keycloak에서 새 클라이언트 구성

DEX는 Operator가 생성한 모든 Argo CD 인스턴스에 기본적으로 설치됩니다. 그러나 Dex 구성을 삭제하고 대신 Keycloak을 추가하여 OpenShift 자격 증명을 사용하여 Argo CD에 로그인할 수 있습니다. Keycloak은 Argo CD와 OpenShift 간의 ID 브로커 역할을 합니다.

프로세스

Keycloak을 구성하려면 다음 단계를 따르십시오.

  1. Argo CD CR(사용자 정의 리소스)에서 .spec.sso.dex 매개변수를 제거하여 Dex 구성을 삭제하고 CR을 저장합니다. 

    dex:
    openShiftOAuth: true
    resources:
      limits:
        cpu:
        memory:
      requests:
        cpu:
        memory:
  2. Argo CD CR에서 provider 매개변수의 값을 keycloak 으로 설정합니다.

  3. 다음 단계 중 하나를 수행하여 Keycloak을 구성합니다.

    • 보안 연결의 경우 다음 예와 같이 rootCA 매개변수 값을 설정합니다. 

      apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  sso:
    provider: keycloak
    keycloak:
      rootCA: "<PEM-encoded-root-certificate>" 1
  server:
    route:
      enabled: true
      1
      Keycloak의 TLS 인증서를 확인하는 데 사용되는 사용자 정의 인증서입니다.

      Operator는 .spec.keycloak.rootCA 매개변수의 변경 사항을 조정하고 argocd-cm 구성 맵에서 PEM 인코딩 루트 인증서로 oidc.config 매개변수를 업데이트합니다.

    • 비보안 연결의 경우 rootCA 매개변수 값을 비워 두고 아래와 같이 oidc.tls.insecure.skip.verify 매개변수를 사용합니다. 

      apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: basic
spec:
  extraConfig:
    oidc.tls.insecure.skip.verify: "true"
  sso:
    provider: keycloak
    keycloak:
      rootCA: ""
참고

Keycloak 인스턴스를 설치하고 실행하는 데 3분 정도 걸립니다.

4.13.2. Keycloak에 로그인

Keycloak 콘솔에 로그인하여 ID 또는 역할을 관리하고 다양한 역할에 할당된 권한을 정의합니다.

사전 요구 사항

  • Dex의 기본 구성이 제거되었습니다.
  • Keycloak SSO 공급자를 사용하도록 Argo CD CR을 구성해야 합니다.

프로세스

  1. 로그인할 Keycloak 경로 URL을 가져옵니다. 

    $ oc -n argocd get route keycloak

NAME        HOST/PORT                                                        PATH   SERVICES   PORT    TERMINATION   WILDCARD
keycloak    keycloak-default.apps.ci-ln-******.origin-ci-int-aws.dev.**.com         keycloak   <all>    reencrypt     None

  2. 사용자 이름과 암호를 환경 변수로 저장하는 Keycloak Pod 이름을 가져옵니다. 

    $ oc -n argocd get pods

NAME                      READY   STATUS           RESTARTS   AGE
keycloak-1-2sjcl           1/1    Running            0        45m

    1. Keycloak 사용자 이름을 가져옵니다. 

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME

SSO_ADMIN_USERNAME=<username>

    2. Keycloak 암호를 가져옵니다. 

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD

SSO_ADMIN_PASSWORD=<password>

  3. 로그인 페이지에서 LOG IN VIA KEYCLOAK 를 클릭합니다.

    참고

    Keycloak 인스턴스가 준비된 후 LOGIN VIA KEYCLOAK 옵션이 표시됩니다.

  4. OpenShift로 로그인을 클릭합니다.

    참고

    kubeadmin 을 사용한 로그인은 지원되지 않습니다.

  5. 로그인할 OpenShift 자격 증명을 입력합니다.

  6. 선택 사항: 기본적으로 Argo CD에 로그인한 모든 사용자에게 읽기 전용 액세스 권한이 있습니다. argocd-rbac-cm 구성 맵을 업데이트하여 사용자 수준 액세스를 관리할 수 있습니다. 

    policy.csv:
<name>, <email>, role:admin

4.13.3. Keycloak 설치 제거

Argo CD 사용자 정의 리소스(CR) 파일에서 SSO 필드를 제거하여 Keycloak 리소스 및 관련 구성을 삭제할 수 있습니다. SSO 필드를 제거한 후 파일의 값은 다음과 유사합니다. 

  apiVersion: argoproj.io/v1alpha1
  kind: ArgoCD
  metadata:
    name: example-argocd
    labels:
      example: basic
  spec:
    server:
      route:
       enabled: true
참고

이 방법을 사용하여 생성된 Keycloak 애플리케이션은 현재 영구적이지 않습니다. Argo CD Keycloak 영역에서 생성된 추가 구성은 서버가 다시 시작되면 삭제됩니다.

4.14. Argo CD RBAC 구성

기본적으로 RHSSO를 사용하여 Argo CD에 로그인하면 읽기 전용 사용자입니다. 사용자 수준 액세스를 변경하고 관리할 수 있습니다.

4.14.1. 사용자 수준 액세스 구성

사용자 수준 액세스를 관리하고 수정하려면 Argo CD 사용자 정의 리소스에서 RBAC 섹션을 구성합니다.

프로세스

  • argocd 사용자 정의 리소스를 편집합니다. 

    $ oc edit argocd [argocd-instance-name] -n [namespace]

    출력 결과

    metadata
...
...
  rbac:
    policy: 'g, rbacsystem:cluster-admins, role:admin'
    scopes: '[groups]'

  • rbac 섹션에 정책 구성을 추가하고 이름,이메일, 사용자 역할을 추가합니다. 

    metadata
...
...
rbac:
    policy: <name>, <email>, role:<admin>
    scopes: '[groups]'
참고

현재 RHSSO는 Red Hat OpenShift GitOps 사용자의 그룹 정보를 읽을 수 없습니다. 따라서 사용자 수준에서 RBAC를 구성합니다.

4.14.2. RHSSO 리소스 요청/제한 수정

기본적으로 RHSSO 컨테이너는 리소스 요청 및 제한 사항을 사용하여 생성됩니다. 리소스 요청을 변경하고 관리할 수 있습니다.

리소스요구 사항제한

CPU

500

1000m

메모리

512 Mi

1024 Mi

프로세스

Argo CD CR에 패치를 적용하는 기본 리소스 요구 사항을 수정합니다. 

$ oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]'
참고

Red Hat OpenShift GitOps에서 생성한 RHSSO는 Operator가 변경한 변경 사항만 유지합니다. RHSSO가 다시 시작되면 RHSSO의 관리자가 생성한 추가 구성이 삭제됩니다.

4.15. 리소스 할당량 또는 요청 구성

Argo CD 사용자 정의 리소스를 사용하면 Argo CD 워크로드에 대한 리소스 요청 및 제한을 생성, 업데이트 및 삭제할 수 있습니다.

4.15.1. 리소스 요청 및 제한을 사용하여 워크로드 구성

리소스 요청 및 제한을 사용하여 Argo CD 사용자 지정 리소스 워크로드를 생성할 수 있습니다. 이는 리소스 할당량으로 구성된 네임스페이스에 Argo CD 인스턴스를 배포하려는 경우 필요합니다.

다음 Argo CD 인스턴스는 애플리케이션 컨트롤러 , ApplicationSet 컨트롤러 ,Dex,Redis,Repo Server, 및 Server 와 같은 Argo CD 워크로드를 리소스 요청 및 제한과 함께 배포합니다. 동일한 방식으로 리소스 요구 사항으로 다른 워크로드를 생성할 수도 있습니다. 

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example
spec:
  server:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 125m
        memory: 128Mi
    route:
      enabled: true
  applicationSet:
    resources:
      limits:
        cpu: '2'
        memory: 1Gi
      requests:
        cpu: 250m
        memory: 512Mi
  repo:
    resources:
      limits:
        cpu: '1'
        memory: 512Mi
      requests:
        cpu: 250m
        memory: 256Mi
  dex:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 250m
        memory: 128Mi
  redis:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 250m
        memory: 128Mi
  controller:
    resources:
      limits:
        cpu: '2'
        memory: 2Gi
      requests:
        cpu: 250m
        memory: 1Gi

4.15.2. Argo CD 인스턴스 패치를 적용하여 리소스 요구 사항을 업데이트

전체 또는 설치 후 워크로드에 대한 리소스 요구 사항을 업데이트할 수 있습니다.

프로세스

Argo CD 네임스페이스에서 Argo CD 인스턴스의 애플리케이션 컨트롤러 리소스 요청을 업데이트합니다. 

oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/cpu", "value":"1"}]'

oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/memory", "value":"512Mi"}]'

4.15.3. 리소스 요청 제거

설치 후 전체 또는 모든 워크로드에 대한 리소스 요구 사항을 제거할 수도 있습니다.

프로세스

Argo CD 네임스페이스에서 Argo CD 인스턴스의 애플리케이션 컨트롤러 리소스 요청을 제거합니다. 

oc -n argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/cpu"}]'

oc -n argocd argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/memory"}]'

4.16. Argo CD 사용자 정의 리소스 워크로드 모니터링

Red Hat OpenShift GitOps를 사용하면 특정 Argo CD 인스턴스에 대한 Argo CD 사용자 정의 리소스 워크로드의 가용성을 모니터링할 수 있습니다. Argo CD 사용자 정의 리소스 워크로드를 모니터링하면 경고를 활성화하여 Argo CD 인스턴스의 상태에 대한 최신 정보가 있습니다. 해당 Argo CD 인스턴스의 application-controller, repo-server 또는 서버와 같은 구성 요소 워크로드 Pod가 특정 이유로 발생할 수 없으며 준비된 복제본 수와 특정 기간 동안 필요한 복제본 수 사이에 변동이 있는 경우 Operator는 경고를 트리거합니다.

Argo CD 사용자 정의 리소스 워크로드를 모니터링하기 위한 설정을 활성화하고 비활성화할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • Red Hat OpenShift GitOps가 클러스터에 설치되어 있습니다.
  • 모니터링 스택은 openshift-monitoring 프로젝트의 클러스터에 구성되어 있습니다. 또한 Argo CD 인스턴스는 Prometheus를 통해 모니터링할 수 있는 네임스페이스에 있습니다.
  • kube-state-metrics 서비스가 클러스터에서 실행 중입니다.

  • 선택 사항: 사용자 정의 프로젝트에 Argo CD 인스턴스에 대한 모니터링을 이미 사용하는 경우 클러스터의 사용자 정의 프로젝트에 대한 모니터링이 활성화되어 있는지 확인합니다.

    참고

    기본 openshift-monitoring 스택에서 감시하지 않는 네임스페이스에서 Argo CD 인스턴스에 대한 모니터링을 활성화하려면 openshift-* 로 시작하지 않는 네임스페이스, 클러스터에서 사용자 워크로드 모니터링을 활성화해야 합니다. 이 작업을 사용하면 모니터링 스택에서 생성된 PrometheusRule을 가져올 수 있습니다.

4.16.1. Argo CD 사용자 정의 리소스 워크로드에 대한 모니터링 활성화

기본적으로 Argo CD 사용자 정의 리소스 워크로드에 대한 모니터링 구성은 false 로 설정됩니다.

Red Hat OpenShift GitOps를 사용하면 특정 Argo CD 인스턴스에 대한 워크로드 모니터링을 활성화할 수 있습니다. 결과적으로 Operator는 특정 Argo CD 인스턴스에서 관리하는 모든 워크로드에 대한 경고 규칙이 포함된 PrometheusRule 오브젝트를 생성합니다. 이러한 경고 규칙은 해당 구성 요소의 복제본 수가 일정 기간 동안 원하는 상태에서 변경될 때 경고를 트리거합니다. Operator는 사용자가 PrometheusRule 오브젝트에 대한 변경 사항을 덮어쓰지 않습니다.

프로세스

  1. 지정된 Argo CD 인스턴스에서 .spec.monitoring.enabled 필드 값을 true 로 설정합니다.

    Argo CD 사용자 정의 리소스의 예

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: repo
spec:
  ...
  monitoring:
    enabled: true
  ...

  2. Operator에서 생성한 PrometheusRule에 경고 규칙이 포함되어 있는지 확인합니다.

    경고 규칙 예

    apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: argocd-component-status-alert
  namespace: openshift-gitops
spec:
  groups:
    - name: ArgoCDComponentStatus
      rules:
        ...
        - alert: ApplicationSetControllerNotReady 1
          annotations:
            message: >-
              applicationSet controller deployment for Argo CD instance in
              namespace "default" is not running
          expr: >-
            kube_statefulset_status_replicas{statefulset="openshift-gitops-application-controller statefulset",
            namespace="openshift-gitops"} !=
            kube_statefulset_status_replicas_ready{statefulset="openshift-gitops-application-controller statefulset",
            namespace="openshift-gitops"}
          for: 1m
          labels:
            severity: critical

    1
    Argo CD 인스턴스에서 생성한 워크로드가 예상대로 실행되는지 확인하는 PrometheusRule의 경고 규칙입니다.

4.16.2. Argo CD 사용자 정의 리소스 워크로드에 대한 모니터링 비활성화

특정 Argo CD 인스턴스에 대한 워크로드 모니터링을 비활성화할 수 있습니다. 워크로드 모니터링을 비활성화하면 생성된 PrometheusRule이 삭제됩니다.

프로세스

  • 지정된 Argo CD 인스턴스에서 .spec.monitoring.enabled 필드 값을 false 로 설정합니다.

    Argo CD 사용자 정의 리소스의 예

    apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: repo
spec:
  ...
  monitoring:
    enabled: false
  ...

4.16.3. 추가 리소스

4.17. Argo CD 로그 보기

Red Hat OpenShift의 로깅 하위 시스템을 사용하여 Argo CD 로그를 볼 수 있습니다. 로깅 하위 시스템은 Kibana 대시보드에서 로그를 시각화합니다. OpenShift Logging Operator는 기본적으로 Argo CD로 로깅할 수 있습니다.

4.17.1. Argo CD 로그 저장 및 검색

Kibana 대시보드를 사용하여 Argo CD 로그를 저장하고 검색할 수 있습니다.

사전 요구 사항

  • Red Hat OpenShift GitOps Operator가 클러스터에 설치되어 있습니다.
  • Red Hat OpenShift의 로깅 하위 시스템은 클러스터에 기본 구성으로 설치됩니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 red hat applications menu icon 메뉴 → Observability → Logging 으로 이동하여 Kibana 대시보드를 확인합니다.

  2. 인덱스 패턴을 생성합니다.

    1. 모든 인덱스를 표시하려면 인덱스 패턴을 * 로 정의하고 다음 단계를 클릭합니다.
    2. @timestamp for Time Filter 필드 이름을 선택합니다.
    3. 인덱스 패턴 만들기를 클릭합니다.
  3. Kibana 대시보드의 탐색 패널에서 Discover 탭을 클릭합니다.

  4. Argo CD의 로그를 검색하는 필터를 생성합니다. 다음 단계에서는 openshift-gitops 네임스페이스에 있는 모든 Pod의 로그를 검색하는 필터를 생성합니다.

    1. Add a filter + 를 클릭합니다.
    2. kubernetes.namespace_name 필드를 선택합니다.
    3. is operator를 선택합니다.
    4. openshift-gitops 값을 선택합니다.
    5. 저장을 클릭합니다.
  5. 선택 사항: 검색 범위를 좁히려면 추가 필터를 추가합니다. 예를 들어 특정 Pod의 로그를 검색하려면 kubernetes.pod_name 을 필드로 사용하여 다른 필터를 생성할 수 있습니다.
  6. Kibana 대시보드에서 필터링된 Argo CD 로그를 확인합니다.

4.17.2. 추가 리소스

4.18. 인프라 노드에서 GitOps 컨트롤 플레인 워크로드 실행

인프라 노드를 사용하여 서브스크립션 수에 대한 추가 청구 비용을 방지할 수 있습니다.

OpenShift Container Platform을 사용하여 Red Hat OpenShift GitOps Operator가 설치한 인프라 노드에서 특정 워크로드를 실행할 수 있습니다. 이는 해당 네임스페이스의 기본 Argo CD 인스턴스를 포함하여 openshift-gitops 네임스페이스에 기본적으로 Red Hat OpenShift GitOps Operator가 설치하는 워크로드로 구성됩니다.

참고

사용자 네임스페이스에 설치된 다른 Argo CD 인스턴스는 인프라 노드에서 실행할 수 없습니다.

4.18.1. GitOps 워크로드를 인프라 노드로 이동

Red Hat OpenShift GitOps에서 설치한 기본 워크로드를 인프라 노드로 이동할 수 있습니다. 이동할 수 있는 워크로드는 다음과 같습니다.

  • Kam 배포
  • 클러스터 배포 (백엔드 서비스)
  • openshift-gitops-applicationset-controller 배포
  • openshift-gitops-dex-server 배포
  • openshift-gitops-redis deployment
  • openshift-gitops-redis-ha-haproxy 배포
  • openshift-gitops-repo-sever 배포
  • openshift-gitops-server 배포
  • openshift-gitops-application-controller statefulset
  • openshift-gitops-redis-server statefulset

프로세스

  1. 다음 명령을 실행하여 기존 노드에 인프라로 레이블을 지정합니다. 

    $ oc label node <node-name> node-role.kubernetes.io/infra=

  2. GitOpsService CR(사용자 정의 리소스)을 편집하여 인프라 노드 선택기를 추가합니다. 

    $ oc edit gitopsservice -n openshift-gitops

  3. GitOpsService CR 파일에서 runOnInfra 필드를 spec 섹션에 추가하고 true 로 설정합니다. 이 필드는 openshift-gitops 네임스페이스의 워크로드를 인프라 노드로 이동합니다. 

    apiVersion: pipelines.openshift.io/v1alpha1
kind: GitopsService
metadata:
  name: cluster
spec:
  runOnInfra: true

  4. 선택 사항: 테인트를 적용하고 인프라 노드의 워크로드를 분리하고 다른 워크로드가 이러한 노드에서 예약되지 않도록 합니다. 

    $ oc adm taint nodes -l node-role.kubernetes.io/infra
infra=reserved:NoSchedule infra=reserved:NoExecute

  5. 선택 사항: 노드에 테인트를 적용하는 경우 GitOpsService CR에 허용 오차를 추가할 수 있습니다. 

    spec:
  runOnInfra: true
  tolerations:
  - effect: NoSchedule
    key: infra
    value: reserved
  - effect: NoExecute
    key: infra
    value: reserved

Red Hat OpenShift GitOps 네임스페이스의 인프라 노드에 워크로드가 예약되어 있는지 확인하려면 Pod 이름을 클릭하고 노드 선택기 및 Tolerations 가 추가되었는지 확인합니다.

참고

기본 Argo CD CR에 수동으로 추가된 노드 선택기 및 허용 오차는 토글 및 GitOpsService CR의 허용 오차를 통해 덮어씁니다.

4.18.2. 추가 리소스

4.19. GitOps Operator의 크기 조정 요구 사항

크기 조정 요구 사항 페이지에는 OpenShift Container Platform에 Red Hat OpenShift GitOps를 설치하기 위한 크기 조정 요구 사항이 표시됩니다. GitOps Operator에서 인스턴스화한 기본 ArgoCD 인스턴스에 대한 크기 조정 세부 정보도 제공합니다.

4.19.1. GitOps의 크기 조정 요구 사항

Red Hat OpenShift GitOps는 클라우드 네이티브 애플리케이션에 대한 연속 배포를 구현하는 선언적 방법입니다. GitOps를 통해 애플리케이션의 CPU 및 메모리 요구 사항을 정의하고 구성할 수 있습니다.

Red Hat OpenShift GitOps Operator를 설치할 때마다 네임스페이스의 리소스가 정의된 제한 내에 설치됩니다. 기본 설치에서 제한 또는 요청을 설정하지 않으면 할당량이 있는 네임스페이스 내에서 Operator가 실패합니다. 리소스가 충분하지 않으면 클러스터에서 ArgoCD 관련 Pod를 예약할 수 없습니다. 다음 표에서는 기본 워크로드에 대한 리소스 요청 및 제한을 자세히 설명합니다.

워크로드CPU 요청CPU 제한메모리 요청메모리 제한

argocd-application-controller

1

2

1024M

2048M

applicationset-controller

1

2

512M

1024M

argocd-server

0.125

0.5

128M

256M

argocd-repo-server

0.5

1

256M

1024M

argocd-redis

0.25

0.5

128M

256M

argocd-dex

0.25

0.5

128M

256M

HAProxy

0.25

0.5

128M

256M

선택적으로 oc 명령과 함께 ArgoCD 사용자 정의 리소스를 사용하여 세부 사항을 확인하고 수정할 수도 있습니다. 

oc edit argocd <name of argo cd> -n namespace

4.20. 지원 케이스에 대한 디버깅 데이터 수집

지원 케이스를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원 팀에 제공해야 합니다. must-gather 툴을 사용하여 프로젝트 수준 리소스, 클러스터 수준 리소스 및 Red Hat OpenShift GitOps 구성 요소에 대한 진단 정보를 수집할 수 있습니다. 

참고

즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 Red Hat OpenShift GitOps 둘 다에 대한 진단 정보를 제공하십시오.

4.20.1. must-gather 툴 정보

oc adm must-gather CLI 명령은 다음을 포함하여 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터에서 정보를 수집합니다.

  • 리소스 정의
  • 서비스 로그

기본적으로 oc adm must-gather 명령은 기본 플러그인 이미지를 사용하고 ./must-gather.local 에 씁니다.

또는 다음 섹션에 설명된 대로 적절한 인수로 명령을 실행하여 특정 정보를 수집할 수 있습니다.

  • 하나 이상의 특정 기능과 관련된 데이터를 수집하려면 다음 섹션에 나열된 대로 이미지와 함께 --image 인수를 사용합니다.

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

    $ oc adm must-gather \
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.13.3

  • 감사 로그를 수집하려면 다음 섹션에 설명된 대로 -- /usr/bin/gather_audit_logs 인수를 사용합니다.

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

    $ oc adm must-gather -- /usr/bin/gather_audit_logs
    참고

    감사 로그는 파일 크기를 줄이기 위해 기본 정보 세트의 일부로 수집되지 않습니다.

oc adm must-gather 를 실행하면 클러스터의 새 프로젝트에 임의의 이름이 있는 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 중인 디렉터리에 생성되어 있습니다.

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

NAMESPACE                      NAME                 READY   STATUS      RESTARTS      AGE
...
openshift-must-gather-5drcj    must-gather-bklx4    2/2     Running     0             72s
openshift-must-gather-5drcj    must-gather-s8sdh    2/2     Running     0             72s
...

선택적으로 --run-namespace 옵션을 사용하여 특정 네임스페이스에서 oc adm must-gather 명령을 실행할 수 있습니다.

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

$ oc adm must-gather --run-namespace <namespace> \
  --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.13.3

4.20.2. Red Hat OpenShift GitOps에 대한 디버깅 데이터 수집

oc adm must-gather CLI 명령을 사용하여 Red Hat OpenShift GitOps와 연결된 클러스터에 대한 다음 세부 정보를 수집합니다.

  • Red Hat OpenShift GitOps Operator의 서브스크립션 및 네임스페이스입니다.
  • ArgoCD 오브젝트가 사용 가능한 네임스페이스 및 ArgoCD,Applications,ApplicationSets,AppProjects 및 configmaps 와 같은 네임스페이스의 오브젝트입니다.
  • Red Hat OpenShift GitOps Operator에서 관리하는 네임스페이스 목록과 해당 네임스페이스의 리소스입니다.
  • 모든 GitOps 관련 사용자 정의 리소스 오브젝트 및 정의
  • Operator 및 Argo CD 로그입니다.
  • 경고 및 오류 수준 이벤트

사전 요구 사항

  • 관리자로 OpenShift Container Platform 클러스터에 로그인했습니다.
  • OpenShift Container Platform CLI(oc)를 설치했습니다.
  • Red Hat OpenShift GitOps Operator가 설치되었습니다.

프로세스

  1. 디버깅 정보를 저장할 디렉터리로 이동합니다.

  2. Red Hat OpenShift GitOps must-gather 이미지를 사용하여 oc adm must-gather 명령을 실행합니다. 

    $ oc adm must-gather --image=registry.redhat.io/openshift-gitops-1/gitops-must-gather-rhel8:v1.9.0

    must-gather 툴은 현재 디렉터리에서 ./must-gather.local 로 시작하는 새 디렉터리를 생성합니다. 예를 들면 ./must-gather.local.4157245944708210399 입니다.

  3. 방금 만든 디렉터리에서 압축 파일을 만듭니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다. 

    $ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210399
  4. Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.

4.21. Red Hat OpenShift GitOps의 문제 해결

Red Hat OpenShift GitOps로 작업할 때 성능, 모니터링, 구성 및 기타 측면과 관련된 문제가 발생할 수 있습니다. 이 섹션에서는 이러한 문제를 이해하고 해결할 수 있는 솔루션을 제공하는 데 도움이 됩니다.

4.21.1. 문제: Argo CD의 자동 부팅 시 머신 구성과 동기화

Red Hat OpenShift Container Platform에서 노드는 Red Hat OpenShift Machine Config Operator (MCO)를 통해 자동으로 업데이트됩니다. MCO(Machine Config Operator)는 클러스터가 노드의 전체 라이프사이클을 관리하는 데 사용하는 사용자 정의 리소스입니다.

MCO 리소스가 클러스터에서 생성 또는 업데이트되면 MCO는 업데이트를 선택하고 선택한 노드에 필요한 변경을 수행한 다음 해당 노드를 차단, 드레이닝 및 재부팅하여 노드를 정상적으로 다시 시작합니다. 커널에서 kubelet까지 모든 것을 처리합니다.

그러나 MCO와 GitOps 워크플로 간의 상호 작용으로 인해 주요 성능 문제와 바람직하지 않은 기타 동작이 발생할 수 있습니다. 이 섹션에서는 MCO 및 Argo CD GitOps 오케스트레이션 도구가 제대로 작동하도록 만드는 방법을 보여줍니다.

4.21.1.1. 해결책: 머신 구성 및 Argo CD의 향상된 성능

GitOps 워크플로우의 일부로 Machine Config Operator를 사용하는 경우 다음 순서에서 하위 최적화 성능을 생성할 수 있습니다.

  • Argo CD는 애플리케이션 리소스가 포함된 Git 리포지토리에 커밋한 후 자동화된 동기화 작업을 시작합니다.
  • 동기화 작업이 진행되는 동안 Argo CD가 새로운 또는 업데이트된 머신 구성을 알리는 경우 MCO는 머신 구성에 대한 변경 사항을 선택하고 노드 재부팅을 시작하여 변경 사항을 적용합니다.
  • 클러스터의 재부팅 노드에 Argo CD 애플리케이션 컨트롤러가 포함된 경우 애플리케이션 컨트롤러가 종료되고 애플리케이션 동기화가 중단됩니다.

MCO는 노드를 순차적으로 재부팅하고 재부팅할 때마다 Argo CD 워크로드를 다시 예약할 수 있으므로 동기화를 완료하는 데 시간이 다소 걸릴 수 있습니다. 이로 인해 MCO가 동기화 내에서 머신 구성의 영향을 받는 모든 노드를 재부팅할 때까지 정의되지 않은 동작이 발생합니다.

4.21.2. 추가 리소스

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, edit 및 view입니다. 로그인 플러그인은 Jenkins가 실행되는 네임스페이스 또는 프로젝트에서 해당 역할에 대해 자체AR 요청을 실행합니다.

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

기본 OpenShift Container Platform admin, edit 및 view 역할과 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 역할의 목록입니다.
  • 기본 admin 및 edit 역할과 생성한 새 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가 처음 시작되면 관리자 및 암호와 함께 구성이 생성됩니다. 기본 사용자 인증 정보는 admin 및 password입니다. 표준 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_OAUTH가 true로 설정된 경우 해당되지 않습니다.

기본값: 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_PLUGINS 가 true 로 설정된 경우 설치할 추가 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 이미지 스트림 태그의 이미지가 사용됩니다.

기본값: 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 이미지 스트림 태그의 이미지가 사용됩니다.

기본값: image-registry.openshift-image-registry.svc:5000/openshift/java:latest

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

Kubernetes 플러그인을 사용하기 위해 OpenShift Container Platform에서는 Jenkins 에이전트로 사용하기에 적합한 OpenShift 에이전트 기본 이미지를 제공합니다.

중요

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.io의 openshift4 리포지토리에 있었습니다.

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

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

Maven 및 Node.js 에이전트 이미지는 Kubernetes 플러그인에 대한 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-build 라는 Pod 템플릿이 있습니다. 이 pod 템플릿은 openshift 네임스페이스의 java 이미지 스트림에서 제공하는 최신 Java 버전을 사용합니다.

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

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

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

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

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

참고

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

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

적절한 레이블이 있는 구성 맵을 찾으면 Jenkins 이미지는 구성 맵의 키-값 데이터 페이로드에 있는 값에 Jenkins 및 Kubernetes 플러그인 pod 템플릿의 구성 형식과 일치하는 XML(Extensible Markup Language)이 포함되어 있다고 가정합니다. 이미지 스트림 및 이미지 스트림 태그에 대한 구성 맵의 한 가지 주요 장점은 모든 Kubernetes 플러그인 pod 템플릿 매개변수를 제어할 수 있다는 것입니다.

jenkins-agent의 예제 구성 맵은 다음과 같습니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
data:
  template1: |-
    <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
      <inheritFrom></inheritFrom>
      <name>template1</name>
      <instanceCap>2147483647</instanceCap>
      <idleMinutes>0</idleMinutes>
      <label>template1</label>
      <serviceAccount>jenkins</serviceAccount>
      <nodeSelector></nodeSelector>
      <volumes/>
      <containers>
        <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          <name>jnlp</name>
          <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image>
          <privileged>false</privileged>
          <alwaysPullImage>true</alwaysPullImage>
          <workingDir>/tmp</workingDir>
          <command></command>
          <args>${computer.jnlpmac} ${computer.name}</args>
          <ttyEnabled>false</ttyEnabled>
          <resourceRequestCpu></resourceRequestCpu>
          <resourceRequestMemory></resourceRequestMemory>
          <resourceLimitCpu></resourceLimitCpu>
          <resourceLimitMemory></resourceLimitMemory>
          <envVars/>
        </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
      </containers>
      <envVars/>
      <annotations/>
      <imagePullSecrets/>
      <nodeProperties/>
    </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>

다음 예제에서는 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>
참고

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

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

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

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

  • 구성 맵, 이미지 스트림 또는 이미지 스트림 태그에서 레이블 또는 주석을 제거하면 Kubernetes 플러그인 구성에서 기존 PodTemplate 이 삭제됩니다.
  • 이러한 오브젝트가 제거되면 Kubernetes 플러그인에서 해당 구성이 제거됩니다.
  • 레이블 또는 주석이 적절히 지정된 ConfigMap,ImageStream 또는 ImageStreamTag 오브젝트를 생성하거나 초기 생성 후 라벨을 추가하면 Kubernetes-plugin 구성에 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 파일을 빌드하며 두 번째 BuildConfig인 openshift-jee-sample-docker가 실행되도록 합니다. 두 번째 BuildConfig는 컨테이너 이미지에 새 WAR 파일의 계층을 지정합니다.

중요

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

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

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

추가 리소스

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. 추가 리소스

5.2. Jenkins 에이전트

OpenShift Container Platform에서는 Jenkins 에이전트로 사용할 기본 이미지를 제공합니다.

Jenkins 에이전트의 기본 이미지는 다음을 수행합니다.

  • 필요한 도구, 헤드리스 Java, Jenkins JNLP 클라이언트 및 git,tar,zip 및 nss 를 포함한 유용한 툴을 모두 가져옵니다.
  • JNLP 에이전트를 진입점으로 설정합니다.
  • Jenkins 작업 내에서 명령줄 작업을 호출하는 oc 클라이언트 도구가 포함되어 있습니다.
  • RHEL(Red Hat Enterprise Linux) 및 localdev 이미지 모두에 Dockerfile을 제공합니다.
중요

OpenShift Container Platform 릴리스 버전에 적합한 에이전트 이미지 버전을 사용합니다. OpenShift Container Platform 버전과 호환되지 않는 oc 클라이언트 버전을 포함하면 예기치 않은 동작이 발생할 수 있습니다.

OpenShift Container Platform Jenkins 이미지는 Jenkins Kubernetes 플러그인에서 에이전트 이미지를 사용하는 방법을 설명하기 위해 다음 샘플 java-builder pod 템플릿도 정의합니다.

java-builder pod 템플릿은 두 개의 컨테이너를 사용합니다. * OpenShift Container Platform Base 에이전트 이미지를 사용하고 Jenkins 에이전트를 시작 및 중지하기 위해 JNLP 계약을 처리하는 jnlp 컨테이너입니다. * 코드 빌드에 Maven 바이너리 mvn 을 포함한 다양한 Java 바이너리가 포함된 java OpenShift Container Platform Sample ImageStream을 사용하는 Java 컨테이너입니다.

5.2.1. 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 컨테이너 이미지 레지스트리로 푸시할 수 있습니다.

5.2.2. Jenkins 에이전트 환경 변수

각 Jenkins 에이전트 컨테이너는 다음 환경 변수를 사용하여 구성할 수 있습니다.

변수정의값 및 설정 예

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

USE_JAVA_VERSION

컨테이너에서 에이전트를 실행하는 데 사용할 Java 버전의 버전을 지정합니다. 컨테이너 기본 이미지에는 java의 두 가지 버전이 설치되어 있습니다. java-11 및 java-1.8.0. 컨테이너 기본 이미지를 확장하는 경우 관련 접미사를 사용하여 대체 버전의 java를 지정할 수 있습니다.

기본값은 java-11 입니다.

설정 예: java-1.8.0

5.2.3. Jenkins 에이전트 메모리 요구 사항

JVM은 모든 Jenkins 에이전트에서 Jenkins JNLP 에이전트를 호스트하고 javac, Maven 또는 Gradle 같은 Java 애플리케이션을 실행하는 데 사용됩니다.

기본적으로 Jenkins JNLP 에이전트 JVM은 힙에 대해 컨테이너 메모리 제한의 50%를 사용합니다. 이 값은 CONTAINER_HEAP_PERCENT 환경 변수를 통해 수정할 수 있습니다. 상한값으로 제한하거나 완전히 재정의할 수도 있습니다.

파이프라인에서 실행되는 쉘 스크립트나 oc 명령과 같이 Jenkins 에이전트 컨테이너에서 실행되는 다른 모든 프로세스는 기본적으로 OOM을 종료하지 않고는 나머지 50%의 메모리 제한을 초과하여 사용할 수 없습니다.

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

5.2.4. Jenkins 에이전트 Gradle 빌드

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

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

  • org.gradle.daemon=false를 gradle.properties 파일에 추가하여 오래된 Gradle 데몬이 비활성화되었는지 확인합니다.
  • org.gradle.parallel=true가 gradle.properties 파일에서 설정되지 않았고 --parallel이 명령줄 인수로 설정되지 않았음을 확인하여 병렬 빌드 실행을 비활성화합니다.
  • Java 컴파일이 프로세스 외부에서 실행되지 않도록 하려면 build.gradle 파일에서 java { options.fork = false }를 설정합니다.
  • build.gradle 파일에서 test { maxParallelForks = 1 }가 설정되었는지 확인하여 여러 추가 테스트 프로세스를 비활성화합니다.
  • GRADLE_OPTS, JAVA_OPTS 또는 JAVA_TOOL_OPTIONS 환경 변수를 통해 Gradle JVM 메모리 매개변수를 재정의합니다.
  • maxHeapSize 및 jvmArgs 설정을 build.gradle에서 정의하거나 -Dorg.gradle.jvmargs 명령줄 인수를 통해 Gradle 테스트 JVM에 대한 최대 힙 크기 및 JVM 인수를 설정합니다.

5.2.5. Jenkins 에이전트 pod 보존

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

  • Always는 빌드 결과에 관계없이 빌드 pod를 유지합니다.
  • Default 는 플러그인 값을 사용합니다. 이 값은 pod 템플릿만 사용합니다.
  • Never는 pod를 항상 삭제합니다.
  • On Failure는 빌드 중 실패하면 pod를 유지합니다.

pod 보존은 Pipeline Jenkinsfile에서 재정의할 수 있습니다. 

podTemplate(label: "mypod",
  cloud: "openshift",
  inheritFrom: "maven",
  podRetention: onFailure(), 1
  containers: [
    ...
  ]) {
  node("mypod") {
    ...
  }
}
1
podRetention에 대해 허용되는 값은 never(), onFailure(), always() 및 default()입니다.
주의

보존된 pod를 계속 실행하면서 리소스 할당량에 대한 계산에 반영할 수 있습니다.

5.3. Jenkins에서 OpenShift Pipelines 또는 Tekton으로 마이그레이션

CI/CD 워크플로를 Jenkins에서 Tekton 프로젝트를 기반으로 하는 클라우드 네이티브 CI/CD 환경인 Red Hat OpenShift Pipelines 로 마이그레이션할 수 있습니다.

5.3.1. Jenkins 및 OpenShift Pipelines 개념 비교

Jenkins 및 OpenShift Pipelines에서 사용되는 다음과 동등한 용어를 검토하고 비교할 수 있습니다.

5.3.1.1. Jenkins 용어

Jenkins는 공유 라이브러리 및 플러그인을 사용하여 확장할 수 있는 선언적 및 스크립팅된 파이프라인을 제공합니다. Jenkins의 몇 가지 기본 용어는 다음과 같습니다.

  • pipeline: Groovy 구문을 사용하여 애플리케이션을 빌드, 테스트 및 배포하는 전체 프로세스를 자동화합니다.
  • Node: 스크립팅된 파이프라인을 오케스트레이션하거나 실행할 수 있는 시스템입니다.
  • Stage: 파이프라인에서 수행되는 작업의 개념적으로 구별되는 하위 집합입니다. 플러그인 또는 사용자 인터페이스는 종종 이 블록을 사용하여 작업의 상태 또는 진행 상황을 표시합니다.
  • Step: 명령 또는 스크립트를 사용하여 수행할 정확한 작업을 지정하는 단일 작업입니다.

5.3.1.2. OpenShift Pipelines 용어

OpenShift Pipelines는 선언적 파이프라인에 YAML 구문을 사용하고 작업으로 구성됩니다. OpenShift Pipelines의 몇 가지 기본 용어는 다음과 같습니다.

  • Pipeline: 일련의 직렬, 병렬 또는 둘 다에 있는 작업 세트입니다.
  • Task: 명령, 바이너리 또는 스크립트로 구성된 일련의 단계입니다.
  • PipelineRun: 하나 이상의 작업이 있는 파이프라인 실행입니다.

  • TaskRun: 하나 이상의 단계로 작업을 실행합니다.

    참고

    매개변수 및 작업 영역과 같은 입력 세트로 PipelineRun 또는 TaskRun을 시작하고 실행 결과 출력 및 아티팩트 세트가 생성됩니다.

  • Workspace: OpenShift Pipelines에서 작업 공간은 다음과 같은 목적을 제공하는 개념적 블록입니다.

    • 입력, 출력 및 빌드 아티팩트의 저장.
    • 작업 간에 데이터를 공유하는 공용 공간.
    • 시크릿에 보유된 인증 정보, 구성 맵에 저장된 구성 및 조직에서 공유하는 공통 툴의 마운트 지점.
    참고

    Jenkins에는 OpenShift Pipelines 작업 공간에 직접적으로 동일한 작업 공간이 없습니다. 복제된 코드 리포지토리를 저장하고 기록 및 아티팩트를 빌드하므로 컨트롤 노드를 작업 영역으로 간주할 수 있습니다. 작업이 다른 노드에 할당되면 복제된 코드와 생성된 아티팩트가 해당 노드에 저장되지만 제어 노드는 빌드 내역을 유지합니다.

5.3.1.3. 개념 매핑

Jenkins 및 OpenShift Pipelines의 구성 요소는 동일하지 않으며 특정 비교에서는 기술적으로 정확한 매핑을 제공하지 않습니다. Jenkins 및 OpenShift Pipelines의 다음 용어 및 개념은 일반적으로 상관 관계가 있습니다.

표 5.1. Jenkins 및 OpenShift Pipelines - 기본 비교

JenkinsOpenShift Pipelines

Pipeline

Pipeline 및 PipelineRun

Stage

Task

Step

작업의 단계

5.3.2. Jenkins에서 OpenShift Pipelines로 샘플 파이프라인 마이그레이션

다음 동등한 예제를 사용하여 Jenkins에서 OpenShift Pipelines로 파이프라인을 마이그레이션, 테스트 및 배포할 수 있습니다.

5.3.2.1. Jenkins 파이프라인

빌드, 테스트 및 배포를 위해 Groovy로 작성된 Jenkins 파이프라인을 고려하십시오. 

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

5.3.2.2. OpenShift Pipelines 파이프라인

이전 Jenkins 파이프라인과 동일한 OpenShift Pipelines에서 파이프라인을 생성하려면 다음 세 가지 작업을 생성합니다.

빌드 작업 YAML 정의 파일 예

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)

test 작업 YAML 정의 파일 예

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)

deploy task YAML 정의 파일 예

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)

세 가지 작업을 순차적으로 결합하여 OpenShift Pipelines에서 파이프라인을 구성할 수 있습니다.

예: 빌드, 테스트 및 배포를 위한 OpenShift Pipelines 파이프라인

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

5.3.3. Jenkins 플러그인에서 Tekton Hub 작업으로 마이그레이션

플러그인을 사용하여 Jenkins의 기능을 확장할 수 있습니다. OpenShift Pipelines에서 유사한 확장성을 얻으려면 Tekton Hub 에서 사용할 수 있는 작업을 사용합니다.

예를 들어 Jenkins의 git plugin 에 해당하는 Tekton Hub의 git-clone 작업을 고려하십시오.

예: 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

5.3.4. 사용자 정의 작업 및 스크립트를 사용하여 OpenShift Pipelines 기능 확장

OpenShift Pipelines의 Tekton Hub에서 올바른 작업을 찾지 못하거나 작업을 더 잘 제어해야 하는 경우 사용자 지정 작업 및 스크립트를 생성하여 OpenShift Pipelines의 기능을 확장할 수 있습니다.

예: maven test 명령을 실행하기 위한 사용자 지정 작업

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
...

예: YAML 파일에 작성하여 사용자 정의 Python 스크립트 실행

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

5.3.5. Jenkins 및 OpenShift Pipelines 실행 모델 비교

Jenkins 및 OpenShift Pipelines는 유사한 기능을 제공하지만 아키텍처 및 실행에서는 다릅니다.

표 5.2. Jenkins 및 OpenShift Pipelines의 실행 모델 비교

JenkinsOpenShift Pipelines

Jenkins에는 컨트롤러 노드가 있습니다. Jenkins는 파이프라인을 실행하고 중앙 집중적으로 단계를 실행하거나 다른 노드에서 실행되는 작업을 오케스트레이션합니다.

OpenShift Pipelines는 서버리스 및 배포되며 실행을 위한 중앙 종속성이 없습니다.

컨테이너는 파이프라인을 통해 Jenkins 컨트롤러 노드에서 시작됩니다.

OpenShift Pipelines는 모든 단계가 Pod에서 컨테이너로 실행되는 '컨테이너 우선' 접근 방식을 채택합니다(Jenkins의 노드와 동일).

확장성은 플러그인을 사용하여 달성합니다.

확장성은 Tekton Hub의 작업을 사용하거나 사용자 지정 작업 및 스크립트를 생성하여 얻을 수 있습니다.

5.3.6. 일반적인 사용 사례 예

Jenkins 및 OpenShift Pipelines 모두 다음과 같은 일반적인 CI/CD 사용 사례에 대한 기능을 제공합니다.

  • Apache Maven을 사용하여 이미지 컴파일, 빌드 및 배포
  • 플러그인을 사용하여 코어 기능 확장
  • 공유 가능한 라이브러리 및 사용자 지정 스크립트 사용

5.3.6.1. Jenkins 및 OpenShift Pipelines에서 Maven 파이프라인 실행

Jenkins 및 OpenShift Pipelines 워크플로우 모두에서 Maven을 사용하여 이미지를 컴파일, 빌드 및 배포할 수 있습니다. 기존 Jenkins 워크플로를 OpenShift Pipelines에 매핑하려면 다음 예제를 고려하십시오.

예: 이미지를 컴파일 및 빌드하고 Jenkins에서 Maven을 사용하여 OpenShift에 배포합니다.

#!/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' }

예: 이미지를 컴파일 및 빌드하고 OpenShift Pipelines의 Maven을 사용하여 OpenShift에 배포합니다.

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

5.3.6.2. 플러그인을 사용하여 Jenkins 및 OpenShift Pipelines의 핵심 기능 확장

Jenkins는 광범위한 사용자 기반에 의해 수년 동안 개발 된 수많은 플러그인의 대규모 에코 시스템의 이점을 가지고 있습니다. Jenkins 플러그인 색인 에서 플러그인을 검색하고 검색할 수 있습니다.

OpenShift Pipelines에는 커뮤니티 및 엔터프라이즈 사용자가 개발하고 기여한 많은 작업이 있습니다. 재사용 가능한 OpenShift Pipelines 작업의 공개적으로 카탈로그는 Tekton Hub 에서 사용할 수 있습니다.

또한 OpenShift Pipelines는 핵심 기능 내에 Jenkins 에코 시스템의 많은 플러그인을 통합합니다. 예를 들어 권한 부여는 Jenkins 및 OpenShift Pipelines 모두에서 중요한 기능입니다. Jenkins는 역할 기반 권한 부여 전략 플러그인을 사용하여 권한 부여를 수행하는 반면, OpenShift Pipelines는 OpenShift의 기본 제공 역할 기반 액세스 제어 시스템을 사용합니다.

5.3.6.3. Jenkins 및 OpenShift Pipelines에서 재사용 가능한 코드 공유

Jenkins 공유 라이브러리는 Jenkins 파이프라인의 일부에 재사용 가능한 코드를 제공합니다. 라이브러리는 코드 반복 없이 고도로 모듈식 파이프라인을 생성하기 위해 Jenkinsfiles 간에 공유됩니다.

OpenShift Pipelines에는 Jenkins 공유 라이브러리가 직접적으로 동일하지는 않지만 사용자 지정 작업 및 스크립트와 함께 Tekton Hub 의 작업을 사용하여 유사한 워크플로를 수행할 수 있습니다.

5.3.7. 추가 리소스

5.4. OpenShift Jenkins 이미지에 대한 중요한 변경 사항

OpenShift Container Platform 4.11은 OpenShift Jenkins 및 OpenShift 에이전트 기본 이미지를 registry.redhat.io 의 ocp-tools-4 리포지토리로 이동합니다. 또한 페이로드에서 OpenShift Jenkins Maven 및 NodeJS 에이전트 이미지도 제거합니다.

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

이러한 변경 사항은 Jenkins Kubernetes 플러그인과 함께 여러 컨테이너 Pod 템플릿을 사용하도록 OpenShift Container Platform 4.10 권장 사항을 지원합니다.

5.4.1. OpenShift Jenkins 이미지 재배치

OpenShift Container Platform 4.11은 특정 OpenShift Jenkins 이미지의 위치와 가용성을 크게 변경합니다. 또한 이러한 이미지를 업데이트할 시기와 방법을 구성할 수 있습니다.

OpenShift Jenkins 이미지와 동일하게 유지되는 것은 무엇입니까?

  • Cluster Samples Operator는 OpenShift Jenkins 이미지 작동을 위한 ImageStream 및 Template 오브젝트를 관리합니다.
  • 기본적으로 Jenkins Pod 템플릿의 Jenkins DeploymentConfig 오브젝트는 Jenkins 이미지가 변경될 때 재배포를 트리거합니다. 기본적으로 이 이미지는 Samples Operator 페이로드의 ImageStream YAML 파일에 있는 openshift 네임스페이스에 있는 Jenkins 이미지 스트림 태그의 jenkins:2 이미지 스트림 태그에서 참조합니다.
  • OpenShift Container Platform 4.10 및 이전 버전에서 4.11로 업그레이드하는 경우 더 이상 사용되지 않는 maven 및 nodejs pod 템플릿은 여전히 기본 이미지 구성에 있습니다.
  • OpenShift Container Platform 4.10 및 이전 버전에서 4.11로 업그레이드하는 경우 jenkins-agent-maven 및 jenkins-agent-nodejs 이미지 스트림이 여전히 클러스터에 있습니다. 이러한 이미지 스트림을 유지하려면 " openshift 네임스페이스의 jenkins-agent- maven 및 jenkins-agent -nodejs 이미지 스트림에서는 어떻게 됩니까?"를 참조하십시오.

OpenShift Jenkins 이미지의 지원 매트릭스는 어떻게 됩니까?

registry.redhat.io 레지스트리의 ocp-tools-4 리포지토리의 각 새 이미지는 여러 버전의 OpenShift Container Platform을 지원합니다. Red Hat은 이러한 새 이미지 중 하나를 업데이트하면 모든 버전에서 동시에 사용할 수 있습니다. 이 가용성은 Red Hat이 보안 권고에 대응하여 이미지를 업데이트할 때 이상적입니다. 처음에는 이 변경 사항이 OpenShift Container Platform 4.11 이상에 적용됩니다. 이러한 변경 사항은 결국 OpenShift Container Platform 4.9 이상에 적용될 예정입니다.

이전에는 각 Jenkins 이미지가 하나의 OpenShift Container Platform 버전만 지원했으며 Red Hat은 시간이 지남에 따라 해당 이미지를 순차적으로 업데이트할 수 있었습니다.

OpenShift Jenkins 및 Jenkins 에이전트 기본 ImageStream 및 ImageStreamTag 오브젝트에는 어떤 추가 기능이 있습니까?

in-knativeload 이미지 스트림에서 비지침 로드 이미지를 참조하는 이미지 스트림으로 이동하면 OpenShift Container Platform에서 추가 이미지 스트림 태그를 정의할 수 있습니다. Red Hat은 OpenShift Container Platform 4.10 및 이전 버전에 존재하는 "jenkins:2" 및 " image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base-rhel8:latest 와 함께 사용할 수 있도록 일련의 새 이미지 스트림 태그를 생성했습니다. 이러한 새 이미지 스트림 태그는 Jenkins 관련 이미지 스트림을 유지하는 방법을 개선하기 위해 일부 요청을 처리합니다.

새 이미지 스트림 태그 정보:

ocp-upgrade-redeploy
OpenShift Container Platform을 업그레이드할 때 Jenkins 이미지를 업데이트하려면 Jenkins 배포 구성에서 이 이미지 스트림 태그를 사용하십시오. 이 이미지 스트림 태그는 jenkins 이미지 스트림의 기존 2 이미지 스트림 태그와 jenkins -agent-base-rhel8 이미지 스트림의 최신 이미지 스트림 태그에 해당합니다. 하나의 SHA 또는 이미지 다이제스트에만 이미지 태그를 사용합니다. Jenkins 보안 권고와 같이 ocp-tools-4 이미지가 변경되면 Red Hat Engineering에서 Cluster Samples Operator 페이로드를 업데이트합니다.
user-maintained-upgrade-redeploy
OpenShift Container Platform을 업그레이드한 후 Jenkins를 수동으로 재배포하려면 Jenkins 배포 구성에서 이 이미지 스트림 태그를 사용하십시오. 이 이미지 스트림 태그는 사용 가능한 가장 구체적인 이미지 버전 표시기를 사용합니다. Jenkins를 재배포하는 경우 $ oc import-image jenkins:user-maintained-upgrade-redeploy -n openshift 를 실행합니다. 이 명령을 실행하면 OpenShift Container Platform ImageStream 컨트롤러에서 registry.redhat.io 이미지 레지스트리에 액세스하고 해당 Jenkins ImageStreamTag 오브젝트의 OpenShift 이미지 레지스트리 슬롯에 업데이트된 이미지를 저장합니다. 그렇지 않으면 이 명령을 실행하지 않으면 Jenkins 배포 구성에서 재배포를 트리거하지 않습니다.
scheduled-upgrade-redeploy
최신 버전의 Jenkins 이미지가 릴리스될 때 자동으로 재배포하려면 Jenkins 배포 구성에서 이 이미지 스트림 태그를 사용하십시오. 이 이미지 스트림 태그는 OpenShift Container Platform 이미지 스트림 컨트롤러의 이미지 스트림 태그 기능을 주기적으로 가져와서 백업 이미지 변경 사항을 확인합니다. 예를 들어 최근 Jenkins 보안 권고로 인해 이미지가 변경되면 OpenShift Container Platform에서 Jenkins 배포 구성의 재배포를 트리거합니다. 다음 "ECDHE 리소스"의 "이미지 스트림 태그 구성"을 참조하십시오.

openshift 네임스페이스의 jenkins-agent-maven 및 jenkins-agent-nodejs 이미지 스트림은 어떻게 됩니까?

OpenShift Container Platform의 OpenShift Jenkins Maven 및 NodeJS 에이전트 이미지는 4.10에서 더 이상 사용되지 않으며 4.11의 OpenShift Container Platform 설치 페이로드에서 제거됩니다. 이러한 대안은 ocp-tools-4 리포지토리에 정의되어 있지 않습니다. 그러나 다음 "Jenkins 에이전트" 섹션에 설명된 사이드카 패턴을 사용하여 이 문제를 해결할 수 있습니다.

그러나 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

5.4.2. Jenkins 이미지 스트림 태그 사용자 정의

기본 업그레이드 동작을 재정의하고 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 의 값을 변경합니다. 예를 들어, 2 in "value": "jenkins:2" 를 다음 이미지 스트림 태그 중 하나로 바꿉니다.

  • OCP-upgrade-redeploy, 기본값은 OpenShift Container Platform을 업그레이드할 때 Jenkins 이미지를 업데이트합니다.
  • user-maintained-upgrade-redeploy 를 사용하려면 OpenShift Container Platform을 업그레이드한 후 $ oc import-image jenkins:user-maintained-upgrade-redeploy -n openshift 를 실행하여 Jenkins를 수동으로 재배포해야 합니다.
  • scheduled-upgrade-redeploy 는 지정된 < image>:<tag > 조합에서 변경 사항이 있는지 주기적으로 확인하고 변경 시 이미지를 업그레이드합니다. 이미지 변경 컨트롤러는 변경된 이미지를 가져와서 템플릿에서 프로비저닝한 Jenkins 배포 구성을 재배포합니다. 이 예약된 가져오기 정책에 대한 자세한 내용은 다음 "ECDHE 리소스"의 "이미지 스트림에 태그 추가"를 참조하십시오.
참고

기존 배포의 현재 업그레이드 값을 재정의하려면 해당 템플릿 매개변수에 해당하는 환경 변수의 값을 변경합니다.

사전 요구 사항

  • OpenShift Container Platform 4.13에서 OpenShift Jenkins를 실행하고 있습니다.
  • OpenShift Jenkins가 배포된 네임스페이스를 알고 있습니다.

절차

  • 이미지 스트림 태그 값을 설정하고 < namespace >를 OpenShift Jenkins가 배포된 네임스페이스로 바꾸고 < image_stream_tag >를 이미지 스트림 태그로 바꿉니다.

    예제

    $ oc patch dc jenkins -p '{"spec":{"triggers":[{"type":"ImageChange","imageChangeParams":{"automatic":true,"containerNames":["jenkins"],"from":{"kind":"ImageStreamTag","namespace":"<namespace>","name":"jenkins:<image_stream_tag>"}}}]}}'

    작은 정보

    또는 Jenkins 배포 구성 YAML을 편집하려면 $ oc edit dc/jenkins -n <namespace >를 입력하고 'jenkins:<image_stream_tag>' 행을 업데이트합니다.

5.4.3. 추가 리소스

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.