OpenShift Container Platform은 애플리케이션을 빌드하고 배포하기 위해 설계되었습니다. 개발 프로세스에서 OpenShift Container Platform과 관련된 크기에 따라 다음을 선택할 수 있습니다.

OpenShift Container Platform을 직접 사용하여 애플리케이션의 개발을 처음부터 시작할 수 있습니다. 이러한 유형의 개발 프로세스를 계획할 때 다음 단계를 고려하십시오.

초기 계획

OpenShift Container Platform에 액세스

개발

generate

관리

verify

가능한 또 다른 애플리케이션 개발 전략은 로컬에서 개발한 다음 OpenShift Container Platform을 사용하여 완전히 개발한 애플리케이션을 배포하는 것입니다. 애플리케이션 코드가 이미 있어야 하는 경우 다음 프로세스를 사용하여 완료되면 OpenShift Container Platform 설치를 빌드하고 배포하십시오.

초기 계획

개발

OpenShift Container Platform에 액세스

generate

verify

관리

OpenShift CLI 또는 웹 콘솔을 사용하여 소스 또는 바이너리 코드, 이미지 및/또는 템플릿을 포함한 구성 요소에서 새 OpenShift Container Platform 애플리케이션을 생성할 수 있습니다.

애플리케이션 승격은 일반적으로 다양한 런타임 환경을 통해 애플리케이션을 이동하는 것을 의미합니다. 예를 들어, 애플리케이션은 결국 프로덕션 환경으로 승격되기 전에 개발 환경에서 시작하여 추가 테스트를 위해 스테이지 환경으로 승격될 수 있습니다. 변경 사항이 애플리케이션에 도입되면 변경 사항이 개발에서 시작되고 단계와 프로덕션 단계를 통해 승격됩니다.

현재 "애플리케이션"은 Java, Perl, Python 등으로 작성된 소스 코드 그 이상입니다. 이제 애플리케이션의 언어별 런타임에 대한 정적 웹 콘텐츠, 통합 스크립트 또는 관련 구성보다 많습니다. 해당 언어별 런타임에서 사용하는 애플리케이션별 아카이브보다 많습니다.

OpenShift Container Platform과 Kubernetes 및 Docker의 통합 기반에서 추가 애플리케이션 아티팩트는 다음과 같습니다.

OpenShift Container Platform에서 애플리케이션을 승격하는 방법을 살펴보면 이 주제는 다음과 같습니다.

이 컨텍스트에서 배포 환경은 CI/CD 파이프라인의 특정 단계에서 애플리케이션을 실행할 수 있는 별도의 공간을 설명합니다. 일반적인 환경에는 개발,테스트,단계, 프로덕션 이 포함됩니다. 환경 경계는 다음과 같은 다양한 방법으로 정의할 수 있습니다.

또한 귀하의 조직은 세 가지를 모두 활용할 수 있습니다.

근본적으로 애플리케이션 승격은 앞서 언급한 애플리케이션 구성 요소를 한 환경에서 다른 환경으로 이동하는 프로세스입니다. 다음 하위 섹션에서는 애플리케이션 승격 자동화에 대한 총체 솔루션에 대해 논의하기 전에 다양한 구성 요소를 직접 이동하는 데 사용할 수 있는 툴을 간략하게 설명합니다.

Docker, Kubernetes 및 OpenShift Container Platform 에코시스템에서 도입한 새 애플리케이션 아티팩트 구성 요소를 정의한 이 섹션에서는 OpenShift Container Platform에서 제공하는 메커니즘 및 툴을 사용하여 환경 간에 해당 구성 요소를 승격하는 방법을 설명합니다.

애플리케이션을 구성하는 구성 요소 중 이미지는 노트의 기본 아티팩트입니다. 이러한 온프레미스를 가져와서 애플리케이션 승격으로 확장하면 코어, 기본 애플리케이션 승격 패턴은 이미지 단위인 이미지 승격 패턴입니다. 대다수의 애플리케이션 승격 시나리오에는 승격 파이프라인을 통해 이미지의 관리 및 전파가 포함됩니다.

간단한 시나리오는 파이프라인을 통해 이미지 관리 및 전파만 처리합니다. 승격 시나리오가 범위를 넓기 때문에 다른 애플리케이션 아티팩트, 특히 API 오브젝트는 파이프라인을 통해 관리 및 전파되는 항목의 인벤토리에 포함됩니다.

이 주제에서는 수동 및 자동화된 접근 방식을 사용하여 이미지뿐만 아니라 API 오브젝트를 승격하는 방법에 대한 몇 가지 구체적인 예를 설명합니다. 그러나 먼저 애플리케이션 승격 파이프라인에 대한 환경 설정 시 다음 사항에 유의하십시오.

웹 콘솔을 사용하여 새 프로젝트를 생성하려면 프로젝트 패널 또는 프로젝트 페이지에서 프로젝트 생성 버튼을 클릭합니다.

Create Project (프로젝트 만들기) 버튼은 기본적으로 표시되지만 선택적으로 숨겨지거나 사용자 지정할 수 있습니다.

CLI를 사용하여 새 프로젝트를 생성하려면 다음을 수행합니다.

$ oc new-project <project_name> \
    --description="<description>" --display-name="<display_name>"

예를 들면 다음과 같습니다.

$ oc new-project hello-openshift \
    --description="This is an example project to demonstrate OpenShift v3" \
    --display-name="Hello OpenShift"

이 주제에서는 MySQL, PostgreSQL 및 MongoDB 데이터베이스 애플리케이션을 OpenShift 버전 2(v2)에서 OpenShift 버전 3(v3)으로 마이그레이션하는 방법을 검토합니다.

지원되는 MySQL 환경 변수

지원되는 PostgreSQL 환경 변수

지원되는 MongoDB 환경 변수

이 주제에서는 Python, Ruby, PHP, Perl, Node.js, WordPress, Ghost, JBoss EAP, JBoss WS(Tomcat) 및 Wildfly 10(JBoss AS) 웹 프레임워크 애플리케이션을 OpenShift 버전 2(v2)에서 OpenShift 버전 3(v3)으로 마이그레이션하는 방법을 검토합니다.

지원되는 Python 버전

지원되는 Ruby 버전

지원되는 PHP 버전

$ oc new-app https://github.com/<github-id>/<repo-name>.git

지원되는 Perl 버전

지원되는 Node.js 버전

WordPress 애플리케이션을 OpenShift Container Platform v3로 마이그레이션하는 방법에 대한 자세한 내용은 OpenShift 블로그를 참조하십시오.

Ghost 애플리케이션을 OpenShift Container Platform v3로 마이그레이션하는 방법에 대한 자세한 내용은 OpenShift 블로그를 참조하십시오.

v2 빠른 시작 v3 빠른 시작에 대한 명확한 마이그레이션 경로는 없지만 현재 v3에서 다음 빠른 시작을 사용할 수 있습니다. oc new-app 을 사용하여 애플리케이션을 생성하는 대신 데이터베이스가 있는 애플리케이션이 있는 경우 oc new-app 을 다시 사용하여 별도의 데이터베이스 서비스를 시작하고 두 개를 공통 환경 변수로 연결하면 다음 중 하나를 사용하여 소스 코드가 포함된 GitHub 리포지토리에서 한 번에 연결된 애플리케이션 및 데이터베이스를 인스턴스화할 수 있습니다. oc get templates -n openshift:를 사용하여 사용 가능한 모든 템플릿을 나열할 수 있습니다.

위의 템플릿 URL 중 하나의 git clone 을 로컬에서 실행합니다. 애플리케이션 소스 코드를 추가하고 커밋하고 GitHub 리포지토리를 내보낸 다음 위에 나열된 템플릿 중 하나에서 v3 빠른 시작 애플리케이션을 시작합니다.

이 주제에서는 OpenShift 버전 2(v2)와 OpenShift 버전 3(v3) 간의 지속적인 통합 및 배포(CI/CD) 애플리케이션의 차이점과 이러한 애플리케이션을 v3 환경으로 마이그레이션하는 방법을 검토합니다.

OpenShift 버전 2(v2) 및 OpenShift 버전 3(v3)의 Jenkins 애플리케이션은 아키텍처의 기본 차이로 인해 다르게 구성됩니다. 예를 들어, v2에서 애플리케이션은 톱니바이너에서 호스팅되는 통합 Git 리포지토리를 사용하여 소스 코드를 저장합니다. v3에서 소스 코드는 Pod 외부에서 호스팅되는 퍼블릭 또는 프라이빗 Git 리포지토리에 있습니다.

또한 OpenShift v3에서는 Jenkins 작업을 소스 코드 변경 사항에 따라 트리거할 수 있을 뿐만 아니라 ImageStream을 변경하면 소스 코드와 함께 애플리케이션을 빌드하는 데 사용되는 이미지가 변경됩니다. 따라서 v3에서 새 Jenkins 애플리케이션을 생성한 다음 OpenShift v3 환경에 적합한 구성으로 작업을 다시 생성하여 Jenkins 애플리케이션을 수동으로 마이그레이션하는 것이 좋습니다.

Jenkins 애플리케이션을 생성하고, 작업을 구성하고, Jenkins 플러그인을 올바르게 사용하는 방법에 대한 자세한 내용은 다음 리소스를 참조하십시오.

이 주제에서는 OpenShift 버전 2(v2)와 OpenShift 버전 3(v3) 간의 웹 후크와 작업 후크의 차이점을 살펴보고 이러한 애플리케이션을 v3 환경으로 마이그레이션하는 방법을 검토합니다.

GitHub에서 Webhook가 성공적으로 구성되었음을 알리는 메시지가 표시됩니다.

이제 GitHub 리포지토리에 변경 사항을 내보낼 때마다 새 빌드가 자동으로 시작되고 빌드가 성공하면 새 배포가 시작됩니다.

OpenShift 버전 2(v2)에는 .openshift/action_hooks 디렉터리에 있는 build, deploy, post_deploy 및 pre_build 스크립트 또는 action_hooks가 있습니다. v3에서 이러한 함수의 일대일 매핑은 없지만 v3의 S2I 툴에 는 지정된 URL 또는 소스 리포지토리의 .s2i/bin 디렉터리에 사용자 지정 가능한 스크립트 를 추가하는 옵션이 있습니다.

OpenShift 버전 3(v3)은 빌드 후 이미지를 기본 테스트 및 레지스트리로 푸시하기 전에 실행 후 빌드 후 후크 를 제공합니다. 배포 후크 는 배포 구성에 구성됩니다.

v2에서 action_hooks는 일반적으로 환경 변수를 설정하는 데 사용됩니다. v2에서 모든 환경 변수는 다음을 사용하여 전달해야 합니다.

$ oc new-app <source-url> -e ENV_VAR=env_var

또는 다음을 수행합니다.

$ oc new-app <template-name> -p ENV_VAR=env_var

또한 다음을 사용하여 환경 변수를 추가하거나 변경할 수 있습니다.

$ oc set env dc/<name-of-dc>
ENV_VAR1=env_var1 ENV_VAR2=env_var2’

S 2I(Source-to-Image) 툴 은 컨테이너 이미지에 애플리케이션 소스 코드를 삽입하고 최종 제품은 빌더 이미지와 빌드 소스 코드를 통합하는 새로운 즉시 실행 가능한 컨테이너 이미지입니다. S2I 툴은 리포지토리에서 OpenShift Container Platform 없이 로컬 머신에 설치할 수 있습니다.

S2I 툴은 OpenShift Container Platform에서 사용하기 전에 애플리케이션 및 이미지를 로컬에서 테스트하고 확인하는 매우 강력한 도구입니다.

이 주제에서는 OpenShift 버전 2(v2) 및 OpenShift 버전 3(v3)에 대해 지원되는 언어, 프레임워크, 데이터베이스 및 마커를 검토합니다.

OpenShift Container Platform 고객이 사용하는 공통 조합에 대한 자세한 내용은 OpenShift Container Platform 테스트 통합을 참조하십시오.

데이터베이스 응용 프로그램 주제의 지원되는 데이터베이스 섹션을 참조하십시오.

빠른 시작은 OpenShift Container Platform에서 실행되는 애플리케이션의 기본 예입니다. 빠른 시작은 다양한 언어와 프레임워크로 제공되며 일련의 서비스, 빌드 구성 및 배포 구성으로 구성된 템플릿으로 정의됩니다. 이 템플릿은 애플리케이션을 빌드하고 배포하는 데 필요한 이미지 및 소스 리포지터리를 참조합니다.

빠른 시작을 살펴보려면 템플릿에서 애플리케이션을 생성합니다. 관리자가 이미 OpenShift Container Platform 클러스터에 이러한 템플릿을 이미 설치했을 수 있으며, 이 경우 간단히 웹 콘솔에서 선택할 수 있습니다. 템플릿을 업로드, 생성 및 수정하는 방법에 대한 자세한 내용은 템플릿 설명서를 참조하십시오.

빠른 시작은 애플리케이션 소스 코드가 포함된 소스 리포지터리를 참조합니다. 빠른 시작을 사용자 지정하려면 리포지터리를 포크하고 템플릿에서 애플리케이션을 생성할 때 기본 소스 리포지토리 이름을 포크된 리포지토리로 대체합니다. 그러면 제공된 소스 예 대신 소스 코드를 사용하여 수행되는 빌드가 생성됩니다. 그런 다음, 소스 리포지터리에서 코드를 업데이트하고 새 빌드를 시작하여 배포된 애플리케이션에 변경 사항이 반영된 것을 확인할 수 있습니다.

이 빠른 시작은 표시된 프레임워크 및 언어의 기본 애플리케이션을 제공합니다.

Ruby on Rails는 Ruby 로 작성된 인기 있는 웹 프레임워크입니다. 이 안내서에서는 OpenShift Container Platform에서 Rails 4를 사용하는 방법을 설명합니다.

이 가이드에서는 다음이 필요합니다.

먼저 OpenShift Container Platform 인스턴스가 실행 중이고 사용 가능한지 확인합니다. OpenShift Container Platform을 시작하고 실행하는 방법에 대한 자세한 내용은 설치 방법을 확인하십시오. 또한 이메일 주소와 암호로 로그인 할 수 있도록 oc CLI 클라이언트가 설치되어 있고 명령 쉘에서 명령에 액세스할 수 있는지 확인합니다.

$ sudo yum install -y postgresql postgresql-server postgresql-devel

$ sudo postgresql-setup initdb

$ sudo systemctl start postgresql.service

$ sudo -u postgres createuser -s rails

Rails 애플리케이션을 처음부터 시작하는 경우 Rails gem을 먼저 설치해야 합니다.

$ gem install rails
Successfully installed rails-4.2.0
1 gem installed

Rails gem을 설치한 후 PostgreSQL을 데이터베이스로 사용하여 새 애플리케이션을 생성합니다.

$ rails new rails-app --database=postgresql

그런 다음 새 애플리케이션 디렉터리로 변경합니다.

$ cd rails-app

이미 애플리케이션이 있으면 pg(postgresql) gem이 Gemfile에 있는지 확인합니다. gem을 추가하여 Gemfile 을 편집하지 않는 경우:

gem 'pg'

모든 종속 항목이 있는 새 Gemfile.lock 을 생성하려면 다음을 실행합니다.

$ bundle install

pg gem과 함께 postgresql 데이터베이스를 사용하는 것 외에도 config/database.yml 에서 postgresql 어댑터를 사용하는지 확인해야 합니다.

config/database.yml 파일의 default 섹션이 다음과 같이 표시되도록 업데이트되었는지 확인합니다.

default: &default
  adapter: postgresql
  encoding: unicode
  pool: 5
  host: localhost
  username: rails
  password:

이 rake 명령을 사용하여 애플리케이션의 개발 및 테스트 데이터베이스를 생성합니다.

$ rake db:create

PostgreSQL 서버에 development 및 test 데이터베이스가 생성됩니다.

$ rails generate controller welcome index

root 'welcome#index'

$ rails server

<% user = ENV.key?("POSTGRESQL_ADMIN_PASSWORD") ? "root" : ENV["POSTGRESQL_USER"] %>
<% password = ENV.key?("POSTGRESQL_ADMIN_PASSWORD") ? ENV["POSTGRESQL_ADMIN_PASSWORD"] : ENV["POSTGRESQL_PASSWORD"] %>
<% db_service = ENV.fetch("DATABASE_SERVICE_NAME","").upcase %>

default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see rails configuration guide
  # http://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV["POSTGRESQL_MAX_CONNECTIONS"] || 5 %>
  username: <%= user %>
  password: <%= password %>
  host: <%= ENV["#{db_service}_SERVICE_HOST"] %>
  port: <%= ENV["#{db_service}_SERVICE_PORT"] %>
  database: <%= ENV["POSTGRESQL_DATABASE"] %>

$ ls -1
app
bin
config
config.ru
db
Gemfile
Gemfile.lock
lib
log
public
Rakefile
README.rdoc
test
tmp
vendor

$ git init
$ git add .
$ git commit -m "initial commit"

$ git remote add origin git@github.com:<namespace/repository-name>.git

$ git push

Ruby on Rails 애플리케이션을 배포하려면 애플리케이션을 위한 새 프로젝트를 생성합니다.

$ oc new-project rails-app --description="My Rails application" --display-name="Rails Application"

rails-app 프로젝트를 생성하면 자동으로 새 프로젝트 네임스페이스로 전환됩니다.

OpenShift Container Platform에서 애플리케이션을 배포하려면 다음 세 단계를 수행해야 합니다.

$ oc new-app postgresql -e POSTGRESQL_DATABASE=db_name -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password

-e POSTGRESQL_ADMIN_PASSWORD=admin_pw

$ oc get pods --watch

$ oc new-app path/to/source/code --name=rails-app -e POSTGRESQL_USER=username -e POSTGRESQL_PASSWORD=password -e POSTGRESQL_DATABASE=db_name -e DATABASE_SERVICE_NAME=postgresql

$ oc get dc rails-app -o json

env": [
    {
        "name": "POSTGRESQL_USER",
        "value": "username"
    },
    {
        "name": "POSTGRESQL_PASSWORD",
        "value": "password"
    },
    {
        "name": "POSTGRESQL_DATABASE",
        "value": "db_name"
    },
    {
        "name": "DATABASE_SERVICE_NAME",
        "value": "postgresql"
    }

],

$ oc logs -f build/rails-app-1

$ oc get pods

$ oc rsh <FRONTEND_POD_ID>

$ RAILS_ENV=production bundle exec rake db:migrate

$ oc expose service rails-app --hostname=www.example.com

Java 및 Maven을 사용하여 애플리케이션을 개발하는 동안 여러 번 구축할 가능성이 높습니다. 포드의 빌드 시간을 단축하기 위해 Maven 종속성을 로컬 Nexus 리포지토리에 캐시할 수 있습니다. 이 튜토리얼에서는 클러스터에 Nexus 리포지토리를 생성하는 방법을 안내합니다.

이 튜토리얼에서는 Maven에 사용하기 위해 이미 설정된 프로젝트로 작업하고 있다고 가정합니다. Java 프로젝트와 함께 Maven을 사용하려면 가이드를 확인하는 것이 좋습니다.

또한 애플리케이션의 이미지에서 Maven 미러 기능을 확인하십시오. Maven을 사용하는 대부분의 이미지에는 이 프로세스를 간소화하는 데 사용할 수 있는 MAVEN_MIRROR_URL 환경 변수가 있습니다. 이 기능이 없는 경우 Nexus 설명서를 읽고 빌드를 올바르게 구성합니다.

또한 각 Pod에서 제대로 작동하는 데 충분한 리소스를 부여해야 합니다. Nexus 배포 구성에서 Pod 템플릿을 편집하여 더 많은 리소스를 요청해야 할 수 있습니다.

다음 단계에서는 새 Nexus 리포지토리를 사용하는 빌드를 정의하는 방법을 보여줍니다. 튜토리얼의 나머지 부분에서는 wildfly-100-centos7 이 있는 이 예제 리포지토리 를 빌더로 사용하지만 이러한 변경 사항이 모든 프로젝트에서 작동해야 합니다.

예제 빌더 이미지는 환경의 일부로 MAVEN_MIRROR_URL 을 지원하므로 이를 사용하여 빌더 이미지를 Nexus 리포지토리로 가리킬 수 있습니다. 이미지가 환경 변수를 사용하여 Maven 미러를 구성하는 것을 지원하지 않는 경우 Nexus 미러를 가리키도록 올바른 Maven 설정을 제공하도록 빌더 이미지를 수정해야 할 수 있습니다.

$ oc new-build openshift/wildfly-100-centos7:latest~https://github.com/openshift/jee-ex.git \
	-e MAVEN_MIRROR_URL='http://nexus.<Nexus_Project>:8081/nexus/content/groups/public'
$ oc logs build/jee-ex-1 --follow

<Nexus_Project> 를 Nexus 리포지토리의 프로젝트 이름으로 바꿉니다. 사용하는 애플리케이션과 동일한 프로젝트에 있는 경우 <Nexus_Project>를 제거할 수 있습니다. OpenShift Container Platform의 DNS 확인에 대해 자세히 알아보십시오.

웹 브라우저에서 http://<NexusIP>:8081/ 6443/content/groups/public 으로 이동하여 애플리케이션의 종속 항목을 저장했는지 확인합니다. 빌드 로그를 확인하여 Maven이 Nexus 미러를 사용하고 있는지 확인할 수도 있습니다. 성공하면 URL http://nexus:8081 을 참조하는 출력이 표시됩니다.

간단한 웹 사이트 또는 복잡한 마이크로 서비스를 생성하는 등 OpenShift Pipelines를 사용하여 OpenShift에서 애플리케이션을 빌드, 테스트, 배포 및 승격합니다.

OpenShift Jenkins 이미지는 표준 Jenkins Pipeline Syntax 외에도 OpenShift Jenkins 클라이언트 플러그인 (OpenShift Jenkins Client Plug-in을 통해) OpenShift Domain Specific Language (DSL)을 제공합니다. OpenShift API 서버와의 풍부한 상호 작용을 위해 읽기 쉽고 간결하며 포괄적이며 유창한 구문을 제공하여 OpenShift 클러스터에서 애플리케이션을 빌드, 배포, 승격을 보다 효과적으로 제어할 수 있습니다.

이 예제에서는 nodejs-mongodb.json 템플릿을 사용하여 Node.js/MongoDB 애플리케이션을 빌드, 배포, 확인하는 OpenShift Pipeline을 생성하는 방법을 보여줍니다.

Jenkins 마스터를 생성하려면 다음을 실행합니다.

  $ oc project <project_name> 1
  $ oc new-app jenkins-ephemeral 2

이제 Jenkins 마스터가 가동되어 실행 중이므로 Jenkins 파이프라인 전략을 사용하여 Node.js/MongoDB 예제 애플리케이션을 빌드, 배포, 스케일링하는 BuildConfig를 생성합니다.

다음 콘텐츠를 사용하여 nodejs-sample-pipeline.yaml이라는 파일을 생성합니다.

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 DSL을 사용하여 Groovy로 작성됩니다. 소스 리포지토리에 jenkinsfile 을 포함하는 것이 기본 방법이지만 이 예제에서는 YAML 리터럴 스타일 을 사용하여 BuildConfig에 인라인 콘텐츠를 포함합니다.

완료된 BuildConfig는 예제 디렉터리 nodejs-sample-pipeline.yaml 의 OpenShift Origin 리포지토리에서 볼 수 있습니다.

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().latest()
                  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
                }
            }
        }
      }
    }
  }
}

다음을 실행하여 OpenShift 클러스터에 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

여기에서 사용되는 OpenShift DSL 구문에 대한 자세한 내용은 OpenShift Jenkins 클라이언트 플러그인 을 참조하십시오.

다음 명령을 사용하여 파이프라인을 시작합니다.

$ oc start-build nodejs-sample-pipeline

파이프라인이 시작되면 프로젝트 내에서 수행되는 다음 작업이 표시되어야 합니다.

OpenShift Pipelines를 사용하면 한 프로젝트에서 Jenkins를 시작한 다음 OpenShift 동기화 플러그인이 개발자가 작업하는 프로젝트 그룹을 모니터링할 수 있습니다. 다음 섹션에서는 이 프로세스를 완료하는 단계를 간략하게 설명합니다.

OpenShift의 바이너리 빌드 기능을 사용하면 개발자가 Git 리포지토리 URL에서 빌드를 가져오는 대신 소스 또는 아티팩트를 빌드에 직접 업로드할 수 있습니다. 소스, Docker 또는 사용자 정의 전략이 있는 BuildConfig는 바이너리 빌드로 시작할 수 있습니다. 로컬 아티팩트에서 빌드를 시작하면 기존 소스 참조가 로컬 사용자 머신에서 들어오는 소스로 교체됩니다.

소스는 start-build 명령을 사용할 때 사용 가능한 인수에 해당하는 여러 가지 방법으로 제공될 수 있습니다.

다음 튜토리얼에서는 OpenShift 클러스터를 사용할 수 있고 아티팩트를 생성할 수 있는 프로젝트가 있다고 가정합니다. git 과 oc 를 로컬에서 사용할 수 있어야 합니다.

$ git checkout -b my_branch
$ git add .
$ git commit -m "My changes"
$ oc start-build ruby-hello-world --from-repo="." --follow

OpenShift Container Platform의 빌드 는 입력 매개변수를 결과 오브젝트로 변환하는 프로세스입니다. 대부분의 경우 빌드는 소스 코드를 실행 가능한 컨테이너 이미지로 변환하는 데 사용됩니다.

빌드 구성 또는 BuildConfig 는 빌드 전략 및 하나 이상의 소스가 특징입니다. 전략은 앞서 언급한 프로세스를 결정하는 반면 소스는 입력을 제공합니다.

빌드 전략은 다음과 같습니다.

그리고 빌드 입력으로 제공될 수 있는 6가지 유형의 소스가 있습니다.

각 빌드 전략은 특정 유형의 소스를 고려하거나 무시하고 이를 사용하는 방법을 결정하는 데 달려 있습니다. 바이너리 및 Git은 함께 사용할 수 없는 소스 유형입니다. Dockerfile 및 이미지는 서로 또는 Git 또는 Binary와 함께 사용할 수 있습니다. Binary 소스 유형은 시스템에 지정되는 방법의 다른 옵션에서 고유합니다.

빌드 구성은 단일 빌드 정의와 새 빌드를 생성해야 할 때의 트리거 세트를 설명합니다. 빌드 구성은 BuildConfig에 의해 정의되는데 BuildConfig는 새 인스턴스를 생성하기 위해 API 서버에 대한 POST에 사용할 수 있는 REST 오브젝트입니다.

OpenShift Container Platform을 사용하여 애플리케이션을 생성하기 위해 선택하는 방법에 따라 BuildConfig는 일반적으로 웹 콘솔 또는 CLI를 사용하는 경우 자동으로 생성되며 언제든지 편집할 수 있습니다. BuildConfig 를 구성하는 부분과 사용 가능한 옵션을 이해하면 나중에 구성을 수동으로 조정하도록 선택하는 경우 도움이 될 수 있습니다.

다음 예제 BuildConfig에서는 컨테이너 이미지 태그 또는 소스 코드가 변경될 때마다 새 빌드를 생성합니다.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "ruby-sample-build" 1
spec:
  runPolicy: "Serial" 2
  triggers: 3
    -
      type: "GitHub"
      github:
        secret: "secret101"
    - type: "Generic"
      generic:
        secret: "secret101"
    -
      type: "ImageChange"
  source: 4
    git:
      uri: "https://github.com/openshift/ruby-hello-world"
  strategy: 5
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "ruby-20-centos7:latest"
  output: 6
    to:
      kind: "ImageStreamTag"
      name: "origin-ruby-sample:latest"
  postCommit: 7
      script: "bundle exec rake test"

다음 명령을 사용하여 현재 프로젝트의 기존 빌드 구성에서 새 빌드를 수동으로 시작합니다.

$ oc start-build <buildconfig_name>

--from-build 플래그를 사용하여 빌드를 다시 실행합니다.

$ oc start-build --from-build=<build_name>

--follow 플래그를 지정하여 빌드 로그를 stdout에서 스트리밍합니다.

$ oc start-build <buildconfig_name> --follow

빌드에 원하는 환경 변수를 설정하려면 --env 플래그를 지정합니다.

$ oc start-build <buildconfig_name> --env=<key>=<value>

빌드에 Git 소스 가져오기 또는 Dockerfile을 사용하는 대신 소스를 직접 내보내 빌드를 시작할 수 있습니다. 소스는 Git 또는 SVN 작업 디렉터리, 배포하려는 사전 빌드된 바이너리 아티팩트 세트 또는 단일 파일의 콘텐츠일 수 있습니다. 이 작업은 start-build 명령에 다음 옵션 중 하나를 지정하여 수행할 수 있습니다.

이러한 옵션을 빌드에 직접 전달하면 해당 콘텐츠가 빌드로 스트리밍되어 현재 빌드 소스 설정을 덮어씁니다.

예를 들어 다음 명령은 로컬 Git 리포지토리의 콘텐츠를 태그 v2 의 아카이브로 전송하고 빌드를 시작합니다.

$ oc start-build hello-world --from-repo=../hello-world --commit=v2

웹 콘솔을 사용하거나 다음 CLI 명령을 사용하여 빌드를 수동으로 취소합니다.

$ oc cancel-build <build_name>

동시에 여러 빌드를 취소합니다.

$ oc cancel-build <build1_name> <build2_name> <build3_name>

빌드 구성에서 생성된 모든 빌드를 취소합니다.

$ oc cancel-build bc/<buildconfig_name>

지정된 상태(예: new 또는 pending)의 빌드를 모두 취소하고 다른 상태의 빌드를 무시합니다.

$ oc cancel-build bc/<buildconfig_name>  --state=<state>

다음 명령을 사용하여 BuildConfig 를 삭제합니다.

$ oc delete bc <BuildConfigName>

또한 이 BuildConfig 에서 인스턴스화한 모든 빌드도 삭제됩니다. 빌드를 삭제하지 않으려면 --cascade=false 플래그를 지정합니다.

$ oc delete --cascade=false bc <BuildConfigName>

웹 콘솔을 사용하거나 oc describe CLI 명령을 사용하여 빌드 세부 정보를 볼 수 있습니다.

$ oc describe build <build_name>

다음과 같은 정보가 표시됩니다.

빌드에서 Docker 또는 Source 전략을 사용하는 경우 oc describe 출력에 커밋 ID, 작성자, 커밋, 메시지 등 해당 빌드에 사용된 소스 리버전 정보도 포함됩니다.

웹 콘솔 또는 CLI를 사용하여 빌드 로그에 액세스할 수 있습니다.

빌드를 직접 사용하여 로그를 스트리밍하려면 다음을 수행합니다.

$ oc logs -f build/<build_name>

빌드 구성에 대한 최신 빌드 로그를 스트리밍하려면 다음을 수행합니다.

$ oc logs -f bc/<buildconfig_name>

빌드 구성에 대한 지정된 버전 빌드의 로그를 반환하려면 다음을 수행합니다.

$ oc logs --version=<number> bc/<buildconfig_name>

로그 Verbosity

더 세부적인 출력을 제공하기 위해 BuildConfig에서 sourceStrategy 또는 dockerStrategy의 일부로 BUILD_LOGLEVEL 환경 변수를 전달합니다.

sourceStrategy:
...
  env:
    - name: "BUILD_LOGLEVEL"
      value: "2" 1

소스 빌드에 사용 가능한 로그 수준은 다음과 같습니다.

빌드 입력 은 빌드가 작동하도록 소스 콘텐츠를 제공합니다. OpenShift Container Platform에서 소스를 제공하는 방법은 여러 가지가 있습니다. 우선순위 순서대로 다음을 수행합니다.

다양한 입력을 단일 빌드로 결합할 수 있습니다. 인라인 Dockerfile이 우선하므로 다른 입력에서 제공하는 Dockerfile 이라는 다른 파일을 덮어쓸 수 있습니다. 바이너리(local) 입력과 Git 리포지토리는 서로 함께 사용할 수 없는 입력입니다.

입력 보안은 빌드 중 사용한 특정 리소스 또는 인증 정보를 빌드에서 생성한 최종 애플리케이션 이미지에서 사용할 수 있도록 하거나 Secret 리소스에 정의된 값을 사용하려는 경우에 유용합니다. 외부 아티팩트를 사용하면 기타 빌드 입력 유형 중 하나로 사용할 수 없는 추가 파일을 가져올 수 있습니다.

빌드가 실행될 때마다 다음을 수행합니다.

다음 소스 정의 예제에는 다양한 입력 유형 및 이러한 유형이 결합되는 방법에 대한 설명이 포함되어 있습니다. 각 입력 유형이 정의되는 방법에 대한 자세한 내용은 각 입력 유형별 섹션을 참조하십시오.

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git 1
  images:
  - from:
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths:
    - destinationDir: app/dir/injected/dir 2
      sourcePath: /usr/lib/somefile.jar
  contextDir: "app/dir" 3
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 4

dockerfile 값이 제공되면 이 필드의 내용은 Dockerfile 이라는 파일로 디스크에 작성됩니다. 이 작업은 다른 입력 소스를 처리한 후 수행되므로 입력 소스 리포지토리에 루트 디렉터리에 Dockerfile 이 포함된 경우 이 콘텐츠를 덮어씁니다.

이 필드의 일반적인 사용은 Docker 전략 빌드에 Dockerfile 을 제공하는 것입니다.

소스 정의는 BuildConfig에 있는 spec 섹션의 일부입니다.

source:
  dockerfile: "FROM centos:7\nRUN yum install -y httpd" 1

이미지를 통해 빌드 프로세스에 추가 파일을 제공할 수 있습니다. 입력 이미지는 From 및 To 이미지 타겟을 정의하는 방식과 동일한 방식으로 참조합니다. 즉 컨테이너 이미지와 이미지 스트림 태그 를 모두 참조할 수 있습니다. 이미지와 함께 이미지를 복사할 파일 또는 디렉터리의 경로와 빌드 컨텍스트에서 해당 이미지를 배치할 대상을 나타내는 하나 이상의 경로 쌍을 제공해야 합니다.

소스 경로는 지정된 이미지 내의 모든 절대 경로일 수 있습니다. 대상은 상대 디렉터리 경로여야 합니다. 빌드 시 이미지가 로드되고 표시된 파일과 디렉터리가 빌드 프로세스의 컨텍스트 디렉터리로 복사됩니다. 이는 소스 리포지토리 콘텐츠(있는 경우)가 복제되는 것과 동일한 디렉터리입니다. 소스 경로가 /. 로 종료되면 디렉터리의 콘텐츠가 복사되지만 디렉터리 자체는 대상에 생성되지 않습니다.

이미지 입력은 BuildConfig의 source 정의에 지정됩니다.

source:
  git:
    uri: https://github.com/openshift/ruby-hello-world.git
  images: 1
  - from: 2
      kind: ImageStreamTag
      name: myinputimage:latest
      namespace: mynamespace
    paths: 3
    - destinationDir: injected/dir 4
      sourcePath: /usr/lib/somefile.jar 5
  - from:
      kind: ImageStreamTag
      name: myotherinputimage:latest
      namespace: myothernamespace
    pullSecret: mysecret 6
    paths:
    - destinationDir: injected/dir
      sourcePath: /usr/lib/somefile.jar

지정된 경우 소스 코드가 제공된 위치에서 가져옵니다.

인라인 Dockerfile을 제공하면 Git 리포지토리의 contextDir 에 있는 Dockerfile (있는 경우)을 덮어씁니다.

소스 정의는 BuildConfig에 있는 spec 섹션의 일부입니다.

source:
  git: 1
    uri: "https://github.com/openshift/ruby-hello-world"
    ref: "master"
  contextDir: "app/dir" 2
  dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3

ref 필드가 가져오기 요청을 나타내는 경우 시스템은 git fetch 작업을 사용한 다음 FETCH_HEAD 를 확인합니다.

ref 값을 제공하지 않으면 OpenShift Container Platform에서 부분 복제(--depth=1)를 수행합니다. 이 경우 기본 분기(일반적으로 master)의 최근 커밋과 관련된 파일만 다운로드됩니다. 그러면 리포지토리는 더 빠르게 다운로드되지만 전체 커밋 내역은 다운로드되지 않습니다. 지정된 리포지토리의 기본 분기에 대한 전체 git clone을 수행하려면 기본 분기(예: master)의 이름을 ref로 설정합니다.

source:
  git:
    uri: "https://github.com/openshift/ruby-hello-world"
    httpProxy: http://proxy.example.com
    httpsProxy: https://proxy.example.com
    noProxy: somedomain.com, otherdomain.com

$ oc secrets link builder mysecret

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'

kind: Secret
apiVersion: v1
metadata:
  name: matches-all-corporate-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/*
data:
  ...

kind: Secret
apiVersion: v1
metadata:
  name: override-for-my-dev-servers-https-only
  annotations:
    build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/*
    build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/*
data:
  ...

$ oc annotate secret mysecret \
    'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"
  source:
    git:
      uri: "https://github.com/user/app.git"
    sourceSecret:
      name: "basicsecret"
  strategy:
    sourceStrategy:
      from:
        kind: "ImageStreamTag"
        name: "python-33-centos7:latest"

$ oc set build-secret --source bc/sample-build basicsecret

$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>

[http]
        sslVerify=false

$ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --type=kubernetes.io/basic-auth

$ oc create secret generic <secret_name> \
    --from-literal=password=<token> \
    --type=kubernetes.io/basic-auth

$ ssh-keygen -t rsa -C "your_email@example.com"

$ oc create secret generic <secret_name> \
    --from-file=ssh-privatekey=<path/to/ssh/private/key> \
    --from-file=<path/to/known_hosts> \ 1
    --type=kubernetes.io/ssh-auth

로컬 파일 시스템의 콘텐츠를 빌더로 스트리밍하는 것을 Binary 빌드라고 합니다. 이러한 빌드의 경우 BuildConfig.spec.source.type 의 해당 값은 Binary 입니다.

이 소스 유형은 oc start-build를 사용할 때만 활용하므로 고유합니다.

바이너리 빌드를 사용하려면 다음 옵션 중 하나를 사용하여 oc start-build를 호출합니다.

위의 각 사례에서 다음을 수행합니다.

HTTP 또는 HTTPS 스키마를 사용하여 파일 이름 대신 URL을 --from-file 및 --from-archive로 전달할 수 있습니다. URL과 함께 --from-file을 사용하는 경우 빌더 이미지의 파일 이름은 웹 서버에서 전송한 Content-Disposition 헤더 또는 헤더가 없는 경우 URL 경로의 마지막 구성 요소에 따라 결정됩니다. 지원되는 인증 형식이 없는 경우 사용자 정의 TLS 인증서를 사용하거나 인증서 검증 작업을 비활성화할 수 없습니다.

oc new-build --binary=true를 사용하면 명령에서 바이너리 빌드와 관련된 제한을 적용합니다. 생성된 BuildConfig 에는 소스 유형이 Binary 이므로 이 BuildConfig 에 대한 빌드를 실행하는 유일한 방법은 --from 옵션 중 하나와 함께 oc start-build 를 사용하여 필수 바이너리 데이터를 제공하는 것입니다.

dockerfile 및 contextDir 소스 옵션에 는 바이너리 빌드에서 특별한 의미가 있습니다.

Dockerfile 은 바이너리 빌드 소스와 함께 사용할 수 있습니다. dockerfile 을 사용하고 바이너리 스트림이 아카이브인 경우 해당 콘텐츠는 아카이브의 모든 Dockerfile에 대한 대체 Dockerfile 역할을 합니다. dockerfile 을 --from-file 인수와 함께 사용하고 파일 인수의 이름이 dockerfile 이면 dockerfile 의 값이 바이너리 스트림의 값을 대체합니다.

추출된 아카이브 콘텐츠를 캡슐화하는 바이너리 스트림의 경우 contextDir 필드의 값이 아카이브 내 하위 디렉터리로 해석되고, 유효한 경우 빌드를 실행하기 전에 빌더가 해당 하위 디렉터리로 변경됩니다.

일부 시나리오에서는 빌드 작업을 수행하려면 종속 리소스에 액세스하기 위해 자격 증명 또는 기타 구성 데이터가 필요합니다. 그러나 이러한 정보가 소스 제어에 배치되는 것은 바람직하지 않습니다. 이러한 목적으로 입력 보안 및 입력 ConfigMap을 정의할 수 있습니다.

예를 들어 Maven을 통해 Java 애플리케이션을 빌드할 때 개인 키를 통해 액세스하는 Maven Central 또는 JCenter의 개인 미러를 설정할 수 있습니다. 프라이빗 미러에서 라이브러리를 다운로드하려면 다음을 제공해야 합니다.

보안상의 이유로 애플리케이션 이미지에 자격 증명을 노출해서는 안 됩니다.

이 예제에서는 Java 애플리케이션을 설명하지만 /etc/ssl/certs 디렉터리, API 키 또는 토큰, 라이센스 파일 등에 SSL 인증서를 추가하는 데 동일한 접근 방식을 사용할 수 있습니다.

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn” \
    --build-config-map "settings-mvn"

source:
  git:
    uri: https://github.com/wildfly/quickstart.git
  contextDir: helloworld
  configMaps:
    - configMap:
        name: settings-mvn
      destinationDir: ".m2"
  secrets:
    - secret:
        name: secret-mvn
      destinationDir: ".ssh"

$ oc new-build \
    openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \
    --context-dir helloworld --build-secret “secret-mvn:.ssh” \
    --build-config-map "settings-mvn:.m2"

FROM centos/ruby-22-centos7

USER root
COPY ./secret-dir /secrets
COPY ./config /

# Create a shell script that will output secrets and ConfigMaps when the image is run
RUN echo '#!/bin/sh' > /input_report.sh
RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh
RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh
RUN chmod 755 /input_report.sh

CMD ["/bin/sh", "-c", "/input_report.sh"]

바이너리 파일을 소스 리포지토리에 저장하지 않는 것이 좋습니다. 따라서 빌드 프로세스 중 추가 파일(예: Java .jar 종속성)을 가져오는 빌드를 정의해야 합니다. 이 작업을 수행하는 방법은 사용 중인 빌드 전략에 따라 다릅니다.

소스 빌드 전략의 경우 assemble 스크립트에 적절한 쉘 명령을 배치해야 합니다.

#!/bin/sh
APP_VERSION=1.0
wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

#!/bin/sh
exec java -jar app.jar

Docker 빌드 전략의 경우 Dockerfile 을 수정하고 RUN 명령으로 쉘 명령을 호출해야 합니다.

FROM jboss/base-jdk:8

ENV APP_VERSION 1.0
RUN wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar

EXPOSE 8080
CMD [ "java", "-jar", "app.jar" ]

실제로 Dockerfile 또는 assemble 스크립트를 업데이트하는 대신 BuildConfig 에 정의된 환경 변수를 사용하여 다운로드할 특정 파일을 사용자 지정할 수 있도록 파일 위치에 대한 환경 변수를 사용할 수 있습니다.

다음과 같이 환경 변수를 정의하는 다양한 방법 중에서 선택할 수 있습니다.

개인 컨테이너 레지스트리에 유효한 인증 정보를 사용하여 .docker/config.json 파일을 사용하여 빌드를 제공할 수 있습니다. 이 경우 출력 이미지를 개인 컨테이너 이미지 레지스트리로 내보내거나 인증이 필요한 개인 컨테이너 이미지 레지스트리에서 빌더 이미지를 가져올 수 있습니다.

.docker/config.json 파일은 기본적으로 홈 디렉터리에 있으며 다음과 같은 형식입니다.

auths:
  https://index.docker.io/v1/: 1
    auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 2
    email: "user@example.com" 3

이 파일에서 여러 컨테이너 이미지 레지스트리 항목을 정의할 수 있습니다. 또는 docker login 명령을 실행하여 이 파일에 인증 항목을 추가할 수도 있습니다. 파일이 없는 경우 생성됩니다.

Kubernetes는 구성 및 암호를 저장하는 데 사용할 수 있는 Secret 오브젝트를 제공합니다.

Docker 또는 Source 전략을 사용하는 빌드로 인해 새 컨테이너 이미지가 생성됩니다. 그런 다음 이미지를 Build 사양의 output 섹션에 지정된 컨테이너 이미지 레지스트리로 푸시됩니다.

출력 종류가 ImageStreamTag 인 경우 이미지를 통합 OpenShift Container Platform 레지스트리로 푸시하고 지정된 이미지 스트림에 태그를 지정합니다. 출력 유형이 DockerImage 인 경우 출력 참조의 이름이 Docker 내보내기 사양으로 사용됩니다. 사양은 레지스트리를 포함할 수 있으며 레지스트리가 지정되지 않은 경우 기본적으로 DockerHub로 설정됩니다. 빌드 사양의 출력 섹션이 비어 있으면 빌드 종료 시 이미지를 푸시하지 않습니다.

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "sample-image:latest"

spec:
  output:
    to:
      kind: "DockerImage"
      name: "my-registry.mycompany.com:5000/myimages/myimage:tag"

Docker 및 Source 전략 빌드에서는 출력 이미지에 다음 환경 변수를 설정합니다.

또한 모든 사용자 정의 환경 변수(예: Source 또는 Docker 전략 옵션을 통해 구성된 환경 변수)도 출력 이미지 환경 변수 목록의 일부입니다.

Docker 및 소스 빌드에서는 출력 이미지에 다음 라벨을 설정합니다.

BuildConfig.spec.output.imageLabels 필드를 사용하여 BuildConfig 에서 빌드된 각 이미지에 적용할 사용자 정의 라벨 목록을 지정할 수도 있습니다.

spec:
  output:
    to:
      kind: "ImageStreamTag"
      name: "my-image:latest"
    imageLabels:
    - name: "vendor"
      value: "MyCompany"
    - name: "authoritative-source-url"
      value: "registry.mycompany.com"

빌드 이미지는 다이제스트 로 고유하게 식별할 수 있으며, 나중에 현재 태그에 관계없이 다이제스트로 이미지를 가져오는 데 사용할 수 있습니다.

Docker 및 소스 빌드는 이미지를 레지스트리로 내보낸 후 Build.status.output.to.imageDigest 에 다이제스트를 저장합니다. 다이제스트는 레지스트리에 의해 계산됩니다. 따라서 레지스트리가 다이제스트를 반환하지 않았거나 빌더 이미지가 해당 형식을 이해하지 못하는 경우와 같이 존재하지 않는 경우가 있을 수 있습니다.

status:
  output:
    to:
      imageDigest: sha256:29f5d56d12684887bdfa50dcd29fc31eea4aaf4ad3bec43daf19026a7ce69912

이미지를 개인 컨테이너 이미지 레지스트리로 푸시하려면 시크릿을 사용하여 인증 정보를 제공할 수 있습니다. 자세한 내용은 Build Inputs 를 참조하십시오.

다음 옵션은 S2I 빌드 전략에 따라 다릅니다.

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "builder-image:latest" 1
    forcePull: true 2

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "incremental-image:latest" 1
    incremental: true 2

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "builder-image:latest"
    scripts: "http://somehost.com/scripts_directory" 1

sourceStrategy:
...
  env:
    - name: "DISABLE_ASSET_COMPILATION"
      value: "true"

다음 옵션은 Docker 빌드 전략에 따라 다릅니다.

strategy:
  dockerStrategy:
    from:
      kind: "ImageStreamTag"
      name: "debian:latest"

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

strategy:
  dockerStrategy:
    noCache: true

strategy:
  dockerStrategy:
    forcePull: true 1

dockerStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

dockerStrategy:
...
  buildArgs:
    - name: "foo"
      value: "bar"

다음 옵션은 사용자 정의 빌드 전략에 따라 다릅니다.

strategy:
  customStrategy:
    from:
      kind: "DockerImage"
      name: "registry.access.redhat.com/openshift3/ose-docker-builder"

strategy:
  customStrategy:
    exposeDockerSocket: true

strategy:
  customStrategy:
    secrets:
      - secretSource: 1
          name: "secret1"
        mountPath: "/tmp/secret1" 2
      - secretSource:
          name: "secret2"
        mountPath: "/tmp/secret2"

strategy:
  customStrategy:
    forcePull: true 1

customStrategy:
...
  env:
    - name: "HTTP_PROXY"
      value: "http://myproxy.net:5187/"

다음 옵션은 Pipeline 빌드 전략에 따라 다릅니다.

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')
        }

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

jenkinsPipelineStrategy:
...
  env:
    - name: "FOO"
      value: "BAR"

Pod 환경 변수와 마찬가지로 빌드 환경 변수는 Downward API를 사용하여 다른 리소스/변수에 대한 참조 측면에서 정의할 수 있습니다. 그러나 아래에 언급된 몇 가지 예외가 있습니다.

값을 가져올 필드의 JsonPath에 fieldPath 환경 변수 소스를 설정하면 빌드 오브젝트에 대한 정보를 삽입할 수 있습니다.

env:
  - name: FIELDREF_ENV
    valueFrom:
      fieldRef:
        fieldPath: metadata.name

빌드 환경 변수에서 valueFrom을 사용하여 컨테이너 리소스를 참조하는 기능은 컨테이너를 생성하기 전에 참조를 확인하기 때문에 지원되지 않습니다.

valueFrom 구문을 사용하여 Secrets의 키 값을 환경 변수로 사용할 수 있습니다.

apiVersion: v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: MYVAL
        valueFrom:
          secretKeyRef:
            key: myval
            name: mysecret

BuildConfig를 정의할 때 BuildConfig를 실행해야 하는 상황을 제어하기 위해 트리거를 정의할 수 있습니다. 다음과 같은 빌드 트리거를 사용할 수 있습니다.

Webhook 트리거를 사용하면 OpenShift Container Platform API 끝점에 요청을 전송하여 새 빌드를 트리거할 수 있습니다. GitHub,GitLab,Bitbucket 또는 Generic Webhook를 사용하여 이러한 트리거를 정의할 수 있습니다.

OpenShift Container Platform Webhook는 현재 각 Git 기반 소스 코드 관리 시스템(SCM)에 대해 유사한 버전의 푸시 이벤트만 지원합니다. 기타 모든 이벤트 유형은 무시됩니다.

내보내기 이벤트가 처리되면 이벤트 내부의 분기 참조가 해당 BuildConfig 의 분기 참조와 일치하는지 여부에 대한 확인이 수행됩니다. 일치하는 경우 웹 후크 이벤트에 명시된 정확한 커밋 참조가 OpenShift Container Platform 빌드에 대해 검사됩니다. 일치하지 않는 경우에는 빌드가 트리거되지 않습니다.

모든 Webhook에 대해 WebHook Secret Key 라는 키와 Webhook를 호출할 때 제공할 값이 되는 값으로 보안을 정의해야 합니다. 그런 다음 Webhook 정의에서 보안을 참조해야 합니다. 보안을 사용하면 URL의 고유성이 보장되어 다른 사용자가 빌드를 트리거할 수 없습니다. 키 값은 Webhook 호출 중에 제공된 보안과 비교됩니다.

예를 들면 아래 예제에는 mysecret이라는 보안에 대한 참조가 포함된 GitHub Webhook가 있습니다.

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

그런 다음 보안이 다음과 같이 정의됩니다. 보안 값은 Secret 오브젝트의 data 필드에 필요하므로 base64로 인코딩됩니다.

- kind: Secret
  apiVersion: v1
  metadata:
    name: mysecret
    creationTimestamp:
  data:
    WebHookSecretKey: c2VjcmV0dmFsdWUx

type: "GitHub"
github:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

$ curl -H "X-GitHub-Event: push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github

type: "GitLab"
gitlab:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

$ curl -H "X-GitLab-Event: Push Hook" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab

type: "Bitbucket"
bitbucket:
  secretReference:
    name: "mysecret"

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

$ curl -H "X-Event-Key: repo:push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket

type: "Generic"
generic:
  secretReference:
    name: "mysecret"
  allowEnv: true 1

https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

$ curl -X POST -k https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

git:
  uri: "<url to git repository>"
  ref: "<optional git reference>"
  commit: "<commit hash identifying a specific git commit>"
  author:
    name: "<author name>"
    email: "<author e-mail>"
  committer:
    name: "<committer name>"
    email: "<committer e-mail>"
  message: "<commit message>"
env: 1
   - name: "<variable name>"
     value: "<variable value>"

$ curl -H "Content-Type: application/yaml" --data-binary @payload_file.yaml -X POST -k https://<openshift_api_host:port>/oapi/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic

$ oc describe bc <name>

이미지 변경 트리거를 사용하면 새 버전의 업스트림 이미지가 준비될 때 빌드가 자동으로 호출됩니다. 예를 들어 빌드가 RHEL 이미지를 기반으로 하는 경우 RHEL 이미지가 변경될 때마다 해당 빌드를 트리거하여 실행할 수 있습니다. 결과적으로 애플리케이션 이미지는 항상 최신 RHEL 기본 이미지에서 실행됩니다.

이미지 변경 트리거를 구성하려면 다음 작업을 수행해야 합니다.

전략 이미지 스트림에 이미지 변경 트리거를 사용하는 경우 생성된 빌드에 해당 태그에 해당하는 최신 이미지를 가리키는 변경 불가능한 Docker 태그가 제공됩니다. 이 새 이미지 참조는 빌드에 대해 실행할 때 전략에서 사용합니다.

전략 이미지 스트림을 참조하지 않는 다른 이미지 변경 트리거의 경우 새 빌드가 시작되지만 빌드 전략은 고유한 이미지 참조로 업데이트되지 않습니다.

전략에 대한 이미지 변경 트리거가 있는 위의 예에서 결과 빌드는 다음과 같습니다.

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"

그 결과 트리거된 빌드는 리포지토리로 방금 푸시된 새 이미지를 사용하고 동일한 입력을 사용하여 빌드를 다시 실행할 수 있습니다.

이미지 변경 트리거를 일시 정지하여 빌드를 시작하기 전에 참조 이미지 스트림에 대한 다양한 변경 사항을 허용할 수 있습니다. 처음에 ImageChangeTrigger를 BuildConfig에 추가할 때 빌드가 즉시 트리거되지 않도록 paused 특성을 true로 설정할 수도 있습니다.

type: "ImageChange"
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
  paused: true

모든 Strategy 유형의 이미지 필드를 설정하는 것 외에 사용자 지정 빌드의 경우 OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE 환경 변수도 확인합니다. 존재하지 않는 경우 변경 불가능한 이미지 참조를 사용하여 생성됩니다. 존재하는 경우 변경 불가능한 이미지 참조를 사용하여 업데이트됩니다.

Webhook 트리거 또는 수동 요청으로 인해 빌드가 트리거되는 경우 생성된 빌드는 Strategy에서 참조한 ImageStream의 확인된 <immutableid>를 사용합니다. 그러면 쉽게 재현할 수 있도록 일관된 이미지 태그를 사용하여 빌드를 수행할 수 있습니다.

구성 변경 트리거를 사용하면 새 BuildConfig가 생성되는 즉시 빌드가 자동으로 호출됩니다. 다음은 BuildConfig 내 트리거 정의 YAML의 예입니다.

  type: "ConfigChange"

$ oc set triggers bc <name> --from-github

$ oc set triggers bc <name> --from-image='<image>'

$ oc set triggers bc <name> --from-bitbucket --remove

빌드 후크를 사용하면 빌드 프로세스에 동작을 삽입할 수 있습니다.

BuildConfig 오브젝트의 postCommit 필드는 빌드 출력 이미지를 실행하는 임시 컨테이너 내에서 명령을 실행합니다. 후크는 이미지의 마지막 계층을 커밋한 직후 그리고 이미지를 레지스트리로 푸시하기 전에 실행됩니다.

현재 작업 디렉터리는 이미지의 WORKDIR로 설정되어 있으며 이는 컨테이너 이미지의 기본 작업 디렉터리입니다. 대부분의 이미지에서 이 디렉터리는 소스 코드가 있는 위치입니다.

스크립트 또는 명령에서 0이 아닌 종료 코드를 반환하거나 임시 컨테이너를 시작하지 못하는 경우 후크가 실패합니다. 후크가 실패하면 빌드가 실패로 표시되고 이미지를 레지스트리로 푸쉬하지 않습니다. 실패 이유는 빌드 로그를 확인하여 검사할 수 있습니다.

빌드 후크를 사용하면 빌드를 완료로 표시하고 레지스트리에 이미지를 제공하기 전에 단위 테스트를 실행하여 이미지를 확인할 수 있습니다. 모든 테스트를 통과하고 테스트 실행기에서 종료 코드 0을 반환하면 빌드가 성공으로 표시됩니다. 실패한 테스트가 있는 경우 빌드가 실패로 표시됩니다. 모든 경우에서 빌드 로그에는 실패한 테스트를 식별하는 데 사용할 수 있는 테스트 실행기의 출력이 포함됩니다.

postCommit 후크는 테스트 실행뿐만 아니라 다른 명령에도 사용할 수 있습니다. 임시 컨테이너에서 실행되기 때문에 후크의 변경 사항은 유지되지 않으므로 후크 실행이 최종 이미지에 영향을 미칠 수 없습니다. 이 동작은 특히 자동으로 삭제되어 최종 이미지에 존재하지 않는 테스트 종속 항목의 설치 및 사용을 허용합니다.

빌드 후 후크를 구성하는 방법은 다양합니다. 다음 예제의 모든 양식은 동일하고 bundle exec rake test --verbose:

$ oc set build-hook bc/mybc \
    --post-commit \
    --command \
    -- bundle exec rake test --verbose

$ oc set build-hook bc/mybc --post-commit --script="bundle exec rake test --verbose"

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

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

runPolicy 필드를 Serial 로 설정하면 Build 구성에서 생성된 모든 새 빌드가 순차적으로 실행됩니다. 즉, 한 번에 하나의 빌드만 실행되고 모든 새 빌드는 이전 빌드가 완료될 때까지 대기합니다. 이 정책을 사용하면 일관되고 예측 가능한 빌드 출력이 생성됩니다. 이는 기본 runPolicy 입니다.

Serial 정책을 사용하여 sample-build 구성에서 3개의 빌드를 트리거하면 다음이 발생합니다.

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git           New
sample-build-3   Source    Git           New

sample-build-1 빌드가 완료되면 sample-build-2 빌드가 실행됩니다.

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Completed 43 seconds ago   34s
sample-build-2   Source    Git@1aa381b   Running   2 seconds ago    2s
sample-build-3   Source    Git           New

runPolicy 필드를 Serial LatestOnly 로 설정하면 직렬 실행 정책을 사용하는 것과 동일하게 Build 구성에서 생성한 모든 새 빌드가 순차적으로 실행됩니다. 차이점은 현재 실행 중인 빌드가 완료되면 실행될 다음 빌드가 생성된 최신 빌드입니다. 즉, 큐 빌드를 건너뛰기 때문에 대기할 때까지 기다리지 않습니다. 건너뛰기된 빌드는 취소됨 으로 표시됩니다. 이 정책은 빠르고 반복적인 개발에 사용할 수 있습니다.

SerialLatestOnly 정책을 사용하여 sample-build 구성에서 세 개의 빌드를 트리거하면 다음이 발생합니다.

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git           Cancelled
sample-build-3   Source    Git           New

sample-build-2 빌드는 취소(skipped)되고 sample-build-1 완료 후 다음 빌드 실행이 sample-build-3 빌드가 됩니다.

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Completed 43 seconds ago   34s
sample-build-2   Source    Git           Cancelled
sample-build-3   Source    Git@1aa381b   Running   2 seconds ago    2s

runPolicy 필드를 Parallel 로 설정하면 Build 구성에서 생성된 모든 새 빌드가 병렬로 실행됩니다. 첫 번째 생성된 빌드가 마지막에 완료되어 이전에 완료된 마지막 빌드로 생성된 푸시된 컨테이너 이미지를 대체할 수 있으므로 예측할 수 없는 결과가 발생할 수 있습니다.

빌드가 완료될 순서에 상관하지 않는 경우 병렬 실행 정책을 사용합니다.

Parallel 정책을 사용하여 sample-build 구성에서 3개의 빌드를 트리거하면 세 가지 동시 빌드가 발생합니다.

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git@a76d881   Running   15 seconds ago   3s
sample-build-3   Source    Git@689d111   Running   17 seconds ago   3s

완료 순서는 보장되지 않습니다.

NAME             TYPE      FROM          STATUS    STARTED          DURATION
sample-build-1   Source    Git@e79d887   Running   13 seconds ago   13s
sample-build-2   Source    Git@a76d881   Running   15 seconds ago   3s
sample-build-3   Source    Git@689d111   Completed 17 seconds ago   5s

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

리소스 제한을 빌드 구성의 일부로 지정하여 리소스 사용을 제한할 수도 있습니다. 다음 예에서 각 리소스,cpu, memory 매개변수는 선택 사항입니다.

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  resources:
    limits:
      cpu: "100m" 1
      memory: "256Mi" 2

그러나 프로젝트에 할당량 을 정의한 경우 다음 두 항목 중 하나가 필요합니다.

그러지 않으면 할당량을 충족하지 못하여 빌드 Pod 생성이 실패합니다.

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

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

다음 예제에서는 completionDeadlineSeconds 필드를 30분으로 지정하는 BuildConfig의 일부를 보여줍니다.

spec:
  completionDeadlineSeconds: 1800

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

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  nodeSelector:1
    key1: value1
    key2: value2

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

자세한 내용은 글로벌 빌드 기본값 구성 및 덮어쓰기를 참조하십시오.

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

이러한 문제를 방지하려면 두 개의 빌드를 함께 연결할 수 있습니다. 하나는 컴파일된 아티팩트를 생성하는 빌드와 아티팩트를 실행하는 별도의 이미지에 아티팩트를 배치하는 두 번째 빌드입니다. 다음 예에서 S2I( Source-to-Image ) 빌드는 Docker 빌드와 결합하여 아티팩트를 컴파일한 다음 별도의 런타임 이미지에 배치됩니다.

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

apiVersion: 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
    type: Git
  strategy:
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: wildfly:10.1
        namespace: openshift
    type: Source

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

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

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

기본적으로 라이프사이클이 완료된 빌드는 무기한 유지됩니다. 다음 샘플 빌드 구성에 표시된 대로 successfulBuildsHistoryLimit 또는 failedBuildsHistoryLimit 에 대한 양의 정수 값을 제공하여 유지되는 이전 빌드 수를 제한할 수 있습니다.

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2 1
  failedBuildsHistoryLimit: 2 2

빌드 정리는 다음 작업으로 트리거됩니다.

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

OpenShift Container Platform 배포는 일반적인 사용자 애플리케이션에 대한 세분화된 관리를 제공합니다. 다음 세 가지 API 오브젝트를 사용하여 설명합니다.

배포 구성을 생성하면 배포 구성의 Pod 템플릿을 나타내는 복제 컨트롤러가 생성됩니다. 배포 구성이 변경되면 최신 Pod 템플릿을 사용하여 새 복제 컨트롤러가 생성되고 배포 프로세스가 실행되어 이전 복제 컨트롤러를 축소하고 새 복제 컨트롤러를 확장합니다.

애플리케이션 인스턴스는 생성 시 서비스 로드 밸런서와 라우터 모두에서 자동으로 추가 및 제거됩니다. 애플리케이션에서 TERM 신호를 수신할 때 정상 종료 를 지원하는 경우 실행 중인 사용자 연결을 정상적으로 완료할 수 있는 기회를 제공할 수 있습니다.

배포 시스템에서 제공하는 기능:

배포 구성은 다른 모든 리소스와 마찬가지로 oc 명령으로 관리할 수 있는 deploymentConfig OpenShift Container Platform API 리소스입니다. 다음은 deploymentConfig 리소스의 예입니다.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "frontend"
spec:
  template: 1
    metadata:
      labels:
        name: "frontend"
    spec:
      containers:
        - name: "helloworld"
          image: "openshift/origin-ruby-sample"
          ports:
            - containerPort: 8080
              protocol: "TCP"
  replicas: 5 2
  triggers:
    - type: "ConfigChange" 3
    - type: "ImageChange" 4
      imageChangeParams:
        automatic: true
        containerNames:
          - "helloworld"
        from:
          kind: "ImageStreamTag"
          name: "origin-ruby-sample:latest"
  strategy: 5
    type: "Rolling"
  paused: false 6
  revisionHistoryLimit: 2 7
  minReadySeconds: 0 8

웹 콘솔을 사용하거나 CLI에서 새 배포 프로세스를 수동으로 시작할 수 있습니다.

$ oc rollout latest dc/<name>

사용 가능한 모든 버전의 애플리케이션에 대한 기본 정보를 얻으려면 다음을 수행합니다.

$ oc rollout history dc/<name>

그러면 현재 실행 중인 배포 프로세스를 포함하여 제공된 배포 구성에 대해 최근 생성된 모든 복제 컨트롤러에 대한 세부 정보가 표시됩니다.

--revision 플래그를 사용하여 리버전 관련 세부 정보를 볼 수 있습니다.

$ oc rollout history dc/<name> --revision=1

배포 구성 및 최신 버전에 대한 자세한 내용은 다음을 참조하십시오.

$ oc describe dc <name>

현재 배포 구성 버전이 배포되지 않은 경우 다음을 사용하여 배포 프로세스를 다시 시작할 수 있습니다.

$ oc rollout retry dc/<name>

최신 버전이 성공적으로 배포된 경우 명령은 메시지를 표시하고 배포 프로세스를 재시도하지 않습니다.

롤백은 애플리케이션을 이전 리버전으로 되돌리고 REST API, CLI 또는 웹 콘솔을 사용하여 수행할 수 있습니다.

마지막으로 성공적으로 배포된 구성 리버전으로 롤백하려면 다음을 수행합니다.

$ oc rollout undo dc/<name>

배포 구성의 템플릿이 undo 명령에 지정된 배포 리버전과 일치하도록 되돌아가고 새 복제 컨트롤러가 시작됩니다. 버전이 --to-revision 으로 지정되지 않은 경우 마지막으로 성공적으로 배포된 리버전이 사용됩니다.

롤백이 완료되면 실수로 새 배포 프로세스가 시작되지 않도록 배포 구성의 이미지 변경 트리거가 비활성화됩니다. 이미지 변경 트리거를 다시 활성화하려면 다음을 수행합니다.

$ oc set triggers dc/<name> --auto

이미지의 ENTRYPOINT 를 무효화하여 컨테이너의 시작 동작을 수정하는 명령을 컨테이너에 추가할 수 있습니다. 이는 지정된 시간에 배포당 한 번만 실행할 수 있는 라이프사이클 후크 와 다릅니다.

배포 구성의 spec 필드에 command 매개변수를 추가합니다. 또한 command(command가 존재하지 않는 경우 ENTRYPOINT)를 수정하는 args 필드를 추가할 수 있습니다.

...
spec:
  containers:
    -
    name: <container_name>
    image: 'image'
    command:
      - '<command>'
    args:
      - '<argument_1>'
      - '<argument_2>'
      - '<argument_3>'
...

예를 들어 -jar 및 /opt/app-root/springboots2idemo.jar 인수를 사용하여 java 명령을 실행하려면 다음을 실행합니다.

...
spec:
  containers:
    -
    name: example-spring-boot
    image: 'image'
    command:
      - java
    args:
      - '-jar'
      - /opt/app-root/springboots2idemo.jar
...

지정된 배포 구성의 최신 리버전 로그를 스트리밍하려면 다음을 수행합니다.

$ oc logs -f dc/<name>

최신 버전이 실행 중이거나 실패한 경우 oc logs 는 Pod 배포를 담당하는 프로세스의 로그를 반환합니다. 성공하는 경우 oc logs 는 애플리케이션 Pod의 로그를 반환합니다.

또한 실패한 이전 배포 프로세스(복제 컨트롤러 및 배포 Pod)가 존재하고 이를 수동으로 정리하거나 삭제하지 않은 경우에만 이러한 프로세스의 로그를 볼 수 있습니다.

$ oc logs --version=1 dc/<name>

로그 검색에 대한 자세한 옵션은 다음을 참조하십시오.

$ oc logs --help

배포 구성에는 클러스터 내부의 이벤트에 대한 응답으로 새 배포 프로세스 생성을 유도하는 트리거가 포함될 수 있습니다.

triggers:
  - type: "ConfigChange"

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true 1
      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

$ oc set triggers dc/frontend --from-image=myproject/origin-ruby-sample:latest -c helloworld

$ oc set triggers --help

배포는 배포 Pod에 의해 완료됩니다. 기본적으로 배포 Pod는 예약된 컴퓨팅 노드에서 바인딩되지 않은 노드 리소스를 사용합니다. 대부분의 경우 배포 Pod는 낮은 리소스를 사용하고 잠시 동안 실행되기 때문에 바인딩되지 않은 리소스 소비가 문제가 발생하지 않습니다. 프로젝트에서 기본 컨테이너 제한을 지정하는 경우 배포 Pod에서 사용하는 리소스와 다른 모든 Pod와 함께 해당 제한에 대해 카운트합니다.

배포 구성의 배포 전략을 통해 배포 Pod에서 사용하는 리소스를 제한할 수 있습니다. 배포 Pod의 리소스 제한은 Recreate, 롤링 또는 사용자 정의 배포 전략과 함께 사용할 수 있습니다.

다음 예에서 각 resources, cpu, memory, ephemeral-storage는 선택 사항입니다.

type: "Recreate"
resources:
  limits:
    cpu: "100m" 1
    memory: "256Mi" 2
    ephemeral-storage: "1Gi" 3

그러나 프로젝트에 할당량을 정의한 경우 다음 두 항목 중 하나가 필요합니다.

그러지 않으면 할당량을 충족하지 못하여 배포 Pod 생성이 실패합니다.

롤백 외에도 웹 콘솔에서 복제본 수를 세부적으로 제어하거나 oc scale 명령을 사용하여 세부적으로 제어할 수 있습니다. 예를 들어 다음 명령은 배포 구성 프론트엔드 의 복제본을 3으로 설정합니다.

$ oc scale dc frontend --replicas=3

결국 복제본 수는 배포 구성 프런트 엔드 에서 구성한 배포의 원하는 현재 상태로 전달됩니다.

라벨이 지정된 노드와 함께 노드 선택기를 사용하여 Pod 배치를 제어할 수 있습니다.

클러스터 관리자는 Pod 배치를 특정 노드로 제한하기 위해 프로젝트의 기본 노드 선택기를 설정할 수 있습니다. OpenShift Container Platform 개발자는 Pod 구성에 노드 선택기를 설정하여 노드를 추가로 제한할 수 있습니다.

Pod를 생성할 때 노드 선택기를 추가하려면 Pod 구성을 편집하고 nodeSelector 값을 추가합니다. 이는 단일 Pod 구성 또는 Pod 템플릿에 추가할 수 있습니다.

apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    disktype: ssd
...

노드 선택기가 제 위치에 있으면 생성된 Pod가 라벨이 지정된 노드에 할당됩니다.

여기에 지정된 레이블은 클러스터 관리자가 추가한 라벨과 함께 사용됩니다.