3.5. 빌드 및 이미지 스트림
3.5.1. 빌드
빌드는 입력 매개 변수를 결과 오브젝트로 변환하는 프로세스입니다. 대부분의 경우 프로세스는 입력 매개변수 또는 소스 코드를 실행 가능한 이미지로 변환하는 데 사용됩니다. BuildConfig 오브젝트는 전체 빌드 프로세스에 대한 정의입니다.
OpenShift Container Platform은 빌드 이미지에서 Docker 형식 컨테이너를 생성하고 컨테이너 이미지 레지스트리로 내보내 Kubernetes를 활용합니다.
빌드 오브젝트는 공통 특성을 공유합니다. 빌드에 대한 입력, 빌드 프로세스를 완료하고, 빌드 프로세스를 로깅하고, 빌드에 성공한 빌드의 리소스를 게시하고, 빌드의 최종 상태를 게시해야 합니다. 빌드에서는 CPU 사용량, 메모리 사용량, 빌드 또는 Pod 실행 시간과 같은 리소스 제한 사항을 활용합니다.
OpenShift Container Platform 빌드 시스템은 빌드 API에 지정된 선택 가능한 유형을 기반으로 하는 빌드 전략에 대한 확장 가능한 지원을 제공합니다. 다음은 세 가지 주요 빌드 전략입니다.
기본적으로 Docker 빌드 및 S2I 빌드가 지원됩니다.
빌드의 결과 오브젝트는 빌드를 생성하는 데 사용된 빌더에 따라 다릅니다. Docker 및 S2I 빌드의 경우 결과 오브젝트는 실행 가능한 이미지입니다. 사용자 정의 빌드의 경우 결과 오브젝트는 빌더 이미지 작성자가 지정한 모든 항목입니다.
또한 Pipeline 빌드 전략을 사용하여 정교한 워크플로를 구현할 수 있습니다.
- 연속 통합
- 연속 배포
빌드 명령 목록은 개발자 가이드를 참조하십시오.
OpenShift Container Platform이 빌드를 위해 Docker를 활용하는 방법에 대한 자세한 내용은 업스트림 문서를 참조하십시오.
3.5.1.1. Docker 빌드
Docker 빌드 전략에서는 Docker 빌드 명령을 호출하므로 실행 가능한 이미지를 생성하기 위해 Dockerfile 및 모든 필수 아티팩트가 있는 리포지토리가 필요합니다.
3.5.1.2. S2I(Source-to-Image) 빌드
S 2I(Source-to-Image) 는 재현 가능한 Docker 형식의 컨테이너 이미지를 빌드하는 툴입니다. 컨테이너 이미지에 애플리케이션 소스를 삽입하고 새 이미지를 어셈블하여 실행할 수 있는 이미지를 생성합니다. 새 이미지는 기본 이미지(빌더)와 빌드된 소스를 통합하며 docker run 명령과 함께 사용할 준비가 되었습니다. S2I는 이전에 다운로드한 종속성, 이전에 빌드한 아티팩트 등을 다시 사용하는 증분 빌드를 지원합니다.
S2I의 장점은 다음과 같습니다.
| 이미지 유연성 |
S2I 스크립트는 기존 에코시스템을 활용하여 거의 모든 Docker 형식의 컨테이너 이미지에 애플리케이션 코드를 삽입하도록 작성할 수 있습니다. 현재 S2I는 |
| 속도 | S2I를 사용하면 각 단계에서 새 계층을 생성하지 않고도 assemble 프로세스에서 많은 수의 복잡한 작업을 수행할 수 있으므로 프로세스가 빨라집니다. 또한 S2I 스크립트는 빌드가 실행될 때마다 다운로드하거나 빌드할 필요 없이 이전 버전의 애플리케이션 이미지에 저장된 아티팩트를 다시 사용하도록 작성할 수 있습니다. |
| 패치 가능성 | 보안 문제로 인해 기본 이미지에 패치가 필요한 경우 S2I를 사용하면 애플리케이션을 일관되게 다시 빌드할 수 있습니다. |
| 운영 효율성 | Dockerfile 에서 허용하므로 임의의 작업을 허용하는 대신 빌드 작업을 제한하면 PaaS 운영자가 실수로 빌드 시스템의 오용을 방지할 수 있습니다. |
| 운영 보안 | 임의의 Dockerfile 을 구축하면 호스트 시스템을 루트 권한 에스컬레이션에 노출합니다. 전체 Docker 빌드 프로세스가 Docker 권한이 있는 사용자로 실행되므로 악의적인 사용자가 악용할 수 있습니다. S2I는 root 사용자로 수행되는 작업을 제한하며 스크립트를 루트가 아닌 사용자로 실행할 수 있습니다. |
| 사용자 효율성 |
S2I를 사용하면 개발자가 임의의 |
| 에코시스템 | S2I는 애플리케이션의 모범 사례를 활용할 수 있는 이미지의 공유 에코시스템을 권장합니다. |
| 재현 가능성 | 생성된 이미지에는 특정 버전의 빌드 툴 및 종속성을 포함하여 모든 입력이 포함될 수 있습니다. 이렇게 하면 이미지를 정확하게 재현할 수 있습니다. |
3.5.1.3. 사용자 정의 빌드
사용자 정의 빌드 전략을 사용하면 개발자가 전체 빌드 프로세스를 담당하는 특정 빌더 이미지를 정의할 수 있습니다. 자체 빌더 이미지를 사용하면 빌드 프로세스를 사용자 정의할 수 있습니다.
사용자 정의 빌더 이미지는 빌드 프로세스 논리에 포함된 일반 Docker 형식 컨테이너 이미지입니다(예: RPM 또는 기본 이미지 빌드). openshift/origin-custom-docker-builder 이미지는 사용자 지정 빌더 이미지의 예제 구현으로 Docker Hub 레지스트리에서 사용할 수 있습니다.
3.5.1.4. 파이프 라인 빌드
파이프라인 빌드 전략을 사용하면 개발자가 Jenkins 파이프라인 플러그인에 의해 실행할 Jenkins 파이프라인을 정의할 수 있습니다. 다른 빌드 유형과 동일한 방식으로 OpenShift Container Platform에서 빌드를 시작, 모니터링, 관리할 수 있습니다.
파이프라인 워크플로는 Jenkinsfile에 정의되거나 빌드 구성에 직접 포함되거나 Git 리포지토리에 제공되고 빌드 구성에서 참조됩니다.
프로젝트에서 Pipeline 전략을 사용하여 빌드 구성을 정의하면 OpenShift Container Platform에서 Jenkins 서버를 인스턴스화하여 파이프라인을 실행합니다. 프로젝트의 이후 파이프라인 빌드 구성은 이 Jenkins 서버를 공유합니다.
Jenkins 서버가 배포되는 방법과 자동 프로비저닝 동작을 구성하거나 비활성화하는 방법에 대한 자세한 내용은 파이프라인 실행 구성을 참조하십시오.
모든 Pipeline 빌드 구성이 삭제되어도 Jenkins 서버가 자동으로 제거되지 않습니다. 사용자가 수동으로 삭제해야 합니다.
Jenkins 파이프라인에 대한 자세한 내용은 Jenkins 설명서 를 참조하십시오.
