OpenShift 빌드 정보


Red Hat OpenShift Builds 1.0

OpenShift 빌드 소개

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift 빌드 기능 및 사용자 정의 리소스에 대한 개요를 제공합니다. 또한 릴리스 노트와 지원을 받는 방법에 대한 세부 사항이 포함되어 있습니다.

1장. Red Hat OpenShift 빌드 개요

Red Hat OpenShift 빌드는 OpenShift Container Platform 클러스터에서 컨테이너 이미지를 빌드하는 데 사용할 수 있는 확장 가능한 프레임워크입니다. 프레임워크는 source-to-image, Cloud Native Buildpacks, Buildah 등과 같은 툴을 지원하며 다음 4가지 요소를 기반으로 합니다.

소스 코드
빌드할 소스 코드를 정의합니다.
출력 이미지
애플리케이션 이미지를 내보낼 위치 정의
빌드 전략
애플리케이션을 어셈블할 전략을 정의합니다.
호출
애플리케이션을 빌드하려는 시간을 정의합니다.

Red Hat OpenShift 빌드는 다음 CR(사용자 정의 리소스)으로 구성됩니다.

  • Build
  • BuildStrategyClusterBuildStrategy
  • BuildRun

OpenShift 빌드는 Kubernetes 플랫폼에서 컨테이너 이미지를 빌드하는 프레임워크를 제공하는 오픈 소스 shipwright 프로젝트를 기반으로 합니다.

1.1. 빌드 리소스

Build 리소스는 애플리케이션의 소스 코드와 애플리케이션 이미지를 내보낼 위치를 정의합니다. 다음 예제에서는 Git 소스, 빌드 전략 및 출력 이미지로 구성된 간단한 빌드를 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://github.com/username/taxi
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
    image: registry.mycompany.com/my-org/taxi-app:latest
Copy to Clipboard Toggle word wrap

Build 리소스를 확장하여 이미지를 프라이빗 레지스트리로 내보내거나 .podman 파일을 사용할 수도 있습니다.

1.2. BuildStrategy 및 ClusterBuildStrategy 리소스

BuildStrategyClusterBuildStrategy 리소스는 애플리케이션을 어셈블하기 위한 일련의 단계를 정의합니다. 네임스페이스 및 클러스터 내의 Cluster BuildStrategy 리소스 내에서 BuildStrategy 리소스를 사용할 수 있습니다.

BuildStrategy 또는 ClusterBuildStrategy 리소스의 사양은 steps 오브젝트로 구성됩니다. 다음 예제에서는 buildpacks v3 클러스터 빌드 전략의 사양을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: buildpacks-v3
spec:
  steps:
    - name: build-and-push
      image: docker.io/paketobuildpacks/builder-full:latest
      env:
        - name: CNB_PLATFORM_API
          value: $(params.platform-api-version)
        - name: PARAM_SOURCE_CONTEXT
          value: $(params.shp-source-context)
        - name: PARAM_OUTPUT_IMAGE
          value: $(params.shp-output-image)
      command:
        - /bin/bash
# ...
Copy to Clipboard Toggle word wrap

1.3. buildrun 리소스

BuildRun 리소스는 클러스터 작업 또는 Tekton 작업 실행과 유사하게 클러스터에서 빌드를 호출합니다. BuildRun 리소스는 클러스터의 워크로드를 표시하여 실행 중인 Pod를 생성합니다. BuildRun 은 실행 중인 빌드 인스턴스입니다. 클러스터에서 특정 매개변수를 사용하여 실행할 빌드를 인스턴스화합니다.

BuildRun 리소스는 다음 요소를 정의하는 데 도움이 됩니다.

  • 빌드 상태를 모니터링할 고유한 BuildRun 이름
  • 빌드 중 사용할 참조된 Build 인스턴스
  • 빌드의 모든 보안을 호스팅하는 서비스 계정

BuildRun 리소스는 네임스페이스 내에서 사용할 수 있습니다.

1.4. 빌드 컨트롤러

빌드 컨트롤러는 Build 리소스의 업데이트를 모니터링하고 다음 작업을 수행합니다.

  • 참조된 StrategyRef 오브젝트가 Build 리소스에 있는지 확인합니다.
  • Build CR에서 지정된 매개변수가 참조된 빌드 전략에 있는지 확인합니다. 매개변수 이름이 예약된 이름과 충돌하는지도 확인합니다.
  • Build 리소스에 컨테이너 레지스트리 출력 시크릿이 있는지 확인합니다.
  • 참조된 spec.source.git.url 끝점 URL이 Build 리소스에 있는지 확인합니다.

빌드 실행 컨트롤러는 Build 또는 TaskRun 리소스의 업데이트를 모니터링하고 다음 작업을 수행합니다.

  • 기존 TaskRun 리소스를 검색하고 상위 BuildRun 리소스 상태를 업데이트합니다.
  • 지정된 서비스 계정을 검색하고 Build 리소스의 출력 보안과 함께 설정합니다.
  • TaskRun 리소스가 없는 경우 컨트롤러는 새 Tekton TaskRun 리소스를 생성하고 TaskRun 리소스에 대한 참조를 설정합니다.
  • TaskRun 리소스의 후속 업데이트의 경우 컨트롤러는 상위 BuildRun 리소스를 업데이트합니다.

1.4.1. 빌드 검증

잘못된 종속성 또는 구성 설정으로 인해 실패하는 BuildRun 리소스를 트리거하지 않으려면 빌드 컨트롤러에서 미리 유효성을 검사합니다. 모든 검증이 성공하면 Succeeded 라는 status.reason 필드를 볼 수 있습니다. 그러나 검증이 실패하는 경우 status.reasonstatus.message 필드를 확인하여 근본 원인을 파악해야 합니다.

Expand
표 1.1. 빌드 컨트롤러의 빌드 검증
status.reason 필드설명

BuildStrategyNotFound

네임스페이스 수준에서 참조된 전략이 존재하지 않습니다.

ClusterBuildStrategyNotFound

클러스터 수준에서 참조된 전략이 존재하지 않습니다.

SetOwnerReferenceFailed

BuildBuildRun 리소스 간의 소유자 참조를 설정하지 못했습니다. 이 상태는 빌드에서 spec.retention.atBuildDeletion 필드를 true 로 설정할 때 트리거됩니다.

SpecSourceSecretRefNotFound

Git에 인증하는 데 사용되는 시크릿은 존재하지 않습니다.

SpecOutputSecretRefNotFound

컨테이너 레지스트리에 인증하는 데 사용되는 시크릿은 존재하지 않습니다.

SpecBuilderSecretRefNotFound

컨테이너 레지스트리에 인증하는 데 사용되는 시크릿은 존재하지 않습니다.

MultipleSecretRefNotFound

인증에 사용되는 여러 보안이 누락되어 있습니다.

RestrictedParametersInUse

하나 이상의 정의된 params 는 예약된 매개변수와 함께 배치됩니다.

정의되지 않음 매개변수

매개변수는 참조된 전략에 정의되지 않습니다. 해당 매개변수를 전략의 spec.parameters 사양에 정의해야 합니다.

RemoteRepositoryUnreachable

정의된 spec.source.git.url 사양을 찾을 수 없습니다. 이 검증은 HTTP 및 HTTPS 프로토콜에서만 수행됩니다.

BuildNameInvalid

metadata.name 필드의 빌드 이름이 유효하지 않습니다. 빌드 이름에 유효한 라벨 값을 사용해야 합니다.

SpecEnvNameCanNotBeBlank

사용자 제공 환경 변수의 이름이 비어 있음을 나타냅니다.

SpecEnvValueCanNotBeBlank

사용자 제공 환경 변수의 값이 비어 있음을 나타냅니다.

1.4.2. 컨트롤러 설정

컨트롤러는 OpenShift Container Platform 클러스터에 몇 가지 기본값이 있습니다. 그러나 controller.yaml 파일에 정의된 환경 변수를 사용하여 몇 가지 컨트롤러 설정을 설정하거나 수정할 수 있습니다. 다음 환경 변수를 사용할 수 있습니다.

Expand
표 1.2. 컨트롤러 설정
환경 변수설명

CTX_TIMEOUT

모든 사용자 정의 리소스 정의 조정 작업에 사용되는 기본 컨텍스트 시간 초과를 재정의합니다. 기본값은 5 초입니다.

REMOTE_ARTIFACTS_CONTAINER_IMAGE

.spec.sources 원격 아티팩트 다운로드에 사용되는 컨테이너 이미지를 지정합니다. 기본적으로 환경 변수는 quay.io/quay/busybox:latest 컨테이너 이미지를 사용합니다.

TERMINATION_LOG_PATH

종료 로그의 경로를 나타냅니다. 기본값은 /dev/termination-log 입니다.

GIT_ENABLE_REWRITE_RULE

Git 래퍼를 활성화하여 해당 소스 호스트 이름에 대해 대신 Git 구성 재작성 규칙 URL을 설정합니다. 기본값은 false입니다.

GIT_CONTAINER_TEMPLATE

Git 리포지토리를 복제하는 단계에 사용되는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 {"image": "ghcr.io/shipwright-io/build/git:latest", "command": ["/ko-app/git"], "env": [{"name": "HOME", "value": "/shared-home"}, "securityContext":{"allowPrivilegeEscalation": false, "securityContext":{"입니다. "capabilities": {"drop": ["ALL"]}, "runAsUser": 1000,"runAsGroup": 1000}}. argsname 속성은 빌드 컨트롤러에서 설정하므로 무시됩니다.

GIT_CONTAINER_IMAGE

Git 복제 단계를 위한 사용자 정의 컨테이너 이미지를 나타냅니다. GIT_CONTAINER_TEMPLATEGIT_CONTAINER_IMAGE 변수가 모두 이미지를 지정하는 경우 GIT_CONTAINER_IMAGE 변수에 지정된 이미지가 우선합니다.

BUNDLE_IMAGE_CONTAINER_TEMPLATE

패키지 소스 코드를 가져오기 위해 번들 이미지를 가져오는 단계에 사용되는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 {"image": "ghcr.io/shipwright-io/build/bundle:latest", "command": ["/ko-app/bundle"], "env": [{"name": "HOME","value": "/shared-home"}], "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser":1000,"runAsGroup":1000}}. argsname 속성은 빌드 컨트롤러에서 설정하므로 무시됩니다.

BUNDLE_IMAGE_CONTAINER_IMAGE

패키지된 소스 코드를 가져오기 위해 번들 이미지를 가져오는 사용자 지정 컨테이너 이미지를 나타냅니다. BUNDLE_IMAGE_CONTAINER_TEMPLATEBUNDLE_IMAGE_CONTAINER_IMAGE 변수가 모두 이미지를 지정하는 경우 BUNDLE_IMAGE_CONTAINER_IMAGE 변수에 지정된 이미지가 우선합니다.

IMAGE_PROCESSING_CONTAINER_TEMPLATE

이미지를 처리하는 단계에 사용되는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 {"image": "ghcr.io/shipwright-io/build/image-processing:latest", "command": ["/ko-app/image-processing"], "env": [{"name": "HOME"": "/shared-home"}, "securityContext": {"allowPrivilegeEscalation": false입니다. "capabilities": {"add": ["DAC_OVERRIDE"], "drop": ["ALL"]}, "runAsUser": 0, "runAsgGroup": 0}}. argsname 속성은 빌드 컨트롤러에서 설정하므로 무시됩니다.

IMAGE_PROCESSING_CONTAINER_IMAGE

이미지를 처리하는 단계에 사용되는 사용자 지정 컨테이너 이미지를 나타냅니다. IMAGE_PROCESSING_CONTAINER_TEMPLATEIMAGE_PROCESSING_CONTAINER_IMAGE 변수가 모두 이미지를 지정하는 경우 IMAGE_PROCESSING_CONTAINER_IMAGE 변수에 지정된 이미지가 우선합니다.

WAITER_IMAGE_CONTAINER_TEMPLATE

로컬 소스 코드가 업로드될 때까지 대기하는 컨테이너 템플릿의 JSON 표시를 나타냅니다. 기본값은 {"image":"ghcr.io/shipwright-io/build/waiter:latest", "command": ["/ko-app/waiter"], "args": ["start"], "env": [{"name": "HOME"": "HOME"": "/shared-home"}]입니다. "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser":1000,"runAsGroup":1000}}. argsname 속성은 빌드 컨트롤러에서 설정하므로 무시됩니다.

WAITER_IMAGE_CONTAINER_IMAGE

로컬 소스 코드가 업로드될 때까지 대기하는 사용자 지정 컨테이너 이미지를 나타냅니다. WAITER_IMAGE_CONTAINER_TEMPLATEWAITER_IMAGE_CONTAINER_IMAGE 변수가 모두 이미지를 지정하는 경우 WAITER_IMAGE_CONTAINER_IMAGE 변수에 지정된 이미지가 우선합니다.

BUILD_CONTROLLER_LEADER_ELECTION_NAMESPACE

shipwright-build-controller 잠금을 저장하는 데 사용되는 네임스페이스를 설정합니다. 기본적으로 잠금은 빌드 컨트롤러와 동일한 네임스페이스에 있습니다.

BUILD_CONTROLLER_LEASE_DURATION

컨트롤러 작업을 강제로 인수하기 전에 컨트롤러가 아닌 노드의 대기 기간인 LeaseDuration 필드를 재정의합니다.

BUILD_CONTROLLER_RENEW_DEADLINE

작동 중인 컨트롤러 노드가 컨트롤러 작업을 다시 설정하는 기간인 RenewDeadline 필드를 재정의합니다.

BUILD_CONTROLLER_RETRY_PERIOD

새 컨트롤러를 선택하기 전에 컨트롤러 선택기 노드가 대기하는 기간인 RetryPeriod 필드를 재정의합니다.

BUILD_MAX_CONCURRENT_RECONCILES

빌드 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 0입니다.

BUILDRUN_MAX_CONCURRENT_RECONCILES

빌드 실행 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 0입니다.

BUILDSTRATEGY_MAX_CONCURRENT_RECONCILES

빌드 전략 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 0입니다.

CLUSTERBUILDSTRATEGY_MAX_CONCURRENT_RECONCILES

클러스터 빌드 전략 컨트롤러의 동시 조정 수를 나타냅니다. 기본값은 0입니다.

KUBE_API_BURST

Kubernetes API 클라이언트에 사용할 버스트를 나타냅니다. 기본값은 0입니다.

KUBE_API_QPS

Kubernetes API 클라이언트에 사용할 QPS를 나타냅니다. 기본값은 0입니다.

2장. OpenShift 빌드 설치

클러스터 관리자는 OpenShift Container Platform 클러스터에 Red Hat OpenShift 빌드를 설치할 수 있습니다.

2.1. 사전 요구 사항

  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
  • oc CLI를 설치했습니다.
  • OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.
  • 클러스터에 Marketplace 기능이 활성화되어 있거나 Red Hat Operator 카탈로그 소스가 수동으로 구성되어 있습니다.

2.2. 콘솔을 사용하여 OpenShift 빌드 설치

OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 Red Hat OpenShift Builds Operator를 설치할 수 있습니다. 이 Operator를 설치하면 빌드 구성 요소를 설치하고 사용할 수 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 OperatorOperatorHub 페이지로 이동합니다.
  2. 키워드로 필터링 상자를 사용하여 카탈로그에서 Red Hat OpenShift Builds Operator를 검색합니다.
  3. Red Hat OpenShift Builds Operator 타일을 클릭합니다.
  4. Operator에 대한 간략한 설명을 읽고 설치를 클릭합니다.
  5. Operator 설치 페이지에서 다음을 수행합니다.

    1. 설치 모드가 클러스터의 모든 네임스페이스(기본값) 로 설정되어 있는지 확인합니다. 이 모드는 기본 openshift-operators 네임스페이스에 Operator를 설치하여 클러스터의 모든 네임스페이스를 감시하고 사용할 수 있도록 합니다.
    2. 설치된 네임스페이스 가 기본적으로 openshift-operators 로 설정되어 있는지 확인합니다.
    3. Approval Strategy으로 Automatic을 선택합니다. 그러면 Operator에 향후 지원되는 업그레이드가 OLM(Operator Lifecycle Manager)에 의해 자동으로 처리됩니다. Manual 승인 전략을 선택하면 OLM에서 업데이트 요청을 생성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.
    4. 채널 업데이트 선택:

      • 업데이트 채널은 기본적으로 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 채널을 사용할 수 있습니다.
  6. 설치를 클릭합니다.

검증

  • 설치된 Operator 페이지에서 Red Hat OpenShift Builds Operator가 나열되고 설치가 성공으로 설정되어 있는지 확인합니다.

2.2.1. 콘솔을 사용하여 shipwrightBuild 리소스 생성

Red Hat OpenShift Builds Operator를 설치한 후 빌드 컨트롤러의 기능을 활성화하려면 shipwrightBuild 리소스를 생성해야 합니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator → 설치된 Operator 페이지로 이동합니다.
  2. 목록에 있는 Red Hat OpenShift Builds Operator 링크를 클릭합니다. Operator 세부 정보 페이지가 열립니다.
  3. shipwright Build 탭을 선택하고 Create ShipwrightBuild 를 클릭합니다.
  4. 양식 보기 또는 YAML 보기를 선택하여 다음과 같은 방식으로 새 ShipwrightBuild 리소스를 구성합니다.

    • 양식 보기 또는 YAML 보기를 선택하면 nametargetNamespace 필드에 대해 구성된 기본값이 표시됩니다. 해당 필드를 편집하지 않으려면 생성 을 클릭하여 shipwrightBuild 리소스를 기본값으로 구성합니다.

      생성된 리소스를 shipwright Build 탭에서 볼 수 있습니다.

검증

  • 컨트롤러 Pod가 언급된 대상 네임스페이스에 생성되어 있어야 합니다.

2.3. CLI를 사용하여 OpenShift 빌드 설치

CLI를 사용하여 Red Hat OpenShift 빌드도 설치할 수 있습니다.

프로세스

  1. 다음 예와 같이 하위.yaml 서브스크립션 오브젝트 파일을 생성하여 Red Hat OpenShift Builds Operator에 네임스페이스를 등록합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-builds-operator
      namespace: openshift-operators
    spec:
      channel: <channel-name> 
    1
    
      name: openshift-builds-operator 
    2
    
      source: redhat-operators 
    3
    
      sourceNamespace: openshift-marketplace 
    4
    Copy to Clipboard Toggle word wrap
    1
    Operator를 서브스크립션할 채널 이름입니다.
    2
    등록할 Operator의 이름입니다.
    3
    Operator를 제공하는 CatalogSource의 이름입니다.
    4
    CatalogSource의 네임스페이스입니다. 기본 OperatorHub CatalogSources에는 openshift-marketplace를 사용합니다.
  2. 다음 명령을 실행하여 서브스크립션 오브젝트를 적용합니다.

    $ oc apply -f sub.yml
    Copy to Clipboard Toggle word wrap

    이제 Red Hat OpenShift Builds Operator가 기본 대상 네임스페이스 openshift-operators 에 설치됩니다.

2.3.1. CLI를 사용하여 shipwrightBuild 리소스 생성

Red Hat OpenShift Builds Operator를 설치한 후 빌드 컨트롤러의 기능을 활성화하려면 shipwrightBuild 리소스를 생성해야 합니다.

프로세스

  1. 다음 예와 같이 instance.yaml 파일을 생성하여 shipwright-builds 네임스페이스에 shipwrightBuild 리소스를 생성합니다.

    apiVersion: operator.shipwright.io/v1beta1
    kind: ShipwrightBuild
    metadata:
      name: shipwright-build
    spec:
      targetNamespace: shipwright-builds
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 YAML 파일을 적용합니다.

    $ oc apply -f instance.yaml
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 shipwrightBuild 리소스가 이제 구성되었는지 확인합니다.

    $ oc get pods -n shipwright-builds
    Copy to Clipboard Toggle word wrap

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-v3source-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: 이 클러스터 빌드 전략에는 추가 처리 없이 이미지를 대상 리포지토리로 내보내는 단계가 포함되어 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • buildah 전략을 설치하려면 요구 사항에 따라 다음 명령 중 하나 이상을 실행합니다.

    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildah/buildstrategy_buildah_strategy_managed_push_cr.yaml
    Copy to Clipboard Toggle word wrap
    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml
    Copy to Clipboard Toggle word wrap

3.2. Buildpacks v3

CCNB(Cloud Native Builder) 컨테이너 이미지를 기반으로 하는 buildpacks v3 전략을 사용할 수 있습니다(예:oeku /buildpacks:18cloudfoundry/cnb:bionic ).

3.2.1. buildpacks v3 전략 설치

namepsace 또는 클러스터 수준에서 buildpacks v3 전략을 설치할 수 있습니다. 클러스터 수준에 설치하여 클러스터 내의 다른 네임스페이스에서 buildpacks v3 전략을 공유할 수 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • 클러스터 수준에서 buildpacks v3 전략을 설치하려면 다음 명령을 실행합니다.

    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_cr.yaml
    Copy to Clipboard Toggle word wrap
  • 네임스페이스 수준에서 buildpacks v3 전략을 설치하려면 다음 명령을 실행합니다.

    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_namespaced_cr.yaml
    Copy to Clipboard Toggle word wrap

3.3. Kaniko

kaniko 클러스터 빌드 전략을 사용하여 컨테이너 파일 또는 컨텍스트 디렉터리에서 컨테이너 이미지를 빌드할 수 있습니다. kaniko-trivy 클러스터 빌드 전략을 사용하여 Trivy 보안 스캐너로 컨테이너 이미지를 검사할 수도 있습니다. 스캐너가 이미지에서 중요한 취약점을 발견하면 BuildRun 리소스는 오류와 함께 종료되고 취약한 이미지를 컨테이너 레지스트리로 내보내지 않습니다.

참고

이미지 검사를 수행해도 빌드 중인 컨테이너 파일을 신뢰할 수 있는 것은 아닙니다. 빌드하려는 코드를 보호하려면 buildpacks v3 또는 source-to-image 빌드 전략을 사용해야 합니다.

3.3.1. kaniko 전략 설치

클러스터 수준에서 kaniko 전략을 설치할 수 있습니다. 클러스터 수준에 설치하여 클러스터 내의 다른 네임스페이스에서 kaniko 전략을 공유할 수 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • 클러스터 수준에서 kaniko 전략을 설치하려면 다음 명령을 실행합니다.

    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/kaniko/buildstrategy_kaniko_cr.yaml
    Copy to Clipboard Toggle word wrap
  • 클러스터 수준에서 kaniko-trivy 전략을 설치하려면 다음 명령을 실행합니다.

    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/kaniko/buildstrategy_kaniko-trivy_cr.yaml
    Copy to Clipboard Toggle word wrap

3.4. buildkit

buildctl 클라이언트 및 buildkit d 데몬으로 구성된 buildkit 클러스터 빌드 전략을 사용할 수 있습니다. 이 전략은 클라이언트와 데몬이 모두 단일 컨테이너에서 실행되는 데몬리스 모드에서 실행됩니다. 권한 없이 전략을 실행할 수 있습니다.

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 클러스터 빌드 전략에서는 제한되지 않은 프로필을 사용하여 AppArmorSecComp 보안 매개변수를 비활성화합니다.

3.4.5. Pod 보안 표준이 있는 클러스터에서 사용

buildkit 전략에서 Pod 보안 관련 필드를 구성할 수 있습니다. 클러스터 설정 및 관리 구성에 따라 다음 설정을 사용할 수 있습니다.

  • 기본 rootlesskit 패키지에 필요한 대로 AppArmorseccomp 매개변수 모두에 대해 제한되지 않은 프로필을 정의합니다.
  • 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 전략을 공유할 수 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • 클러스터 수준에서 buildkit 전략을 설치하려면 다음 명령을 실행합니다.

    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml
    Copy to Clipboard Toggle word wrap

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 전략을 공유할 수 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • 클러스터 수준에서 ko 전략을 설치하려면 다음 명령을 실행합니다.

    $ oc apply -f https://raw.githubusercontent.com/shipwright-io/build/main/samples/buildstrategy/ko/buildstrategy_ko_cr.yaml
    Copy to Clipboard Toggle word wrap

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 ) 전략을 공유할 수 있습니다.

사전 요구 사항

  • oc CLI를 설치했습니다.

프로세스

  • 클러스터 수준에서 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
    Copy to Clipboard Toggle word wrap

4장. OpenShift 빌드 구성

Build CR(사용자 정의 리소스)을 사용하면 빌드를 구성하기 위해 소스, 빌드 전략, 매개변수 값, 빌더 또는 Docker 파일, 출력, 보존 매개변수 및 볼륨을 정의하는 데 도움이 됩니다. 빌드 리소스는 네임스페이스 내에서 사용할 수 있습니다.

빌드를 구성하려면 Build 리소스 YAML 파일을 생성하여 OpenShift Container Platform 클러스터에 적용합니다.

4.1. 빌드의 구성 가능한 필드

Build 사용자 정의 리소스(CR)에서 다음 필드를 사용할 수 있습니다.

Expand
표 4.1. Build CR의 필드
필드presence설명

apiVersion

필수 항목

리소스의 API 버전을 지정합니다(예: shipwright.io/v1beta1 ).

kind

필수 항목

리소스 유형을 지정합니다(예: Build ).

메타데이터

필수 항목

Build 리소스의 이름과 같이 사용자 정의 리소스 정의 인스턴스를 식별하는 메타데이터를 나타냅니다.

spec.source

필수 항목

소스 코드의 위치(예: Git 리포지토리 또는 소스 번들 이미지)를 나타냅니다.

spec.strategy

필수 항목

Build 리소스에 사용되는 전략의 이름과 유형을 나타냅니다.

spec.output

필수 항목

생성된 이미지를 내보낼 위치를 나타냅니다.

spec.output.pushSecret

필수 항목

컨테이너 레지스트리에 액세스하기 위한 기존 시크릿을 나타냅니다.

spec.paramValues

선택 사항

빌드 전략에 정의된 매개변수 값을 지정하는 name-value 목록을 나타냅니다.

spec.timeout

선택 사항

사용자 정의 시간 초과를 정의합니다. 기본값은 10분입니다. BuildRun 리소스에서 이 필드 값을 덮어쓸 수 있습니다.

spec.output.annotations

선택 사항

출력 이미지에 주석을 달 때 사용할 수 있는 키-값 쌍 목록을 나타냅니다.

spec.output.labels

선택 사항

출력 이미지에 레이블을 지정하는 데 사용할 수 있는 키-값 쌍 목록을 나타냅니다.

spec.env

선택 사항

빌드 컨테이너에 전달할 수 있는 추가 환경 변수를 정의합니다. 사용 가능한 변수는 빌드 전략에서 사용하는 도구에 따라 달라집니다.

spec.retention.ttlAfterFailed

선택 사항

실패한 빌드 실행이 존재할 수 있는 기간을 지정합니다.

spec.retention.ttlAfterSucceeded

선택 사항

성공적인 빌드 실행이 존재할 수 있는 기간을 지정합니다.

spec.retention.failedLimit

선택 사항

존재할 수 있는 실패한 빌드 실행 수를 지정합니다.

spec.retention.succeededLimit

선택 사항

존재할 수 있는 성공적인 빌드 실행 수를 지정합니다.

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 로 설정합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
  annotations:
    build.shipwright.io/verify.repository: "true"
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-go
    contextDir: docker-build
Copy to Clipboard Toggle word wrap

빌드 컨트롤러는 다음 시나리오에서 Git 리포지토리가 있는지 확인합니다.

  • HTTP 또는 HTTPS 프로토콜과 함께 끝점 URL을 사용하는 경우
  • git@ 과 같은 SSH 프로토콜을 정의했지만 참조된 보안(예: source.git.cloneSecret )이 정의되어 있지 않은 경우입니다.

다음 예제에서는 다양한 소스 입력 세트를 사용하여 빌드를 구성하는 방법을 보여줍니다.

예: 인증 정보를 사용하여 빌드 구성

다음 예와 같이 인증 정보를 지정하여 소스로 빌드를 구성할 수 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildpack-nodejs-build
spec:
  source:
    git:
      url: https://github.com/sclorg/nodejs-ex
      cloneSecret: source-repository-credentials
Copy to Clipboard Toggle word wrap

예: 컨텍스트 경로를 사용하여 빌드 구성

다음 예와 같이 Git 리포지토리에서 컨텍스트 경로를 지정하는 소스로 빌드를 구성할 수 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-custom-context-dockerfile
spec:
  source:
    git:
      url: https://github.com/userjohn/npm-simple
    contextDir: docker-build
Copy to Clipboard Toggle word wrap

예: 태그를 사용하여 빌드 구성

다음 예와 같이 Git 리포지토리의 v.0.1.0 태그를 지정하는 소스로 빌드를 구성할 수 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-go
      revision: v0.1.0
Copy to Clipboard Toggle word wrap

예: 환경 변수를 사용하여 빌드 구성

다음 예와 같이 환경 변수를 지정하는 빌드를 구성할 수도 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-go
    contextDir: docker-build
  env:
    - name: <example_var_1>
      value: "<example_value_1>"
    - name: <example_var_2>
      value: "<example_value_2>"
Copy to Clipboard Toggle word wrap

4.3. 전략 정의

Build CR에서 빌드에 대한 전략을 구성할 수 있습니다. 다음 빌드 전략을 사용할 수 있습니다.

  • buildah
  • buildpacks-v3
  • source-to-image

빌드 전략을 구성하려면 다음 예와 같이 Build CR에서 spec.strategy.namespec.strategy.kind 필드를 정의합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildpack-nodejs-build
spec:
  strategy:
    name: buildpacks-v3
    kind: ClusterBuildStrategy
Copy to Clipboard Toggle word wrap

4.4. 빌드의 매개변수 값 정의

Build CR에서 빌드 전략 매개변수의 값을 지정할 수 있습니다. 매개변수 값을 지정하면 빌드 전략의 단계가 작동하는 방법을 제어할 수 있습니다. BuildRun 리소스의 값을 덮어쓸 수도 있습니다.

모든 매개변수의 경우 직접 또는 구성 맵 또는 시크릿의 참조 키를 사용하여 값을 지정해야 합니다.

참고

빌드 전략 단계에서 매개변수를 사용하면 구성 맵 및 시크릿 사용이 제한됩니다. 매개변수가 명령, 인수 또는 환경 변수에 사용되는 경우에만 구성 맵과 시크릿을 사용할 수 있습니다.

Build CR에서 paramValues 필드를 사용하는 경우 다음 시나리오를 사용하지 마십시오.

  • BuildStrategy CR에 정의된 spec.parameters 중 하나와 일치하지 않는 spec.paramValues 이름을 지정합니다.
  • shipwright 예약된 매개변수와 충돌하는 spec.paramValues 이름을 지정합니다. 이러한 매개변수에는 BUILDER_IMAGE,CONTEXT_DIRshp- 로 시작하는 모든 이름이 포함됩니다.

또한 Build CR에서 paramValues 필드를 정의하기 전에 전략의 내용을 이해해야 합니다.

4.4.1. 매개변수 값을 정의하는 구성 예

다음 예제에서는 빌드 전략에서 매개변수를 정의하고 Build CR을 사용하여 해당 매개변수에 값을 할당하는 방법을 보여줍니다. Build CR의 유형 배열 의 매개변수에 값을 할당할 수도 있습니다.

예: ClusterBuildStrategy CR의 매개변수 정의

다음 예제에서는 여러 매개변수를 정의하는 ClusterBuildStrategy CR을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: buildah
spec:
  parameters:
    - name: build-args
      description: "The values for the args in the Dockerfile. Values must be in the format KEY=VALUE."
      type: array
      defaults: []
    # ...
    - name: storage-driver
      description: "The storage driver to use, such as 'overlay' or 'vfs'."
      type: string
      default: "vfs"
# ...
steps:
# ...
Copy to Clipboard Toggle word wrap

예: Build CR에서 매개변수에 값 할당

위의 ClusterBuildStrategy CR은 storage-driver 매개변수를 정의하고 다음 예와 같이 Build CR에서 storage-driver 매개변수 값을 지정할 수 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: <your_build>
  namespace: <your_namespace>
spec:
  paramValues:
  - name: storage-driver
    value: "overlay"
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
  # ...
Copy to Clipboard Toggle word wrap

예: 중앙에서 매개변수를 제어하기 위해 ConfigMap CR 생성

여러 빌드에 storage-driver 매개변수를 사용하고 중앙에서 사용을 제어하려면 다음 예와 같이 ConfigMap CR을 생성할 수 있습니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: buildah-configuration
  namespace: <your_namespace>
data:
  storage-driver: overlay
Copy to Clipboard Toggle word wrap

다음 예와 같이 생성된 ConfigMap CR을 Build CR에서 매개변수 값으로 사용할 수 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: <your_build>
  namespace: <your_namespace>
spec:
  paramValues:
  - name: storage-driver
    configMapValue:
      name: buildah-configuration
      key: storage-driver
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
  # ...
Copy to Clipboard Toggle word wrap

예: Build CR에서 type 배열 의 매개변수에 값 할당

배열 형식의 매개 변수에 값을 할당할 수 있습니다. buildah 전략을 사용하는 경우 registries-search 매개변수를 정의하여 특정 레지스트리의 이미지를 검색할 수 있습니다. 다음 예제에서는 registries-search 배열 매개변수에 값을 할당하는 방법을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: <your_build>
  namespace: <your_namespace>
spec:
  paramValues:
  - name: storage-driver
    configMapValue:
      name: buildah-configuration
      key: storage-driver
  - name: registries-search
    values:
    - value: registry.redhat.io
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
  # ...
Copy to Clipboard Toggle word wrap

예: Build CR에서 시크릿 참조

다음 예와 같이 registries-block 배열 매개변수의 시크릿을 참조할 수 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: <your_build>
  namespace: <your_namespace>
spec:
  paramValues:
  - name: storage-driver
    configMapValue:
      name: buildah-configuration
      key: storage-driver
  - name: registries-block
    values:
    - secretValue: 
1

        name: registry-configuration
        key: reg-blocked
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
  # ...
Copy to Clipboard Toggle word wrap
1
이 값은 보안을 참조합니다.

4.5. 빌더 또는 Docker 파일 정의

Build CR에서 spec.paramValues 필드를 사용하여 출력 이미지를 빌드하는 도구가 포함된 이미지를 지정할 수 있습니다. 다음 예제는 Build CR에서 Dockerfile 이미지를 지정합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-go
    contextDir: docker-build
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  paramValues:
  - name: dockerfile
    value: Dockerfile
Copy to Clipboard Toggle word wrap

다음 예와 같이 빌더 이미지를 Build CR의 source-to-image 빌드 전략의 일부로 사용할 수도 있습니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: s2i-nodejs-build
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-nodejs
    contextDir: source-build/
  strategy:
    name: source-to-image
    kind: ClusterBuildStrategy
  paramValues:
  - name: builder-image
    value: docker.io/centos/nodejs-10-centos7
Copy to Clipboard Toggle word wrap

4.6. 출력 정의

Build CR에서 이미지를 내보낼 출력 위치를 지정할 수 있습니다. 외부 프라이빗 레지스트리를 출력 위치로 사용하는 경우 이미지에 액세스할 시크릿을 지정해야 합니다. 출력 이미지에 대한 주석 및 레이블을 지정할 수도 있습니다.

참고

주석 또는 레이블을 지정하면 출력 이미지가 두 번 푸시됩니다. 첫 번째 푸시는 빌드 전략에서 가져오고 두 번째 푸시는 이미지 구성을 변경하여 주석과 레이블을 추가합니다.

다음 예제에서는 이미지가 푸시되는 퍼블릭 레지스트리를 정의합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: s2i-nodejs-build
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-nodejs
    contextDir: source-build/
  strategy:
    name: source-to-image
    kind: ClusterBuildStrategy
  paramValues:
  - name: builder-image
    value: docker.io/centos/nodejs-10-centos7
  output:
    image: image-registry.openshift-image-registry.svc:5000/build-examples/nodejs-ex
Copy to Clipboard Toggle word wrap

다음 예제에서는 이미지가 푸시되는 프라이빗 레지스트리를 정의합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: s2i-nodejs-build
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-nodejs
    contextDir: source-build/
  strategy:
    name: source-to-image
    kind: ClusterBuildStrategy
  paramValues:
  - name: builder-image
    value: docker.io/centos/nodejs-10-centos7
  output:
    image: us.icr.io/source-to-image-build/nodejs-ex
    pushSecret: icr-knbuild
Copy to Clipboard Toggle word wrap

다음 예제에서는 이미지에 대한 주석 및 레이블을 정의합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: s2i-nodejs-build
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-nodejs
    contextDir: source-build/
  strategy:
    name: source-to-image
    kind: ClusterBuildStrategy
  paramValues:
  - name: builder-image
    value: docker.io/centos/nodejs-10-centos7
  output:
    image: us.icr.io/source-to-image-build/nodejs-ex
    pushSecret: icr-knbuild
    annotations:
      "org.opencontainers.image.source": "https://github.com/org/repo"
      "org.opencontainers.image.url": "https://my-company.com/images"
    labels:
      "maintainer": "team@my-company.com"
      "description": "This is my cool image"
Copy to Clipboard Toggle word wrap

4.7. 빌드에 대한 보존 매개변수 정의

보존 매개변수는 다음과 같은 목적으로 정의할 수 있습니다.

  • 완료된 빌드 실행이 존재할 수 있는 기간을 지정하려면 다음을 수행합니다.
  • 빌드에 존재할 수 있는 성공 또는 실패한 빌드 실행 수를 지정하려면 다음을 수행합니다.

보존 매개 변수를 사용하면 BuildRun 인스턴스 또는 리소스를 자동으로 정리할 수 있습니다. Build CR에서 다음 보존 매개변수 값을 설정할 수 있습니다.

  • retention.succeededLimit: 빌드에 존재할 수 있는 성공한 빌드 실행 수를 정의합니다.
  • retention.failedLimit: 빌드에 존재할 수 있는 실패한 빌드 실행 수를 정의합니다.
  • retention.ttlAfterFailed: 실패한 빌드 실행이 존재할 수 있는 기간을 지정합니다.
  • retention.ttlAfterSucceeded: 성공적인 빌드 실행이 존재할 수 있는 기간을 지정합니다.

다음 예제에서는 Build CR에서 보존 매개변수를 사용하는 방법을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: build-retention-ttl
spec:
  source:
    git:
      url: "https://github.com/shipwright-io/sample-go"
    contextDir: docker-build
  strategy:
    kind: ClusterBuildStrategy
  output:
  # ...
  retention:
    ttlAfterFailed: 30m
    ttlAfterSucceeded: 1h
    failedLimit: 10
    succeededLimit: 20
  # ...
Copy to Clipboard Toggle word wrap
참고

retention.failedLimitretention.succeededLimit 매개변수 값을 변경하면 빌드에 변경 사항이 적용되는 즉시 새 제한이 적용됩니다. 그러나 retention.ttlAfterFailedretention.ttlAfterSucceeded 매개변수 값을 변경하면 새 빌드 실행에서만 새 보존 기간이 적용됩니다. 이전 빌드는 이전 보존 기간을 따릅니다. BuildRun 및 Build CR 모두에 보존 기간이 정의된 경우 Build Run CR에 정의된 보존 기간이 우선 순위를 가져옵니다.

4.8. 빌드의 볼륨 정의

Build CR에서 볼륨을 정의할 수 있습니다. 정의된 볼륨은 BuildStrategy 리소스에 지정된 볼륨을 재정의합니다. 볼륨을 재정의하지 않으면 빌드 실행에 실패합니다.

다음 예제에서는 Build CR의 volumes 필드를 사용하는 방법을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: <build_name>
spec:
  source:
    git:
      url: https://github.com/example/url
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  paramValues:
  - name: dockerfile
    value: Dockerfile
  output:
    image: registry/namespace/image:latest
  volumes:
    - name: <your_volume_name>
      configMap:
        name: <your_configmap_name>
Copy to Clipboard Toggle word wrap

5장. 빌드 전략 구성

BuildStrategy 또는 ClusterBuildStrategy CR(사용자 정의 리소스)을 사용하면 전략 매개변수, 시스템 매개변수, 단계 리소스 정의, 주석 및 볼륨을 정의하여 빌드 전략을 구성할 수 있습니다. BuildStrategy 리소스는 네임스페이스 내에서 사용할 수 있으며 ClusterBuildStrategy 리소스는 클러스터 전체에서 사용할 수 있습니다.

빌드 전략을 구성하려면 BuildStrategy 또는 ClusterBuildStrategy 리소스 YAML 파일을 생성하여 OpenShift Container Platform 클러스터에 적용합니다.

5.1. 전략 매개변수 정의

BuildStrategy 또는 ClusterBuildStrategy CR(사용자 정의 리소스)에서 전략 매개변수를 정의하고 Build 또는 Build Run CR에서 해당 매개변수 값을 설정하거나 수정할 수 있습니다. 빌드 전략을 생성할 때 빌드 시 전략 매개변수를 구성하거나 수정할 수도 있습니다.

전략에 대한 매개변수를 정의하기 전에 다음 사항을 고려하십시오.

  • 빌드 전략 CR의 spec.parameters 필드에 매개변수 목록을 정의합니다. 각 목록 항목에는 배열 유형에 대한 이름, 설명, 유형 및 선택적 기본값 또는 값이 포함되어 있습니다. 기본값이 설정되지 않은 경우 Build 또는 BuildRun CR에 값을 정의해야 합니다.
  • 빌드 전략의 spec.steps 필드에 문자열 또는 배열 유형의 매개변수를 정의합니다.
  • $(params.your-parameter-name) 구문을 사용하여 문자열 유형의 매개변수를 지정합니다. 전략을 참조하는 Build 또는 BuildRun CR에서 your-parameter-name 매개변수 값을 설정할 수 있습니다. 요구 사항에 따라 다음 문자열 매개변수를 정의할 수 있습니다.

    Expand
    표 5.1. 문자열 매개변수
    매개변수설명

    image

    이 매개변수를 사용하여 golang:$(params.go-version)과 같은 사용자 정의 태그를 정의합니다.

    args

    이 매개변수를 사용하여 빌더 명령에 데이터 전달

    env

    이 매개변수를 사용하여 환경 변수의 값을 제공

  • $(params.your-array-parameter-name[*]) 구문을 사용하여 배열 유형의 매개변수를 지정합니다. 배열을 지정한 후 인수 또는 명령에서 사용할 수 있습니다. 배열의 각 항목에 대해 인수가 설정됩니다. 다음 예제에서는 빌드 전략의 spec.steps 필드에서 array 매개변수를 사용합니다.

    apiVersion: shipwright.io/v1beta1
    kind: ClusterBuildStrategy
    metadata:
      name: <cluster_build_strategy_name>
      # ...
    spec:
      parameters:
        - name: tool-args
          description: Parameters for the tool
          type: array
      steps:
        - name: a-step
          command:
            - some-tool
          args:
            - --tool-args
            - $(params.tool-args[*])
    Copy to Clipboard Toggle word wrap
  • 매개변수 값을 단순한 문자열로 제공하거나 구성 맵 또는 시크릿의 키에 대한 참조로 제공합니다. 매개변수의 경우 명령에 정의된 경우에만 구성 맵 또는 시크릿 값을 사용할 수 있습니다. spec.steps 필드의args 또는 env 섹션.

5.2. 시스템 매개변수 정의

빌드 전략의 단계를 정의하여 시스템 정보에 액세스하거나 Build 또는 BuildRun CR(사용자 정의 리소스)에서 사용자 정의 정보를 정의할 때 시스템 매개변수를 사용할 수 있습니다. 빌드 실행 컨트롤러에서 런타임에 정의하므로 시스템 매개변수를 구성하거나 수정할 수 없습니다.

빌드 전략 정의에서 다음 시스템 매개변수를 정의할 수 있습니다.

Expand
표 5.2. 시스템 매개변수
매개변수설명

$(params.shp-source-root)

소스 코드가 포함된 디렉터리의 절대 경로를 나타냅니다.

$(params.shp-source-context)

소스 코드의 컨텍스트 디렉터리에 대한 절대 경로를 나타냅니다. Build CR에서 spec.source.contextDir 에 값을 지정하지 않으면 이 매개변수는 $(params.shp-source-root) 시스템 매개변수의 값을 사용합니다.

$(params.shp-output-image)

Build 또는 BuildRun CR의 spec.output.image 필드에 정의된 대로 내보낼 이미지의 URL을 나타냅니다.

5.3. 단계 리소스 정의

빌드 전략의 모든 단계에 대한 CPU, 메모리, 디스크 사용량과 같은 리소스 정의를 포함할 수 있습니다. 여러 단계가 있는 전략의 경우 다른 단계보다 많은 리소스가 필요할 수 있습니다. 전략 관리자는 각 단계에 적합한 리소스 값을 정의할 수 있습니다.

예를 들어 동일한 단계를 사용하여 전략을 설치할 수 있지만 클러스터에 다른 이름과 단계 리소스를 설치하여 사용자가 더 작거나 큰 리소스 요구 사항을 사용하여 빌드를 생성할 수 있습니다.

5.3.1. 다양한 리소스가 있는 전략

리소스에 대한 다양한 제한으로 동일한 전략의 여러 유형을 정의합니다. 다음 예제에서는 리소스에 정의된 소규모 및 중간 제한과 동일한 buildah 전략을 사용합니다. 이 예제에서는 전략 관리자가 단계 리소스 정의를 보다 효과적으로 제어할 수 있도록 제공합니다.

5.3.1.1. 작은 제한이 있는 Buildah 전략

다음 예와 같이 buildah 전략에 대한 작은 리소스 제한을 사용하여 spec.steps[].resources 필드를 정의합니다.

예: 작은 제한이 있는 buildah 전략

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: buildah-small
spec:
  steps:
    - name: build-and-push
      image: quay.io/containers/buildah:v1.31.0
      workingDir: $(params.shp-source-root)
      securityContext:
        capabilities:
          add:
          - "SETFCAP"
      command:
        - /bin/bash
      args:
        - -c
        - |
          set -euo pipefail
          # Parse parameters
        # ...
        # That's the separator between the shell script and its args
        - --
        - --context
        - $(params.shp-source-context)
        - --dockerfile
        - $(build.dockerfile)
        - --image
        - $(params.shp-output-image)
        - --build-args
        - $(params.build-args[*])
        - --registries-block
        - $(params.registries-block[*])
        - --registries-insecure
        - $(params.registries-insecure[*])
        - --registries-search
        - $(params.registries-search[*])
      resources:
        limits:
          cpu: 250m
          memory: 65Mi
        requests:
          cpu: 250m
          memory: 65Mi
  parameters:
    - name: build-args
      description: "The values for the args in the Dockerfile. Values must be in the format KEY=VALUE."
      type: array
      defaults: []
    # ...
Copy to Clipboard Toggle word wrap

5.3.1.2. 중간 제한이 있는 Buildah 전략

다음 예와 같이 buildah 전략에 대한 중간 리소스 제한을 사용하여 spec.steps[].resources 필드를 정의합니다.

예: 중간 제한이 있는 buildah 전략

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: buildah-medium
spec:
  steps:
    - name: build-and-push
      image: quay.io/containers/buildah:v1.31.0
      workingDir: $(params.shp-source-root)
      securityContext:
        capabilities:
          add:
          - "SETFCAP"
      command:
        - /bin/bash
      args:
        - -c
        - |
          set -euo pipefail
          # Parse parameters
        # ...
        # That's the separator between the shell script and its args
        - --
        - --context
        - $(params.shp-source-context)
        - --dockerfile
        - $(build.dockerfile)
        - --image
        - $(params.shp-output-image)
        - --build-args
        - $(params.build-args[*])
        - --registries-block
        - $(params.registries-block[*])
        - --registries-insecure
        - $(params.registries-insecure[*])
        - --registries-search
        - $(params.registries-search[*])
      resources:
        limits:
          cpu: 500m
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
  parameters:
    - name: build-args
      description: "The values for the args in the Dockerfile. Values must be in the format KEY=VALUE."
      type: array
      defaults: []
    # ...
Copy to Clipboard Toggle word wrap

전략에 대한 리소스 정의를 구성한 후 다음 예와 같이 Build CR의 전략을 참조해야 합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-medium
spec:
  source:
    git:
      url: https://github.com/shipwright-io/sample-go
    contextDir: docker-build
  strategy:
    name: buildah-medium
    kind: ClusterBuildStrategy
  # ...
Copy to Clipboard Toggle word wrap

5.3.2. Tekton 파이프라인의 리소스 관리

빌드 컨트롤러는 전략 단계를 실행하기 위해 Pod를 예약할 수 있도록 Tekton 파이프라인 컨트롤러에서 작동합니다. 런타임 시 빌드 컨트롤러에서 Tekton TaskRun 리소스를 생성하고 TaskRun 리소스는 특정 네임스페이스에 새 Pod를 생성합니다. 그런 다음 이 Pod는 모든 전략 단계를 순차적으로 실행하여 이미지를 빌드합니다.

5.4. 주석 정의

빌드 전략 또는 다른 Kubernetes 오브젝트에 대한 클러스터 빌드 전략에 대한 주석을 정의할 수 있습니다. 빌드 전략에서는 먼저 주석을 TaskRun 리소스에 전파합니다. 그런 다음 Tekton은 해당 항목을 Pod에 전파합니다.

다음과 같은 목적으로 주석을 사용할 수 있습니다.

  • Pod가 사용할 수 있는 네트워크 대역폭을 제한하기 위해 kubernetes.io/ingress-bandwidthkubernetes.io/egress-bandwidth 주석은 Kubernetes 네트워크 트래픽 셰이핑 기능에 정의됩니다.
  • 컨테이너의 AppArmor 프로필을 정의하려면 container.apparmor.security.beta.kubernetes.io/<container_name > 주석이 사용됩니다.

다음 예제에서는 빌드 전략에서 주석 사용을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: <cluster_build_strategy_name>
  annotations:
    container.apparmor.security.beta.kubernetes.io/step-build-and-push: unconfined
    container.seccomp.security.alpha.kubernetes.io/step-build-and-push: unconfined
spec:
  # ...
Copy to Clipboard Toggle word wrap

다음 주석은 전파되지 않습니다.

  • kubectl.kubernetes.io/last-applied-configuration
  • clusterbuildstrategy.shipwright.io/*
  • buildstrategy.shipwright.io/*
  • build.shipwright.io/*
  • buildrun.shipwright.io/*

전략 관리자는 정책 엔진을 사용하여 주석 사용을 추가로 제한할 수 있습니다.

5.5. 문자열 매개변수 보안 참조

문자열 매개변수는 BuildStrategy 또는 Cluster BuildStrategy CR(사용자 정의 리소스)에서 환경 변수, 인수 또는 이미지를 정의할 때 사용됩니다. 빌드 전략 단계에서는 $(params.your-parameter-name) 구문을 사용하여 문자열 매개변수를 참조할 수 있습니다.

참고

빌드 전략 단계에서 $(params.your-parameter-name) 구문을 사용하여 시스템 매개변수 및 전략 매개변수를 참조할 수도 있습니다.

Pod에서 모든 $(params.your-parameter-name) 변수가 실제 문자열로 교체됩니다. 그러나 인라인 스크립트를 사용하여 인수에서 string 매개변수를 참조할 때 주의해야 합니다. 예를 들어 스크립트로 정의된 인수로 매개변수 값을 안전하게 전달하려면 다음 접근 방법 중 하나를 선택할 수 있습니다.

  • 환경 변수 사용
  • 인수 사용

예: 문자열 매개변수를 환경 변수에 참조

문자열 매개 변수를 스크립트 내에서 직접 사용하는 대신 환경 변수에 전달할 수 있습니다. 환경 변수 인용을 사용하면 명령 삽입 취약점을 방지할 수 있습니다. buildpacks v3 와 같은 전략에 이 접근 방식을 사용할 수 있습니다. 다음 예제에서는 스크립트 내의 환경 변수를 사용하여 문자열 매개변수를 참조합니다.

apiVersion: shipwright.io/v1beta1
kind: BuildStrategy
metadata:
  name: buildpacks-v3
spec:
  parameters:
    - name: sample-parameter
      description: A sample parameter
      type: string
  steps:
    - name: sample-step
      env:
        - name: PARAM_SAMPLE_PARAMETER
          value: $(params.sample-parameter)
      command:
        - /bin/bash
      args:
        - -c
        - |
          set -euo pipefail

          some-tool --sample-argument "${PARAM_SAMPLE_PARAMETER}"
Copy to Clipboard Toggle word wrap

예: 문자열 매개변수를 인수로 참조

string 매개변수를 스크립트 내에 정의된 인수로 전달할 수 있습니다. 명령 주입에 대한 감시를 인용하는 적절한 쉘입니다. buildah 와 같은 전략에 이 접근 방식을 사용할 수 있습니다. 다음 예제에서는 스크립트 내에 정의된 인수를 사용하여 문자열 매개변수를 참조합니다.

apiVersion: shipwright.io/v1beta1
kind: BuildStrategy
metadata:
  name: buildah
spec:
  parameters:
    - name: sample-parameter
      description: A sample parameter
      type: string
  steps:
    - name: sample-step
      command:
        - /bin/bash
      args:
        - -c
        - |
          set -euo pipefail

          SAMPLE_PARAMETER="$1"

          some-tool --sample-argument "${SAMPLE_PARAMETER}"
        - --
        - $(params.sample-parameter)
Copy to Clipboard Toggle word wrap

5.6. 시스템 결과 정의

빌드 전략에서 생성한 이미지의 크기와 다이제스트를 결과 파일 집합에 저장할 수 있습니다. BuildRun 리소스가 실패하는 경우 디버깅을 위해 오류 세부 정보를 저장할 수도 있습니다. BuildStrategy 또는 ClusterBuildStrategy CR에서 다음 결과 매개변수를 정의할 수 있습니다.

Expand
표 5.3. 결과 매개변수
매개변수설명

$(results.shp-image-digest.path)

이미지의 다이제스트를 저장하는 파일의 경로를 나타냅니다.

$(results.shp-image-size.path)

이미지의 압축 크기를 저장하는 파일의 경로를 나타냅니다.

$(results.shp-error-reason.path)

오류 이유를 저장하는 파일의 경로를 나타냅니다.

$(results.shp-error-message.path)

오류 메시지를 저장하는 파일의 경로를 나타냅니다.

다음 예제는 BuildRun CR의 .status.output 필드에 있는 이미지의 크기와 다이제스트를 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
# ...
status:
 # ...
  output:
    digest: sha256:07626e3c7fdd28d5328a8d6df8d29cd3da760c7f5e2070b534f9b880ed093a53
    size: 1989004
  # ...
Copy to Clipboard Toggle word wrap

다음 예제에서는 BuildRun CR의 .status.failure Details 필드에 있는 오류 이유 및 메시지를 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
# ...
status:
  # ...
  failureDetails:
    location:
      container: step-source-default
      pod: baran-build-buildrun-gzmv5-b7wbf-pod-bbpqr
    message: The source repository does not exist, or you have insufficient permission
      to access it.
    reason: GitRemotePrivate
Copy to Clipboard Toggle word wrap

5.7. 볼륨 및 볼륨 마운트 정의

빌드 전략에는 볼륨 및 볼륨 마운트 정의가 포함됩니다. 빌드 전략에 정의된 볼륨은 일반적인 volumeSource 유형을 모두 지원합니다. 빌드 단계는 볼륨 마운트를 생성하여 볼륨을 참조합니다.

참고

빌드 단계에 정의된 볼륨 마운트를 사용하면 BuildStrategy, Build 또는 Build Run 리소스에 정의된 볼륨에 액세스할 수 있습니다.

빌드 전략의 볼륨은 기본적으로 false 로 설정된 overridable 부울 플래그를 사용합니다. Build 또는 BuildRun 리소스가 BuildStrategy 리소스에 정의된 볼륨을 덮어쓰려고 하면 덮어쓸 수 있는 플래그의 기본값이 false 이므로 실패합니다.

다음 예제에서는 volumesvolumeMounts 필드를 정의하는 BuildStrategy 리소스를 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildStrategy
metadata:
  name: buildah
spec:
  steps:
    - name: build
      image: quay.io/containers/buildah:v1.23.3
      workingDir: $(params.shp-source-root)
      command:
        - buildah
        - bud
        - --tls-verify=false
        - --layers
        - -f
        - $(build.dockerfile)
        - -t
        - $(params.shp-output-image)
        - $(params.shp-source-context)
      volumeMounts:
        - name: varlibcontainers
          mountPath: /var/lib/containers
  volumes:
    - name: varlibcontainers
      overridable: true
      emptyDir: {}
Copy to Clipboard Toggle word wrap

6장. 빌드 실행 구성

BuildRun CR(사용자 정의 리소스)을 사용하면 빌드 참조, 빌드 사양, 매개변수 값, 서비스 계정, 출력, 보존 매개변수 및 볼륨을 정의하여 빌드 실행을 구성할 수 있습니다. BuildRun 리소스는 네임스페이스 내에서 사용할 수 있습니다.

빌드 실행을 구성하려면 BuildRun 리소스 YAML 파일을 생성하여 OpenShift Container Platform 클러스터에 적용합니다.

6.1. 빌드 실행의 구성 가능한 필드

BuildRun CR(사용자 정의 리소스)에서 다음 필드를 사용할 수 있습니다.

Expand
표 6.1. BuildRun CR의 필드
필드presence설명

apiVersion

필수 항목

리소스의 API 버전을 지정합니다. 예를 들어 shipwright.io/v1beta1 입니다.

kind

필수 항목

리소스 유형을 지정합니다. 예를 들면 BuildRun 입니다.

메타데이터

필수 항목

사용자 지정 리소스 정의 인스턴스를 식별하는 메타데이터를 나타냅니다. 예를 들어 BuildRun 리소스의 이름입니다.

spec.build.name

선택 사항

사용할 기존 Build 리소스 인스턴스를 지정합니다. spec.build.spec 필드에 이 필드를 사용할 수 없습니다.

spec.build.spec

선택 사항

사용할 포함된 Build 리소스 인스턴스를 지정합니다. spec.build.name 필드에 이 필드를 사용할 수 없습니다.

spec.serviceAccount

선택 사항

이미지를 빌드할 때 사용할 서비스 계정을 나타냅니다.

spec.timeout

선택 사항

사용자 정의 시간 초과를 정의합니다. 이 필드 값은 Build 리소스에 정의된 spec.timeout 필드의 값을 덮어씁니다.

spec.paramValues

선택 사항

빌드 전략에 정의된 매개변수 값을 지정하는 name-value 목록을 나타냅니다. 매개변수 값은 Build 리소스에서 동일한 이름으로 정의된 매개변수 값을 덮어씁니다.

spec.output.image

선택 사항

생성된 이미지를 내보낼 사용자 지정 위치를 나타냅니다. 이 필드 값은 Build 리소스에 정의된 output.image 필드의 값을 덮어씁니다.

spec.output.pushSecret

선택 사항

컨테이너 레지스트리에 액세스할 수 있는 기존 시크릿을 나타냅니다. 이 시크릿은 Build 리소스에서 요청한 다른 시크릿과 함께 서비스 계정에 추가됩니다.

spec.env

선택 사항

빌드 컨테이너에 전달할 수 있는 추가 환경 변수를 정의합니다. 이 필드 값은 Build 리소스에 지정된 환경 변수를 재정의합니다. 사용 가능한 변수는 빌드 전략에서 사용하는 도구에 따라 달라집니다.

참고

spec.build.namespec.build.spec 필드는 함께 사용할 수 없으므로 동일한 CR에서 함께 사용할 수 없습니다.

6.2. 빌드 참조 정의

BuildRun 리소스에서 spec.build.name 필드를 구성하여 빌드할 이미지를 나타내는 Build 리소스를 참조할 수 있습니다. 다음 예제는 spec.build.name 필드를 구성하는 BuildRun CR을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  build:
    name: buildpack-nodejs-build-namespaced
Copy to Clipboard Toggle word wrap

6.3. 빌드 사양 정의

BuildRun 리소스에 전체 spec.build.spec 필드를 삽입하여 이미지를 빌드할 수 있습니다. 다음 예제는 spec.build.spec 필드를 구성하는 BuildRun CR을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: standalone-buildrun
spec:
   build:
    spec:
      source:
        git:
          url: https://github.com/shipwright-io/sample-go.git
        contextDir: source-build
      strategy:
        kind: ClusterBuildStrategy
        name: buildpacks-v3
      output:
        image: <path_to_image>
Copy to Clipboard Toggle word wrap
참고

spec.build.namespec.build.spec 필드는 함께 사용할 수 없으므로 동일한 CR에서 함께 사용할 수 없습니다.

6.4. 빌드 실행에 대한 매개변수 값 정의

BuildRun CR에서 빌드 전략 매개변수의 값을 지정할 수 있습니다. 동일한 이름의 Build 리소스에도 정의된 매개변수 값을 제공한 경우 Build Run 리소스에 정의된 값이 우선합니다.

다음 예에서 BuildRun 리소스의 cache 매개변수 값은 Build 리소스에 정의된 cache 매개변수의 값을 재정의합니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: <your_build>
  namespace: <your_namespace>
spec:
  paramValues:
  - name: cache
    value: disabled
  strategy:
    name: <your_strategy>
    kind: ClusterBuildStrategy
  source:
  # ...
  output:
  # ...
Copy to Clipboard Toggle word wrap
apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: <your_buildrun>
  namespace: <your_namespace>
spec:
  build:
    name: <your_build>
  paramValues:
  - name: cache
    value: registry
Copy to Clipboard Toggle word wrap

6.5. 서비스 계정 정의

BuildRun 리소스에서 서비스 계정을 정의할 수 있습니다. 서비스 계정은 다음 예와 같이 Build 리소스에서 참조하는 모든 보안을 호스팅합니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  build:
    name: buildpack-nodejs-build-namespaced
  serviceAccount: pipeline 
1
Copy to Clipboard Toggle word wrap
1
spec.serviceAccount 필드의 값을 ".generate" 로 설정하여 런타임 중에 서비스 계정을 생성할 수도 있습니다. 생성된 서비스 계정의 이름은 BuildRun 리소스의 이름과 일치합니다.
참고

서비스 계정을 정의하지 않으면 BuildRun 리소스는 네임스페이스에 있는 경우 파이프라인 서비스 계정을 사용합니다. 그렇지 않으면 BuildRun 리소스에서 기본 서비스 계정을 사용합니다.

6.6. 빌드 실행에 대한 보존 매개변수 정의

BuildRun 리소스에 완료된 빌드 실행이 존재할 수 있는 기간을 지정할 수 있습니다. 보존 매개 변수를 사용하면 BuildRun 인스턴스를 자동으로 정리할 수 있습니다. BuildRun CR에서 다음 보존 매개변수의 값을 설정할 수 있습니다.

  • retention.ttlAfterFailed: 실패한 빌드 실행이 존재할 수 있는 기간을 지정합니다.
  • retention.ttlAfterSucceeded: 성공적인 빌드 실행이 존재할 수 있는 기간을 지정합니다.

다음 예제에서는 BuildRun CR에서 보존 매개변수를 정의하는 방법을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: buidrun-retention-ttl
spec:
  build:
    name: build-retention-ttl
  retention:
    ttlAfterFailed: 10m
    ttlAfterSucceeded: 10m
Copy to Clipboard Toggle word wrap
참고

BuildRunBuild CR 모두에 retention 매개변수를 정의한 경우 Build Run CR에 정의된 값이 Build CR에 정의된 보존 매개변수 값을 재정의합니다.

6.7. 빌드 실행에 대한 볼륨 정의

BuildRun CR에서 볼륨을 정의할 수 있습니다. 정의된 볼륨은 BuildStrategy 리소스에 지정된 볼륨을 재정의합니다. 볼륨을 재정의하지 않으면 빌드 실행에 실패합니다.

BuildBuildRun 리소스가 동일한 볼륨을 재정의하는 경우 BuildRun 리소스에 정의된 볼륨이 재정의에 사용됩니다.

다음 예제에서는 volumes 필드를 사용하는 BuildRun CR을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: <buildrun_name>
spec:
  build:
    name: <build_name>
  volumes:
    - name: <volume_name>
      configMap:
        name: <configmap_name>
Copy to Clipboard Toggle word wrap

6.8. 환경 변수 정의

필요에 따라 BuildRun CR에서 환경 변수를 사용할 수 있습니다. 다음 예제에서는 환경 변수를 정의하는 방법을 보여줍니다.

예: 환경 변수를 사용하여 BuildRun 리소스 정의

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  build:
    name: buildpack-nodejs-build-namespaced
  env:
    - name: <example_var_1>
      value: "<example_value_1>"
    - name: <example_var_2>
      value: "<example_value_2>"
Copy to Clipboard Toggle word wrap

다음 예제에서는 Kubernetes Downward API를 사용하여 Pod를 환경 변수로 노출하는 BuildRun 리소스를 보여줍니다.

예: Pod를 환경 변수로 노출하도록 BuildRun 리소스 정의

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  build:
    name: buildpack-nodejs-build-namespaced
  env:
    - name: <pod_name>
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
Copy to Clipboard Toggle word wrap

다음 예제에서는 Kubernetes Downward API를 사용하여 컨테이너를 환경 변수로 노출하는 BuildRun 리소스를 보여줍니다.

예: 컨테이너를 환경 변수로 노출하도록 BuildRun 리소스 정의

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  build:
    name: buildpack-nodejs-build-namespaced
  env:
    - name: MEMORY_LIMIT
      valueFrom:
        resourceFieldRef:
          containerName: <my_container>
          resource: limits.memory
Copy to Clipboard Toggle word wrap

6.9. 빌드 실행 상태

BuildRun 리소스는 다음 예와 같이 이미지 빌드 상태가 변경될 때마다 업데이트됩니다.

예: 알 수 없는 상태로 빌드

$ oc get buildrun buildpacks-v3-buildrun
NAME                    SUCCEEDED   REASON    MESSAGE   STARTTIME   COMPLETIONTIME
buildpacks-v3-buildrun  Unknown     Pending   Pending   1s
Copy to Clipboard Toggle word wrap

예: True 상태로 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
Copy to Clipboard Toggle word wrap

BuildRun 리소스는 상태 관련 정보를 status.conditions 필드에 저장합니다. 예를 들어 Succeeded 유형의 조건은 리소스가 작업을 성공적으로 완료했음을 나타냅니다. status.conditions 필드에는 BuildRun 리소스의 status, reason, message와 같은 중요한 정보가 포함됩니다.

6.9.1. 빌드 실행 상태 설명

BuildRun CR(사용자 정의 리소스)은 이미지 빌드 프로세스 중에 다른 상태를 가질 수 있습니다. 다음 표에서는 빌드 실행의 다양한 상태에 대해 설명합니다.

Expand
표 6.2. 빌드 실행의 상태
상태원인설명

알 수 없음

보류 중

BuildRun 리소스는 Pod 상태가 Pending 임을 기다립니다.

알 수 없음

실행 중

BuildRun 리소스의 유효성이 검사되었으며 작업을 수행하기 시작했습니다.

알 수 없음

BuildRunCanceled

사용자가 빌드 실행을 취소하도록 요청했습니다. 이 요청은 빌드 실행 컨트롤러를 트리거하여 관련 작업 실행 취소를 요청합니다. 이 상태가 있는 경우에도 취소가 진행 중입니다.

True

succeeded

BuildRun 리소스의 Pod가 생성됩니다.

False

실패

단계 중 하나에서 BuildRun 리소스가 실패합니다.

False

BuildRunTimeout

BuildRun 리소스의 실행이 시간 초과됩니다.

False

UnknownStrategyKind

Kind 필드에 정의된 전략 유형은 알 수 없습니다. 이러한 전략 유형인 ClusterBuildStrategyBuildStrategy 를 정의할 수 있습니다.

False

ClusterBuildStrategyNotFound

참조된 클러스터 범위 전략이 클러스터에서 찾을 수 없습니다.

False

BuildStrategyNotFound

참조된 네임스페이스 범위 전략이 클러스터에서 찾을 수 없습니다.

False

SetOwnerReferenceFailed

BuildRun 리소스에서 ownerReferences 필드를 관련 TaskRun 리소스로 설정하지 못했습니다.

False

TaskRunIsMissing

BuildRun 리소스와 관련된 TaskRun 리소스를 찾을 수 없습니다.

False

TaskRunGenerationFailed

TaskRun 사양 생성에 실패했습니다.

False

MissingParameterValues

기본값 없이 빌드 전략에 정의된 일부 매개변수에 대한 값을 제공하지 않았습니다. Build 또는 BuildRun CR에서 해당 매개변수의 값을 제공해야 합니다.

False

RestrictedParametersInUse

시스템 매개 변수의 값이 제공되었습니다. 이 값은 허용되지 않습니다.

False

정의되지 않음 매개변수

빌드 전략에 정의되지 않은 매개변수 값이 제공되었습니다.

False

WrongParameterValueType

잘못된 유형의 빌드 전략 매개변수에 대한 값이 제공되었습니다. 예를 들어 매개변수가 빌드 전략에서 배열 또는 문자열로 정의된 경우 그에 따라 값 집합 또는 직접 값을 제공해야 합니다.

False

InconsistentParameterValues

매개변수 값에는 값 ,configMapValue, secretValue 등 두 개 이상의 값이 포함되어 있습니다. 일관성을 유지하려면 언급된 값 중 하나만 제공해야 합니다.

False

EmptyArrayItemParameterValues

array 매개변수의 값에는 값 ,configMapValue, secretValue 라는 값이 포함되어 있지 않습니다. 언급된 값 중 하나만 null 배열 항목이 허용되지 않으므로 제공해야 합니다.

False

IncompleteConfigMapValueParameterValues

매개변수 값에는 이름 또는 value 필드가 비어 있는 configMapValue 값이 포함되어 있습니다. 네임스페이스의 기존 구성 맵 키를 가리키는 빈 필드를 지정해야 합니다.

False

IncompleteSecretValueParameterValues

매개변수 값에는 이름 또는 value 필드가 비어 있는 secretValue 값이 포함되어 있었습니다. 네임스페이스의 기존 시크릿 키를 가리키도록 빈 필드를 지정해야 합니다.

False

ServiceAccountNotFound

참조된 서비스 계정이 클러스터에서 찾을 수 없습니다.

False

BuildRegistrationFailed

BuildRun 리소스의 참조된 빌드는 Failed 상태입니다.

False

BuildNotFound

BuildRun 리소스에서 참조된 빌드를 찾을 수 없습니다.

False

BuildRunCanceled

BuildRun 및 관련 TaskRun 리소스가 성공적으로 취소되었습니다.

False

BuildRunNameInvalid

metadata.name 필드에 정의된 빌드 실행 이름이 유효하지 않습니다. BuildRun CR에서 빌드 실행 이름에 유효한 라벨 값을 제공해야 합니다.

False

BuildRunNoRefOrSpec

BuildRun 리소스에 spec.build.name 또는 spec.build.spec 필드가 정의되어 있지 않습니다.

False

BuildRunAmbiguousBuild

정의된 BuildRun 리소스는 spec.build.namespec.build.spec 필드를 모두 사용합니다. 매개 변수 중 하나만 한 번에 허용됩니다.

False

BuildRunBuildFieldOverrideForbidden

정의된 spec.build.name 필드는 허용되지 않는 spec.build.spec 필드와 함께 재정의를 사용합니다. spec.build.spec 필드를 사용하여 해당 값을 직접 지정합니다.

False

PodEvicted

빌드 실행 Pod가 실행 중인 노드에서 제거되었습니다.

6.9.2. 빌드 실행 실패

빌드 실행에 실패하면 BuildRun CR의 status.failure Details 필드를 확인하여 Pod 또는 컨테이너에서 오류가 발생한 정확한 지점을 확인할 수 있습니다. status.failureDetails 필드에는 오류 메시지와 실패 이유가 포함됩니다. 빌드 전략에 정의된 경우 메시지와 실패 이유만 표시됩니다.

다음 예제에서는 실패한 빌드 실행을 보여줍니다.

# ...
status:
  # ...
  failureDetails:
    location:
      container: step-source-default
      pod: baran-build-buildrun-gzmv5-b7wbf-pod-bbpqr
    message: The source repository does not exist, or you have insufficient permission
      to access it.
    reason: GitRemotePrivate
Copy to Clipboard Toggle word wrap
참고

status.failureDetails 필드는 Git과 관련된 모든 작업에 대한 오류 세부 정보도 제공합니다.

6.9.3. 단계적 결과 빌드 실행 상태가

BuildRun 리소스의 실행을 완료한 후 .status 필드에 빌드 실행 컨트롤러에서 생성된 단계에서 .status.taskResults 결과가 포함됩니다. 결과에는 이미지 다이제스트 또는 이미지 빌드에 사용되는 소스 코드의 커밋 SHA가 포함됩니다. BuildRun 리소스에서 .status.sources 필드에는 소스 단계 실행의 결과가 포함되어 있으며 .status.output 필드에는 출력 단계의 실행 결과가 포함됩니다.

다음 예제에서는 Git 소스에 대한 단계 결과가 있는 BuildRun 리소스를 보여줍니다.

예: Git 소스에 대한 단계 결과가 있는 BuildRun 리소스

# ...
status:
  buildSpec:
    # ...
  output:
    digest: sha256:07626e3c7fdd28d5328a8d6df8d29cd3da760c7f5e2070b534f9b880ed093a53
    size: 1989004
  sources:
  - name: default
    git:
      commitAuthor: xxx xxxxxx
      commitSha: f25822b85021d02059c9ac8a211ef3804ea8fdde
      branchName: main
Copy to Clipboard Toggle word wrap

다음 예제에서는 로컬 소스 코드에 대한 단계 결과가 있는 BuildRun 리소스를 보여줍니다.

예: 로컬 소스 코드에 대한 단계 결과가 있는 BuildRun 리소스

# ...
status:
  buildSpec:
    # ...
  output:
    digest: sha256:07626e3c7fdd28d5328a8d6df8d29cd3da760c7f5e2070b534f9b880ed093a53
    size: 1989004
  sources:
  - name: default
    bundle:
      digest: sha256:0f5e2070b534f9b880ed093a537626e3c7fdd28d5328a8d6df8d29cd3da760c7
Copy to Clipboard Toggle word wrap

참고

빌드 전략에 정의된 경우에만 출력 이미지의 다이제스트와 크기가 표시됩니다.

6.9.4. 빌드 스냅샷

각 빌드 실행 조정에 대해 기존 작업 실행이 해당 빌드 실행의 일부인 경우 BuildRun 리소스 상태의 buildSpec 필드가 업데이트됩니다.

이번 업데이트 중에 Build 리소스 스냅샷은 BuildRun 리소스의 status.buildSpec 필드를 생성하고 포함합니다. 이로 인해 buildSpec 필드에는 특정 이미지 빌드를 실행하는 데 사용된 원래 Build 사양의 정확한 사본이 포함되어 있습니다. 빌드 스냅샷을 사용하면 원래 Build 리소스 구성을 볼 수 있습니다.

6.10. Tekton 작업과의 빌드 실행 관계

BuildRun 리소스는 이미지 생성 작업을 Tekton TaskRun 리소스에 위임하여 작업이 완료되거나 작업에서 실패할 때까지 모든 단계를 실행합니다.

빌드 실행 조정 중에 빌드 실행 컨트롤러에서 새 TaskRun 리소스를 생성합니다. 컨트롤러는 TaskRun 리소스에서 빌드 실행 실행에 필요한 단계를 포함합니다. 포함된 단계는 빌드 전략에 정의됩니다.

6.11. 빌드 실행 취소

상태를 BuildRun Canceled 로 설정하여 활성 BuildRun 인스턴스를 취소할 수 있습니다. BuildRun 인스턴스를 취소하면 기본 TaskRun 리소스도 취소됨으로 표시됩니다.

다음 예제에서는 BuildRun 리소스에 대해 취소된 빌드 실행을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: BuildRun
metadata:
  name: buildpack-nodejs-buildrun-namespaced
spec:
  # [...]
  state: "BuildRunCanceled"
Copy to Clipboard Toggle word wrap

6.12. 자동 빌드 실행 삭제

빌드 실행을 자동으로 삭제하려면 빌드 또는 build run 사양에 다음 보존 매개변수를 추가할 수 있습니다.

  • buildrun TTL 매개변수: 빌드가 완료된 후 정의된 기간 동안만 존재하는지 확인합니다.

    • buildrun.spec.retention.ttlAfterFailed: 지정된 시간이 경과하고 빌드 실행에 실패한 경우 빌드 실행이 삭제됩니다.
    • buildrun.spec.retention.ttlAfterSucceeded: 지정된 시간이 통과되고 빌드 실행에 성공하면 빌드 실행이 삭제됩니다.
  • Build TTL 매개변수: 빌드가 완료된 후 정의된 기간 동안만 빌드에 대해 실행되도록 합니다.

    • 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" 주석을 추가할 수 있습니다. 이 주석을 기반으로 빌드 컨트롤러는 빌드 보안에 대한 이벤트 생성, 업데이트 또는 삭제와 같은 이벤트 시 조정 작업을 수행합니다. 다음 예제에서는 보안과 함께 주석을 사용하는 방법을 보여줍니다.

apiVersion: v1
data:
  .dockerconfigjson: <pull_secret> 
1

kind: Secret
metadata:
  annotations:
    build.shipwright.io/referenced.secret: "true" 
2

  name: secret-docker
type: kubernetes.io/dockerconfigjson
Copy to Clipboard Toggle word wrap
1
base64로 인코딩된 풀 시크릿입니다.
2
build.shipwright.io/referenced.secret 주석의 값은 true 로 설정됩니다.

이 주석은 빌드 인스턴스에서 참조하지 않는 보안을 필터링합니다. 예를 들어 시크릿에 이 주석이 없는 경우 보안에 대해 이벤트가 트리거된 경우에도 빌드 컨트롤러에서 조정하지 않습니다. 이벤트 트리거를 조정하면 빌드 컨트롤러에서 빌드 구성에 대한 검증을 다시 트리거하여 종속성이 누락되었는지 파악할 수 있습니다.

7.2. Git 리포지토리에 대한 인증

Git 리포지토리에 대해 다음과 같은 인증 유형을 정의할 수 있습니다.

  • 기본 인증
  • SSH(Secure Shell) 인증

Build CR에서 두 가지 유형의 인증을 사용하여 Git 보안을 구성할 수도 있습니다.

7.2.1. 기본 인증

기본 인증을 사용하여 Git 리포지토리의 사용자 이름과 암호를 구성해야 합니다. 다음 예제에서는 Git에 대한 기본 인증을 사용하는 방법을 보여줍니다.

apiVersion: v1
kind: Secret
metadata:
  name: secret-git-basic-auth
  annotations:
    build.shipwright.io/referenced.secret: "true"
type: kubernetes.io/basic-auth 
1

stringData: 
2

  username: <cleartext_username>
  password: <cleartext_password>
Copy to Clipboard Toggle word wrap
1
Kubernetes 시크릿의 유형입니다.
2
사용자 이름과 암호를 일반 텍스트로 저장할 필드입니다.

7.2.2. SSH 인증

SSH 인증을 사용하면 사용할 Git 리포지토리 공급자의 호스트 이름을 지정하도록 Tekton 주석을 구성해야 합니다. 예를 들어 GitHub의 경우 github.com 또는 GitLab 의 경우 github.com 입니다.

다음 예제에서는 Git에 대한 SSH 인증을 사용하는 방법을 보여줍니다.

apiVersion: v1
kind: Secret
metadata:
  name: secret-git-ssh-auth
  annotations:
    build.shipwright.io/referenced.secret: "true"
type: kubernetes.io/ssh-auth 
1

data:
  ssh-privatekey: |   
2

    # Insert ssh private key, base64 encoded
Copy to Clipboard Toggle word wrap
1
Kubernetes 시크릿의 유형입니다.
2
Git에 인증하는 데 사용되는 SSH 키의 Base64 인코딩입니다. base64 ~/.ssh/id_rsa.pub 명령을 사용하여 이 키를 생성할 수 있습니다. 여기서 ~/.ssh/id_rsa.pub 는 일반적으로 Git을 인증하는 데 사용되는 키의 기본 위치를 나타냅니다.

7.2.3. Git 시크릿 사용

관련 네임스페이스에 보안을 생성한 후 Build Custom Resource(CR)에서 참조할 수 있습니다. 두 가지 유형의 인증을 모두 사용하여 Git 시크릿을 구성할 수 있습니다.

다음 예제에서는 SSH 인증 유형을 사용하여 Git 시크릿을 사용하는 방법을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: git@gitlab.com:userjohn/newtaxi.git
      cloneSecret: secret-git-ssh-auth
Copy to Clipboard Toggle word wrap

다음 예제에서는 기본 인증 유형을 사용하여 Git 보안을 사용하는 방법을 보여줍니다.

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://gitlab.com/userjohn/newtaxi.git
      cloneSecret: secret-git-basic-auth
Copy to Clipboard Toggle word wrap

7.3. 컨테이너 레지스트리에 대한 인증

이미지를 프라이빗 컨테이너 레지스트리로 내보내려면 해당 네임스페이스에 보안을 정의한 다음 Build 사용자 정의 리소스(CR)에서 참조해야 합니다.

프로세스

  1. 다음 명령을 실행하여 보안을 생성합니다.

    $ 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 Toggle word wrap
    1
    < registry_host > 값은 이 형식의 https://<registry_server>/<registry_host > 형식의 URL을 나타냅니다.
    2
    & lt;username& gt; 값은 사용자 ID입니다.
    3
    & lt;password > 값은 컨테이너 레지스트리 암호 또는 액세스 토큰일 수 있습니다.
  2. 다음 명령을 실행하여 보안에 주석을 답니다.

    $ oc --namespace <namespace> annotate secrets <container_registry_secret_name> build.shipwright.io/referenced.secret='true'
    Copy to Clipboard Toggle word wrap
  3. spec.output.pushSecret 필드의 값을 Build CR의 보안 이름으로 설정합니다.

    apiVersion: shipwright.io/v1beta1
    kind: Build
    metadata:
      name: buildah-golang-build
      # ...
      output:
        image: <path_to_image>
        pushSecret: <container_registry_secret_name>
    Copy to Clipboard Toggle word wrap

7.4. 역할 기반 액세스 제어

릴리스 배포 YAML 파일에는 OpenShift Builds 오브젝트를 사용하기 위한 두 가지 클러스터 전체 역할이 포함되어 있습니다. 기본적으로 다음 역할이 설치됩니다.

  • shpwright-build-aggregate-view:Build Strategy ,Cluster BuildStrategy, BuildRun 과 같은 OpenShift Builds 리소스에 대한 읽기 액세스 권한을 부여합니다. 이 역할은 Kubernetes 역할에 집계됩니다.
  • shipwright-build-aggregate-edit: 네임스페이스 수준에서 구성된 OpenShift 빌드 리소스에 대한 액세스 권한을 작성합니다. 빌드 리소스에는 BuildStrategy,Build, BuildRun 이 포함됩니다. 모든 ClusterBuildStrategy 리소스에 읽기 액세스 권한이 부여됩니다. 이 역할은 Kubernetes editadmin 역할에 집계됩니다.

클러스터 관리자만 ClusterBuildStrategy 리소스에 대한 쓰기 액세스 권한이 있습니다. 이러한 권한으로 별도의 Kubernetes ClusterRole 역할을 생성하고 해당 역할을 적절한 사용자에게 바인딩하여 이 설정을 변경할 수 있습니다.

8장. 빌드 컨트롤러 관찰 기능

OpenShift 빌드에서는 빌드 리소스의 성능 및 기능을 모니터링하는 데 도움이 되는 여러 메트릭을 노출합니다. 빌드 컨트롤러 메트릭은 포트 8383 에 노출됩니다.

OpenShift 빌드에서는 빌드 컨트롤러에서 pprof 모드를 활성화하는 프로파일링 기능도 제공합니다.

8.1. 빌드 컨트롤러 메트릭

모니터링 목적으로 다음 빌드 컨트롤러 메트릭을 확인할 수 있습니다.

Expand
표 8.1. 빌드 컨트롤러 메트릭
이름유형설명라벨상태

build_builds_registered_total

카운터

전체 등록된 빌드 수입니다.

  • buildstrategy=<build_buildstrategy_name>
  • namespace=<buildrun_namespace>
  • build=<build_name>

실험적

build_buildruns_completed_total

카운터

전체 완료된 빌드 실행 수입니다.

  • buildstrategy=<build_buildstrategy_name>
  • namespace=<buildrun_namespace>
  • build=<build_name>
  • buildrun=<buildrun_name>

실험적

build_buildrun_establish_duration_seconds

히스토그램

빌드 실행 시 지속 시간을 초 단위로 설정합니다.

  • buildstrategy=<build_buildstrategy_name>
  • namespace=<buildrun_namespace>
  • build=<build_name>
  • buildrun=<buildrun_name>

실험적

build_buildrun_completion_duration_seconds

히스토그램

빌드 실행 완료 기간(초)입니다.

  • buildstrategy=<build_buildstrategy_name>
  • namespace=<buildrun_namespace>
  • build=<build_name>
  • buildrun=<buildrun_name>

실험적

build_buildrun_rampup_duration_seconds

히스토그램

빌드는 초 단위의 ramp-up 기간을 실행합니다.

  • buildstrategy=<build_buildstrategy_name>
  • namespace=<buildrun_namespace>
  • build=<build_name>
  • buildrun=<buildrun_name>

실험적

build_buildrun_taskrun_rampup_duration_seconds

히스토그램

작업 실행에 대한 빌드 실행 기간(초)입니다.

  • buildstrategy=<build_buildstrategy_name>
  • namespace=<buildrun_namespace>
  • build=<build_name>
  • buildrun=<buildrun_name>

실험적

build_buildrun_taskrun_pod_rampup_duration_seconds

히스토그램

작업 실행 Pod의 빌드 실행 시간(초)입니다.

  • buildstrategy=<build_buildstrategy_name>
  • namespace=<buildrun_namespace>
  • build=<build_name>
  • buildrun=<buildrun_name>

실험적

8.1.1. 히스토그램 메트릭

빌드 컨트롤러에 사용자 정의 버킷을 사용하려면 특정 히스토그램 지표에 대한 환경 변수를 설정해야 합니다. 다음 표에서는 모든 히스토그램 메트릭에 대한 환경 변수를 보여줍니다.

Expand
표 8.2. 히스토그램 메트릭
메트릭환경 변수Default

build_buildrun_establish_duration_seconds

PROMETHEUS_BR_EST_DUR_BUCKETS

0,1,2,3,5,7,10,15,20,30

build_buildrun_completion_duration_seconds

PROMETHEUS_BR_COMP_DUR_BUCKETS

50,100,150,200,250,300,350,400,450,500

build_buildrun_rampup_duration_seconds

PROMETHEUS_BR_RAMPUP_DUR_BUCKETS

0,1,2,3,4,5,6,7,8,9,10

build_buildrun_taskrun_rampup_duration_seconds

PROMETHEUS_BR_RAMPUP_DUR_BUCKETS

0,1,2,3,4,5,6,7,8,9,10

build_buildrun_taskrun_pod_rampup_duration_seconds

PROMETHEUS_BR_RAMPUP_DUR_BUCKETS

0,1,2,3,4,5,6,7,8,9,10

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"
    # ...
    Copy to Clipboard Toggle word wrap

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
    # ...
    Copy to Clipboard Toggle word wrap
  • 여러 메트릭 레이블을 활성화하려면 controller.yaml 배포 파일의 spec.containers[0].spec.env 섹션에 다음 항목을 추가합니다.

    # ...
      env:
      - name: PROMETHEUS_ENABLED_LABELS
        value: buildstrategy,namespace,build
    # ...
    Copy to Clipboard Toggle word wrap

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"
    Copy to Clipboard Toggle word wrap

9장. OpenShift 빌드 설치 제거

클러스터 관리자는 Red Hat OpenShift Builds Operator를 설치 제거할 수 있습니다. Operator를 설치 제거해도 CR(사용자 정의 리소스) 및 OpenShift 빌드 구성 요소가 자동으로 제거되지 않습니다.

Red Hat OpenShift Builds Operator를 설치 제거하려면 다음 작업을 수행합니다.

  1. Operator를 설치할 때 기본적으로 생성된 CR(사용자 정의 리소스)을 삭제합니다.

    참고

    CR을 제거하지 않고 Operator를 설치 제거하는 경우 나중에 제거할 수 없습니다.

  2. Operator를 설치 제거합니다.

9.1. OpenShift 빌드 구성 요소 및 사용자 정의 리소스 삭제

Operator를 설치하는 동안 기본적으로 생성된 CR(사용자 정의 리소스)을 삭제합니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 AdministrationCustom Resource Definition로 이동합니다.
  2. 이름으로 필터링 상자에 operator.shipwright.io 를 입력하여 Red Hat OpenShift Builds Operator CR을 검색합니다.
  3. CRD Config을 클릭하여 Custom Resource Definition Details 페이지를 엽니다.
  4. 작업 드롭다운 목록을 클릭하고 사용자 정의 리소스 정의 삭제 를 선택합니다.

    참고

    CR을 삭제하면 OpenShift 빌드 컨트롤러와 클러스터의 모든 관련 구성 요소 및 작업이 삭제됩니다.

  5. Delete 를 클릭하여 CR 삭제를 확인합니다.

9.2. Red Hat OpenShift Builds Operator 설치 제거

웹 콘솔의 관리자 화면을 사용하여 Red Hat OpenShift Builds Operator를 설치 제거할 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 관리자로 로그인되어 있습니다.

프로세스

  1. OperatorsOperatorHub로 이동합니다.
  2. OperatorHub 페이지에서 키워드로 필터링 상자를 사용하여 Red Hat OpenShift Builds Operator를 검색합니다.
  3. Red Hat OpenShift Builds Operator 타일을 클릭합니다. Operator 타일은 Operator가 설치되었음을 나타냅니다.
  4. 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.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat