2.9. 고급 빌드 수행

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

2.9.1. 빌드 리소스 설정
링크 복사

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

프로세스

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

프로젝트의 기본 컨테이너 제한에 리소스 제한을 지정하여 리소스 사용 제한을 제한합니다.
리소스 제한을 빌드 구성의 일부로 지정하여 리소스 사용을 제한합니다. **다음 예제에서는 각 resources, cpu, memory 매개변수가 선택 사항입니다.
```
apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  resources:
    limits:
      cpu: "100m" 
      memory: "256Mi" 
```
```
apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  resources:
    limits:
      cpu: "100m" 
```
1
```
      memory: "256Mi" 
```
2
Copy to Clipboard Toggle word wrap
1
cpu는 CPU 단위입니다. 100m은 0.1 CPU 단위(100 * 1e-3)를 나타냅니다.
2
memory는 바이트 단위입니다. 256Mi는 268435456바이트(256 * 2 ^ 20)를 나타냅니다.
그러나 프로젝트에 할당량을 정의한 경우 다음 두 항목 중 하나가 필요합니다.
- requests가 명시적으로 설정된 resources 섹션:
  resources: requests:
  1
  cpu: "100m" memory: "256Mi"
  Copy to Clipboard Toggle word wrap
  1
  requests 오브젝트에 할당량의 리소스 목록에 해당하는 리소스 목록이 포함되어 있습니다.
- 프로젝트에 정의된 제한 범위: LimitRange 오브젝트의 기본값은 빌드 프로세스 중 생성된 Pod에 적용됩니다.
  그러지 않으면 할당량을 충족하지 못하여 빌드 Pod 생성이 실패합니다.

2.9.2. 최대 기간 설정
링크 복사

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

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

프로세스

최대 기간을 설정하려면 BuildConfig에서 completionDeadlineSeconds를 지정합니다. 다음 예제에서는 completionDeadlineSeconds 필드를 30분으로 지정하는 BuildConfig의 일부를 보여줍니다.
```
spec:
  completionDeadlineSeconds: 1800
```
```
spec:
  completionDeadlineSeconds: 1800
```
Copy to Clipboard Toggle word wrap

참고

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

2.9.3. 특정 노드에 빌드 할당
링크 복사

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

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

참고

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

프로세스

BuildConfig의 nodeSelector 필드에 라벨을 할당하여 특정 노드에서 실행할 빌드를 할당합니다. 예를 들면 다음과 같습니다.
```
apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  nodeSelector:
    key1: value1
    key2: value2
```
```
apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  nodeSelector:
```
1
```
    key1: value1
    key2: value2
```
Copy to Clipboard Toggle word wrap
1
이 빌드 구성과 관련된 빌드는 key1=value2 및 key2=value2 라벨이 있는 노드에서만 실행됩니다.

2.9.4. 연결된 빌드
링크 복사

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

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

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

참고

이 예제에서는 S2I 빌드와 Docker 빌드를 연결하지만 첫 번째 빌드에서는 원하는 아티팩트를 포함하는 이미지를 생성하는 모든 전략을 사용할 수 있고, 두 번째 빌드에서는 이미지의 입력 콘텐츠를 소비하는 모든 전략을 사용할 수 있습니다.

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: image-build
spec:
  output:
    to:
      kind: ImageStreamTag
      name: image-build:latest
  source:
    dockerfile: |-
      FROM jee-runtime:latest
      COPY ROOT.war /deployments/ROOT.war
    images:
    - from:


        kind: ImageStreamTag
        name: artifact-image:latest
      paths:


      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from:


        kind: ImageStreamTag
        name: jee-runtime:latest
  triggers:
  - imageChange: {}
    type: ImageChange

Copy to Clipboard

Toggle word wrap

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

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

2.9.5. 빌드 정리
링크 복사

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

프로세스

BuildConfig의 successfulBuildsHistoryLimit 또는 failedBuildsHistoryLimit에 양의 정수 값을 제공하여 유지되는 이전 빌드의 수를 제한합니다. 예를 들면 다음과 같습니다.
```
apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2 
  failedBuildsHistoryLimit: 2 
```
```
apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2 
```
1
```
  failedBuildsHistoryLimit: 2 
```
2
Copy to Clipboard Toggle word wrap
1
successfulBuildsHistoryLimit은 completed 상태의 빌드를 두 개까지 유지합니다.
2
failedBuildsHistoryLimit은 failed, canceled 또는 error 상태의 빌드를 두 개까지 유지합니다.
다음 작업 중 하나로 빌드 정리를 트리거합니다.
- 빌드 구성 업데이트
- 빌드가 라이프사이클을 완료할 때까지 대기

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

참고

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

2.9.6. 빌드 정책 실행
링크 복사

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

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

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

맨 위로 이동

2.9. 고급 빌드 수행

2.9.1. 빌드 리소스 설정
링크 복사

2.9.2. 최대 기간 설정
링크 복사

2.9.3. 특정 노드에 빌드 할당
링크 복사

2.9.4. 연결된 빌드
링크 복사

2.9.5. 빌드 정리
링크 복사

2.9.6. 빌드 정책 실행
링크 복사

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.9. 고급 빌드 수행

2.9.1. 빌드 리소스 설정링크 복사링크가 클립보드에 복사되었습니다!

2.9.2. 최대 기간 설정링크 복사링크가 클립보드에 복사되었습니다!

2.9.3. 특정 노드에 빌드 할당링크 복사링크가 클립보드에 복사되었습니다!

2.9.4. 연결된 빌드링크 복사링크가 클립보드에 복사되었습니다!

2.9.5. 빌드 정리링크 복사링크가 클립보드에 복사되었습니다!

2.9.6. 빌드 정책 실행링크 복사링크가 클립보드에 복사되었습니다!

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.9.1. 빌드 리소스 설정
링크 복사

2.9.2. 최대 기간 설정
링크 복사

2.9.3. 특정 노드에 빌드 할당
링크 복사

2.9.4. 연결된 빌드
링크 복사

2.9.5. 빌드 정리
링크 복사

2.9.6. 빌드 정책 실행
링크 복사