Documentation for this version is no longer maintained.
View documentation for the latest supported version.OpenShift 빌드 정보
OpenShift 빌드 소개
초록
1장. Red Hat OpenShift 빌드 개요 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenShift 빌드는 OpenShift Container Platform 클러스터에서 컨테이너 이미지를 빌드하는 데 사용할 수 있는 확장 가능한 프레임워크입니다. 프레임워크는 source-to-image, Cloud Native Buildpacks, Buildah 등과 같은 툴을 지원하며 다음 4가지 요소를 기반으로 합니다.
- 소스 코드
- 빌드할 소스 코드를 정의합니다.
- 출력 이미지
- 애플리케이션 이미지를 내보낼 위치 정의
- 빌드 전략
- 애플리케이션을 어셈블할 전략을 정의합니다.
- 호출
- 애플리케이션을 빌드하려는 시간을 정의합니다.
Red Hat OpenShift 빌드는 다음 CR(사용자 정의 리소스)으로 구성됩니다.
-
Build -
BuildStrategy및ClusterBuildStrategy -
BuildRun
OpenShift 빌드는 Kubernetes 플랫폼에서 컨테이너 이미지를 빌드하는 프레임워크를 제공하는 오픈 소스 shipwright 프로젝트를 기반으로 합니다.
1.1. 빌드 리소스 링크 복사링크가 클립보드에 복사되었습니다!
Build 리소스는 애플리케이션의 소스 코드와 애플리케이션 이미지를 내보낼 위치를 정의합니다. 다음 예제에서는 Git 소스, 빌드 전략 및 출력 이미지로 구성된 간단한 빌드를 보여줍니다.
Build 리소스를 확장하여 이미지를 프라이빗 레지스트리로 내보내거나 .podman 파일을 사용할 수도 있습니다.
1.2. BuildStrategy 및 ClusterBuildStrategy 리소스 링크 복사링크가 클립보드에 복사되었습니다!
BuildStrategy 및 ClusterBuildStrategy 리소스는 애플리케이션을 어셈블하기 위한 일련의 단계를 정의합니다. 네임스페이스 및 클러스터 내의 Cluster 리소스 내에서 BuildStrategy 리소스를 사용할 수 있습니다.
BuildStrategy
BuildStrategy 또는 ClusterBuildStrategy 리소스의 사양은 steps 오브젝트로 구성됩니다. 다음 예제에서는 buildpacks v3 클러스터 빌드 전략의 사양을 보여줍니다.
1.3. buildrun 리소스 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스는 클러스터 작업 또는 Tekton 작업 실행과 유사하게 클러스터에서 빌드를 호출합니다. BuildRun 리소스는 클러스터의 워크로드를 표시하여 실행 중인 Pod를 생성합니다. BuildRun 은 실행 중인 빌드 인스턴스입니다. 클러스터에서 특정 매개변수를 사용하여 실행할 빌드를 인스턴스화합니다.
BuildRun 리소스는 다음 요소를 정의하는 데 도움이 됩니다.
-
빌드 상태를 모니터링할 고유한
BuildRun이름 -
빌드 중 사용할 참조된
Build인스턴스 - 빌드의 모든 보안을 호스팅하는 서비스 계정
각 BuildRun 리소스는 네임스페이스 내에서 사용할 수 있습니다.
1.4. 빌드 컨트롤러 링크 복사링크가 클립보드에 복사되었습니다!
빌드 컨트롤러는 Build 리소스의 업데이트를 모니터링하고 다음 작업을 수행합니다.
-
참조된
StrategyRef오브젝트가Build리소스에 있는지 확인합니다. -
BuildCR에서 지정된 매개변수가 참조된 빌드 전략에 있는지 확인합니다. 매개변수 이름이 예약된 이름과 충돌하는지도 확인합니다. -
Build리소스에 컨테이너 레지스트리 출력 시크릿이 있는지 확인합니다. -
참조된
spec.source.git.url끝점 URL이Build리소스에 있는지 확인합니다.
빌드 실행 컨트롤러는 Build 또는 TaskRun 리소스의 업데이트를 모니터링하고 다음 작업을 수행합니다.
-
기존
TaskRun리소스를 검색하고 상위BuildRun리소스 상태를 업데이트합니다. -
지정된 서비스 계정을 검색하고
Build리소스의 출력 보안과 함께 설정합니다. -
TaskRun리소스가 없는 경우 컨트롤러는 새 TektonTaskRun리소스를 생성하고TaskRun리소스에 대한 참조를 설정합니다. -
TaskRun리소스의 후속 업데이트의 경우 컨트롤러는 상위BuildRun리소스를 업데이트합니다.
1.4.1. 빌드 검증 링크 복사링크가 클립보드에 복사되었습니다!
잘못된 종속성 또는 구성 설정으로 인해 실패하는 BuildRun 리소스를 트리거하지 않으려면 빌드 컨트롤러에서 미리 유효성을 검사합니다. 모든 검증이 성공하면 Succeeded 라는 status.reason 필드를 볼 수 있습니다. 그러나 검증이 실패하는 경우 status.reason 및 status.message 필드를 확인하여 근본 원인을 파악해야 합니다.
| status.reason 필드 | 설명 |
|---|---|
|
| 네임스페이스 수준에서 참조된 전략이 존재하지 않습니다. |
|
| 클러스터 수준에서 참조된 전략이 존재하지 않습니다. |
|
|
|
|
| Git에 인증하는 데 사용되는 시크릿은 존재하지 않습니다. |
|
| 컨테이너 레지스트리에 인증하는 데 사용되는 시크릿은 존재하지 않습니다. |
|
| 컨테이너 레지스트리에 인증하는 데 사용되는 시크릿은 존재하지 않습니다. |
|
| 인증에 사용되는 여러 보안이 누락되어 있습니다. |
|
|
하나 이상의 정의된 |
|
|
매개변수는 참조된 전략에 정의되지 않습니다. 해당 매개변수를 전략의 |
|
|
정의된 |
|
|
|
|
| 사용자 제공 환경 변수의 이름이 비어 있음을 나타냅니다. |
|
| 사용자 제공 환경 변수의 값이 비어 있음을 나타냅니다. |
1.4.2. 컨트롤러 설정 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤러는 OpenShift Container Platform 클러스터에 몇 가지 기본값이 있습니다. 그러나 controller.yaml 파일에 정의된 환경 변수를 사용하여 몇 가지 컨트롤러 설정을 설정하거나 수정할 수 있습니다. 다음 환경 변수를 사용할 수 있습니다.
| 환경 변수 | 설명 |
|---|---|
|
|
모든 사용자 정의 리소스 정의 조정 작업에 사용되는 기본 컨텍스트 시간 초과를 재정의합니다. 기본값은 |
|
|
|
|
|
종료 로그의 경로를 나타냅니다. 기본값은 |
|
|
Git 래퍼를 활성화하여 해당 소스 호스트 |
|
|
Git 리포지토리를 복제하는 단계에 사용되는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 |
|
|
Git 복제 단계를 위한 사용자 정의 컨테이너 이미지를 나타냅니다. |
|
|
패키지 소스 코드를 가져오기 위해 번들 이미지를 가져오는 단계에 사용되는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 |
|
|
패키지된 소스 코드를 가져오기 위해 번들 이미지를 가져오는 사용자 지정 컨테이너 이미지를 나타냅니다. |
|
|
이미지를 처리하는 단계에 사용되는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 |
|
|
이미지를 처리하는 단계에 사용되는 사용자 지정 컨테이너 이미지를 나타냅니다. |
|
|
로컬 소스 코드가 업로드될 때까지 대기하는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 |
|
|
로컬 소스 코드가 업로드될 때까지 대기하는 사용자 지정 컨테이너 이미지를 나타냅니다. |
|
|
|
|
|
컨트롤러 작업을 강제로 인수하기 전에 컨트롤러가 아닌 노드의 대기 기간인 |
|
|
작동 중인 컨트롤러 노드가 컨트롤러 작업을 다시 설정하는 기간인 |
|
|
새 컨트롤러를 선택하기 전에 컨트롤러 선택기 노드가 대기하는 기간인 |
|
|
빌드 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 |
|
|
빌드 실행 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 |
|
|
빌드 전략 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 |
|
|
클러스터 빌드 전략 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 |
|
|
Kubernetes API 클라이언트에 사용할 버스트를 나타냅니다. 기본값은 |
|
|
Kubernetes API 클라이언트에 사용할 QPS를 나타냅니다. 기본값은 |
2장. OpenShift 빌드 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 OpenShift Container Platform 클러스터에 Red Hat OpenShift 빌드를 설치할 수 있습니다.
2.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
-
ocCLI를 설치했습니다. - OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.
- 클러스터에 Marketplace 기능이 활성화되어 있거나 Red Hat Operator 카탈로그 소스가 수동으로 구성되어 있습니다.
2.2. 콘솔을 사용하여 OpenShift 빌드 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 Red Hat OpenShift Builds Operator를 설치할 수 있습니다. 이 Operator를 설치하면 빌드 구성 요소를 설치하고 사용할 수 있습니다.
프로세스
- 웹 콘솔의 관리자 화면에서 Operator → OperatorHub 페이지로 이동합니다.
- 키워드로 필터링 상자를 사용하여 카탈로그에서 Red Hat OpenShift Builds Operator를 검색합니다.
- Red Hat OpenShift Builds Operator 타일을 클릭합니다.
- Operator에 대한 간략한 설명을 읽고 설치를 클릭합니다.
Operator 설치 페이지에서 다음을 수행합니다.
-
설치 모드가 클러스터의 모든 네임스페이스(기본값) 로 설정되어 있는지 확인합니다. 이 모드는 기본
openshift-operators네임스페이스에 Operator를 설치하여 클러스터의 모든 네임스페이스를 감시하고 사용할 수 있도록 합니다. -
설치된 네임스페이스 가 기본적으로
openshift-operators로 설정되어 있는지 확인합니다. - Approval Strategy으로 Automatic을 선택합니다. 그러면 Operator에 향후 지원되는 업그레이드가 OLM(Operator Lifecycle Manager)에 의해 자동으로 처리됩니다. Manual 승인 전략을 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.
채널 업데이트 선택:
- 업데이트 채널은 기본적으로 latest 로 설정됩니다. 최신 채널을 사용하면 Red Hat OpenShift Builds Operator의 최신 안정적인 버전을 설치할 수 있습니다.
-
특정 버전의 Red Hat OpenShift Builds Operator를 설치하려면 클러스터 관리자가 해당
openshift-builds-<version> 채널을 사용할 수 있습니다. 예를 들어 Red Hat OpenShift Builds Operator 버전0.11.0을 설치하려면openshift-builds-0.11.0채널을 사용할 수 있습니다.
-
설치 모드가 클러스터의 모든 네임스페이스(기본값) 로 설정되어 있는지 확인합니다. 이 모드는 기본
- 설치를 클릭합니다.
검증
- 설치된 Operator 페이지에서 Red Hat OpenShift Builds Operator가 나열되고 설치가 성공으로 설정되어 있는지 확인합니다.
2.2.1. 콘솔을 사용하여 shipwrightBuild 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenShift Builds Operator를 설치한 후 빌드 컨트롤러의 기능을 활성화하려면 shipwrightBuild 리소스를 생성해야 합니다.
프로세스
- 웹 콘솔의 관리자 화면에서 Operator → 설치된 Operator 페이지로 이동합니다.
- 목록에 있는 Red Hat OpenShift Builds Operator 링크를 클릭합니다. Operator 세부 정보 페이지가 열립니다.
- shipwright Build 탭을 선택하고 Create ShipwrightBuild 를 클릭합니다.
양식 보기 또는 YAML 보기를 선택하여 다음과 같은 방식으로 새
ShipwrightBuild리소스를 구성합니다.양식 보기 또는 YAML 보기를 선택하면
name및targetNamespace필드에 대해 구성된 기본값이 표시됩니다. 해당 필드를 편집하지 않으려면 생성 을 클릭하여shipwrightBuild리소스를 기본값으로 구성합니다.생성된 리소스를 shipwright Build 탭에서 볼 수 있습니다.
검증
- 컨트롤러 Pod가 언급된 대상 네임스페이스에 생성되어 있어야 합니다.
2.3. CLI를 사용하여 OpenShift 빌드 설치 링크 복사링크가 클립보드에 복사되었습니다!
CLI를 사용하여 Red Hat OpenShift 빌드도 설치할 수 있습니다.
프로세스
다음 예와 같이
하위.yaml서브스크립션 오브젝트 파일을 생성하여 Red Hat OpenShift Builds Operator에 네임스페이스를 등록합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 서브스크립션 오브젝트를 적용합니다.
oc apply -f sub.yml
$ oc apply -f sub.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이제 Red Hat OpenShift Builds Operator가 기본 대상 네임스페이스
openshift-operators에 설치됩니다.
2.3.1. CLI를 사용하여 shipwrightBuild 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenShift Builds Operator를 설치한 후 빌드 컨트롤러의 기능을 활성화하려면 shipwrightBuild 리소스를 생성해야 합니다.
프로세스
다음 예와 같이
instance.yaml파일을 생성하여리소스를 생성합니다.shipwright-builds네임스페이스에 shipwrightBuildCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 YAML 파일을 적용합니다.
oc apply -f instance.yaml
$ oc apply -f instance.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여
shipwrightBuild 리소스가이제 구성되었는지 확인합니다.oc get pods -n shipwright-builds
$ oc get pods -n shipwright-buildsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3장. 샘플 빌드 전략 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터에 빌드 전략 또는 클러스터 빌드 전략을 설치할 수 있습니다. ClusterBuildStrategy 리소스는 클러스터 전체에서 사용할 수 있으며 네임 스페이스 내에서 BuildStrategy 리소스를 사용할 수 있습니다.
Red Hat OpenShift 빌드는 linux/amd64 플랫폼에서 다음 빌드 전략을 지원합니다.
-
buildpacks-v3-heroku -
buildpacks-v3
Red Hat OpenShift 빌드는 다음 클러스터 빌드 전략을 지원합니다.
-
buildah -
buildkit -
buildpacks-v3-heroku -
buildpacks-v3 -
kaniko -
ko -
source-to-image
buildpacks-v3-heroku,buildpacks-v3 및 source-to-image 전략은 linux/amd64 플랫폼에서만 지원됩니다. 나머지 클러스터 빌드 전략은 모든 플랫폼에서 지원됩니다.
3.1. Buildah 링크 복사링크가 클립보드에 복사되었습니다!
buildah 클러스터 빌드 전략을 사용하여 Build CR에 컨테이너 파일을 지정하여 컨테이너 이미지를 빌드하고 내보낼 수 있습니다. buildah 전략을 클러스터 수준에서 설치할 수 있습니다.
3.1.1. buildah 전략 설치 링크 복사링크가 클립보드에 복사되었습니다!
buildah 클러스터 빌드 전략을 설치할 수 있습니다. 이 전략은 데몬을 실행할 필요가 없으며 권한이 없는 사용자가 사용할 수 있습니다.
buildah 전략은 다음 리소스를 사용하여 설치할 수 있습니다.
-
buildah-shipwright-managed-push: 이 클러스터 빌드 전략을 사용하면 빌드 이미지를 로컬에 저장하여 내보내기 전에 이미지 취약점 스캔과 같은 추가 처리 작업을 수행할 수 있습니다. 이미지를 처리할 수 있는 출력 디렉터리에 저장해야 합니다.$(params.shp-output-directory)시스템 매개 변수는 처리를 위한 출력 디렉터리를 정의합니다. -
buildah-strategy-managed-push: 이 클러스터 빌드 전략에는 추가 처리 없이 이미지를 대상 리포지토리로 내보내는 단계가 포함되어 있습니다.
사전 요구 사항
-
ocCLI를 설치했습니다.
프로세스
buildah전략을 설치하려면 요구 사항에 따라 다음 명령 중 하나 이상을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildah/buildstrategy_buildah_strategy_managed_push_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildah/buildstrategy_buildah_strategy_managed_push_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. Buildpacks v3 링크 복사링크가 클립보드에 복사되었습니다!
CCNB(Cloud Native Builder) 컨테이너 이미지를 기반으로 하는 buildpacks v3 전략을 사용할 수 있습니다(예:oeku /buildpacks:18 및 cloudfoundry/cnb:bionic ).
3.2.1. buildpacks v3 전략 설치 링크 복사링크가 클립보드에 복사되었습니다!
namepsace 또는 클러스터 수준에서 buildpacks v3 전략을 설치할 수 있습니다. 클러스터 수준에 설치하여 클러스터 내의 다른 네임스페이스에서 buildpacks v3 전략을 공유할 수 있습니다.
사전 요구 사항
-
ocCLI를 설치했습니다.
프로세스
클러스터 수준에서
buildpacks v3전략을 설치하려면 다음 명령을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 네임스페이스 수준에서
buildpacks v3전략을 설치하려면 다음 명령을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_namespaced_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_namespaced_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. Kaniko 링크 복사링크가 클립보드에 복사되었습니다!
kaniko 클러스터 빌드 전략을 사용하여 컨테이너 파일 또는 컨텍스트 디렉터리에서 컨테이너 이미지를 빌드할 수 있습니다. kaniko-trivy 클러스터 빌드 전략을 사용하여 Trivy 보안 스캐너로 컨테이너 이미지를 검사할 수도 있습니다. 스캐너가 이미지에서 중요한 취약점을 발견하면 BuildRun 리소스는 오류와 함께 종료되고 취약한 이미지를 컨테이너 레지스트리로 내보내지 않습니다.
이미지 검사를 수행해도 빌드 중인 컨테이너 파일을 신뢰할 수 있는 것은 아닙니다. 빌드하려는 코드를 보호하려면 buildpacks v3 또는 source-to-image 빌드 전략을 사용해야 합니다.
3.3.1. kaniko 전략 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 수준에서 kaniko 전략을 설치할 수 있습니다. 클러스터 수준에 설치하여 클러스터 내의 다른 네임스페이스에서 kaniko 전략을 공유할 수 있습니다.
사전 요구 사항
-
ocCLI를 설치했습니다.
프로세스
클러스터 수준에서
kaniko전략을 설치하려면 다음 명령을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/kaniko/buildstrategy_kaniko_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/kaniko/buildstrategy_kaniko_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 수준에서
kaniko-trivy전략을 설치하려면 다음 명령을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/kaniko/buildstrategy_kaniko-trivy_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/kaniko/buildstrategy_kaniko-trivy_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. buildkit 링크 복사링크가 클립보드에 복사되었습니다!
buildctl 클라이언트 및 데몬으로 구성된 buildkit 클러스터 빌드 전략을 사용할 수 있습니다. 이 전략은 클라이언트와 데몬이 모두 단일 컨테이너에서 실행되는 데몬리스 모드에서 실행됩니다. 권한 없이 전략을 실행할 수 있습니다.
buildkit d
3.4.1. 캐시 내보내기 링크 복사링크가 클립보드에 복사되었습니다!
buildkit 전략에서는 캐싱을 사용하여 빌드 시간을 최적화합니다. 이미지를 레지스트리로 푸시하면 buildkit 전략에서 빌드된 이미지에 캐시 정보를 추가합니다. Build CR의 paramValues 사양에서 cache 매개변수 값을 disabled 로 설정하여 캐싱을 비활성화할 수 있습니다.
3.4.2. 빌드 인수 및 보안 링크 복사링크가 클립보드에 복사되었습니다!
빌드 전략에서 build-args 및 시크릿 과 같은 배열 매개변수를 정의할 수도 있습니다. 기밀 데이터를 저장하려면 KEY=VALUE 형식으로 build-args 값을 제공하고 secrets 매개변수를 사용해야 합니다.
3.4.3. 멀티 플랫폼 빌드 링크 복사링크가 클립보드에 복사되었습니다!
샘플 빌드 전략에는 여러 플랫폼 이미지를 빌드하는 데 buildkit 전략을 사용하도록 설정할 수 있는 플랫폼 배열 매개변수가 포함되어 있습니다. 이 배열 매개변수를 설정하지 않으면 빌드 전략 리소스에 정의된 FROM 이미지에서 지원하는 플랫폼에 대해 이미지가 빌드됩니다. 해당 이미지가 여러 플랫폼을 지원하는 경우 클러스터 노드의 플랫폼에 맞게 이미지가 빌드됩니다.
3.4.4. 알려진 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
rootless 실행을 허용하기 위해 buildkit 클러스터 빌드 전략에서는 제한되지 않은 프로필을 사용하여 AppArmor 및 SecComp 보안 매개변수를 비활성화합니다.
3.4.5. Pod 보안 표준이 있는 클러스터에서 사용 링크 복사링크가 클립보드에 복사되었습니다!
buildkit 전략에서 Pod 보안 관련 필드를 구성할 수 있습니다. 클러스터 설정 및 관리 구성에 따라 다음 설정을 사용할 수 있습니다.
-
기본
rootlesskit패키지에 필요한 대로AppArmor및seccomp매개변수 모두에 대해제한되지 않은프로필을 정의합니다. -
root 수준 권한으로 실행되도록
setuid비트가 구성된 바이너리를 사용하도록allowPrivilegeEscalation플래그의 값을true로 설정합니다. 플래그를 활성화하면rootlesskit패키지를 지원하여 사용자 네임스페이스 매핑 파일/proc/<pid>/uid_map을 설정합니다. -
루트가 아닌 사용자에 대한 실행 작업을 지원하도록
runAsUser필드의 값을UID 1000또는GID 1000으로 설정합니다.
이전 설정은 Pod 보안 표준이 클러스터와 함께 사용되지 않는 경우 영향을 미치지 않습니다.
allowPrivilegeEscalation 플래그를 true 로 설정하지 않으면 rootlesskit 패키지를 실행하여 buildkit 데몬을 시작할 수 없습니다. 보안 표준이 제한된 클러스터는 buildkit 전략을 사용할 수 없습니다.
3.4.6. buildkit 전략 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 수준에서 buildkit 전략을 설치할 수 있습니다. 클러스터 수준에서 설치하여 클러스터 내의 다른 네임스페이스에서 buildkit 전략을 공유할 수 있습니다.
사전 요구 사항
-
ocCLI를 설치했습니다.
프로세스
클러스터 수준에서
buildkit전략을 설치하려면 다음 명령을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildkit/buildstrategy_buildkit_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. Ko 링크 복사링크가 클립보드에 복사되었습니다!
ko 클러스터 빌더 전략을 사용하여 Golang 기본 패키지에서 이미지를 빌드할 수 있습니다. ko 빌드 전략 작동을 제어하려면 Build 또는 BuildRun CR에서 다음 매개변수를 구성할 수 있습니다.
-
go-flags:GOFLAGS환경 변수의 값입니다. 기본값은비어있습니다. -
go-version:Go전략의 버전입니다. 매개변수 값은 golang 이미지의 태그와 일치해야 합니다. 기본값은1.18입니다. -
Ko-version:ko전략의 버전입니다. 기본값은latest입니다. -
package-directory:기본패키지가 포함된 컨텍스트 디렉터리 내의 디렉터리입니다. -
target-platform:linux/arm64와 같이 빌드하는 대상 플랫폼입니다. 쉼표로 구분된 여러 플랫폼(예:linux/arm64,linux/amd64)을 제공할 수도 있습니다.모든값은 기본 이미지에서 지원하는 모든 플랫폼을 빌드합니다.현재 값은 현재빌드가 실행되는 플랫폼을 빌드합니다. -
gocache:GOCACHE환경 변수를 포함할 볼륨입니다. 매개변수 값을 영구 볼륨으로 설정하여 다시 빌드에 대한 컴파일 성능을 최적화할 수 있습니다. 기본값은emptyDir볼륨이며, 이는 빌드 실행이 끝날 때 캐시된 데이터가 삭제됨을 의미합니다.
3.5.1. ko 전략 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 수준에서 ko 전략을 설치할 수 있습니다. 클러스터 수준에서 설치하여 클러스터 내의 여러 네임스페이스에서 ko 전략을 공유할 수 있습니다.
사전 요구 사항
-
ocCLI를 설치했습니다.
프로세스
클러스터 수준에서
ko전략을 설치하려면 다음 명령을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/ko/buildstrategy_ko_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/ko/buildstrategy_ko_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. S2I(Source-to-Image) 링크 복사링크가 클립보드에 복사되었습니다!
kaniko 와 함께 S2I(Source -to-Image ) 빌드 전략을 사용하여 컨테이너 파일을 생성하고 이미지 빌드용 소스 코드를 준비할 수 있습니다. Build CR의 spec.output.image 필드에 지정된 출력 위치로 컨테이너 이미지를 생성하고 푸시하려면 kaniko 전략이 필요합니다.
S 2I(Source-to- Image) 전략에는 Build CR에서 builderImage 매개변수로 사용할 수 있는 이미지가 필요합니다.
3.6.1. S2I(Source-to-Image) 전략 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 수준에서 S2I (Source-to-Image ) 전략을 설치할 수 있습니다. 클러스터 수준에서 클러스터를 설치하여 클러스터 내 다른 네임스페이스에서 S2I(Source -to-Image ) 전략을 공유할 수 있습니다.
사전 요구 사항
-
ocCLI를 설치했습니다.
프로세스
클러스터 수준에서 S
2I(Source-to-Image) 전략을 설치하려면 다음 명령을 실행합니다.oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/source-to-image/buildstrategy_source-to-image-redhat_cr.yaml
$ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/source-to-image/buildstrategy_source-to-image-redhat_cr.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4장. OpenShift 빌드 구성 링크 복사링크가 클립보드에 복사되었습니다!
Build CR(사용자 정의 리소스)을 사용하면 빌드를 구성하기 위해 소스, 빌드 전략, 매개변수 값, 빌더 또는 Docker 파일, 출력, 보존 매개변수 및 볼륨을 정의하는 데 도움이 됩니다. 빌드 리소스는 네임스페이스 내에서 사용할 수 있습니다.
빌드를 구성하려면 Build 리소스 YAML 파일을 생성하여 OpenShift Container Platform 클러스터에 적용합니다.
4.1. 빌드의 구성 가능한 필드 링크 복사링크가 클립보드에 복사되었습니다!
Build 사용자 정의 리소스(CR)에서 다음 필드를 사용할 수 있습니다.
| 필드 | presence | 설명 |
|---|---|---|
|
| 필수 항목 |
리소스의 API 버전을 지정합니다(예: |
|
| 필수 항목 |
리소스 유형을 지정합니다(예: |
|
| 필수 항목 |
|
|
| 필수 항목 | 소스 코드의 위치(예: Git 리포지토리 또는 소스 번들 이미지)를 나타냅니다. |
|
| 필수 항목 |
|
|
| 필수 항목 | 생성된 이미지를 내보낼 위치를 나타냅니다. |
|
| 필수 항목 | 컨테이너 레지스트리에 액세스하기 위한 기존 시크릿을 나타냅니다. |
|
| 선택 사항 | 빌드 전략에 정의된 매개변수 값을 지정하는 name-value 목록을 나타냅니다. |
|
| 선택 사항 |
사용자 정의 시간 초과를 정의합니다. 기본값은 10분입니다. |
|
| 선택 사항 | 출력 이미지에 주석을 달 때 사용할 수 있는 키-값 쌍 목록을 나타냅니다. |
|
| 선택 사항 | 출력 이미지에 레이블을 지정하는 데 사용할 수 있는 키-값 쌍 목록을 나타냅니다. |
|
| 선택 사항 | 빌드 컨테이너에 전달할 수 있는 추가 환경 변수를 정의합니다. 사용 가능한 변수는 빌드 전략에서 사용하는 도구에 따라 달라집니다. |
|
| 선택 사항 | 실패한 빌드 실행이 존재할 수 있는 기간을 지정합니다. |
|
| 선택 사항 | 성공적인 빌드 실행이 존재할 수 있는 기간을 지정합니다. |
|
| 선택 사항 | 존재할 수 있는 실패한 빌드 실행 수를 지정합니다. |
|
| 선택 사항 | 존재할 수 있는 성공적인 빌드 실행 수를 지정합니다. |
4.2. 소스 정의 링크 복사링크가 클립보드에 복사되었습니다!
다음 필드의 값을 설정하여 빌드의 소스 세부 정보를 Build CR(사용자 정의 리소스)에서 구성할 수 있습니다.
-
source.git.url: Git 리포지토리에서 사용할 수 있는 이미지의 소스 위치를 정의합니다. -
source.git.cloneSecret: 개인 Git 리포지토리의 SSH 개인 키가 포함된 네임스페이스의 시크릿을 참조합니다. -
source.git.revision: 소스 Git 리포지토리에서 선택할 특정 버전을 정의합니다. 예를 들어 커밋, 태그 또는 분기 이름입니다. 이 필드는 기본적으로 Git 리포지토리 기본 분기입니다. -
source.contextDir: 소스 코드가 루트 폴더에 없는 리포지토리의 컨텍스트 경로를 지정합니다.
빌드 컨트롤러에서 이미지를 가져오기 위해 지정한 Git 리포지토리가 있는지 자동으로 확인하지 않습니다. 검증해야 하는 경우 다음 예와 같이 build.shipwright.io/verify.repository 주석의 값을 true 로 설정합니다.
빌드 컨트롤러는 다음 시나리오에서 Git 리포지토리가 있는지 확인합니다.
- HTTP 또는 HTTPS 프로토콜과 함께 끝점 URL을 사용하는 경우
-
git@과 같은 SSH 프로토콜을 정의했지만 참조된 보안(예:source.git.cloneSecret)이 정의되어 있지 않은 경우입니다.
다음 예제에서는 다양한 소스 입력 세트를 사용하여 빌드를 구성하는 방법을 보여줍니다.
예: 인증 정보를 사용하여 빌드 구성
다음 예와 같이 인증 정보를 지정하여 소스로 빌드를 구성할 수 있습니다.
예: 컨텍스트 경로를 사용하여 빌드 구성
다음 예와 같이 Git 리포지토리에서 컨텍스트 경로를 지정하는 소스로 빌드를 구성할 수 있습니다.
예: 태그를 사용하여 빌드 구성
다음 예와 같이 Git 리포지토리의 v.0.1.0 태그를 지정하는 소스로 빌드를 구성할 수 있습니다.
예: 환경 변수를 사용하여 빌드 구성
다음 예와 같이 환경 변수를 지정하는 빌드를 구성할 수도 있습니다.
4.3. 전략 정의 링크 복사링크가 클립보드에 복사되었습니다!
Build CR에서 빌드에 대한 전략을 구성할 수 있습니다. 다음 빌드 전략을 사용할 수 있습니다.
-
buildah -
buildpacks-v3 -
source-to-image
빌드 전략을 구성하려면 다음 예와 같이 Build CR에서 spec.strategy.name 및 spec.strategy.kind 필드를 정의합니다.
4.4. 빌드의 매개변수 값 정의 링크 복사링크가 클립보드에 복사되었습니다!
Build CR에서 빌드 전략 매개변수의 값을 지정할 수 있습니다. 매개변수 값을 지정하면 빌드 전략의 단계가 작동하는 방법을 제어할 수 있습니다. BuildRun 리소스의 값을 덮어쓸 수도 있습니다.
모든 매개변수의 경우 직접 또는 구성 맵 또는 시크릿의 참조 키를 사용하여 값을 지정해야 합니다.
빌드 전략 단계에서 매개변수를 사용하면 구성 맵 및 시크릿 사용이 제한됩니다. 매개변수가 명령, 인수 또는 환경 변수에 사용되는 경우에만 구성 맵과 시크릿을 사용할 수 있습니다.
Build CR에서 paramValues 필드를 사용하는 경우 다음 시나리오를 사용하지 마십시오.
-
BuildStrategyCR에 정의된spec.parameters중 하나와 일치하지 않는spec.paramValues이름을 지정합니다. -
shipwright 예약된 매개변수와 충돌하는
spec.paramValues이름을 지정합니다. 이러한 매개변수에는BUILDER_IMAGE,CONTEXT_DIR및shp-로 시작하는 모든 이름이 포함됩니다.
또한 Build CR에서 paramValues 필드를 정의하기 전에 전략의 내용을 이해해야 합니다.
4.4.1. 매개변수 값을 정의하는 구성 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 빌드 전략에서 매개변수를 정의하고 Build CR을 사용하여 해당 매개변수에 값을 할당하는 방법을 보여줍니다. Build CR의 유형 배열 의 매개변수에 값을 할당할 수도 있습니다.
예: ClusterBuildStrategy CR의 매개변수 정의
다음 예제에서는 여러 매개변수를 정의하는 ClusterBuildStrategy CR을 보여줍니다.
예: Build CR에서 매개변수에 값 할당
위의 ClusterBuildStrategy CR은 storage-driver 매개변수를 정의하고 다음 예와 같이 Build CR에서 storage-driver 매개변수 값을 지정할 수 있습니다.
예: 중앙에서 매개변수를 제어하기 위해 ConfigMap CR 생성
여러 빌드에 storage-driver 매개변수를 사용하고 중앙에서 사용을 제어하려면 다음 예와 같이 ConfigMap CR을 생성할 수 있습니다.
다음 예와 같이 생성된 ConfigMap CR을 Build CR에서 매개변수 값으로 사용할 수 있습니다.
예: Build CR에서 type 배열 의 매개변수에 값 할당
배열 형식의 매개 변수에 값을 할당할 수 있습니다. buildah 전략을 사용하는 경우 registries-search 매개변수를 정의하여 특정 레지스트리의 이미지를 검색할 수 있습니다. 다음 예제에서는 registries-search 배열 매개변수에 값을 할당하는 방법을 보여줍니다.
예: Build CR에서 시크릿 참조
다음 예와 같이 registries-block 배열 매개변수의 시크릿을 참조할 수 있습니다.
- 1
- 이 값은 보안을 참조합니다.
4.5. 빌더 또는 Docker 파일 정의 링크 복사링크가 클립보드에 복사되었습니다!
Build CR에서 spec.paramValues 필드를 사용하여 출력 이미지를 빌드하는 도구가 포함된 이미지를 지정할 수 있습니다. 다음 예제는 Build CR에서 Dockerfile 이미지를 지정합니다.
다음 예와 같이 빌더 이미지를 Build CR의 source-to-image 빌드 전략의 일부로 사용할 수도 있습니다.
4.6. 출력 정의 링크 복사링크가 클립보드에 복사되었습니다!
Build CR에서 이미지를 내보낼 출력 위치를 지정할 수 있습니다. 외부 프라이빗 레지스트리를 출력 위치로 사용하는 경우 이미지에 액세스할 시크릿을 지정해야 합니다. 출력 이미지에 대한 주석 및 레이블을 지정할 수도 있습니다.
주석 또는 레이블을 지정하면 출력 이미지가 두 번 푸시됩니다. 첫 번째 푸시는 빌드 전략에서 가져오고 두 번째 푸시는 이미지 구성을 변경하여 주석과 레이블을 추가합니다.
다음 예제에서는 이미지가 푸시되는 퍼블릭 레지스트리를 정의합니다.
다음 예제에서는 이미지가 푸시되는 프라이빗 레지스트리를 정의합니다.
다음 예제에서는 이미지에 대한 주석 및 레이블을 정의합니다.
4.7. 빌드에 대한 보존 매개변수 정의 링크 복사링크가 클립보드에 복사되었습니다!
보존 매개변수는 다음과 같은 목적으로 정의할 수 있습니다.
- 완료된 빌드 실행이 존재할 수 있는 기간을 지정하려면 다음을 수행합니다.
- 빌드에 존재할 수 있는 성공 또는 실패한 빌드 실행 수를 지정하려면 다음을 수행합니다.
보존 매개 변수를 사용하면 BuildRun 인스턴스 또는 리소스를 자동으로 정리할 수 있습니다. Build CR에서 다음 보존 매개변수 값을 설정할 수 있습니다.
-
retention.succeededLimit: 빌드에 존재할 수 있는 성공한 빌드 실행 수를 정의합니다. -
retention.failedLimit: 빌드에 존재할 수 있는 실패한 빌드 실행 수를 정의합니다. -
retention.ttlAfterFailed: 실패한 빌드 실행이 존재할 수 있는 기간을 지정합니다. -
retention.ttlAfterSucceeded: 성공적인 빌드 실행이 존재할 수 있는 기간을 지정합니다.
다음 예제에서는 Build CR에서 보존 매개변수를 사용하는 방법을 보여줍니다.
retention.failedLimit 및 retention.succeededLimit 매개변수 값을 변경하면 빌드에 변경 사항이 적용되는 즉시 새 제한이 적용됩니다. 그러나 retention.ttlAfterFailed 및 retention.ttlAfterSucceeded 매개변수 값을 변경하면 새 빌드 실행에서만 새 보존 기간이 적용됩니다. 이전 빌드는 이전 보존 기간을 따릅니다. BuildRun 및 Build CR 모두에 보존 기간이 정의된 경우 CR에 정의된 보존 기간이 우선 순위를 가져옵니다.
Build Run
4.8. 빌드의 볼륨 정의 링크 복사링크가 클립보드에 복사되었습니다!
Build CR에서 볼륨을 정의할 수 있습니다. 정의된 볼륨은 BuildStrategy 리소스에 지정된 볼륨을 재정의합니다. 볼륨을 재정의하지 않으면 빌드 실행에 실패합니다.
다음 예제에서는 Build CR의 volumes 필드를 사용하는 방법을 보여줍니다.
5장. 빌드 전략 구성 링크 복사링크가 클립보드에 복사되었습니다!
BuildStrategy 또는 ClusterBuildStrategy CR(사용자 정의 리소스)을 사용하면 전략 매개변수, 시스템 매개변수, 단계 리소스 정의, 주석 및 볼륨을 정의하여 빌드 전략을 구성할 수 있습니다. BuildStrategy 리소스는 네임스페이스 내에서 사용할 수 있으며 ClusterBuildStrategy 리소스는 클러스터 전체에서 사용할 수 있습니다.
빌드 전략을 구성하려면 BuildStrategy 또는 ClusterBuildStrategy 리소스 YAML 파일을 생성하여 OpenShift Container Platform 클러스터에 적용합니다.
5.1. 전략 매개변수 정의 링크 복사링크가 클립보드에 복사되었습니다!
BuildStrategy 또는 ClusterBuildStrategy CR(사용자 정의 리소스)에서 전략 매개변수를 정의하고 Build 또는 CR에서 해당 매개변수 값을 설정하거나 수정할 수 있습니다. 빌드 전략을 생성할 때 빌드 시 전략 매개변수를 구성하거나 수정할 수도 있습니다.
Build Run
전략에 대한 매개변수를 정의하기 전에 다음 사항을 고려하십시오.
-
빌드 전략 CR의
spec.parameters필드에 매개변수 목록을 정의합니다. 각 목록 항목에는 배열 유형에 대한 이름, 설명, 유형 및 선택적 기본값 또는 값이 포함되어 있습니다. 기본값이 설정되지 않은 경우Build또는BuildRunCR에 값을 정의해야 합니다. -
빌드 전략의
spec.steps필드에 문자열 또는 배열 유형의 매개변수를 정의합니다. $(params.your-parameter-name)구문을 사용하여 문자열 유형의 매개변수를 지정합니다. 전략을 참조하는Build또는BuildRunCR에서your-parameter-name매개변수 값을 설정할 수 있습니다. 요구 사항에 따라 다음 문자열 매개변수를 정의할 수 있습니다.Expand 표 5.1. 문자열 매개변수 매개변수 설명 image이 매개변수를 사용하여
golang:$(params.go-version)과 같은 사용자 정의 태그를 정의합니다.args이 매개변수를 사용하여 빌더 명령에 데이터 전달
env이 매개변수를 사용하여 환경 변수의 값을 제공
$(params.your-array-parameter-name[*])구문을 사용하여 배열 유형의 매개변수를 지정합니다. 배열을 지정한 후 인수 또는 명령에서 사용할 수 있습니다. 배열의 각 항목에 대해 인수가 설정됩니다. 다음 예제에서는 빌드 전략의spec.steps필드에서 array 매개변수를 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
매개변수 값을 단순한 문자열로 제공하거나 구성 맵 또는 시크릿의 키에 대한 참조로 제공합니다. 매개변수의 경우
명령에정의된 경우에만 구성 맵 또는 시크릿 값을 사용할 수 있습니다.spec.steps필드의args또는env섹션.
5.2. 시스템 매개변수 정의 링크 복사링크가 클립보드에 복사되었습니다!
빌드 전략의 단계를 정의하여 시스템 정보에 액세스하거나 Build 또는 BuildRun CR(사용자 정의 리소스)에서 사용자 정의 정보를 정의할 때 시스템 매개변수를 사용할 수 있습니다. 빌드 실행 컨트롤러에서 런타임에 정의하므로 시스템 매개변수를 구성하거나 수정할 수 없습니다.
빌드 전략 정의에서 다음 시스템 매개변수를 정의할 수 있습니다.
| 매개변수 | 설명 |
|---|---|
|
| 소스 코드가 포함된 디렉터리의 절대 경로를 나타냅니다. |
|
|
소스 코드의 컨텍스트 디렉터리에 대한 절대 경로를 나타냅니다. |
|
|
|
5.3. 단계 리소스 정의 링크 복사링크가 클립보드에 복사되었습니다!
빌드 전략의 모든 단계에 대한 CPU, 메모리, 디스크 사용량과 같은 리소스 정의를 포함할 수 있습니다. 여러 단계가 있는 전략의 경우 다른 단계보다 많은 리소스가 필요할 수 있습니다. 전략 관리자는 각 단계에 적합한 리소스 값을 정의할 수 있습니다.
예를 들어 동일한 단계를 사용하여 전략을 설치할 수 있지만 클러스터에 다른 이름과 단계 리소스를 설치하여 사용자가 더 작거나 큰 리소스 요구 사항을 사용하여 빌드를 생성할 수 있습니다.
5.3.1. 다양한 리소스가 있는 전략 링크 복사링크가 클립보드에 복사되었습니다!
리소스에 대한 다양한 제한으로 동일한 전략의 여러 유형을 정의합니다. 다음 예제에서는 리소스에 정의된 소규모 및 중간 제한과 동일한 buildah 전략을 사용합니다. 이 예제에서는 전략 관리자가 단계 리소스 정의를 보다 효과적으로 제어할 수 있도록 제공합니다.
5.3.1.1. 작은 제한이 있는 Buildah 전략 링크 복사링크가 클립보드에 복사되었습니다!
다음 예와 같이 buildah 전략에 대한 작은 리소스 제한을 사용하여 spec.steps[].resources 필드를 정의합니다.
예: 작은 제한이 있는 buildah 전략
5.3.1.2. 중간 제한이 있는 Buildah 전략 링크 복사링크가 클립보드에 복사되었습니다!
다음 예와 같이 buildah 전략에 대한 중간 리소스 제한을 사용하여 spec.steps[].resources 필드를 정의합니다.
예: 중간 제한이 있는 buildah 전략
전략에 대한 리소스 정의를 구성한 후 다음 예와 같이 Build CR의 전략을 참조해야 합니다.
5.3.2. Tekton 파이프라인의 리소스 관리 링크 복사링크가 클립보드에 복사되었습니다!
빌드 컨트롤러는 전략 단계를 실행하기 위해 Pod를 예약할 수 있도록 Tekton 파이프라인 컨트롤러에서 작동합니다. 런타임 시 빌드 컨트롤러에서 Tekton TaskRun 리소스를 생성하고 TaskRun 리소스는 특정 네임스페이스에 새 Pod를 생성합니다. 그런 다음 이 Pod는 모든 전략 단계를 순차적으로 실행하여 이미지를 빌드합니다.
5.4. 주석 정의 링크 복사링크가 클립보드에 복사되었습니다!
빌드 전략 또는 다른 Kubernetes 오브젝트에 대한 클러스터 빌드 전략에 대한 주석을 정의할 수 있습니다. 빌드 전략에서는 먼저 주석을 TaskRun 리소스에 전파합니다. 그런 다음 Tekton은 해당 항목을 Pod에 전파합니다.
다음과 같은 목적으로 주석을 사용할 수 있습니다.
-
Pod가 사용할 수 있는 네트워크 대역폭을 제한하기 위해
kubernetes.io/ingress-bandwidth및kubernetes.io/egress-bandwidth주석은 Kubernetes 네트워크 트래픽 셰이핑 기능에 정의됩니다. -
컨테이너의 AppArmor 프로필을 정의하려면
container.apparmor.security.beta.kubernetes.io/<container_name> 주석이 사용됩니다.
다음 예제에서는 빌드 전략에서 주석 사용을 보여줍니다.
다음 주석은 전파되지 않습니다.
-
kubectl.kubernetes.io/last-applied-configuration -
clusterbuildstrategy.shipwright.io/* -
buildstrategy.shipwright.io/* -
build.shipwright.io/* -
buildrun.shipwright.io/*
전략 관리자는 정책 엔진을 사용하여 주석 사용을 추가로 제한할 수 있습니다.
5.5. 문자열 매개변수 보안 참조 링크 복사링크가 클립보드에 복사되었습니다!
문자열 매개변수는 BuildStrategy 또는 Cluster CR(사용자 정의 리소스)에서 환경 변수, 인수 또는 이미지를 정의할 때 사용됩니다. 빌드 전략 단계에서는 BuildStrategy $(params.your-parameter-name) 구문을 사용하여 문자열 매개변수를 참조할 수 있습니다.
빌드 전략 단계에서 $(params.your-parameter-name) 구문을 사용하여 시스템 매개변수 및 전략 매개변수를 참조할 수도 있습니다.
Pod에서 모든 $(params.your-parameter-name) 변수가 실제 문자열로 교체됩니다. 그러나 인라인 스크립트를 사용하여 인수에서 string 매개변수를 참조할 때 주의해야 합니다. 예를 들어 스크립트로 정의된 인수로 매개변수 값을 안전하게 전달하려면 다음 접근 방법 중 하나를 선택할 수 있습니다.
- 환경 변수 사용
- 인수 사용
예: 문자열 매개변수를 환경 변수에 참조
문자열 매개 변수를 스크립트 내에서 직접 사용하는 대신 환경 변수에 전달할 수 있습니다. 환경 변수 인용을 사용하면 명령 삽입 취약점을 방지할 수 있습니다. buildpacks v3 와 같은 전략에 이 접근 방식을 사용할 수 있습니다. 다음 예제에서는 스크립트 내의 환경 변수를 사용하여 문자열 매개변수를 참조합니다.
예: 문자열 매개변수를 인수로 참조
string 매개변수를 스크립트 내에 정의된 인수로 전달할 수 있습니다. 명령 주입에 대한 감시를 인용하는 적절한 쉘입니다. buildah 와 같은 전략에 이 접근 방식을 사용할 수 있습니다. 다음 예제에서는 스크립트 내에 정의된 인수를 사용하여 문자열 매개변수를 참조합니다.
5.6. 시스템 결과 정의 링크 복사링크가 클립보드에 복사되었습니다!
빌드 전략에서 생성한 이미지의 크기와 다이제스트를 결과 파일 집합에 저장할 수 있습니다. BuildRun 리소스가 실패하는 경우 디버깅을 위해 오류 세부 정보를 저장할 수도 있습니다. BuildStrategy 또는 ClusterBuildStrategy CR에서 다음 결과 매개변수를 정의할 수 있습니다.
| 매개변수 | 설명 |
|---|---|
|
| 이미지의 다이제스트를 저장하는 파일의 경로를 나타냅니다. |
|
| 이미지의 압축 크기를 저장하는 파일의 경로를 나타냅니다. |
|
| 오류 이유를 저장하는 파일의 경로를 나타냅니다. |
|
| 오류 메시지를 저장하는 파일의 경로를 나타냅니다. |
다음 예제는 BuildRun CR의 .status.output 필드에 있는 이미지의 크기와 다이제스트를 보여줍니다.
다음 예제에서는 BuildRun CR의 .status.failure Details 필드에 있는 오류 이유 및 메시지를 보여줍니다.
5.7. 볼륨 및 볼륨 마운트 정의 링크 복사링크가 클립보드에 복사되었습니다!
빌드 전략에는 볼륨 및 볼륨 마운트 정의가 포함됩니다. 빌드 전략에 정의된 볼륨은 일반적인 volumeSource 유형을 모두 지원합니다. 빌드 단계는 볼륨 마운트를 생성하여 볼륨을 참조합니다.
빌드 단계에 정의된 볼륨 마운트를 사용하면 BuildStrategy, Build 또는 리소스에 정의된 볼륨에 액세스할 수 있습니다.
Build Run
빌드 전략의 볼륨은 기본적으로 false 로 설정된 overridable 부울 플래그를 사용합니다. Build 또는 BuildRun 리소스가 BuildStrategy 리소스에 정의된 볼륨을 덮어쓰려고 하면 덮어쓸 수 있는 플래그의 기본값이 false 이므로 실패합니다.
다음 예제에서는 volumes 및 volumeMounts 필드를 정의하는 BuildStrategy 리소스를 보여줍니다.
6장. 빌드 실행 구성 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun CR(사용자 정의 리소스)을 사용하면 빌드 참조, 빌드 사양, 매개변수 값, 서비스 계정, 출력, 보존 매개변수 및 볼륨을 정의하여 빌드 실행을 구성할 수 있습니다. BuildRun 리소스는 네임스페이스 내에서 사용할 수 있습니다.
빌드 실행을 구성하려면 BuildRun 리소스 YAML 파일을 생성하여 OpenShift Container Platform 클러스터에 적용합니다.
6.1. 빌드 실행의 구성 가능한 필드 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun CR(사용자 정의 리소스)에서 다음 필드를 사용할 수 있습니다.
| 필드 | presence | 설명 |
|---|---|---|
|
| 필수 항목 |
리소스의 API 버전을 지정합니다. 예를 들어 |
|
| 필수 항목 |
리소스 유형을 지정합니다. 예를 들면 |
|
| 필수 항목 |
사용자 지정 리소스 정의 인스턴스를 식별하는 메타데이터를 나타냅니다. 예를 들어 |
|
| 선택 사항 |
사용할 기존 |
|
| 선택 사항 |
사용할 포함된 |
|
| 선택 사항 | 이미지를 빌드할 때 사용할 서비스 계정을 나타냅니다. |
|
| 선택 사항 |
사용자 정의 시간 초과를 정의합니다. 이 필드 값은 |
|
| 선택 사항 |
빌드 전략에 정의된 매개변수 값을 지정하는 name-value 목록을 나타냅니다. 매개변수 값은 |
|
| 선택 사항 |
생성된 이미지를 내보낼 사용자 지정 위치를 나타냅니다. 이 필드 값은 |
|
| 선택 사항 |
컨테이너 레지스트리에 액세스할 수 있는 기존 시크릿을 나타냅니다. 이 시크릿은 |
|
| 선택 사항 |
빌드 컨테이너에 전달할 수 있는 추가 환경 변수를 정의합니다. 이 필드 값은 |
spec.build.name 및 spec.build.spec 필드는 함께 사용할 수 없으므로 동일한 CR에서 함께 사용할 수 없습니다.
6.2. 빌드 참조 정의 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스에서 spec.build.name 필드를 구성하여 빌드할 이미지를 나타내는 Build 리소스를 참조할 수 있습니다. 다음 예제는 spec.build.name 필드를 구성하는 BuildRun CR을 보여줍니다.
6.3. 빌드 사양 정의 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스에 전체 spec.build.spec 필드를 삽입하여 이미지를 빌드할 수 있습니다. 다음 예제는 spec.build.spec 필드를 구성하는 BuildRun CR을 보여줍니다.
spec.build.name 및 spec.build.spec 필드는 함께 사용할 수 없으므로 동일한 CR에서 함께 사용할 수 없습니다.
6.4. 빌드 실행에 대한 매개변수 값 정의 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun CR에서 빌드 전략 매개변수의 값을 지정할 수 있습니다. 동일한 이름의 Build 리소스에도 정의된 매개변수 값을 제공한 경우 리소스에 정의된 값이 우선합니다.
Build Run
다음 예에서 BuildRun 리소스의 cache 매개변수 값은 Build 리소스에 정의된 cache 매개변수의 값을 재정의합니다.
6.5. 서비스 계정 정의 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스에서 서비스 계정을 정의할 수 있습니다. 서비스 계정은 다음 예와 같이 Build 리소스에서 참조하는 모든 보안을 호스팅합니다.
- 1
spec.serviceAccount필드의 값을".generate"로 설정하여 런타임 중에 서비스 계정을 생성할 수도 있습니다. 생성된 서비스 계정의 이름은BuildRun리소스의 이름과 일치합니다.
서비스 계정을 정의하지 않으면 BuildRun 리소스는 네임스페이스에 있는 경우 파이프라인 서비스 계정을 사용합니다. 그렇지 않으면 BuildRun 리소스에서 기본 서비스 계정을 사용합니다.
6.6. 빌드 실행에 대한 보존 매개변수 정의 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스에 완료된 빌드 실행이 존재할 수 있는 기간을 지정할 수 있습니다. 보존 매개 변수를 사용하면 BuildRun 인스턴스를 자동으로 정리할 수 있습니다. BuildRun CR에서 다음 보존 매개변수의 값을 설정할 수 있습니다.
-
retention.ttlAfterFailed: 실패한 빌드 실행이 존재할 수 있는 기간을 지정합니다. -
retention.ttlAfterSucceeded: 성공적인 빌드 실행이 존재할 수 있는 기간을 지정합니다.
다음 예제에서는 BuildRun CR에서 보존 매개변수를 정의하는 방법을 보여줍니다.
BuildRun 및 Build CR 모두에 retention 매개변수를 정의한 경우 CR에 정의된 값이 Build CR에 정의된 보존 매개변수 값을 재정의합니다.
Build Run
6.7. 빌드 실행에 대한 볼륨 정의 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun CR에서 볼륨을 정의할 수 있습니다. 정의된 볼륨은 BuildStrategy 리소스에 지정된 볼륨을 재정의합니다. 볼륨을 재정의하지 않으면 빌드 실행에 실패합니다.
Build 및 BuildRun 리소스가 동일한 볼륨을 재정의하는 경우 BuildRun 리소스에 정의된 볼륨이 재정의에 사용됩니다.
다음 예제에서는 volumes 필드를 사용하는 BuildRun CR을 보여줍니다.
6.8. 환경 변수 정의 링크 복사링크가 클립보드에 복사되었습니다!
필요에 따라 BuildRun CR에서 환경 변수를 사용할 수 있습니다. 다음 예제에서는 환경 변수를 정의하는 방법을 보여줍니다.
예: 환경 변수를 사용하여 BuildRun 리소스 정의
다음 예제에서는 Kubernetes Downward API를 사용하여 Pod를 환경 변수로 노출하는 BuildRun 리소스를 보여줍니다.
예: Pod를 환경 변수로 노출하도록 BuildRun 리소스 정의
다음 예제에서는 Kubernetes Downward API를 사용하여 컨테이너를 환경 변수로 노출하는 BuildRun 리소스를 보여줍니다.
예: 컨테이너를 환경 변수로 노출하도록 BuildRun 리소스 정의
6.9. 빌드 실행 상태 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스는 다음 예와 같이 이미지 빌드 상태가 변경될 때마다 업데이트됩니다.
예: 알 수 없는 상태로 빌드
oc get buildrun buildpacks-v3-buildrun
$ oc get buildrun buildpacks-v3-buildrun
NAME SUCCEEDED REASON MESSAGE STARTTIME COMPLETIONTIME
buildpacks-v3-buildrun Unknown Pending Pending 1s
예: True 상태로 BuildRun
oc get buildrun buildpacks-v3-buildrun
$ oc get buildrun buildpacks-v3-buildrun
NAME SUCCEEDED REASON MESSAGE STARTTIME COMPLETIONTIME
buildpacks-v3-buildrun True Succeeded All Steps have completed executing 4m28s 16s
BuildRun 리소스는 상태 관련 정보를 status.conditions 필드에 저장합니다. 예를 들어 Succeeded 유형의 조건은 리소스가 작업을 성공적으로 완료했음을 나타냅니다. status.conditions 필드에는 BuildRun 리소스의 status, reason, message와 같은 중요한 정보가 포함됩니다.
6.9.1. 빌드 실행 상태 설명 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun CR(사용자 정의 리소스)은 이미지 빌드 프로세스 중에 다른 상태를 가질 수 있습니다. 다음 표에서는 빌드 실행의 다양한 상태에 대해 설명합니다.
| 상태 | 원인 | 설명 |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
| 사용자가 빌드 실행을 취소하도록 요청했습니다. 이 요청은 빌드 실행 컨트롤러를 트리거하여 관련 작업 실행 취소를 요청합니다. 이 상태가 있는 경우에도 취소가 진행 중입니다. |
|
|
|
|
|
|
|
단계 중 하나에서 |
|
|
|
|
|
|
|
|
|
|
| 참조된 클러스터 범위 전략이 클러스터에서 찾을 수 없습니다. |
|
|
| 참조된 네임스페이스 범위 전략이 클러스터에서 찾을 수 없습니다. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
기본값 없이 빌드 전략에 정의된 일부 매개변수에 대한 값을 제공하지 않았습니다. |
|
|
| 시스템 매개 변수의 값이 제공되었습니다. 이 값은 허용되지 않습니다. |
|
|
| 빌드 전략에 정의되지 않은 매개변수 값이 제공되었습니다. |
|
|
| 잘못된 유형의 빌드 전략 매개변수에 대한 값이 제공되었습니다. 예를 들어 매개변수가 빌드 전략에서 배열 또는 문자열로 정의된 경우 그에 따라 값 집합 또는 직접 값을 제공해야 합니다. |
|
|
|
매개변수 값에는 값 , |
|
|
|
array 매개변수의 값에는 값 , |
|
|
|
매개변수 값에는 |
|
|
|
매개변수 값에는 |
|
|
| 참조된 서비스 계정이 클러스터에서 찾을 수 없습니다. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
정의된 |
|
|
|
정의된 |
|
|
| 빌드 실행 Pod가 실행 중인 노드에서 제거되었습니다. |
6.9.2. 빌드 실행 실패 링크 복사링크가 클립보드에 복사되었습니다!
빌드 실행에 실패하면 BuildRun CR의 status.failure Details 필드를 확인하여 Pod 또는 컨테이너에서 오류가 발생한 정확한 지점을 확인할 수 있습니다. status.failureDetails 필드에는 오류 메시지와 실패 이유가 포함됩니다. 빌드 전략에 정의된 경우 메시지와 실패 이유만 표시됩니다.
다음 예제에서는 실패한 빌드 실행을 보여줍니다.
status.failureDetails 필드는 Git과 관련된 모든 작업에 대한 오류 세부 정보도 제공합니다.
6.9.3. 단계적 결과 빌드 실행 상태가 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스의 실행을 완료한 후 .status 필드에 빌드 실행 컨트롤러에서 생성된 단계에서 .status.taskResults 결과가 포함됩니다. 결과에는 이미지 다이제스트 또는 이미지 빌드에 사용되는 소스 코드의 커밋 SHA가 포함됩니다. BuildRun 리소스에서 .status.sources 필드에는 소스 단계 실행의 결과가 포함되어 있으며 .status.output 필드에는 출력 단계의 실행 결과가 포함됩니다.
다음 예제에서는 Git 소스에 대한 단계 결과가 있는 BuildRun 리소스를 보여줍니다.
예: Git 소스에 대한 단계 결과가 있는 BuildRun 리소스
다음 예제에서는 로컬 소스 코드에 대한 단계 결과가 있는 BuildRun 리소스를 보여줍니다.
예: 로컬 소스 코드에 대한 단계 결과가 있는 BuildRun 리소스
빌드 전략에 정의된 경우에만 출력 이미지의 다이제스트와 크기가 표시됩니다.
6.9.4. 빌드 스냅샷 링크 복사링크가 클립보드에 복사되었습니다!
각 빌드 실행 조정에 대해 기존 작업 실행이 해당 빌드 실행의 일부인 경우 BuildRun 리소스 상태의 buildSpec 필드가 업데이트됩니다.
이번 업데이트 중에 Build 리소스 스냅샷은 BuildRun 리소스의 status.buildSpec 필드를 생성하고 포함합니다. 이로 인해 buildSpec 필드에는 특정 이미지 빌드를 실행하는 데 사용된 원래 Build 사양의 정확한 사본이 포함되어 있습니다. 빌드 스냅샷을 사용하면 원래 Build 리소스 구성을 볼 수 있습니다.
6.10. Tekton 작업과의 빌드 실행 관계 링크 복사링크가 클립보드에 복사되었습니다!
BuildRun 리소스는 이미지 생성 작업을 Tekton TaskRun 리소스에 위임하여 작업이 완료되거나 작업에서 실패할 때까지 모든 단계를 실행합니다.
빌드 실행 조정 중에 빌드 실행 컨트롤러에서 새 TaskRun 리소스를 생성합니다. 컨트롤러는 TaskRun 리소스에서 빌드 실행 실행에 필요한 단계를 포함합니다. 포함된 단계는 빌드 전략에 정의됩니다.
6.11. 빌드 실행 취소 링크 복사링크가 클립보드에 복사되었습니다!
상태를 로 설정하여 활성 BuildRun 인스턴스를 취소할 수 있습니다. BuildRun CanceledBuildRun 인스턴스를 취소하면 기본 TaskRun 리소스도 취소됨으로 표시됩니다.
다음 예제에서는 BuildRun 리소스에 대해 취소된 빌드 실행을 보여줍니다.
6.12. 자동 빌드 실행 삭제 링크 복사링크가 클립보드에 복사되었습니다!
빌드 실행을 자동으로 삭제하려면 빌드 또는 사양에 다음 보존 매개변수를 추가할 수 있습니다.
build run
buildrunTTL 매개변수: 빌드가 완료된 후 정의된 기간 동안만 존재하는지 확인합니다.-
buildrun.spec.retention.ttlAfterFailed: 지정된 시간이 경과하고 빌드 실행에 실패한 경우 빌드 실행이 삭제됩니다. -
buildrun.spec.retention.ttlAfterSucceeded: 지정된 시간이 통과되고 빌드 실행에 성공하면 빌드 실행이 삭제됩니다.
-
BuildTTL 매개변수: 빌드가 완료된 후 정의된 기간 동안만 빌드에 대해 실행되도록 합니다.-
build.spec.retention.ttlAfterFailed: 지정된 시간이 경과하고 빌드 실행에 실패한 경우 빌드 실행이 삭제됩니다. -
build.spec.retention.ttlAfterSucceeded: 지정된 시간이 경과하고 빌드에 성공한 경우 빌드 실행이 삭제됩니다.
-
빌드제한 매개변수: 빌드에 대해 제한된 수의 성공 또는 실패한 빌드 실행만 존재할 수 있는지 확인합니다.-
build.spec.retention.succeededLimit: 빌드에 존재할 수 있는 성공한 빌드 실행 수를 정의합니다. -
build.spec.retention.failedLimit: 빌드에 존재할 수 있는 실패한 빌드 실행 수를 정의합니다.
-
7장. 빌드 이미지 인증 링크 복사링크가 클립보드에 복사되었습니다!
이미지를 빌드할 때 인증을 정의해야 할 수 있습니다. 예를 들어 이미지를 프라이빗 레지스트리로 내보내거나 Git 리포지토리에서 소스 코드를 가져오는 경우 인증이 필요합니다. 인증 시 사용자 이름과 암호 또는 시크릿을 사용하여 필요한 중요한 데이터를 저장할 수 있습니다.
이미지 빌드 중 인증을 위해 Build CR(사용자 정의 리소스)에서 보안과 함께 기본 또는 SSH 인증을 구성할 수 있습니다.
7.1. 빌드 보안 주석 링크 복사링크가 클립보드에 복사되었습니다!
빌드 보안에 build.shipwright.io/referenced.secret: "true" 주석을 추가할 수 있습니다. 이 주석을 기반으로 빌드 컨트롤러는 빌드 보안에 대한 이벤트 생성, 업데이트 또는 삭제와 같은 이벤트 시 조정 작업을 수행합니다. 다음 예제에서는 보안과 함께 주석을 사용하는 방법을 보여줍니다.
이 주석은 빌드 인스턴스에서 참조하지 않는 보안을 필터링합니다. 예를 들어 시크릿에 이 주석이 없는 경우 보안에 대해 이벤트가 트리거된 경우에도 빌드 컨트롤러에서 조정하지 않습니다. 이벤트 트리거를 조정하면 빌드 컨트롤러에서 빌드 구성에 대한 검증을 다시 트리거하여 종속성이 누락되었는지 파악할 수 있습니다.
7.2. Git 리포지토리에 대한 인증 링크 복사링크가 클립보드에 복사되었습니다!
Git 리포지토리에 대해 다음과 같은 인증 유형을 정의할 수 있습니다.
- 기본 인증
- SSH(Secure Shell) 인증
Build CR에서 두 가지 유형의 인증을 사용하여 Git 보안을 구성할 수도 있습니다.
7.2.1. 기본 인증 링크 복사링크가 클립보드에 복사되었습니다!
기본 인증을 사용하여 Git 리포지토리의 사용자 이름과 암호를 구성해야 합니다. 다음 예제에서는 Git에 대한 기본 인증을 사용하는 방법을 보여줍니다.
7.2.2. SSH 인증 링크 복사링크가 클립보드에 복사되었습니다!
SSH 인증을 사용하면 사용할 Git 리포지토리 공급자의 호스트 이름을 지정하도록 Tekton 주석을 구성해야 합니다. 예를 들어 GitHub의 경우 github.com 또는 GitLab 의 경우 github.com 입니다.
다음 예제에서는 Git에 대한 SSH 인증을 사용하는 방법을 보여줍니다.
7.2.3. Git 시크릿 사용 링크 복사링크가 클립보드에 복사되었습니다!
관련 네임스페이스에 보안을 생성한 후 Build Custom Resource(CR)에서 참조할 수 있습니다. 두 가지 유형의 인증을 모두 사용하여 Git 시크릿을 구성할 수 있습니다.
다음 예제에서는 SSH 인증 유형을 사용하여 Git 시크릿을 사용하는 방법을 보여줍니다.
다음 예제에서는 기본 인증 유형을 사용하여 Git 보안을 사용하는 방법을 보여줍니다.
7.3. 컨테이너 레지스트리에 대한 인증 링크 복사링크가 클립보드에 복사되었습니다!
이미지를 프라이빗 컨테이너 레지스트리로 내보내려면 해당 네임스페이스에 보안을 정의한 다음 Build 사용자 정의 리소스(CR)에서 참조해야 합니다.
프로세스
다음 명령을 실행하여 보안을 생성합니다.
oc --namespace <namespace> create secret docker-registry <container_registry_secret_name> \ --docker-server=<registry_host> \ --docker-username=<username> \ --docker-password=<password> \ --docker-email=<email_address>
$ oc --namespace <namespace> create secret docker-registry <container_registry_secret_name> \ --docker-server=<registry_host> \1 --docker-username=<username> \2 --docker-password=<password> \3 --docker-email=<email_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보안에 주석을 답니다.
oc --namespace <namespace> annotate secrets <container_registry_secret_name> build.shipwright.io/referenced.secret='true'
$ oc --namespace <namespace> annotate secrets <container_registry_secret_name> build.shipwright.io/referenced.secret='true'Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.output.pushSecret필드의 값을BuildCR의 보안 이름으로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. 역할 기반 액세스 제어 링크 복사링크가 클립보드에 복사되었습니다!
릴리스 배포 YAML 파일에는 OpenShift Builds 오브젝트를 사용하기 위한 두 가지 클러스터 전체 역할이 포함되어 있습니다. 기본적으로 다음 역할이 설치됩니다.
-
shpwright-build-aggregate-view:BuildStrategy ,ClusterBuildStrategy,BuildRun과 같은 OpenShift Builds 리소스에 대한 읽기 액세스 권한을 부여합니다. 이 역할은 Kubernetes뷰역할에 집계됩니다. -
shipwright-build-aggregate-edit: 네임스페이스 수준에서 구성된 OpenShift 빌드 리소스에 대한 액세스 권한을 작성합니다. 빌드 리소스에는BuildStrategy,Build,BuildRun이 포함됩니다. 모든ClusterBuildStrategy리소스에 읽기 액세스 권한이 부여됩니다. 이 역할은 Kubernetesedit및admin역할에 집계됩니다.
클러스터 관리자만 ClusterBuildStrategy 리소스에 대한 쓰기 액세스 권한이 있습니다. 이러한 권한으로 별도의 Kubernetes ClusterRole 역할을 생성하고 해당 역할을 적절한 사용자에게 바인딩하여 이 설정을 변경할 수 있습니다.
8장. 빌드 컨트롤러 관찰 기능 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift 빌드에서는 빌드 리소스의 성능 및 기능을 모니터링하는 데 도움이 되는 여러 메트릭을 노출합니다. 빌드 컨트롤러 메트릭은 포트 8383 에 노출됩니다.
OpenShift 빌드에서는 빌드 컨트롤러에서 pprof 모드를 활성화하는 프로파일링 기능도 제공합니다.
8.1. 빌드 컨트롤러 메트릭 링크 복사링크가 클립보드에 복사되었습니다!
모니터링 목적으로 다음 빌드 컨트롤러 메트릭을 확인할 수 있습니다.
| 이름 | 유형 | 설명 | 라벨 | 상태 |
|---|---|---|---|---|
|
| 카운터 | 전체 등록된 빌드 수입니다. |
| 실험적 |
|
| 카운터 | 전체 완료된 빌드 실행 수입니다. |
| 실험적 |
|
| 히스토그램 | 빌드 실행 시 지속 시간을 초 단위로 설정합니다. |
| 실험적 |
|
| 히스토그램 | 빌드 실행 완료 기간(초)입니다. |
| 실험적 |
|
| 히스토그램 | 빌드는 초 단위의 ramp-up 기간을 실행합니다. |
| 실험적 |
|
| 히스토그램 | 작업 실행에 대한 빌드 실행 기간(초)입니다. |
| 실험적 |
|
| 히스토그램 | 작업 실행 Pod의 빌드 실행 시간(초)입니다. |
| 실험적 |
8.1.1. 히스토그램 메트릭 링크 복사링크가 클립보드에 복사되었습니다!
빌드 컨트롤러에 사용자 정의 버킷을 사용하려면 특정 히스토그램 지표에 대한 환경 변수를 설정해야 합니다. 다음 표에서는 모든 히스토그램 메트릭에 대한 환경 변수를 보여줍니다.
| 메트릭 | 환경 변수 | Default |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
8.1.2. 히스토그램 버킷 구성 링크 복사링크가 클립보드에 복사되었습니다!
빌드 컨트롤러의 경우 환경 변수 값을 설정하여 히스토그램 버킷을 구성할 수 있습니다. 빌드 컨트롤러를 로컬에서 실행할 때 환경 변수 값을 시작하기 직전에 설정합니다.
OpenShift Container Platform 클러스터에 빌드 컨트롤러를 배포할 때 controller.yaml 배포 파일에 환경 변수를 추가해야 합니다. 환경 변수 값은 쉼표로 구분된 숫자 목록이어야 합니다.
프로세스
다음 예와 같이
controller.yaml배포 파일의spec.containers[0].spec.env섹션에 환경 변수의 항목을 추가합니다.# ... env: - name: PROMETHEUS_BR_COMP_DUR_BUCKETS value: "30,60,90,120,180,240,300,360,420,480" # ...# ... env: - name: PROMETHEUS_BR_COMP_DUR_BUCKETS value: "30,60,90,120,180,240,300,360,420,480" # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.1.3. 메트릭 라벨 구성 링크 복사링크가 클립보드에 복사되었습니다!
PROMETHEUS_ENABLED_LABELS 환경 변수를 구성하여 사용할 메트릭 레이블을 활성화할 수 있습니다. 지원되는 지표 라벨은 다음과 같습니다.
-
buildstrategy -
네임스페이스 -
Build -
buildrun
OpenShift Container Platform 클러스터에 빌드 컨트롤러를 배포할 때 controller.yaml 배포 파일에 환경 변수를 추가해야 합니다. 쉼표로 구분된 값 목록을 사용하여 mutiple 메트릭 레이블을 활성화할 수도 있습니다.
프로세스
단일 메트릭 레이블을 활성화하려면
controller.yaml배포 파일의spec.containers[0].spec.env섹션에 다음 항목을 추가합니다.# ... env: - name: PROMETHEUS_ENABLED_LABELS value: namespace # ...# ... env: - name: PROMETHEUS_ENABLED_LABELS value: namespace # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 여러 메트릭 레이블을 활성화하려면
controller.yaml배포 파일의spec.containers[0].spec.env섹션에 다음 항목을 추가합니다.# ... env: - name: PROMETHEUS_ENABLED_LABELS value: buildstrategy,namespace,build # ...# ... env: - name: PROMETHEUS_ENABLED_LABELS value: buildstrategy,namespace,build # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2. 빌드 컨트롤러 프로파일링 링크 복사링크가 클립보드에 복사되었습니다!
빌드 컨트롤러는 기본적으로 바이너리에서 생략된 pprof 프로파일링 모드를 지원합니다. 프로파일링 기능을 사용하려면 pprof 모드가 활성화된 빌드 컨트롤러 이미지를 사용합니다.
8.2.1. 빌드 컨트롤러에서 pprof 모드 활성화 링크 복사링크가 클립보드에 복사되었습니다!
pprof 모드를 활성화하려면 openshift-builds-controller 배포 파일을 편집하여 디버그 접미사와 함께 컨테이너 태그를 사용합니다.
프로세스
다음 명령을 실행하여 모드를 활성화합니다.
oc --namespace <namespace> set image \ deployment/openshift-builds-controller \ openshift-builds="$(oc --namespace <namespace> get deployment openshift-builds-controller --output jsonpath='{.spec.template.spec.containers[].image}')-debug"$ oc --namespace <namespace> set image \ deployment/openshift-builds-controller \ openshift-builds="$(oc --namespace <namespace> get deployment openshift-builds-controller --output jsonpath='{.spec.template.spec.containers[].image}')-debug"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9장. OpenShift 빌드 설치 제거 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Red Hat OpenShift Builds Operator를 설치 제거할 수 있습니다. Operator를 설치 제거해도 CR(사용자 정의 리소스) 및 OpenShift 빌드 구성 요소가 자동으로 제거되지 않습니다.
Red Hat OpenShift Builds Operator를 설치 제거하려면 다음 작업을 수행합니다.
Operator를 설치할 때 기본적으로 생성된 CR(사용자 정의 리소스)을 삭제합니다.
참고CR을 제거하지 않고 Operator를 설치 제거하는 경우 나중에 제거할 수 없습니다.
- Operator를 설치 제거합니다.
9.1. OpenShift 빌드 구성 요소 및 사용자 정의 리소스 삭제 링크 복사링크가 클립보드에 복사되었습니다!
Operator를 설치하는 동안 기본적으로 생성된 CR(사용자 정의 리소스)을 삭제합니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.
프로세스
- 웹 콘솔의 관리자 화면에서 Administration → Custom Resource Definition로 이동합니다.
-
이름으로 필터링 상자에
operator.shipwright.io를 입력하여 Red Hat OpenShift Builds Operator CR을 검색합니다. - CRD Config을 클릭하여 Custom Resource Definition Details 페이지를 엽니다.
작업 드롭다운 목록을 클릭하고 사용자 정의 리소스 정의 삭제 를 선택합니다.
참고CR을 삭제하면 OpenShift 빌드 컨트롤러와 클러스터의 모든 관련 구성 요소 및 작업이 삭제됩니다.
- Delete 를 클릭하여 CR 삭제를 확인합니다.
9.2. Red Hat OpenShift Builds Operator 설치 제거 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔의 관리자 화면을 사용하여 Red Hat OpenShift Builds Operator를 설치 제거할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.
프로세스
- Operators → OperatorHub로 이동합니다.
- OperatorHub 페이지에서 키워드로 필터링 상자를 사용하여 Red Hat OpenShift Builds Operator를 검색합니다.
- Red Hat OpenShift Builds Operator 타일을 클릭합니다. Operator 타일은 Operator가 설치되었음을 나타냅니다.
- Red Hat OpenShift Builds Operator 설명 페이지에서 설치 제거를 클릭합니다.
Legal Notice
링크 복사링크가 클립보드에 복사되었습니다!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman 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 Software Collections 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.