2.5. 빌드 전략 사용
다음 섹션에서는 지원되는 주요 빌드 전략과 이러한 전략을 사용하는 방법을 정의합니다.
2.5.1. Docker 빌드
OpenShift Container Platform은 Buildah를 사용하여 Dockerfile에서 컨테이너 이미지를 빌드합니다. Dockerfile을 사용하여 컨테이너 이미지를 빌드하는 방법에 대한 자세한 내용은 Dockerfile 참조 문서를 참조하십시오.
buildArgs
배열을 사용하여 Docker 빌드 인수를 설정하는 경우 Dockerfile 참조 문서에서 ARG 및 FROM이 상호 작용하는 방법 이해를 참조하십시오.
2.5.1.1. Dockerfile FROM 이미지 교체
Dockerfile의 FROM
명령을 BuildConfig
오브젝트의 from
으로 교체할 수 있습니다. Dockerfile에서 다중 단계 빌드를 사용하는 경우 마지막 FROM
명령의 이미지가 교체됩니다.
프로세스
Dockerfile의 FROM
명령을 BuildConfig
오브젝트의 from
으로 교체
strategy: dockerStrategy: from: kind: "ImageStreamTag" name: "debian:latest"
2.5.1.2. Dockerfile 경로 사용
기본적으로 Docker 빌드는 BuildConfig.spec.source.contextDir
필드에 지정된 컨텍스트의 루트에 있는 Dockerfile을 사용합니다.
dockerfilePath
필드를 사용하면 BuildConfig.spec.source.contextDir
필드와 상대되는 다른 경로를 사용하여 Dockerfile을 찾을 수 있습니다. 파일 이름은 기본 Dockerfile(예: MyDockerfile
) 또는 하위 디렉터리의 Dockerfile 경로(예: dockerfiles/app1/Dockerfile
)와 다를 수 있습니다.
프로세스
빌드에서 다른 경로를 사용하여 Dockerfile을 찾도록 dockerfilePath
필드를 사용하려면 다음과 같이 설정합니다.
strategy: dockerStrategy: dockerfilePath: dockerfiles/app1/Dockerfile
2.5.1.3. Docker 환경 변수 사용
Docker 빌드 프로세스 및 생성된 이미지에 환경 변수를 사용할 수 있도록 빌드 구성의 dockerStrategy
정의에 환경 변수를 추가할 수 있습니다.
정의된 환경 변수는 FROM
명령 직후 단일 ENV
Dockerfile 명령으로 삽입되어 나중에 Dockerfile 내에서 참조할 수 있습니다.
프로세스
변수는 빌드 중 정의되고 출력 이미지에 유지되므로 해당 이미지를 실행하는 모든 컨테이너에도 존재합니다.
예를 들어 다음은 빌드 및 런타임 중 사용할 사용자 정의 HTTP 프록시를 정의합니다.
dockerStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
oc set env
명령을 사용하면 빌드 구성에 정의된 환경 변수도 관리할 수 있습니다.
2.5.1.4. Docker 빌드 인수 추가
buildArgs
배열을 사용하여 Docker 빌드 인수를 설정할 수 있습니다. 빌드 인수는 빌드가 시작될 때 Docker로 전달됩니다.
Dockerfile 참조 문서에서 ARG 및 FROM이 상호 작용하는 방법 이해를 참조하십시오.
절차
Docker 빌드 인수를 설정하려면 BuildConfig
오브젝트의 dockerStrategy
정의에 있는 buildArgs
배열에 항목을 추가합니다. 예를 들면 다음과 같습니다.
dockerStrategy: ... buildArgs: - name: "foo" value: "bar"
name
및 value
필드만 지원됩니다. valueFrom
필드의 설정은 모두 무시됩니다.
2.5.1.5. Docker 빌드를 사용하여 계층 스쿼시
Docker 빌드는 일반적으로 Dockerfile의 각 명령을 나타내는 계층을 생성합니다. imageOptimizationPolicy
를 SkipLayers
로 설정하면 모든 명령을 기본 이미지 상단의 단일 계층으로 병합합니다.
프로세스
imageOptimizationPolicy
를SkipLayers
로 설정합니다.strategy: dockerStrategy: imageOptimizationPolicy: SkipLayers
2.5.1.6. 빌드 볼륨 사용
빌드 볼륨을 마운트하여 출력 컨테이너 이미지에 유지되지 않는 정보에 대한 실행 중인 빌드 액세스 권한을 제공할 수 있습니다.
빌드 볼륨은 리포지토리 자격 증명과 같은 중요한 정보를 제공하며, 빌드 환경 또는 구성에 빌드 시만 있으면 됩니다. 빌드 볼륨은 출력 컨테이너 이미지에 데이터가 지속될 수 있는 빌드 입력 과 다릅니다.
실행 중인 빌드에서 데이터를 읽는 빌드 볼륨의 마운트 지점은 Pod 볼륨 마운트 와 기능적으로 유사합니다.
프로세스
BuildConfig
오브젝트의dockerStrategy
정의에서volumes
배열에 빌드 볼륨을 추가합니다. 예를 들면 다음과 같습니다.spec: dockerStrategy: volumes: - name: secret-mvn 1 mounts: - destinationPath: /opt/app-root/src/.ssh 2 source: type: Secret 3 secret: secretName: my-secret 4 - name: settings-mvn 5 mounts: - destinationPath: /opt/app-root/src/.m2 6 source: type: ConfigMap 7 configMap: name: my-config 8
2.5.2. S2I(Source-to-Image) 빌드
S2I(Source-to-Image)는 재현 가능한 컨테이너 이미지를 빌드하는 툴입니다. 컨테이너 이미지에 애플리케이션 소스를 삽입하고 새 이미지를 어셈블하여 실행할 수 있는 이미지를 생성합니다. 새 이미지는 기본 이미지, 빌더, 빌드 소스를 통합하고 buildah run
명령과 함께 사용할 수 있습니다. S2I는 이전에 다운로드한 종속 항목, 이전에 빌드한 아티팩트 등을 다시 사용하는 증분 빌드를 지원합니다.
2.5.2.1. S2I(Source-to-Image) 증분 빌드 수행
S2I(Source-to-Image)는 증분 빌드를 수행할 수 있으므로 이전에 빌드한 이미지의 아티팩트를 재사용할 수 있습니다.
프로세스
증분 빌드를 생성하려면 전략 정의를 다음과 같이 수정합니다.
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "incremental-image:latest" 1 incremental: true 2
추가 리소스
- 증분 빌드를 지원하는 빌더 이미지를 생성하는 방법에 대한 내용은 S2I 요구 사항을 참조하십시오.
2.5.2.2. S2I(Source-to-Image) 빌더 이미지 스크립트 덮어쓰기
빌더 이미지에서 제공하는 assemble
, run
, save-artifacts
S2I(Source-to-Image) 스크립트를 덮어쓸 수 있습니다.
프로세스
빌더 이미지에서 제공하는 assemble
, run
, save-artifacts
S2I 스크립트를 덮어쓰려면 다음 중 하나를 수행합니다.
-
애플리케이션 소스 리포지토리의
.s2i/bin
디렉터리에assemble
,run
, 또는save-artifacts
스크립트를 제공합니다. 스크립트가 포함된 디렉터리의 URL을 전략 정의의 일부로 제공합니다. 예를 들면 다음과 같습니다.
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "builder-image:latest" scripts: "http://somehost.com/scripts_directory" 1
- 1
- 이 경로에는
run
,assemble
,save-artifacts
가 추가됩니다. 일부 또는 모든 스크립트가 확인되면 해당 스크립트가 이미지에 제공된 동일한 이름의 스크립트 대신 사용됩니다.
scripts
URL에 있는 파일은 소스 리포지토리의 .s2i/bin
에 있는 파일보다 우선합니다.
2.5.2.3. S2I(Source-to-Image) 환경 변수
소스 빌드 프로세스 및 결과 이미지에서 환경 변수를 사용할 수 있도록 하는 방법에는 환경 파일과 BuildConfig 환경 값을 사용하는 것입니다. 제공되는 변수는 빌드 프로세스 중 출력 이미지에 제공됩니다.
2.5.2.3.1. S2I(Source-to-Image) 환경 파일 사용
소스 빌드를 사용하면 소스 리포지토리의 .s2i/environment
파일에 지정하는 방식으로 애플리케이션 내에서 행당 하나씩 환경 값을 설정할 수 있습니다. 이 파일에 지정된 환경 변수는 빌드 프로세스 중 출력 이미지에 제공됩니다.
소스 리포지토리에 .s2i/environment
파일을 제공하는 경우 빌드 중 S2I(Source-to-Image)에서 이 파일을 읽습니다. 그러면 assemble
스크립트에서 이러한 변수를 사용할 수 있으므로 빌드 동작을 사용자 정의할 수 있습니다.
프로세스
예를 들어 빌드 중 Rails 애플리케이션의 자산 컴파일을 비활성화하려면 다음을 수행합니다.
-
.s2i/environment
파일에DISABLE_ASSET_COMPILATION=true
를 추가합니다.
빌드 외에 지정된 환경 변수도 실행 중인 애플리케이션 자체에서 사용할 수 있습니다. 예를 들어 Rails 애플리케이션이 production
대신 development
모드에서 시작되도록 하려면 다음을 수행합니다.
-
RAILS_ENV=development
를.s2i/environment
파일에 추가합니다.
지원되는 환경 변수의 전체 목록은 각 이미지의 이미지 사용 섹션에서 확인할 수 있습니다.
2.5.2.3.2. S2I(Source-to-Image) 빌드 구성 환경 사용
빌드 구성의 sourceStrategy
정의에 환경 변수를 추가할 수 있습니다. 여기에 정의된 환경 변수는 assemble
스크립트를 실행하는 동안 표시되고 출력 이미지에 정의되어 run
스크립트 및 애플리케이션 코드에서도 사용할 수 있습니다.
프로세스
예를 들어 Rails 애플리케이션의 자산 컴파일을 비활성화하려면 다음을 수행합니다.
sourceStrategy: ... env: - name: "DISABLE_ASSET_COMPILATION" value: "true"
추가 리소스
- 빌드 환경 섹션에서는 고급 지침을 제공합니다.
-
oc set env
명령을 사용하면 빌드 구성에 정의된 환경 변수도 관리할 수 있습니다.
2.5.2.4. S2I(Source-to-Image) 소스 파일 무시
S2I(Source-to-Image)는 무시해야 하는 파일 패턴 목록이 포함된 .s2iignore
파일을 지원합니다. .s2iignore
파일에 있는 패턴과 일치하고 다양한 입력 소스에서 제공하는 빌드 작업 디렉터리의 파일은 assemble
스크립트에서 사용할 수 없습니다.
2.5.2.5. S2I(Source-to-Image)를 사용하여 소스 코드에서 이미지 생성
S2I(Source-to-Image)는 애플리케이션 소스 코드를 입력으로 사용하고 어셈블된 애플리케이션을 실행하는 새 이미지를 출력으로 생성하는 이미지를 쉽게 작성할 수 있는 프레임워크입니다.
재현 가능한 컨테이너 이미지를 빌드하는 데 S2I를 사용하는 주요 장점은 개발자가 쉽게 사용할 수 있다는 점입니다. 빌더 이미지 작성자는 이미지에서 최상의 S2I 성능, 빌드 프로세스, S2I 스크립트를 제공하도록 두 가지 기본 개념을 이해해야 합니다.
2.5.2.5.1. S2I(Source-to-Image) 빌드 프로세스 이해
빌드 프로세스는 최종 컨테이너 이미지로 통합되는 다음 세 가지 기본 요소로 구성됩니다.
- 소스
- S2I(Source-to-Image) 스크립트
- 빌더 이미지
S2I는 첫 번째 FROM
명령으로 빌더 이미지가 포함된 Dockerfile을 생성합니다. 그런 다음 S2I에서 생성된 Dockerfile은 Buildah로 전달됩니다.
2.5.2.5.2. S2I(Source-to-Image) 스크립트를 작성하는 방법
스크립트를 빌더 이미지 내에서 실행할 수 있는 경우 모든 프로그래밍 언어로 S2I(Source-to-Image) 스크립트를 작성할 수 있습니다. S2I는 assemble
/run
/save-artifacts
스크립트를 제공하는 다양한 옵션을 지원합니다. 이러한 위치는 모두 다음 순서에 따라 각 빌드에서 확인합니다.
- 빌드 구성에 지정된 스크립트입니다.
-
애플리케이션 소스
.s2i/bin
디렉터리에 있는 스크립트입니다. -
라벨이
io.openshift.s2i.scripts-url
인 기본 이미지 URL에 있는 스크립트입니다.
이미지에 지정된 io.openshift.s2i.scripts-url
라벨과 빌드 구성에 지정된 스크립트 모두 다음 양식 중 하나를 취할 수 있습니다.
-
image:///path_to_scripts_dir
: S2I 스크립트가 있는 디렉터리에 대한 이미지 내부의 절대 경로입니다. -
file:///path_to_scripts_dir
: S2I 스크립트가 있는 호스트의 디렉터리에 대한 상대 또는 절대 경로입니다. -
http(s)://path_to_scripts_dir
: S2I 스크립트가 있는 디렉터리에 대한 URL입니다.
스크립트 | 설명 |
---|---|
|
|
|
|
|
이러한 종속 항목은 |
|
|
|
참고
|
S2I 스크립트의 예
다음 예제 S2I 스크립트는 Bash로 작성됩니다. 각 예에서는 tar
콘텐츠가 /tmp/s2i
디렉터리에 압축 해제되어 있다고 가정합니다.
assemble
스크립트:
#!/bin/bash # restore build artifacts if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then mv /tmp/s2i/artifacts/* $HOME/. fi # move the application source mv /tmp/s2i/src $HOME/src # build application artifacts pushd ${HOME} make all # install the artifacts make install popd
run
스크립트:
#!/bin/bash # run the application /opt/application/run.sh
save-artifacts
스크립트:
#!/bin/bash pushd ${HOME} if [ -d deps ]; then # all deps contents to tar stream tar cf - deps fi popd
usage
스크립트:
#!/bin/bash # inform the user how to use the image cat <<EOF This is a S2I sample builder image, to use it, install https://github.com/openshift/source-to-image EOF
추가 리소스
2.5.2.6. 빌드 볼륨 사용
빌드 볼륨을 마운트하여 출력 컨테이너 이미지에 유지되지 않는 정보에 대한 실행 중인 빌드 액세스 권한을 제공할 수 있습니다.
빌드 볼륨은 리포지토리 자격 증명과 같은 중요한 정보를 제공하며, 빌드 환경 또는 구성에 빌드 시만 있으면 됩니다. 빌드 볼륨은 출력 컨테이너 이미지에 데이터가 지속될 수 있는 빌드 입력 과 다릅니다.
실행 중인 빌드에서 데이터를 읽는 빌드 볼륨의 마운트 지점은 Pod 볼륨 마운트 와 기능적으로 유사합니다.
프로세스
BuildConfig
오브젝트의sourceStrategy
정의에서volumes
배열에 빌드 볼륨을 추가합니다. 예를 들면 다음과 같습니다.spec: sourceStrategy: volumes: - name: secret-mvn 1 mounts: - destinationPath: /opt/app-root/src/.ssh 2 source: type: Secret 3 secret: secretName: my-secret 4 - name: settings-mvn 5 mounts: - destinationPath: /opt/app-root/src/.m2 6 source: type: ConfigMap 7 configMap: name: my-config 8
2.5.3. 사용자 정의 빌드
사용자 정의 빌드 전략을 사용하면 개발자가 전체 빌드 프로세스를 담당하는 특정 빌더 이미지를 정의할 수 있습니다. 자체 빌더 이미지를 사용하면 빌드 프로세스를 사용자 정의할 수 있습니다.
사용자 정의 빌더 이미지는 빌드 프로세스 논리가 포함된 일반 컨테이너 이미지입니다(예: RPM 또는 기본 이미지 빌드).
사용자 정의 빌드는 높은 권한으로 실행되며 기본적으로 사용자에게 제공되지 않습니다. 클러스터 관리 권한이 있는 신뢰할 수 있는 사용자에게만 사용자 정의 빌드를 실행할 수 있는 권한을 부여해야 합니다.
2.5.3.1. 사용자 정의 빌드에 FROM 이미지 사용
customStrategy.from
섹션을 사용하여 사용자 정의 빌드에 사용할 이미지를 표시할 수 있습니다.
프로세스
customStrategy.from
섹션을 설정합니다.strategy: customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder"
2.5.3.2. 사용자 정의 빌드에서 보안 사용
사용자 정의 전략에서는 모든 빌드 유형에 추가할 수 있는 소스 및 이미지 보안 외에 임의의 보안 목록을 빌더 Pod에 추가할 수 있습니다.
프로세스
각 보안을 특정 위치에 마운트하려면
strategy
YAML 파일의secretSource
및mountPath
필드를 편집합니다.strategy: customStrategy: secrets: - secretSource: 1 name: "secret1" mountPath: "/tmp/secret1" 2 - secretSource: name: "secret2" mountPath: "/tmp/secret2"
2.5.3.3. 사용자 정의 빌드에 환경 변수 사용
사용자 정의 빌드 프로세스에서 환경 변수를 사용할 수 있도록 하려면 빌드 구성의 customStrategy
정의에 환경 변수를 추가하면 됩니다.
여기에서 정의한 환경 변수는 사용자 정의 빌드를 실행하는 Pod로 전달됩니다.
프로세스
빌드 중 사용할 사용자 정의 HTTP 프록시를 정의합니다.
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
빌드 구성에 정의된 환경 변수를 관리하려면 다음 명령을 입력합니다.
$ oc set env <enter_variables>
2.5.3.4. 사용자 정의 빌더 이미지 사용
OpenShift Container Platform의 사용자 정의 빌드 전략을 사용하면 전체 빌드 프로세스를 담당하는 특정 빌더 이미지를 정의할 수 있습니다. 패키지, JAR, WAR, 설치 가능한 ZIP 또는 기본 이미지와 같은 개별 아티팩트를 생성하는 빌드가 필요한 경우 사용자 정의 빌드 전략을 사용하는 사용자 정의 빌더 이미지를 사용합니다.
사용자 정의 빌더 이미지는 RPM 또는 기본 컨테이너 이미지와 같은 아티팩트를 구축하는 데 사용되는 빌드 프로세스 논리에 내장된 일반 컨테이너 이미지입니다.
또한 사용자 정의 빌더를 사용하면 단위 테스트 또는 통합 테스트를 실행하는 CI/CD 흐름과 같이 확장된 빌드 프로세스를 구현할 수 있습니다.
2.5.3.4.1. 사용자 정의 빌더 이미지
사용자 정의 빌더 이미지는 호출 시 빌드를 진행하는 데 필요한 정보와 함께 다음 환경 변수를 수신합니다.
변수 이름 | 설명 |
---|---|
|
|
| 빌드할 소스가 있는 Git 리포지토리의 URL입니다. |
|
|
| 빌드할 때 사용할 Git 리포지토리의 하위 디렉터리를 지정합니다. 정의한 경우에만 존재합니다. |
| 빌드할 Git 참조입니다. |
| 이 빌드 오브젝트를 생성한 OpenShift Container Platform 마스터의 버전입니다. |
| 이미지를 내보낼 컨테이너 이미지 레지스트리입니다. |
| 빌드 중인 이미지의 컨테이너 이미지 태그 이름입니다. |
|
|
2.5.3.4.2. 사용자 정의 빌더 워크플로
사용자 정의 빌더 이미지 작성자는 빌드 프로세스를 정의하는 데 유연성이 있지만 빌더 이미지는 OpenShift Container Platform 내에서 빌드를 실행하는 데 필요한 다음 단계를 준수해야 합니다.
-
Build
오브젝트 정의에는 빌드의 입력 매개변수에 대한 모든 필수 정보가 포함되어 있습니다. - 빌드 프로세스를 실행합니다.
- 빌드에서 이미지를 생성하면 빌드의 출력 위치가 정의된 경우 해당 위치로 내보냅니다. 다른 출력 위치는 환경 변수를 통해 전달할 수 있습니다.
2.5.4. 파이프라인 빌드
파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.
OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile
을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.
파이프라인 빌드 전략을 사용하면 개발자가 Jenkins 파이프라인 플러그인에서 사용할 Jenkins 파이프라인을 정의할 수 있습니다. 다른 빌드 유형과 동일한 방식으로 OpenShift Container Platform에서 빌드를 시작, 모니터링, 관리할 수 있습니다.
파이프라인 워크플로는 빌드 구성에 직접 포함하거나 Git 리포지토리에 제공하는 방식으로 jenkinsfile
에 정의하고 빌드 구성에서 참조합니다.
2.5.4.1. OpenShift Container Platform 파이프라인 이해
파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.
OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile
을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.
파이프라인을 사용하면 OpenShift Container Platform에서 애플리케이션의 빌드, 배포, 승격을 제어할 수 있습니다. Jenkins Pipeline 빌드 전략, jenkinsfiles
및 OpenShift Container Platform Domain Specific Language (DSL)의 조합을 사용하여 Jenkins 클라이언트 플러그인에서 제공하는 DSL(OpenShift Container Platform Domain Specific Language)을 사용하면 모든 시나리오에 대해 고급 빌드, 테스트, 배포 및 승격을 수행할 수 있습니다.
OpenShift Container Platform Jenkins 동기화 플러그인
OpenShift Container Platform Jenkins 동기화 플러그인은 Jenkins 작업 및 빌드와 동기화된 빌드 구성 및 빌드 오브젝트를 유지하고 다음 기능을 제공합니다.
- Jenkins에서 동적 작업 및 실행 생성
- 이미지 스트림, 이미지 스트림 태그 또는 구성 맵에서 에이전트 Pod 템플릿 동적 생성
- 환경 변수 할당
- OpenShift Container Platform 웹 콘솔의 파이프라인 시각화
- Jenkins Git 플러그인과의 통합으로 OpenShift Container Platform 빌드의 커밋 정보를 Jenkins Git 플러그인에 전달합니다.
- Jenkins 자격 증명 항목에 시크릿 동기화.
OpenShift Container Platform Jenkins 클라이언트 플러그인
OpenShift Container Platform Jenkins 클라이언트 플러그인은 Jenkins 플러그인 중 하나로, OpenShift Container Platform API 서버와의 다양한 상호 작용을 위해 읽기 쉽고 간결하고 포괄적이며 유창한 Jenkins Pipeline 구문을 제공하기 위한 것입니다. 플러그인은 OpenShift Container Platform 명령줄 툴인 oc
를 사용하는데 스크립트를 실행하는 노드에서 이 툴을 사용할 수 있어야 합니다.
Jenkins 클라이언트 플러그인은 애플리케이션의 jenkinsfile
내에서 OpenShift Container Platform DSL을 사용할 수 있도록 Jenkins 마스터에 설치해야 합니다. 이 플러그인은 OpenShift Container Platform Jenkins 이미지를 사용할 때 기본적으로 설치 및 활성화됩니다.
프로젝트 내 OpenShift Container Platform Pipeline의 경우 Jenkins Pipeline 빌드 전략을 사용해야 합니다. 이 전략에서는 기본적으로 소스 리포지토리의 루트에서 jenkinsfile
을 사용하지만 다음과 같은 구성 옵션을 제공합니다.
-
빌드 구성 내의 인라인
jenkinsfile
필드 -
소스
contextDir
에 상대적으로 사용할jenkinsfile
의 위치를 참조하는, 빌드 구성 내의jenkinsfilePath
필드
선택적 jenkinsfilePath
필드는 소스 contextDir
에 상대적으로 사용할 파일의 이름을 지정합니다. contextDir
이 생략된 경우 기본값은 리포지토리의 루트입니다. jenkinsfilePath
가 생략된 경우 기본값은 jenkinsfile
입니다.
2.5.4.2. 파이프라인 빌드를 위한 Jenkins 파일 제공
파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.
OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile
을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.
jenkinsfile
에서는 표준 Groovy 언어 구문을 사용하여 애플리케이션의 구성, 빌드, 배포를 세부적으로 제어할 수 있습니다.
다음 방법 중 하나로 jenkinsfile
을 제공할 수 있습니다.
- 소스 코드 리포지토리에 있는 파일
-
jenkinsfile
필드를 사용하여 빌드 구성의 일부로 포함
첫 번째 옵션을 사용하는 경우 다음 위치 중 하나의 애플리케이션 소스 코드 리포지토리에 jenkinsfile
을 포함해야 합니다.
-
리포지토리 루트에 있는
jenkinsfile
이라는 파일 -
리포지토리의 소스
contextDir
루트에 있는jenkinsfile
이라는 파일 -
BuildConfig의
JenkinsPipelineStrategy
섹션에 있는jenkinsfilePath
필드를 통해 지정되는 파일 이름(제공되는 경우 소스contextDir
에 상대적이고 제공되지 않는 경우 기본값은 리포지토리의 루트임)
jenkinsfile
은 Jenkins 에이전트 Pod에서 실행됩니다. OpenShift Container Platform DSL을 사용하려면 해당 Pod에 사용 가능한 OpenShift Container Platform 클라이언트 바이너리가 있어야 합니다.
프로세스
다음 중 하나를 수행하여 Jenkins 파일을 제공할 수 있습니다.
- 빌드 구성에 Jenkins 파일 포함
- 빌드 구성에 Jenkins 파일이 포함된 Git 리포지토리에 대한 참조 포함
포함된 정의
kind: "BuildConfig" apiVersion: "v1" metadata: name: "sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: |- node('agent') { stage 'build' openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true') stage 'deploy' openshiftDeploy(deploymentConfig: 'frontend') }
Git 리포지토리에 대한 참조
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "sample-pipeline"
spec:
source:
git:
uri: "https://github.com/openshift/ruby-hello-world"
strategy:
jenkinsPipelineStrategy:
jenkinsfilePath: some/repo/dir/filename 1
- 1
- 선택적
jenkinsfilePath
필드는 소스contextDir
에 상대적으로 사용할 파일의 이름을 지정합니다.contextDir
이 생략된 경우 기본값은 리포지토리의 루트입니다.jenkinsfilePath
가 생략된 경우 기본값은jenkinsfile
입니다.
2.5.4.3. 파이프라인 빌드에 환경 변수 사용
파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.
OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile
을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.
파이프라인 빌드 프로세스에서 환경 변수를 사용할 수 있도록 하려면 빌드 구성의 jenkinsPipelineStrategy
정의에 환경 변수를 추가하면 됩니다.
정의된 환경 변수는 빌드 구성과 관련된 모든 Jenkins 작업의 매개변수로 설정됩니다.
프로세스
빌드 중 사용할 환경 변수를 정의하려면 YAML 파일을 다음과 같이 편집합니다.
jenkinsPipelineStrategy: ... env: - name: "FOO" value: "BAR"
oc set env
명령을 사용하면 빌드 구성에 정의된 환경 변수도 관리할 수 있습니다.
2.5.4.3.1. BuildConfig 환경 변수 및 Jenkins 작업 매개변수 간 매핑
파이프라인 전략 빌드 구성의 변경 사항에 따라 Jenkins 작업이 생성되거나 업데이트되면 빌드 구성의 모든 환경 변수가 Jenkins 작업 매개 변수 정의에 매핑됩니다. 여기서 Jenkins 작업 매개변수 정의의 기본값은 연결된 환경 변수의 현재 값입니다.
Jenkins 작업의 초기 생성 후에도 Jenkins 콘솔에서 작업에 매개변수를 추가할 수 있습니다. 매개변수 이름은 빌드 구성의 환경 변수 이름과 다릅니다. 매개변수는 해당 Jenkins 작업에 대한 빌드가 시작될 때 적용됩니다.
Jenkins 작업의 빌드를 시작하는 방법에 따라 매개변수 설정 방법이 결정됩니다.
-
oc start-build
로 시작하는 경우 빌드 구성의 환경 변수 값은 해당 작업 인스턴스에 설정된 매개변수입니다. Jenkins 콘솔에서 매개변수 기본값을 변경하면 해당 변경 사항이 무시됩니다. 빌드 구성 값이 우선합니다. oc start-build -e
로 시작하는 경우-e
옵션에 지정된 환경 변수의 값이 우선합니다.- 빌드 구성에 나열되지 않은 환경 변수를 지정하면 Jenkins 작업 매개변수 정의로 추가됩니다.
-
Jenkins 콘솔에서 환경 변수에 해당하는 매개변수를 변경하면 해당 변경 사항이 무시됩니다. 빌드 구성 및
oc start-build -e
로 지정하는 항목이 우선합니다.
- Jenkins 콘솔에서 Jenkins 작업을 시작하면 작업의 빌드를 시작하는 과정의 일부로 Jenkins 콘솔을 사용하여 매개변수 설정을 제어할 수 있습니다.
빌드 구성에서 작업 매개변수와 연결할 수 있는 모든 환경 변수를 지정하는 것이 좋습니다. 이렇게 하면 디스크 I/O가 줄어들고 Jenkins 처리 중 성능이 향상됩니다.
2.5.4.4. 파이프라인 빌드 튜토리얼
파이프라인 빌드 전략은 OpenShift Container Platform 4에서 더 이상 사용되지 않습니다. 동등하고 향상된 기능은 Tekton 기반 OpenShift Container Platform Pipelines에 있습니다.
OpenShift Container Platform의 Jenkins 이미지는 완전히 지원되며 사용자는 Jenkins 사용 설명서를 따라 작업에 jenkinsfile
을 정의하거나 소스 제어 관리 시스템에 저장해야 합니다.
이 예제에서는 nodejs-mongodb.json
템플릿을 사용하여 Node.js/MongoDB
애플리케이션을 빌드, 배포, 확인할 OpenShift Container Platform Pipeline을 생성하는 방법을 보여줍니다.
프로세스
Jenkins 마스터를 생성합니다.
$ oc project <project_name>
사용할 프로젝트를 선택하거나
oc new-project <project_name>
을 사용하여 새 프로젝트를 생성합니다.$ oc new-app jenkins-ephemeral 1
영구 스토리지를 사용하려면 대신
jenkins-persistent
를 사용합니다.다음 콘텐츠를 사용하여
nodejs-sample-pipeline.yaml
이라는 파일을 생성합니다.참고이 과정에서 Jenkins Pipeline 전략을 사용하여
Node.js/MongoDB
예제 애플리케이션을 빌드, 배포, 스케일링하는BuildConfig
오브젝트가 생성됩니다.kind: "BuildConfig" apiVersion: "v1" metadata: name: "nodejs-sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: <pipeline content from below> type: JenkinsPipeline
jenkinsPipelineStrategy
를 사용하여BuildConfig
오브젝트를 생성한 후에는 인라인jenkinsfile
을 사용하여 파이프라인에 수행할 작업을 지시합니다.참고이 예에서는 애플리케이션에 대한 Git 리포지토리를 설정하지 않습니다.
다음
jenkinsfile
콘텐츠는 OpenShift Container Platform DSL을 사용하여 Groovy로 작성됩니다. 소스 리포지토리에jenkinsfile
을 포함하는 것이 기본 방법이지만 이 예제에서는 YAML 리터럴 스타일을 사용하여BuildConfig
오브젝트에 인라인 콘텐츠를 포함합니다.def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 1 def templateName = 'nodejs-mongodb-example' 2 pipeline { agent { node { label 'nodejs' 3 } } options { timeout(time: 20, unit: 'MINUTES') 4 } stages { stage('preamble') { steps { script { openshift.withCluster() { openshift.withProject() { echo "Using project: ${openshift.project()}" } } } } } stage('cleanup') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.selector("all", [ template : templateName ]).delete() 5 if (openshift.selector("secrets", templateName).exists()) { 6 openshift.selector("secrets", templateName).delete() } } } } } } stage('create') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.newApp(templatePath) 7 } } } } } stage('build') { steps { script { openshift.withCluster() { openshift.withProject() { def builds = openshift.selector("bc", templateName).related('builds') timeout(5) { 8 builds.untilEach(1) { return (it.object().status.phase == "Complete") } } } } } } } stage('deploy') { steps { script { openshift.withCluster() { openshift.withProject() { def rm = openshift.selector("dc", templateName).rollout() timeout(5) { 9 openshift.selector("dc", templateName).related('pods').untilEach(1) { return (it.object().status.phase == "Running") } } } } } } } stage('tag') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 10 } } } } } } }
- 1
- 사용할 템플릿의 경로입니다.
- 1 2
- 생성할 템플릿의 이름입니다.
- 3
- 이 빌드를 실행할
node.js
에이전트 Pod를 구동합니다. - 4
- 이 파이프라인에 타임아웃을 20분으로 설정합니다.
- 5
- 이 템플릿 라벨이 있는 모든 항목을 삭제합니다.
- 6
- 이 템플릿 라벨을 사용하여 모든 보안을 삭제합니다.
- 7
templatePath
에서 새 애플리케이션을 생성합니다.- 8
- 빌드가 완료될 때까지 최대 5분 동안 기다립니다.
- 9
- 배포가 완료될 때까지 최대 5분 정도 기다립니다.
- 10
- 다른 모든 과정이 성공하면
$ {templateName}:latest
이미지에$ {templateName}-staging:latest
태그를 지정합니다. 스테이징 환경에 대한 파이프라인 빌드 구성에서는$ {templateName}-staging:latest
이미지가 변경될 때까지 기다린 다음 해당 이미지를 스테이징 환경에 배포할 수 있습니다.
참고위 예제는 선언적 파이프라인 스타일로 작성되었지만 기존에 스크립팅된 파이프라인 스타일도 지원됩니다.
OpenShift Container Platform 클러스터에서 파이프라인
BuildConfig
를 생성합니다.$ oc create -f nodejs-sample-pipeline.yaml
자체 파일을 생성하지 않으려면 다음을 실행하여 원래 리포지토리의 샘플을 사용하면 됩니다.
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml
파이프라인을 시작합니다.
$ oc start-build nodejs-sample-pipeline
참고또는 빌드
파이프라인 섹션으로 이동하여 파이프라인 시작을 클릭하거나 Jenkins 콘솔을 방문하여 생성한 파이프라인으로 이동한 다음 지금 빌드를 클릭하여 OpenShift Container Platform 웹 콘솔에서 파이프라인을 시작할 수 있습니다. 파이프라인이 시작되면 프로젝트 내에서 수행되는 다음 작업이 표시되어야 합니다.
- Jenkins 서버에서 작업 인스턴스가 생성됩니다.
- 파이프라인에 필요한 경우 에이전트 Pod가 시작됩니다.
파이프라인은 에이전트 Pod에서 실행되지만 에이전트가 필요하지 않은 경우에는 마스터에서 실행됩니다.
-
template=nodejs-mongodb-example
라벨을 사용하여 이전에 생성한 리소스는 삭제됩니다. -
새 애플리케이션 및 이 애플리케이션의 모든 관련 리소스는
nodejs-mongodb-example
템플릿에서 생성됩니다. nodejs-mongodb-example
BuildConfig
를 사용하여 빌드가 시작됩니다.- 파이프라인은 빌드가 완료될 때까지 기다린 후 다음 단계를 트리거합니다.
배포는
nodejs-mongodb-example
배포 구성을 사용하여 시작됩니다.- 파이프라인은 배포가 완료될 때까지 기다린 후 다음 단계를 트리거합니다.
-
빌드 및 배포가 성공하면
nodejs-mongodb-example:latest
이미지에nodejs-mongodb-example:stage
태그가 지정됩니다.
-
파이프라인에 필요한 경우 에이전트 pod가 삭제됩니다.
참고파이프라인 실행을 시각화하는 가장 좋은 방법은 OpenShift Container Platform 웹 콘솔에서 확인하는 것입니다. 웹 콘솔에 로그인하고 빌드
파이프라인으로 이동하여 파이프라인을 확인할 수 있습니다.
2.5.5. 웹 콘솔을 사용하여 보안 추가
개인 리포지토리에 액세스할 수 있도록 빌드 구성에 보안을 추가할 수 있습니다.
프로세스
OpenShift Container Platform 웹 콘솔에서 개인 리포지토리에 액세스할 수 있도록 빌드 구성에 보안을 추가하려면 다음을 수행합니다.
- 새 OpenShift Container Platform 프로젝트를 생성합니다.
- 개인 소스 코드 리포지토리에 액세스하는 데 필요한 자격 증명이 포함된 보안을 생성합니다.
- 빌드 구성을 생성합니다.
-
빌드 구성 편집기 페이지 또는 웹 콘솔의
빌더 이미지에서 앱 생성
페이지에서 소스 보안을 설정합니다. - 저장을 클릭합니다.
2.5.6. 가져오기 및 내보내기 활성화
빌드 구성에 가져오기 보안을 설정하여 프라이빗 레지스트리로 가져오고 내보내기 보안을 설정하여 내보낼 수 있습니다.
프로세스
프라이빗 레지스트리로 가져오기를 활성화하려면 다음을 수행합니다.
- 빌드 구성에 가져오기 보안을 설정합니다.
내보내기를 활성화하려면 다음을 수행합니다.
- 빌드 구성에 내보내기 보안을 설정합니다.