개발자 가이드

1장. 개요
링크 복사

이 안내서는 애플리케이션 개발자를 대상으로 하며 OpenShift Container Platform 클라우드 환경에서 애플리케이션을 개발하고 배포하기 위해 워크스테이션을 설정하고 구성하기 위한 지침을 제공합니다. 여기에는 개발자를 위한 자세한 지침 및 예제가 포함됩니다.

새 애플리케이션 생성
프로젝트 모니터링 및 구성
템플릿을 사용하여 구성 생성
빌드 전략 옵션 및 Webhook를 포함한 빌드 관리
배포 전략을 포함하여 배포 정의
경로 생성 및 관리
보안 생성 및 구성
데이터베이스 및 SaaS 끝점과 같은 외부 서비스 통합
프로브를 사용하여 애플리케이션 상태 확인

2장. 애플리케이션 라이프 사이클 관리
링크 복사

2.1. 개발 프로세스 계획
링크 복사

2.1.1. 개요
링크 복사

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

OpenShift Container Platform 프로젝트 내에서 개발에 중점을 두어 처음부터 애플리케이션을 빌드한 다음 라이프사이클을 지속적으로 개발 및 관리하거나
별도의 환경에서 이미 개발한 애플리케이션(예: 바이너리, 컨테이너 이미지, 소스 코드)을 가져와 OpenShift Container Platform에 배포합니다.

2.1.2. OpenShift Container Platform을 개발 환경으로 사용
링크 복사

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

초기 계획

사용 중인 애플리케이션은 어떻게 합니까?
어떤 프로그래밍 언어를 개발할 수 있습니까?

OpenShift Container Platform 액세스

OpenShift Container Platform은 귀하 또는 조직 내 관리자가 이 시점에 설치해야 합니다.

개발

선택한 편집기 또는 IDE를 사용하여 애플리케이션의 기본 스keleton을 만듭니다. OpenShift Container Platform에 어떤 종류의 애플리케이션인지 알 수 있을 만큼 충분히 개발되어야 합니다.
코드를 Git 리포지토리로 내보냅니다.

generate

oc new-app 명령을 사용하여 기본 애플리케이션을 만듭니다. OpenShift Container Platform은 빌드 및 배포 구성을 생성합니다.

관리

애플리케이션 코드 개발을 시작합니다.
애플리케이션 빌드가 완료되었는지 확인합니다.
로컬 개발 및 코드 단축으로 계속 진행하십시오.
코드를 Git 리포지토리로 내보냅니다.
추가 구성이 필요합니까? 자세한 옵션은 개발자 가이드 를 참조하십시오.

확인

여러 가지 방법으로 애플리케이션을 확인할 수 있습니다. 변경 사항을 애플리케이션의 Git 리포지토리로 푸시하고 OpenShift Container Platform을 사용하여 애플리케이션을 다시 빌드하고 재배포할 수 있습니다. 또는 rsync 를 사용하여 핫 디플로이먼트를 통해 코드 변경 사항을 실행 중인 Pod에 동기화할 수 있습니다.

2.1.3. OpenShift Container Platform에 배포할 애플리케이션 가져오기
링크 복사

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

초기 계획

사용 중인 애플리케이션은 어떻게 합니까?
어떤 프로그래밍 언어를 개발할 수 있습니까?

개발

선택한 편집기 또는 IDE를 사용하여 애플리케이션 코드를 개발합니다.
로컬로 애플리케이션 코드를 빌드하고 테스트합니다.
코드를 Git 리포지토리로 내보냅니다.

OpenShift Container Platform 액세스

OpenShift Container Platform은 귀하 또는 조직 내 관리자가 이 시점에 설치해야 합니다.

generate

oc new-app 명령을 사용하여 기본 애플리케이션을 만듭니다. OpenShift Container Platform은 빌드 및 배포 구성을 생성합니다.

확인

위의 Generate 단계에 빌드 및 배포한 애플리케이션이 OpenShift Container Platform에서 성공적으로 실행되고 있는지 확인합니다.

관리

결과에 만족할 때까지 애플리케이션 코드를 계속 개발하십시오.
OpenShift Container Platform에서 애플리케이션을 다시 빌드하여 새로 내보낸 코드를 수락합니다.
추가 구성이 필요합니까? 자세한 옵션은 개발자 가이드 를 참조하십시오.

2.2. 새 애플리케이션 생성
링크 복사

2.2.1. 개요
링크 복사

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

2.2.2. CLI를 사용하여 애플리케이션 생성
링크 복사

2.2.2.1. 소스 코드에서 애플리케이션 생성
링크 복사

new-app 명령을 사용하면 로컬 또는 원격 Git 리포지토리의 소스 코드에서 애플리케이션을 생성할 수 있습니다.

로컬 디렉터리에서 Git 리포지토리를 사용하여 애플리케이션을 생성하려면 다음을 수행합니다.

oc new-app /path/to/source/code

$ oc new-app /path/to/source/code

Copy to Clipboard

Toggle word wrap

참고

로컬 Git 리포지토리를 사용하는 경우 리포지토리에 OpenShift Container Platform 클러스터에서 액세스할 수 있는 URL을 가리키는 origin 이라는 원격이 있어야 합니다. 리모트가 없는 경우 new-app 은 바이너리 빌드 를 생성합니다.

원격 Git 리포지토리를 사용하여 애플리케이션을 생성하려면 다음을 수행합니다.

oc new-app https://github.com/sclorg/cakephp-ex

$ oc new-app https://github.com/sclorg/cakephp-ex

Copy to Clipboard

Toggle word wrap

프라이빗 원격 Git 리포지토리를 사용하여 애플리케이션을 생성하려면 다음을 수행합니다.

oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecret

$ oc new-app https://github.com/youruser/yourprivaterepo --source-secret=yoursecret

Copy to Clipboard

Toggle word wrap

참고

프라이빗 원격 Git 리포지토리를 사용하는 경우 --source-secret 플래그를 사용하여 BuildConfig 에 삽입할 기존 소스 복제 보안을 지정하여 리포지토리에 액세스할 수 있습니다.

--context-dir 플래그를 지정하여 소스 코드 리포지토리의 하위 디렉터리를 사용할 수 있습니다. 원격 Git 리포지토리 및 컨텍스트 하위 디렉터리를 사용하여 애플리케이션을 생성하려면 다음을 수행합니다.

oc new-app https://github.com/sclorg/s2i-ruby-container.git \
    --context-dir=2.0/test/puma-test-app

$ oc new-app https://github.com/sclorg/s2i-ruby-container.git \
    --context-dir=2.0/test/puma-test-app

Copy to Clipboard

Toggle word wrap

또한 원격 URL을 지정하면 URL 끝에 #<branch_name>을 추가하여 사용할 Git 분기를 지정할 수 있습니다.

oc new-app https://github.com/openshift/ruby-hello-world.git#beta4

$ oc new-app https://github.com/openshift/ruby-hello-world.git#beta4

Copy to Clipboard

Toggle word wrap

new-app 명령은 소스 코드에서 자체적으로 새 애플리케이션 이미지를 생성하는 빌드 구성을 생성합니다. new-app 명령은 일반적으로 새 이미지를 배포하는 배포 구성 과 이미지를 실행하는 배포에 부하 분산 액세스를 제공하는 서비스를 생성합니다.

OpenShift Container Platform은 Docker, Pipeline 또는 Source 빌드 전략 사용 여부를 자동으로 탐지 하고 Source 빌드의 경우 적절한 언어 빌더 이미지를 탐지합니다.

빌드 전략 탐지

새 애플리케이션을 생성할 때 Jenkinsfile 이 소스 리포지토리의 루트 또는 지정된 컨텍스트 디렉터리에 있는 경우 OpenShift Container Platform은 Pipeline 빌드 전략을 생성합니다. 그렇지 않으면 Dockerfile 이 발견되면 OpenShift Container Platform에서 Docker 빌드 전략을 생성합니다. 그렇지 않으면 소스 빌드 전략을 생성합니다.

--strategy 플래그를 docker,pipeline 또는 source 로 설정하여 빌드 전략을 덮어쓸 수 있습니다.

oc new-app /home/user/code/myapp --strategy=docker

$ oc new-app /home/user/code/myapp --strategy=docker

Copy to Clipboard

Toggle word wrap

참고

oc 명령을 실행하려면 빌드 소스가 포함된 파일이 원격 Git 리포지토리에 제공되어야 합니다. 모든 소스 빌드에 git remote -v를 사용해야 합니다.

언어 탐지

Source 빌드 전략을 사용하는 경우 new-app 은 리포지토리의 루트 또는 지정된 컨텍스트 디렉터리에 특정 파일이 있는지에 따라 사용할 언어 빌더를 결정합니다.

Expand

표 2.1. new-app에 의해 감지된 언어
언어	파일
`dotnet`	*project.json, .csproj
`jee`	*pom.xml*
`nodejs`	*app.json, package.json*
`perl`	*cpanfile, index.pl*
`php`	*composer.json, index.php*
`python`	*requirements.txt, setup.py*
`ruby`	*Gemfile, Rakefile, config.ru*
`scala`	*build.sbt*
`golang`	*Godeps, main.go*

언어를 탐지한 후 new-app 은 OpenShift Container Platform 서버에서 탐지된 언어와 일치하는 supports 주석이 있는 이미지 스트림 태그 또는 탐지된 언어의 이름과 일치하는 이미지 스트림을 검색합니다. 일치 항목이 없는 경우 new-app은 Docker Hub 레지스트리에서 이름을 기반으로 탐지된 언어와 일치하는 이미지를 검색합니다.

이미지(이미지 스트림 또는 컨테이너 사양)와 리포지토리를 지정하여 빌더에서 특정 소스 리포지토리에 사용하는 이미지를 재정의할 수 있습니다. 이 작업이 완료되면 빌드 전략 탐지 및 언어 탐지 가 수행되지 않습니다.

예를 들어 원격 리포지토리의 소스에 myproject/my-ruby 이미지 스트림을 사용하려면 다음을 실행합니다.

oc new-app myproject/my-ruby~https://github.com/openshift/ruby-hello-world.git

$ oc new-app myproject/my-ruby~https://github.com/openshift/ruby-hello-world.git

Copy to Clipboard

Toggle word wrap

로컬 리포지토리의 소스에 openshift/ruby-20-centos7:latest 컨테이너 이미지 스트림을 사용하려면 다음을 수행합니다.

oc new-app openshift/ruby-20-centos7:latest~/home/user/code/my-ruby-app

$ oc new-app openshift/ruby-20-centos7:latest~/home/user/code/my-ruby-app

Copy to Clipboard

Toggle word wrap

2.2.2.2. 이미지에서 애플리케이션 생성
링크 복사

기존 이미지에서 애플리케이션을 배포할 수 있습니다. 이미지는 OpenShift Container Platform 서버의 이미지 스트림, 특정 레지스트리 또는 Docker Hub 레지스트리의 이미지 또는 로컬 Docker 서버의 이미지에서 가져올 수 있습니다.

new-app 명령은 전달된 인수에 지정된 이미지 유형을 확인합니다. 그러나 이미지가 Docker 이미지인지( -i| --image 인수를 사용하여) 이미지 스트림인지 new-app 에 명시적으로 알릴 수 있습니다.

참고

로컬 Docker 리포지토리에서 이미지를 지정하는 경우 OpenShift Container Platform 클러스터 노드에서 동일한 이미지를 사용할 수 있는지 확인해야 합니다.

예를 들어 DockerHub MySQL 이미지에서 애플리케이션을 생성하려면 다음을 수행합니다.

oc new-app mysql

$ oc new-app mysql

Copy to Clipboard

Toggle word wrap

프라이빗 레지스트리의 이미지를 사용하여 애플리케이션을 생성하려면 전체 Docker 이미지 사양을 지정합니다.

oc new-app myregistry:5000/example/myimage

$ oc new-app myregistry:5000/example/myimage

Copy to Clipboard

Toggle word wrap

참고

이미지가 포함된 레지스트리가 SSL로 보호되지 않은 경우 클러스터 관리자는 해당 레지스트리를 가리키는 --insecure-registry 플래그로 OpenShift Container Platform 노드 호스트의 Docker 데몬을 실행해야 합니다. 또한 new-app 에 --insecure-registry 플래그가 있는 비보안 레지스트리에서 이미지가 제공되도록 해야 합니다.

기존 이미지 스트림 및 선택적 이미지 스트림 태그 에서 애플리케이션을 생성할 수 있습니다.

oc new-app my-stream:v1

$ oc new-app my-stream:v1

Copy to Clipboard

Toggle word wrap

2.2.2.3. 템플릿에서 애플리케이션 생성
링크 복사

템플릿 이름을 인수로 지정하여 이전에 저장된 템플릿 또는 템플릿 파일에서 애플리케이션을 생성할 수 있습니다. 예를 들어 샘플 애플리케이션 템플릿을 저장하고 이를 사용하여 애플리케이션을 생성할 수 있습니다.

저장된 템플릿에서 애플리케이션을 생성하려면 다음을 수행합니다.

oc create -f examples/sample-app/application-template-stibuild.json
oc new-app ruby-helloworld-sample

$ oc create -f examples/sample-app/application-template-stibuild.json
$ oc new-app ruby-helloworld-sample

Copy to Clipboard

Toggle word wrap

OpenShift Container Platform에 먼저 저장하지 않고 로컬 파일 시스템에서 템플릿을 직접 사용하려면 -f|--file 인수를 사용합니다.

oc new-app -f examples/sample-app/application-template-stibuild.json

$ oc new-app -f examples/sample-app/application-template-stibuild.json

Copy to Clipboard

Toggle word wrap

템플릿 매개변수

템플릿을 기반으로 애플리케이션을 생성할 때 -p|--param 인수를 사용하여 템플릿에 정의된 매개변수 값을 설정합니다.

oc new-app ruby-helloworld-sample \
    -p ADMIN_USERNAME=admin -p ADMIN_PASSWORD=mypassword

$ oc new-app ruby-helloworld-sample \
    -p ADMIN_USERNAME=admin -p ADMIN_PASSWORD=mypassword

Copy to Clipboard

Toggle word wrap

템플릿을 인스턴스화할 때 해당 매개변수를 파일에 저장한 다음 해당 파일을 --param-file과 함께 사용할 수 있습니다. 표준 입력에서 매개변수를 읽으려면 --param-file=-:을 사용하십시오.

cat helloworld.params
ADMIN_USERNAME=admin
ADMIN_PASSWORD=mypassword
oc new-app ruby-helloworld-sample --param-file=helloworld.params
cat helloworld.params | oc new-app ruby-helloworld-sample --param-file=-

$ cat helloworld.params
ADMIN_USERNAME=admin
ADMIN_PASSWORD=mypassword
$ oc new-app ruby-helloworld-sample --param-file=helloworld.params
$ cat helloworld.params | oc new-app ruby-helloworld-sample --param-file=-

Copy to Clipboard

Toggle word wrap

2.2.2.4. 애플리케이션 생성 추가 수정
링크 복사

new-app 명령은 생성 중인 애플리케이션을 빌드, 배포, 실행할 OpenShift Container Platform 오브젝트를 생성합니다. 일반적으로 이러한 오브젝트는 입력 소스 리포지토리 또는 입력 이미지에서 파생된 이름을 사용하여 현재 프로젝트에서 생성됩니다. 그러나 new-app 을 사용하면 이 동작을 수정할 수 있습니다.

new-app으로 생성되는 오브젝트 세트는 입력을 통해 전달되는 아티팩트(소스 리포지토리, 이미지 또는 템플릿)에 따라 다릅니다.

Expand

표 2.2. new-app 출력 오브젝트
개체	설명
`BuildConfig`	명령줄에 지정된 각 소스 리포지토리에 대해 `BuildConfig` 가 생성됩니다. `BuildConfig` 는 사용할 전략, 소스 위치 및 빌드 출력 위치를 지정합니다.
`ImageStreams`	`BuildConfig` 의 경우 일반적으로 두 개의 `ImageStreams` 가 생성됩니다. 하나는 입력 이미지를 나타냅니다. `소스` 빌드에서는 빌더 이미지입니다. `Docker` 빌드에서는 출처 이미지에 해당합니다. 두 번째 이미지는 출력 이미지를 나타냅니다. 컨테이너 이미지가 `new-app`에 입력으로 지정되면 해당 이미지에도 이미지 스트림이 생성됩니다.
`DeploymentConfig`	`DeploymentConfig` 는 빌드 출력 또는 지정된 이미지를 배포하기 위해 생성됩니다. `new-app` 명령은 결과 `DeploymentConfig` 에 포함된 컨테이너에 지정된 모든 Docker 볼륨에 대해 emptyDir 볼륨을 생성합니다.
`서비스`	`new-app` 명령은 입력 이미지에서 노출된 포트를 탐지합니다. 가장 낮은 숫자의 노출된 포트를 사용하여 해당 포트를 노출하는 서비스를 생성합니다. 다른 포트를 공개하려면 `new-app`을 완료한 후 `oc expose` 명령을 사용하여 추가 서비스를 생성하기만 하면 됩니다.
기타	기타 오브젝트는 템플릿에 따라 템플릿을 인스턴스화할 때 생성될 수 있습니다.

2.2.2.4.1. 환경 변수 지정
링크 복사

템플릿,소스 또는 이미지에서 애플리케이션을 생성할 때 -e|--env 인수를 사용하여 런타임 시 환경 변수를 애플리케이션 컨테이너에 전달할 수 있습니다.

oc new-app openshift/postgresql-92-centos7 \
    -e POSTGRESQL_USER=user \
    -e POSTGRESQL_DATABASE=db \
    -e POSTGRESQL_PASSWORD=password

$ oc new-app openshift/postgresql-92-centos7 \
    -e POSTGRESQL_USER=user \
    -e POSTGRESQL_DATABASE=db \
    -e POSTGRESQL_PASSWORD=password

Copy to Clipboard

Toggle word wrap

이 변수는 --env-file 인수를 사용하여 파일에서 읽을 수도 있습니다.

cat postgresql.env
POSTGRESQL_USER=user
POSTGRESQL_DATABASE=db
POSTGRESQL_PASSWORD=password
oc new-app openshift/postgresql-92-centos7 --env-file=postgresql.env

$ cat postgresql.env
POSTGRESQL_USER=user
POSTGRESQL_DATABASE=db
POSTGRESQL_PASSWORD=password
$ oc new-app openshift/postgresql-92-centos7 --env-file=postgresql.env

Copy to Clipboard

Toggle word wrap

또한 --env-file=-을 사용하여 환경 변수를 표준 입력에 제공할 수 있습니다.

cat postgresql.env | oc new-app openshift/postgresql-92-centos7 --env-file=-

$ cat postgresql.env | oc new-app openshift/postgresql-92-centos7 --env-file=-

Copy to Clipboard

Toggle word wrap

자세한 내용은 환경 변수 관리를 참조하십시오.

참고

new-app 처리의 일부로 생성된 BuildConfig 오브젝트는 -e|--env 또는 --env-file 인수를 통해 전달되는 환경 변수로 업데이트되지 않습니다.

2.2.2.4.2. 빌드 환경 변수 지정
링크 복사

템플릿,소스 또는 이미지에서 애플리케이션을 생성할 때 --build-env 인수를 사용하여 런타임 시 환경 변수를 빌드 컨테이너에 전달할 수 있습니다.

oc new-app openshift/ruby-23-centos7 \
    --build-env HTTP_PROXY=http://myproxy.net:1337/ \
    --build-env GEM_HOME=~/.gem

$ oc new-app openshift/ruby-23-centos7 \
    --build-env HTTP_PROXY=http://myproxy.net:1337/ \
    --build-env GEM_HOME=~/.gem

Copy to Clipboard

Toggle word wrap

이 변수는 --build-env-file 인수를 사용하여 파일에서 읽을 수도 있습니다.

cat ruby.env
HTTP_PROXY=http://myproxy.net:1337/
GEM_HOME=~/.gem
oc new-app openshift/ruby-23-centos7 --build-env-file=ruby.env

$ cat ruby.env
HTTP_PROXY=http://myproxy.net:1337/
GEM_HOME=~/.gem
$ oc new-app openshift/ruby-23-centos7 --build-env-file=ruby.env

Copy to Clipboard

Toggle word wrap

또한 --build-env-file=-을 사용하여 환경 변수를 표준 입력에 제공할 수 있습니다.

cat ruby.env | oc new-app openshift/ruby-23-centos7 --build-env-file=-

$ cat ruby.env | oc new-app openshift/ruby-23-centos7 --build-env-file=-

Copy to Clipboard

Toggle word wrap

2.2.2.4.3. 라벨 지정
링크 복사

소스,이미지 또는 템플릿에서 애플리케이션을 생성할 때 -l|--label 인수를 사용하여 생성된 오브젝트에 라벨을 추가할 수 있습니다. 라벨을 사용하면 애플리케이션과 관련된 오브젝트를 전체적으로 선택, 구성, 삭제할 수 있습니다.

oc new-app https://github.com/openshift/ruby-hello-world -l name=hello-world

$ oc new-app https://github.com/openshift/ruby-hello-world -l name=hello-world

Copy to Clipboard

Toggle word wrap

2.2.2.4.4. 생성 없이 출력 보기
링크 복사

new-app 이 생성되는 시험 실행을 보려면 yaml 또는 json 값과 함께 -o|--output 인수를 사용하면 됩니다. 그런 다음 출력을 사용하여 생성할 오브젝트를 미리 보거나 편집할 수 있는 파일로 리디렉션할 수 있습니다. 충족되면 oc create 를 사용하여 OpenShift Container Platform 오브젝트를 생성할 수 있습니다.

new-app 아티팩트를 파일에 출력하려면 편집하여 다음을 생성합니다.

oc new-app https://github.com/openshift/ruby-hello-world \
    -o yaml > myapp.yaml
vi myapp.yaml
oc create -f myapp.yaml

$ oc new-app https://github.com/openshift/ruby-hello-world \
    -o yaml > myapp.yaml
$ vi myapp.yaml
$ oc create -f myapp.yaml

Copy to Clipboard

Toggle word wrap

2.2.2.4.5. 다른 이름으로 오브젝트 생성
링크 복사

new-app으로 생성한 오브젝트는 일반적으로 소스 리포지토리 또는 해당 오브젝트를 생성하는 데 사용된 이미지의 이름을 따서 이름이 지정됩니다. 명령에 --name 플래그를 추가하여 생성한 오브젝트의 이름을 설정할 수 있습니다.

oc new-app https://github.com/openshift/ruby-hello-world --name=myapp

$ oc new-app https://github.com/openshift/ruby-hello-world --name=myapp

Copy to Clipboard

Toggle word wrap

2.2.2.4.6. 다른 프로젝트에서 오브젝트 생성
링크 복사

일반적으로 new-app은 현재 프로젝트에서 오브젝트를 생성합니다. 그러나 -n|--namespace 인수를 사용하여 액세스할 수 있는 다른 프로젝트에서 오브젝트를 생성할 수 있습니다.

oc new-app https://github.com/openshift/ruby-hello-world -n myproject

$ oc new-app https://github.com/openshift/ruby-hello-world -n myproject

Copy to Clipboard

Toggle word wrap

2.2.2.4.7. 여러 오브젝트 생성
링크 복사

new-app 명령을 사용하면 new-app에 다양한 매개변수를 지정하는 애플리케이션을 여러 개 생성할 수 있습니다. 명령 줄에서 지정된 라벨은 단일 명령으로 생성된 모든 개체에 적용됩니다. 환경 변수는 소스 또는 이미지에서 생성한 모든 구성 요소에 적용됩니다.

소스 리포지토리 및 Docker Hub 이미지에서 애플리케이션을 생성하려면 다음을 실행합니다.

oc new-app https://github.com/openshift/ruby-hello-world mysql

$ oc new-app https://github.com/openshift/ruby-hello-world mysql

Copy to Clipboard

Toggle word wrap

참고

소스 코드 리포지토리와 빌더 이미지가 별도의 인수로 지정되면 new-app에서 빌더 이미지를 소스 코드 저장소의 빌더로 사용합니다. 이를 원하지 않는 경우 ~ 구분자를 사용하여 소스에 필요한 빌더 이미지를 지정합니다.

2.2.2.4.8. 단일 Pod에서 이미지 및 소스 그룹화
링크 복사

new-app 명령을 사용하면 단일 Pod에 여러 이미지를 함께 배포할 수 있습니다. 함께 그룹화할 이미지를 지정하려면 + 구분자를 사용합니다. --group 명령줄 인수를 사용하여 함께 그룹화해야 하는 이미지를 지정할 수도 있습니다. 소스 리포지토리에서 빌드한 이미지를 기타 이미지와 함께 그룹화하려면 그룹에 해당 빌더 이미지를 지정합니다.

oc new-app ruby+mysql

$ oc new-app ruby+mysql

Copy to Clipboard

Toggle word wrap

소스에서 빌드한 이미지를 외부 이미지와 함께 배포하려면 다음을 실행합니다.

oc new-app \
    ruby~https://github.com/openshift/ruby-hello-world \
    mysql \
    --group=ruby+mysql

$ oc new-app \
    ruby~https://github.com/openshift/ruby-hello-world \
    mysql \
    --group=ruby+mysql

Copy to Clipboard

Toggle word wrap

2.2.2.4.9. 이미지, 템플릿 및 기타 입력 검색
링크 복사

oc new-app 명령에 대한 이미지, 템플릿 및 기타 입력을 검색하려면 --search 및 --list플래그를 추가합니다. 예를 들어 PHP를 포함하는 모든 이미지 또는 템플릿을 찾으려면 다음을 실행합니다.

oc new-app --search php

$ oc new-app --search php

Copy to Clipboard

Toggle word wrap

2.2.3. 웹 콘솔을 사용하여 애플리케이션 생성
링크 복사

원하는 프로젝트에 있는 동안 프로젝트에 추가를 클릭합니다.

View larger image

프로젝트의 이미지 목록 또는 서비스 카탈로그에서 빌더 이미지를 선택합니다.

참고

여기에 설명된 대로 주석에 builder 태그가 표시된 이미지 스트림 태그만 이 목록에 표시됩니다.

kind: "ImageStream"
apiVersion: "v1"
metadata:
  name: "ruby"
  creationTimestamp: null
spec:
  dockerImageRepository: "registry.access.redhat.com/openshift3/ruby-20-rhel7"
  tags:
    -
      name: "2.0"
      annotations:
        description: "Build and run Ruby 2.0 applications"
        iconClass: "icon-ruby"
        tags: "builder,ruby" 
        supports: "ruby:2.0,ruby"
        version: "2.0"

kind: "ImageStream"
apiVersion: "v1"
metadata:
  name: "ruby"
  creationTimestamp: null
spec:
  dockerImageRepository: "registry.access.redhat.com/openshift3/ruby-20-rhel7"
  tags:
    -
      name: "2.0"
      annotations:
        description: "Build and run Ruby 2.0 applications"
        iconClass: "icon-ruby"
        tags: "builder,ruby"

1


        supports: "ruby:2.0,ruby"
        version: "2.0"

Copy to Clipboard

Toggle word wrap

1: 여기에 빌더를 포함하면 이 ImageStreamTag는 웹 콘솔에 빌더로 표시됩니다.

새 애플리케이션 화면에서 설정을 수정하여 애플리케이션을 지원하도록 오브젝트를 구성합니다.

View larger image

2.3. 환경 간 애플리케이션 승격
링크 복사

2.3.1. 개요
링크 복사

애플리케이션 승격은 다양한 런타임 환경을 통해 애플리케이션을 이동하는 것을 의미하며, 일반적으로 완성도가 증가하고 있습니다. 예를 들어, 애플리케이션은 개발 환경에서 시작한 다음, 프로덕션 환경으로 승격되기 전에 추가 테스트를 위해 스테이징 환경으로 승격될 수 있습니다. 애플리케이션에 변경 사항이 도입되면 변경 사항이 개발 과정에서 다시 시작되고 스테이지 및 프로덕션을 통해 확장됩니다.

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

OpenShift Container Platform과 Kubernetes 및 Docker의 결합된 기반과 관련된 추가 애플리케이션 아티팩트에는 다음이 포함됩니다.

풍부한 메타데이터 및 관련 툴 세트가 있는 Docker 컨테이너 이미지.
애플리케이션 사용을 위해 컨테이너에 삽입되는 환경 변수 입니다.
API 오브젝트 (리소스 정의라고도 함, OpenShift Container Platform의 코어 개념)를 참조하십시오.
- 애플리케이션 사용을 위해 컨테이너에 삽입됩니다.
- OpenShift Container Platform에서 컨테이너 및 Pod를 관리하는 방법을 지정합니다.

OpenShift Container Platform에서 애플리케이션을 승격하는 방법을 설명할 때 이 주제는 다음과 같습니다.

애플리케이션 정의에 도입된 이러한 새 아티팩트를 자세히 설명합니다.
애플리케이션 승격 파이프라인을 위해 다양한 환경을 해독할 수 있는 방법을 설명합니다.
이러한 새로운 아티팩트를 관리하기 위한 방법론과 툴에 대해 논의합니다.
애플리케이션 승격에 다양한 개념, 구성, 방법론 및 툴을 적용하는 예제를 제공합니다.

2.3.2. 애플리케이션 구성 요소
링크 복사

2.3.2.1. API 오브젝트
링크 복사

OpenShift Container Platform 및 Kubernetes 리소스 정의(애플리케이션 인벤토리에 새로 도입된 항목)와 관련하여 애플리케이션 승격 주제를 고려할 때 이러한 API 오브젝트의 몇 가지 주요 설계 지점이 있습니다.

먼저 OpenShift Container Platform 문서 전체에서 강조 표시된 대로 모든 API 오브젝트를 JSON 또는 YAML을 통해 표현할 수 있으므로 기존 소스 제어 및 스크립팅을 통해 이러한 리소스 정의를 쉽게 관리할 수 있습니다.

또한 API 오브젝트는 원하는 시스템의 상태를 지정하는 오브젝트의 일부와 시스템의 상태 또는 현재 상태를 반영하는 기타 부분을 제공하도록 설계되었습니다. 이는 입력 및 출력으로 간주할 수 있습니다. 입력 부분은 JSON 또는 YAML로 표현되는 경우 특히 SCM(소스 제어 관리) 아티팩트로 자연스럽게 적용되는 항목입니다.

참고

API 오브젝트의 입력 또는 사양 부분은 완전히 정적이거나 동적일 수 있으므로 템플릿 처리를 통한 변수 대체 가 인스턴스화할 때 가능합니다.

API 오브젝트와 관련된 이러한 포인트의 결과는 해당 표현식을 JSON 또는 YAML 파일로 사용하면 애플리케이션 구성을 코드로 처리할 수 있다는 것입니다.

거의 모든 API 오브젝트가 조직의 애플리케이션 아티팩트로 간주될 수 있습니다. 다음은 애플리케이션 배포 및 관리와 관련된 오브젝트입니다.

BuildConfigs: 이는 애플리케이션 승격과 관련하여 특별한 사례 리소스입니다. BuildConfig 는 확실히 애플리케이션의 일부이지만 특히 개발자 관점에서는 BuildConfig 가 파이프라인을 통해 승격되지 않습니다. 파이프라인을 통해 승격된(다른 항목과 함께) 이미지를 생성합니다.
템플릿: 애플리케이션 승격 측면에서 템플릿 은 특히 매개 변수화 기능을 사용하여 지정된 스테이징 환경에서 리소스를 설정하기 위한 시작점 역할을 할 수 있습니다. 추가 복원 후 수정은 애플리케이션이 승격 파이프라인을 통해 이동하는 경우에도 매우 적용할 수 있습니다. 이에 대한 자세한 내용은 시나리오 및 예제 를 참조하십시오.
라우트: 이는 경로 를 통해 애플리케이션 액세스의 다양한 단계에 대한 테스트로서 애플리케이션 승격 파이프라인에서 단계마다 다른 가장 일반적인 리소스입니다. 또한 수동 사양 또는 호스트 이름의 자동 생성과 경로 의 HTTP 수준 보안과 관련된 옵션이 있습니다.
서비스: 지정된 애플리케이션 승격 단계(빠른 단계에서 개별 개발자를 위해 간단하게 수행)에서 router 및 Routes 를 방지하기 위한 이유가 있는 경우, Cluster IP 주소와 포트를 통해 애플리케이션에 액세스할 수 있습니다. 사용되는 경우 단계 간 주소와 포트 관리를 일부 확인할 수 있습니다.
끝점: 특정 애플리케이션 수준 서비스(예: 많은 엔터프라이즈의 데이터베이스 인스턴스)는 OpenShift Container Platform에서 관리하지 않을 수 있습니다. 그런 다음 해당 엔드포인트 를 직접 만든 다음 해당 엔드포인트를 직접 생성하는 경우( 서비스 의 선택기 필드 작성)는 중복되거나 단계 간에 공유되는 활동입니다(사용자 환경 위임 방법 기반).
보안: 시크릿에 의해 캡슐화된 민감한 정보는 해당 엔티티(OpenShift Container Platform에서 관리하는 서비스 또는 OpenShift Container Platform 외부에서 관리되는 외부 서비스)가 공유하는 경우 스테이징 환경 간에 공유됩니다. 애플리케이션 승격 파이프라인의 서로 다른 단계에 있는 엔터티의 다양한 버전이 있는 경우 파이프라인의 각 단계에서 고유한 보안을 유지하거나 파이프라인을 통과하면서 수정할 수 있습니다. 또한 SCM에 JSON 또는 YAML 로 보안을 저장하는 경우 중요한 정보를 보호하기 위해 일종의 암호화가 보장될 수 있습니다.
DeploymentConfigs: 이 오브젝트는 지정된 애플리케이션 승격 파이프라인 단계에 대한 환경을 정의하고 범위를 지정하는 데 필요한 기본 리소스입니다. 애플리케이션 시작 방법을 제어합니다. 모든 다른 단계에서 공통적인 측면이 있지만, 애플리케이션 승격 파이프라인을 통해 진행됨에 따라 각 단계의 환경의 차이를 반영하거나 애플리케이션의 다양한 시나리오 테스트를 용이하게 하기 위해 시스템 동작의 변화가 변경되어 있습니다.
ImageStreams, ImageStreamTags, ImageStreamImage: 이미지 및 이미지 스트림 섹션에 자세히 설명된 이러한 오브젝트는 컨테이너 이미지 관리에 대한 OpenShift Container Platform 추가의 핵심입니다. ???
serviceaccounts 및 RoleBindings: OpenShift Container Platform 내의 다른 API 오브젝트와 외부 서비스에 대한 권한 관리는 애플리케이션을 관리하는 데 기본적으로 사용됩니다. Secrets 와 유사하게 ServiceAccounts 및 RoleBindings 오브젝트는 서로 다른 환경을 공유하거나 분리해야 하는 애플리케이션 승격 파이프라인의 다양한 단계 간에 공유되는 방법에 따라 다를 수 있습니다.
PersistentVolumeClaims: 데이터베이스와 같은 상태 저장 서비스와 관련하여 서로 다른 애플리케이션 승격 단계 간에 공유하는 양과 조직이 애플리케이션 데이터의 사본을 공유하는 방법과 직접 관련이 있습니다.
ConfigMaps: Pod 자체에서 포드 구성의 유용한 분리(환경 변수 스타일 구성의 경우)는 일관된 Pod 동작이 필요한 경우 다양한 스테이징 환경에서 공유할 수 있습니다. 포드 동작을 변경하기 위해 단계 간에 수정할 수도 있습니다(일반적으로 애플리케이션의 다양한 측면이 다른 단계에서 심사됨).

2.3.2.2. 이미지
링크 복사

앞에서 언급했듯이 컨테이너 이미지는 이제 애플리케이션의 아티팩트입니다. 사실, 새로운 애플리케이션 아티팩트를 통해 이미지와 이미지 관리는 애플리케이션 승격과 관련된 주요 요소입니다. 경우에 따라 이미지가 애플리케이션의 전체를 캡슐화할 수 있으며 애플리케이션 승격 흐름은 이미지 관리만으로 구성됩니다.

일반적으로 이미지는 애플리케이션 바이너리가 이전 시스템에 없는 것처럼 SCM 시스템에서 관리되지 않습니다. 그러나 바이너리, 설치 가능한 아티팩트 및 해당 리포지토리(즉, RPM 리포지토리, RPM 리포지토리, Nexus 등)와 마찬가지로 SCM과 유사한 이미지 관리, 유사한 구조 및 용어와 유사한 구조 및 용어가 발생합니다.

이미지 레지스트리 == SCM 서버
이미지 리포지토리 == SCM 리포지토리

이미지가 레지스트리에 있으므로 해당 이미지에서 나타내는 애플리케이션을 실행해야 하는 환경에서 액세스할 수 있는 레지스트리에 적절한 이미지가 있는지 확인하는 것과 관련된 애플리케이션 승격입니다.

이미지를 직접 참조하지 않고 애플리케이션 정의는 일반적으로 이미지 스트림에 대한 참조를 추상화합니다. 즉, 이미지 스트림은 애플리케이션 구성 요소를 구성하는 또 다른 API 오브젝트가 됩니다. 이미지 스트림에 대한 자세한 내용은 핵심 개념을 참조하십시오.

2.3.2.3. 요약
링크 복사

이제 OpenShift Container Platform 내에서 애플리케이션 승격과 관련된 참고 사항, 이미지 및 API 오브젝트의 애플리케이션 아티팩트에 자세히 설명되어 있습니다. 승격 파이프라인의 다양한 단계에서 애플리케이션을 실행하는 위치는 토론 지점 옆에 있습니다.

2.3.3. 배포 환경
링크 복사

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

단일 프로젝트 내에서 레이블 및 고유한 이름 지정을 통해
클러스터 내의 다양한 프로젝트를 통해
별도의 클러스터를 통해.

그리고 귀하의 조직이 세 가지를 모두 활용할 수 있다고 생각할 수 있습니다.

2.3.3.1. 고려 사항
링크 복사

일반적으로 배포 환경을 구성하는 방법에 다음과 같은 추론을 고려합니다.

승격 흐름의 다양한 단계를 허용하는 리소스 양
승격 흐름의 다양한 단계를 얼마나 격리해야하는지
승격 흐름의 다양한 단계를 중앙에서 (또는 지리적으로 분산) 중앙 위치(또는 지리적으로 분산) 방법

또한 OpenShift Container Platform 클러스터 및 프로젝트가 이미지 레지스트리와 관련된 방법에 대한 몇 가지 중요한 알림은 다음과 같습니다.

동일한 클러스터의 여러 프로젝트에서 동일한 이미지 스트림에 액세스할 수 있습니다.
여러 클러스터가 동일한 외부 레지스트리에 액세스할 수 있습니다.
클러스터는 OpenShift Container Platform 내부 이미지 레지스트리가 경로를 통해 노출되는 경우에만 레지스트리를 공유할 수 있습니다.

2.3.3.2. 요약
링크 복사

배포 환경을 정의한 후에는 파이프라인 내에서 단계가 중단되는 승격 흐름을 구현할 수 있습니다. 이러한 승격 흐름 구현을 구성하는 방법과 도구는 다음 토론 포인트입니다.

2.3.4. 방법 및 도구
링크 복사

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

참고

빌드 및 배포 프로세스 중 사용할 수 있는 삽입 지점이 많이 있습니다. BuildConfig 및 DeploymentConfig API 오브젝트 내에 정의됩니다. 이러한 후크를 사용하면 데이터베이스 및 OpenShift Container Platform 클러스터 자체와 같이 배포된 구성 요소와 상호 작용할 수 있는 사용자 정의 스크립트를 호출할 수 있습니다.

따라서 이러한 후크를 사용하여 환경 간에 애플리케이션을 효과적으로 이동하는 구성 요소 관리 작업을 수행할 수 있습니다. 예를 들어 후크 내에서 이미지 태그 작업을 수행할 수 있습니다. 그러나 다양한 후크 포인트는 특정 환경 내에서 애플리케이션의 라이프사이클을 관리하는 데 가장 적합합니다(예: 새 버전의 애플리케이션이 배포될 때 데이터베이스 스키마 마이그레이션을 수행하기 위해 사용) 환경 간에 애플리케이션 구성 요소를 이동하는 것이 좋습니다.

2.3.4.1. API 오브젝트 관리
링크 복사

하나의 환경에 정의된 대로 리소스는 새 환경으로 가져오기 위해 JSON 또는 YAML 파일 콘텐츠로 내보냅니다. 따라서 JSON 또는 YAML로 API 오브젝트의 표현식은 애플리케이션 파이프라인을 통해 API 오브젝트를 승격하는 작업 단위 역할을 합니다. oc CLI는 이 콘텐츠를 내보내고 가져오는 데 사용됩니다.

작은 정보

파일에 저장된 JSON 또는 YAML로 OpenShift Container Platform을 통한 승격 흐름에는 필요하지 않지만 SCM 시스템에서 콘텐츠를 저장하고 검색할 수 있습니다. 이를 통해 분기 생성, 다양한 라벨 또는 버전에 연결된 태그를 비롯하여 SCM의 버전 관리 관련 기능을 활용할 수 있습니다.

2.3.4.1.1. API 오브젝트 상태 내보내기
링크 복사

oc export 를 사용하여 API 오브젝트 사양을 캡처해야 합니다. 이 작업은 오브젝트 정의(예: 현재 네임스페이스 또는 할당된 IP 주소)에서 환경별 데이터를 제거하여 다른 환경에서 재생성할 수 있습니다(예: 오브젝트의 필터링되지 않은 상태를 출력하는 oc get 작업 제외).

라벨에 단일 작업에서 Pod 그룹을 선택하고 관리할 수 있으므로 API 오브젝트에서 레이블을 추가, 수정 또는 제거할 수 있는 oc 레이블 을 사용하면 승격 흐름을 위해 수집되는 오브젝트 집합을 구성하는 것으로 유용할 수 있습니다. 이를 통해 올바른 오브젝트 세트를 쉽게 내보낼 수 있으며, 레이블이 새 환경에서 오브젝트를 생성할 때 전달되므로 각 환경에서 애플리케이션 구성 요소를 보다 쉽게 관리할 수 있습니다.

참고

API 오브젝트에는 종종 보안을 참조하는 DeploymentConfig 와 같은 참조가 포함되어 있습니다. 하나의 환경에서 다른 환경으로 API 오브젝트를 이동할 때 이러한 참조도 새 환경으로 이동해야 합니다.

마찬가지로 DeploymentConfig 와 같은 API 오브젝트에는 외부 레지스트리를 참조하는 ImageStreams 에 대한 참조가 포함되는 경우가 많습니다. 하나의 환경에서 다른 환경으로 API 오브젝트를 이동할 때 이러한 참조를 새 환경 내에서 확인할 수 있는지 확인해야 합니다. 즉, 참조를 확인할 수 있어야 하며 ImageStream 이 새 환경에서 액세스할 수 있는 레지스트리를 참조해야 합니다. 자세한 내용은 이미지 이동 및 프로모션 Caveats 를 참조하십시오.

2.3.4.1.2. API 오브젝트 상태 가져오기
링크 복사

2.3.4.1.2.1. 초기 생성
링크 복사

애플리케이션이 새 환경에 처음 소개되는 경우 API 오브젝트의 사양을 표시하고 oc create 를 실행하여 적절한 환경에서 애플리케이션을 생성하는 JSON 또는 YAML로 충분합니다. oc create 를 사용하는 경우 --save-config 옵션을 고려하십시오. 주석 목록에 있는 오브젝트에 구성 요소를 저장하면 나중에 oc apply 를 사용하여 오브젝트를 수정할 수 있습니다.

2.3.4.1.2.2. 반복적 수정
링크 복사

다양한 스테이징 환경이 초기에 설정되고, 승격 주기가 시작되고 애플리케이션이 스테이지에서 단계로 이동하면 애플리케이션의 일부인 API 오브젝트의 수정이 포함될 수 있습니다. 이러한 API 오브젝트의 변경 사항은 OpenShift Container Platform 시스템의 구성을 나타내기 때문에 가능합니다. 이러한 변경에 대한 동기는 다음과 같습니다.

스테이징 환경 간의 환경 차이점에 대한 회계입니다.
애플리케이션에서 지원하는 다양한 시나리오 확인.

oc CLI를 사용하여 API 오브젝트를 다음 단계의 환경으로 전송합니다. API 오브젝트를 수정하는 다양한 oc 명령 세트가 있지만 이 주제에서는 oc apply, which computes and applies differences between objects에 중점을 둡니다.

특히 oc apply 를 기존 오브젝트 정의와 함께 입력으로 사용하는 3방향 병합으로 볼 수 있습니다. 다음과 같은 3방향 병합을 수행합니다.

상기 명령 입력은, The input to the command,
상기 객체의 현재 버전, 및 The current version of the object, and
현재 오브젝트에 주석으로 저장된 최신 사용자 지정 오브젝트 정의입니다.

그런 다음 기존 오브젝트가 결과로 업데이트됩니다.

오브젝트가 소스와 대상 환경 간에 동일할 것으로 예상되는 경우와 같이 API 오브젝트의 추가 사용자 정의가 필요한 경우 oc set 와 같은 oc 명령을 사용하여 업스트림 환경의 최신 오브젝트 정의를 적용한 후 오브젝트를 수정할 수 있습니다.

몇 가지 구체적인 사용은 시나리오와 예에 인용되어 있습니다.

2.3.4.2. 이미지 및 이미지 스트림 관리
링크 복사

OpenShift Container Platform의 이미지는 일련의 API 오브젝트를 통해 관리됩니다. 그러나 이미지 관리는 이미지에 가장 직접적으로 연결된 도구 및 API 오브젝트에 대한 토론을 애플리케이션 승격의 핵심입니다. 이미지 승격(파이프론을 통해 이미지 승격)을 관리하는 데 도움이 되는 수동 및 자동 양식이 모두 존재합니다.

2.3.4.2.1. 이미지 이동
링크 복사

참고

이미지 관리와 관련된 자세한 경고 사항은 이미지 관리 주제를 참조하십시오.

2.3.4.2.1.2. 태그 환경에서 다른 레지스트리를 사용하는 경우
링크 복사

스테이징 환경에서 다른 OpenShift Container Platform 레지스트리를 사용하는 경우 고급 사용량이 발생합니다. 내부 레지스트리에 액세스하는 단계는 자세히 나와지만 요약하면 다음과 같습니다.

docker 로그인 명령에 제공할 OpenShift Container Platform 액세스 토큰을 가져오는 docker 명령을 사용합니다.
OpenShift Container Platform 레지스트리에 로그인한 후 docker pull,docker tag 및 docker push 를 사용하여 이미지를 전송합니다.
다음 파이프라인 환경의 레지스트리에서 이미지를 사용할 수 있는 후 필요에 따라 oc tag 를 사용하여 이미지 스트림을 채웁니다.

2.3.4.2.2. 배포
링크 복사

기본 애플리케이션 이미지 또는 애플리케이션을 구성하는 API 오브젝트를 변경하든 관계없이 승격된 변경 사항을 가져오기 위해 일반적으로 배포가 필요합니다. 애플리케이션 이미지가 변경되는 경우(예: 업스트림 환경에서 이미지를 승격하는 과정의 일부로 oc tag 작업 또는 docker push 로 인해) DeploymentConfig 의 ImageChangeTriggers 가 새 배포를 트리거할 수 있습니다. 마찬가지로 DeploymentConfig API 오브젝트 자체를 변경하는 경우 ConfigChangeTrigger 는 승격 단계에서 API 오브젝트를 업데이트할 때(예: oc apply) 배포를 시작할 수 있습니다.

그러지 않으면 수동 배포를 용이하게 하는 oc 명령은 다음과 같습니다.

oc rollout: 일시 중지 및 의미 체계를 다시 시작하고 기록 관리에 대한 풍부한 기능을 포함하여 배포를 관리하는 새로운 접근 방식입니다.
oc rollback: 이전 배포로 되돌릴 수 있습니다. 승격 시나리오에서 새 버전 테스트에 문제가 발생하면 이전 버전과 함께 여전히 작동하는지 확인할 수 있습니다.

2.3.4.2.3. Jenkins를 사용하여 승격 흐름 자동화
링크 복사

승격 시 환경 간에 이동해야 하는 애플리케이션의 구성 요소와 구성 요소를 이동하는 데 필요한 단계를 이해한 후 워크플로를 오케스트레이션하고 자동화할 수 있습니다. OpenShift Container Platform은 이 프로세스에 도움이 되는 Jenkins 이미지 및 플러그인을 제공합니다.

OpenShift Container Platform Jenkins 이미지는 Jenkins 및 Jenkins 파이프라인의 통합을 용이하게 하는 OpenShift Container Platform 중심 플러그인 세트를 포함하여 이미지 사용을 자세히 설명합니다. 또한 Pipeline 빌드 전략은 Jenkins Pipelines와 OpenShift Container Platform 간의 통합을 지원합니다. 이러한 모든 초점은 애플리케이션 프로모션을 포함하여 CI/CD의 다양한 측면을 지원하는 데 중점을 둡니다.

애플리케이션 승격 단계의 수동 실행 이상으로 이동할 때 OpenShift Container Platform에서 제공하는 Jenkins 관련 기능을 염두에 두어야 합니다.

OpenShift Container Platform은 OpenShift Container Platform 클러스터에서 쉽게 배포할 수 있도록 사용자 지정된 Jenkins 이미지를 제공합니다.
Jenkins 이미지에는 승격 워크플로 구현을 위한 구성 블록을 제공하는 OpenShift Pipeline 플러그인이 포함되어 있습니다. 이러한 빌드 블록에는 Jenkins 작업의 트리거와 이미지 스트림 변경, 해당 작업 내의 빌드 및 배포 트리거가 포함됩니다.
OpenShift Container Platform Jenkins 파이프라인 빌드 전략을 사용하는 BuildConfig 는 Jenkinsfile 기반 Jenkins 파이프라인 작업을 실행할 수 있습니다. 파이프라인 작업은 Jenkins의 복잡한 승격 흐름을 위한 전략적 방향이며 OpenShift Pipeline 플러그인에서 제공하는 단계를 활용할 수 있습니다.

2.3.4.2.4. Egree Caveats
링크 복사

2.3.4.2.4.1. API 오브젝트 참조
링크 복사

API 오브젝트는 다른 오브젝트를 참조할 수 있습니다. 이 문제의 일반적인 사용은 이미지 스트림을 참조하는 DeploymentConfig 가 있지만 다른 참조 관계가 존재할 수도 있습니다.

한 환경에서 다른 환경으로 API 오브젝트를 복사할 때 대상 환경에서 여전히 모든 참조를 확인할 수 있어야 합니다. 고려해야 할 몇 가지 참조 시나리오가 있습니다.

이 참조는 프로젝트의 "로컬"입니다. 이 경우 참조된 오브젝트는 참조하는 오브젝트와 동일한 프로젝트에 있습니다. 일반적으로 올바른 작업은 참조된 오브젝트를 참조하는 오브젝트와 동일한 프로젝트의 대상 환경에 복사하는 것입니다.
이 참조는 다른 프로젝트의 오브젝트입니다. 이는 일반적으로 공유 프로젝트의 이미지 스트림을 여러 애플리케이션 프로젝트에서 사용하는 경우입니다( 이미지 관리참조). 이 경우 참조 오브젝트를 새 환경에 복사할 때 대상 환경에서 해결될 수 있도록 필요에 따라 참조를 업데이트해야 합니다. 이는 다음을 의미할 수 있습니다.
- 대상 환경에서 공유 프로젝트의 이름이 다른 경우 참조를 가리키는 프로젝트를 변경합니다.
- 참조된 오브젝트를 대상 환경의 로컬 프로젝트로 이동하고 기본 오브젝트를 대상 환경으로 이동할 때 로컬 프로젝트를 가리키도록 참조를 업데이트합니다.
- 참조된 오브젝트를 대상 환경에 복사하고 참조 참조를 업데이트하는 다른 조합의 일부입니다.

일반적으로 지침은 새 환경에 복사 중인 개체에서 참조하는 오브젝트를 고려하고 대상 환경에서 참조를 확인할 수 있는지 확인하는 것입니다. 그렇지 않은 경우 참조를 수정하고 대상 환경에서 참조된 오브젝트를 사용할 수 있도록 적절한 조치를 취하십시오.

2.3.4.2.4.2. 이미지 레지스트리 참조
링크 복사

이미지 스트림은 이미지 리포지터리를 참조하여 표시되는 이미지의 소스를 나타냅니다. 이미지 스트림이 한 환경에서 다른 환경으로 이동하는 경우 레지스트리 및 리포지토리 참조도 변경해야 하는지 여부를 고려하는 것이 중요합니다.

다른 이미지 레지스트리를 사용하여 테스트 환경과 프로덕션 환경 간의 격리를 어설션합니다.
다른 이미지 리포지토리를 사용하여 테스트 및 프로덕션 지원 이미지를 분리합니다.

이러한 경우 올바른 이미지로 해석되도록 소스 환경에서 대상 환경으로 복사할 때 이미지 스트림을 수정해야 합니다. 이는 Scenarios 및 Examples에 설명된 단계를 수행하여 하나의 레지스트리와 저장소의 이미지를 다른 레지스트리로 복사하는 것도 가능합니다.

2.3.4.3. 요약
링크 복사

이 시점에서 다음이 정의됩니다.

배포된 애플리케이션을 구성하는 새 애플리케이션 아티팩트입니다.
OpenShift Container Platform에서 제공하는 툴 및 개념과 애플리케이션 승격 활동에 대한 상관 관계입니다.
OpenShift Container Platform과 CI/CD 파이프라인 엔진 Jenkins 간 통합

OpenShift Container Platform 내에서 애플리케이션 승격 흐름의 예를 함께 배치하는 것은 이 항목의 마지막 단계입니다.

2.3.5. 시나리오 및 예
링크 복사

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

애플리케이션을 구성하는 구성 요소 중 이미지는 주 아티팩트입니다. 온프레미스를 가져와서 애플리케이션 승격으로 확장하는 경우 핵심, 기본 애플리케이션 승격 패턴은 이미지 승격입니다. 여기서 작업 단위가 이미지입니다. 대부분의 애플리케이션 프로모션 시나리오에는 승격 파이프라인을 통해 이미지를 관리하고 전파해야 합니다.

간단한 시나리오는 파이프라인을 통해 이미지를 관리하고 전파하기만 하면 됩니다. 승격 시나리오가 범위가 넓어짐에 따라 다른 애플리케이션 아티팩트(특히 API 오브젝트)가 파이프라인을 통해 관리되고 전파되는 항목에 포함됩니다.

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

2.3.5.1. 프로모션에 대한 설정
링크 복사

애플리케이션의 초기 버전 개발을 완료한 후 다음 논리적 단계는 승격 파이프라인의 후속 스테이징 환경으로 전송할 수 있도록 애플리케이션의 콘텐츠를 패키징하는 것입니다.

먼저 전송 가능으로 보는 모든 API 오브젝트를 그룹화하고 여기에 공통 라벨을 적용합니다.
```
labels:
  promotion-group: <application_name>
```
```
labels:
  promotion-group: <application_name>
```
Copy to Clipboard Toggle word wrap
앞에서 설명한 대로 oc label 명령은 다양한 API 오브젝트를 사용하여 라벨을 쉽게 관리할 수 있습니다.
작은 정보
OpenShift Container Platform 템플릿에서 처음에 API 오브젝트를 정의하는 경우 프로모션 준비를 위해 내보낼 때 모든 관련 오브젝트에 공통 라벨이 있는지 쉽게 확인할 수 있습니다.
후속 쿼리에서 해당 라벨을 사용할 수 있습니다. 예를 들어 애플리케이션 API 오브젝트를 전송할 수 있는 다음 oc 명령 호출 세트를 고려하십시오.
```
oc login <source_environment>
oc project <source_project>
oc export dc,is,svc,route,secret,sa -l promotion-group=<application_name> -o yaml > export.yaml
oc login <target_environment>
oc new-project <target_project>
oc create -f export.yaml
```
```
$ oc login <source_environment>
$ oc project <source_project>
$ oc export dc,is,svc,route,secret,sa -l promotion-group=<application_name> -o yaml > export.yaml
$ oc login <target_environment>
$ oc new-project <target_project> 
```
1
```
$ oc create -f export.yaml
```
Copy to Clipboard Toggle word wrap
1
또는 이미 존재하는 경우 oc 프로젝트 <target_project >입니다.
참고
oc export 명령에서 이미지 스트림의 유형이 포함되는지 여부 는 파이프라인의 다양한 환경에서 이미지, 이미지 스트림 및 레지스트리를 관리하는 방법에 따라 다릅니다. 이 문제의 경고는 아래에서 설명합니다. 이미지 관리 주제도 참조하십시오.
승격 파이프라인의 다양한 스테이징 환경에서 사용되는 각 레지스트리에 대해 작동하는 데 필요한 토큰도 가져와야 합니다. 각 환경에 대해 다음을 수행합니다.
1. 환경에 로그인합니다.
  $ oc login <each_environment_with_a_unique_registry>
  Copy to Clipboard Toggle word wrap
2. 다음을 사용하여 액세스 토큰을 가져옵니다.
  $ oc whoami -t
  Copy to Clipboard Toggle word wrap
3. 나중에 사용할 수 있도록 토큰 값을 복사하여 붙여넣습니다.

2.3.5.2. 반복 가능한 프로모션 프로세스
링크 복사

파이프라인에 대한 다양한 스테이징 환경을 설정한 후 반복 가능한 단계 세트를 통해 승격 파이프라인을 통해 애플리케이션의 각 반복을 검증할 수 있습니다. 소스 환경의 이미지 또는 API 오브젝트가 변경될 때마다 이러한 기본 단계가 수행됩니다.

업데이트된 이미지 이동 → 업데이트된 API 오브젝트 이동 → 환경별 사용자 정의 적용

일반적으로 첫 번째 단계는 애플리케이션과 관련된 이미지 업데이트를 파이프라인의 다음 단계로 승격하는 것입니다. 위에서 언급했듯이 이미지 승격의 주요 차이점은 OpenShift Container Platform 레지스트리가 스테이징 환경 간에 공유되는지 여부입니다.
1. 레지스트리를 공유하는 경우 oc 태그 를 활용합니다.
  $ oc tag <project_for_stage_N>/<imagestream_name_for_stage_N>:<tag_for_stage_N> <project_for_stage_N+1>/<imagestream_name_for_stage_N+1>:<tag_for_stage_N+1>
  Copy to Clipboard Toggle word wrap
2. 레지스트리가 공유되지 않는 경우 소스 및 대상 레지스트리에 로그인하여 애플리케이션 이미지를 적절하게 푸시할 때 승격된 각 파이프라인 레지스트리의 액세스 토큰을 활용할 수 있습니다.
  1. 소스 환경 레지스트리에 로그인합니다.
    
    $ docker login -u <username> -e <any_email_address> -p <token_value> <src_env_registry_ip>:<port>
    
    Copy to Clipboard Toggle word wrap
  2. 애플리케이션의 이미지를 가져옵니다.
    
    $ docker pull <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
    
    Copy to Clipboard Toggle word wrap
  3. 애플리케이션 이미지를 대상 레지스트리의 위치에 태그하고, 대상 스테이징 환경을 준수하는 데 필요한 네임스페이스, 이름 및 태그를 업데이트합니다.
    
    $ docker tag <src_env_registry_ip>:<port>/<namespace>/<image name>:<tag> <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
    
    Copy to Clipboard Toggle word wrap
  4. 대상 스테이징 환경 레지스트리에 로그인합니다.
    
    $ docker login -u <username> -e <any_email_address> -p <token_value> <dest_env_registry_ip>:<port>
    
    Copy to Clipboard Toggle word wrap
  5. 이미지를 대상으로 푸시합니다.
    
    $ docker push <dest_env_registry_ip>:<port>/<namespace>/<image name>:<tag>
    
    Copy to Clipboard Toggle word wrap
    
    작은 정보
    외부 레지스트리에서 새 버전의 이미지를 자동으로 가져오려면 oc tag 명령에 --scheduled 옵션이 있습니다. 사용하는 경우 ImageStreamTag 참조는 이미지를 호스팅하는 레지스트리에서 주기적으로 가져옵니다.
다음으로 애플리케이션 진화에서 API 오브젝트에 대한 기본 변경이나 애플리케이션을 구성하는 API 오브젝트 집합에서 추가 및 삭제 작업을 수행해야 하는 경우가 있습니다. 애플리케이션 API 오브젝트의 이러한 진화가 발생하면 OpenShift Container Platform CLI는 하나의 스테이징 환경에서 다음 단계로 변경할 수 있는 광범위한 옵션을 제공합니다.
1. 프로모션 파이프라인을 처음 설정할 때와 동일한 방식으로 시작합니다.
  $ oc login <source_environment> $ oc project <source_project> $ oc export dc,is,svc,route,secret,sa -l promotion-group=<application_name> -o yaml > export.yaml $ oc login <target_environment> $ oc <target_project>
  Copy to Clipboard Toggle word wrap
2. 단순히 새 환경에서 리소스를 생성하는 대신 업데이트합니다. 이 작업은 다음과 같은 몇 가지 방법으로 수행할 수 있습니다.
  1. 더 보수적인 접근 방식은 oc apply 를 활용하고 대상 환경의 각 API 오브젝트에 새로운 변경 사항을 병합하는 것입니다. 이렇게 하면 --dry-run=true 옵션을 사용하고 실제로 오브젝트를 변경하기 전에 결과 오브젝트를 검사할 수 있습니다.
    
    $ oc apply -f export.yaml --dry-run=true
    
    Copy to Clipboard Toggle word wrap
    
    충족되면 실제로 apply 명령을 실행합니다.
    
    $ oc apply -f export.yaml
    
    Copy to Clipboard Toggle word wrap
    
    apply 명령은 경우에 따라 더 복잡한 시나리오에 도움이 되는 추가 인수를 사용합니다. 자세한 내용은 oc apply --help 를 참조하십시오.
  2. 또는 더 간단하고 공격적인 접근 방식은 oc replace 를 활용하는 것입니다. 이 업데이트 및 교체와 함께 예행 연습이 없습니다. 가장 기본적인 형태로 다음을 실행합니다.
    
    $ oc replace -f export.yaml
    
    Copy to Clipboard Toggle word wrap
    
    적용되는 것과 마찬가지로Replace 는 보다 정교한 동작에 대한 추가 인수를 사용합니다. 자세한 내용은 oc replace --help 를 참조하십시오.
이전 단계에서는 도입된 새 API 오브젝트를 자동으로 처리하지만, 소스 환경에서 API 오브젝트가 삭제된 경우 oc delete 를 사용하여 대상 환경에서 수동으로 삭제해야 합니다.
API 오브젝트에 포함된 환경 변수 튜닝은 스테이징 환경마다 다를 수 있으므로 필요한 값이 필요할 수 있습니다. 이를 위해 oc set env 를 사용하십시오.
```
oc set env <api_object_type>/<api_object_ID> <env_var_name>=<env_var_value>
```
```
$ oc set env <api_object_type>/<api_object_ID> <env_var_name>=<env_var_value>
```
Copy to Clipboard Toggle word wrap
마지막으로 oc rollout 명령 또는 위의 Deployments 섹션에서 설명하는 다른 메커니즘 중 하나를 사용하여 업데이트된 애플리케이션의 새 배포를 트리거합니다.

2.3.5.3. Jenkins를 사용하여 반복 가능한 승격 프로세스
링크 복사

OpenShift Container Platform의 Jenkins Docker 이미지에 정의된 OpenShift 샘플 작업은 Jenkins 구문에서 OpenShift Container Platform 내의 이미지 승격 예제입니다. 이 샘플의 설정은 OpenShift Origin 소스 리포지토리에 있습니다.

이 샘플에는 다음이 포함됩니다.

Jenkins를 CI/CD 엔진으로 사용합니다.
Jenkins용 OpenShift Pipeline 플러그인을 사용합니다. 이 플러그인은 Jenkins Freestyle 및 DSL 작업 단계로 패키지된 OpenShift Container Platform용 oc CLI에서 제공하는 기능의 하위 집합을 제공합니다. oc 바이너리는 OpenShift Container Platform의 Jenkins Docker 이미지에도 포함되며 Jenkins 작업의 OpenShift Container Platform과 상호 작용하는 데도 사용할 수 있습니다.
Jenkins에 대한 OpenShift Container Platform 제공 템플릿입니다. 임시 스토리지 및 영구 스토리지용 템플릿이 있습니다.
샘플 애플리케이션: OpenShift Origin 소스 리포지토리에 정의된 이 애플리케이션은 ImageStreams,ImageChangeTriggers,ImageStreamTags,BuildConfigs, 및 승격 파이프라인의 다른 단계에 해당하는 별도의 DeploymentConfigs 및 Services 를 활용합니다.

다음은 OpenShift 샘플 작업의 다양한 부분을 자세히 검사합니다.

첫 번째 단계는 oc scale dc frontend --replicas=0 호출과 동일합니다. 이 단계는 실행 중일 수 있는 이전 버전의 애플리케이션 이미지를 중단하기 위한 것입니다.
두 번째 단계는 oc start-build frontend 호출과 동일합니다.
세 번째 단계는 oc rollout latest dc/frontend 호출과 동일합니다.
네 번째 단계는 이 샘플의 '테스트'입니다. 이를 통해 이 애플리케이션의 연결된 서비스가 네트워크 관점에서 실제로 액세스할 수 있습니다. 커버에서 소켓 연결은 OpenShift Container Platform 서비스와 연결된 IP 주소 및 포트에 대해 시도됩니다. 물론 OpenShift Pipepline 플러그인 단계를 통해 추가 테스트를 추가한 다음 Jenkins Shell 단계를 통해 OS 수준 명령 및 스크립트를 활용하여 애플리케이션을 테스트할 수 있습니다.
다섯 번째 단계는 애플리케이션 테스트가 통과되어 이미지를 "사용 가능"으로 표시하려는 가정 하에 시작됩니다. 이 단계에서는 최신 이미지에서 애플리케이션 이미지에 대한 새 prod 태그가 생성됩니다. 해당 태그에 대해 frontend DeploymentConfig 에 ImageChangeTrigger 가 정의되어 있으면 해당 "production" 배포가 시작됩니다.
마지막 단계는 플러그인에서 "프로덕션" 배포에 대해 원하는 수의 복제본 수를 시작했음을 확인하는 확인 단계입니다.

3장. 인증
링크 복사

3.1. 웹 콘솔 인증
링크 복사

< master_public_addr>:8443 의 브라우저에서 웹 콘솔에 액세스할 때 자동으로 로그인 페이지로 리디렉션됩니다.

웹 콘솔에 액세스하는 데 사용할 수 있는 브라우저 버전 및 운영 체제를 검토합니다.

이 페이지에서 로그인 자격 증명을 제공하여 API 호출을 위해 토큰을 가져올 수 있습니다. 로그인하면 웹 콘솔 을 사용하여 프로젝트를 탐색할 수 있습니다.

3.2. CLI 인증
링크 복사

CLI 명령 oc login 을 사용하여 명령줄에서 인증할 수 있습니다. 이 명령을 옵션 없이 실행하여 CLI를 시작할 수 있습니다.

oc login

$ oc login

Copy to Clipboard

Toggle word wrap

명령의 대화형 흐름은 제공된 인증 정보를 사용하여 OpenShift Container Platform 서버에 대한 세션을 설정하는 데 도움이 됩니다. OpenShift Container Platform 서버에 성공적으로 로그인하는 데 필요한 정보가 제공되지 않으면 명령은 필요에 따라 사용자 입력을 요청하는 메시지를 표시합니다. 이 구성은 자동으로 저장되며 이후의 모든 명령에 사용됩니다.

oc login --help 명령 출력에 나열된 oc login 명령의 모든 구성 옵션은 선택 사항입니다. 다음 예제에서는 몇 가지 일반적인 옵션과 함께 사용법을 보여줍니다.

oc login [-u=<username>] \
  [-p=<password>] \
  [-s=<server>] \
  [-n=<project>] \
  [--certificate-authority=</path/to/file.crt>|--insecure-skip-tls-verify]

$ oc login [-u=<username>] \
  [-p=<password>] \
  [-s=<server>] \
  [-n=<project>] \
  [--certificate-authority=</path/to/file.crt>|--insecure-skip-tls-verify]

Copy to Clipboard

Toggle word wrap

다음 표에서는 이러한 일반적인 옵션에 대해 설명합니다.

Expand

표 3.1. 일반 CLI 구성 옵션
옵션	구문	설명
`-s, --server`	`$ oc login -s=<server>` Copy to Clipboard Toggle word wrap	OpenShift Container Platform 서버의 호스트 이름을 지정합니다. 이 플래그를 통해 서버를 제공하면 명령에서 대화형으로 요청하지 않습니다. 이 플래그는 CLI 구성 파일이 이미 있고 다른 서버에 로그인하고 전환하려는 경우에도 사용할 수 있습니다.
`-u, --username` 및 `-p, --password`	`$ oc login -u=<username> -p=<password>` Copy to Clipboard Toggle word wrap	OpenShift Container Platform 서버에 로그인할 인증 정보를 지정할 수 있습니다. 이러한 플래그를 통해 사용자 이름 또는 암호를 제공하면 명령에서 대화형으로 요청하지 않습니다. 이러한 플래그는 세션 토큰이 설정된 구성 파일이 이미 있고 로그인하고 다른 사용자 이름으로 전환하려는 경우에도 사용할 수 있습니다.
`-n, --namespace`	`$ oc login -u=<username> -p=<password> -n=<project>` Copy to Clipboard Toggle word wrap	`oc login` 과 함께 사용하는 글로벌 CLI 옵션을 사용하면 지정된 사용자로 로그인할 때 전환할 프로젝트를 지정할 수 있습니다.
`--certificate-authority`	`$ oc login --certificate-authority=<path/to/file.crt>` Copy to Clipboard Toggle word wrap	HTTPS를 사용하는 OpenShift Container Platform 서버를 사용하여 정확하고 안전하게 인증합니다. 인증 기관 파일의 경로를 제공해야 합니다.
`--insecure-skip-tls-verify`	`$ oc login --insecure-skip-tls-verify` Copy to Clipboard Toggle word wrap	서버 인증서 확인을 바이패스하는 HTTPS 서버와의 상호 작용을 허용하지만 안전하지는 않습니다. 유효한 인증서를 제공하지 않는 HTTPS 서버에 `oc login` 을 시도하면 이 또는 `--certificate-authority` 플래그가 제공되지 않은 경우 `oc login` 에서 안전하지 않은 연결을 위해 사용자 입력(`y/N` 종류 입력)을 확인하라는 메시지를 표시합니다.

CLI 구성 파일을 사용하면 여러 CLI 프로필을 쉽게 관리할 수 있습니다.

참고

관리자 자격 증명에 대한 액세스 권한이 있지만 기본 시스템 사용자 system:admin 으로 더 이상 로그인하지 않은 경우 CLI 구성 파일에 인증 정보가 계속 있는 한 언제든지 이 사용자로 다시 로그인할 수 있습니다. 다음 명령은 로그인하고 기본 프로젝트로 전환합니다.

oc login -u system:admin -n default

$ oc login -u system:admin -n default

Copy to Clipboard

Toggle word wrap

4장. 권한 부여
링크 복사

4.1. 개요
링크 복사

이 주제에는 클러스터 관리자가 지정한 대로 애플리케이션 개발자와 해당 기능에 대한 권한 부여 작업이 포함되어 있습니다.

4.2. 사용자가 Pod를 만들 수 있는지 확인
링크 복사

scc-review 및 scc-subject-review 옵션을 사용하면 개별 사용자 또는 특정 서비스 계정의 사용자가 포드를 생성하거나 업데이트할 수 있는지 확인할 수 있습니다.

scc-review 옵션을 사용하여 서비스 계정에서 Pod를 생성하거나 업데이트할 수 있는지 확인할 수 있습니다. 이 명령은 리소스를 허용하는 보안 컨텍스트 제약 조건을 출력합니다.

예를 들어 system:serviceaccount:projectname:default 서비스 계정이 있는 사용자가 Pod를 생성할 수 있는지 확인하려면 다음을 실행합니다.

oc policy scc-review -z system:serviceaccount:projectname:default -f my_resource.yaml

$ oc policy scc-review -z system:serviceaccount:projectname:default -f my_resource.yaml

Copy to Clipboard

Toggle word wrap

scc-subject-review 옵션을 사용하여 특정 사용자가 Pod를 생성하거나 업데이트할 수 있는지 확인할 수도 있습니다.

oc policy scc-subject-review -u <username> -f my_resource.yaml

$ oc policy scc-subject-review -u <username> -f my_resource.yaml

Copy to Clipboard

Toggle word wrap

특정 그룹에 속하는 사용자가 특정 파일에 Pod를 생성할 수 있는지 확인하려면 다음을 수행하십시오.

oc policy scc-subject-review -u <username> -g <groupname> -f my_resource.yaml

$ oc policy scc-subject-review -u <username> -g <groupname> -f my_resource.yaml

Copy to Clipboard

Toggle word wrap

4.3. 인증된 사용자로 수행할 수 있는 작업 확인
링크 복사

OpenShift Container Platform 프로젝트 내에서 모든 네임스페이스 범위 리소스(타사 리소스 포함)에 대해 수행할 수 있는 동사 를 확인할 수 있습니다.

can-i 명령 옵션은 사용자 및 역할 측면에서 범위를 테스트합니다.

oc policy can-i --list --loglevel=8

$ oc policy can-i --list --loglevel=8

Copy to Clipboard

Toggle word wrap

출력에서는 정보를 수집할 API 요청을 결정하는 데 도움이 됩니다.

정보를 사용자가 읽을 수 있는 형식으로 다시 수신하려면 다음을 실행합니다.

oc policy can-i --list

$ oc policy can-i --list

Copy to Clipboard

Toggle word wrap

출력에 전체 목록이 제공됩니다.

특정 동사를 수행할 수 있는지 확인하려면 다음을 실행합니다.

oc policy can-i <verb> <resource>

$ oc policy can-i <verb> <resource>

Copy to Clipboard

Toggle word wrap

사용자 범위는 지정된 범위에 대한 자세한 정보를 제공할 수 있습니다. 예를 들어 다음과 같습니다.

oc policy can-i <verb> <resource> --scopes=user:info

$ oc policy can-i <verb> <resource> --scopes=user:info

Copy to Clipboard

Toggle word wrap

5장. 프로젝트
링크 복사

5.1. 개요
링크 복사

사용자 커뮤니티는 프로젝트를 통해 다른 커뮤니티와 별도로 콘텐츠를 구성하고 관리할 수 있습니다.

5.2. 프로젝트 생성
링크 복사

클러스터 관리자가 허용하는 경우 CLI 또는 웹 콘솔 을 사용하여 새 프로젝트를 생성할 수 있습니다.

5.2.1. 웹 콘솔 사용
링크 복사

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

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

5.2.2. CLI 사용
링크 복사

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

참고

작성할 수 있는 프로젝트 수는 시스템 관리자가 제한할 수 있습니다. 한도에 도달하면 새 프로젝트를 생성하려면 기존 프로젝트를 삭제해야 할 수 있습니다.

5.3. 프로젝트 보기
링크 복사

프로젝트를 볼 때 권한 부여 정책에 따라 볼 수 있는 액세스 권한이 있는 프로젝트만 볼 수 있습니다.

프로젝트 목록을 보려면 다음을 수행합니다.

oc get projects

$ oc get projects

Copy to Clipboard

Toggle word wrap

CLI 작업을 위해 현재 프로젝트에서 다른 프로젝트로 변경할 수 있습니다. 그러면 지정된 프로젝트가 프로젝트 범위의 콘텐츠를 조작하는 모든 후속 작업에서 사용됩니다.

oc project <project_name>

$ oc project <project_name>

Copy to Clipboard

Toggle word wrap

웹 콘솔 을 사용하여 프로젝트 간에 보고 변경할 수도 있습니다. 인증 및 로그인 후 액세스 권한이 있는 프로젝트 목록이 표시됩니다.

서비스 카탈로그와 함께 표시된 오른쪽 패널은 가장 최근에 액세스한 프로젝트(최대 5개의 프로젝트)에 빠르게 액세스할 수 있습니다. 전체 프로젝트 목록은 오른쪽 패널 상단에 있는 View All (모두 보기) 링크를 사용합니다.

CLI를 사용하여 새 프로젝트를 생성하는 경우 브라우저에서 페이지를 새로 고침하여 새 프로젝트를 확인할 수 있습니다.

프로젝트를 선택하면 해당 프로젝트의 프로젝트 개요 로 이동합니다.

특정 프로젝트의 kebab 메뉴를 클릭하면 다음 옵션이 표시됩니다.

5.4. 프로젝트 상태 확인
링크 복사

oc status 명령은 현재 프로젝트에 대한 고급 개요와 해당 구성 요소 및 해당 관계를 제공합니다. 이 명령은 인수를 사용하지 않습니다.

oc status

$ oc status

Copy to Clipboard

Toggle word wrap

5.5. 라벨로 필터링
링크 복사

리소스 레이블 을 사용하여 웹 콘솔 의 프로젝트 페이지 콘텐츠를 필터링할 수 있습니다. 제안된 라벨 이름과 값 중에서 선택하거나 자체적으로 를 입력할 수 있습니다. 여러 필터를 추가할 수 있습니다. 여러 필터를 적용하면 리소스가 모든 필터와 일치하여 표시됨을 유지해야 합니다.

라벨을 기준으로 필터링하려면 다음을 수행합니다.

라벨 유형을 선택합니다.

View larger image

다음 명령 중 하나를 선택합니다.

Exists	레이블 이름이 있지만 해당 값을 무시합니다.
존재하지 않음	레이블 이름이 없지만 해당 값을 무시합니다.
in	레이블 이름이 존재하고 선택한 값 중 하나와 같은지 확인합니다.
들어 있지 않음	레이블 이름이 없거나 선택한 값과 같지 않은지 확인합니다. View larger image 에서 선택한 경우 값 집합을 선택한 다음 필터 를 선택합니다. View larger image

필터를 추가한 후 모든 필터 지우기를 선택하거나 개별 필터를 클릭하여 필터 를 제거하여 필터링을 중지할 수 있습니다.

View larger image

5.6. 페이지 번호 표시
링크 복사

OpenShift Container Platform 웹 콘솔 은 이제 레이블 필터 및 기타 설정을 저장하는 데 도움이 되는 북마크 페이지 상태가 표시됩니다.

탭 간 전환과 같이 페이지 상태를 변경하려면 브라우저의 탐색 모음의 URL이 자동으로 업데이트됩니다.

5.7. 프로젝트 삭제
링크 복사

프로젝트를 삭제하면 서버에서 프로젝트 상태를 활성에서 종료로 업데이트합니다. 그런 다음 서버는 프로젝트를 마지막으로 제거하기 전에 종료 중인 프로젝트에서 모든 콘텐츠를 지웁니다. 프로젝트가 종료 상태인 동안 사용자는 프로젝트에 새 콘텐츠를 추가할 수 없습니다. CLI 또는 웹 콘솔에서 프로젝트를 삭제할 수 있습니다.

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

oc delete project <project_name>

$ oc delete project <project_name>

Copy to Clipboard

Toggle word wrap

6장. 애플리케이션 마이그레이션
링크 복사

6.1. 개요
링크 복사

이 주제에서는 OpenShift 버전 3(v3)으로 OpenShift 버전 2(v2) 애플리케이션의 마이그레이션 프로세스에 대해 설명합니다.

참고

이 주제에서는 OpenShift v2와 관련된 일부 용어를 사용합니다. OpenShift Enterprise 2와 OpenShift Enterprise 3을 비교하면 두 버전과 사용된 언어의 차이점에 대한 통찰력을 얻을 수 있습니다.

OpenShift v2 애플리케이션을 OpenShift Container Platform v3으로 마이그레이션하려면 v2 애플리케이션의 모든 카트리지를 각각 OpenShift Container Platform v3의 해당 이미지 또는 템플릿과 동일하므로 기록해야 하며 개별적으로 마이그레이션해야 합니다. 각 MongoDB마다 모든 종속 항목 또는 필수 패키지도 v3 이미지에 포함되어야 하므로 기록해야 합니다.

일반적인 마이그레이션 절차는 다음과 같습니다.

v2 애플리케이션을 백업합니다.
- 웹 카트리지: GitHub의 리포지토리로 내보내와 같은 Git 리포지토리로 소스 코드를 백업할 수 있습니다.
- 데이터베이스 카트리지: 덤프 명령(mongodump,mysqldump,pg_dump)을 사용하여 데이터베이스를 백업할 수 있습니다.
- 웹 및 데이터베이스 카트리지: rhc 클라이언트 툴은 여러 개의 Fluentd를 백업할 수 있는 스냅샷 기능을 제공합니다.
  $ rhc snapshot save <app_name>
  Copy to Clipboard Toggle word wrap
  스냅샷은 압축을 풀 수 있는 tar 파일이며 해당 내용은 애플리케이션 소스 코드와 데이터베이스 덤프입니다.
애플리케이션에 데이터베이스 카트리지가 있는 경우 v3 데이터베이스 애플리케이션을 생성하고 데이터베이스 덤프를 새 v3 데이터베이스 애플리케이션의 Pod로 동기화한 다음, 데이터베이스 복원 명령을 사용하여 v3 데이터베이스 애플리케이션의 v2 데이터베이스 데이터베이스를 복원합니다.
웹 프레임워크 애플리케이션의 경우 애플리케이션 소스 코드를 편집하여 v3와 호환되도록 합니다. 그런 다음 Git 리포지토리의 적절한 파일에 필요한 종속성 또는 패키지를 추가합니다. v2 환경 변수를 해당 v3 환경 변수로 변환합니다.
소스(Git 리포지토리) 또는 Git URL을 사용한 빠른 시작에서 v3 애플리케이션을 생성합니다. 또한 데이터베이스 서비스 매개 변수를 새 애플리케이션에 추가하여 데이터베이스 애플리케이션을 웹 애플리케이션에 연결합니다.
v2에는 통합 Git 환경이 있으며, 변경 사항이 v2 Git 리포지토리로 푸시될 때마다 애플리케이션이 자동으로 다시 빌드 및 재시작됩니다. v3에서 소스 코드 변경으로 인해 빌드가 자동으로 트리거되도록 하려면 v3의 초기 빌드가 완료된 후 Webhook 를 설정해야 합니다.

6.2. 데이터베이스 애플리케이션 마이그레이션
링크 복사

6.2.1. 개요
링크 복사

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

6.2.2. 지원되는 데이터베이스
링크 복사

Expand

v2	v3
MongoDB: 2.4	MongoDB: 2.4, 2.6
MySQL: 5.5	MySQL: 5.5, 5.6
PostgreSQL: 9.2	PostgreSQL: 9.2, 9.4

6.2.3. MySQL
링크 복사

모든 데이터베이스를 덤프 파일로 내보내고 로컬 머신 (현재 디렉토리에 있음)에 복사합니다.

rhc ssh <v2_application_name>
mysqldump --skip-lock-tables -h $OPENSHIFT_MYSQL_DB_HOST -P ${OPENSHIFT_MYSQL_DB_PORT:-3306} -u ${OPENSHIFT_MYSQL_DB_USERNAME:-'admin'} \
 --password="$OPENSHIFT_MYSQL_DB_PASSWORD" --all-databases > ~/app-root/data/all.sql
exit

$ rhc ssh <v2_application_name>
$ mysqldump --skip-lock-tables -h $OPENSHIFT_MYSQL_DB_HOST -P ${OPENSHIFT_MYSQL_DB_PORT:-3306} -u ${OPENSHIFT_MYSQL_DB_USERNAME:-'admin'} \
 --password="$OPENSHIFT_MYSQL_DB_PASSWORD" --all-databases > ~/app-root/data/all.sql
$ exit

Copy to Clipboard

Toggle word wrap

로컬 머신에 dbdump 를 다운로드합니다.

mkdir mysqldumpdir
rhc scp -a <v2_application_name> download mysqldumpdir app-root/data/all.sql

$ mkdir mysqldumpdir
$ rhc scp -a <v2_application_name> download mysqldumpdir app-root/data/all.sql

Copy to Clipboard

Toggle word wrap

템플릿에서 v3 mysql-persistent Pod를 생성합니다.

oc new-app mysql-persistent -p \
   MYSQL_USER=<your_V2_mysql_username> -p \
   MYSQL_PASSWORD=<your_v2_mysql_password> -p MYSQL_DATABASE=<your_v2_database_name>

$ oc new-app mysql-persistent -p \
   MYSQL_USER=<your_V2_mysql_username> -p \
   MYSQL_PASSWORD=<your_v2_mysql_password> -p MYSQL_DATABASE=<your_v2_database_name>

Copy to Clipboard

Toggle word wrap

Pod를 사용할 준비가 되었는지 확인합니다.
```
oc get pods
```
```
$ oc get pods
```
Copy to Clipboard Toggle word wrap
Pod가 실행 중이면 데이터베이스 아카이브 파일을 v3 MySQL Pod에 복사합니다.
```
oc rsync /local/mysqldumpdir <mysql_pod_name>:/var/lib/mysql/data
```
```
$ oc rsync /local/mysqldumpdir <mysql_pod_name>:/var/lib/mysql/data
```
Copy to Clipboard Toggle word wrap
v3 실행 Pod에서 데이터베이스를 복원합니다.
```
oc rsh <mysql_pod>
cd /var/lib/mysql/data/mysqldumpdir
```
```
$ oc rsh <mysql_pod>
$ cd /var/lib/mysql/data/mysqldumpdir
```
Copy to Clipboard Toggle word wrap
v3에서 데이터베이스를 복원하려면 root 사용자로 MySQL에 액세스해야 합니다.
v2에서 $OPENSHIFT_MYSQL_DB_USERNAME 에는 모든 데이터베이스에 대한 전체 권한이 있습니다. v3에서는 각 데이터베이스에 대해 $MYSQL_USER 에 권한을 부여해야 합니다.
```
mysql -u root
source all.sql
```
```
$ mysql -u root
$ source all.sql
```
Copy to Clipboard Toggle word wrap
< dbname >에 모든 권한을 < your_v2_username>@localhost 에 부여한 다음 권한을 플러시합니다.
Pod에서 덤프 디렉터리를 제거합니다.
```
cd ../; rm -rf /var/lib/mysql/data/mysqldumpdir
```
```
$ cd ../; rm -rf /var/lib/mysql/data/mysqldumpdir
```
Copy to Clipboard Toggle word wrap

지원되는 MySQL 환경 변수

Expand

v2	v3
`OPENSHIFT_MYSQL_DB_HOST`	`[service_name]_SERVICE_HOST`
`OPENSHIFT_MYSQL_DB_PORT`	`[service_name]_SERVICE_PORT`
`OPENSHIFT_MYSQL_DB_USERNAME`	`MYSQL_USER`
`OPENSHIFT_MYSQL_DB_PASSWORD`	`MYSQL_PASSWORD`
`OPENSHIFT_MYSQL_DB_URL`
`OPENSHIFT_MYSQL_DB_LOG_DIR`
`OPENSHIFT_MYSQL_VERSION`
`OPENSHIFT_MYSQL_DIR`
`OPENSHIFT_MYSQL_DB_SOCKET`
`OPENSHIFT_MYSQL_IDENT`
`OPENSHIFT_MYSQL_AIO`	`MYSQL_AIO`
`OPENSHIFT_MYSQL_MAX_ALLOWED_PACKET`	`MYSQL_MAX_ALLOWED_PACKET`
`OPENSHIFT_MYSQL_TABLE_OPEN_CACHE`	`MYSQL_TABLE_OPEN_CACHE`
`OPENSHIFT_MYSQL_SORT_BUFFER_SIZE`	`MYSQL_SORT_BUFFER_SIZE`
`OPENSHIFT_MYSQL_LOWER_CASE_TABLE_NAMES`	`MYSQL_LOWER_CASE_TABLE_NAMES`
`OPENSHIFT_MYSQL_MAX_CONNECTIONS`	`MYSQL_MAX_CONNECTIONS`
`OPENSHIFT_MYSQL_FT_MIN_WORD_LEN`	`MYSQL_FT_MIN_WORD_LEN`
`OPENSHIFT_MYSQL_FT_MAX_WORD_LEN`	`MYSQL_FT_MAX_WORD_LEN`
`OPENSHIFT_MYSQL_DEFAULT_STORAGE_ENGINE`
`OPENSHIFT_MYSQL_TIMEZONE`
	`MYSQL_DATABASE`
	`MYSQL_ROOT_PASSWORD`
	`MYSQL_MASTER_USER`
	`MYSQL_MASTER_PASSWORD`

6.2.4. PostgreSQL
링크 복사

장치에서 v2 PostgreSQL 데이터베이스를 백업합니다.

rhc ssh -a <v2-application_name>
mkdir ~/app-root/data/tmp
pg_dump <database_name> | gzip > ~/app-root/data/tmp/<database_name>.gz

$ rhc ssh -a <v2-application_name>
$ mkdir ~/app-root/data/tmp
$ pg_dump <database_name> | gzip > ~/app-root/data/tmp/<database_name>.gz

Copy to Clipboard

Toggle word wrap

백업 파일을 로컬 머신에 다시 추출합니다.

rhc scp -a <v2_application_name> download <local_dest> app-root/data/tmp/<db-name>.gz
gzip -d <database-name>.gz

$ rhc scp -a <v2_application_name> download <local_dest> app-root/data/tmp/<db-name>.gz
$ gzip -d <database-name>.gz

Copy to Clipboard

Toggle word wrap

참고

4단계에 대해 백업 파일을 별도의 폴더에 저장합니다.

새 서비스를 생성하기 위해 v2 애플리케이션 데이터베이스 이름, 사용자 이름 및 암호를 사용하여 PostgreSQL 서비스를 생성합니다.
```
oc new-app postgresql-persistent -p POSTGRESQL_DATABASE=dbname -p
```
```
$ oc new-app postgresql-persistent -p POSTGRESQL_DATABASE=dbname -p
POSTGRESQL_PASSWORD=password -p POSTGRESQL_USER=username
```
Copy to Clipboard Toggle word wrap
Pod를 사용할 준비가 되었는지 확인합니다.
```
oc get pods
```
```
$ oc get pods
```
Copy to Clipboard Toggle word wrap

Pod가 실행 중인 경우 백업 디렉터리를 Pod에 동기화합니다.

oc rsync /local/path/to/dir <postgresql_pod_name>:/var/lib/pgsql/data

$ oc rsync /local/path/to/dir <postgresql_pod_name>:/var/lib/pgsql/data

Copy to Clipboard

Toggle word wrap

Pod에 원격으로 액세스합니다.
```
oc rsh <pod_name>
```
```
$ oc rsh <pod_name>
```
Copy to Clipboard Toggle word wrap

데이터베이스를 복원합니다.

psql dbname < /var/lib/pgsql/data/<database_backup_file>

psql dbname < /var/lib/pgsql/data/<database_backup_file>

Copy to Clipboard

Toggle word wrap

더 이상 필요하지 않은 모든 백업 파일을 제거하십시오.
```
rm /var/lib/pgsql/data/<database-backup-file>
```
```
$ rm /var/lib/pgsql/data/<database-backup-file>
```
Copy to Clipboard Toggle word wrap

지원되는 PostgreSQL 환경 변수

Expand

v2	v3
`OPENSHIFT_POSTGRESQL_DB_HOST`	`[service_name]_SERVICE_HOST`
`OPENSHIFT_POSTGRESQL_DB_PORT`	`[service_name]_SERVICE_PORT`
`OPENSHIFT_POSTGRESQL_DB_USERNAME`	`POSTGRESQL_USER`
`OPENSHIFT_POSTGRESQL_DB_PASSWORD`	`POSTGRESQL_PASSWORD`
`OPENSHIFT_POSTGRESQL_DB_LOG_DIR`
`OPENSHIFT_POSTGRESQL_DB_PID`
`OPENSHIFT_POSTGRESQL_DB_SOCKET_DIR`
`OPENSHIFT_POSTGRESQL_DB_URL`
`OPENSHIFT_POSTGRESQL_VERSION`
`OPENSHIFT_POSTGRESQL_SHARED_BUFFERS`
`OPENSHIFT_POSTGRESQL_MAX_CONNECTIONS`
`OPENSHIFT_POSTGRESQL_MAX_PREPARED_TRANSACTIONS`
`OPENSHIFT_POSTGRESQL_DATESTYLE`
`OPENSHIFT_POSTGRESQL_LOCALE`
`OPENSHIFT_POSTGRESQL_CONFIG`
`OPENSHIFT_POSTGRESQL_SSL_ENABLED`
	`POSTGRESQL_DATABASE`
	`POSTGRESQL_ADMIN_PASSWORD`

6.2.5. MongoDB
링크 복사

참고

OpenShift v3의 경우: MongoDB 쉘 버전 3.2.6
OpenShift v2: MongoDB 쉘 버전 2.4.9의 경우

ssh 명령을 통해 v2 애플리케이션에 원격으로 액세스합니다.
```
rhc ssh <v2_application_name>
```
```
$ rhc ssh <v2_application_name>
```
Copy to Clipboard Toggle word wrap

mongodump 를 실행하여 -d <database_name> -c <collections>로 단일 데이터베이스를 지정합니다. 이러한 옵션이 없으면 모든 데이터베이스를 덤프합니다. 각 데이터베이스는 자체 디렉터리에 덤프됩니다.

mongodump -h $OPENSHIFT_MONGODB_DB_HOST -o app-root/repo/mydbdump -u 'admin' -p $OPENSHIFT_MONGODB_DB_PASSWORD
cd app-root/repo/mydbdump/<database_name>; tar -cvzf dbname.tar.gz
exit

$ mongodump -h $OPENSHIFT_MONGODB_DB_HOST -o app-root/repo/mydbdump -u 'admin' -p $OPENSHIFT_MONGODB_DB_PASSWORD
$ cd app-root/repo/mydbdump/<database_name>; tar -cvzf dbname.tar.gz
$ exit

Copy to Clipboard

Toggle word wrap

mongodump 디렉터리의 로컬 머신에 dbdump 를 다운로드합니다.

mkdir mongodump
rhc scp -a <v2 appname> download mongodump \
  app-root/repo/mydbdump/<dbname>/dbname.tar.gz

$ mkdir mongodump
$ rhc scp -a <v2 appname> download mongodump \
  app-root/repo/mydbdump/<dbname>/dbname.tar.gz

Copy to Clipboard

Toggle word wrap

v3에서 MongoDB 포드를 시작합니다. 최신 이미지(3.2.6)에는 mongo-tools 가 포함되지 않으므로 mongorestore 또는 mongoimport 명령을 사용하려면 기본 mongodb-persistent 템플릿을 편집하여 mongo-tools, "mongodb:2.4" 가 포함된 이미지 태그를 지정해야 합니다. 따라서 다음 oc export 명령 및 편집이 필요합니다.

oc export template mongodb-persistent -n openshift -o json > mongodb-24persistent.json

$ oc export template mongodb-persistent -n openshift -o json > mongodb-24persistent.json

Copy to Clipboard

Toggle word wrap

L80 of mongodb-24persistent.json 을 편집하고 mongodb:latest 를 mongodb:2.4 로 바꿉니다.

oc new-app --template=mongodb-persistent -n <project-name-that-template-was-created-in> \
  MONGODB_USER=user_from_v2_app -p \
  MONGODB_PASSWORD=password_from_v2_db -p \
  MONGODB_DATABASE=v2_dbname -p \
  MONGODB_ADMIN_PASSWORD=password_from_v2_db
oc get pods

$ oc new-app --template=mongodb-persistent -n <project-name-that-template-was-created-in> \
  MONGODB_USER=user_from_v2_app -p \
  MONGODB_PASSWORD=password_from_v2_db -p \
  MONGODB_DATABASE=v2_dbname -p \
  MONGODB_ADMIN_PASSWORD=password_from_v2_db
$ oc get pods

Copy to Clipboard

Toggle word wrap

mongodb pod가 실행 중이면 데이터베이스 아카이브 파일을 v3 MongoDB Pod에 복사합니다.

oc rsync local/path/to/mongodump <mongodb_pod_name>:/var/lib/mongodb/data
oc rsh <mongodb_pod>

$ oc rsync local/path/to/mongodump <mongodb_pod_name>:/var/lib/mongodb/data
$ oc rsh <mongodb_pod>

Copy to Clipboard

Toggle word wrap

MongoDB 포드에서 복원할 각 데이터베이스에 대해 다음을 완료합니다.

cd /var/lib/mongodb/data/mongodump
tar -xzvf dbname.tar.gz
mongorestore -u $MONGODB_USER -p $MONGODB_PASSWORD -d dbname -v /var/lib/mongodb/data/mongodump

$ cd /var/lib/mongodb/data/mongodump
$ tar -xzvf dbname.tar.gz
$ mongorestore -u $MONGODB_USER -p $MONGODB_PASSWORD -d dbname -v /var/lib/mongodb/data/mongodump

Copy to Clipboard

Toggle word wrap

데이터베이스가 복원되었는지 확인합니다.

mongo admin -u $MONGODB_USER -p $MONGODB_ADMIN_PASSWORD
use dbname
show collections
exit

$ mongo admin -u $MONGODB_USER -p $MONGODB_ADMIN_PASSWORD
$ use dbname
$ show collections
$ exit

Copy to Clipboard

Toggle word wrap

Pod에서 mongodump 디렉터리를 제거합니다.
```
rm -rf /var/lib/mongodb/data/mongodump
```
```
$ rm -rf /var/lib/mongodb/data/mongodump
```
Copy to Clipboard Toggle word wrap

지원되는 MongoDB 환경 변수

Expand

v2	v3
`OPENSHIFT_MONGODB_DB_HOST`	`[service_name]_SERVICE_HOST`
`OPENSHIFT_MONGODB_DB_PORT`	`[service_name]_SERVICE_PORT`
`OPENSHIFT_MONGODB_DB_USERNAME`	`MONGODB_USER`
`OPENSHIFT_MONGODB_DB_PASSWORD`	`MONGODB_PASSWORD`
`OPENSHIFT_MONGODB_DB_URL`
`OPENSHIFT_MONGODB_DB_LOG_DIR`
	`MONGODB_DATABASE`
	`MONGODB_ADMIN_PASSWORD`
	`MONGODB_NOPREALLOC`
	`MONGODB_SMALLFILES`
	`MONGODB_QUIET`
	`MONGODB_REPLICA_NAME`
	`MONGODB_KEYFILE_VALUE`

6.3. 웹 프레임워크 애플리케이션 마이그레이션
링크 복사

6.3.1. 개요
링크 복사

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

6.3.2. Python
링크 복사

새 GitHub 리포지토리를 설정하고 현재 로컬 v2 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap
setup.py, wsgi.py, requirements.txt 등과 같은 중요한 파일이 모두 새 리포지토리로 푸시되었는지 확인합니다.
- 애플리케이션에 필요한 모든 패키지가 requirements.txt 에 포함되어 있는지 확인합니다.
oc 명령을 사용하여 빌더 이미지 및 소스 코드에서 새 Python 애플리케이션을 시작합니다.
```
oc new-app --strategy=source
```
```
$ oc new-app --strategy=source
python:3.3~https://github.com/<github-id>/<repo-name> --name=<app-name> -e
<ENV_VAR_NAME>=<env_var_value>
```
Copy to Clipboard Toggle word wrap

지원되는 Python 버전

Expand

v2	v3
Python: 2.6, 2.7, 3.3	지원되는 컨테이너 이미지
Django	Django-psql-example (quickstart)

6.3.3. Ruby
링크 복사

새 GitHub 리포지토리를 설정하고 현재 로컬 v2 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>.git
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap
Gemfile이 없고 간단한 랙 애플리케이션을 실행 중인 경우 이 Gemfile을 소스의 루트에 복사합니다.
```
https://github.com/sclorg/ruby-ex/blob/master/Gemfile
```
```
https://github.com/sclorg/ruby-ex/blob/master/Gemfile
```
Copy to Clipboard Toggle word wrap
참고
Ruby 2.0을 지원하는 랙 gem의 최신 버전은 1.6.4이므로 Gemfile은 gem 'rack', "1.6.4" 로 수정되어야 합니다.
Ruby 2.2 이상의 경우 rack gem 2.0 이상을 사용하십시오.
oc 명령을 사용하여 빌더 이미지 및 소스 코드에서 새 Ruby 애플리케이션을 시작합니다.
```
oc new-app --strategy=source
```
```
$ oc new-app --strategy=source
ruby:2.0~https://github.com/<github-id>/<repo-name>.git
```
Copy to Clipboard Toggle word wrap

지원되는 Ruby 버전

Expand

v2	v3
Ruby: 1.8, 1.9, 2.0	지원되는 컨테이너 이미지
Ruby on Rails: 3, 4	Rails-postgresql-example(quickstart)
Sinatra

6.3.4. PHP
링크 복사

새 GitHub 리포지토리를 설정하고 현재 로컬 v2 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap

oc 명령을 사용하여 빌더 이미지 및 소스 코드에서 새 PHP 애플리케이션을 시작합니다.

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

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

Copy to Clipboard

Toggle word wrap

지원되는 PHP 버전

Expand

v2	v3
PHP: 5.3, 5.4	지원되는 컨테이너 이미지
PHP 5.4 with Zend Server 6.1
CodeIgniter 2
HHVM
Laravel 5.0
	CakePHP-mysql-example (quickstart)

6.3.5. Perl
링크 복사

새 GitHub 리포지토리를 설정하고 현재 로컬 v2 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap

로컬 Git 리포지토리를 편집하고 업스트림에 변경 사항을 푸시하여 v3와 호환되도록 합니다.

v2, CPAN 모듈은 .openshift/cpan.txt 에 있습니다. v3에서 s2i 빌더는 소스의 루트 디렉터리에서 cpanfile 이라는 파일을 찾습니다.

cd <local-git-repository>
mv .openshift/cpan.txt cpanfile

$ cd <local-git-repository>
$ mv .openshift/cpan.txt cpanfile

Copy to Clipboard

Toggle word wrap

cpanfile은 약간 다른 형식이 있습니다.

Expand

cpanfile 형식	cpan.txt 형식
requires ‘cpan::mod’;	cpan::mod
'Dancer'가 필요합니다.	댄서
'YAML'이 필요합니다.	YAML

.openshift 디렉터리 제거
참고
v3에서는 action_hooks 및 cron 작업이 동일한 방식으로 지원되지 않습니다. 자세한 내용은 동작 후크 를 참조하십시오.

oc 명령을 사용하여 빌더 이미지 및 소스 코드에서 새 Perl 애플리케이션을 시작합니다.

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

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

Copy to Clipboard

Toggle word wrap

지원되는 Perl 버전

Expand

v2	v3
Perl: 5.10	지원되는 컨테이너 이미지
	Danr-mysql-example (quickstart)

6.3.6. Node.js
링크 복사

새 GitHub 리포지토리를 설정하고 이를 현재 로컬 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap
로컬 Git 리포지토리를 편집하고 업스트림에 변경 사항을 푸시하여 v3와 호환되도록 합니다.
1. .openshift 디렉터리를 제거합니다.
  참고
  v3에서는 action_hooks 및 cron 작업이 동일한 방식으로 지원되지 않습니다. 자세한 내용은 동작 후크 를 참조하십시오.
2. server.js 를 편집합니다.
  - L116 server.js: 'self.app = express();'
  - L25 server.js: self.ipaddress = '0.0.0.0';
  - L26 server.js: self.port = 8080;
    참고
    line(L)은 기본 V2 카트리지 server.js.js에서 가져온 것입니다.
oc 명령을 사용하여 빌더 이미지 및 소스 코드에서 새 Node.js 애플리케이션을 시작합니다.
```
oc new-app https://github.com/<github-id>/<repo-name>.git
```
```
$ oc new-app https://github.com/<github-id>/<repo-name>.git
--name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>
```
Copy to Clipboard Toggle word wrap

지원되는 Node.js 버전

Expand

v2	v3
Node.js 0.10	지원되는 컨테이너 이미지
	nodejs-mongodb-example. 이 빠른 시작 템플릿은 Node.js 버전 6만 지원합니다.

6.3.7. WordPress
링크 복사

중요

현재 WordPress 애플리케이션 마이그레이션 지원은 Red Hat이 지원하지 않고 커뮤니티에서 제공합니다.

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

6.3.8. 유령
링크 복사

중요

현재 Ghost 애플리케이션 마이그레이션 지원은 Red Hat이 지원하지 않고 커뮤니티에서 제공합니다.

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

6.3.9. JBoss EAP
링크 복사

새 GitHub 리포지토리를 설정하고 이를 현재 로컬 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap
리포지토리에 사전 빌드된 .war 파일이 포함된 경우 리포지토리의 루트 디렉터리의 배포 디렉터리에 있어야 합니다.
JBoss EAP 7 빌더 이미지(jboss-eap70-openshift) 및 GitHub의 소스 코드 리포지터리를 사용하여 새 애플리케이션을 생성합니다.
```
oc new-app --strategy=source jboss-eap70-openshift:1.6~https://github.com/<github-id>/<repo-name>.git
```
```
$ oc new-app --strategy=source jboss-eap70-openshift:1.6~https://github.com/<github-id>/<repo-name>.git
```
Copy to Clipboard Toggle word wrap

6.3.10. JBoss WS(Tomcat)
링크 복사

새 GitHub 리포지토리를 설정하고 이를 현재 로컬 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap
리포지토리에 사전 빌드된 .war 파일이 포함된 경우 리포지토리의 루트 디렉터리의 배포 디렉터리에 있어야 합니다.
JBoss Web Server 3(Tomcat 7) 빌더 이미지(jboss-webserver30-tomcat7) 및 GitHub의 소스 코드 리포지터리를 사용하여 새 애플리케이션을 생성합니다.
```
oc new-app --strategy=source
```
```
$ oc new-app --strategy=source
jboss-webserver30-tomcat7-openshift~https://github.com/<github-id>/<repo-name>.git
--name=<app-name> -e <ENV_VAR_NAME>=<env_var_value>
```
Copy to Clipboard Toggle word wrap

6.3.11. JBoss AS(Wildfly 10)
링크 복사

새 GitHub 리포지토리를 설정하고 이를 현재 로컬 Git 리포지토리에 원격 분기로 추가합니다.
```
git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
```
$ git remote add <remote-name> https://github.com/<github-id>/<repo-name>
```
Copy to Clipboard Toggle word wrap
로컬 v2 소스 코드를 새 리포지토리로 내보냅니다.
```
git push -u <remote-name> master
```
```
$ git push -u <remote-name> master
```
Copy to Clipboard Toggle word wrap
로컬 Git 리포지토리를 편집하고 업스트림 변경 사항을 푸시하여 v3와 호환되도록 합니다.
1. .openshift 디렉터리를 제거합니다.
  참고
  v3에서는 action_hooks 및 cron 작업이 동일한 방식으로 지원되지 않습니다. 자세한 내용은 동작 후크 를 참조하십시오.
2. 배포 디렉터리를 소스 리포지토리의 루트에 추가합니다. .war 파일을 'deployments' 디렉터리로 이동합니다.
oc 명령을 사용하여 빌더 이미지 및 소스 코드에서 새 Wildfly 애플리케이션을 시작합니다.
```
oc new-app https://github.com/<github-id>/<repo-name>.git
```
```
$ oc new-app https://github.com/<github-id>/<repo-name>.git
 --image-stream=”openshift/wildfly:10.0" --name=<app-name> -e
 <ENV_VAR_NAME>=<env_var_value>
```
Copy to Clipboard Toggle word wrap
참고
인수 --name 은 애플리케이션 이름을 지정하는 선택적입니다. -e 인수는 OPENSHIFT_PYTHON_DIR 과 같은 빌드 및 배포 프로세스에 필요한 환경 변수를 추가하기 위한 옵션입니다.

6.3.12. 지원되는 JBoss 버전
링크 복사

Expand

v2	v3
JBoss App Server 7
Tomcat 6 (JBoss EWS 1.0)	지원되는 컨테이너 이미지
Tomcat 7 (JBoss EWS 2.0)	지원되는 컨테이너 이미지
Vert.x 2.1
WildFly App Server 10
WildFly App Server 8.2.1.Final
WildFly App Server 9
CapeDwarf
JBoss Data Virtualization 6	지원되는 컨테이너 이미지
JBoss EAP(Enterprise App Platform) 6	지원되는 컨테이너 이미지
JBoss Unified Push Server 1.0.0.Beta1, Beta2
JBoss BPM 제품군	지원되는 컨테이너 이미지
JBoss BRMS	지원되는 컨테이너 이미지
	jboss-eap70-openshift: 1.3-Beta
	eap64-https-s2i
	eap64-mongodb-persistent-s2i
	eap64-mysql-persistent-s2i
	eap64-psql-persistent-s2i

6.4. 빠른 시작 예
링크 복사

6.4.1. 개요
링크 복사

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

CakePHP MySQL https://github.com/sclorg/cakephp-ex
- template: cakephp-mysql-example
Node.js MongoDB https://github.com/sclorg/nodejs-ex
- 템플릿: nodejs-mongodb-example
Django PosgreSQL https://github.com/sclorg/django-ex
- template: django-psql-example
Dancer MySQL https://github.com/sclorg/dancer-ex
- template: dancer-mysql-example
Rails PostgreSQL https://github.com/sclorg/rails-ex
- 템플릿: rails-postgresql-example

6.4.2. 워크플로우
링크 복사

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

애플리케이션용 GitHub 리포지토리를 생성합니다.

빠른 시작 템플릿을 복제하고 GitHub 리포지토리를 원격으로 추가합니다.

git clone <one-of-the-template-URLs-listed-above>
cd <your local git repository>
git remote add upstream <https://github.com/<git-id>/<quickstart-repo>.git>
git push -u upstream master

$ git clone <one-of-the-template-URLs-listed-above>
$ cd <your local git repository>
$ git remote add upstream <https://github.com/<git-id>/<quickstart-repo>.git>
$ git push -u upstream master

Copy to Clipboard

Toggle word wrap

소스 코드를 GitHub에 커밋하고 내보냅니다.

cd <your local repository>
git commit -am “added code for my app”
git push origin master

$ cd <your local repository>
$ git commit -am “added code for my app”
$ git push origin master

Copy to Clipboard

Toggle word wrap

v3에서 새 애플리케이션을 생성합니다.
```
oc new-app --template=<template> \
-p SOURCE_REPOSITORY_URL=<https://github.com/<git-id>/<quickstart_repo>.git> \
-p DATABASE_USER=<your_db_user> \
-p DATABASE_NAME=<your_db_name> \
-p DATABASE_PASSWORD=<your_db_password> \
-p DATABASE_ADMIN_PASSWORD=<your_db_admin_password>
```
```
$ oc new-app --template=<template> \
-p SOURCE_REPOSITORY_URL=<https://github.com/<git-id>/<quickstart_repo>.git> \
-p DATABASE_USER=<your_db_user> \
-p DATABASE_NAME=<your_db_name> \
-p DATABASE_PASSWORD=<your_db_password> \
-p DATABASE_ADMIN_PASSWORD=<your_db_admin_password> 
```
1
Copy to Clipboard Toggle word wrap
1
MongoDB에만 적용됩니다.
이제 포드 2개, 웹 프레임워크 포드 및 데이터베이스 포드가 실행 중이어야 합니다. 웹 프레임워크 포드 환경은 데이터베이스 포드 환경과 일치해야 합니다. oc set env pod/<pod_name> --list:로 환경 변수를 나열 할 수 있습니다.
- DATABASE_NAME 은 이제 &lt ;DB_SERVICE>_DATABASE
- DATABASE_USER 이제 &lt ;DB_SERVICE>_USER
- DATABASE_PASSWORD 이제 &lt ;DB_SERVICE>_PASSWORD
- DATABASE_ADMIN_PASSWORD 는 이제 MONGODB_ADMIN_PASSWORD (MongoDB에만 적용 가능)
  SOURCE_REPOSITORY_URL 이 지정되지 않은 경우 템플릿은 위의 템플릿 URL(https://github.com/openshift/<quickstart>-ex)을 소스 리포지토리로 사용하고 hello-welcome 애플리케이션이 시작됩니다.
데이터베이스를 마이그레이션하는 경우 데이터베이스를 덤프 파일로 내보내고 새 v3 데이터베이스 Pod의 데이터베이스를 복원합니다. 데이터베이스 포드가 이미 시작되어 실행 중이므로 데이터베이스 애플리케이션 데이터베이스 애플리케이션에 설명된 단계를 참조하여 oc new-app 단계를 건너뜁니다.

6.5. CI/CD(Continuous Integration and Deployment)
링크 복사

6.5.1. 개요
링크 복사

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

6.5.2. Jenkins
링크 복사

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

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

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

6.6. Webhook 및 작업 후크
링크 복사

6.6.1. 개요
링크 복사

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

6.6.2. Webhook
링크 복사

GitHub 리포지토리에서 BuildConfig 를 생성한 후 다음을 실행합니다.

oc describe bc/<name-of-your-BuildConfig>

$ oc describe bc/<name-of-your-BuildConfig>

Copy to Clipboard

Toggle word wrap

그러면 다음과 같은 Webhook GitHub URL이 출력됩니다.

<https://api.starter-us-east-1.openshift.com:443/oapi/v1/namespaces/nsname/buildconfigs/bcname/webhooks/secret/github>.

<https://api.starter-us-east-1.openshift.com:443/oapi/v1/namespaces/nsname/buildconfigs/bcname/webhooks/secret/github>.

Copy to Clipboard

Toggle word wrap

GitHub 웹 콘솔에서 이 URL을 잘라내어 GitHub에 붙여넣습니다.
GitHub 리포지토리의 설정 → Webhook 및 서비스에서 Webhook 추가 를 선택합니다.
URL 출력(위와 유사)을 Payload URL 필드에 붙여넣습니다.
Content Type 을 application/json 으로 설정합니다.
Webhook 추가를 클릭합니다.

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

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

참고

애플리케이션을 삭제하거나 다시 생성하는 경우 GitHub의 Payload URL 필드를 새 BuildConfig Webhook URL로 업데이트해야 합니다.

6.6.3. 작업 후크
링크 복사

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

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

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

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

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

Copy to Clipboard

Toggle word wrap

또는 다음을 수행합니다.

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

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

Copy to Clipboard

Toggle word wrap

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

oc set env dc/<name-of-dc>

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

Copy to Clipboard

Toggle word wrap

6.7. S2I 툴
링크 복사

6.7.1. 개요
링크 복사

S2I(Source-to-Image) 툴은 애플리케이션 소스 코드를 컨테이너 이미지에 삽입하고 최종 제품은 빌더 이미지와 빌드 소스 코드를 통합하는 즉시 실행할 준비가 된 컨테이너 이미지입니다. S2I 툴은 리포지터리에서 OpenShift Container Platform 없이 로컬 머신에 설치할 수 있습니다. https://github.com/openshift/source-to-image#installation

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

6.7.2. 컨테이너 이미지 생성
링크 복사

애플리케이션에 필요한 빌더 이미지를 확인합니다. Red Hat은 Python, Ruby, Perl, PHP 및 Node.js 를 포함한 다양한 언어를 위한 여러 빌더 이미지를 제공합니다. 커뮤니티 공간에서 다른 이미지를 사용할 수 있습니다.
S2I는 로컬 파일 시스템의 소스 코드 또는 Git 리포지토리에서 이미지를 빌드할 수 있습니다. 빌더 이미지 및 소스 코드에서 새 컨테이너 이미지를 빌드하려면 다음을 수행합니다.
```
s2i build <source-location> <builder-image-name> <output-image-name>
```
```
$ s2i build <source-location> <builder-image-name> <output-image-name>
```
Copy to Clipboard Toggle word wrap
참고
<source-location >은 Git 리포지토리 URL 또는 로컬 파일 시스템의 소스 코드일 수 있습니다.

Docker 데몬을 사용하여 빌드 이미지를 테스트합니다.

docker run -d --name <new-name> -p <port-number>:<port-number> <output-image-name>
curl localhost:<port-number>

$ docker run -d --name <new-name> -p <port-number>:<port-number> <output-image-name>
$ curl localhost:<port-number>

Copy to Clipboard

Toggle word wrap

새 이미지를 OpenShift 레지스트리에 내보냅니다.
oc 명령을 사용하여 OpenShift 레지스트리의 이미지에서 새 애플리케이션을 생성합니다.
```
oc new-app <image-name>
```
```
$ oc new-app <image-name>
```
Copy to Clipboard Toggle word wrap

6.8. 기술 지원 가이드
링크 복사

6.8.1. 개요
링크 복사

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

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

6.8.2. 지원되는 데이터베이스
링크 복사

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

6.8.3. 지원되는 언어
링크 복사

PHP
Python
Perl
Node.js
Ruby
JBoss/xPaaS

6.8.4. 지원되는 프레임워크
링크 복사

Expand

표 6.1. 지원되는 프레임워크
v2	v3
Jenkins 서버	jenkins-persistent
드루팔 7
유령 0.7.5
WordPress 4
Ceylon
Go
MEAN

6.8.5. 지원되는 마크커
링크 복사

Expand

표 6.2. Python
v2	v3
pip_install	리포지토리에 *requirements.txt* 가 포함된 경우 기본적으로 pip가 호출됩니다. 그렇지 않으면 pip를 사용하지 않습니다.

Expand

표 6.3. Ruby
v2	v3
disable_asset_compilation	이 작업은 buildconfig 전략 정의에서 `DISABLE_ASSET_COMPILATION` 환경 변수를 true 로 설정하여 수행할 수 있습니다.

Expand

표 6.4. Perl
v2	v3
enable_cpan_tests	이 작업은 빌드 구성에서 `ENABLE_CPAN_TEST` 환경 변수를 true 로 설정하여 수행할 수 있습니다.

Expand

표 6.5. PHP
v2	v3
use_composer	소스 리포지토리에 root 디렉터리에 *composer.json* 이 포함된 경우 composer가 항상 사용됩니다.

Expand

표 6.6. Node.js
v2	v3
NODEJS_VERSION	해당 없음
use_npm	IKEv `_MODE` 가 true 로 설정되어 있지 않으면 npm 을 항상 애플리케이션을 시작하는 데 사용됩니다. 이 경우 nodemon 이 대신 사용됩니다.

Expand

표 6.7. JBoss EAP, JBoss WS, WildFly
v2	v3
enable_debugging	이 옵션은 비어 있지 않은 값으로 설정하여 배포 구성에 설정된 `ENABLE_JPDA` 환경 변수를 통해 제어합니다.
skip_maven_build	*pom.xml* 이 있으면 maven이 실행됩니다.
java7	해당 없음
java8	JavaEE는 JDK8을 사용합니다.

Expand

표 6.8. Jenkins
v2	v3
enable_debugging	해당 없음

Expand

표 6.9. All
v2	v3
force_clean_build	buildconfig 의 noCache 필드로 v3에는 유사한 개념이 있으므로 컨테이너를 빌드하여 각 계층을 다시 실행합니다. S2I 빌드에서 incremental 플래그는 기본적으로 false이며 이는 정리된 빌드 를 나타냅니다.
hot_deploy	Ruby, Python, Perl, PHP, Node.js
enable_public_server_status	해당 없음
disable_auto_scaling	자동 스케일링은 기본적으로 비활성화되어 Pod 자동 스케일링 을 통해 설정할 수 있습니다.

7장. 튜토리얼
링크 복사

7.1. 개요
링크 복사

이 주제 그룹에는 OpenShift Container Platform에서 애플리케이션을 가동 및 실행하는 방법에 대한 정보가 포함되어 있으며 다양한 언어와 프레임워크를 다룹니다.

7.2. 빠른 시작 템플릿
링크 복사

7.2.1. 개요
링크 복사

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

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

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

7.2.2. 웹 프레임워크 빠른 시작 템플릿
링크 복사

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

CakePHP: PHP 웹 프레임워크(MySQL 데이터베이스 포함)
- 템플릿 정의
- 소스 리포지터리
Dancer: Perl 웹 프레임워크(MySQL 데이터베이스 포함)
- 템플릿 정의
- 소스 리포지터리
Django: Python 웹 프레임워크(PostgreSQL 데이터베이스 포함)
- 템플릿 정의
- 소스 리포지터리
NodeJS: NodeJS 웹 애플리케이션(MongoDB 데이터베이스 포함)
- 템플릿 정의
- 소스 리포지터리
Rails: Ruby 웹 프레임워크(PostgreSQL 데이터베이스 포함)
- 템플릿 정의
- 소스 리포지터리

7.3. Ruby on Rails
링크 복사

7.3.1. 개요
링크 복사

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

주의

OpenShift Container Platform에서 애플리케이션을 실행하는 데 필요한 모든 단계에 대한 개요를 보려면 전체 튜토리얼을 통해 안내해 드립니다. 문제가 발생하면 전체 자습서를 읽어보고 다시 돌아가 문제를 해결하십시오. 이전 단계를 검토하여 모든 단계가 제대로 실행되었는지 확인하는 것도 유용할 수 있습니다.

이 가이드에서는 다음이 필요합니다.For this guide, you will need:

기본 Ruby/Rails 지식
로컬로 설치된 Ruby 2.0.0+, Rubygems, Bundler 버전
기본 Git 지식
OpenShift Container Platform v3의 인스턴스 실행

7.3.2. 로컬 워크스테이션 설정
링크 복사

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

7.3.2.1. 데이터베이스 설정
링크 복사

Rails 애플리케이션은 거의 항상 데이터베이스와 함께 사용됩니다. 로컬 개발을 위해 PostgreSQL 데이터베이스를 선택했습니다. 설치 유형:

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

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

Copy to Clipboard

Toggle word wrap

다음으로 데이터베이스를 초기화해야 합니다.

sudo postgresql-setup initdb

$ sudo postgresql-setup initdb

Copy to Clipboard

Toggle word wrap

이 명령은 데이터를 저장할 /var/lib/pgsql/data 디렉토리를 생성합니다.

다음을 입력하여 데이터베이스를 시작합니다.

sudo systemctl start postgresql.service

$ sudo systemctl start postgresql.service

Copy to Clipboard

Toggle word wrap

데이터베이스가 실행 중이면 rails 사용자를 생성합니다.

sudo -u postgres createuser -s rails

$ sudo -u postgres createuser -s rails

Copy to Clipboard

Toggle word wrap

이전에 만든 사용자는 암호가 없습니다.

7.3.3. 애플리케이션 작성
링크 복사

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

gem install rails

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

Copy to Clipboard

Toggle word wrap

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

rails new rails-app --database=postgresql

$ rails new rails-app --database=postgresql

Copy to Clipboard

Toggle word wrap

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

cd rails-app

$ cd rails-app

Copy to Clipboard

Toggle word wrap

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

gem 'pg'

gem 'pg'

Copy to Clipboard

Toggle word wrap

종속 항목이 모두 포함된 새 Gemfile.lock 을 생성하려면 다음을 실행합니다.

bundle install

$ bundle install

Copy to Clipboard

Toggle word wrap

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

rake db:create

$ rake db:create

Copy to Clipboard

Toggle word wrap

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

7.3.3.1. 시작 페이지 만들기
링크 복사

Rails 4는 더 이상 프로덕션에서 정적 public/index.html 페이지를 제공하지 않으므로 새 루트 페이지를 생성해야 합니다.

사용자 정의 시작 페이지를 사용하려면 다음 단계를 수행해야 합니다.

인덱스 작업을 사용하여 컨트롤러 생성
welcome 컨트롤러 index 작업의 뷰 페이지 생성
생성된 컨트롤러 및 뷰를 통해 애플리케이션 루트 페이지를 제공할 경로 생성

Rails는 이 모든 필요한 단계를 수행하는 생성기를 제공합니다.

rails generate controller welcome index

$ rails generate controller welcome index

Copy to Clipboard

Toggle word wrap

필요한 모든 파일이 생성되었으며, 이제 config/routes.rb 파일에서 행 2를 다음과 같이 편집해야 합니다.

root 'welcome#index'

root 'welcome#index'

Copy to Clipboard

Toggle word wrap

rails 서버를 실행하여 페이지를 사용할 수 있는지 확인합니다.

rails server

$ rails server

Copy to Clipboard

Toggle word wrap

브라우저에서 http://localhost:3000으로 가서 페이지를 확인해야 합니다. 페이지가 표시되지 않으면 서버로 출력되는 로그를 확인하여 디버그합니다.

7.3.3.2. OpenShift Container Platform용 애플리케이션 구성
링크 복사

OpenShift Container Platform에서 실행할 PostgreSQL 데이터베이스 서비스와 통신하는 애플리케이션을 사용하려면 데이터베이스 서비스 생성 시 나중에 정의할 환경 변수 을 사용하도록 config/database.yml 의 default 섹션을 편집해야 합니다.

사전 정의된 변수와 함께 편집한 config/database.yml 의 default 섹션은 다음과 같아야 합니다.

<% 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"] %>

<% 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"] %>

Copy to Clipboard

Toggle word wrap

최종 파일을 찾는 방법의 예는 Ruby on Rails 예제 application config/database.yml 을 참조하십시오.

7.3.3.3. Git에 애플리케이션 저장
링크 복사

OpenShift Container Platform에는 git 이 필요합니다. 설치되어 있지 않은 경우 설치해야 합니다.

OpenShift Container Platform에서 애플리케이션을 빌드하려면 일반적으로 소스 코드를 git 리포지토리에 저장해야 하므로 git 이 아직 없는 경우 설치해야 합니다.

ls -1 명령을 실행하여 Rails 애플리케이션 디렉토리에 있는지 확인합니다. 명령 출력은 다음과 같아야 합니다.

ls -1

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

Copy to Clipboard

Toggle word wrap

이제 Rails 앱 디렉토리에서 다음 명령을 실행하여 코드를 초기화하고 git으로 커밋합니다.

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

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

Copy to Clipboard

Toggle word wrap

애플리케이션이 커밋되면 원격 리포지토리로 내보내야 합니다. 이를 위해 새 리포지토리를 생성하는 GitHub 계정이 필요합니다.

git 리포지터리를 가리키는 remote를 설정합니다.

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

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

Copy to Clipboard

Toggle word wrap

그런 다음 애플리케이션을 원격 Git 리포지토리로 푸시합니다.

git push

$ git push

Copy to Clipboard

Toggle word wrap

7.3.4. OpenShift Container Platform에 애플리케이션 배포
링크 복사

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

OpenShift Container Platform의 PostgreSQL 이미지에서데이터베이스 서비스 생성
데이터베이스 서비스와 연결하여 OpenShift Container Platform의 Ruby 2.0 빌더 이미지와 Ruby on Rails 소스 코드에서 프런트 엔드 서비스 생성
애플리케이션 경로를 생성합니다.

7.3.4.1. 데이터베이스 서비스 생성
링크 복사

Rails 애플리케이션에 실행 중인 데이터베이스 서비스가 필요합니다. 이 서비스에는 PostgeSQL 데이터베이스 이미지 를 사용합니다.

데이터베이스 서비스를 생성하려면 oc new-app 명령을 사용합니다. 데이터베이스 컨테이너 내에서 사용할 몇 가지 필요한 환경 변수를 이 명령으로 전달해야 합니다. 이러한 환경 변수는 사용자 이름, 암호 및 데이터베이스 이름을 설정하는 데 필요합니다. 이러한 환경 변수 의 값을 원하는 대로 변경할 수 있습니다. 설정할 변수는 다음과 같습니다.

POSTGRESQL_DATABASE
POSTGRESQL_USER
POSTGRESQL_PASSWORD

이러한 변수를 설정하면 다음과 같은 결과를 얻을 수 있습니다.

지정된 이름의 데이터베이스가 있습니다.
지정된 이름의 사용자가 있습니다.
사용자가 지정된 암호를 사용하여 지정된 데이터베이스에 액세스할 수 있습니다.

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

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

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

Copy to Clipboard

Toggle word wrap

데이터베이스 관리자의 암호도 설정하려면 다음 행을 이전 명령에 추가합니다.

-e POSTGRESQL_ADMIN_PASSWORD=admin_pw

-e POSTGRESQL_ADMIN_PASSWORD=admin_pw

Copy to Clipboard

Toggle word wrap

이 명령의 진행 상황을 보려면 다음을 수행합니다.

oc get pods --watch

$ oc get pods --watch

Copy to Clipboard

Toggle word wrap

7.3.4.2. 프론트 엔드 서비스 생성
링크 복사

애플리케이션을 OpenShift Container Platform으로 가져오려면 oc new-app 명령을 다시 사용하여 애플리케이션이 있는 리포지토리를 지정해야 합니다. 이 경우 데이터베이스 서비스 생성 에서 설정한 데이터베이스 관련 환경 변수를 지정해야 합니다.

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 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

Copy to Clipboard

Toggle word wrap

이 명령을 사용하면 OpenShift Container Platform에서 소스 코드를 가져와서 빌더 이미지를 설정하고, 애플리케이션 이미지를 빌드 하며, 새로 생성된 이미지를 지정된 환경 변수 와 함께 배포합니다. 애플리케이션 이름은 rails-app으로 지정됩니다.

rails-app DeploymentConfig 의 JSON 문서를 보고 환경 변수가 추가되었는지 확인할 수 있습니다.

oc get dc rails-app -o json

$ oc get dc rails-app -o json

Copy to Clipboard

Toggle word wrap

다음 섹션이 표시되어야 합니다.

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

],

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

],

Copy to Clipboard

Toggle word wrap

빌드 프로세스를 확인하려면 다음을 수행합니다.

oc logs -f build rails-app-1

$ oc logs -f build rails-app-1

Copy to Clipboard

Toggle word wrap

빌드가 완료되면 OpenShift Container Platform에서 실행 중인 포드를 확인할 수 있습니다.

oc get pods

$ oc get pods

Copy to Clipboard

Toggle word wrap

myapp-<number>-<hash>로 시작되는 행이 표시되어야 합니다. OpenShift Container Platform에서 실행 중인 애플리케이션을 나타냅니다.

애플리케이션이 작동하려면 데이터베이스 마이그레이션 스크립트를 실행하여 데이터베이스를 초기화해야 합니다. 이 작업을 수행하는 방법은 다음 두 가지입니다.

실행 중인 프런트 엔드 컨테이너에서 수동으로 수행합니다.

먼저 rsh 명령을 사용하여 프런트 엔드 컨테이너를 실행해야합니다.

oc rsh <FRONTEND_POD_ID>

$ oc rsh <FRONTEND_POD_ID>

Copy to Clipboard

Toggle word wrap

컨테이너 내부에서 마이그레이션을 실행합니다.

RAILS_ENV=production bundle exec rake db:migrate

$ RAILS_ENV=production bundle exec rake db:migrate

Copy to Clipboard

Toggle word wrap

Rails 애플리케이션을 개발 또는 테스트 환경에서 실행 중인 경우 RAILS_ENV 환경 변수를 지정할 필요가 없습니다.

템플릿에 사전 배포 라이프사이클 후크를 추가하여 수행합니다. 예를 들어 Rails 예제 애플리케이션에서 후크 예제 를 확인합니다.

7.3.4.3. 애플리케이션 경로 생성
링크 복사

www.example.com 과 같이 외부에서 접근할 수 있는 호스트 이름을 지정하여 서비스를 공개하려면 OpenShift Container Platform 경로를 사용합니다. 이 경우 다음을 입력하여 프런트 엔드 서비스를 공개해야 합니다.

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

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

Copy to Clipboard

Toggle word wrap

주의

사용자가 지정한 호스트 이름이 라우터의 IP 주소로 확인되는지 확인하는 것은 사용자의 책임입니다. 자세한 내용은 다음에서 OpenShift Container Platform 설명서를 참조하십시오.

7.4. Maven에 대한 Nexus Mirror 설정
링크 복사

7.4.1. 소개
링크 복사

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

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

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

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

7.4.2. Nexus 설정
링크 복사

공식 Nexus 컨테이너 이미지를 다운로드하여 배포합니다.
```
oc new-app sonatype/nexus
```
```
oc new-app sonatype/nexus
```
Copy to Clipboard Toggle word wrap
새로 생성된 Nexus 서비스를 노출하여 경로를 생성합니다.
```
oc expose svc/nexus
```
```
oc expose svc/nexus
```
Copy to Clipboard Toggle word wrap

oc get routes 를 사용하여 포드의 새 외부 주소를 찾습니다.

oc get routes

oc get routes

Copy to Clipboard

Toggle word wrap

출력은 다음과 유사해야 합니다.

NAME      HOST/PORT                              PATH      SERVICES   PORT       TERMINATION
nexus     nexus-myproject.192.168.1.173.xip.io             nexus      8081-tcp

NAME      HOST/PORT                              PATH      SERVICES   PORT       TERMINATION
nexus     nexus-myproject.192.168.1.173.xip.io             nexus      8081-tcp

Copy to Clipboard

Toggle word wrap

브라우저를 HOST/PORT 아래의 URL로 이동하여 Nexus가 실행 중인지 확인합니다. Nexus에 로그인하려면 기본 관리자 사용자 이름은 admin 이며 암호는 admin123 입니다.

참고

Nexus는 중앙 리포지토리에 대해 사전 구성되어 있지만 애플리케이션에 다른 사용자가 필요할 수 있습니다. 많은 Red Hat 이미지의 경우 Maven 리포지토리에 jboss-ga 리포지토리를 추가하는 것이 좋습니다.

7.4.2.1. 프로브를 사용하여 성공 확인
링크 복사

준비 상태 및 활동성 프로브 를 설정할 수 있는 적절한 시간입니다. 이를 통해 주기적으로 Nexus가 올바르게 실행되고 있는지 확인합니다.

oc set probe dc/nexus \
	--liveness \
	--failure-threshold 3 \
	--initial-delay-seconds 30 \
	-- echo ok
oc set probe dc/nexus \
	--readiness \
	--failure-threshold 3 \
	--initial-delay-seconds 30 \
	--get-url=http://:8081/nexus/content/groups/public

$ oc set probe dc/nexus \
	--liveness \
	--failure-threshold 3 \
	--initial-delay-seconds 30 \
	-- echo ok
$ oc set probe dc/nexus \
	--readiness \
	--failure-threshold 3 \
	--initial-delay-seconds 30 \
	--get-url=http://:8081/nexus/content/groups/public

Copy to Clipboard

Toggle word wrap

7.4.2.2. Nexus에 지속성 추가
링크 복사

참고

영구 스토리지를 원하지 않는 경우 Nexus에 계속 연결합니다. 그러나 어떤 이유로든 Pod를 다시 시작하면 캐시된 종속 항목과 구성 사용자 지정이 손실됩니다.

서버를 실행하는 Pod가 종료될 때 캐시된 종속성이 손실되지 않도록 Nexus에 대한 PVC(영구 볼륨 클레임)를 생성합니다. PVC에는 클러스터에서 사용 가능한 PV(영구 볼륨)가 필요합니다. 사용 가능한 PV가 없고 클러스터에 관리자 액세스 권한이 없는 경우 시스템 관리자에게 읽기/쓰기 영구 볼륨을 생성하도록 요청합니다.

그렇지 않으면 영구 볼륨 생성 방법에 대한 지침은 OpenShift Container Platform의 영구 스토리지 를 참조하십시오.

Nexus 배포 구성에 PVC를 추가합니다.

oc volumes dc/nexus --add \
	--name 'nexus-volume-1' \
	--type 'pvc' \
	--mount-path '/sonatype-work/' \
	--claim-name 'nexus-pv' \
	--claim-size '1G' \
	--overwrite

$ oc volumes dc/nexus --add \
	--name 'nexus-volume-1' \
	--type 'pvc' \
	--mount-path '/sonatype-work/' \
	--claim-name 'nexus-pv' \
	--claim-size '1G' \
	--overwrite

Copy to Clipboard

Toggle word wrap

이렇게 하면 배포 구성에 대한 이전 emptyDir 볼륨이 제거되고 /sonatype-work 에 마운트된 1GB의 영구 스토리지에 대한 클레임이 추가됩니다. 구성 변경으로 인해 Nexus Pod가 자동으로 재배포됩니다.

Nexus가 실행 중인지 확인하려면 브라우저에서 Nexus 페이지를 새로 고칩니다. 다음을 사용하여 배포 진행 상황을 모니터링할 수 있습니다.

oc get pods -w

$ oc get pods -w

Copy to Clipboard

Toggle word wrap

7.4.3. Nexus에 연결
링크 복사

다음 단계에서는 새 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

$ 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

Copy to Clipboard

Toggle word wrap

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

7.4.4. 성공 확인
링크 복사

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

7.4.5. 추가 리소스
링크 복사

7.5. OpenShift Pipeline 빌드
링크 복사

7.5.1. 소개
링크 복사

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

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

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

7.5.2. Jenkins 마스터 생성
링크 복사

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

oc project <project_name>

  $ oc project <project_name>

1


  $ oc new-app jenkins-ephemeral

2

Copy to Clipboard

Toggle word wrap

1: 사용할 프로젝트를 선택하거나 oc new-project <project_name>을 사용하여 새 프로젝트를 생성합니다.
2: 영구 스토리지를 사용하려면 대신 jenkins-persistent를 사용합니다.

참고

Jenkins 자동 프로비저닝이 클러스터에서 활성화되고 Jenkins 마스터에 사용자 정의를 수행할 필요가 없는 경우 이전 단계를 건너뛸 수 있습니다.

Jenkins 자동 프로비저닝에 대한 자세한 내용은 파이프라인 실행 구성을 참조하십시오.

7.5.3. Pipeline 빌드 구성
링크 복사

이제 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

kind: "BuildConfig"
apiVersion: "v1"
metadata:
  name: "nodejs-sample-pipeline"
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: <pipeline content from below>
    type: JenkinsPipeline

Copy to Clipboard

Toggle word wrap

Pipeline 빌드 전략 구성에 대한 자세한 내용은 Pipeline Strategy Options 을 참조하십시오.

7.5.4. Jenkinsfile
링크 복사

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' 
def templateName = 'nodejs-mongodb-example' 
pipeline {
  agent {
    node {
      label 'nodejs' 
    }
  }
  options {
    timeout(time: 20, unit: 'MINUTES') 
  }
  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() 
                  if (openshift.selector("secrets", templateName).exists()) { 
                    openshift.selector("secrets", templateName).delete()
                  }
                }
            }
        }
      }
    }
    stage('create') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  openshift.newApp(templatePath) 
                }
            }
        }
      }
    }
    stage('build') {
      steps {
        script {
            openshift.withCluster() {
                openshift.withProject() {
                  def builds = openshift.selector("bc", templateName).related('builds')
                  timeout(5) { 
                    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) { 
                    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") 
                }
            }
        }
      }
    }
  }
}

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

Copy to Clipboard

Toggle word wrap

1: 사용할 템플릿의 경로입니다.
2: 생성할 템플릿의 이름입니다.
3: 이 빌드를 실행할 node.js 슬레이브 Pod를 실행합니다.
4: 이 파이프라인에 타임아웃을 20분으로 설정합니다.
5: 이 템플릿 라벨이 있는 모든 항목을 삭제합니다.
6: 이 템플릿 라벨을 사용하여 모든 보안을 삭제합니다.
7: templatePath에서 새 애플리케이션을 생성합니다.
8: 빌드가 완료될 때까지 최대 5분 동안 기다립니다.
9: 배포가 완료될 때까지 최대 5분 정도 기다립니다.
10: 다른 모든 과정이 성공하면 $ {templateName}:latest 이미지에 $ {templateName}-staging:latest 태그를 지정합니다. 스테이징 환경의 파이프라인 BuildConfig는 $ {templateName}-staging:latest 이미지가 변경되고 스테이징 환경에 배포할 수 있습니다.

참고

위 예제는 선언적 파이프라인 스타일을 사용하여 작성되었지만 오래된 스크립팅된 파이프라인 스타일도 지원됩니다.

7.5.5. Pipeline 생성
링크 복사

다음을 실행하여 OpenShift 클러스터에서 BuildConfig를 생성할 수 있습니다.

oc create -f nodejs-sample-pipeline.yaml

$ oc create -f nodejs-sample-pipeline.yaml

Copy to Clipboard

Toggle word wrap

자체 파일을 생성하지 않으려면 다음을 실행하여 원래 리포지토리의 샘플을 사용하면 됩니다.

oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml

$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml

Copy to Clipboard

Toggle word wrap

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

7.5.6. Pipeline 시작
링크 복사

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

oc start-build nodejs-sample-pipeline

$ oc start-build nodejs-sample-pipeline

Copy to Clipboard

Toggle word wrap

참고

또는 빌드 → 파이프라인 섹션으로 이동하여 파이프라인 시작을 클릭하거나 Jenkins 콘솔을 방문하여 생성한 파이프라인으로 이동한 다음 지금 빌드 를 클릭하여 OpenShift 웹 콘솔을 사용하여 파이프라인을 시작할 수 있습니다.

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

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 웹 콘솔에서 확인하는 것입니다. 웹 콘솔에 로그인하고 빌드 → 파이프라인으로 이동하여 파이프라인을 볼 수 있습니다.

7.5.7. OpenShift Pipelines의 고급 옵션
링크 복사

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

Jenkins 자동=프로비저닝을 비활성화하려면 파이프라인 실행 구성을 참조하십시오.
Jenkins 서비스 계정이 OpenShift Pipelines를 실행할 각 프로젝트에 액세스할 수 있도록 하려면 cross Project Access를 참조하십시오.
모니터링할 프로젝트를 추가하려면 다음 중 하나를 수행합니다.
- Jenkins 콘솔에 로그인합니다.
  - Manage Jenkins (Jenkins 관리)으로 이동한 다음 Configure System.
  - OpenShift Jenkins 동기화 에서 네임스페이스 필드를 업데이트합니다.
- 또는 S2I 확장 옵션을 사용하여 OpenShift Jenkins 이미지를 확장하여 Jenkins 구성 파일을 업데이트합니다.

참고

OpenShift 동기화 플러그인을 실행하는 여러 Jenkins 배포에서 동일한 프로젝트를 모니터링하지 마십시오. 이러한 인스턴스와 예기치 않은 결과가 발생할 수 있는 조정은 없습니다.

7.6. 바이너리 빌드
링크 복사

7.6.1. 소개
링크 복사

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

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

파일에서 (--from-file): 빌드의 전체 소스가 단일 파일로 구성된 경우입니다. 예를 들어, Docker 빌드의 Dockerfile, Wildfly 빌드의 경우 pom.xml 또는 Ruby 빌드의 Gemfile 일 수 있습니다.
디렉터리(--from-directory): 소스가 로컬 디렉터리에 있고 Git 리포지토리에 커밋되지 않은 경우 이 값을 사용합니다. start-build 명령은 지정된 디렉터리의 아카이브를 생성하고 소스로 빌더에 업로드합니다.
아카이브에서 (--from-archive): 소스를 사용하는 아카이브가 이미 있는 경우 이 명령을 사용합니다. 아카이브는 tar , tar.gz 또는 zip 형식이어야 합니다.
Git 리포지토리(--from-repo): 현재 사용자의 로컬 머신에 있는 Git 리포지토리의 일부인 소스용입니다. 현재 리포지토리의 HEAD 커밋이 보관되어 빌드를 위해 OpenShift로 전송됩니다.

7.6.1.1. 사용 사례
링크 복사

바이너리 빌드에서는 기존 Git 리포지토리에서 소스를 가져오기 위한 빌드 요구 사항을 제거합니다. 바이너리 빌드를 사용하는 이유는 다음과 같습니다.

로컬 코드 변경 사항 빌드 및 테스트 공용 리포지토리의 소스를 복제할 수 있으며, 빌드를 위해 로컬 변경 사항을 OpenShift에 업로드할 수 있습니다. 로컬 변경 사항을 커밋하거나 아무데도 푸시할 필요가 없습니다.
개인 코드 빌드. 새 빌드는 바이너리 빌드로 처음부터 시작할 수 있습니다. 그런 다음 SCM에 검사하지 않고도 로컬 워크스테이션에서 OpenShift로 소스를 직접 업로드할 수 있습니다.
다른 소스에서 아티팩트를 사용하여 이미지 빌드. Jenkins 파이프라인을 사용하면 바이너리 빌드가 Maven 또는 C 컴파일러와 같은 툴로 빌드된 아티팩트와 해당 빌드를 사용하는 런타임 이미지를 결합하는 데 유용합니다.

7.6.1.2. 제한 사항
링크 복사

바이너리 빌드는 반복할 수 없습니다. 바이너리 빌드는 빌드 시작 시 사용자가 아티팩트를 업로드하는 데 의존하기 때문에 사용자가 매번 동일한 업로드를 반복하지 않고 동일한 빌드를 반복할 수 없습니다.
바이너리 빌드를 자동으로 트리거할 수 없습니다. 사용자가 필요한 바이너리 아티팩트를 업로드할 때만 수동으로 시작할 수 있습니다.

참고

바이너리 빌드로 시작되는 빌드에도 소스 URL이 구성될 수 있습니다. 이 경우 트리거가 빌드를 성공적으로 시작했지만 구성된 소스 URL에서 가져오고 빌드가 마지막으로 실행될 때 사용자가 제공한 소스에서 제공되지 않습니다.

7.6.2. 튜토리얼 개요
링크 복사

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

7.6.2.1. 튜토리얼: 로컬 코드 변경 빌드
링크 복사

기존 소스 리포지터리를 기반으로 새 애플리케이션을 생성하고 경로를 생성합니다.

oc new-app https://github.com/openshift/ruby-hello-world.git
oc expose svc/ruby-hello-world

$ oc new-app https://github.com/openshift/ruby-hello-world.git
$ oc expose svc/ruby-hello-world

Copy to Clipboard

Toggle word wrap

초기 빌드가 완료될 때까지 기다린 후 경로 호스트로 이동하여 애플리케이션의 페이지를 확인합니다. 시작 페이지가 표시됩니다.
```
oc get route ruby-hello-world
```
```
$ oc get route ruby-hello-world
```
Copy to Clipboard Toggle word wrap

리포지토리를 로컬로 복제합니다.

git clone https://github.com/openshift/ruby-hello-world.git
cd ruby-hello-world

$ git clone https://github.com/openshift/ruby-hello-world.git
$ cd ruby-hello-world

Copy to Clipboard

Toggle word wrap

애플리케이션 보기를 변경합니다. 즐겨 찾는 편집기를 사용하여 views/main.rb: < body > 태그를 < body style="background-color:blue" >로 변경하십시오.
로컬에서 수정된 소스를 사용하여 새 빌드를 시작합니다. 리포지토리의 로컬 디렉터리에서 다음을 실행합니다.
```
----
$ oc start-build ruby-hello-world --from-dir="." --follow
----
```
```
----
$ oc start-build ruby-hello-world --from-dir="." --follow
----
```
Copy to Clipboard Toggle word wrap

빌드가 완료되고 애플리케이션이 재배포되면 애플리케이션의 경로 호스트로 이동하여 파란색 배경이 있는 페이지가 생성됩니다.

로컬로 변경하고 oc start-build --from-dir 을 사용하여 코드를 빌드할 수 있습니다.

코드 분기를 생성하고, 변경 사항을 로컬에서 커밋하고, 리포지토리의 HEAD를 빌드 소스로 사용할 수도 있습니다.

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

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

Copy to Clipboard

Toggle word wrap

7.6.2.2. 튜토리얼: 개인 코드 빌드
링크 복사

코드를 저장할 로컬 디렉터리를 만듭니다.
```
mkdir myapp
cd myapp
```
```
$ mkdir myapp
$ cd myapp
```
Copy to Clipboard Toggle word wrap

디렉터리에서 다음 콘텐츠를 사용하여 Dockerfile 이라는 파일을 생성합니다.

FROM centos:centos7

EXPOSE 8080

COPY index.html /var/run/web/index.html

CMD cd /var/run/web && python -m SimpleHTTPServer 8080

FROM centos:centos7

EXPOSE 8080

COPY index.html /var/run/web/index.html

CMD cd /var/run/web && python -m SimpleHTTPServer 8080

Copy to Clipboard

Toggle word wrap

다음 콘텐츠를 사용하여 index.html 이라는 파일을 생성합니다.

<html>
  <head>
    <title>My local app</title>
  </head>
  <body>
    <h1>Hello World</h1>
    <p>This is my local application</p>
  </body>
</html>

<html>
  <head>
    <title>My local app</title>
  </head>
  <body>
    <h1>Hello World</h1>
    <p>This is my local application</p>
  </body>
</html>

Copy to Clipboard

Toggle word wrap

애플리케이션에 대한 새 빌드를 생성합니다.

oc new-build --strategy docker --binary --docker-image centos:centos7 --name myapp

$ oc new-build --strategy docker --binary --docker-image centos:centos7 --name myapp

Copy to Clipboard

Toggle word wrap

로컬 디렉터리의 콘텐츠를 사용하여 바이너리 빌드를 시작합니다.
```
oc start-build myapp --from-dir . --follow
```
```
$ oc start-build myapp --from-dir . --follow
```
Copy to Clipboard Toggle word wrap
new-app 을 사용하여 애플리케이션을 배포한 다음 해당 경로를 생성합니다.
```
oc new-app myapp
oc expose svc/myapp
```
```
$ oc new-app myapp
$ oc expose svc/myapp
```
Copy to Clipboard Toggle word wrap
경로의 호스트 이름을 가져와서 다음으로 이동합니다.
```
oc get route myapp
```
```
$ oc get route myapp
```
Copy to Clipboard Toggle word wrap

코드를 빌드하고 배포한 후에는 로컬 파일을 변경하고 oc start-build myapp --from-dir 을 호출하여 새 빌드를 시작하여 반복할 수 있습니다. 빌드되면 코드가 자동으로 배포되고 페이지를 새로 고칠 때 변경 사항이 브라우저에 반영됩니다.

7.6.2.3. 튜토리얼: 파이프라인에서 바이너리 아티팩트
링크 복사

OpenShift의 Jenkins를 사용하면 적절한 툴과 함께 슬레이브 이미지를 사용하여 코드를 빌드할 수 있습니다. 예를 들어, maven 슬레이브를 사용하여 코드 리포지토리에서 WAR를 빌드할 수 있습니다. 그러나 이 아티팩트가 빌드되면 코드를 실행하기 위해 올바른 런타임 아티팩트가 포함된 이미지에 커밋해야 합니다. 바이너리 빌드는 이러한 아티팩트를 런타임 이미지에 추가하는 데 사용할 수 있습니다. 다음 튜토리얼에서는 maven 슬레이브를 사용하여 WAR를 빌드한 다음 Dockerfile 과 함께 바이너리 빌드를 사용하여 해당 WAR를 와일드카드 런타임 이미지에 추가하는 Jenkins 파이프라인을 만듭니다.

애플리케이션의 새 디렉터리를 생성합니다.
```
mkdir mavenapp
cd mavenapp
```
```
$ mkdir mavenapp
$ cd mavenapp
```
Copy to Clipboard Toggle word wrap
실행할 와일드카드 이미지 내의 적절한 위치에 WAR를 복사하는 Dockerfile 을 생성합니다. Dockerfile 이라는 로컬 파일에 다음을 복사합니다.
```
FROM wildfly:latest
COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
CMD  $STI_SCRIPTS_PATH/run
```
```
FROM wildfly:latest
COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
CMD  $STI_SCRIPTS_PATH/run
```
Copy to Clipboard Toggle word wrap
해당 Dockerfile의 새 BuildConfig를 생성합니다.
참고
이렇게 하면 ROOT.war 아티팩트를 아직 사용할 수 없으므로 처음에 실패하는 빌드가 자동으로 시작됩니다. 아래 파이프라인은 바이너리 빌드를 사용하여 해당 WAR를 빌드에 전달합니다.
```
cat Dockerfile | oc new-build -D - --name mavenapp
```
```
$ cat Dockerfile | oc new-build -D - --name mavenapp
```
Copy to Clipboard Toggle word wrap

WAR를 빌드할 Jenkins 파이프라인으로 BuildConfig를 생성한 다음 해당 WAR를 사용하여 이전에 생성한 Dockerfile 을 사용하여 이미지를 빌드합니다. 바이너리 아티팩트가 도구 집합에 의해 빌드된 다른 플랫폼에 동일한 패턴을 사용할 수 있으며 최종 패키지의 다른 런타임 이미지와 결합됩니다. mavenapp-pipeline.yml 에 다음 코드를 저장합니다.

apiVersion: v1
kind: BuildConfig
metadata:
  name: mavenapp-pipeline
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        pipeline {
          agent { label "maven" }
          stages {
            stage("Clone Source") {
              steps {
                checkout([$class: 'GitSCM',
                            branches: [[name: '*/master']],
                            extensions: [
                              [$class: 'RelativeTargetDirectory', relativeTargetDir: 'mavenapp']
                            ],
                            userRemoteConfigs: [[url: 'https://github.com/openshift/openshift-jee-sample.git']]
                        ])
              }
            }
            stage("Build WAR") {
              steps {
                dir('mavenapp') {
                  sh 'mvn clean package -Popenshift'
                }
              }
            }
            stage("Build Image") {
              steps {
                dir('mavenapp/target') {
                  sh 'oc start-build mavenapp --from-dir . --follow'
                }
              }
            }
          }
        }
    type: JenkinsPipeline
  triggers: []

apiVersion: v1
kind: BuildConfig
metadata:
  name: mavenapp-pipeline
spec:
  strategy:
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        pipeline {
          agent { label "maven" }
          stages {
            stage("Clone Source") {
              steps {
                checkout([$class: 'GitSCM',
                            branches: [[name: '*/master']],
                            extensions: [
                              [$class: 'RelativeTargetDirectory', relativeTargetDir: 'mavenapp']
                            ],
                            userRemoteConfigs: [[url: 'https://github.com/openshift/openshift-jee-sample.git']]
                        ])
              }
            }
            stage("Build WAR") {
              steps {
                dir('mavenapp') {
                  sh 'mvn clean package -Popenshift'
                }
              }
            }
            stage("Build Image") {
              steps {
                dir('mavenapp/target') {
                  sh 'oc start-build mavenapp --from-dir . --follow'
                }
              }
            }
          }
        }
    type: JenkinsPipeline
  triggers: []

Copy to Clipboard

Toggle word wrap

파이프라인 빌드를 생성합니다. Jenkins가 프로젝트에 배포되지 않으면 파이프라인을 사용하여 BuildConfig를 생성하면 Jenkins가 배포됩니다. Jenkins가 파이프라인을 빌드할 준비가 되기까지 몇 분이 걸릴 수 있습니다. oc rollout status dc/jenkins 를 호출하여 Jenkins 롤아웃의 상태를 확인할 수 있습니다.
```
oc create -f ./mavenapp-pipeline.yml
```
```
$ oc create -f ./mavenapp-pipeline.yml
```
Copy to Clipboard Toggle word wrap
Jenkins가 준비되면 이전에 정의된 파이프라인을 시작합니다.
```
oc start-build mavenapp-pipeline
```
```
$ oc start-build mavenapp-pipeline
```
Copy to Clipboard Toggle word wrap
파이프라인 빌드가 완료되면 new-app을 사용하여 새 애플리케이션을 배포하고 경로를 노출합니다.
```
oc new-app mavenapp
oc expose svc/mavenapp
```
```
$ oc new-app mavenapp
$ oc expose svc/mavenapp
```
Copy to Clipboard Toggle word wrap
브라우저를 사용하여 애플리케이션의 경로로 이동합니다.
```
oc get route mavenapp
```
```
$ oc get route mavenapp
```
Copy to Clipboard Toggle word wrap

8장. 빌드
링크 복사

8.1. 빌드 작업 방법
링크 복사

8.1.1. 빌드란 무엇인가?
링크 복사

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

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

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

S2I(Source-to-Image)(설명,옵션)
파이프 라인 (설명,옵션)
Docker(설명,옵션)
사용자 정의 (설명,옵션)

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

git
Dockerfile
바이너리
Image
입력 보안
외부 아티팩트

특정 유형의 소스를 고려하거나 무시하고 사용할 방법을 결정하는 것은 각 빌드 전략입니다. 바이너리와 Git은 상호 배타적인 소스 유형입니다. Dockerfile 및 이미지는 자체적으로 사용하거나 Git 또는 Binary와 함께 사용할 수 있습니다. Binary 소스 유형은 시스템에 지정된 방법에 있는 다른 옵션과 고유합니다.

8.1.2. BuildConfig란 무엇입니까?
링크 복사

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

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

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

BuildConfig 오브젝트 정의

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

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"

Copy to Clipboard

Toggle word wrap

1: 이 사양은 ruby-sample-build 라는 새 BuildConfig 를 생성합니다.
2: runPolicy 필드는 이 빌드 구성에서 생성한 빌드를 동시에 실행할 수 있는지 여부를 제어합니다. 기본값은 Serial 입니다. 즉, 새 빌드가 동시에 실행되지 않고 순차적으로 실행됩니다.
3: 트리거 목록을 지정할 수 있으며 이로 인해 새 빌드가 생성됩니다.
4: source 섹션은 빌드의 소스를 정의합니다. 소스 유형에 따라 기본 입력 소스가 결정되는데, 소스 유형은 코드 리포지토리 위치를 가리키는 Git, 인라인 Dockerfile에서 빌드하는 Dockerfile 또는 바이너리 페이로드를 허용하는 Binary일 수 있습니다. 한 번에 여러 소스를 사용할 수 있습니다. 자세한 내용은 각 소스 유형에 대한 설명서를 참조하십시오.
5: strategy 섹션에서는 빌드를 실행하는 데 사용하는 빌드 전략에 대해 설명합니다. 여기에서 Source , Docker 또는 Custom 전략을 지정할 수 있습니다. 위의 예에서는 Source-To-Image에서 애플리케이션 빌드에 사용할 ruby-20-centos7 컨테이너 이미지를 사용합니다.
6: 컨테이너 이미지가 성공적으로 빌드되면 output 섹션에 설명된 리포지토리로 푸시됩니다.
7: postCommit 섹션에서는 선택적 빌드 후크를 정의합니다.

8.2. 기본 빌드 작업
링크 복사

8.2.1. 빌드 시작
링크 복사

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

oc start-build <buildconfig_name>

$ oc start-build <buildconfig_name>

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

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

oc start-build <buildconfig_name> --follow

$ oc start-build <buildconfig_name> --follow

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

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

Expand

옵션	설명
`--from-dir=<directory>`	보관하여 빌드에 바이너리 입력으로 사용할 디렉터리를 지정합니다.
`--from-file=<file>`	빌드 소스에서 유일한 파일이 될 단일 파일을 지정합니다. 이 파일은 제공된 원래 파일과 파일 이름이 동일한 빈 디렉터리의 루트에 배치됩니다.
`--from-repo=<local_source_repo>`	빌드에 바이너리 입력으로 사용할 로컬 리포지토리의 경로를 지정합니다. 빌드에 사용되는 분기, 태그 또는 커밋을 제어하는 `--commit` 옵션을 추가합니다.

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

참고

바이너리 입력에서 트리거된 빌드는 서버의 소스를 유지하지 않으므로 기본 이미지 변경에 의해 트리거된 리빌드는 빌드 구성에 지정된 소스를 사용합니다.

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

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

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

Copy to Clipboard

Toggle word wrap

8.2.2. 빌드 취소
링크 복사

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

oc cancel-build <build_name>

$ oc cancel-build <build_name>

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

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

oc cancel-build bc/<buildconfig_name>

$ oc cancel-build bc/<buildconfig_name>

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

8.2.3. BuildConfig 삭제
링크 복사

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

oc delete bc <BuildConfigName>

$ oc delete bc <BuildConfigName>

Copy to Clipboard

Toggle word wrap

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

oc delete --cascade=false bc <BuildConfigName>

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

Copy to Clipboard

Toggle word wrap

8.2.4. 빌드 세부 정보 보기
링크 복사

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

oc describe build <build_name>

$ oc describe build <build_name>

Copy to Clipboard

Toggle word wrap

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

빌드 소스
빌드 전략
출력 대상
대상 레지스트리의 이미지 다이제스트
빌드가 생성된 방법

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

8.2.5. 빌드 로그 액세스
링크 복사

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

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

oc logs -f build/<build_name>

$ oc logs -f build/<build_name>

Copy to Clipboard

Toggle word wrap

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

oc logs -f bc/<buildconfig_name>

$ oc logs -f bc/<buildconfig_name>

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

로그 세부 정보

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

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

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

1

Copy to Clipboard

Toggle word wrap

1: 이 값을 원하는 로그 수준으로 조정합니다.

참고

플랫폼 관리자는 BuildDefaults 승인 컨트롤러에 대한 env/BUILD_LOGLEVEL 을 구성하여 전체 OpenShift Container Platform 인스턴스에 대한 기본 빌드 상세 정보 표시 수준을 설정할 수 있습니다. 이 기본값은 지정된 BuildConfig에 BUILD_LOGLEVEL을 지정하여 덮어쓸 수 있습니다. 명령줄에서 --build-loglevel을 oc start-build로 전달하여 바이너리가 아닌 빌드에 더 높은 우선순위를 지정할 수 있습니다.

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

수준 0	*assemble* 스크립트를 실행하는 컨테이너에서 출력을 생성하고 모든 발생한 오류를 생성합니다. 이는 기본값입니다.
수준 1	실행된 프로세스에 대한 기본 정보를 생성합니다.
수준 2	실행된 프로세스에 대한 매우 자세한 정보를 생성합니다.
수준 3	실행된 프로세스에 대한 자세한 정보와 아카이브 콘텐츠 목록을 생성합니다.
수준 4	현재는 수준 3과 동일한 정보를 제공합니다.
수준 5	위 수준에서 언급한 모든 정보를 생성하고 Docker 내보내기 메시지도 제공합니다.

8.3. 빌드 입력
링크 복사

8.3.1. 빌드 입력 작업 방법
링크 복사

빌드 입력 에서는 빌드가 작동하도록 소스 콘텐츠를 제공합니다. OpenShift Container Platform에서 소스를 제공하는 방법에는 여러 가지가 있습니다. 우선순위 순서에 따라:

인라인 Dockerfile 정의
기존 이미지에서 추출한 컨텐츠
Git 리포지토리
바이너리(로컬) 입력
입력 보안
외부 아티팩트

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

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

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

작업 디렉터리가 구성되고 모든 입력 콘텐츠가 작업 디렉터리에 배치됩니다. 예를 들어 입력 Git 리포지토리가 작업 디렉터리에 복제되고 입력 이미지에서 지정된 파일이 타겟 경로를 사용하여 작업 디렉터리에 복사됩니다.
빌드 프로세스에서는 contextDir이 정의된 경우 디렉터리를 해당 디렉터리로 변경합니다.
인라인 Dockerfile(있는 경우)은 현재 디렉터리에 기록됩니다.
현재 디렉터리의 콘텐츠는 Dockerfile, 사용자 정의 빌더 논리 또는 assemble 스크립트에서 참조하기 위해 빌드 프로세스에 제공됩니다. 즉 contextDir 외부에 있는 모든 입력 콘텐츠는 빌드에서 무시합니다.

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

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

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

Copy to Clipboard

Toggle word wrap

1: 빌드를 위한 작업 디렉터리에 복제할 리포지토리입니다.
2: myinputimage 의 /usr/lib/somefile.jar 는 < workingdir>/app/dir/injected/dir 에 저장됩니다.
3: 빌드용 작업 디렉터리는 < original_workingdir>/app/dir 이 됩니다.
4: 이 콘텐츠가 있는 Dockerfile은 < original_workingdir>/app/dir 에 생성되어 해당 이름의 기존 파일을 덮어씁니다.

8.3.2. Dockerfile 소스
링크 복사

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

이 필드는 일반적으로 Docker 전략 빌드에 Dockerfile 을 제공하는 데 사용됩니다.

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

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

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

1

Copy to Clipboard

Toggle word wrap

1: dockerfile 필드에는 빌드할 인라인 Dockerfile이 포함되어 있습니다.

8.3.3. 이미지 소스
링크 복사

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

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

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

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

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

Copy to Clipboard

Toggle word wrap

1: 하나 이상의 입력 이미지 및 파일로 이루어진 배열입니다.
2: 복사할 파일이 포함된 이미지에 대한 참조입니다.
3: 소스/대상 경로로 이루어진 배열입니다.
4: 빌드 프로세스에서 파일에 액세스할 수 있는, 빌드 루트의 상대 디렉터리입니다.
5: 참조한 이미지에서 복사할 파일의 위치입니다.
6: 입력 이미지에 액세스하는 데 자격 증명이 필요한 경우 제공되는 선택적 보안입니다.

참고

이 기능은 사용자 지정 전략을 사용하는 빌드에서는 지원되지 않습니다.

8.3.4. Git 소스
링크 복사

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

인라인 Dockerfile을 제공하면 Git 리포지토리의 contextDir 에 Dockerfile 을 덮어씁니다.

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

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

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

Copy to Clipboard

Toggle word wrap

1: git 필드에는 소스 코드의 원격 Git 리포지토리에 대한 URI가 포함되어 있습니다. 필요한 경우 ref 필드를 지정하여 특정 Git 참조를 확인합니다. 유효한 ref는 SHA1 태그 또는 분기 이름이 될 수 있습니다.
2: contextDir 필드를 사용하면 빌드에서 애플리케이션 소스 코드를 찾는 소스 코드 리포지토리 내부의 기본 위치를 덮어쓸 수 있습니다. 애플리케이션이 하위 디렉터리에 있는 경우 이 필드를 사용하여 기본 위치(루트 폴더)를 덮어쓸 수 있습니다.
3: 선택적 dockerfile 필드를 제공하는 경우 소스 리포지토리에 있을 수 있는 모든 Dockerfile을 덮어쓰는 Dockerfile이 문자열에 포함되어야 합니다.

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

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

8.3.4.1. 프록시 사용
링크 복사

프록시를 통해서만 Git 리포지토리에 액세스할 수 있는 경우 BuildConfig 의 source 섹션에서 사용할 프록시를 정의할 수 있습니다. 사용할 HTTP 및 HTTPS 프록시를 둘 다 구성할 수 있습니다. 두 필드 모두 선택 사항입니다. 프록시를 사용하지 않아야 하는 도메인도 NoProxy 필드를 통해 지정할 수 있습니다.

참고

이를 위해서는 소스 URI에서 HTTP 또는 HTTPS 프로토콜을 사용해야 합니다.

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

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

Copy to Clipboard

Toggle word wrap

클러스터 관리자는 Ansible을 사용하여 Git 복제의 글로벌 프록시를 구성 할 수도 있습니다.

참고

Pipeline 전략 빌드의 경우 Jenkins의 Git 플러그인에 대한 현재 제한 사항을 고려할 때 Git 플러그인을 통한 모든 Git 작업은 BuildConfig 에 정의된 HTTP 또는 HTTPS 프록시를 활용하지 않습니다. Git 플러그인은 플러그인 관리자 패널에서 Jenkins UI에 구성된 프록시만 사용합니다. 이 프록시는 모든 작업에서 Jenkins 내의 모든 Git 상호 작용에 사용됩니다. JenkinsBehindProxy에서 Jenkins UI를 통해 프록시를 구성하는 방법에 대한 지침을 확인할 수 있습니다.

8.3.4.2. 소스 복제 보안
링크 복사

빌더 Pod는 빌드의 소스로 정의된 모든 Git 리포지토리에 액세스해야 합니다. 소스 복제 보안은 자체 서명되거나 신뢰할 수 없는 SSL 인증서가 있는 프라이빗 리포지토리 또는 리포지토리와 같이 일반적으로 액세스할 수 없는 리포지토리에 대한 액세스 권한을 제공하는 데 사용됩니다.

다음 소스 복제 보안 구성이 지원됩니다.

.gitconfig File
기본 인증
SSH 키 인증
신뢰할 수 있는 인증 기관

참고

이러한 구성의 조합을 사용하여 특정 요구 사항을 충족할 수도 있습니다.

빌드는 사용된 소스 복제 보안에 대한 액세스 권한이 있어야 하는 builder 서비스 계정으로 실행됩니다. 다음 명령으로 액세스 권한이 부여됩니다.

oc secrets link builder mysecret

$ oc secrets link builder mysecret

Copy to Clipboard

Toggle word wrap

참고

기본적으로 비활성화되어 있는 서비스 계정으로만 시크릿을 제한합니다. 즉, 마스터 구성 파일에서 serviceAccountConfig.limitSecretReferences 가 false (기본 설정)로 설정된 경우 서비스에 시크릿을 연결할 필요가 없습니다.

8.3.4.2.1. 빌드 구성에 소스 복제 보안 자동 추가
링크 복사

BuildConfig가 생성되면 OpenShift Container Platform에서 소스 복제 보안 참조를 자동으로 채울 수 있습니다. 이 동작을 사용하면 결과 빌드에서 참조된 보안에 저장된 인증 정보를 자동으로 사용하여 추가 구성없이 원격 Git 리포지토리에 인증할 수 있습니다.

이 기능을 사용하려면 Git 리포지토리 인증 정보가 포함된 보안이 나중에 BuildConfig 가 생성될 네임스페이스에 있어야 합니다. 이 시크릿에 는 build.openshift.io/source-secret-match-uri- 접두사가 붙은 하나 이상의 주석이 추가로 포함되어야 합니다. 이러한 각 주석의 값은 다음과 같이 정의된 URI 패턴입니다. 소스 복제 보안 참조 없이 BuildConfig 가 생성되고 해당 Git 소스 URI는 Secret 주석의 URI 패턴과 일치하는 경우 OpenShift Container Platform은 BuildConfig 에 해당 보안에 참조를 자동으로 삽입합니다.

URI 패턴은 다음으로 구성되어야 합니다.

유효한 스키마(*://, git://, http://, https:// 또는 ssh://).
호스트 (* 또는 유효한 호스트 이름 또는 IP 주소, 필요한 경우 *..
경로 (/* 또는 / 뒤에는 선택적으로 * 문자를 포함 하는 경우).

위의 모든 항목에서 * 문자는 와일드카드로 해석됩니다.

중요

URI 패턴은 RFC3986을 준수하는 Git 소스 URI와 일치해야 합니다. URI 패턴에 사용자 이름(또는 암호) 구성 요소를 포함하지 마십시오.

예를 들어 git 리포지토리 URL에 ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN/jira.git 을 사용하는 경우 소스 보안을 ssh://bitbucket.atlassian.com:7999/* ( ssh://git@bitbucket.atlassian.com:7999/*아님)로 지정해야 합니다.

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

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

Copy to Clipboard

Toggle word wrap

여러 보안이 특정 BuildConfig 의 Git URI와 일치하는 경우 OpenShift Container Platform은 가장 긴 일치 항목이 있는 보안을 선택합니다. 이렇게 하면 다음 예와 같이 기본 덮어쓰기가 가능합니다.

다음 조각은 두 개의 부분적인 소스 복제 보안을 보여줍니다. 첫 번째는 HTTPS를 통해 액세스하는 도메인 mycorp.com의 모든 서버와 일치하고, 두 번째는 서버 mydev1.mycorp.com 및 mydev2.mycorp.com에 대한 액세스 권한을 덮어씁니다.

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:
  ...

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:
  ...

Copy to Clipboard

Toggle word wrap

다음을 사용하여 기존 보안에 build.openshift.io/source-secret-match-uri- 주석을 추가합니다.

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

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

Copy to Clipboard

Toggle word wrap

8.3.4.2.2. 수동으로 소스 복제 보안 추가
링크 복사

소스 복제 보안은 BuildConfig 내부의 source 섹션에 source Secret 필드를 추가하고 생성한 시크릿 이름(이 예에서는basic secret )으로 설정하여 빌드 구성에 수동으로 추가할 수 있습니다.

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"

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"

Copy to Clipboard

Toggle word wrap

참고

oc set build-secret 명령을 사용하여 기존 빌드 구성에 소스 복제 보안을 설정할 수도 있습니다.

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

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

Copy to Clipboard

Toggle word wrap

BuildConfig에 시크릿을 정의하면 이 항목에 대한 자세한 정보가 제공됩니다.

8.3.4.2.3. .gitconfig 파일
링크 복사

애플리케이션 복제가 .gitconfig 파일에 종속된 경우 이 파일이 포함된 보안을 생성한 다음 빌더 서비스 계정에 추가한 다음 BuildConfig 를 수행할 수 있습니다.

.gitconfig 파일에서 보안을 생성하려면 다음을 수행합니다.

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

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

Copy to Clipboard

Toggle word wrap

참고

.gitconfig 파일의 http 섹션에 sslVerify=false 가 설정된 경우 SSL 확인을 해제할 수 있습니다.

[http]
        sslVerify=false

[http]
        sslVerify=false

Copy to Clipboard

Toggle word wrap

8.3.4.2.4. Secured Git용 .gitconfig 파일
링크 복사

Git 서버가 2-way SSL 및 사용자 이름으로 보안된 경우 소스 빌드에 인증서 파일을 추가하고 .gitconfig 파일의 인증서 파일에 참조를 추가해야 합니다.

애플리케이션 소스 코드의 /var/run/secrets/openshift.io/source/ 폴더에 client.crt, cacert.crt, client.key 파일을 추가합니다.

서버의 .gitconfig 파일에서 다음 예에 표시된 [http] 섹션을 추가합니다.

cat .gitconfig
[user]
        name = <name>
        email = <email>
[http]
        sslVerify = false
        sslCert = /var/run/secrets/openshift.io/source/client.crt
        sslKey = /var/run/secrets/openshift.io/source/client.key
        sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt

# cat .gitconfig
[user]
        name = <name>
        email = <email>
[http]
        sslVerify = false
        sslCert = /var/run/secrets/openshift.io/source/client.crt
        sslKey = /var/run/secrets/openshift.io/source/client.key
        sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt

Copy to Clipboard

Toggle word wrap

시크릿을 생성합니다.

oc create secret generic <secret_name> \
--from-literal=username=<user_name> \
--from-literal=password=<password> \
--from-file=.gitconfig=.gitconfig \
--from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
--from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
--from-file=client.key=/var/run/secrets/openshift.io/source/client.key

$ oc create secret generic <secret_name> \
--from-literal=username=<user_name> \

1


--from-literal=password=<password> \

2


--from-file=.gitconfig=.gitconfig \
--from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \
--from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \
--from-file=client.key=/var/run/secrets/openshift.io/source/client.key

Copy to Clipboard

Toggle word wrap

1: 사용자의 Git 사용자 이름입니다.
2: 이 사용자의 암호입니다.

중요

암호를 다시 입력하지 않으려면 빌드에서 S2I 이미지를 지정해야 합니다. 그러나 리포지토리를 복제할 수 없는 경우에도 빌드를 승격하려면 사용자 이름과 암호를 지정해야 합니다.

8.3.4.2.5. 기본 인증
링크 복사

기본 인증에는 --username 및 --password 를 조합하거나 SCM 서버에 인증할 토큰이 필요합니다.

개인 리포지토리에 액세스하기 위해 사용자 이름과 암호를 사용하기 전에 먼저 시크릿 을 생성합니다.

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=username=<user_name> \
    --from-literal=password=<password> \
    --type=kubernetes.io/basic-auth

Copy to Clipboard

Toggle word wrap

토큰을 사용하여 기본 인증 보안을 생성하려면 다음을 수행합니다.

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

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

Copy to Clipboard

Toggle word wrap

8.3.4.2.6. SSH 키 인증
링크 복사

SSH 키 기반 인증에는 개인 SSH 키가 필요합니다.

리포지토리 키는 일반적으로 $HOME/.ssh/ 디렉터리에 있으며 기본적으로 이름이 id_dsa.pub,id_ecdsa.pub,id_ed25519.pub 또는 id_rsa.pub 입니다. 다음 명령을 사용하여 SSH 키 자격 증명을 생성합니다.

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

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

Copy to Clipboard

Toggle word wrap

참고

SSH 키의 암호를 생성하면 OpenShift Container Platform이 빌드되지 않습니다. 암호를 입력하라는 메시지가 표시되면 비워 두십시오.

두 파일(공개 키 및 해당 개인 키(id_dsa, id_ecdsa, id_ed25519 또는 id_rsa))이 생성됩니다. 두 파일이 모두 있는 상태에서 공개 키를 업로드하는 방법에 대한 SCM(소스 제어 관리) 시스템의 설명서를 참조하십시오. 개인 키는 개인 리포지토리에 액세스하는 데 사용됩니다.

SSH 키를 사용하여 개인 리포지토리에 액세스하기 전에 먼저 보안을 생성합니다.

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

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

Copy to Clipboard

Toggle word wrap

8.3.4.2.7. 신뢰할 수 있는 인증 기관
링크 복사

git clone 작업 중에 신뢰할 수 있는 TLS 인증 기관 세트는 OpenShift Container Platform 인프라 이미지에 빌드됩니다. Git 서버에서 자체 서명된 인증서 또는 이미지에서 신뢰할 수 없는 인증 기관에서 서명한 인증서를 사용하는 경우 인증서가 포함된 보안을 생성하거나 TLS 확인을 비활성화할 수 있습니다.

CA 인증서에 대한 보안을 생성하는 경우 OpenShift Container Platform에서는 git clone 작업 중에 Git 서버에 액세스합니다. 이 방법을 사용하면 제공되는 모든 TLS 인증서를 허용하는 Git의 SSL 확인을 비활성화하는 것보다 더 안전합니다.

다음 프로세스 중 하나를 완료합니다.

CA 인증서 파일을 사용하여 보안을 생성합니다(권장).
1. CA에서 중간 인증 기관을 사용하는 경우 ca.crt 파일의 모든 CA 인증서를 결합합니다. 다음 명령을 실행합니다.
  $ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt
  Copy to Clipboard Toggle word wrap
2. 시크릿을 생성합니다.
  $ oc create secret generic mycert --from-file=ca.crt=</path/to/file>
  1
  Copy to Clipboard Toggle word wrap
  1
  키 이름 ca.crt 를 사용해야 합니다.
Git TLS 확인을 비활성화합니다.
빌드 구성의 적절한 전략 섹션에서 GIT_SSL_NO_VERIFY 환경 변수를 true 로 설정합니다. oc set env 명령을 사용하여 BuildConfig 환경 변수를 관리할 수 있습니다.

8.3.4.2.8. 조합
링크 복사

다음은 위의 방법을 결합하여 특정 요구에 맞는 소스 복제 보안을 생성하는 방법에 대한 몇 가지 예입니다.

.gitconfig 파일을 사용하여 SSH 기반 인증 보안을 생성하려면 다음을 수행합니다.

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

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

Copy to Clipboard

Toggle word wrap

.gitconfig 파일 및 CA 인증서를 결합하는 보안을 생성하려면 다음을 수행합니다.

oc create secret generic <secret_name> \
    --from-file=ca.crt=<path/to/certificate> \
    --from-file=<path/to/.gitconfig>

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

Copy to Clipboard

Toggle word wrap

CA 인증서 파일을 사용하여 기본 인증 보안을 생성하려면 다음을 수행합니다.

oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=ca.crt=</path/to/file> \
    --type=kubernetes.io/basic-auth

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

Copy to Clipboard

Toggle word wrap

.gitconfig 파일을 사용하여 기본 인증 보안을 생성하려면 다음을 수행합니다.

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

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

Copy to Clipboard

Toggle word wrap

.gitconfig 파일 및 CA 인증서 파일을 사용하여 기본 인증 보안을 생성하려면 다음을 수행합니다.

oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --from-file=ca.crt=</path/to/file> \
    --type=kubernetes.io/basic-auth

$ oc create secret generic <secret_name> \
    --from-literal=username=<user_name> \
    --from-literal=password=<password> \
    --from-file=</path/to/.gitconfig> \
    --from-file=ca.crt=</path/to/file> \
    --type=kubernetes.io/basic-auth

Copy to Clipboard

Toggle word wrap

8.3.5. 바이너리(로컬) 소스
링크 복사

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

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

참고

바이너리 유형 빌드에서는 로컬 파일 시스템에서 콘텐츠를 스트리밍해야 하므로 바이너리 유형 빌드를 자동으로 트리거할 수 없습니다(예: 이미지 변경 트리거를 통해) 바이너리 파일을 제공할 수 없기 때문입니다. 마찬가지로 웹 콘솔에서 바이너리 유형 빌드를 시작할 수 없습니다.

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

--from-file: 지정한 파일의 콘텐츠가 빌더에 바이너리 스트림으로 전송됩니다. 파일에 URL을 지정할 수도 있습니다. 그러면 빌더에서 빌드 컨텍스트 상단에 있는 것과 동일한 이름으로 파일에 데이터를 저장합니다.
--from-dir 및 --from-repo: 콘텐츠가 보관되고 빌더에 바이너리 스트림으로 전송됩니다. 그러면 빌더가 빌드 컨텍스트 디렉터리 내에서 아카이브 콘텐츠를 추출합니다. --from-dir 을 사용하면 추출될 아카이브에 URL을 지정할 수도 있습니다.
--from-archive: 지정하는 아카이브가 빌더로 전송되며 빌드 컨텍스트 디렉터리 내에서 추출됩니다. 이 옵션은 --from-dir과 동일하게 작동합니다. 이러한 옵션에 대한 인수가 디렉터리인 경우 먼저 호스트에서 아카이브가 생성됩니다.

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

BuildConfig 에 이미 Binary 소스 유형이 정의되어 있는 경우 효과적으로 무시되고 클라이언트가 전송하는 내용으로 교체됩니다.
BuildConfig에 Git 소스 유형이 정의되어 있는 경우 Binary 및 Git을 함께 사용할 수 없으므로 해당 BuildConfig가 동적으로 비활성화되고 빌더에 제공하는 바이너리 스트림의 데이터에 우선순위가 지정됩니다.

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 필드의 값이 아카이브 내 하위 디렉터리로 해석되고, 유효한 경우 빌드를 실행하기 전에 빌더가 해당 하위 디렉터리로 변경됩니다.

8.3.6. 입력 보안
링크 복사

일부 시나리오에서는 빌드 작업을 할 때 종속 리소스에 액세스하기 위한 인증서가 필요하지만 빌드에서 생성한 최종 애플리케이션 이미지에서 해당 인증서가 사용 가능한 것은 바람직하지 않습니다. 이러한 목적으로 입력 보안을 정의할 수 있습니다.

예를 들어 Node.js 애플리케이션을 빌드할 때 Node.js 모듈에 맞게 개인용 미러를 설정할 수 있습니다. 해당 프라이빗 미러에서 모듈을 다운로드하려면 URL, 사용자 이름 및 암호가 포함된 빌드에 사용할 사용자 정의 .npmrc 파일을 제공해야 합니다. 보안상의 이유로 애플리케이션 이미지에 자격 증명을 노출해서는 안 됩니다.

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

8.3.6.1. 입력 보안 추가
링크 복사

기존 BuildConfig 에 입력 보안을 추가하려면 다음을 수행합니다.

보안이 없으면 다음과 같이 생성합니다.
```
oc create secret generic secret-npmrc \
    --from-file=.npmrc=<path/to/.npmrc>
```
```
$ oc create secret generic secret-npmrc \
    --from-file=.npmrc=<path/to/.npmrc>
```
Copy to Clipboard Toggle word wrap
이렇게 하면 ~/.npmrc 파일의 base64 인코딩 콘텐츠가 포함된 secret-npmrc 라는 새 보안이 생성됩니다.

다음과 같이 기존 BuildConfig의 source 섹션에 보안을 추가합니다.

source:
  git:
    uri: https://github.com/openshift/nodejs-ex.git
  secrets:
    - secret:
        name: secret-npmrc

source:
  git:
    uri: https://github.com/openshift/nodejs-ex.git
  secrets:
    - secret:
        name: secret-npmrc

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 새 BuildConfig에 보안을 포함시킵니다.

oc new-build \
    openshift/nodejs-010-centos7~https://github.com/openshift/nodejs-ex.git \
    --build-secret secret-npmrc

$ oc new-build \
    openshift/nodejs-010-centos7~https://github.com/openshift/nodejs-ex.git \
    --build-secret secret-npmrc

Copy to Clipboard

Toggle word wrap

빌드 중에 .npmrc 파일이 소스 코드가 있는 디렉터리로 복사됩니다. OpenShift Container Platform S2I 빌더 이미지에서 이 디렉터리는 Dockerfile 의 WORKDIR 명령을 사용하여 설정된 이미지 작업 디렉터리입니다. 다른 디렉터리를 지정하려면 보안 정의에 destinationDir 을 추가합니다.

source:
  git:
    uri: https://github.com/openshift/nodejs-ex.git
  secrets:
    - secret:
        name: secret-npmrc
      destinationDir: /etc

source:
  git:
    uri: https://github.com/openshift/nodejs-ex.git
  secrets:
    - secret:
        name: secret-npmrc
      destinationDir: /etc

Copy to Clipboard

Toggle word wrap

새 BuildConfig 를 생성할 때 대상 디렉터리를 지정할 수도 있습니다.

oc new-build \
    openshift/nodejs-010-centos7~https://github.com/openshift/nodejs-ex.git \
    --build-secret “secret-npmrc:/etc”

$ oc new-build \
    openshift/nodejs-010-centos7~https://github.com/openshift/nodejs-ex.git \
    --build-secret “secret-npmrc:/etc”

Copy to Clipboard

Toggle word wrap

두 경우 모두 빌드 환경의 /etc 디렉토리에 .npmrc 파일이 추가됩니다. Docker 전략 의 경우 대상 디렉터리는 상대 경로여야 합니다.

8.3.6.2. S2I(Source-to-Image) 전략
링크 복사

Source 전략을 사용하면 정의된 모든 입력 보안이 해당 destinationDir에 복사됩니다. destinationDir을 비워 두면 보안이 빌더 이미지의 작업 디렉터리에 배치됩니다.

destinationDir 이 상대 경로인 경우 동일한 규칙이 사용됩니다. 보안은 이미지의 작업 디렉터리를 기준으로 하는 경로에 배치됩니다. destinationDir 이 있어야 합니다. 그렇지 않으면 오류가 발생합니다. 복사 프로세스 중에 디렉터리 경로가 생성되지 않습니다.

참고

현재 이러한 비밀을 가진 모든 파일은 world-writable ( 0666 권한이 있음)이며 assemble 스크립트를 실행한 후 0으로 잘립니다. 즉, 보안 파일은 결과 이미지에 존재하지만 보안상의 이유로 비어 있습니다.

8.3.6.3. Docker 전략
링크 복사

Docker 전략을 사용하는 경우 Dockerfile 의 ADD 및 COPY 명령을 사용하여 정의된 모든 입력 보안을 컨테이너 이미지에 추가할 수 있습니다.

보안의 destinationDir 을 지정하지 않으면 Dockerfile 이 있는 동일한 디렉터리로 파일이 복사됩니다. 상대 경로를 destinationDir 로 지정하면 보안이 Dockerfile 위치와 관련하여 해당 디렉터리에 복사됩니다. 그러면 Docker 빌드 작업에서 빌드 중 사용하는 컨텍스트 디렉터리의 일부로 보안 파일을 사용할 수 있습니다.

예 8.1. 보안 데이터를 참조하는 Dockerfile의 예

FROM centos/ruby-22-centos7

USER root
ADD ./secret-dir /secrets
COPY ./secret2 /

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

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

FROM centos/ruby-22-centos7

USER root
ADD ./secret-dir /secrets
COPY ./secret2 /

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

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

Copy to Clipboard

Toggle word wrap

참고

일반적으로 사용자는 해당 이미지에서 실행 중인 컨테이너에 보안이 표시되지 않도록 최종 애플리케이션 이미지에서 입력 보안을 제거해야 합니다. 그러나 보안은 추가된 계층에 있는 이미지 자체에 계속 존재합니다. 이 제거는 Dockerfile 자체에 포함되어야 합니다.

8.3.6.4. 사용자 정의 전략
링크 복사

사용자 정의 전략을 사용하는 경우 정의된 모든 입력 보안은 /var/run/secrets/openshift.io/build 디렉터리의 빌더 컨테이너 내에서 사용할 수 있습니다. 사용자 정의 빌드 이미지는 이러한 보안을 적절하게 사용해야 합니다. 사용자 정의 전략을 사용하면 사용자 정의 전략 옵션에 설명된 대로 시크릿도 정의할 수 있습니다.

기존 전략 보안과 입력 보안은 기술적으로 차이가 없습니다. 그러나 빌더 이미지는 빌드 사용 사례에 따라 해당 이미지를 구분하고 다르게 사용할 수 있습니다.

입력 보안은 항상 /var/run/secrets/openshift.io/build 디렉터리에 마운트되거나 빌더에서 전체 빌드 오브젝트를 포함하는 $BUILD 환경 변수를 구문 분석할 수 있습니다.

8.3.7. 외부 Artifacts 사용
링크 복사

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

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

.s2i/bin/assemble 파일

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

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

Copy to Clipboard

Toggle word wrap

.s2i/bin/run 파일

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

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

Copy to Clipboard

Toggle word wrap

참고

소스 빌드에 사용되는 assemble 및 run 스크립트를 제어하는 방법에 대한 자세한 내용은 빌더 이미지 스크립트 덮어쓰기 를 참조하십시오.

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

Dockerfile발췌 내용

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" ]

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" ]

Copy to Clipboard

Toggle word wrap

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

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

.s2i/environment 파일 사용 (소스 빌드 전략 전용)
BuildConfig에 설정
oc start-build --env를 사용하여 명시적으로 제공 (수동으로 트리거되는 빌드 전용)

8.3.8. 프라이빗 레지스트리에 Docker 인증 정보 사용
링크 복사

프라이빗 Docker 레지스트리에 유효한 자격 증명이 있는 .docker/config.json 파일을 사용하여 빌드를 제공할 수 있습니다. 이를 통해 출력 이미지를 프라이빗 Docker 레지스트리로 내보내거나 인증이 필요한 프라이빗 Docker 레지스트리에서 빌더 이미지를 가져올 수 있습니다.

참고

OpenShift Container Platform Docker 레지스트리의 경우 OpenShift Container Platform에서 보안이 자동으로 생성되므로 필요하지 않습니다.

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

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

auths:
  https://index.docker.io/v1/:

1


    auth: "YWRfbGzhcGU6R2labnRib21ifTE="

2


    email: "user@example.com"

3

Copy to Clipboard

Toggle word wrap

1: 레지스트리의 URL입니다.
2: 암호화된 암호입니다.
3: 로그인에 사용할 이메일 주소입니다.

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

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

로컬 .docker/config.json 파일에서 보안을 생성합니다.

oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

$ oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

Copy to Clipboard

Toggle word wrap

이 명령은 dockerhub라는 보안의 JSON 사양을 생성한 후 오브젝트를 생성합니다.

보안이 생성되면 builder 서비스 계정에 추가합니다. 각 빌드는 builder 역할로 실행되므로 다음 명령을 사용하여 시크릿에 액세스 권한을 부여해야 합니다.
```
oc secrets link builder dockerhub
```
```
$ oc secrets link builder dockerhub
```
Copy to Clipboard Toggle word wrap

BuildConfig 의 output 섹션에 pushSecret 필드를 추가하고 생성한 보안 의 이름으로 설정합니다. 위의 예에서 dockerhub:

spec:
  output:
    to:
      kind: "DockerImage"
      name: "private.registry.com/org/private-image:latest"
    pushSecret:
      name: "dockerhub"

spec:
  output:
    to:
      kind: "DockerImage"
      name: "private.registry.com/org/private-image:latest"
    pushSecret:
      name: "dockerhub"

Copy to Clipboard

Toggle word wrap

oc set build-secret 명령을 사용하여 빌드 구성에 내보내기 보안을 설정할 수도 있습니다.

oc set build-secret --push bc/sample-build dockerhub

$ oc set build-secret --push bc/sample-build dockerhub

Copy to Clipboard

Toggle word wrap

빌드 전략 정의의 일부인 pullSecret 필드를 지정하여 프라이빗 Docker 레지스트리에서 빌더 컨테이너 이미지를 가져옵니다.

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "docker.io/user/private_repository"
    pullSecret:
      name: "dockerhub"

strategy:
  sourceStrategy:
    from:
      kind: "DockerImage"
      name: "docker.io/user/private_repository"
    pullSecret:
      name: "dockerhub"

Copy to Clipboard

Toggle word wrap

oc set build-secret 명령을 사용하여 빌드 구성에 가져오기 보안을 설정할 수도 있습니다.

oc set build-secret --pull bc/sample-build dockerhub

$ oc set build-secret --pull bc/sample-build dockerhub

Copy to Clipboard

Toggle word wrap

참고

이 예제에서는 소스 빌드에 pullSecret을 사용하지만 Docker 및 Custom 빌드에도 적용할 수 있습니다.

8.4. 빌드 출력
링크 복사

8.4.1. 빌드 출력 개요
링크 복사

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

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

ImageStreamTag로 출력

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

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

Copy to Clipboard

Toggle word wrap

Docker 내보내기 사양으로 출력

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

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

Copy to Clipboard

Toggle word wrap

8.4.2. 이미지 환경 변수 출력
링크 복사

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

Expand

변수	설명
`OPENSHIFT_BUILD_NAME`	빌드 이름
`OPENSHIFT_BUILD_NAMESPACE`	빌드의 네임스페이스
`OPENSHIFT_BUILD_SOURCE`	빌드의 소스 URL
`OPENSHIFT_BUILD_REFERENCE`	빌드에 사용된 Git 참조
`OPENSHIFT_BUILD_COMMIT`	빌드에 사용된 소스 커밋

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

8.4.3. 출력 이미지 레이블
링크 복사

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

Expand

레이블	설명
`io.openshift.build.commit.author`	빌드에 사용된 소스 커밋 작성자
`io.openshift.build.commit.date`	빌드에 사용된 소스 커밋의 날짜
`io.openshift.build.commit.id`	빌드에 사용된 소스 커밋의 해시
`io.openshift.build.commit.message`	빌드에 사용된 소스 커밋의 메시지
`io.openshift.build.commit.ref`	소스에 지정된 분기 또는 참조
`io.openshift.build.source-location`	빌드의 소스 URL

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"

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

Copy to Clipboard

Toggle word wrap

8.4.4. 출력 이미지 다이제스트
링크 복사

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

Docker 및 소스 빌드는 이미지를 레지스트리로 푸시한 후 Build.status.output.to.imageDigest 에 다이제스트를 저장합니다. 다이제스트는 레지스트리에 의해 계산됩니다. 따라서 예를 들어 레지스트리에서 다이제스트를 반환하지 않았거나 빌더 이미지에서 해당 형식을 인식하지 못하는 경우와 같이 이러한 문제가 발생할 수 있습니다.

레지스트리에 대한 Successful Push 후 기본 이미지 다이제스트

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

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

Copy to Clipboard

Toggle word wrap

8.4.5. 프라이빗 레지스트리에 Docker 인증 정보 사용
링크 복사

이미지를 프라이빗 Docker 레지스트리에 푸시하려면 보안을 사용하여 인증 정보를 제공할 수 있습니다. 지침은 빌드 입력을 참조하십시오.

8.5. 빌드 전략 옵션
링크 복사

8.5.1. S2I(Source-to-Image) 전략 옵션
링크 복사

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

8.5.1.1. 강제 Pull
링크 복사

기본적으로 빌드 구성에 지정된 빌더 이미지를 노드에서 로컬로 사용할 수 있는 경우 해당 이미지가 사용됩니다. 그러나 로컬 이미지를 재정의하고 이미지 스트림이 가리키는 레지스트리에서 새로 고침하려면 forcePull 플래그가 true 로 설정된 BuildConfig 를 생성합니다.

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

strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "builder-image:latest"

1


    forcePull: true

2

Copy to Clipboard

Toggle word wrap

1: 사용 중인 빌더 이미지가 사용됩니다. 여기서 노드의 로컬 버전이 이미지 스트림이 가리키는 레지스트리의 버전으로 업데이트되지 않을 수 있습니다.
2: 이 플래그를 사용하면 로컬 빌더 이미지가 무시되고 이미지 스트림이 가리키는 레지스트리에서 새 버전을 가져옵니다. forcePull 을 false 로 설정하면 로컬에 저장된 이미지를 따르는 기본 동작이 생성됩니다.

8.5.1.2. 증분 빌드
링크 복사

S2I는 증분 빌드를 수행할 수 있으므로 이전에 빌드한 이미지의 아티팩트를 재사용합니다. 증분 빌드를 생성하려면 전략 정의를 다음과 같이 수정하여 BuildConfig 를 생성합니다.

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

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

1


    incremental: true

2

Copy to Clipboard

Toggle word wrap

1: 증분 빌드를 지원하는 이미지를 지정합니다. 빌더 이미지 설명서를 참조하여 이 동작을 지원하는지 확인합니다.
2: 이 플래그는 증분 빌드 시도 여부를 제어합니다. 빌더 이미지에서 증분 빌드를 지원하지 않는 경우 빌드는 성공하지만 save-artifacts 스크립트가 누락되어 증분 빌드가 성공적이지 않은 로그 메시지가 표시됩니다.

참고

증분 빌드를 지원하는 빌더 이미지를 생성하는 방법에 대한 자세한 내용은 S2I 요구 사항 주제를 참조하십시오.

8.5.1.3. 빌더 이미지 스크립트 덮어쓰기
링크 복사

다음 두 가지 방법 중 하나로 빌더 이미지에서 제공하는 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"

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

1

Copy to Clipboard

Toggle word wrap

1: 이 경로에는 , assemble, save-artifacts 가 추가됩니다. 일부 또는 모든 스크립트가 발견되면 이미지에 제공된 동일한 이름의 스크립트 대신 사용됩니다.

참고

scripts URL에 있는 파일은 소스 리포지토리의 .s2i/bin 에 있는 파일보다 우선합니다. S2I 스크립트 사용 방법에 대한 정보는 S2I 요구 사항 주제 및 S2I 설명서를 참조하십시오.

8.5.1.4. 환경 변수
링크 복사

소스 빌드 프로세스 및 결과 이미지에서 환경 변수를 사용할 수 있도록 하는 방법에는 두 가지가 있습니다. 환경 파일 및 BuildConfig 환경 값입니다. 제공되는 변수는 빌드 프로세스 중 출력 이미지에 제공됩니다.

8.5.1.4.1. 환경 파일
링크 복사

소스 빌드를 사용하면 소스 리포지토리의 .s2i/environment 파일에 지정하여 애플리케이션 내에서 환경 값(행당 하나씩)을 설정할 수 있습니다. 이 파일에 지정된 환경 변수는 빌드 프로세스 중 출력 이미지에 제공됩니다. 지원되는 환경 변수의 전체 목록은 각 이미지의 설명서에서 확인할 수 있습니다.

소스 리포지토리에 .s2i/environment 파일을 제공하는 경우 S2I는 빌드 중에 이 파일을 읽습니다. 그러면 assemble 스크립트에서 이러한 변수를 사용할 수 있으므로 빌드 동작을 사용자 정의할 수 있습니다.

예를 들어 Rails 애플리케이션의 자산 컴파일을 비활성화하려면 .s2i/environment 파일에 DISABLE_ASSET_COMPILATION=true 를 추가하여 빌드 중에 자산 컴파일을 건너뛰도록 할 수 있습니다.

빌드 외에 지정된 환경 변수도 실행 중인 애플리케이션 자체에서 사용할 수 있습니다. 예를 들어 .s2i/environment 파일에 RAILS_ENV=development 를 추가하여 Rails 애플리케이션이 프로덕션 대신 개발 모드에서 시작되도록 할 수 있습니다.

8.5.1.4.2. BuildConfig 환경
링크 복사

BuildConfig 의 sourceStrategy 정의에 환경 변수를 추가할 수 있습니다. 여기에 정의된 환경 변수는 assemble 스크립트를 실행하는 동안 표시되고 출력 이미지에 정의되어 run 스크립트 및 애플리케이션 코드에서도 사용할 수 있습니다.

예를 들어 Rails 애플리케이션의 자산 컴파일을 비활성화하는 방법은 다음과 같습니다.

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

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

Copy to Clipboard

Toggle word wrap

빌드 환경 섹션에서는 고급 지침을 제공합니다.

oc set env 명령을 사용하여 BuildConfig 에 정의된 환경 변수도 관리할 수 있습니다.

8.5.1.5. 웹 콘솔을 통한 보안 추가
링크 복사

프라이빗 리포지토리에 액세스할 수 있도록 빌드 구성에 보안을 추가하려면 다음을 수행합니다.

새 OpenShift Container Platform 프로젝트를 생성합니다.
개인 소스 코드 리포지토리에 액세스하는 데 필요한 자격 증명이 포함된 보안을 생성합니다.
S2I(Source-to-Image) 빌드 구성을 생성합니다.
빌드 구성 편집기 페이지 또는 웹 콘솔 의 빌더 이미지에서 앱 생성 페이지에서 소스 보안을 설정합니다.
저장 버튼을 클릭합니다.

8.5.1.5.1. 가져오기 및 푸시 활성화
링크 복사

빌드 구성에서 Pull Secret 을 설정하여 프라이빗 레지스트리로 가져오고 푸시 보안을 설정하여 내보내기를 활성화합니다.

8.5.1.6. 소스 파일 무시
링크 복사

이미지의 소스는 무시해야 하는 파일 패턴 목록이 포함된 .s2iignore 파일을 지원합니다. .s2iignore 파일에 있는 패턴과 일치하는 다양한 입력 소스에서 제공하는 빌드 작업 디렉터리의 파일은 assemble 스크립트에서 사용할 수 없습니다.

.s2iignore 파일 형식에 대한 자세한 내용은 S2I(Source -to-image) 설명서를 참조하십시오.

8.5.2. Docker 전략 옵션
링크 복사

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

8.5.2.1. FROM Image
링크 복사

Dockerfile 의 FROM 명령은 BuildConfig 의 from 으로 대체됩니다.

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

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

Copy to Clipboard

Toggle word wrap

8.5.2.2. Dockerfile 경로
링크 복사

기본적으로 Docker 빌드에서는 BuildConfig.spec.source.contextDir 필드에 지정된 컨텍스트의 루트에 있는 Dockerfile(이름 Dockerfile)을 사용합니다.

dockerfilePath 필드를 사용하면 BuildConfig.spec.source.contextDir 필드와 상대되는 다른 경로를 사용하여 Dockerfile을 찾을 수 있습니다. 기본 Dockerfile (예: MyDockerfile) 또는 하위 디렉터리의 Dockerfile 경로(예: dockerfiles/app1/Dockerfile) 이외의 다른 파일 이름일 수 있습니다.

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

strategy:
  dockerStrategy:
    dockerfilePath: dockerfiles/app1/Dockerfile

Copy to Clipboard

Toggle word wrap

8.5.2.3. 캐시 없음
링크 복사

Docker 빌드는 일반적으로 빌드를 수행하는 호스트에 있는 캐시된 계층을 재사용합니다. noCache 옵션을 true 로 설정하면 빌드에서 캐시된 계층을 무시하고 Dockerfile 의 모든 단계를 다시 실행합니다.

strategy:
  dockerStrategy:
    noCache: true

strategy:
  dockerStrategy:
    noCache: true

Copy to Clipboard

Toggle word wrap

8.5.2.4. 강제 Pull
링크 복사

기본적으로 빌드 구성에 지정된 빌더 이미지를 노드에서 로컬로 사용할 수 있는 경우 해당 이미지가 사용됩니다. 그러나 로컬 이미지를 재정의하고 이미지 스트림이 가리키는 레지스트리에서 새로 고침하려면 forcePull 플래그가 true 로 설정된 BuildConfig 를 생성합니다.

strategy:
  dockerStrategy:
    forcePull: true

strategy:
  dockerStrategy:
    forcePull: true

1

Copy to Clipboard

Toggle word wrap

1: 이 플래그를 사용하면 로컬 빌더 이미지가 무시되고 새 버전이 이미지 스트림이 가리키는 레지스트리에서 가져올 수 있습니다. forcePull 을 false 로 설정하면 로컬에 저장된 이미지를 따르는 기본 동작이 생성됩니다.

8.5.2.5. 환경 변수
링크 복사

Docker 빌드 프로세스 및 결과 이미지에서 환경 변수를 사용할 수 있도록 BuildConfig 의 dockerStrategy 정의에 환경 변수를 추가하면 됩니다.

정의된 환경 변수는 FROM 명령 직후 단일 ENV Dockerfile 명령으로 삽입되어 나중에 Dockerfile 내에서 참조할 수 있습니다.

변수는 빌드 중 정의되고 출력 이미지에 유지되므로 해당 이미지를 실행하는 모든 컨테이너에도 존재합니다.

예를 들어 다음은 빌드 및 런타임 중 사용할 사용자 정의 HTTP 프록시를 정의합니다.

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

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

Copy to Clipboard

Toggle word wrap

클러스터 관리자는 Ansible을 사용하여 글로벌 빌드 설정을 구성 할 수도 있습니다.

oc set env 명령을 사용하여 BuildConfig 에 정의된 환경 변수도 관리할 수 있습니다.

8.5.2.6. 웹 콘솔을 통한 보안 추가
링크 복사

프라이빗 리포지토리에 액세스할 수 있도록 빌드 구성에 보안을 추가하려면 다음을 수행합니다.

새 OpenShift Container Platform 프로젝트를 생성합니다.
개인 소스 코드 리포지토리에 액세스하는 데 필요한 자격 증명이 포함된 보안을 생성합니다.
Docker 빌드 구성을 생성합니다.
빌드 구성 편집기 페이지 또는 웹 콘솔 의 fromimage 페이지에서 소스 보안을 설정합니다.
저장 버튼을 클릭합니다.

8.5.2.7. Docker 빌드 인수
링크 복사

Docker 빌드 인수를 설정하려면 BuildConfig 의 dockerStrategy 정의에 있는 BuildArgs 배열에 항목을 추가합니다. 예를 들어 다음과 같습니다.

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

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

Copy to Clipboard

Toggle word wrap

빌드 인수는 빌드가 시작될 때 Docker로 전달됩니다.

8.5.2.7.1. 가져오기 및 푸시 활성화
링크 복사

빌드 구성에서 Pull Secret 을 설정하여 프라이빗 레지스트리로 가져오고 푸시 보안을 설정하여 내보내기를 활성화합니다.

8.5.3. 사용자 정의 전략 옵션
링크 복사

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

8.5.3.1. FROM Image
링크 복사

customStrategy.from 섹션을 사용하여 사용자 정의 빌드에 사용할 이미지를 나타냅니다.

strategy:
  customStrategy:
    from:
      kind: "DockerImage"
      name: "openshift/sti-image-builder"

strategy:
  customStrategy:
    from:
      kind: "DockerImage"
      name: "openshift/sti-image-builder"

Copy to Clipboard

Toggle word wrap

8.5.3.2. Docker 소켓 노출
링크 복사

컨테이너 내부에서 Docker 명령을 실행하고 컨테이너 이미지 빌드를 허용하려면 빌드 컨테이너를 액세스 가능한 소켓에 바인딩해야 합니다. 이렇게 하려면 exposeDockerSocket 옵션을 true 로 설정합니다.

strategy:
  customStrategy:
    exposeDockerSocket: true

strategy:
  customStrategy:
    exposeDockerSocket: true

Copy to Clipboard

Toggle word wrap

8.5.3.3. 보안
링크 복사

모든 빌드 유형에 추가할 수 있는 소스 및 이미지의 시크릿 외에도 사용자 정의 전략을 통해 빌더 Pod에 임의의 보안 목록을 추가할 수 있습니다.

각 시크릿은 특정 위치에 마운트할 수 있습니다.

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

strategy:
  customStrategy:
    secrets:
      - secretSource:

1


          name: "secret1"
        mountPath: "/tmp/secret1"

2


      - secretSource:
          name: "secret2"
        mountPath: "/tmp/secret2"

Copy to Clipboard

Toggle word wrap

1: secretSource는 빌드와 동일한 네임스페이스에 있는 보안에 대한 참조입니다.
2: mountPath는 보안을 마운트해야 하는 사용자 정의 빌더 내부의 경로입니다.

8.5.3.3.1. 웹 콘솔을 통한 보안 추가
링크 복사

프라이빗 리포지토리에 액세스할 수 있도록 빌드 구성에 보안을 추가하려면 다음을 수행합니다.

새 OpenShift Container Platform 프로젝트를 생성합니다.
개인 소스 코드 리포지토리에 액세스하는 데 필요한 자격 증명이 포함된 보안을 생성합니다.
사용자 정의 빌드 구성을 생성합니다.
빌드 구성 편집기 페이지 또는 웹 콘솔 의 fromimage 페이지에서 소스 보안을 설정합니다.
저장 버튼을 클릭합니다.

8.5.3.3.2. 가져오기 및 푸시 활성화
링크 복사

빌드 구성에서 Pull Secret 을 설정하여 프라이빗 레지스트리로 가져오고 푸시 보안을 설정하여 내보내기를 활성화합니다.

8.5.3.4. 강제 Pull
링크 복사

기본적으로 빌드 Pod를 설정할 때 빌드 컨트롤러에서 빌드 구성에 지정된 이미지를 노드에서 로컬로 사용할 수 있는지 확인합니다. 이렇게 하면 해당 이미지가 사용됩니다. 그러나 로컬 이미지를 재정의하고 이미지 스트림이 가리키는 레지스트리에서 새로 고침하려면 forcePull 플래그가 true 로 설정된 BuildConfig 를 생성합니다.

strategy:
  customStrategy:
    forcePull: true

strategy:
  customStrategy:
    forcePull: true

1

Copy to Clipboard

Toggle word wrap

1: 이 플래그를 사용하면 로컬 빌더 이미지가 무시되고 새 버전이 이미지 스트림이 가리키는 레지스트리에서 가져올 수 있습니다. forcePull 을 false 로 설정하면 로컬에 저장된 이미지를 따르는 기본 동작이 생성됩니다.

8.5.3.5. 환경 변수
링크 복사

사용자 정의 빌드 프로세스에서 환경 변수를 사용할 수 있도록 하려면 BuildConfig 의 customStrategy 정의에 환경 변수를 추가할 수 있습니다.

여기에서 정의한 환경 변수는 사용자 정의 빌드를 실행하는 Pod로 전달됩니다.

예를 들어 빌드 중 사용할 사용자 정의 HTTP 프록시를 정의합니다.

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

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

Copy to Clipboard

Toggle word wrap

클러스터 관리자는 Ansible을 사용하여 글로벌 빌드 설정을 구성 할 수도 있습니다.

oc set env 명령을 사용하여 BuildConfig 에 정의된 환경 변수도 관리할 수 있습니다.

8.5.4. 파이프라인 전략 옵션
링크 복사

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

8.5.4.1. Jenkinsfile 제공
링크 복사

Jenkinsfile을 두 가지 방법 중 하나로 제공할 수 있습니다.

빌드 구성에 Jenkinsfile을 포함합니다.
빌드 구성에 Jenkinsfile이 포함된 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')
        }

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

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

1: 선택적 jenkinsfilePath 필드는 소스 contextDir에 상대적으로 사용할 파일의 이름을 지정합니다. contextDir이 생략된 경우 기본값은 리포지토리의 루트입니다. jenkinsfilePath 가 생략된 경우 기본값은 Jenkinsfile 입니다.

8.5.4.2. 환경 변수
링크 복사

Pipeline 빌드 프로세스에서 환경 변수를 사용할 수 있도록 하려면 BuildConfig 의 jenkinsPipelineStrategy 정의에 환경 변수를 추가할 수 있습니다.

정의된 환경 변수는 BuildConfig 와 연결된 모든 Jenkins 작업의 매개변수로 설정됩니다.

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

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

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

Copy to Clipboard

Toggle word wrap

참고

oc set env 명령을 사용하여 BuildConfig 에 정의된 환경 변수도 관리할 수 있습니다.

8.5.4.2.1. BuildConfig 환경 변수 및 Jenkins 작업 매개변수 간 매핑
링크 복사

Pipeline 전략 BuildConfig 의 변경 사항을 기반으로 Jenkins 작업이 생성되거나 업데이트되면 BuildConfig 의 모든 환경 변수가 Jenkins 작업 매개변수 정의에 매핑됩니다. 여기서 Jenkins 작업 매개변수 정의의 기본값은 연결된 환경 변수의 현재 값입니다.

Jenkins 작업의 초기 생성 후에도 Jenkins 콘솔에서 작업에 매개변수를 추가할 수 있습니다. 매개변수 이름은 BuildConfig 에 있는 환경 변수의 이름과 다릅니다. 매개변수는 해당 Jenkins 작업에 대한 빌드가 시작될 때 적용됩니다.

Jenkins 작업의 빌드를 시작하는 방법에 따라 매개변수 설정 방법이 결정됩니다. oc start-build 로 시작하는 경우 BuildConfig 의 환경 변수 값은 해당 작업 인스턴스에 설정된 매개변수입니다. Jenkins 콘솔에서 매개변수 기본값을 변경하면 해당 변경 사항이 무시됩니다. BuildConfig 값이 우선합니다.

oc start-build -e로 시작하는 경우 -e 옵션에 지정된 환경 변수의 값이 우선합니다. 그리고 BuildConfig 에 나열되지 않은 환경 변수를 지정하면 Jenkins 작업 매개변수 정의로 추가됩니다. 또한 Jenkins 콘솔에서 환경 변수에 해당하는 매개변수로 변경한 사항은 무시됩니다. BuildConfig 와 oc start-build -e 로 지정하는 항목이 우선합니다.

Jenkins 콘솔을 통해 Jenkins 작업을 시작하면 작업의 빌드를 시작하는 과정의 일부로 Jenkins 콘솔을 통해 매개변수 설정을 제어할 수 있습니다.

8.6. 빌드 환경
링크 복사

8.6.1. 개요
링크 복사

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

참고

oc set env 명령을 사용하여 BuildConfig 에 정의된 환경 변수도 관리할 수 있습니다.

8.6.2. 빌드 필드를 환경 변수로 사용
링크 복사

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

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

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

Copy to Clipboard

Toggle word wrap

참고

Jenkins Pipeline 전략에서는 환경 변수에 valueFrom 구문을 지원하지 않습니다.

8.6.3. 컨테이너 리소스를 환경 변수로 사용
링크 복사

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

8.6.4. 환경 변수로 시크릿 사용
링크 복사

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

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

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

Copy to Clipboard

Toggle word wrap

8.7. 빌드 트리거
링크 복사

8.7.1. 빌드 트리거 개요
링크 복사

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

Webhook
이미지 변경
구성 변경

8.7.2. Webhook 트리거
링크 복사

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

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

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

참고

oc new-app 및 oc new-build 는 GitHub 및 Generic webhook 트리거를 자동으로 생성하지만 필요한 다른 Webhook 트리거는 수동으로 추가해야 합니다( Triggers 설정참조).

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

8.7.2.1. GitHub Webhooks
링크 복사

GitHub Webhook 는 리포지토리를 업데이트할 때 GitHub에서 생성하는 호출을 처리합니다. 트리거를 정의할 때 시크릿을 지정해야 합니다. 이 시크릿 은 Webhook를 구성할 때 GitHub에 제공하는 URL의 일부입니다.

GitHub Webhook 정의의 예:

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

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

Copy to Clipboard

Toggle word wrap

참고

Webhook 트리거 구성에 사용되는 보안은 GitHub UI에서 Webhook를 구성할 때 표시되는 secret 필드와 동일하지 않습니다. 전자는 Webhook URL을 고유하고 예측하기 어렵게 만들고 후자는 X-Hub-Signature 헤더 로 전송되는 본문의 HMAC 16진수 다이제스트를 생성하는 데 사용되는 선택적 문자열 필드입니다.

페이로드 URL은 oc describe 명령으로 GitHub Webhook URL로 반환되며( Webhook URL 표시참조) 다음과 같이 구성됩니다.

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

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

Copy to Clipboard

Toggle word wrap

GitHub Webhook를 구성하려면 다음을 수행합니다.

GitHub 리포지토리에서 BuildConfig 를 생성한 후 다음을 실행합니다.

oc describe bc/<name-of-your-BuildConfig>

$ oc describe bc/<name-of-your-BuildConfig>

Copy to Clipboard

Toggle word wrap

그러면 다음과 같은 Webhook GitHub URL이 생성됩니다.

<https://api.starter-us-east-1.openshift.com:443/oapi/v1/namespaces/nsname/buildconfigs/bcname/webhooks/<secret>/github>.

<https://api.starter-us-east-1.openshift.com:443/oapi/v1/namespaces/nsname/buildconfigs/bcname/webhooks/<secret>/github>.

Copy to Clipboard

Toggle word wrap

GitHub 웹 콘솔에서 이 URL을 잘라내어 GitHub에 붙여넣습니다.
GitHub 리포지토리의 설정 → Webhook 및 서비스에서 Webhook 추가 를 선택합니다.
URL 출력(위와 유사)을 Payload URL 필드에 붙여넣습니다.
GitHub의 기본 application/x-www-form-urlencoded에서 콘텐츠 유형을 application/json으로 변경합니다.
Webhook 추가를 클릭합니다.

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

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

참고

Gogs는 GitHub와 동일한 Webhook 페이로드 형식을 지원합니다. 따라서 Gogs 서버를 사용하는 경우 BuildConfig 에 GitHub Webhook 트리거를 정의하고 Gogs 서버를 통해 트리거할 수 있습니다.

payload.json 과 같은 유효한 JSON 페이로드가 포함된 파일이 있는 경우 curl 을 통해 Webhook를 수동으로 트리거할 수 있습니다.

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

$ 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

Copy to Clipboard

Toggle word wrap

-k 인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.

8.7.2.2. GitLab Webhooks
링크 복사

GitLab Webhook 는 리포지토리를 업데이트할 때 GitLab에서 생성하는 호출을 처리합니다. GitHub 트리거와 마찬가지로 보안을 지정해야 합니다. 다음 예제는 BuildConfig 내의 트리거 정의 YAML입니다.

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

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

Copy to Clipboard

Toggle word wrap

페이로드 URL은 oc describe 명령을 통해 GitLab Webhook URL로 반환되고( Webhook URL 표시참조) 다음과 같이 구성됩니다.

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

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

Copy to Clipboard

Toggle word wrap

GitLab Webhook를 구성하려면 다음을 수행합니다.

Webhook URL을 가져오도록 빌드 구성을 설명합니다.
```
oc describe bc <name>
```
```
$ oc describe bc <name>
```
Copy to Clipboard Toggle word wrap
Webhook URL을 복사하여 <secret>을 보안 값으로 교체합니다.
GitLab 설정 지침에 따라 Webhook URL을 GitLab 리포지토리 설정에 붙여넣습니다.

payload.json 과 같은 유효한 JSON 페이로드가 포함된 파일이 있는 경우 curl 을 통해 Webhook를 수동으로 트리거할 수 있습니다.

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

$ 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

Copy to Clipboard

Toggle word wrap

-k 인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.

8.7.2.3. Bitbucket Webhooks
링크 복사

Bitbucket Webhook는 리포지토리가 업데이트될 때 Bitbucket에서 만든 호출을 처리합니다. 이전 트리거와 유사하게 보안을 지정해야 합니다. 다음 예제는 BuildConfig 내의 트리거 정의 YAML입니다.

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

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

Copy to Clipboard

Toggle word wrap

페이로드 URL은 oc describe 명령을 통해 Bitbucket Webhook URL로 반환되고( Webhook URL 표시참조) 다음과 같이 구성됩니다.

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

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

Copy to Clipboard

Toggle word wrap

Bitbucket Webhook를 구성하려면 다음을 수행합니다.

Webhook URL을 가져오도록 빌드 구성을 설명합니다.
```
oc describe bc <name>
```
```
$ oc describe bc <name>
```
Copy to Clipboard Toggle word wrap
Webhook URL을 복사하여 <secret>을 보안 값으로 교체합니다.
Bitbucket 설정 지침에 따라 Webhook URL을 Bitbucket 리포지토리 설정에 붙여넣습니다.

payload.json 과 같은 유효한 JSON 페이로드가 포함된 파일이 있는 경우 curl 을 통해 Webhook를 수동으로 트리거할 수 있습니다.

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

$ 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

Copy to Clipboard

Toggle word wrap

-k 인수는 API 서버에 올바르게 서명된 인증서가 없는 경우에만 필요합니다.

8.7.2.4. 일반 Webhook
링크 복사

일반 Webhook는 웹 요청을 수행할 수 있는 모든 시스템에서 호출합니다. 다른 Webhook와 마찬가지로 보안을 지정해야 합니다. 이 시크릿은 호출자가 빌드를 트리거하는 데 사용해야 하는 URL의 일부가 됩니다. 보안을 사용하면 URL의 고유성이 보장되어 다른 사용자가 빌드를 트리거할 수 없습니다. 다음은 BuildConfig 내 트리거 정의 YAML의 예입니다.

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

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

1

Copy to Clipboard

Toggle word wrap

1: 일반 Webhook에서 환경 변수를 전달하도록 허용하려면 true로 설정합니다.

호출자를 설정하기 위해 빌드에 대한 일반 Webhook 끝점의 URL을 호출 시스템에 제공합니다.

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

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

Copy to Clipboard

Toggle word wrap

호출자는 Webhook를 POST 작업으로 호출해야 합니다.

Webhook를 수동으로 호출하려면 curl을 사용하면 됩니다.

curl -X POST -k 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

Copy to Clipboard

Toggle word wrap

HTTP 동사를 POST로 설정해야 합니다. 비보안 -k 플래그는 인증서 검증을 무시하도록 지정됩니다. 클러스터에 올바르게 서명된 인증서가 있는 경우 이 두 번째 플래그는 필요하지 않습니다.

끝점은 다음 형식을 사용하여 선택적 페이로드를 허용할 수 있습니다.

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: 
   - name: "<variable name>"
     value: "<variable value>"

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>"

Copy to Clipboard

Toggle word wrap

1: BuildConfig 환경 변수와 유사하게 여기에 정의된 환경 변수를 빌드에 사용할 수 있습니다. 이러한 변수가 BuildConfig 환경 변수와 충돌하는 경우 해당 변수가 우선합니다. 기본적으로 Webhook를 통해 전달되는 환경 변수는 무시됩니다. 이 동작을 활성화하려면 Webhook 정의에서 allowEnv 필드를 true로 설정합니다.

curl 을 사용하여 이 페이로드를 전달하려면 payload_file.yaml 이라는 파일에 정의하고 다음을 실행합니다.

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

$ 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

Copy to Clipboard

Toggle word wrap

인수는 위 예제와 동일하고 헤더와 페이로드가 추가되었습니다. -H 인수는 페이로드 형식에 따라 Content-Type 헤더를 application/yaml 또는 application/json으로 설정합니다. --data-binary 인수는 POST 요청을 사용하여 온전한 새 줄로 바이너리 페이로드를 보내는 데 사용됩니다.

참고

OpenShift Container Platform에서는 유효하지 않은 요청 페이로드(예: 유효하지 않은 콘텐츠 유형, 구문 또는 유효하지 않은 콘텐츠 등)가 제공되더라도 일반 Webhook를 통해 빌드를 트리거할 수 있습니다. 이 동작은 이전 버전과의 호환성을 위해 유지됩니다. 유효하지 않은 요청 페이로드가 제공되면 OpenShift Container Platform에서 HTTP 200 OK 응답의 일부로 JSON 형식의 알림을 반환합니다.

8.7.2.5. Webhook URL 표시
링크 복사

다음 명령을 사용하여 빌드 구성과 관련된 Webhook URL을 표시합니다.

oc describe bc <name>

$ oc describe bc <name>

Copy to Clipboard

Toggle word wrap

위의 명령에서 Webhook URL을 표시하지 않으면 해당 빌드 구성에 Webhook 트리거가 정의되지 않습니다. 트리거를 수동으로 추가하도록 트리거 설정을 참조하십시오.

8.7.3. 이미지 변경 트리거
링크 복사

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

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

트리거하려는 업스트림 이미지를 가리키는 ImageStream을 정의합니다.
```
kind: "ImageStream"
apiVersion: "v1"
metadata:
  name: "ruby-20-centos7"
```
```
kind: "ImageStream"
apiVersion: "v1"
metadata:
  name: "ruby-20-centos7"
```
Copy to Clipboard Toggle word wrap
이는 < system-registry> / <namespace> /ruby-20-centos7 에 있는 컨테이너 이미지 리포지토리에 연결된 이미지 스트림을 정의합니다. & lt;system-registry >는 OpenShift Container Platform에서 실행 중인 docker-registry 라는 이름을 사용하여 서비스로 정의됩니다.
이미지 스트림이 빌드의 기본 이미지인 경우 빌드 전략의 from 필드를 이미지 스트림을 가리키도록 설정합니다.
```
strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "ruby-20-centos7:latest"
```
```
strategy:
  sourceStrategy:
    from:
      kind: "ImageStreamTag"
      name: "ruby-20-centos7:latest"
```
Copy to Clipboard Toggle word wrap
이 경우 sourceStrategy 정의에서는 이 네임스페이스 내에 있는 ruby-20-centos7이라는 이미지 스트림의 latest 태그를 사용합니다.
이미지 스트림을 가리키는 하나 이상의 트리거를 사용하여 빌드를 정의합니다.
```
type: "imageChange" 
imageChange: {}
type: "imageChange" 
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
```
```
type: "imageChange" 
```
1
```
imageChange: {}
type: "imageChange" 
```
2
```
imageChange:
  from:
    kind: "ImageStreamTag"
    name: "custom-image:latest"
```
Copy to Clipboard Toggle word wrap
1
빌드 전략의 from 필드에 정의된 ImageStream 및 Tag를 모니터링하는 이미지 변경 트리거입니다. 여기에서 imageChange 오브젝트는 비어 있어야 합니다.
2
임의의 이미지 스트림을 모니터링하는 이미지 변경 트리거입니다. 이 경우 imageChange 부분에 모니터링할 ImageStreamTag를 참조하는 from 필드를 포함해야 합니다.

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

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

참고

v1 Docker 레지스트리 의 컨테이너 이미지를 가리키는 이미지 스트림은 이미지 스트림 태그를 사용할 수 있을 때 빌드를 한 번만 트리거하고 후속 이미지 업데이트에서는 빌드를 트리거하지 않습니다. 이는 v1 Docker 레지스트리에서 고유하게 확인할 수 있는 이미지가 없기 때문입니다.

8.7.4. 구성 변경 트리거
링크 복사

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

  type: "ConfigChange"

  type: "ConfigChange"

Copy to Clipboard

Toggle word wrap

참고

구성 변경 트리거는 현재 새 BuildConfig를 생성할 때만 작동합니다. 향후 릴리스에서는 BuildConfig가 업데이트될 때마다 구성 변경 트리거도 빌드를 시작할 수 있습니다.

8.7.4.1. 트리거 수동 설정
링크 복사

oc set triggers를 사용하여 빌드 구성에서 트리거를 추가 및 제거할 수 있습니다. 예를 들어 빌드 구성에 GitHub Webhook 트리거를 설정하려면 다음을 사용합니다.

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

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

Copy to Clipboard

Toggle word wrap

이미지 변경 트리거를 설정하려면 다음을 사용합니다.

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

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

Copy to Clipboard

Toggle word wrap

트리거를 제거하려면 --remove를 추가합니다.

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

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

Copy to Clipboard

Toggle word wrap

참고

Webhook 트리거가 이미 있는 경우 해당 트리거를 다시 추가하면 Webhook 보안이 다시 생성됩니다.

자세한 내용은 oc set triggers --help의 도움말 문서를 참조하십시오.

8.8. 빌드 후크
링크 복사

8.8.1. 빌드 후크 개요
링크 복사

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

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

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

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

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

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

8.8.2. Post Commit Build Hooks 구성
링크 복사

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

쉘 스크립트:
```
postCommit:
  script: "bundle exec rake test --verbose"
```
```
postCommit:
  script: "bundle exec rake test --verbose"
```
Copy to Clipboard Toggle word wrap
script 값은 /bin/sh -ic를 사용하여 실행할 쉘 스크립트입니다. 쉘 스크립트가 빌드 후크를 실행하는 데 적합한 경우 이 값을 사용합니다. 예를 들면 위와 같이 단위 테스트를 실행하는 경우입니다. 이미지 항목 지점을 제어하려는 경우 또는 이미지에 /bin/sh가 없는 경우 command 및/또는 args를 사용합니다.
참고
추가 -i 플래그는 CentOS 및 RHEL 이미지 작업 환경을 개선하기 위해 도입되었으며 향후 릴리스에서 제거될 수 있습니다.
이미지 진입점으로서의 명령:
```
postCommit:
  command: ["/bin/bash", "-c", "bundle exec rake test --verbose"]
```
```
postCommit:
  command: ["/bin/bash", "-c", "bundle exec rake test --verbose"]
```
Copy to Clipboard Toggle word wrap
이 양식에서 command는 실행할 명령에 해당하며 Dockerfile 참조에 설명된 exec 형식의 이미지 진입점을 덮어씁니다. 이 명령은 이미지에 /bin/sh가 없거나 쉘을 사용하지 않는 경우 필요합니다. 다른 모든 경우에는 script를 사용하는 것이 더 편리할 수 있습니다.
기본 진입점에 인수를 전달합니다.
```
postCommit:
  args: ["bundle", "exec", "rake", "test", "--verbose"]
```
```
postCommit:
  args: ["bundle", "exec", "rake", "test", "--verbose"]
```
Copy to Clipboard Toggle word wrap
이 양식에서 args 는 이미지의 기본 진입점에 제공된 인수 목록입니다. 이미지 진입점은 인수를 처리할 수 있어야 합니다.
인수가 있는 쉘 스크립트:
```
postCommit:
  script: "bundle exec rake test $1"
  args: ["--verbose"]
```
```
postCommit:
  script: "bundle exec rake test $1"
  args: ["--verbose"]
```
Copy to Clipboard Toggle word wrap
쉘 스크립트에서 올바르게 인용하기 어려운 인수를 전달해야 하는 경우 이 양식을 사용합니다. 스크립트 0에서$0 은 "/bin/sh"이고 $ 1,2 등이 args 의 위치 인수입니다.

인수가 있는 명령:

postCommit:
  command: ["bundle", "exec", "rake", "test"]
  args: ["--verbose"]

postCommit:
  command: ["bundle", "exec", "rake", "test"]
  args: ["--verbose"]

Copy to Clipboard

Toggle word wrap

이 형식은 command에 인수를 추가하는 것과 동일합니다.

참고

script와 command를 동시에 제공하면 유효하지 않은 빌드 후크가 생성됩니다.

8.8.2.1. CLI 사용
링크 복사

oc set build-hook 명령은 빌드 설정에 빌드 후크를 설정하는 데 사용할 수 있습니다.

명령을 post-commit 빌드 후크로 설정하려면 다음을 실행합니다.

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

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

Copy to Clipboard

Toggle word wrap

스크립트를 post-commit 빌드 후크로 설정하려면 다음을 실행합니다.

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

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

Copy to Clipboard

Toggle word wrap

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

8.9.1. 빌드 정책 실행 개요
링크 복사

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

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

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

8.9.2. 직렬 실행 정책
링크 복사

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

Serial 정책을 사용하여 sample-build 구성에서 세 빌드를 트리거하면 다음이 수행됩니다.

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

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

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

8.9.3. SerialLatestOnly Run Policy
링크 복사

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

Copy to Clipboard

Toggle word wrap

8.9.4. 병렬 실행 정책
링크 복사

runPolicy 필드를 Parallel 로 설정하면 빌드 구성에서 생성된 모든 새 빌드가 병렬로 실행됩니다. 이렇게 하면 처음 생성된 빌드가 마지막으로 완료될 수 있으므로 예기치 않은 결과가 발생할 수 있으므로 이전에 완료한 마지막 빌드에서 생성된 푸시된 컨테이너 이미지가 대체됩니다.

빌드가 완료될 순서에 대해 신경 쓰지 않는 경우 병렬 실행 정책을 사용합니다.

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

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   Running   17 seconds ago   3s

Copy to Clipboard

Toggle word wrap

완료 주문은 보장되지 않습니다.

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

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

Copy to Clipboard

Toggle word wrap

8.10. 고급 빌드 작업
링크 복사

8.10.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: 
    cpu: "100m"
    memory: "256Mi"
```
```
resources:
  requests: 
```
1
```
    cpu: "100m"
    memory: "256Mi"
```
Copy to Clipboard Toggle word wrap
1
requests 오브젝트에 할당량의 리소스 목록에 해당하는 리소스 목록이 포함되어 있습니다.
프로젝트에 정의된 제한 범위: LimitRange 오브젝트의 기본값은 빌드 프로세스 중 생성된 Pod에 적용됩니다.

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

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

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

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

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

spec:
  completionDeadlineSeconds: 1800

spec:
  completionDeadlineSeconds: 1800

Copy to Clipboard

Toggle word wrap

참고

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

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

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

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 라벨이 있는 노드에서만 실행됩니다.

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

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

참고

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

8.10.4. 빌드 연결
링크 복사

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

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

참고

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

첫 번째 빌드에서는 애플리케이션 소스를 가져와서 WAR 파일이 포함된 이미지를 생성합니다. 이미지는 artifact-image 이미지 스트림으로 푸쉬합니다. 출력 아티팩트의 경로는 사용된 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

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

Copy to Clipboard

Toggle word wrap

두 번째 빌드에서는 첫 번째 빌드의 출력 이미지 내부의 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: 
        kind: ImageStreamTag
        name: artifact-image:latest
      paths: 
      - sourcePath: /wildfly/standalone/deployments/ROOT.war
        destinationDir: "."
  strategy:
    dockerStrategy:
      from: 
        kind: ImageStreamTag
        name: jee-runtime:latest
    type: Docker
  triggers:
  - imageChange: {}
    type: ImageChange

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

Copy to Clipboard

Toggle word wrap

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

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

8.10.5. 빌드 정리
링크 복사

기본적으로 라이프사이클이 완료된 빌드는 무기한 유지됩니다. 다음 샘플 빌드 구성에 표시된 대로 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: failed BuildsHistoryLimit 은 실패 상태,취소됨 또는 오류와 함께 최대 두 개의 빌드를 유지합니다.

빌드 정리가 다음 작업에 의해 트리거됩니다.

빌드 구성 업데이트
빌드가 라이프사이클이 완료됩니다.

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

참고

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

8.11. 빌드 문제 해결
링크 복사

8.11.1. 리소스 거부에 대한 액세스 요청
링크 복사

문제

다음과 같은 메시지가 표시되고 빌드가 실패합니다.

requested access to the resource is denied

requested access to the resource is denied

Copy to Clipboard

Toggle word wrap

해결

프로젝트에 설정된 이미지 할당량 중 하나를 초과했습니다. 현재 할당량을 확인하고 적용되는 제한과 사용 중인 스토리지를 확인합니다.

oc describe quota

$ oc describe quota

Copy to Clipboard

Toggle word wrap

9장. 배포
링크 복사

9.1. 배포 방법
링크 복사

9.1.1. 배포란 무엇인가?
링크 복사

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

애플리케이션 특정 구성 요소의 원하는 상태를 포드 템플릿으로 설명하는 배포 구성입니다.
배포 구성 상태의 지정 시간 레코드가 Pod 템플릿으로 포함되는 복제 컨트롤러가 하나 이상 있습니다.
하나 이상의 Pod: 특정 버전의 애플리케이션 인스턴스를 나타냅니다.

중요

사용자는 배포 구성에서 소유한 복제 컨트롤러 또는 Pod를 조작할 필요가 없습니다. 배포 시스템을 사용하면 배포 구성 변경 사항이 적절하게 전파됩니다. 기존 배포 전략이 사용 사례에 적합하지 않고 배포 라이프사이클 중에 수동 단계를 실행해야 하는 경우 사용자 지정 전략을 생성해야 합니다.

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

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

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

실행 중인 애플리케이션을 위한 템플릿인 배포 구성.
이벤트에 대한 응답으로 자동 배포를 실행하는 트리거
이전 버전에서 새 버전으로 전환하는 사용자 정의 가능 전략. 전략은 일반적으로 배포 프로세스라는 Pod 내에서 실행됩니다.
배포 라이프사이클 중 다른 지점에서 사용자 정의 동작을 실행하기 위한 일련의 후크 입니다.
배포가 실패하는 경우 롤백 을 수동 또는 자동으로 지원하기 위한 애플리케이션 버전 관리
수동 복제 스케일링 및 자동 스케일링.

9.1.2. 배포 구성 생성
링크 복사

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

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

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

Copy to Clipboard

Toggle word wrap

1: 프런트 엔드 배포 구성의 포드 템플릿은 간단한 Ruby 애플리케이션을 설명합니다.
2: 프런트 엔드의 복제본 5개가 있습니다.
3: 구성 변경 트리거를 사용하면 Pod 템플릿이 변경될 때마다 새 복제 컨트롤러가 생성됩니다.
4: origin-ruby-sample:latest 이미지 스트림 태그의 새 버전을 사용할 수 있을 때마다 이미지 변경 트리거 트리거를 통해 새 복제 컨트롤러가 생성됩니다.
5: 롤링 전략은 Pod를 배포하는 기본 방법입니다. 생략될 수 있습니다.
6: 배포 구성을 일시 중지합니다. 이는 모든 트리거의 기능을 비활성화하고 실제로 롤아웃하기 전에 pod 템플릿에서 여러 변경 사항을 허용합니다.
7: 버전 기록 제한은 롤백을 위해 계속 사용하려는 이전 복제 컨트롤러의 제한입니다. 생략될 수 있습니다. 생략하면 이전 복제 컨트롤러가 정리되지 않습니다.
8: Pod를 사용할 수 있도록 대기하는 최소 시간(준비 검사 성공 후)입니다. 기본값은 0입니다.

9.2. 기본 배포 작업
링크 복사

9.2.1. 배포 시작
링크 복사

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

oc rollout latest dc/<name>

$ oc rollout latest dc/<name>

Copy to Clipboard

Toggle word wrap

참고

배포 프로세스가 이미 진행 중인 경우 명령에서 메시지를 표시하고 새 복제 컨트롤러가 배포되지 않습니다.

9.2.2. 배포 보기
링크 복사

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

oc rollout history dc/<name>

$ oc rollout history dc/<name>

Copy to Clipboard

Toggle word wrap

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

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

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

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

Copy to Clipboard

Toggle word wrap

배포 구성 및 최신 버전에 대한 자세한 내용을 보려면 다음을 수행하십시오.

oc describe dc <name>

$ oc describe dc <name>

Copy to Clipboard

Toggle word wrap

참고

웹 콘솔 은 Browse (찾아보기) 탭에 배포를 표시합니다.

9.2.3. 배포 롤백
링크 복사

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

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

oc rollout undo dc/<name>

$ oc rollout undo dc/<name>

Copy to Clipboard

Toggle word wrap

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

롤백이 완료된 후 실수로 새 배포 프로세스를 시작하는 것을 방지하기 위해 배포 구성에서 이미지 변경 트리거가 롤백의 일부로 비활성화됩니다. 이미지 변경 트리거를 다시 활성화하려면 다음을 수행합니다.

oc set triggers dc/<name> --auto

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

Copy to Clipboard

Toggle word wrap

참고

배포 구성은 최신 배포 프로세스가 실패하는 경우 마지막으로 성공한 구성 리버전으로 자동 롤백을 지원합니다. 이 경우 배포되지 않은 최신 템플릿은 시스템에서 그대로 유지되며 사용자가 해당 구성을 수정할 수 있습니다.

9.2.4. 컨테이너 내부 명령 실행
링크 복사

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

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

Copy to Clipboard

Toggle word wrap

9.2.5. 배포 로그 보기
링크 복사

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

oc logs -f dc/<name>

$ oc logs -f dc/<name>

Copy to Clipboard

Toggle word wrap

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

oc logs --help

$ oc logs --help

Copy to Clipboard

Toggle word wrap

9.2.6. 배포 트리거 설정
링크 복사

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

주의

배포 구성에 트리거가 정의되지 않은 경우 기본적으로 ConfigChange 트리거가 추가됩니다. Trigger가 빈 필드로 정의된 경우 배포를 수동으로 시작해야 합니다.

9.2.6.1. 구성 변경 트리거
링크 복사

ConfigChange 를 트리거하면 배포 구성의 Pod 템플릿에서 변경 사항이 탐지될 때마다 새 복제 컨트롤러가 생성됩니다.

참고

ConfigChange 트리거가 배포 구성에 정의된 경우 배포 구성 자체를 생성한 직후 첫 번째 복제 컨트롤러가 자동으로 생성되고 일시 중지되지 않습니다.

예 9.1. ConfigChange Trigger

triggers:
  - type: "ConfigChange"

triggers:
  - type: "ConfigChange"

Copy to Clipboard

Toggle word wrap

9.2.6.2. ImageChange Trigger
링크 복사

ImageChange 를 트리거하면 이미지 스트림 태그 내용이 변경될 때마다(새 버전의 이미지를 내보낼 때) 새 복제 컨트롤러가 생성됩니다.

예 9.2. ImageChange Trigger

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

triggers:
  - type: "ImageChange"
    imageChangeParams:
      automatic: true

1


      from:
        kind: "ImageStreamTag"
        name: "origin-ruby-sample:latest"
        namespace: "myproject"
      containerNames:
        - "helloworld"

Copy to Clipboard

Toggle word wrap

1: imageChangeParams.automatic 필드를 false로 설정하면 트리거가 비활성화됩니다.

위 예제에서 origin-ruby-sample 이미지 스트림의 latest 태그 값이 변경되고 새 이미지 값이 배포 구성의 helloworld 컨테이너에 지정된 현재 이미지와 다른 경우 helloworld 컨테이너의 새 이미지를 사용하여 새 복제 컨트롤러가 생성됩니다.

참고

ImageChange 트리거가 배포 구성( ConfigChange 트리거 및 automatic=false )에 정의되고 ImageChange 트리거가 가리키는 ImageStreamTag 가 아직 존재하지 않는 경우 빌드에서 이미지를 가져오거나 태그로 푸시하는 즉시 초기 배포 프로세스가 자동으로 시작됩니다.

9.2.6.2.1. 명령줄 사용
링크 복사

oc set triggers 명령을 사용하여 배포 구성에 대한 배포 트리거를 설정할 수 있습니다. 위의 예제에서 다음 명령을 사용하여 ImageChangeTrigger 를 설정할 수 있습니다.

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

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

Copy to Clipboard

Toggle word wrap

자세한 내용은 다음을 참조하십시오.

oc set triggers --help

$ oc set triggers --help

Copy to Clipboard

Toggle word wrap

9.2.7. 배포 리소스 설정
링크 복사

배포는 노드에서 리소스(메모리 및 CPU)를 사용하는 Pod에 의해 완료됩니다. 기본적으로 Pod는 바인딩되지 않은 노드 리소스를 사용합니다. 그러나 프로젝트에서 기본 컨테이너 제한을 지정하는 경우 Pod는 해당 제한까지 리소스를 사용합니다.

리소스 제한을 배포 전략의 일부로 지정하여 리소스 사용을 제한할 수도 있습니다. 배포 리소스는 재생성, 롤링 또는 사용자 정의 배포 전략과 함께 사용할 수 있습니다.

다음 예에서 각 리소스,cpu, memory 는 선택 사항입니다.

type: "Recreate"
resources:
  limits:
    cpu: "100m" 
    memory: "256Mi"

type: "Recreate"
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 섹션:
```
  type: "Recreate"
  resources:
    requests: 
      cpu: "100m"
      memory: "256Mi"
```
```
  type: "Recreate"
  resources:
    requests: 
```
1
```
      cpu: "100m"
      memory: "256Mi"
```
Copy to Clipboard Toggle word wrap
1
requests 오브젝트에 할당량의 리소스 목록에 해당하는 리소스 목록이 포함되어 있습니다.

컴퓨팅 리소스와 요청 과 제한 사이의 차이점에 대한 자세한 내용은 할당량 및 제한 범위를 참조하십시오.

프로젝트에 정의된 제한 범위: LimitRange 오브젝트의 기본값은 배포 프로세스 중에 생성된 Pod에 적용됩니다.

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

9.2.8. 수동 확장
링크 복사

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

oc scale dc frontend --replicas=3

$ oc scale dc frontend --replicas=3

Copy to Clipboard

Toggle word wrap

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

참고

Pod는 oc autoscale 명령을 사용하여 자동 스케일링할 수도 있습니다. 자세한 내용은 Pod 자동 스케일링 을 참조하십시오.

9.2.9. 특정 노드에 Pod 할당
링크 복사

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

참고

OpenShift Container Platform 관리자는 고급 설치 중에 라벨을 할당하거나 설치 후 노드에 추가할 수 있습니다.

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

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

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

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

Copy to Clipboard

Toggle word wrap

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

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

예를 들어 클러스터 관리자가 프로젝트에 type=user-node 및 region=east 레이블을 추가하고 위의 disktype: ssd 라벨을 Pod에 추가하는 경우 Pod는 세 개의 라벨이 모두 있는 노드에서만 예약됩니다.

참고

레이블은 하나의 값으로만 설정할 수 있으므로 관리자가 설정한 기본값으로 region=east 가 있는 Pod 구성에 region=west 인 노드 선택기를 설정하면 예약되지 않는 Pod가 생성됩니다.

9.2.10. 다른 서비스 계정으로 Pod 실행
링크 복사

기본값 이외의 서비스 계정으로 Pod를 실행할 수 있습니다.

배포 구성을 편집합니다.
```
oc edit dc/<deployment_config>
```
```
$ oc edit dc/<deployment_config>
```
Copy to Clipboard Toggle word wrap

serviceAccount 및 serviceAccountName 매개변수를 spec 필드에 추가하고 사용할 서비스 계정을 지정합니다.

spec:
  securityContext: {}
  serviceAccount: <service_account>
  serviceAccountName: <service_account>

spec:
  securityContext: {}
  serviceAccount: <service_account>
  serviceAccountName: <service_account>

Copy to Clipboard

Toggle word wrap

9.2.11. 웹 콘솔에서 배포에 시크릿 추가
링크 복사

개인 리포지토리에 액세스할 수 있도록 배포 구성에 시크릿을 추가합니다.

새 OpenShift Container Platform 프로젝트를 생성합니다.
개인 이미지 리포지토리에 액세스하는 데 필요한 자격 증명이 포함된 시크릿을 생성합니다.
배포 구성을 생성합니다.
배포 구성 편집기 페이지 또는 웹 콘솔 의 fromimage 페이지에서 Pull Secret 을 설정합니다.
저장 버튼을 클릭합니다.

9.3. 배포 전략
링크 복사

9.3.1. 배포 전략이란 무엇입니까?
링크 복사

배포 전략은 애플리케이션을 변경하거나 업그레이드하는 방법입니다. 사용자가 개선 작업을 거의 알아채지 못하도록 다운타임 없이 변경하는 것이 목표입니다.

가장 일반적인 전략은 Blue-Green 배포를 사용하는 것입니다. 테스트 및 평가를 위해 새 버전(Blue 버전)이 제공되지만 사용자는 여전히 안정적인 버전(녹색 버전)을 사용합니다. 준비가 되면 사용자가 Blue 버전으로 전환합니다. 문제가 발생하면 녹색 버전으로 다시 전환할 수 있습니다.

일반적인 대체 전략은 동시에 활성 상태인 A/B 버전을 사용하는 것이며 일부 사용자는 하나의 버전을 사용하며 일부 사용자는 다른 버전을 사용합니다. 이 전략은 사용자 인터페이스 변경 및 기타 기능을 실험하여 사용자 피드백을 받는 데 사용할 수 있습니다. 또한 문제가 제한된 수의 사용자에게 영향을 미치는 프로덕션 컨텍스트에서 작업이 적절한지 확인하는 데 사용할 수도 있습니다.

카나리아 배포는 새 버전을 테스트하지만 문제가 발견되면 신속하게 이전 버전으로 대체합니다. 이는 위의 두 전략 모두에서 수행할 수 있습니다.

경로 기반 배포 전략에서는 서비스의 Pod 수를 스케일링하지 않습니다. 원하는 성능 특성을 유지하려면 배포 구성을 확장해야 할 수 있습니다.

배포 전략을 선택할 때 고려해야 할 사항이 있습니다.

오랫동안 실행 중인 연결을 정상적으로 처리해야 합니다.
데이터베이스 변환은 까다로울 수 있으며 애플리케이션과 함께 수행하고 롤백해야 합니다.
애플리케이션이 마이크로 서비스의 하이브리드이고 전환을 완료하기 위해 기존 구성 요소 다운타임이 필요할 수 있습니다.
이를 위해서는 인프라가 필요합니다.
격리되지 않은 테스트 환경이 있는 경우 새 버전과 이전 버전을 모두 중단할 수 있습니다.

최종 사용자는 일반적으로 라우터에서 처리하는 경로를 통해 애플리케이션에 액세스하므로 배포 전략은 배포 구성 기능 또는 라우팅 기능에 중점을 둘 수 있습니다.

배포 구성에 중점을 둔 전략은 애플리케이션을 사용하는 모든 경로에 영향을 미칩니다. 라우터 기능을 사용하는 전략은 개별 경로를 대상으로 합니다.

많은 배포 전략은 배포 구성을 통해 지원되며 일부 추가 전략은 라우터 기능을 통해 지원됩니다. 배포 구성 기반 전략은 이 섹션에서 설명합니다.

롤링 전략 및 카나리아 배포
재현 전략
사용자 정의 전략
경로를 사용한 Blue-Green 배포
경로를 사용한 A/B 배포 및 카나리아 배포
하나의 서비스, 여러 배포 구성

롤링 전략은 배포 구성에 전략이 지정되지 않은 경우 사용되는 기본 전략입니다.

배포 전략에서는 준비 상태 점검 을 사용하여 새 Pod를 사용할 준비가 되었는지 확인합니다. 준비 상태 점검이 실패하면 배포 구성이 시간 초과될 때까지 Pod를 다시 실행합니다. 기본 타임아웃은 dc.spec.strategy.*params의 TimeoutSeconds에 설정된 값인 10m입니다.

9.3.2. 롤링 전략
링크 복사

롤링 배포를 통해 이전 버전의 애플리케이션 인스턴스를 새 버전의 애플리케이션 인스턴스로 대체합니다. 롤링 배포는 일반적으로 이전 구성 요소를 축소하기 전에 준비 확인을 통해 새 Pod가 준비될 때까지 기다립니다. 심각한 문제가 발생하는 경우 롤링 배포가 중단될 수 있습니다.

9.3.2.1. 카나리아 배포
링크 복사

OpenShift Container Platform의 모든 롤링 배포는 카나리아 배포입니다. 이전 인스턴스를 모두 교체하기 전에 새 버전(캐나리아)을 테스트합니다. 준비 상태 점검이 실패하면 카나리아 인스턴스가 제거되고 배포 구성이 자동으로 롤백됩니다. 준비 상태 점검은 애플리케이션 코드의 일부이며 새 인스턴스를 사용할 준비가 되었는지 확인하는 데 필요한 만큼 정교할 수 있습니다. 더 복잡한 애플리케이션 점검을 구현해야 하는 경우(예: 실제 사용자 워크로드를 새 인스턴스로 전송) 사용자 지정 배포를 구현하거나 Blue-Green 배포 전략을 사용하는 것이 좋습니다.

9.3.2.2. 롤링 배포 사용 시기
링크 복사

애플리케이션을 업데이트하는 동안 다운타임이 발생하지 않도록 하려는 경우
애플리케이션에서 이전 코드 및 새 코드가 동시에 실행되도록 지원하는 경우

롤링 배포에서는 코드의 이전 버전과 새 버전이 동시에 실행됩니다. 이를 위해서는 일반적으로 애플리케이션에서 N-1 호환성 을 처리해야 합니다.

다음은 롤링 전략의 예입니다.

strategy:
  type: Rolling
  rollingParams:
    updatePeriodSeconds: 1 
    intervalSeconds: 1 
    timeoutSeconds: 120 
    maxSurge: "20%" 
    maxUnavailable: "10%" 
    pre: {} 
    post: {}

strategy:
  type: Rolling
  rollingParams:
    updatePeriodSeconds: 1

1


    intervalSeconds: 1

2


    timeoutSeconds: 120

3


    maxSurge: "20%"

4


    maxUnavailable: "10%"

5


    pre: {}

6


    post: {}

Copy to Clipboard

Toggle word wrap

1: 개별 Pod 업데이트 사이에 대기하는 시간입니다. 이 값을 지정하지 않는 경우 기본값은 1입니다.
2: 업데이트 후 배포 상태를 폴링할 때까지 대기하는 시간입니다. 이 값을 지정하지 않는 경우 기본값은 1입니다.
3: 스케일링 이벤트를 중지하기 전에 대기하는 시간입니다. 선택 사항이며 기본값은 600입니다. 여기서 중지하는 경우 이전에 완료된 배포로 자동으로 롤백합니다.
4: maxSurge는 선택 사항이며 지정하지 않는 경우 기본값은 25%입니다. 다음 절차 아래의 정보를 참조하십시오.
5: maxUnavailable은 선택 사항이며 지정하지 않는 경우 기본값은 25%입니다. 다음 절차 아래의 정보를 참조하십시오.
6: pre 및 post 는 둘 다 라이프사이클 후크 입니다.

롤링 전략은 다음과 같습니다.

pre 라이프사이클 후크를 실행합니다.
서지 수에 따라 새 복제 컨트롤러를 확장합니다.
사용할 수 없는 최대 수에 따라 이전 복제 컨트롤러를 축소합니다.
새 복제 컨트롤러가 원하는 복제본 수에 도달하고 이전 복제 컨트롤러가 0으로 스케일링될 때까지 이 스케일링을 반복합니다.
post 라이프사이클 후크를 실행합니다.

중요

축소할 때 롤링 전략은 Pod가 준비될 때까지 대기하므로 추가 스케일링이 가용성에 영향을 미치는지 여부를 결정할 수 있습니다. 확장된 Pod가 준비되지 않으면 배포 프로세스가 결국 타임아웃되어 배포에 실패합니다.

maxUnavailable 매개변수는 업데이트 중 사용할 수 없는 최대 Pod 수입니다. maxSurge 매개변수는 원래 Pod 수 이상으로 예약할 수 있는 최대 Pod 수입니다. 두 매개변수 모두 백분율 (예: 10%) 또는 절대 값(예: 2)으로 설정할 수 있습니다. 기본값은 둘 다 25%입니다.

이러한 매개변수를 사용하면 가용성 및 속도를 위해 배포를 조정할 수 있습니다. 예를 들어 다음과 같습니다.

maxUnavailable=0 및 maxSurge=20% 는 업데이트 및 빠른 확장 중에 전체 용량을 유지 관리합니다.
maxUnavailable=10% 및 maxSurge=0 은 추가 용량을 사용하지 않고 업데이트를 수행합니다(내부 업데이트).
maxUnavailable=10% 및 maxSurge=10% 는 빠르게 확장 및 축소되어 용량 손실 가능성이 있습니다.

일반적으로 빠른 롤아웃을 원한다면 maxSurge를 사용합니다. 리소스 할당량을 고려해야 하며 부분적인 비가용성을 허용할 수 있는 경우 maxUnavailable 을 사용합니다.

9.3.2.3. 롤링 예
링크 복사

롤링 배포는 OpenShift Container Platform의 기본값입니다. 롤링 업데이트를 보려면 다음 단계를 수행합니다.

DockerHub 에 있는 배포 이미지 예제를 기반으로 애플리케이션을 생성합니다.
```
oc new-app openshift/deployment-example
```
```
$ oc new-app openshift/deployment-example
```
Copy to Clipboard Toggle word wrap
라우터가 설치된 경우 경로를 통해 애플리케이션을 사용할 수 있도록 설정하고 서비스 IP를 직접 사용합니다.
```
oc expose svc/deployment-example
```
```
$ oc expose svc/deployment-example
```
Copy to Clipboard Toggle word wrap
deployment-example.<project>.<router_domain >에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
배포 구성을 3개의 복제본으로 확장합니다.
```
oc scale dc/deployment-example --replicas=3
```
```
$ oc scale dc/deployment-example --replicas=3
```
Copy to Clipboard Toggle word wrap
예제의 새 버전에 latest 태그를 지정하여 새 배포를 자동으로 트리거합니다.
```
oc tag deployment-example:v2 deployment-example:latest
```
```
$ oc tag deployment-example:v2 deployment-example:latest
```
Copy to Clipboard Toggle word wrap
브라우저에서 v2 이미지가 표시될 때까지 페이지를 새로 고칩니다.
CLI를 사용하는 경우 다음 명령은 버전 1의 Pod 수와 버전 2의 Pod 수를 보여줍니다. 웹 콘솔에서 포드가 느리게 v2에 추가되고 v1에서 제거되는 것을 확인할 수 있습니다.
```
oc describe dc deployment-example
```
```
$ oc describe dc deployment-example
```
Copy to Clipboard Toggle word wrap

배포 프로세스 중 새 복제 컨트롤러가 점점 확장됩니다. 새 Pod가 (준비 상태 점검을 통과하여) ready 상태로 표시되면 배포 프로세스가 계속됩니다. Pod가 준비 상태가 되지 않으면 프로세스가 중단되고 배포 구성이 이전 버전으로 롤백됩니다.

9.3.3. 재현 전략
링크 복사

재생성 전략에는 기본 롤아웃 동작이 있으며 배포 프로세스에 코드를 삽입하는 라이프사이클 후크 를 지원합니다.

다음은 재생성 전략의 예입니다.

strategy:
  type: Recreate
  recreateParams: 
    pre: {} 
    mid: {}
    post: {}

strategy:
  type: Recreate
  recreateParams:

1


    pre: {}

2


    mid: {}
    post: {}

Copy to Clipboard

Toggle word wrap

1: recreateParams는 선택 사항입니다.
2: pre,mid, post 는 라이프사이클 후크 입니다.

재생성 전략은 다음과 같습니다.

pre 라이프사이클 후크를 실행합니다.
이전 배포를 0으로 축소합니다.
mid 라이프사이클 후크를 실행합니다.
새 배포를 확장합니다.
post 라이프사이클 후크를 실행합니다.

중요

확장하는 동안 배포의 복제본 수가 두 개 이상인 경우 배포를 완전히 확장하기 전에 첫 번째 배포 복제본의 준비 상태를 검증합니다. 첫 번째 복제본의 검증이 실패하면 배포가 실패로 간주됩니다.

9.3.3.1. 재현 배포 사용 시기
링크 복사

새 코드가 시작되려면 마이그레이션 또는 기타 데이터 변환 작업을 실행해야 하는 경우
새 버전과 이전 버전의 애플리케이션 코드가 동시에 실행되는 것을 지원하지 않는 경우
여러 복제본에서 공유할 수 없는 RWO 볼륨을 사용하려는 경우

재현 배포에서는 잠시 동안 애플리케이션 인스턴스가 실행되지 않기 때문에 다운타임이 발생합니다. 그러나 기존 코드와 새 코드가 동시에 실행되지 않습니다.

9.3.4. 사용자 정의 전략
링크 복사

사용자 정의 전략을 사용하면 고유의 배포 동작을 제공할 수 있습니다.

다음은 사용자 정의 전략의 예입니다.

strategy:
  type: Custom
  customParams:
    image: organization/strategy
    command: [ "command", "arg1" ]
    environment:
      - name: ENV_1
        value: VALUE_1

strategy:
  type: Custom
  customParams:
    image: organization/strategy
    command: [ "command", "arg1" ]
    environment:
      - name: ENV_1
        value: VALUE_1

Copy to Clipboard

Toggle word wrap

위 예에서 organization/strategy 컨테이너 이미지는 배포 동작을 제공합니다. 선택적 command 배열은 이미지의 Dockerfile 에 지정된 모든 CMD 지시문을 재정의합니다. 제공되는 선택적 환경 변수는 전략 프로세스의 실행 환경에 추가됩니다.

또한 OpenShift Container Platform에서는 배포 프로세스에 다음 환경 변수를 제공합니다.

Expand

환경 변수	설명
`OPENSHIFT_DEPLOYMENT_NAME`	새 배포 이름(복제 컨트롤러)입니다.
`OPENSHIFT_DEPLOYMENT_NAMESPACE`	새 배포의 이름 공간입니다.

처음에는 새 배포의 복제본 수가 0입니다. 이 전략은 사용자의 요구에 가장 적합한 논리를 사용하여 새 배포를 활성화하는 작업을 담당합니다.

고급 배포 전략에 대해 자세히 알아보십시오.

또는 customParams 를 사용하여 기존 배포 전략에 사용자 정의 배포 논리를 삽입합니다. 사용자 정의 쉘 스크립트 논리를 제공하고 openshift-deploy 바이너리를 호출합니다. 사용자는 사용자 정의 배포 컨테이너 이미지를 제공할 필요는 없지만 기본 OpenShift Container Platform 배포자 이미지가 대신 사용됩니다.

strategy:
  type: Rolling
  customParams:
    command:
    - /bin/sh
    - -c
    - |
      set -e
      openshift-deploy --until=50%
      echo Halfway there
      openshift-deploy
      echo Complete

strategy:
  type: Rolling
  customParams:
    command:
    - /bin/sh
    - -c
    - |
      set -e
      openshift-deploy --until=50%
      echo Halfway there
      openshift-deploy
      echo Complete

Copy to Clipboard

Toggle word wrap

그러면 다음과 같은 배포가 생성됩니다.

Started deployment #2
--> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-2 up to 1
--> Reached 50% (currently 50%)
Halfway there
--> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-1 down to 1
    Scaling custom-deployment-2 up to 2
    Scaling custom-deployment-1 down to 0
--> Success
Complete

Started deployment #2
--> Scaling up custom-deployment-2 from 0 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-2 up to 1
--> Reached 50% (currently 50%)
Halfway there
--> Scaling up custom-deployment-2 from 1 to 2, scaling down custom-deployment-1 from 2 to 0 (keep 2 pods available, don't exceed 3 pods)
    Scaling custom-deployment-1 down to 1
    Scaling custom-deployment-2 up to 2
    Scaling custom-deployment-1 down to 0
--> Success
Complete

Copy to Clipboard

Toggle word wrap

사용자 정의 배포 전략 프로세스에서 OpenShift Container Platform API 또는 Kubernetes API에 액세스해야 하는 경우에는 전략을 실행하는 컨테이너에서 인증을 위해 컨테이너 내에 제공되는 서비스 계정 토큰을 사용하면 됩니다.

9.3.5. 라이프사이클 후크
링크 복사

재생성 및 롤링 전략에서는 라이프사이클 후크를 지원하므로 전략 내의 사전 정의된 지점에서 배포 프로세스에 동작을 삽입할 수 있습니다.

다음은 pre 라이프사이클 후크의 예입니다.

pre:
  failurePolicy: Abort
  execNewPod: {}

pre:
  failurePolicy: Abort
  execNewPod: {}

1

Copy to Clipboard

Toggle word wrap

1: execNewPod 는 Pod 기반 라이프사이클 후크 입니다.

모든 후크에는 후크 실패 시 전략에서 수행해야 하는 조치를 정의하는 failurePolicy 가 있습니다.

Expand

`Abort`	후크가 실패하면 배포 프로세스가 실패로 간주됩니다.
`Retry`	성공할 때까지 후크를 다시 실행합니다.
`Ignore`	모든 후크 오류를 무시하고 배포를 계속 진행합니다.

후크에는 후크 실행 방법을 설명하는 유형별 필드가 있습니다. 현재 Pod 기반 후크 는 지원되는 유일한 후크 유형이며 execNewPod 필드에 지정합니다.

9.3.5.1. Pod 기반 라이프사이클 후크
링크 복사

Pod 기반 라이프사이클 후크는 배포 구성의 템플릿에서 파생된 새 Pod에서 후크 코드를 실행합니다.

간소화된 다음 배포 구성에서는 롤링 전략을 사용합니다. 간결성을 위해 트리거 및 몇 가지 기타 사소한 세부 정보는 생략되었습니다.

kind: DeploymentConfig
apiVersion: v1
metadata:
  name: frontend
spec:
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
        - name: helloworld
          image: openshift/origin-ruby-sample
  replicas: 5
  selector:
    name: frontend
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          containerName: helloworld 
          command: [ "/usr/bin/command", "arg1", "arg2" ] 
          env: 
            - name: CUSTOM_VAR1
              value: custom_value1
          volumes:
            - data

kind: DeploymentConfig
apiVersion: v1
metadata:
  name: frontend
spec:
  template:
    metadata:
      labels:
        name: frontend
    spec:
      containers:
        - name: helloworld
          image: openshift/origin-ruby-sample
  replicas: 5
  selector:
    name: frontend
  strategy:
    type: Rolling
    rollingParams:
      pre:
        failurePolicy: Abort
        execNewPod:
          containerName: helloworld

1


          command: [ "/usr/bin/command", "arg1", "arg2" ]

2


          env:

3


            - name: CUSTOM_VAR1
              value: custom_value1
          volumes:
            - data

4

Copy to Clipboard

Toggle word wrap

1: helloworld 이름은 spec.template.spec.containers[0].name을 나타냅니다.
2: 이 command는 openshift/origin-ruby-sample 이미지로 정의된 모든 ENTRYPOINT를 재정의합니다.
3: env는 후크 컨테이너의 선택적 환경 변수 세트입니다.
4: volume은 후크 컨테이너의 선택적 볼륨 참조 세트입니다.

이 예에서 사전 후크는 helloworld 컨테이너의 openshift/origin-ruby-sample 이미지를 사용하여 새 Pod에서 실행됩니다. 후크 Pod에는 다음과 같은 속성이 있습니다.

후크 명령은 /usr/bin/command arg1 arg2 arg2입니다.
후크 컨테이너에는 CUSTOM_VAR1=custom_value1 환경 변수가 있습니다.
후크 실패 정책은 Abort 이므로 후크가 실패하면 배포 프로세스가 실패합니다.
후크 포드는 배포 구성 Pod에서 데이터 볼륨을 상속합니다.

9.3.5.2. 명령줄 사용
링크 복사

oc set deployment-hook 명령은 배포 구성에 배포 후크를 설정하는 데 사용할 수 있습니다. 위의 예제에서는 다음 명령을 사용하여 사전 배포 후크를 설정할 수 있습니다.

oc set deployment-hook dc/frontend --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
  -v data --failure-policy=abort -- /usr/bin/command arg1 arg2

$ oc set deployment-hook dc/frontend --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
  -v data --failure-policy=abort -- /usr/bin/command arg1 arg2

Copy to Clipboard

Toggle word wrap

9.4. 고급 배포 전략
링크 복사

9.4.1. 고급 배포 전략
링크 복사

배포 전략 에서는 애플리케이션을 개발하는 방법을 제공합니다. 일부 전략에서는 배포 구성을 사용하여 애플리케이션으로 확인되는 모든 경로의 사용자에게 표시되는 변경을 수행합니다. 여기에 설명된 것과 같은 기타 전략에서는 라우터 기능을 사용하여 특정 경로에 영향을 미칩니다.

9.4.2. Blue-Green 배포
링크 복사

Blue-Green 배포에는 두 가지 버전의 애플리케이션을 동시에 실행하고 프로덕션 내 버전(녹색 버전)에서 최신 버전(Blue 버전)으로 트래픽을 이동하는 작업이 포함됩니다. 롤링 전략 또는 전환 서비스를 경로에서 사용할 수 있습니다.

참고

많은 애플리케이션이 영구 데이터에 의존하기 때문에 N-1 호환성 을 지원하는 애플리케이션이 있어야 합니다. 즉, 데이터 계층 복사본을 두 개 생성하여 데이터를 공유하고 데이터베이스, 저장소 또는 디스크 간 실시간 마이그레이션을 구현합니다.

새 버전을 테스트하는 데 사용되는 데이터를 떠올려 보십시오. 데이터가 프로덕션 데이터라면 새 버전의 버그로 인해 프로덕션 버전에 장애가 발생할 수 있습니다.

9.4.2.1. Blue-Green 배포 사용
링크 복사

Blue-Green 배포에서는 두 개의 배포 구성을 사용합니다. 둘 다 실행 중이며 프로덕션의 하나는 경로에서 지정하는 서비스에 따라 다르며 각 배포 구성은 다른 서비스에 노출됩니다. 새 버전의 새 경로를 생성하고 테스트할 수 있습니다. 준비가 되면 새 서비스를 가리키도록 프로덕션 경로의 서비스를 변경하고 새, 파란색, 버전이 활성화됩니다.

필요한 경우 서비스를 이전 버전으로 다시 전환하여 이전 버전의 녹색으로 롤백할 수 있습니다.

경로 및 두 서비스 사용

이 예에서는 두 개의 배포 구성을 설정합니다. 하나는 안정적인 버전(Green 버전)이고 다른 하나는 최신 버전(Blue 버전)을 위한 것입니다.

경로는 서비스를 가리키며 언제든지 다른 서비스를 가리키도록 변경할 수 있습니다. 개발자는 프로덕션 트래픽이 라우팅되기 전에 새 서비스에 연결하여 새 버전의 코드를 테스트할 수 있습니다.

경로는 웹(HTTP 및 HTTPS) 트래픽을 위한 것이므로 이 기술은 웹 애플리케이션에 적합합니다.

예제 애플리케이션의 복사본 두 개를 생성합니다.
```
oc new-app openshift/deployment-example:v1 --name=example-green
oc new-app openshift/deployment-example:v2 --name=example-blue
```
```
$ oc new-app openshift/deployment-example:v1 --name=example-green
$ oc new-app openshift/deployment-example:v2 --name=example-blue
```
Copy to Clipboard Toggle word wrap
이렇게 하면 두 개의 독립적인 애플리케이션 구성 요소가 생성됩니다. 하나는 example-Green 서비스에서 v1 이미지를 실행하고 하나는 example-blue 서비스에서 v2 이미지를 사용합니다.
이전 서비스를 가리키는 경로를 생성합니다.
```
oc expose svc/example-green --name=bluegreen-example
```
```
$ oc expose svc/example-green --name=bluegreen-example
```
Copy to Clipboard Toggle word wrap
bluegreen-example.<project>.<router_domain >에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.
참고
v3.0.1 이전 버전의 OpenShift Container Platform에서 이 명령은 위의 위치가 아닌 example-green.<project>.<router_domain >에 경로를 생성합니다.

경로를 편집하고 서비스 이름을 example-blue 로 변경합니다.

oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-blue"}}}'

$ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-blue"}}}'

Copy to Clipboard

Toggle word wrap

경로가 변경되었는지 확인하려면 v2 이미지가 표시될 때까지 브라우저를 새로 고칩니다.

9.4.3. A/B 배포
링크 복사

A/B 배포 전략을 사용하면 프로덕션 환경에서 제한된 방식으로 새 버전의 애플리케이션을 시도할 수 있습니다. 프로덕션 버전에서 대부분의 사용자 요청을 가져오고 제한된 요청만 새 버전으로 이동하도록 지정할 수 있습니다. 각 버전에 대한 요청 부분을 제어하므로 테스트가 진행됨에 따라 새 버전에 대한 요청 수를 늘리고 결국 이전 버전의 사용을 중지할 수 있습니다. 각 버전의 요청 부하를 조정할 때 필요한 성능을 제공하기 위해 각 서비스의 Pod 수를 조정해야 할 수 있습니다.

소프트웨어 업그레이드 외에도 이 기능을 사용하여 사용자 인터페이스의 버전을 실험할 수 있습니다. 일부 사용자는 이전 버전을 보유하고 있고 일부는 새 버전을 보유하고 있기 때문에 다양한 버전에 대한 사용자의 반응을 평가하여 설계 결정을 알릴 수 있습니다.

이 기능이 효과적이려면 이전 버전과 새 버전이 동시에 실행될 수 있을 정도로 충분히 유사해야 합니다. 버그 수정 릴리즈 및 새 기능이 이전 기능을 방해하지 않는 경우 일반적으로 사용됩니다. 버전이 제대로 작동하려면 N-1 호환성 이 필요합니다.

OpenShift Container Platform은 웹 콘솔과 명령줄 인터페이스를 통해 N-1 호환성을 지원합니다.

9.4.3.1. A/B 테스트에 대한 로드 밸런싱
링크 복사

사용자는 여러 서비스를 사용하여 경로 를 설정합니다. 각 서비스는 애플리케이션의 버전을 처리합니다.

각 서비스에는 weight가 할당되고 각 서비스에 대한 일부 요청에는 service_weight을 sum_of_weights으로 나눈 값이 할당됩니다. 각 서비스의 weight는 서비스 끝점에 분배되므로 끝점 가중치의 합계는 서비스 weight입니다.

이 경로는 최대 4개의 서비스를 제공할 수 있습니다. 서비스 weight는 0~256 사이일 수 있습니다. weight 가 0 이면 새 요청이 서비스로 이동하지 않지만 기존 연결은 활성 상태로 유지됩니다. 서비스 weight가 0이 아닌 경우 각 끝점의 최소 weight는 1입니다. 이로 인해 끝점이 많은 서비스는 weight 가 원하는 것보다 높을 수 있습니다. 이 경우 Pod 수를 줄여 원하는 부하 분산 가중치 를 가져옵니다. 자세한 내용은 대체 백엔드 및 가중치 섹션을 참조하십시오.

웹 콘솔을 사용하면 사용자가 가중치를 설정하고 균형을 표시할 수 있습니다.

A/B 환경을 설정하려면 다음을 수행합니다.

애플리케이션 두 개를 생성하고 서로 다른 이름을 지정합니다. 각각 배포 구성을 생성합니다. 애플리케이션은 동일한 프로그램의 버전입니다. 하나는 일반적으로 현재 프로덕션 버전이며 다른 하나는 제안된 새 버전입니다.
```
oc new-app openshift/deployment-example1 --name=ab-example-a
oc new-app openshift/deployment-example2 --name=ab-example-b
```
```
$ oc new-app openshift/deployment-example1 --name=ab-example-a
$ oc new-app openshift/deployment-example2 --name=ab-example-b
```
Copy to Clipboard Toggle word wrap
서비스를 생성하기 위해 배포 구성을 노출합니다.
```
oc expose dc/ab-example-a --name=ab-example-A
oc expose dc/ab-example-b --name=ab-example-B
```
```
$ oc expose dc/ab-example-a --name=ab-example-A
$ oc expose dc/ab-example-b --name=ab-example-B
```
Copy to Clipboard Toggle word wrap
이 시점에서 두 애플리케이션이 모두 배포되고 실행 중이며 서비스가 있습니다.
경로를 통해 외부에서 애플리케이션을 사용할 수 있도록 설정합니다. 이 시점에서 두 서비스를 노출할 수 있습니다. 현재 프로덕션 버전을 공개하는 것이 편리합니다. 후자는 경로를 수정하여 새 버전을 추가할 수 있습니다.
```
oc expose svc/ab-example-A
```
```
$ oc expose svc/ab-example-A
```
Copy to Clipboard Toggle word wrap
ab-example.<project>.<router_domain >에서 애플리케이션을 검색하여 원하는 버전이 표시되는지 확인합니다.
경로를 배포할 때 라우터는 서비스에 지정된 가중치 에 따라 트래픽의 균형을 조정합니다. 이 시점에는 기본값인 weight=1 인 단일 서비스가 있으므로 모든 요청이 해당 서비스로 이동합니다. 다른 서비스를 alternateBackends 로 추가하고 가중치 를 조정하면 A/B 설정이 활성화됩니다. 이 작업은 oc set route-backends 명령을 실행하거나 경로를 편집하여 수행할 수 있습니다.
참고
경로를 변경하면 다양한 서비스에 대한 트래픽 부분만 변경됩니다. 예상되는 부하를 처리하기 위해 Pod 수를 조정하려면 배포 구성을 스케일링해야 할 수 있습니다.
경로를 편집하려면 다음을 실행합니다.
```
oc edit route <route-name>
```
```
$ oc edit route <route-name>
...
metadata:
  name: route-alternate-service
  annotations:
    haproxy.router.openshift.io/balance: roundrobin
spec:
  host: ab-example.my-project.my-domain
  to:
    kind: Service
    name: ab-example-A
    weight: 10
  alternateBackends:
  - kind: Service
    name: ab-example-B
    weight: 15
...
```
Copy to Clipboard Toggle word wrap

9.4.3.1.1. 웹 콘솔을 사용하여 가중치 관리
링크 복사

경로 세부 정보 페이지(Applications/Routes)로 이동합니다.
작업 메뉴에서 편집 을 선택합니다.
여러 서비스에서 트래픽 분할 을 확인합니다.
서비스 가중치 슬라이더는 각 서비스에 전송된 트래픽의 백분율을 설정합니다.

View larger image

두 개 이상의 서비스 간에 트래픽 분할의 경우 상대 가중치는 각 서비스에 대해 0에서 256 사이의 정수로 지정됩니다.

View larger image

트래픽 가중치는 트래픽이 분할되는 애플리케이션의 확장된 행에 있는 개요 에 표시됩니다.

9.4.3.1.2. CLI를 사용하여 가중치 관리
링크 복사

이 명령은 경로에 따라 균형 있는 서비스와 해당 가중치를 관리합니다.

oc set route-backends ROUTENAME [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

$ oc set route-backends ROUTENAME [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

Copy to Clipboard

Toggle word wrap

예를 들어, 다음은 ab-example-A 를 weight=198 및 ab-example-B 를 weight=2 를 사용하는 첫 번째 대체 서비스로 설정합니다.

oc set route-backends web ab-example-A=198 ab-example-B=2

$ oc set route-backends web ab-example-A=198 ab-example-B=2

Copy to Clipboard

Toggle word wrap

즉 99%의 트래픽이 서비스 ab-example-A 로 전송되고 1%는 서비스 ab-example-B 로 전송됩니다.

이 명령은 배포 구성을 스케일링하지 않습니다. 요청 부하를 처리할 수 있는 Pod가 충분한 경우 이를 수행해야 할 수 있습니다.

플래그 없이 명령을 실행하면 현재 구성이 표시됩니다.

oc set route-backends web

$ oc set route-backends web
NAME                    KIND     TO           WEIGHT
routes/web              Service  ab-example-A 198 (99%)
routes/web              Service  ab-example-B 2   (1%)

Copy to Clipboard

Toggle word wrap

--adjust 플래그를 사용하면 자체 또는 기본 서비스에 대한 개별 서비스의 가중치를 변경할 수 있습니다. 백분율을 지정하면 기본 또는 첫 번째 대체(기본을 지정하는 경우)를 기준으로 서비스가 조정됩니다. 다른 백엔드가 있는 경우 해당 가중치는 변경된 값에 비례하여 유지됩니다.

oc set route-backends web --adjust ab-example-A=200 ab-example-B=10
oc set route-backends web --adjust ab-example-B=5%
oc set route-backends web --adjust ab-example-B=+15%

$ oc set route-backends web --adjust ab-example-A=200 ab-example-B=10
$ oc set route-backends web --adjust ab-example-B=5%
$ oc set route-backends web --adjust ab-example-B=+15%

Copy to Clipboard

Toggle word wrap

--equal 플래그는 모든 서비스의 weight 를 100으로 설정합니다.

oc set route-backends web --equal

$ oc set route-backends web --equal

Copy to Clipboard

Toggle word wrap

--zero 플래그는 모든 서비스의 weight 를 0으로 설정합니다. 모든 요청은 503 오류와 함께 반환됩니다.

참고

일부 라우터에서는 다중 또는 가중치 적용 백엔드를 지원하지 않습니다.

9.4.3.1.3. 하나의 서비스, 여러 배포 구성
링크 복사

라우터가 설치된 경우 경로를 통해 애플리케이션을 사용할 수 있도록 합니다(또는 서비스 IP를 직접 사용).

oc expose svc/ab-example

$ oc expose svc/ab-example

Copy to Clipboard

Toggle word wrap

ab-example.<project>.<router_domain >에서 애플리케이션을 검색하여 v1 이미지가 표시되는지 확인합니다.

첫 번째 shard와 동일한 소스 이미지를 기반으로 두 번째 shard를 만들고 태그가 다른 버전을 지정하고 고유한 값을 설정합니다.

oc new-app openshift/deployment-example:v2 --name=ab-example-b --labels=ab-example=true SUBTITLE="shard B" COLOR="red"

$ oc new-app openshift/deployment-example:v2 --name=ab-example-b --labels=ab-example=true SUBTITLE="shard B" COLOR="red"

Copy to Clipboard

Toggle word wrap

새로 생성된 shard를 편집하여 모든 shard에 공통된 라벨 ab-example=true 를 설정합니다.
```
oc edit dc/ab-example-b
```
```
$ oc edit dc/ab-example-b
```
Copy to Clipboard Toggle word wrap
편집기에서 기존 deploymentconfig=ab-example-b 레이블과 함께 spec.selector 및 spec.template.metadata.labels 아래에 ab-example: "true" 행을 추가합니다. 편집기를 저장하고 종료합니다.
두 번째 shard의 재배포를 트리거하여 새 라벨을 선택합니다.
```
oc rollout latest dc/ab-example-b
```
```
$ oc rollout latest dc/ab-example-b
```
Copy to Clipboard Toggle word wrap
이 시점에 두 Pod 세트 모두 경로에 제공됩니다. 그러나 두 브라우저(연결을 열린 상태로 유지하여)와 라우터(기본적으로 쿠키를 통해)가 백엔드 서버에 대한 연결을 유지하려고 하므로 두 shard가 반환되는 것을 볼 수 없습니다. 브라우저를 하나 또는 다른 shard에 강제 적용하려면 scale 명령을 사용합니다.
```
oc scale dc/ab-example-a --replicas=0
```
```
$ oc scale dc/ab-example-a --replicas=0
```
Copy to Clipboard Toggle word wrap
브라우저를 새로 고치면 v2 및 shard B (빨간색)가 표시되어야 합니다.
```
oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
```
```
$ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0
```
Copy to Clipboard Toggle word wrap
브라우저를 새로 고치면 v1 및 shard A (파란색)가 표시되어야 합니다.
두 shard에서 배포를 트리거하면 해당 shard의 Pod만 영향을 받습니다. 배포 구성 oc edit dc/ab-example-a 또는 oc edit dc/ab-example-b 에서 SUBTITLE 환경 변수를 변경하여 배포를 쉽게 트리거할 수 있습니다. 5-7 단계를 반복하여 shard를 추가할 수 있습니다.
참고
이러한 단계는 향후 OpenShift Container Platform 버전에서 단순화됩니다.

9.4.4. 프록시 Shard / Traffic Splitter
링크 복사

프로덕션 환경에서는 특정 shard에 전달되는 트래픽 분배를 정확하게 제어할 수 있습니다. 많은 수의 인스턴스를 처리할 때는 개별 shard의 상대적 스케일을 사용하여 백분율 기반 트래픽을 구현할 수 있습니다. 이는 수신하는 트래픽을 다른 곳에서 실행되는 별도의 서비스 또는 애플리케이션으로 전달하거나 분할하는 프록시 shard 와 잘 결합합니다.

가장 간단한 구성에서 프록시는 변경되지 않은 요청을 전달합니다. 더 복잡한 설정에서는 들어오는 요청을 복제하여 애플리케이션의 로컬 인스턴스와 별도의 클러스터에 보내 결과를 비교할 수 있습니다. 기타 패턴에는 DR 설치 캐시를 준비 상태로 유지하거나 분석을 위해 들어오는 트래픽을 샘플링하는 작업이 포함됩니다.

구현은 이 예제의 범위를 벗어나지만 모든 TCP(또는 UDP) 프록시는 원하는 shard에서 실행될 수 있습니다. oc scale 명령을 사용하여 프록시 shard에서 요청을 처리하는 상대적 인스턴스 수를 변경합니다. 더 복잡한 트래픽 관리에는 비례 분산 기능을 사용하여 OpenShift Container Platform 라우터를 사용자 정의하는 것이 좋습니다.

9.4.5. N-1 호환성
링크 복사

새 코드와 이전 코드가 동시에 포함된 애플리케이션에서는 새 코드에서 작성한 데이터를 이전 버전의 코드에서 읽고 처리(또는 정상적으로 무시)할 수 있도록 주의해야 합니다. 이는 스키마 진화라고도 하며 복잡한 문제에 해당합니다.

이는 디스크, 데이터베이스, 임시 캐시 또는 사용자 브라우저 세션의 일부인 다양한 형태를 취할 수 있습니다. 대부분의 웹 애플리케이션에서는 롤링 배포를 지원할 수 있지만 이를 처리할 수 있도록 애플리케이션을 테스트하고 설계하는 것이 중요합니다.

일부 애플리케이션의 경우 이전 코드와 새 코드가 나란히 실행되는 기간이 짧기 때문에 버그 또는 일부 실패한 사용자 트랜잭션이 허용됩니다. 다른 애플리케이션의 경우 실패 패턴으로 인해 전체 애플리케이션이 작동하지 않을 수 있습니다.

N-1 호환성을 검증하는 한 가지 방법은 A/B 배포를 사용하는 것입니다. 테스트 환경에서 제어되는 방식으로 이전 코드와 새 코드를 동시에 실행하고 새 배포로 이동하는 트래픽이 이전 배포에 실패하지 않는지 확인합니다.

9.4.6. 정상적인 종료
링크 복사

OpenShift Container Platform 및 Kubernetes는 부하 분산 순환 작업에서 애플리케이션 인스턴스를 제거하기 전에 종료할 시간을 제공합니다. 그러나 애플리케이션은 종료하기 전에 사용자 연결을 명확하게 종료해야 합니다.

종료 시 OpenShift Container Platform은 컨테이너의 프로세스에 TERM 신호를 보냅니다. 애플리케이션 코드는 SIGTERM 을 수신하면 새 연결을 허용하지 않아야 합니다. 이렇게 하면 로드 밸런서가 트래픽을 활성 상태의 다른 인스턴스로 라우팅합니다. 그런 다음 애플리케이션 코드는 열려 있는 모든 연결이 닫힐 때까지 기다려야 합니다(또는 다음 기회에 개별 연결을 정상적으로 종료) 종료.

정상 종료 기간이 만료되면 종료되지 않은 프로세스가 KILL 신호가 전송되어 프로세스가 즉시 종료됩니다. Pod 또는 Pod 템플릿의 terminationGracePeriodSeconds 속성은 정상 종료 기간(기본값 30초)을 제어하고 필요에 따라 애플리케이션별로 사용자 지정할 수 있습니다.

9.5. Kubernetes 배포 지원
링크 복사

9.5.1. 배포 오브젝트 유형
링크 복사

Kubernetes는 deployments 라는 OpenShift Container Platform에서 최상위 오브젝트 유형을 제공합니다. 이 개체 유형은 구분을 위해 Kubernetes 배포로 참조되는 경우 배포 구성 개체 유형의 하위 항목입니다.

배포 구성과 마찬가지로 Kubernetes 배포는 특정 애플리케이션 구성 요소의 원하는 상태를 Pod 템플릿으로 설명합니다. Kubernetes 배포는 Pod 라이프사이클을 오케스트레이션하는 복제본 세트 ( 복제 컨트롤러반복)를 생성합니다.

예를 들어 Kubernetes 배포의 이 정의에서는 하나의 hello-openshift pod를 가져오는 복제본 세트를 생성합니다.

Kubernetes 배포 정의 hello-openshift-deployment.yaml의 예

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-openshift
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hello-openshift
  template:
    metadata:
      labels:
        app: hello-openshift
    spec:
      containers:
      - name: hello-openshift
        image: openshift/hello-openshift:latest
        ports:
        - containerPort: 80

Copy to Clipboard

Toggle word wrap

정의를 로컬 파일에 저장한 후 이를 사용하여 Kubernetes 배포를 생성할 수 있습니다.

oc create -f hello-openshift-deployment.yaml

$ oc create -f hello-openshift-deployment.yaml

Copy to Clipboard

Toggle word wrap

CLI를 사용하여 Common Operations 에 설명된 대로 Kubernetes 배포 및 복제본 세트(예: get 및 describe )를 검사하고 작동할 수 있습니다. 오브젝트 유형의 경우 배포를 사용하거나 Kubernetes 배포 및 복제본 세트 또는 rs 에 대해 복제본 세트를 배포합니다.

CLI 사용 예제에서 kubectl 에 대해 oc 를 대체하는 Deployments 및 Replica Sets 에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.

9.5.2. Kubernetes Deployments Versus 배포 구성
링크 복사

Kubernetes 1.2에 배포가 추가되기 전에 OpenShift Container Platform에 배포 구성이 존재하기 때문에 후자의 개체 유형은 이전과 약간 다릅니다. OpenShift Container Platform의 장기 목표는 Kubernetes 배포의 전체 기능 패리티에 도달하고 이를 애플리케이션에 대한 세밀한 관리를 제공하는 단일 개체 유형으로 전환하는 것입니다.

Kubernetes 배포는 OpenShift Container Platform에서 새 오브젝트 유형을 사용하는 업스트림 프로젝트 및 예제를 원활하게 실행할 수 있도록 지원됩니다. Kubernetes 배포의 현재 기능 세트에 따라 특히 다음을 사용하지 않는 경우 OpenShift Container Platform의 배포 구성 대신 해당 기능을 사용할 수 있습니다.

image streams
라이프사이클 후크
사용자 정의 배포 전략

다음 섹션에서는 두 오브젝트 유형의 차이점에 대해 자세히 설명하여 배포 구성을 통해 Kubernetes 배포를 사용할 시기를 결정하는 데 도움이 됩니다.

9.5.2.1. 배포 구성-특정 기능
링크 복사

9.5.2.1.1. 자동 롤백
링크 복사

Kubernetes 배포는 실패한 경우 성공적으로 배포된 마지막 복제본 세트로 자동 롤백을 지원하지 않습니다. 이 기능은 곧 추가해야 합니다.

9.5.2.1.2. Trigger
링크 복사

Kubernetes 배포에는 배포의 pod 템플릿이 변경될 때마다 새 롤아웃이 자동으로 트리거된다는 점에서 암시적 ConfigChange 트리거가 있습니다. Pod 템플릿 변경 시 새 롤아웃을 수행하지 않으려면 배포를 정지하십시오.

oc rollout pause deployments/<name>

$ oc rollout pause deployments/<name>

Copy to Clipboard

Toggle word wrap

현재 Kubernetes 배포는 ImageChange 트리거를 지원하지 않습니다. 일반 트리거 메커니즘이 업스트림에서 제안되었지만 수락할 수 있는 시기는 알 수 없습니다. 결국 OpenShift Container Platform 특정 메커니즘을 Kubernetes 배포 상단에 배치하도록 구현할 수 있지만 Kubernetes 코어의 일부로 존재하는 것이 더 바람직합니다.

9.5.2.1.3. 라이프사이클 후크
링크 복사

Kubernetes 배포는 라이프사이클 후크를 지원하지 않습니다.

9.5.2.1.4. 사용자 정의 전략
링크 복사

Kubernetes 배포는 아직 사용자가 지정하는 사용자 정의 배포 전략을 지원하지 않습니다.

9.5.2.1.5. 카나리아 배포
링크 복사

Kubernetes 배포는 아직 새 롤아웃의 일부로 실행되지 않습니다.

9.5.2.1.6. 테스트 배포
링크 복사

Kubernetes 배포는 실행 중인 테스트 경로를 지원하지 않습니다.

9.5.2.2. Kubernetes 배포별 기능
링크 복사

9.5.2.2.1. 롤오버
링크 복사

Kubernetes 배포의 배포 프로세스는 모든 새 롤아웃에 배포자 Pod를 사용하는 배포 구성과 달리 컨트롤러 루프에 의해 구동됩니다. 즉, Kubernetes 배포에 활성 복제본 세트가 가능한 한 많이 있을 수 있으며 결국 배포 컨트롤러에서 이전 복제본 세트를 축소하고 최신 복제본 세트를 확장합니다.

배포 구성은 최대 하나의 배포자 Pod를 실행할 수 있습니다. 그러지 않으면 여러 배포자가 최신 복제 컨트롤러라고 생각하는 것을 확장하려고 시도하게 됩니다. 이로 인해 어느 시점에 두 개의 복제 컨트롤러만 활성화할 수 있습니다. 결과적으로 Kubernetes 배포에 대한 빠른 롤아웃이 빨라집니다.

9.5.2.2.2. 비례 스케일링
링크 복사

Kubernetes 배포 컨트롤러는 배포에서 소유한 새 복제본 세트 및 이전 복제본 세트의 크기에 대한 유일한 정보 소스이므로 지속적인 롤아웃을 확장할 수 있습니다. 추가 복제본은 각 복제본 세트의 크기에 비례하여 배포됩니다.

롤아웃이 진행 중이면 배포 구성 컨트롤러가 새 복제 컨트롤러 크기에 대한 배포자 프로세스와 충돌하므로 배포 구성을 확장할 수 없습니다.

9.5.2.2.3. Mid-rollout 정지
링크 복사

Kubernetes 배포는 언제든지 정지할 수 있습니다. 즉, 진행 중인 롤아웃을 정지할 수도 있습니다. 반면 현재 배포자 Pod를 일시 중지할 수 없으므로 롤아웃 중 배포 구성을 일시 중지하려고 하면 배포자 프로세스에 영향을 받지 않고 완료될 때까지 계속됩니다.

10장. 템플릿
링크 복사

10.1. 개요
링크 복사

템플릿은 OpenShift Container Platform에서 생성할 오브젝트 목록을 생성하도록 매개 변수화 및 처리할 수 있는 오브젝트 세트를 설명합니다. 서비스(예: 서비스,빌드 구성, 배포 구성 등) 내에서 생성할 수 있는 권한이 있는 모든 항목을 템플릿을 처리하여 생성할 수 있습니다. 템플릿은 템플릿에 정의된 모든 오브젝트에 적용할 레이블 세트를 정의할 수도 있습니다.

CLI를 사용하거나 템플릿을 프로젝트 또는 글로벌 템플릿 라이브러리에 업로드한 경우 웹 콘솔을 사용하여 템플릿에서 오브젝트 목록을 생성할 수 있습니다. 선별된 템플릿 세트는 OpenShift 이미지 스트림 및 템플릿 라이브러리를 참조하십시오.

10.2. 템플릿 업로드
링크 복사

예를 들어 이 예제 와 같이 템플릿을 정의하는 JSON 또는 YAML 파일이 있는 경우 CLI를 사용하여 템플릿을 프로젝트에 업로드할 수 있습니다. 그러면 해당 프로젝트에 대한 적절한 액세스 권한이 있는 사용자가 반복해서 사용할 수 있도록 템플릿이 프로젝트에 저장됩니다. 자체 템플릿 작성에 대한 지침은 이 항목의 뒷부분에 제공되어 있습니다.

템플릿을 현재 프로젝트의 템플릿 라이브러리에 업로드하려면 다음 명령으로 JSON 또는 YAML 파일을 전달합니다.

oc create -f <filename>

$ oc create -f <filename>

Copy to Clipboard

Toggle word wrap

프로젝트 이름과 -n 옵션을 사용하여 템플릿을 다른 프로젝트에 업로드할 수 있습니다.

oc create -f <filename> -n <project>

$ oc create -f <filename> -n <project>

Copy to Clipboard

Toggle word wrap

이제 웹 콘솔 또는 CLI를 사용하여 템플릿을 선택할 수 있습니다.

10.3. 웹 콘솔을 사용하여 템플릿에서 생성
링크 복사

웹 콘솔을 사용하여 애플리케이션 생성을 참조하십시오.

10.4. CLI를 사용하여 템플릿에서 생성
링크 복사

CLI를 사용하여 템플릿을 처리하고 생성된 구성을 사용하여 오브젝트를 생성할 수 있습니다.

10.4.1. 라벨
링크 복사

레이블 은 Pod와 같이 생성된 오브젝트를 관리하고 구성하는 데 사용됩니다. 템플릿에 지정된 레이블은 템플릿에서 생성된 모든 오브젝트에 적용됩니다.

명령줄에서 템플릿에 레이블을 추가하는 기능도 있습니다.

oc process -f <filename> -l name=otherLabel

$ oc process -f <filename> -l name=otherLabel

Copy to Clipboard

Toggle word wrap

10.4.2. 매개 변수
링크 복사

덮어쓸 수 있는 매개변수 목록은 템플릿의parameters 섹션에 나열되어 있습니다. 다음 명령을 사용하여 사용할 파일을 지정하여 CLI로 나열할 수 있습니다.

oc process --parameters -f <filename>

$ oc process --parameters -f <filename>

Copy to Clipboard

Toggle word wrap

또는 템플릿이 이미 업로드된 경우 다음을 실행합니다.

oc process --parameters -n <project> <template_name>

$ oc process --parameters -n <project> <template_name>

Copy to Clipboard

Toggle word wrap

예를 들어 다음은 기본 openshift 프로젝트의 빠른 시작 템플릿 중 하나에 대한 매개변수를 나열하는 경우의 출력을 보여줍니다.

oc process --parameters -n openshift rails-postgresql-example

$ oc process --parameters -n openshift rails-postgresql-example
NAME                         DESCRIPTION                                                                                              GENERATOR           VALUE
SOURCE_REPOSITORY_URL        The URL of the repository with your application source code                                                                  https://github.com/sclorg/rails-ex.git
SOURCE_REPOSITORY_REF        Set this to a branch name, tag or other ref of your repository if you are not using the default branch
CONTEXT_DIR                  Set this to the relative path to your project if it is not in the root of your repository
APPLICATION_DOMAIN           The exposed hostname that will route to the Rails service                                                                    rails-postgresql-example.openshiftapps.com
GITHUB_WEBHOOK_SECRET        A secret string used to configure the GitHub webhook                                                     expression          [a-zA-Z0-9]{40}
SECRET_KEY_BASE              Your secret key for verifying the integrity of signed cookies                                            expression          [a-z0-9]{127}
APPLICATION_USER             The application user that is used within the sample application to authorize access on pages                                 openshift
APPLICATION_PASSWORD         The application password that is used within the sample application to authorize access on pages                             secret
DATABASE_SERVICE_NAME        Database service name                                                                                                        postgresql
POSTGRESQL_USER              database username                                                                                        expression          user[A-Z0-9]{3}
POSTGRESQL_PASSWORD          database password                                                                                        expression          [a-zA-Z0-9]{8}
POSTGRESQL_DATABASE          database name                                                                                                                root
POSTGRESQL_MAX_CONNECTIONS   database max connections                                                                                                     10
POSTGRESQL_SHARED_BUFFERS    database shared buffers                                                                                                      12MB

Copy to Clipboard

Toggle word wrap

출력에서는 템플릿이 처리될 때 생성기와 같이 정규식으로 생성되는 여러 매개변수를 식별합니다.

10.4.3. 오브젝트 목록 생성
링크 복사

CLI를 사용하면 템플릿 정의 파일을 처리하여 오브젝트 목록을 표준 출력으로 반환할 수 있습니다.

oc process -f <filename>

$ oc process -f <filename>

Copy to Clipboard

Toggle word wrap

또는 템플릿이 현재 프로젝트에 이미 업로드된 경우 다음을 실행합니다.

oc process <template_name>

$ oc process <template_name>

Copy to Clipboard

Toggle word wrap

템플릿을 처리하고 출력을 oc create 로 파이핑하여 템플릿에서 오브젝트를 생성할 수 있습니다.

oc process -f <filename> | oc create -f -

$ oc process -f <filename> | oc create -f -

Copy to Clipboard

Toggle word wrap

또는 템플릿이 현재 프로젝트에 이미 업로드된 경우 다음을 실행합니다.

oc process <template> | oc create -f -

$ oc process <template> | oc create -f -

Copy to Clipboard

Toggle word wrap

재정의하려는 각 < name>=<value> 쌍에 -p 옵션을 추가하여 파일에 정의된 매개변수 값을 덮어쓸 수 있습니다. 매개변수 참조는 템플릿 항목 내의 텍스트 필드에 표시될 수 있습니다.

예를 들어 다음에서는 템플릿의 POSTGRESQL_USER 및 POSTGRESQL_DATABASE 매개변수가 재정의되어 사용자 정의된 환경 변수가 있는 구성을 출력합니다.

예 10.1. 템플릿에서 오브젝트 목록을 생성합니다.

oc process -f my-rails-postgresql \
    -p POSTGRESQL_USER=bob \
    -p POSTGRESQL_DATABASE=mydatabase

$ oc process -f my-rails-postgresql \
    -p POSTGRESQL_USER=bob \
    -p POSTGRESQL_DATABASE=mydatabase

Copy to Clipboard

Toggle word wrap

JSON 파일은 처리된 출력을 oc create 명령으로 파이핑하여 템플릿을 업로드하지 않고 직접 적용하거나 파일로 리디렉션할 수 있습니다.

oc process -f my-rails-postgresql \
    -p POSTGRESQL_USER=bob \
    -p POSTGRESQL_DATABASE=mydatabase \
    | oc create -f -

$ oc process -f my-rails-postgresql \
    -p POSTGRESQL_USER=bob \
    -p POSTGRESQL_DATABASE=mydatabase \
    | oc create -f -

Copy to Clipboard

Toggle word wrap

많은 수의 매개변수가 있는 경우 파일에 저장한 후 해당 파일을 oc process로 전달할 수 있습니다.

cat postgres.env
POSTGRESQL_USER=bob
POSTGRESQL_DATABASE=mydatabase
oc process -f my-rails-postgresql --param-file=postgres.env

$ cat postgres.env
POSTGRESQL_USER=bob
POSTGRESQL_DATABASE=mydatabase
$ oc process -f my-rails-postgresql --param-file=postgres.env

Copy to Clipboard

Toggle word wrap

"-"를 --param-file의 인수로 사용하여 표준 출력에서 환경을 읽을 수도 있습니다.

sed s/bob/alice/ postgres.env | oc process -f my-rails-postgresql --param-file=-

$ sed s/bob/alice/ postgres.env | oc process -f my-rails-postgresql --param-file=-

Copy to Clipboard

Toggle word wrap

10.5. 업로드된 템플릿 수정
링크 복사

다음 명령을 사용하여 프로젝트에 이미 업로드된 템플릿을 편집할 수 있습니다.

oc edit template <template>

$ oc edit template <template>

Copy to Clipboard

Toggle word wrap

10.6. Instant App 및 빠른 시작 템플릿 사용
링크 복사

OpenShift Container Platform에서는 다양한 기본 Instant App 및 빠른 시작 템플릿을 제공하므로 다양한 언어를 위한 새 애플리케이션 생성을 쉽게 시작할 수 있습니다. Rails(Ruby), Django(Python), Node.js, CakePHP(PHP) 및 Dancer(Perl)에 대한 템플릿이 제공됩니다. 클러스터 관리자가 기본 글로벌 openshift 프로젝트에서 이러한 템플릿을 생성한 경우 해당 템플릿에 액세스할 수 있습니다. 다음을 사용하면 사용 가능한 기본 Instant App 및 빠른 시작 템플릿을 나열할 수 있습니다.

oc get templates -n openshift

$ oc get templates -n openshift

Copy to Clipboard

Toggle word wrap

사용할 수 없는 경우 클러스터 관리자에게 기본 이미지 스트림 및 템플릿 주제를 로드 하도록 지시합니다.

기본적으로 템플릿은 필요한 애플리케이션 코드가 포함된 GitHub 의 퍼블릭 소스 리포지터리를 사용하여 빌드합니다. 소스를 수정하고 자체 버전의 애플리케이션을 빌드하려면 다음을 수행해야 합니다.

템플릿의 기본 SOURCE_REPOSITORY_URL 매개변수에서 참조하는 리포지터리를 포크합니다.
템플릿에서 생성하는 경우 기본값 대신 포크를 지정하여 SOURCE_REPOSITORY_URL 매개변수 값을 재정의합니다.

이렇게 하면 템플릿에 의해 생성된 빌드 구성이 이제 애플리케이션 코드의 포크를 가리키므로 코드를 수정하고 원하는 대로 애플리케이션을 다시 빌드할 수 있습니다.

웹 콘솔을 사용하는 이 프로세스의 지침은 개발자를 위한 시작: 웹 콘솔 시작에서 제공됩니다.

참고

일부 Instant App 및 빠른 시작 템플릿은 데이터베이스 배포 구성을 정의합니다. 정의된 구성은 데이터베이스 컨텐츠에 ephemeral 스토리지를 사용합니다. 어떤 이유로든 데이터베이스 포드가 다시 시작되면 데이터베이스 데이터가 모두 손실되므로 이러한 템플릿은 설명용으로만 사용해야 합니다.

10.7. 템플릿 작성
링크 복사

애플리케이션의 모든 오브젝트를 쉽게 다시 생성할 수 있도록 새 템플릿을 정의할 수 있습니다. 템플릿은 일부 메타데이터와 함께 생성하는 오브젝트를 정의하여 해당 오브젝트 생성을 안내합니다.

예 10.2. Simple Template Object Definition (YAML)

apiVersion: v1
kind: Template
metadata:
  name: redis-template
  annotations:
    description: "Description"
    iconClass: "icon-redis"
    tags: "database,nosql"
objects:
- apiVersion: v1
  kind: Pod
  metadata:
    name: redis-master
  spec:
    containers:
    - env:
      - name: REDIS_PASSWORD
        value: ${REDIS_PASSWORD}
      image: dockerfile/redis
      name: master
      ports:
      - containerPort: 6379
        protocol: TCP
parameters:
- description: Password used for Redis authentication
  from: '[A-Z0-9]{8}'
  generate: expression
  name: REDIS_PASSWORD
labels:
  redis: master

apiVersion: v1
kind: Template
metadata:
  name: redis-template
  annotations:
    description: "Description"
    iconClass: "icon-redis"
    tags: "database,nosql"
objects:
- apiVersion: v1
  kind: Pod
  metadata:
    name: redis-master
  spec:
    containers:
    - env:
      - name: REDIS_PASSWORD
        value: ${REDIS_PASSWORD}
      image: dockerfile/redis
      name: master
      ports:
      - containerPort: 6379
        protocol: TCP
parameters:
- description: Password used for Redis authentication
  from: '[A-Z0-9]{8}'
  generate: expression
  name: REDIS_PASSWORD
labels:
  redis: master

Copy to Clipboard

Toggle word wrap

10.7.1. 설명
링크 복사

템플릿 설명은 템플릿의 기능을 사용자에게 알려주고 웹 콘솔에서 검색할 때 템플릿을 찾도록 도와줍니다. 템플릿 이름 이외의 추가 메타데이터는 선택사항이지만 있으면 유용합니다. 메타데이터에는 일반적인 설명 정보 외에도 태그 세트가 포함되어 있습니다. 유용한 태그에는 템플릿과 관련된 언어의 이름이 포함되어 있습니다(예: java, php, ruby 등).

예 10.3. 템플릿 설명 메타데이터

kind: Template
apiVersion: v1
metadata:
  name: cakephp-mysql-example 
  annotations:
    openshift.io/display-name: "CakePHP MySQL Example (Ephemeral)" 
    description: >-
      An example CakePHP application with a MySQL database. For more information
      about using this template, including OpenShift considerations, see
      https://github.com/sclorg/cakephp-ex/blob/master/README.md.


      WARNING: Any data stored will be lost upon pod destruction. Only use this
      template for testing." 
    openshift.io/long-description: >-
      This template defines resources needed to develop a CakePHP application,
      including a build configuration, application deployment configuration, and
      database deployment configuration.  The database is stored in
      non-persistent storage, so this configuration should be used for
      experimental purposes only. 
    tags: "quickstart,php,cakephp" 
    iconClass: icon-php 
    openshift.io/provider-display-name: "Red Hat, Inc." 
    openshift.io/documentation-url: "https://github.com/sclorg/cakephp-ex" 
    openshift.io/support-url: "https://access.redhat.com" 
message: "Your admin credentials are ${ADMIN_USERNAME}:${ADMIN_PASSWORD}"

kind: Template
apiVersion: v1
metadata:
  name: cakephp-mysql-example

1


  annotations:
    openshift.io/display-name: "CakePHP MySQL Example (Ephemeral)"

2


    description: >-
      An example CakePHP application with a MySQL database. For more information
      about using this template, including OpenShift considerations, see
      https://github.com/sclorg/cakephp-ex/blob/master/README.md.


      WARNING: Any data stored will be lost upon pod destruction. Only use this
      template for testing."

3


    openshift.io/long-description: >-
      This template defines resources needed to develop a CakePHP application,
      including a build configuration, application deployment configuration, and
      database deployment configuration.  The database is stored in
      non-persistent storage, so this configuration should be used for
      experimental purposes only.

4


    tags: "quickstart,php,cakephp"

5


    iconClass: icon-php

6


    openshift.io/provider-display-name: "Red Hat, Inc."

7


    openshift.io/documentation-url: "https://github.com/sclorg/cakephp-ex"

8


    openshift.io/support-url: "https://access.redhat.com"

9


message: "Your admin credentials are ${ADMIN_USERNAME}:${ADMIN_PASSWORD}"

10

Copy to Clipboard

Toggle word wrap

1: 템플릿의 고유한 이름입니다.
2: 사용자 인터페이스에서 사용할 수 있는 간단하고 사용자에게 친숙한 이름입니다.
3: 템플릿에 대한 설명입니다. 사용자가 배포 사항을 이해할 수 있도록 충분한 세부 정보와 배포 전에 알아야 할 경고 사항을 포함합니다. README 파일과 같은 추가 정보에 대한 링크도 제공해야 합니다. 단락을 생성하기 위해 줄 바꿈이 포함될 수 있습니다.
4: 추가 템플릿 설명입니다. 예를 들어 서비스 카탈로그에 의해 표시될 수 있습니다.
5: 검색 및 그룹화에 필요한 템플릿과 연관된 태그입니다. 제공된 카탈로그 카테고리 중 하나에 포함할 태그를 추가합니다. 콘솔 상수 파일에 있는 CATALOG_CATEGORIES 의 id 및 categoryAliases 를 참조합니다. 카테고리는 전체 클러스터에 맞게 사용자 지정할 수도 있습니다.
6: 웹 콘솔에서 템플릿과 함께 표시되는 아이콘입니다. 가능한 경우 기존 로고 아이콘 중에서 선택합니다. FontAwesome 및 PatternFly 의 아이콘을 사용할 수도 있습니다. 또는 템플릿을 사용하는 OpenShift Container Platform 클러스터에 추가할 수 있는 CSS 사용자 정의를 통해 아이콘을 제공합니다. 존재하는 아이콘 클래스를 지정해야 합니다. 지정하지 않으면 일반 아이콘으로 대체되지 않습니다.
7: 템플릿을 제공하는 사람 또는 조직의 이름입니다.
8: 템플릿에 대한 추가 문서를 참조하는 URL입니다.
9: 템플릿에 대한 지원을 받을 수 있는 URL입니다.
10: 이 템플릿이 인스턴스화될 때 표시되는 지시 메시지입니다. 이 필드는 새로 생성된 리소스 사용 방법을 사용자에게 알려주어야 합니다. 생성된 인증 정보 및 기타 매개변수가 출력에 포함될 수 있도록 표시 전에 메시지에서 매개변수 대체가 수행됩니다. 사용자가 따라야 하는 다음 단계 문서에 대한 링크를 포함합니다.

10.7.2. 라벨
링크 복사

템플릿에는 레이블 세트가 포함될 수 있습니다. 이러한 레이블은 템플릿이 인스턴스화될 때 생성되는 각 오브젝트에 추가됩니다. 이런 방식으로 레이블을 정의하면 사용자가 특정 템플릿에서 생성된 모든 오브젝트를 쉽게 찾아서 관리할 수 있습니다.

예 10.4. 템플릿 오브젝트 레이블

kind: "Template"
apiVersion: "v1"
...
labels:
  template: "cakephp-mysql-example" 
  app: "${NAME}"

kind: "Template"
apiVersion: "v1"
...
labels:
  template: "cakephp-mysql-example"

1


  app: "${NAME}"

2

Copy to Clipboard

Toggle word wrap

1: 이 템플릿에서 생성된 모든 오브젝트에 적용되는 레이블입니다.
2: 이 템플릿에서 생성된 모든 오브젝트에 적용되는 매개변수화된 레이블입니다. 매개변수 확장은 레이블 키와 값 둘 다에서 수행됩니다.

10.7.3. 매개 변수
링크 복사

매개변수를 사용하면 값을 사용자가 제공하도록 할 수도 있고 템플릿이 인스턴스화될 때 생성되도록 할 수도 있습니다. 그러면 해당 값이 매개변수가 참조될 때마다 대체됩니다. 참조는 오브젝트 목록 필드의 어떤 필드에서든 정의할 수 있습니다. 임의의 암호를 생성하거나 사용자가 템플릿을 사용자 정의하는 데 필요한 호스트 이름 또는 기타 사용자 특정 값을 제공할 수 있도록 하는 데 유용합니다. 매개변수는 다음 두 가지 방법으로 참조할 수 있습니다.

템플릿에 있는 임의의 문자열 필드에 ${PARAMETER_NAME} 형식의 값을 배치하여 문자열 값으로 참조합니다.
템플릿에서 임의의 필드 대신 ${{PARAMETER_NAME}} 형식의 값을 배치하여 json/yaml 값으로 참조합니다.

${PARAMETER_NAME} 구문을 사용하는 경우 여러 매개변수 참조가 단일 필드에서 결합될 수 있으며 참조는 "http://${PARAMETER_1}${PARAMETER_2}" 같이 고정된 데이터에 내에 포함될 수 있습니다. 매개변수 값이 둘 다 대체되며 결과 값은 인용된 문자열이 됩니다.

${{PARAMETER_NAME}} 구문을 사용하는 경우 단일 매개변수 참조만 허용되며 선행/후행 문자는 허용되지 않습니다. 대체가 수행된 후 결과가 유효한 json 오브젝트인 경우 결과 값이 인용되지 않습니다. 결과가 유효한 json 값이 아닌 경우 결과 값이 인용되고 표준 문자열로 처리됩니다.

단일 매개변수는 템플릿 내에서 여러 번 참조될 수 있으며 단일 템플릿 내에서 두 대체 구문을 사용하여 참조될 수도 있습니다.

사용자가 다른 값을 제공하지 않은 경우 사용되는 기본값을 제공할 수 있습니다.

예 10.5. Explicit 값을 기본값으로 설정

parameters:
  - name: USERNAME
    description: "The user name for Joe"
    value: joe

parameters:
  - name: USERNAME
    description: "The user name for Joe"
    value: joe

Copy to Clipboard

Toggle word wrap

매개변수 값은 매개변수 정의에 지정된 규칙을 기반으로 생성할 수도 있습니다.

예 10.6. 매개 변수 값 생성

parameters:
  - name: PASSWORD
    description: "The random user password"
    generate: expression
    from: "[a-zA-Z0-9]{12}"

parameters:
  - name: PASSWORD
    description: "The random user password"
    generate: expression
    from: "[a-zA-Z0-9]{12}"

Copy to Clipboard

Toggle word wrap

위의 예에서 처리가 완료되면 모든 대문자 및 소문자 영문자와 숫자로 구성된 12자 길이의 임의의 암호가 생성됩니다.

사용 가능한 구문은 완전한 정규식 구문이 아닙니다. 하지만 \w, \d 및 \a 한정자를 사용할 수 있습니다.

[\W]{10} 은 10개의 영문자, 숫자 및 밑줄을 생성합니다. PCRE 표준을 따르며 [a-zA-Z0-9_]{10} 과 같습니다.
[\d]{10} 은 10개의 숫자를 생성합니다. [0-9]{10} 과 같습니다.
[\a]{10} 은 10개의 알파벳 문자를 생성합니다. [a-zA-Z]{10} 과 같습니다.

다음은 매개변수 정의 및 참조가 포함된 전체 템플릿의 예입니다.

예 10.7. 매개변수 정의 및 참조가 포함된 전체 템플릿

kind: Template
apiVersion: v1
metadata:
  name: my-template
objects:
  - kind: BuildConfig
    apiVersion: v1
    metadata:
      name: cakephp-mysql-example
      annotations:
        description: Defines how to build the application
    spec:
      source:
        type: Git
        git:
          uri: "${SOURCE_REPOSITORY_URL}" 
          ref: "${SOURCE_REPOSITORY_REF}"
        contextDir: "${CONTEXT_DIR}"
  - kind: DeploymentConfig
    apiVersion: v1
    metadata:
      name: frontend
    spec:
      replicas: "${{REPLICA_COUNT}}" 
parameters:
  - name: SOURCE_REPOSITORY_URL 
    displayName: Source Repository URL 
    description: The URL of the repository with your application source code 
    value: https://github.com/sclorg/cakephp-ex.git 
    required: true 
  - name: GITHUB_WEBHOOK_SECRET
    description: A secret string used to configure the GitHub webhook
    generate: expression 
    from: "[a-zA-Z0-9]{40}" 
  - name: REPLICA_COUNT
    description: Number of replicas to run
    value: "2"
    required: true
message: "... The GitHub webhook secret is ${GITHUB_WEBHOOK_SECRET} ..."

kind: Template
apiVersion: v1
metadata:
  name: my-template
objects:
  - kind: BuildConfig
    apiVersion: v1
    metadata:
      name: cakephp-mysql-example
      annotations:
        description: Defines how to build the application
    spec:
      source:
        type: Git
        git:
          uri: "${SOURCE_REPOSITORY_URL}"

1


          ref: "${SOURCE_REPOSITORY_REF}"
        contextDir: "${CONTEXT_DIR}"
  - kind: DeploymentConfig
    apiVersion: v1
    metadata:
      name: frontend
    spec:
      replicas: "${{REPLICA_COUNT}}"

2


parameters:
  - name: SOURCE_REPOSITORY_URL

3


    displayName: Source Repository URL

4


    description: The URL of the repository with your application source code

5


    value: https://github.com/sclorg/cakephp-ex.git

6


    required: true

7


  - name: GITHUB_WEBHOOK_SECRET
    description: A secret string used to configure the GitHub webhook
    generate: expression

8


    from: "[a-zA-Z0-9]{40}"

9


  - name: REPLICA_COUNT
    description: Number of replicas to run
    value: "2"
    required: true
message: "... The GitHub webhook secret is ${GITHUB_WEBHOOK_SECRET} ..."

10

Copy to Clipboard

Toggle word wrap

1: 이 값은 템플릿이 인스턴스화될 때 SOURCE_REPOSITORY_URL 매개변수 값으로 교체됩니다.
2: 이 값은 템플릿이 인스턴스화될 때 인용되지 않은 REPLICA_COUNT 매개변수 값으로 교체됩니다.
3: 매개변수의 이름입니다. 이 값은 템플릿 내에서 매개변수를 참조하는 데 사용됩니다.
4: 사용자에게 친숙한 매개변수 이름입니다. 사용자에게 표시됩니다.
5: 매개변수에 대한 설명입니다. 예상 값에 대한 제약 조건을 비롯하여 매개변수의 목적에 대한 자세한 정보를 제공합니다. 설명은 콘솔의 텍스트 표준을 따르는 완전한 문장을 사용해야 합니다. 표시 이름과 중복되지 마십시오.
6: 템플릿을 인스턴스화할 때 사용자가 값을 재정의하지 않는 경우 사용되는 매개변수의 기본값입니다. 암호 등에 기본값을 사용하지 말고 생성된 매개변수를 시크릿과 조합하여 사용하십시오.
7: 이 매개변수가 필수임을 나타냅니다. 즉, 사용자가 빈 값으로 이 매개변수를 재정의할 수 없습니다. 매개변수가 기본값 또는 생성된 값을 제공하지 않으면 사용자가 값을 제공해야 합니다.
8: 값이 생성되어 있는 매개변수입니다.
9: 생성기에 대한 입력입니다. 이 경우 생성기는 대문자 및 소문자를 포함하여 40자 길이의 영숫자 값을 생성합니다.
10: 매개변수가 템플릿 메시지에 포함될 수 있습니다. 사용자에게 생성된 값에 대해 알려줍니다.

10.7.4. 오브젝트 목록
링크 복사

템플릿의 주요 부분은 템플릿이 인스턴스화될 때 생성되는 오브젝트 목록입니다. BuildConfig,DeploymentConfig,Service 등 모든 유효한 API 오브젝트 일 수 있습니다. 오브젝트는 정확히 여기에 정의된 대로 생성되며 매개변수 값은 생성 전에 대체됩니다. 이러한 오브젝트 정의는 앞에서 정의한 매개변수를 참조할 수 있습니다.

kind: "Template"
apiVersion: "v1"
metadata:
  name: my-template
objects:
  - kind: "Service" 
    apiVersion: "v1"
    metadata:
      name: "cakephp-mysql-example"
      annotations:
        description: "Exposes and load balances the application pods"
    spec:
      ports:
        - name: "web"
          port: 8080
          targetPort: 8080
      selector:
        name: "cakephp-mysql-example"

kind: "Template"
apiVersion: "v1"
metadata:
  name: my-template
objects:
  - kind: "Service"

1


    apiVersion: "v1"
    metadata:
      name: "cakephp-mysql-example"
      annotations:
        description: "Exposes and load balances the application pods"
    spec:
      ports:
        - name: "web"
          port: 8080
          targetPort: 8080
      selector:
        name: "cakephp-mysql-example"

Copy to Clipboard

Toggle word wrap

1: 이 템플릿에서 생성할 Service의 정의입니다.

참고

오브젝트 정의 메타데이터에 고정된 namespace 필드 값이 포함된 경우 템플릿을 인스턴스화하는 동안 이 필드가 정의에서 제거됩니다. namespace 필드에 매개변수 참조가 포함되어 있는 경우 사용자가 해당 네임스페이스에서 오브젝트를 생성할 수 있는 권한이 있다고 가정하면 매개변수 대체가 값을 해석한 모든 네임스페이스에서 일반 매개변수 대체가 수행되고 오브젝트가 생성됩니다.

10.7.5. 템플릿을 바인딩 가능으로 표시
링크 복사

템플릿 서비스 브로커는 해당 카탈로그에서 인식하는 템플릿 오브젝트마다 하나의 서비스를 알립니다. 기본적으로 이러한 각 서비스는 "바인드 가능" 상태로 알려집니다. 즉, 일반 사용자가 프로비저닝된 서비스에 대해 바인딩할 수 있습니다.

템플릿 작성자는 template.openshift.io/bindable: "false" 주석을 템플릿에 추가하여 최종 사용자가 지정된 템플릿에서 프로비저닝된 서비스에 대해 바인딩하지 못하도록 할 수 있습니다.

10.7.6. 오브젝트 필드 노출
링크 복사

템플릿 작성자는 템플릿의 특정 오브젝트 필드가 노출되어야 함을 나타낼 수 있습니다. 템플릿 서비스 브로커는 ConfigMap, Secret, Service, Route 오브젝트에서 노출된 필드를 인식하고, 브로커가 지원하는 서비스를 사용자가 바인딩할 때 노출된 필드의 값을 반환합니다.

오브젝트의 필드를 하나 이상 노출하려면 template.openshift.io/expose- 또는 template.openshift.io/base64-expose-로 접두사를 붙인 주석을 템플릿의 오브젝트에 추가합니다.

접두사가 제거된 각 주석 키는 전달되어 bind 응답의 키가 됩니다.

각 주석 값은 Kubernetes JSONPath 표현식 이며, 바인딩 시 이를 해석하여 bind 응답에서 값을 반환해야 하는 오브젝트 필드를 나타냅니다.

참고

Bind 응답 키/값 쌍은 시스템의 다른 부분에서 환경 변수로 사용될 수 있습니다. 따라서 접두사가 제거된 모든 주석 키는 유효한 환경 변수 이름( A-Z,a-z, 밑줄)을 사용하여 유효한 환경 변수 이름이어야 하며 뒤에 A-Z,a-z,0-9 또는 underscore가 있어야 합니다.

template.openshift.io/expose- 주석을 사용하여 필드 값을 문자열로 반환합니다. 이 주석을 사용하면 임의의 바이너리 데이터를 처리하지는 않지만 편리합니다. 바이너리 데이터를 반환하려면 template.openshift.io/base64-expose- 주석을 사용하여 데이터를 반환하기 전에 base64로 인코딩합니다.

참고

백슬래시로 이스케이프되지 않으면 Kubernetes JSONPath 구현에서는 ., @ 및 메타 문자와 같은 기타 문자를 표현식 내 위치에 관계없이 문자로 해석합니다. 따라서 예를 들어 my.key라는 ConfigMap 데이터를 참조하기 위해 필요한 JSONPath 표현식은 {.data['my\.key']}입니다. JSONPath 표현식이 YAML로 작성되는 방법에 따라 추가 백슬래시가 필요할 수도 있습니다(예: "{.data['my\\.key']}").

다음은 노출되는 다양한 오브젝트 필드의 예입니다.

kind: Template
apiVersion: v1
metadata:
  name: my-template
objects:
- kind: ConfigMap
  apiVersion: v1
  metadata:
    name: my-template-config
    annotations:
      template.openshift.io/expose-username: "{.data['my\\.username']}"
  data:
    my.username: foo
- kind: Secret
  apiVersion: v1
  metadata:
    name: my-template-config-secret
    annotations:
      template.openshift.io/base64-expose-password: "{.data['password']}"
  stringData:
    password: bar
- kind: Service
  apiVersion: v1
  metadata:
    name: my-template-service
    annotations:
      template.openshift.io/expose-service_ip_port: "{.spec.clusterIP}:{.spec.ports[?(.name==\"web\")].port}"
  spec:
    ports:
    - name: "web"
      port: 8080
- kind: Route
  apiVersion: v1
  metadata:
    name: my-template-route
    annotations:
      template.openshift.io/expose-uri: "http://{.spec.host}{.spec.path}"
  spec:
    path: mypath

kind: Template
apiVersion: v1
metadata:
  name: my-template
objects:
- kind: ConfigMap
  apiVersion: v1
  metadata:
    name: my-template-config
    annotations:
      template.openshift.io/expose-username: "{.data['my\\.username']}"
  data:
    my.username: foo
- kind: Secret
  apiVersion: v1
  metadata:
    name: my-template-config-secret
    annotations:
      template.openshift.io/base64-expose-password: "{.data['password']}"
  stringData:
    password: bar
- kind: Service
  apiVersion: v1
  metadata:
    name: my-template-service
    annotations:
      template.openshift.io/expose-service_ip_port: "{.spec.clusterIP}:{.spec.ports[?(.name==\"web\")].port}"
  spec:
    ports:
    - name: "web"
      port: 8080
- kind: Route
  apiVersion: v1
  metadata:
    name: my-template-route
    annotations:
      template.openshift.io/expose-uri: "http://{.spec.host}{.spec.path}"
  spec:
    path: mypath

Copy to Clipboard

Toggle word wrap

위의 부분적인 템플릿을 기반으로 하는 bind 작업에 대한 응답 예는 다음과 같습니다.

{
  "credentials": {
    "username": "foo",
    "password": "YmFy",
    "service_ip_port": "172.30.12.34:8080",
    "uri": "http://route-test.router.default.svc.cluster.local/mypath"
  }
}

{
  "credentials": {
    "username": "foo",
    "password": "YmFy",
    "service_ip_port": "172.30.12.34:8080",
    "uri": "http://route-test.router.default.svc.cluster.local/mypath"
  }
}

Copy to Clipboard

Toggle word wrap

10.7.7. 템플릿 준비 상태 대기
링크 복사

템플릿 작성자는 템플릿 내의 특정 오브젝트가 일정 시간 대기한 뒤에 서비스 카탈로그, Template Service Broker 또는 TemplateInstance API의 템플릿 인스턴스화가 완료된 것으로 간주된다고 표시할 수 있습니다.

이 기능을 사용하려면 템플릿에서 다음 주석으로 하나 이상의 오브젝트를 Build, BuildConfig, Deployment, DeploymentConfig, Job 또는 StatefulSet 유형으로 표시하십시오.

"template.alpha.openshift.io/wait-for-ready": "true"

"template.alpha.openshift.io/wait-for-ready": "true"

Copy to Clipboard

Toggle word wrap

이 주석이 표시된 모든 오브젝트가 준비되었다고 보고할 때까지 템플릿 인스턴스화는 완료되지 않습니다. 마찬가지로 주석이 있는 오브젝트 보고서 중 실패하는 보고서가 있거나 템플릿이 1시간이라는 고정된 제한 시간 내에 준비되지 않으면 템플릿 인스턴스화가 실패합니다.

인스턴스화를 위해 각 오브젝트 유형의 준비 및 실패는 다음과 같이 정의됩니다.

Expand

유형	준비	실패
`Build`	오브젝트가 완료 단계 보고	오브젝트가 취소, 오류 또는 실패 단계 보고
`BuildConfig`	관련된 최신 Build 오브젝트가 완료 단계 보고	관련된 최신 Build 오브젝트가 취소, 오류 또는 실패 단계 보고
`Deployment`	오브젝트가 사용 가능한 새로운 ReplicaSet 및 배포를 보고(오브젝트에 정의된 readiness 프로브 준수)	오브젝트가 진행 상태를 False로 보고
`DeploymentConfig`	오브젝트가 사용 가능한 새로운 ReplicationController 및 배포를 보고(오브젝트에 정의된 readiness 프로브 준수)	오브젝트가 진행 상태를 False로 보고
`Job`	오브젝트가 완료 보고	오브젝트가 하나 이상의 실패가 발생했음을 보고
`StatefulSet`	오브젝트가 모든 복제본이 준비되었다고 보고(오브젝트에 정의된 readiness 프로브 준수)	해당 없음

다음은 wait-for-ready 주석을 사용하는 템플릿 추출의 예입니다. 더 많은 예를 보려면 OpenShift 빠른 시작 템플릿에서 찾을 수 있습니다.

kind: Template
apiVersion: v1
metadata:
  name: my-template
objects:
- kind: BuildConfig
  apiVersion: v1
  metadata:
    name: ...
    annotations:
      # wait-for-ready used on BuildConfig ensures that template instantiation
      # will fail immediately if build fails
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: DeploymentConfig
  apiVersion: v1
  metadata:
    name: ...
    annotations:
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: Service
  apiVersion: v1
  metadata:
    name: ...
  spec:
    ...

kind: Template
apiVersion: v1
metadata:
  name: my-template
objects:
- kind: BuildConfig
  apiVersion: v1
  metadata:
    name: ...
    annotations:
      # wait-for-ready used on BuildConfig ensures that template instantiation
      # will fail immediately if build fails
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: DeploymentConfig
  apiVersion: v1
  metadata:
    name: ...
    annotations:
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: Service
  apiVersion: v1
  metadata:
    name: ...
  spec:
    ...

Copy to Clipboard

Toggle word wrap

10.7.8. 기타 권장 사항
링크 복사

메모리, CPU 및 스토리지 기본 크기를 설정하여 애플리케이션에 원활한 실행을 위한 리소스가 충분히 부여되도록 합니다.
latest 태그가 주요 버전 간에 사용되는 경우 이미지의 해당 태그를 참조하지 마십시오. 새 이미지를 해당 태그로 푸시하면 실행 중인 애플리케이션이 중단될 수도 있습니다.
좋은 템플릿은 템플릿 배포 후 수정할 필요 없이 깔끔하게 빌드되고 배포됩니다.

10.7.9. 기존 오브젝트에서 템플릿 생성
링크 복사

전체 템플릿을 처음부터 작성하지 않고 프로젝트의 기존 오브젝트를 템플릿 형식으로 내보낸 다음 매개변수 및 기타 사용자 정의를 추가하여 해당 템플릿에서 템플릿을 수정할 수 있습니다. 프로젝트의 오브젝트를 템플릿 형식으로 내보내려면 다음을 실행합니다.

oc export all --as-template=<template_name> > <template_filename>

$ oc export all --as-template=<template_name> > <template_filename>

Copy to Clipboard

Toggle word wrap

all을 사용하지 않고 특정 리소스 유형 또는 여러 리소스를 대체할 수도 있습니다. 더 많은 예를 보려면 oc export -h 를 실행합니다.

oc export all 에 포함된 오브젝트 유형은 다음과 같습니다.

BuildConfig
Build
DeploymentConfig
ImageStream
포드
ReplicationController
Route
서비스

11장. 컨테이너에 대한 원격 쉘 열기
링크 복사

11.1. 개요
링크 복사

oc rsh 명령을 사용하면 시스템에 있는 툴에 로컬로 액세스하고 관리할 수 있습니다. SSH(Secure Shell)는 애플리케이션에 보안 연결을 제공하는 기본 기술 및 업계 표준입니다. 쉘 환경을 사용하여 애플리케이션에 대한 액세스는 SELinux(Security- Enhanced Linux) 정책으로 보호 및 제한됩니다.

11.2. 보안 쉘 세션 시작
링크 복사

컨테이너에 대한 원격 쉘 세션을 엽니다.

oc rsh <pod>

$ oc rsh <pod>

Copy to Clipboard

Toggle word wrap

원격 쉘에서는 컨테이너 내부에 있는 것처럼 명령을 실행하고 컨테이너에서 실행 중인 항목과 관련된 CLI 명령 모니터링, 디버깅 및 사용과 같은 로컬 작업을 수행할 수 있습니다.

예를 들어 MySQL 컨테이너에서는 mysql 명령을 호출한 다음 프롬프트를 사용하여 SELECT 명령에 입력하여 데이터베이스의 레코드 수를 계산할 수 있습니다. 검증을 위해 ps(1) 및 ls(1) 와 같은 명령을 사용할 수도 있습니다.

BuildConfigs 및 DeployConfigs 는 필요한 대로 컨테이너를 보고 해제하는 방법을 매핑합니다. 변경 사항은 유지되지 않습니다. 컨테이너 내에서 직접 변경하고 컨테이너가 제거되고 다시 작성되면 변경 사항이 더 이상 존재하지 않습니다.

참고

oc exec 를 사용하여 원격으로 명령을 실행할 수 있습니다. 그러나 oc rsh 명령은 원격 쉘을 영구적으로 열린 상태로 유지하는 더 쉬운 방법을 제공합니다.

11.3. Secure Shell 세션 도움말
링크 복사

사용법, 옵션 및 예제를 보려면 다음을 참조하십시오.

oc rsh -h

$ oc rsh -h

Copy to Clipboard

Toggle word wrap

12장. 서비스 계정
링크 복사

12.1. 개요
링크 복사

사용자가 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하는 경우 해당 API 토큰은 OpenShift API에 인증합니다. 그러나 일반 사용자의 인증 정보를 사용할 수 없는 경우 구성 요소가 API를 독립적으로 호출하는 것이 일반적입니다. 예를 들어 다음과 같습니다.

복제 컨트롤러는 Pod를 생성하거나 삭제하기 위해 API를 호출합니다.
컨테이너 내부의 애플리케이션에서 검색을 위해 API를 호출할 수 있습니다.
외부 애플리케이션은 모니터링 또는 통합을 위해 API를 호출할 수 있습니다.

서비스 계정을 사용하면 일반 사용자의 자격 증명을 공유하지 않고도 API 액세스 권한을 유연하게 제어할 수 있습니다.

12.2. 사용자 이름 및 그룹
링크 복사

모든 서비스 계정에는 일반 사용자와 마찬가지로 역할을 부여할 수 있는 관련 사용자 이름이 있습니다. 사용자 이름은 프로젝트와 이름에서 파생됩니다.

system:serviceaccount:<project>:<name>

system:serviceaccount:<project>:<name>

Copy to Clipboard

Toggle word wrap

예를 들어 top-secret 프로젝트의 robot 서비스 계정에 view 역할을 추가하려면 다음을 수행합니다.

oc policy add-role-to-user view system:serviceaccount:top-secret:robot

$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot

Copy to Clipboard

Toggle word wrap

중요

프로젝트의 특정 서비스 계정에 대한 액세스 권한을 부여하려면 -z 플래그를 사용할 수 있습니다. 서비스 계정이 속하는 프로젝트에서 -z 플래그를 사용하고 < serviceaccount_name>을 지정합니다. 오타를 방지하고 지정된 서비스 계정에만 액세스 권한을 부여할 수 있으므로 이 방법은 매우 권장됩니다. 예를 들어 다음과 같습니다.

oc policy add-role-to-user <role_name> -z <serviceaccount_name>

 $ oc policy add-role-to-user <role_name> -z <serviceaccount_name>

Copy to Clipboard

Toggle word wrap

프로젝트에 없는 경우 아래 예제와 같이 -n 옵션을 사용하여 적용되는 프로젝트 네임스페이스를 나타냅니다.

모든 서비스 계정은 다음 두 그룹의 멤버이기도 합니다.

system:serviceaccount: 시스템의 모든 서비스 계정이 포함됩니다.
system:serviceaccount:<project>: 지정된 프로젝트의 모든 서비스 계정이 포함됩니다.

예를 들어 모든 프로젝트의 모든 서비스 계정에서 top-secret 프로젝트의 리소스를 볼 수 있도록 하려면 다음을 실행합니다.

oc policy add-role-to-group view system:serviceaccount -n top-secret

$ oc policy add-role-to-group view system:serviceaccount -n top-secret

Copy to Clipboard

Toggle word wrap

managers 프로젝트의 모든 서비스 계정에서 top-secret 프로젝트의 리소스를 편집할 수 있도록 하려면 다음을 수행합니다.

oc policy add-role-to-group edit system:serviceaccount:managers -n top-secret

$ oc policy add-role-to-group edit system:serviceaccount:managers -n top-secret

Copy to Clipboard

Toggle word wrap

12.3. 기본 서비스 계정 및 역할
링크 복사

모든 프로젝트에서 세 개의 서비스 계정이 자동으로 생성됩니다.

Expand

서비스 계정	사용법
builder	빌드 Pod에서 사용합니다. 내부 Docker 레지스트리를 사용하여 프로젝트의 이미지 스트림으로 이미지를 푸시할 수 있는 system:image-builder 역할이 제공됩니다.
deployer	배포 Pod에서 사용하며 system:deployer 역할에 따라 프로젝트에서 복제 컨트롤러 및 Pod를 보고 수정할 수 있습니다.
default	다른 서비스 계정을 지정하지 않는 한 기타 모든 Pod를 실행하는 데 사용합니다.

프로젝트의 모든 서비스 계정에는 system:image-puller 역할이 부여되어 내부 Docker 레지스트리를 사용하여 프로젝트의 모든 이미지 스트림에서 이미지를 가져올 수 있습니다.

12.4. 서비스 계정 관리
링크 복사

서비스 계정은 각 프로젝트 내에 존재하는 API 오브젝트입니다. 서비스 계정을 관리하려면 sa 또는 serviceaccount 오브젝트 유형과 함께 oc 명령을 사용하거나 웹 콘솔을 사용할 수 있습니다.

현재 프로젝트에서 기존 서비스 계정 목록을 가져오려면 다음을 수행합니다.

oc get sa

$ oc get sa
NAME       SECRETS   AGE
builder    2         2d
default    2         2d
deployer   2         2d

Copy to Clipboard

Toggle word wrap

새 서비스 계정을 생성하려면 다음을 수행합니다.

oc create sa robot

$ oc create sa robot
serviceaccount "robot" created

Copy to Clipboard

Toggle word wrap

서비스 계정이 생성되면 다음 두 개의 보안이 자동으로 추가됩니다.

API 토큰
OpenShift Container Registry 인증 정보

서비스 계정을 설명하면 이를 확인할 수 있습니다.

oc describe sa robot

$ oc describe sa robot
Name:		robot
Namespace:	project1
Labels:		<none>
Annotations:	<none>

Image pull secrets:	robot-dockercfg-qzbhb

Mountable secrets: 	robot-token-f4khf
                   	robot-dockercfg-qzbhb

Tokens:            	robot-token-f4khf
                   	robot-token-z8h44

Copy to Clipboard

Toggle word wrap

이 시스템은 서비스 계정에 항상 API 토큰 및 레지스트리 인증 정보가 있는지 확인합니다.

생성된 API 토큰 및 레지스트리 인증 정보는 만료되지 않지만 시크릿을 삭제하여 취소할 수 있습니다. 시크릿이 삭제되면 새 시크릿이 자동으로 생성됩니다.

12.5. 서비스 계정 인증 활성화
링크 복사

서비스 계정은 개인 RSA 키로 서명된 토큰을 사용하여 API에 인증합니다. 인증 계층은 일치하는 공개 RSA 키를 사용하여 서명을 확인합니다.

서비스 계정 토큰 생성을 활성화하려면 마스터의 /etc/origin/master/master-config.yml 파일의 serviceAccountConfig 스탠자를 업데이트하여 privateKeyFile ( 서명용) 및 publicKeyFile 목록에 일치하는 공개 키 파일을 지정합니다.

serviceAccountConfig:
  ...
  masterCA: ca.crt 
  privateKeyFile: serviceaccount.private.key 
  publicKeyFiles:
  - serviceaccount.public.key 
  - ...

serviceAccountConfig:
  ...
  masterCA: ca.crt

1


  privateKeyFile: serviceaccount.private.key

2


  publicKeyFiles:
  - serviceaccount.public.key

3


  - ...

Copy to Clipboard

Toggle word wrap

1: API 서버의 제공 인증서를 확인하는 데 사용되는 CA 파일입니다.
2: 개인 RSA 키 파일(토큰 서명용).
3: 공용 RSA 키 파일(토큰 확인을 위해). 개인 키 파일이 제공되면 공개 키 구성 요소가 사용됩니다. 여러 공개 키 파일을 지정할 수 있으며 공개 키 중 하나에서 유효성을 검사할 수 있으면 토큰이 허용됩니다. 이를 통해 서명 키를 순환할 수 있지만 이전 서명자가 생성한 토큰을 계속 허용할 수 있습니다.

12.6. 관리형 서비스 계정
링크 복사

빌드, 배포 및 기타 포드를 실행하려면 각 프로젝트에서 서비스 계정이 필요합니다. 마스터의 /etc/origin/master/master-config.yml 파일의 managedNames 설정은 모든 프로젝트에서 자동으로 생성되는 서비스 계정을 제어합니다.

serviceAccountConfig:
  ...
  managedNames: 
  - builder 
  - deployer 
  - default 
  - ...

serviceAccountConfig:
  ...
  managedNames:

1


  - builder

2


  - deployer

3


  - default

4


  - ...

Copy to Clipboard

Toggle word wrap

1: 모든 프로젝트에서 자동으로 생성할 서비스 계정 목록입니다.
2: 각 프로젝트의 빌더 서비스 계정은 빌드 Pod에 필요하며, 내부 컨테이너 레지스트리를 사용하여 프로젝트의 모든 이미지 스트림으로 이미지를 푸시할 수 있는 system:image-builder 역할이 제공됩니다.
3: 각 프로젝트의 배포 서비스 계정은 배포 Pod에 필요하며 system:deployer 역할에 따라 프로젝트에서 복제 컨트롤러 및 Pod를 보고 수정할 수 있습니다.
4: 다른 서비스 계정을 지정하지 않는 한 다른 모든 Pod에서 기본 서비스 계정이 사용됩니다.

프로젝트의 모든 서비스 계정에는 system:image-puller 역할이 부여되어 내부 컨테이너 레지스트리를 사용하여 프로젝트의 모든 이미지 스트림에서 이미지를 가져올 수 있습니다.

12.7. 인프라 서비스 계정
링크 복사

다양한 인프라 컨트롤러가 서비스 계정 자격 증명을 사용하여 실행됩니다. 다음 서비스 계정은 서버 시작 시 OpenShift Container Platform 인프라 프로젝트(openshift-infra)에서 생성되며 클러스터 전체에서 다음과 같은 역할이 제공됩니다.

Expand

서비스 계정	설명
replication-controller	system:replication-controller 역할이 할당됨
deployment-controller	system:deployment-controller 역할이 할당됨
build-controller	system:build-controller 역할이 할당되었습니다. 또한 권한 있는 빌드 pod를 생성하기 위해 권한 있는 보안 컨텍스트 제약 조건에 build-controller 서비스 계정이 포함되어 있습니다.

해당 서비스 계정이 생성되는 프로젝트를 구성하려면 마스터의 /etc/origin/master/master-config.yml 파일에서 openshiftinfraNamespace 필드를 설정합니다.

policyConfig:
  ...
  openshiftInfrastructureNamespace: openshift-infra

policyConfig:
  ...
  openshiftInfrastructureNamespace: openshift-infra

Copy to Clipboard

Toggle word wrap

12.8. 서비스 계정 및 시크릿
링크 복사

서비스 계정에서 Pod 시크릿 참조를 허용 목록에 요청하려면 마스터의 /etc/origin/master/master-config.yml 파일에 limitSecretReferences 필드를 true 로 설정합니다. Pod에서 프로젝트의 보안을 참조할 수 있도록 해당 값을 false 로 설정합니다.

serviceAccountConfig:
  ...
  limitSecretReferences: false

serviceAccountConfig:
  ...
  limitSecretReferences: false

Copy to Clipboard

Toggle word wrap

12.9. 허용된 보안 관리
링크 복사

Pod의 서비스 계정에서 API 인증 정보를 제공하는 것 외에도 Pod에서 사용할 수 있는 시크릿을 결정합니다.

Pod는 다음 두 가지 방법으로 보안을 사용합니다.

이미지 가져오기 보안: Pod의 컨테이너 이미지를 가져오는 데 사용되는 인증 정보 제공
마운트 가능한 보안, 보안 콘텐츠를 파일로 삽입

서비스 계정의 Pod에서 이미지 가져오기 시크릿으로 시크릿을 사용할 수 있도록 하려면 다음을 실행합니다.

oc secrets link --for=pull <serviceaccount-name> <secret-name>

$ oc secrets link --for=pull <serviceaccount-name> <secret-name>

Copy to Clipboard

Toggle word wrap

서비스 계정의 Pod에서 보안을 마운트할 수 있도록 하려면 다음을 실행합니다.

oc secrets link --for=mount <serviceaccount-name> <secret-name>

$ oc secrets link --for=mount <serviceaccount-name> <secret-name>

Copy to Clipboard

Toggle word wrap

참고

기본적으로 비활성화되어 있는 서비스 계정으로만 시크릿을 제한합니다. 즉, 마스터 구성 파일에서 serviceAccountConfig.limitSecretReferences 가 false (기본 설정)로 설정된 경우 --for=mount 옵션을 사용하여 서비스 계정의 pod에 시크릿을 마운트할 필요가 없습니다. 그러나 --for=pull 옵션을 사용하여 serviceAccountConfig.limitSecretReferences 값에 관계없이 이미지 풀 시크릿 사용을 활성화해야 합니다.

이 예제에서는 서비스 계정에 보안을 생성하고 추가합니다.

oc create secret generic secret-plans \
    --from-file=plan1.txt \
    --from-file=plan2.txt
oc create secret docker-registry my-pull-secret \
    --docker-username=mastermind \
    --docker-password=12345 \
    --docker-email=mastermind@example.com
oc secrets link robot secret-plans --for=mount
oc secrets link robot my-pull-secret --for=pull
oc describe serviceaccount robot

$ oc create secret generic secret-plans \
    --from-file=plan1.txt \
    --from-file=plan2.txt
secret/secret-plans

$ oc create secret docker-registry my-pull-secret \
    --docker-username=mastermind \
    --docker-password=12345 \
    --docker-email=mastermind@example.com
secret/my-pull-secret

$ oc secrets link robot secret-plans --for=mount

$ oc secrets link robot my-pull-secret --for=pull

$ oc describe serviceaccount robot
Name:               robot
Labels:             <none>
Image pull secrets:	robot-dockercfg-624cx
                   	my-pull-secret

Mountable secrets: 	robot-token-uzkbh
                   	robot-dockercfg-624cx
                   	secret-plans

Tokens:            	robot-token-8bhpp
                   	robot-token-uzkbh

Copy to Clipboard

Toggle word wrap

12.10. 컨테이너 외에도 서비스 계정의 인증 정보 사용
링크 복사

Pod가 생성되면 서비스 계정을 지정하고(또는 기본 서비스 계정을 사용) 해당 서비스 계정의 API 인증 정보 및 참조 보안을 사용할 수 있습니다.

Pod 서비스 계정에 대한 API 토큰이 포함된 파일은 /var/run/secrets/kubernetes.io/serviceaccount/token 에 자동으로 마운트됩니다.

해당 토큰은 Pod의 서비스 계정으로 API를 호출하는 데 사용할 수 있습니다. 이 예제에서는 토큰으로 식별되는 사용자에 대한 정보를 가져오기 위해 users/~ API를 호출합니다.

TOKEN="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    "https://openshift.default.svc.cluster.local/oapi/v1/users/~" \
    "https://openshift.default.svc.cluster.local/oapi/v1/users/~" \
    -H "Authorization: Bearer $TOKEN"
    -H "Authorization: Bearer $TOKEN"

kind: "User"
apiVersion: "user.openshift.io/v1"
metadata:
  name: "system:serviceaccount:top-secret:robot"
  selflink: "/oapi/v1/users/system:serviceaccount:top-secret:robot"
  creationTimestamp: null
identities: null
groups:
  - "system:serviceaccount"
  - "system:serviceaccount:top-secret"

$ TOKEN="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    "https://openshift.default.svc.cluster.local/oapi/v1/users/~" \
    -H "Authorization: Bearer $TOKEN"

kind: "User"
apiVersion: "user.openshift.io/v1"
metadata:
  name: "system:serviceaccount:top-secret:robot"
  selflink: "/oapi/v1/users/system:serviceaccount:top-secret:robot"
  creationTimestamp: null
identities: null
groups:
  - "system:serviceaccount"
  - "system:serviceaccount:top-secret"

Copy to Clipboard

Toggle word wrap

12.11. 서비스 계정의 인증 정보를 외부적으로 사용
링크 복사

동일한 토큰을 API에 인증해야 하는 외부 애플리케이션에 배포할 수 있습니다.

서비스 계정의 API 토큰을 보려면 다음 구문을 사용합니다.

oc describe secret <secret-name>

$ oc describe secret <secret-name>

Copy to Clipboard

Toggle word wrap

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

oc describe secret robot-token-uzkbh -n top-secret
oc login --token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
oc whoami

$ oc describe secret robot-token-uzkbh -n top-secret
Name:		robot-token-uzkbh
Labels:		<none>
Annotations:	kubernetes.io/service-account.name=robot,kubernetes.io/service-account.uid=49f19e2e-16c6-11e5-afdc-3c970e4b7ffe

Type:	kubernetes.io/service-account-token

Data

token:	eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

$ oc login --token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Logged into "https://server:8443" as "system:serviceaccount:top-secret:robot" using the token provided.

You don't have any projects. You can try to create a new project, by running

    $ oc new-project <projectname>

$ oc whoami
system:serviceaccount:top-secret:robot

Copy to Clipboard

Toggle word wrap

13장. 이미지 관리
링크 복사

13.1. 개요
링크 복사

이미지 스트림 은 태그로 식별되는 여러 컨테이너 이미지로 구성됩니다. Docker 이미지 리포지토리와 유사한 관련 이미지의 단일 가상 보기를 제공합니다.

빌드 및 배포는 이미지 스트림을 모니터링하다가 새 이미지가 추가되거나 이미지가 수정되면 알림을 받고 빌드 또는 배포를 수행하여 각각에 대응할 수 있습니다.

이미지 레지스트리 위치, 해당 레지스트리에 대한 인증 요구 사항, 빌드 및 배포의 작동 방식에 따라 이미지와 상호 작용하고 이미지 스트림을 설정하는 방법에는 여러 가지가 있습니다. 다음 섹션에서는 이러한 주제의 범위를 다룹니다.

13.2. 태그 지정 이미지
링크 복사

OpenShift Container Platform 이미지 스트림 및 해당 태그로 작업하기 전에 일반적으로 컨테이너 이미지 컨텍스트에서 이미지 태그를 이해하는 데 도움이 됩니다.

컨테이너 이미지에 이름을 추가하여 태그 라는 이름의 내용을 보다 직관적으로 확인할 수 있습니다. 태그를 사용하여 이미지에 포함된 버전을 지정하는 것이 일반적인 사용 사례입니다. ruby 라는 이미지가 있는 경우 Ruby의 2.0 버전에 대해 2.0 이라는 태그가 있을 수 있으며, 다른 이름이 latest인 다른 이름이 지정된 latest 는 문자 그대로 해당 리포지토리에 빌드된 최신 이미지를 나타낼 수 있습니다.

docker CLI를 사용하여 이미지와 직접 상호 작용할 때 docker tag 명령은 태그를 추가할 수 있으며, 이 태그는 기본적으로 여러 부분으로 구성될 수 있는 별칭을 이미지에 추가합니다. 이러한 부분은 다음을 포함할 수 있습니다.

<registry_server>/<user_name>/<image_name>:<tag>

<registry_server>/<user_name>/<image_name>:<tag>

Copy to Clipboard

Toggle word wrap

위 < user_name > 부분은 이미지가 내부 레지스트리(OpenShift Container Registry)를 사용하여 OpenShift Container Platform 환경에 저장된 경우 프로젝트 또는 네임스페이스 를 참조할 수도 있습니다.

OpenShift Container Platform은 docker tag 명령과 유사하지만 이미지가 아닌 이미지 스트림에서 작동하는 oc tag 명령을 제공합니다.

참고

docker CLI를 사용하여 이미지를 직접 태그 지정하는 방법에 대한 자세한 내용은 Red Hat Enterprise Linux 7의 컨테이너 시작하기 설명서를 참조하십시오.

13.2.1. 이미지 스트림에 태그 추가
링크 복사

OpenShift Container Platform의 이미지 스트림은 태그로 식별되는 0개 이상의 컨테이너 이미지로 구성되므로 oc tag 명령을 사용하여 이미지 스트림에 태그를 추가할 수 있습니다.

oc tag <source> <destination>

$ oc tag <source> <destination>

Copy to Clipboard

Toggle word wrap

예를 들어 ruby 이미지 스트림 static-2.0 태그가 항상 ruby 이미지 스트림 2.0 태그의 현재 이미지를 참조하도록 구성하려면 다음을 수행합니다.

oc tag ruby:2.0 ruby:static-2.0

$ oc tag ruby:2.0 ruby:static-2.0

Copy to Clipboard

Toggle word wrap

이렇게 하면 ruby 이미지 스트림에 static-2.0 이라는 새 이미지 스트림 태그가 생성됩니다. 새 태그는 oc tag 가 실행될 때 ruby:2.0 이미지 스트림 태그가 가리키는 이미지 ID를 직접 참조하며 해당 태그가 가리키는 이미지는 변경되지 않습니다.

사용할 수 있는 태그 유형은 다양합니다. 기본 동작에서는 시간의 특정 이미지를 가리키는 permanent 태그를 사용합니다. 소스가 변경되면 새 (대상) 태그가 변경되지 않습니다.

tracking 태그는 소스 태그를 가져오는 동안 대상 태그의 메타데이터가 업데이트되었음을 나타냅니다. 소스 태그가 변경될 때마다 대상 태그가 업데이트되도록 하려면 --alias=true 플래그를 사용합니다.

oc tag --alias=true <source> <destination>

$ oc tag --alias=true <source> <destination>

Copy to Clipboard

Toggle word wrap

참고

영구 별칭(예: latest 또는 stable)을 생성하려면 tracking 태그를 사용합니다. 이 태그는 단일 이미지 스트림 내에서 만 올바르게 작동합니다. 이미지 스트림 간 별칭을 생성하려고 하면 오류가 발생합니다.

--scheduled=true 플래그를 추가하여 대상 태그를 주기적으로 새로 고칠 수 있습니다(예: 다시 가져오기). 기간은 시스템 수준에서 전역적으로 구성됩니다. 자세한 내용은 Tag 및 Image Metadata 가져오기 를 참조하십시오.

--reference 플래그는 가져오지 않는 이미지 스트림 태그를 생성합니다. 태그는 영구적으로 소스 위치를 가리킵니다.

Docker가 항상 통합 레지스트리에서 태그된 이미지를 가져오도록 지정하려면 --reference-policy=local 을 사용하십시오. 레지스트리는 가져오기 기능을 사용하여 클라이언트에 이미지를 제공합니다. 기본적으로 이미지 Blob은 레지스트리에 의해 로컬로 미러링됩니다. 따라서 다음에 필요할 때 더 빨리 가져올 수 있습니다. 이 플래그를 사용하면 이미지 스트림에 비보안 주석이 있거나 태그에 비보안 가져오기 정책이 있는 한 Docker 데몬에 --insecure -registry 를 제공할 필요 없이 비보안 레지스트리에서 가져올 수도 있습니다.

13.2.2. 권장 태그 지정 규칙
링크 복사

이미지는 시간이 지남에 따라 개선되며 해당 태그를 사용하여 이러한 개선을 반영합니다. 이미지 태그는 항상 빌드된 최신 이미지를 가리킵니다.

태그 이름에 너무 많은 정보가 포함되어 있는 경우(예: v2.0.1-may-2016) 태그는 이미지 하나의 개정만 가리키며 업데이트되지 않습니다. 기본 이미지 정리 옵션을 사용하는 경우 이러한 이미지는 절대 제거되지 않습니다. 크기가 매우 큰 클러스터에서는 모든 수정된 이미지에 대한 새로운 태그 생성 스키마가 아주 오래된 이미지에 대한 초과 태그 메타데이터로 etcd 데이터 저장소를 채울 수 있습니다.

대신 태그 이름이 v2.0 이면 더 많은 이미지 버전이 수정될 가능성이 높습니다. 이로 인해 태그 기록이 길어지므로 이미지 정리기가 오래되고 사용되지 않는 이미지를 제거할 가능성이 높습니다. 자세한 내용은 이미지 정리를 참조하십시오.

태그 이름 지정 규칙은 사용자가 결정하지만 아래에서 <image_name>:<image_tag> 형식으로 된 몇 가지 예를 볼 수 있습니다.

Expand

표 13.1. 이미지 태그 이름 지정 규칙
설명	예
버전	`myimage:v2.0.1`
아키텍처	`myimage:v2.0-x86_64`
기본 이미지	`myimage:v1.2-centos7`
최신(불안정한 상태가 될 수 있음)	`myimage:latest`
안정된 최신 상태	`myimage:stable`

태그 이름에 날짜가 필요한 경우 오래되고 지원되지 않는 이미지와 istags를 정기적으로 검사하여 제거하십시오. 그러지 않으면 오래된 이미지로 인해 리소스 사용량이 증가할 수 있습니다.

13.2.3. 이미지 스트림에서 태그 제거
링크 복사

이미지 스트림에서 태그를 완전히 제거하려면 다음을 실행합니다.

oc delete istag/ruby:latest

$ oc delete istag/ruby:latest

Copy to Clipboard

Toggle word wrap

또는 다음을 수행합니다.

oc tag -d ruby:latest

$ oc tag -d ruby:latest

Copy to Clipboard

Toggle word wrap

13.2.4. 이미지 스트림의 이미지 참조
링크 복사

다음 참조 유형을 사용하여 이미지 스트림에서 이미지를 참조할 수 있습니다.

ImageStreamTag 는 지정된 이미지 스트림 및 태그의 이미지를 참조하거나 검색하는 데 사용됩니다. 해당 이름에 다음 규칙을 사용합니다.
```
<image_stream_name>:<tag>
```
```
<image_stream_name>:<tag>
```
Copy to Clipboard Toggle word wrap
ImageStreamImage 는 지정된 이미지 스트림 및 이미지 이름의 이미지를 참조하거나 검색하는 데 사용됩니다. 해당 이름에 다음 규칙을 사용합니다.
```
<image_stream_name>@<id>
```
```
<image_stream_name>@<id>
```
Copy to Clipboard Toggle word wrap
<id>는 다이제스트라고도 하는 특정 이미지의 변경 불가능한 식별자입니다.
DockerImage 는 지정된 외부 레지스트리의 이미지를 참조하거나 검색하는 데 사용됩니다. 해당 이름에 표준 Docker 가져오기 사양 을 사용합니다. 예를 들면 다음과 같습니다.
```
openshift/ruby-20-centos7:2.0
```
```
openshift/ruby-20-centos7:2.0
```
Copy to Clipboard Toggle word wrap
참고
태그가 지정되지 않은 경우 latest 태그가 사용된 것으로 가정합니다.
다음과 같은 타사 레지스트리를 참조할 수도 있습니다.
```
registry.access.redhat.com/rhel7:latest
```
```
registry.access.redhat.com/rhel7:latest
```
Copy to Clipboard Toggle word wrap
또는 다이제스트가 있는 이미지도 참조할 수 있습니다.
```
centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
```
```
centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
```
Copy to Clipboard Toggle word wrap

CentOS 이미지 스트림 예제와 같은 이미지 스트림 정의 예를 볼 때 ImageStreamTag 정의와 DockerImage 에 대한 참조가 포함되어 있지만 ImageStreamImage 와 관련된 항목은 포함되어 있지 않을 수 있습니다.

이미지 스트림으로 이미지를 가져오거나 태그할 때마다 ImageStreamImage 오브젝트가 OpenShift Container Platform에서 자동으로 생성되기 때문입니다. 이미지 스트림을 생성하는 데 사용하는 이미지 스트림 정의에서는 ImageStreamImage 오브젝트를 명시적으로 정의할 필요가 없습니다.

이미지 스트림 이름과 ID를 사용하여 ImageStreamImage 정의를 검색하여 이미지의 오브젝트 정의를 볼 수 있습니다.

oc export isimage <image_stream_name>@<id>

$ oc export isimage <image_stream_name>@<id>

Copy to Clipboard

Toggle word wrap

참고

다음을 실행하여 지정된 이미지 스트림의 유효한 <id > 값을 찾을 수 있습니다.

oc describe is <image_stream_name>

$ oc describe is <image_stream_name>

Copy to Clipboard

Toggle word wrap

예를 들어 ruby 이미지 스트림에서 ruby@3a335d7 의 이름 및 ID를 사용하여 ImageStreamImage 를 요청합니다.

ImageStreamImage를 통해 이미지 오브젝트의 정의

oc export isimage ruby@3a335d7

$ oc export isimage ruby@3a335d7

apiVersion: v1
image:
  dockerImageLayers:
  - name: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    size: 0
  - name: sha256:ee1dd2cb6df21971f4af6de0f1d7782b81fb63156801cfde2bb47b4247c23c29
    size: 196634330
  - name: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    size: 0
  - name: sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4
    size: 0
  - name: sha256:ca062656bff07f18bff46be00f40cfbb069687ec124ac0aa038fd676cfaea092
    size: 177723024
  - name: sha256:63d529c59c92843c395befd065de516ee9ed4995549f8218eac6ff088bfa6b6e
    size: 55679776
  dockerImageMetadata:
    Architecture: amd64
    Author: SoftwareCollections.org <sclorg@redhat.com>
    Config:
      Cmd:
      - /bin/sh
      - -c
      - $STI_SCRIPTS_PATH/usage
      Entrypoint:
      - container-entrypoint
      Env:
      - PATH=/opt/app-root/src/bin:/opt/app-root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
      - STI_SCRIPTS_URL=image:///usr/libexec/s2i
      - STI_SCRIPTS_PATH=/usr/libexec/s2i
      - HOME=/opt/app-root/src
      - BASH_ENV=/opt/app-root/etc/scl_enable
      - ENV=/opt/app-root/etc/scl_enable
      - PROMPT_COMMAND=. /opt/app-root/etc/scl_enable
      - RUBY_VERSION=2.2
      ExposedPorts:
        8080/tcp: {}
      Image: d9c3abc5456a9461954ff0de8ae25e0e016aad35700594714d42b687564b1f51
      Labels:
        build-date: 2015-12-23
        io.k8s.description: Platform for building and running Ruby 2.2 applications
        io.k8s.display-name: Ruby 2.2
        io.openshift.builder-base-version: 8d95148
        io.openshift.builder-version: 8847438ba06307f86ac877465eadc835201241df
        io.openshift.s2i.scripts-url: image:///usr/libexec/s2i
        io.openshift.tags: builder,ruby,ruby22
        io.s2i.scripts-url: image:///usr/libexec/s2i
        license: GPLv2
        name: CentOS Base Image
        vendor: CentOS
      User: "1001"
      WorkingDir: /opt/app-root/src
    ContainerConfig: {}
    Created: 2016-01-26T21:07:27Z
    DockerVersion: 1.8.2-el7
    Id: 57b08d979c86f4500dc8cad639c9518744c8dd39447c055a3517dc9c18d6fccd
    Parent: d9c3abc5456a9461954ff0de8ae25e0e016aad35700594714d42b687564b1f51
    Size: 430037130
    apiVersion: "1.0"
    kind: DockerImage
  dockerImageMetadataVersion: "1.0"
  dockerImageReference: centos/ruby-22-centos7@sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
  metadata:
    creationTimestamp: 2016-01-29T13:17:45Z
    name: sha256:3a335d7d8a452970c5b4054ad7118ff134b3a6b50a2bb6d0c07c746e8986b28e
    resourceVersion: "352"
    uid: af2e7a0c-c68a-11e5-8a99-525400f25e34
kind: ImageStreamImage
metadata:
  creationTimestamp: null
  name: ruby@3a335d7
  namespace: openshift
  selflink: /oapi/v1/namespaces/openshift/imagestreamimages/ruby@3a335d7

Copy to Clipboard

Toggle word wrap

13.3. Kubernetes 리소스에서 이미지 스트림 사용
링크 복사

OpenShift Container Platform 네이티브 리소스인 이미지 스트림은 빌드 또는 배포 와 같이 OpenShift Container Platform에서 사용할 수 있는 다른 모든 네이티브 리소스와 함께 곧바로 작동됩니다. 현재는 작업,복제 컨트롤러, 복제본 세트 또는 Kubernetes 배포와 같은 네이티브 Kubernetes 리소스와 함께 작동하도록 할 수도 있습니다.

클러스터 관리자는 사용할 수 있는 리소스를 정확하게 구성합니다.

활성화하면 리소스의 이미지 필드에 이미지 스트림에 대한 참조를 배치할 수 있습니다. 이 기능을 사용하는 경우 리소스와 동일한 프로젝트에 상주하는 이미지 스트림만 참조할 수 있습니다. 이미지 스트림 참조는 ruby:2.4 와 같은 단일 세그먼트 값으로 구성되어야 합니다. 여기서 ruby 는 태그가 2.4 이고 참조하는 리소스와 동일한 프로젝트에 상주하는 이미지 스트림의 이름입니다.

이를 활성화하는 방법은 다음 두 가지가 있습니다.

특정 리소스에서 이미지 스트림 분석을 활성화합니다. 이렇게 하면 해당 리소스만 이미지 필드에서 이미지 스트림 이름을 사용할 수 있습니다.
이미지 스트림에서 이미지 스트림 해석을 활성화합니다. 이렇게 하면 해당 이미지 스트림을 가리키는 모든 리소스가 이미지 필드에서 그 이미지 스트림 이름을 사용할 수 있습니다.

이러한 두 작업은 oc set image-lookup 을 사용하여 수행할 수 있습니다. 예를 들어 다음 명령을 사용하면 모든 리소스가 mysql 이라는 이미지 스트림을 참조할 수 있습니다.

oc set image-lookup mysql

$ oc set image-lookup mysql

Copy to Clipboard

Toggle word wrap

이렇게 하면 Imagestream.spec.lookupPolicy.local 필드가 true로 설정됩니다.

이미지 조회가 활성화된 이미지 스트림

apiVersion: v1
kind: ImageStream
metadata:
  annotations:
    openshift.io/display-name: mysql
  name: mysql
  namespace: myproject
spec:
  lookupPolicy:
    local: true

apiVersion: v1
kind: ImageStream
metadata:
  annotations:
    openshift.io/display-name: mysql
  name: mysql
  namespace: myproject
spec:
  lookupPolicy:
    local: true

Copy to Clipboard

Toggle word wrap

활성화되는 경우 이미지 스트림 내 모든 태그에 대해 해당 동작이 활성화됩니다.

이미지 스트림을 쿼리하고 다음을 사용하여 옵션이 설정되었는지 확인할 수 있습니다.

oc set image-lookup

$ oc set image-lookup

Copy to Clipboard

Toggle word wrap

특정 리소스에서 이미지 조회를 활성화할 수도 있습니다. 이 명령을 사용하면 mysql 이라는 Kubernetes 배포에서 이미지 스트림을 사용할 수 있습니다.

oc set image-lookup deploy/mysql

$ oc set image-lookup deploy/mysql

Copy to Clipboard

Toggle word wrap

이렇게 하면 배포에 alpha.image.policy.openshift.io/resolve-names 주석이 설정됩니다.

이미지 조회가 활성화된 배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
  namespace: myproject
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        alpha.image.policy.openshift.io/resolve-names: '*'
    spec:
      containers:
      - image: mysql:latest
        imagePullPolicy: Always
        name: mysql

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
  namespace: myproject
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        alpha.image.policy.openshift.io/resolve-names: '*'
    spec:
      containers:
      - image: mysql:latest
        imagePullPolicy: Always
        name: mysql

Copy to Clipboard

Toggle word wrap

이미지 조회를 비활성화하려면 --enabled=false 를 전달합니다.

oc set image-lookup deploy/mysql --enabled=false

$ oc set image-lookup deploy/mysql --enabled=false

Copy to Clipboard

Toggle word wrap

13.4. 이미지 가져오기 정책
링크 복사

pod의 각 컨테이너에는 컨테이너 이미지가 있습니다. 이미지를 생성하여 레지스트리로 푸시한 후에는 pod에서 해당 이미지를 참조할 수 있습니다.

OpenShift Container Platform은 컨테이너를 생성할 때 컨테이너의 imagePullPolicy 를 사용하여 컨테이너를 시작하기 전에 이미지를 가져와야 하는지 결정합니다. imagePullPolicy 에는 세 가지 가능한 값이 있습니다.

Always - 항상 이미지를 가져옵니다.
IfNotPresent - 이미지가 노드에 없는 경우에만 가져옵니다.
절대 - 절대 이미지를 가져오지 않습니다.

컨테이너의 imagePullPolicy 매개변수가 지정되지 않은 경우 OpenShift Container Platform은 이미지의 태그를 기반으로 설정합니다.

태그가 최신 이면 OpenShift Container Platform의 기본값은 imagePullPolicy 를 Always 입니다.
그러지 않으면 OpenShift Container Platform의 기본값은 imagePullPolicy 를 IfNotPresent 입니다.

참고

Never Image Pull Policy를 사용하는 경우, 인증 정보가 있는 Pod에서만 개인 이미지를 사용하여 AlwaysPullImages 승인 컨트롤러 를 사용하여 해당 이미지를 가져올 수 있는지 확인할 수 있습니다. 이 승인 컨트롤러가 활성화되지 않은 경우 노드에 대한 모든 사용자의 모든 Pod는 이미지에 대한 권한 부여 확인없이 이미지를 사용할 수 있습니다.

13.5. 내부 레지스트리에 액세스
링크 복사

OpenShift Container Platform의 내부 레지스트리에 직접 액세스하여 이미지를 푸시하거나 가져올 수 있습니다. 예를 들어 이미지를 수동으로 푸시하거나 Docker로 직접 이미지를 가져와서 이미지 스트림을 생성 하려는 경우 유용할 수 있습니다.

내부 레지스트리는 OpenShift Container Platform API와 동일한 토큰을 사용하여 인증합니다. 내부 레지스트리에 대해 docker 로그인 을 수행하려면 사용자 이름과 이메일을 선택할 수 있지만 암호는 유효한 OpenShift Container Platform 토큰이어야 합니다.

내부 레지스트리에 로그인하려면 다음을 수행합니다.

OpenShift Container Platform에 로그인합니다.
```
oc login
```
```
$ oc login
```
Copy to Clipboard Toggle word wrap
액세스 토큰을 가져옵니다.
```
oc whoami -t
```
```
$ oc whoami -t
```
Copy to Clipboard Toggle word wrap
토큰을 사용하여 내부 레지스트리에 로그인합니다. 시스템에 docker 가 설치되어 있어야 합니다.
```
docker login -u <user_name> -e <email_address> \
    -p <token_value> <registry_server>:<port>
```
```
$ docker login -u <user_name> -e <email_address> \
    -p <token_value> <registry_server>:<port>
```
Copy to Clipboard Toggle word wrap
참고
사용할 레지스트리 IP 또는 호스트 이름과 포트를 모르는 경우 클러스터 관리자에게 문의하십시오.

이미지를 가져오려면 인증된 사용자에게 요청한 이미지 스트림/레이어에 대한 가져오기 권한이 있어야 합니다. 이미지를 밀어 넣으려면 인증된 사용자에게 요청한 이미지 스트림/레이어에 대한 업데이트 권한이 있어야 합니다.

기본적으로 프로젝트의 모든 서비스 계정에는 해당 프로젝트의 이미지를 가져올 수 있는 권한이 있고, builder 서비스 계정에는 해당 프로젝트에 이미지를 밀어 넣을 권한이 있습니다.

13.6. 이미지 가져오기 보안 사용
링크 복사

Docker 레지스트리 를 보호하여 인증되지 않은 당사자가 특정 이미지에 액세스하지 못하도록 보호할 수 있습니다. OpenShift Container Platform의 내부 레지스트리를 사용하며 동일한 프로젝트에 있는 이미지 스트림에서 이미지를 가져오는 경우 Pod 서비스 계정에 이미 올바른 권한이 있어야 하며 추가 작업이 필요하지 않습니다.

하지만 OpenShift Container Platform 프로젝트 간에 이미지를 참조하거나 보안 레지스트리의 이미지를 참조하는 경우와 같은 다른 시나리오에서는 추가 구성 단계가 필요합니다. 다음 섹션에서는 이러한 시나리오 및 필요한 단계에 대해 자세히 설명합니다.

13.6.1. Pod에서 프로젝트 간 이미지를 참조하도록 허용
링크 복사

내부 레지스트리를 사용하는 경우 project-a 의 pod가 project-b 의 이미지를 참조하도록 허용하려면 project-a 의 서비스 계정이 project-b 의 system:image-puller 역할에 바인딩되어야 합니다.

oc policy add-role-to-user \
    system:image-puller system:serviceaccount:project-a:default \
    --namespace=project-b

$ oc policy add-role-to-user \
    system:image-puller system:serviceaccount:project-a:default \
    --namespace=project-b

Copy to Clipboard

Toggle word wrap

해당 역할을 추가한 후 기본 서비스 계정을 참조하는 project-a 의 pod는 project-b 에서 이미지를 가져올 수 있습니다.

project-a 의 모든 서비스 계정에 대한 액세스를 허용하려면 그룹을 사용합니다.

oc policy add-role-to-group \
    system:image-puller system:serviceaccounts:project-a \
    --namespace=project-b

$ oc policy add-role-to-group \
    system:image-puller system:serviceaccounts:project-a \
    --namespace=project-b

Copy to Clipboard

Toggle word wrap

13.6.2. Pod에서 기타 보안 레지스트리의 이미지를 참조하도록 허용
링크 복사

dockercfg 파일(또는 최신 Docker 클라이언트의 경우 $HOME/.docker/config.json )은 이전에 보안 또는 비보안 레지스트리에 로그인한 경우 해당 정보를 저장하는 Docker 인증 정보 파일입니다.

OpenShift Container Platform의 내부 레지스트리가 아닌 보안 컨테이너 이미지를 가져오려면 Docker 인증 정보에서 풀 시크릿 을 생성하여 서비스 계정에 추가해야 합니다.

보안 레지스트리의 .dockercfg 파일이 이미 있는 경우 다음을 실행하여 해당 파일에서 보안을 생성할 수 있습니다.

oc create secret generic <pull_secret_name> \
    --from-file=.dockercfg=<path/to/.dockercfg> \
    --type=kubernetes.io/dockercfg

$ oc create secret generic <pull_secret_name> \
    --from-file=.dockercfg=<path/to/.dockercfg> \
    --type=kubernetes.io/dockercfg

Copy to Clipboard

Toggle word wrap

또는 $HOME/.docker/config.json 파일이 있는 경우 다음을 수행합니다.

oc create secret generic <pull_secret_name> \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

$ oc create secret generic <pull_secret_name> \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

Copy to Clipboard

Toggle word wrap

보안 레지스트리의 Docker 인증 정보 파일이 아직 없는 경우 다음을 실행하여 시크릿을 생성할 수 있습니다.

oc create secret docker-registry <pull_secret_name> \
    --docker-server=<registry_server> \
    --docker-username=<user_name> \
    --docker-password=<password> \
    --docker-email=<email>

$ oc create secret docker-registry <pull_secret_name> \
    --docker-server=<registry_server> \
    --docker-username=<user_name> \
    --docker-password=<password> \
    --docker-email=<email>

Copy to Clipboard

Toggle word wrap

Pod의 이미지 가져오기에 시크릿을 사용하려면 서비스 계정에 이 시크릿을 추가해야 합니다. 이 예제의 서비스 계정 이름은 Pod가 사용하는 서비스 계정 이름과 일치해야 합니다. 기본값은 기본 서비스 계정입니다.

oc secrets link default <pull_secret_name> --for=pull

$ oc secrets link default <pull_secret_name> --for=pull

Copy to Clipboard

Toggle word wrap

빌드 이미지를 내보내고 가져오는 데 시크릿을 사용하려면 Pod 내부에서 보안을 마운트할 수 있어야 합니다. 다음을 실행하여 이 작업을 수행할 수 있습니다.

oc secrets link builder <pull_secret_name>

$ oc secrets link builder <pull_secret_name>

Copy to Clipboard

Toggle word wrap

13.6.2.1. delegated 인증을 사용하여 프라이빗 레지스트리 가져오기
링크 복사

개인 레지스트리는 별도의 서비스에 인증을 위임할 수 있습니다. 이 경우 인증 및 레지스트리 끝점 둘 다에 대해 이미지 풀 시크릿을 정의해야 합니다.

참고

Red Hat Container Catalog의 타사 이미지는 Red Hat Connect 파트너 레지스트리(registry.connect.redhat.com)에서 제공됩니다. 이 레지스트리는 인증을 sso.redhat.com 에 위임하므로 다음 절차가 적용됩니다.

위임된 인증 서버에 대한 시크릿을 생성합니다.

oc create secret docker-registry \
    --docker-server=sso.redhat.com \
    --docker-username=developer@example.com \
    --docker-password=******** \
    --docker-email=unused \
    redhat-connect-sso

$ oc create secret docker-registry \
    --docker-server=sso.redhat.com \
    --docker-username=developer@example.com \
    --docker-password=******** \
    --docker-email=unused \
    redhat-connect-sso

secret/redhat-connect-sso

Copy to Clipboard

Toggle word wrap

개인 레지스트리에 대한 시크릿을 생성합니다.

oc create secret docker-registry \
    --docker-server=privateregistry.example.com \
    --docker-username=developer@example.com \
    --docker-password=******** \
    --docker-email=unused \
    private-registry

$ oc create secret docker-registry \
    --docker-server=privateregistry.example.com \
    --docker-username=developer@example.com \
    --docker-password=******** \
    --docker-email=unused \
    private-registry

secret/private-registry

Copy to Clipboard

Toggle word wrap

참고

Red Hat Connect 파트너 레지스트리(registry.connect.redhat.com)는 자동 생성된 dockercfg 보안 유형(BZ#1476330)을 허용하지 않습니다. Docker 로그인 명령에서 생성된 파일을 사용하여 일반 파일 기반 보안을 생성해야 합니다.

docker login registry.connect.redhat.com --username developer@example.com
oc create secret generic redhat-connect --from-file=.dockerconfigjson=.docker/config.json
oc secrets link default redhat-connect --for=pull

$ docker login registry.connect.redhat.com --username developer@example.com

Password: *************
Login Succeeded

$ oc create secret generic redhat-connect --from-file=.dockerconfigjson=.docker/config.json

$ oc secrets link default redhat-connect --for=pull

Copy to Clipboard

Toggle word wrap

13.7. Tag 및 Image Metadata 가져오기
링크 복사

외부 Docker 이미지 레지스트리의 이미지 리포지토리에서 태그 및 이미지 메타데이터를 가져오도록 이미지 스트림을 구성할 수 있습니다. 이 작업은 몇 가지 다른 방법을 사용하여 수행할 수 있습니다.

--from 옵션을 사용하여 oc import-image 명령을 사용하여 태그 및 이미지 정보를 수동으로 가져올 수 있습니다.

oc import-image <image_stream_name>[:<tag>] --from=<docker_image_repo> --confirm

$ oc import-image <image_stream_name>[:<tag>] --from=<docker_image_repo> --confirm

Copy to Clipboard

Toggle word wrap

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

oc import-image my-ruby --from=docker.io/openshift/ruby-20-centos7 --confirm

$ oc import-image my-ruby --from=docker.io/openshift/ruby-20-centos7 --confirm
The import completed successfully.

Name:			my-ruby
Created:		Less than a second ago
Labels:			<none>
Annotations:		openshift.io/image.dockerRepositoryCheck=2016-05-06T20:59:30Z
Docker Pull Spec:	172.30.94.234:5000/demo-project/my-ruby

Tag	Spec					Created			PullSpec							Image
latest	docker.io/openshift/ruby-20-centos7	Less than a second ago	docker.io/openshift/ruby-20-centos7@sha256:772c5bf9b2d1e8...	<same>

Copy to Clipboard

Toggle word wrap

--all 플래그를 추가하여 latest 대신 이미지의 모든 태그를 가져올 수도 있습니다.

OpenShift Container Platform의 대부분의 오브젝트와 마찬가지로 JSON 또는 YAML 정의를 파일에 작성하고 저장한 다음 CLI를 사용하여 오브젝트를 생성할 수도 있습니다. spec.dockerImageRepository 필드를 이미지의 Docker 가져오기 사양으로 설정합니다.
```
apiVersion: "v1"
kind: "ImageStream"
metadata:
  name: "my-ruby"
spec:
  dockerImageRepository: "docker.io/openshift/ruby-20-centos7"
```
```
apiVersion: "v1"
kind: "ImageStream"
metadata:
  name: "my-ruby"
spec:
  dockerImageRepository: "docker.io/openshift/ruby-20-centos7"
```
Copy to Clipboard Toggle word wrap
그런 다음 오브젝트를 생성합니다.
```
oc create -f <file>
```
```
$ oc create -f <file>
```
Copy to Clipboard Toggle word wrap

외부 Docker 레지스트리에서 이미지를 참조하는 이미지 스트림을 생성할 때 OpenShift Container Platform은 이미지에 대한 최신 정보를 얻기 위해 짧은 시간 내에 외부 레지스트리와 통신합니다.

태그 및 이미지 메타데이터가 동기화되면 이미지 스트림 오브젝트는 다음과 유사합니다.

apiVersion: v1
kind: ImageStream
metadata:
  name: my-ruby
  namespace: demo-project
  selflink: /oapi/v1/namespaces/demo-project/imagestreams/my-ruby
  uid: 5b9bd745-13d2-11e6-9a86-0ada84b8265d
  resourceVersion: '4699413'
  generation: 2
  creationTimestamp: '2016-05-06T21:34:48Z'
  annotations:
    openshift.io/image.dockerRepositoryCheck: '2016-05-06T21:34:48Z'
spec:
  dockerImageRepository: docker.io/openshift/ruby-20-centos7
  tags:
    -
      name: latest
      annotations: null
      from:
        kind: DockerImage
        name: 'docker.io/openshift/ruby-20-centos7:latest'
      generation: 2
      importPolicy: {  }
status:
  dockerImageRepository: '172.30.94.234:5000/demo-project/my-ruby'
  tags:
    -
      tag: latest
      items:
        -
          created: '2016-05-06T21:34:48Z'
          dockerImageReference: 'docker.io/openshift/ruby-20-centos7@sha256:772c5bf9b2d1e8e80742ed75aab05820419dc4532fa6d7ad8a1efddda5493dc3'
          image: 'sha256:772c5bf9b2d1e8e80742ed75aab05820419dc4532fa6d7ad8a1efddda5493dc3'
          generation: 2

apiVersion: v1
kind: ImageStream
metadata:
  name: my-ruby
  namespace: demo-project
  selflink: /oapi/v1/namespaces/demo-project/imagestreams/my-ruby
  uid: 5b9bd745-13d2-11e6-9a86-0ada84b8265d
  resourceVersion: '4699413'
  generation: 2
  creationTimestamp: '2016-05-06T21:34:48Z'
  annotations:
    openshift.io/image.dockerRepositoryCheck: '2016-05-06T21:34:48Z'
spec:
  dockerImageRepository: docker.io/openshift/ruby-20-centos7
  tags:
    -
      name: latest
      annotations: null
      from:
        kind: DockerImage
        name: 'docker.io/openshift/ruby-20-centos7:latest'
      generation: 2
      importPolicy: {  }
status:
  dockerImageRepository: '172.30.94.234:5000/demo-project/my-ruby'
  tags:
    -
      tag: latest
      items:
        -
          created: '2016-05-06T21:34:48Z'
          dockerImageReference: 'docker.io/openshift/ruby-20-centos7@sha256:772c5bf9b2d1e8e80742ed75aab05820419dc4532fa6d7ad8a1efddda5493dc3'
          image: 'sha256:772c5bf9b2d1e8e80742ed75aab05820419dc4532fa6d7ad8a1efddda5493dc3'
          generation: 2

Copy to Clipboard

Toggle word wrap

태그 추가를 Image Streams에 언급된 대로 oc tag 명령으로 --scheduled=true 플래그를 설정하여 예약된 간격으로 외부 레지스트리를 쿼리하도록 태그를 설정하여 태그 를 설정할 수 있습니다.

또는 태그 정의에서 importPolicy.scheduled 를 true 로 설정할 수 있습니다.

apiVersion: v1
kind: ImageStream
metadata:
  name: ruby
spec:
  tags:
  - from:
      kind: DockerImage
      name: openshift/ruby-20-centos7
    name: latest
    importPolicy:
      scheduled: true

apiVersion: v1
kind: ImageStream
metadata:
  name: ruby
spec:
  tags:
  - from:
      kind: DockerImage
      name: openshift/ruby-20-centos7
    name: latest
    importPolicy:
      scheduled: true

Copy to Clipboard

Toggle word wrap

13.7.1. Insecure Registries에서 이미지 가져오기
링크 복사

자체 서명된 인증서로 서명된 인증서 또는 HTTPS 대신 일반 HTTP를 사용하는 등 비보안 이미지 레지스트리에서 태그 및 이미지 메타데이터를 가져오도록 이미지 스트림을 구성할 수 있습니다.

이를 구성하려면 openshift.io/image.insecureRepository 주석을 추가하고 true 로 설정합니다. 이 설정은 레지스트리에 연결할 때 인증서 검증을 건너뜁니다.

kind: ImageStream
apiVersion: v1
metadata:
  name: ruby
  annotations:
    openshift.io/image.insecureRepository: "true" 
  spec:
    dockerImageRepository: my.repo.com:5000/myimage

kind: ImageStream
apiVersion: v1
metadata:
  name: ruby
  annotations:
    openshift.io/image.insecureRepository: "true"

1


  spec:
    dockerImageRepository: my.repo.com:5000/myimage

Copy to Clipboard

Toggle word wrap

1: openshift.io/image.insecureRepository 주석을 true로 설정합니다.

중요

이 옵션은 통합 레지스트리에서 이미지 스트림의 태그된 외부 이미지에 대해 안전하지 않은 전송으로 대체하도록 지시합니다. 이는 위험합니다. 가능한 경우 istag 를 안전하지 않은 상태로 표시 하여 이 위험을 피하십시오.

중요

위의 정의는 태그 및 이미지 메타데이터 가져오기에만 영향을 미칩니다. 이 이미지를 클러스터에서 사용하려면 (예: docker pull) 다음 중 하나가 true여야 합니다.

각 노드에는 dockerImageRepository 의 레지스트리 부분과 일치하는 --insecure-registry 플래그를 사용하여 Docker가 구성됩니다. 자세한 내용은 호스트 준비를 참조하십시오.
각 istag 사양에는 referencePolicy.type 이 Local 로 설정되어 있어야 합니다. 자세한 내용은 참조 정책을 참조하십시오.

13.7.1.1. 이미지 스트림 태그 정책
링크 복사

13.7.1.1.1. 비보안 태그 가져오기 정책
링크 복사

위의 주석은 특정 ImageStream 의 모든 이미지 및 태그에 적용됩니다. 세분화된 제어의 경우 istags 에 정책을 설정할 수 있습니다. 이 태그에 대한 이미지만 비보안 전송으로 허용하려면 태그 정의에서 importPolicy.insecure 를 true 로 설정합니다.

참고

특정 istag 아래에 있는 이미지에 대해 안전하지 않은 전송의 중단은 이미지 스트림에 insecure로 주석이 추가되거나 istag 에 비보안 가져오기 정책이 있는 경우 활성화됩니다. importPolicy.insecure' 를 false 로 설정하면 이미지 스트림 주석을 덮어쓸 수 없습니다.

13.7.1.1.2. 참조 정책
링크 복사

참조 정책을 사용하면 이 이미지 스트림 태그를 참조하는 리소스에서 이미지를 가져올 위치를 지정할 수 있습니다. 원격 이미지(외부 레지스트리에서 가져온 해당)에만 적용할 수 있습니다. 로컬 및 소스 에서 선택할 수있는 두 가지 옵션이 있습니다.

소스 정책은 클라이언트에게 이미지의 소스 레지스트리에서 직접 가져오도록 지시합니다. 클러스터에서 이미지를 관리하지 않는 한 통합 레지스트리는 포함되어 있지 않습니다. (외부 이미지가 아닙니다.) 이는 기본 정책입니다.

로컬 정책은 클라이언트에 항상 통합 레지스트리에서 가져오도록 지시합니다. 이 기능은 Docker 데몬 설정을 수정하지 않고 외부 비보안 레지스트리에서 가져오려는 경우 유용합니다.

이 정책은 이미지 스트림 태그 사용에만 영향을 미칩니다. 외부 레지스트리 위치를 사용하여 이미지를 직접 참조하거나 가져오는 구성 요소 또는 작업은 내부 레지스트리로 리디렉션되지 않습니다.

pull-through 기능

의 레지스트리는 클라이언트에 원격 이미지를 제공합니다. 로컬 참조 정책을 사용하도록 기본적으로 설정되어 있는 이 기능은 기본적으로 활성화되어 있어야 합니다. 또한 나중에 더 빠르게 액세스하기 위해 모든 Blob은 기본적으로 미러링됩니다.

이미지 스트림 태그 사양에서 정책을 referencePolicy.type 으로 설정할 수 있습니다.

로컬 참조 정책이 포함된 보안 태그의 예

kind: ImageStream
apiVersion: v1
metadata:
  name: ruby
  tags:
  - from:
      kind: DockerImage
      name: my.repo.com:5000/myimage
    name: mytag
    importPolicy:
      insecure: true 
    referencePolicy:
      type: Local

kind: ImageStream
apiVersion: v1
metadata:
  name: ruby
  tags:
  - from:
      kind: DockerImage
      name: my.repo.com:5000/myimage
    name: mytag
    importPolicy:
      insecure: true

1


    referencePolicy:
      type: Local

2

Copy to Clipboard

Toggle word wrap

1: 해당 레지스트리에 대한 비보안 연결을 사용하려면 tag mytag 를 설정합니다.
2: 외부 이미지를 가져올 수 있는 통합 레지스트리를 사용하려면 태그 mytag 를 설정합니다. 참조 정책 유형이 Source 로 설정된 경우 클라이언트는 my.repo.com:5000/myimage 에서 직접 이미지를 가져옵니다.

13.7.2. 프라이빗 레지스트리에서 이미지 가져오기
링크 복사

인증이 필요한 개인 이미지 레지스트리에서 태그 및 이미지 메타데이터를 가져오도록 이미지 스트림을 구성할 수 있습니다.

이를 구성하려면 인증 정보를 저장하는 데 사용되는 시크릿 을 생성해야 합니다. oc create secret 명령을 사용하여 보안 생성에 대한 지침은 Pod에서 다른 보안 레지스트리의 이미지를 참조하도록 허용 을 참조하십시오.

시크릿을 구성한 후 새 이미지 스트림 생성 또는 oc import-image 명령을 사용하여 진행합니다. 가져오기 프로세스 중에 OpenShift Container Platform은 시크릿을 선택하여 원격 당사자에게 제공합니다.

참고

비보안 레지스트리에서 가져올 때 보안에 정의된 레지스트리 URL에 :80 포트 접미사가 포함되어야 합니다. 그렇지 않으면 레지스트리에서 가져 오려고 할 때 시크릿이 사용되지 않습니다.

13.7.3. 외부 레지스트리에 대해 신뢰할 수 있는 인증서 추가
링크 복사

가져온 레지스트리가 표준 인증 기관에서 서명하지 않은 인증서를 사용하는 경우 레지스트리의 인증서 또는 서명 기관을 신뢰하도록 시스템을 명시적으로 구성해야 합니다. 이 작업은 레지스트리 가져오기 컨트롤러(일반적으로 마스터 노드)를 실행하는 호스트 시스템에 CA 인증서 또는 레지스트리 인증서를 추가하여 수행할 수 있습니다.

호스트 시스템에서 인증서 또는 CA 인증서를 /etc/pki/tls/certs 또는 /etc/pki/ca-trust 에 각각 추가해야 합니다. 또한 Red Hat 배포판에서 update-ca-trust 명령을 실행한 후 마스터 서비스를 다시 시작하여 인증서 변경 사항을 선택해야 합니다.

13.7.4. 프로젝트 간 이미지 가져오기
링크 복사

내부 레지스트리에서 태그 및 이미지 메타데이터를 가져오기 위해 이미지 스트림을 구성할 수 있지만 다른 프로젝트에서는 이미지 스트림을 구성할 수 있습니다. 이에 권장되는 방법은 이미지 스트림에 태그 추가와 같이 oc tag 명령을 사용하는 것입니다.

oc tag <source_project>/<image_stream>:<tag> <new_image_stream>:<new_tag>

$ oc tag <source_project>/<image_stream>:<tag> <new_image_stream>:<new_tag>

Copy to Clipboard

Toggle word wrap

또 다른 방법은 가져오기 사양을 사용하여 다른 프로젝트에서 이미지를 수동으로 가져오는 것입니다.

주의

다음 방법은 강력히 권장되지 않으며 oc tag 를 사용하는 이전이 충분하지 않은 경우에만 사용해야 합니다.

먼저 다른 프로젝트에 액세스하는 데 필요한 정책을 추가합니다.

oc policy add-role-to-group \
    system:image-puller \
    system:serviceaccounts:<destination_project> \
    -n <source_project>

$ oc policy add-role-to-group \
    system:image-puller \
    system:serviceaccounts:<destination_project> \
    -n <source_project>

Copy to Clipboard

Toggle word wrap

이렇게 하면 < destination_project >가 < source_project>에서 이미지를 가져올 수 있습니다.

정책을 사용하여 이미지를 수동으로 가져올 수 있습니다.

oc import-image <new_image_stream> --confirm \
    --from=<docker_registry>/<source_project>/<image_stream>

$ oc import-image <new_image_stream> --confirm \
    --from=<docker_registry>/<source_project>/<image_stream>

Copy to Clipboard

Toggle word wrap

13.7.5. 수동으로 이미지를 푸시하여 이미지 스트림 생성
링크 복사

내부 레지스트리로 이미지를 수동으로 푸시하여 이미지 스트림을 자동으로 생성할 수도 있습니다. 이는 OpenShift Container Platform 내부 레지스트리를 사용하는 경우에만 가능합니다.

이 절차를 수행하기 전에 다음 절차를 충족해야 합니다.

푸시해야 하는 대상 프로젝트가 이미 있어야 합니다.
해당 프로젝트에서 사용자는 {get, update} "imagestream/layers" 를 승인해야 합니다. 또한 이미지 스트림이 아직 존재하지 않으므로 해당 프로젝트에서 {create} "imagestream" 을 승인해야 합니다. 프로젝트 관리자인 경우 이러한 권한이 있습니다.

참고

system:image-pusher 역할은 새 이미지 스트림을 생성할 수 있는 권한을 부여하지 않으며, 이미지를 기존 이미지 스트림으로 푸시하기 위한 권한만 부여되지 않으므로 사용자에게 추가 권한이 부여되지 않은 한 아직 존재하지 않는 이미지 스트림으로 이미지를 푸시하는 데 사용할 수 없습니다.

이미지를 수동으로 푸시하여 이미지 스트림을 생성하려면 다음을 수행합니다.

먼저 내부 레지스트리에 로그인합니다.
그런 다음 적절한 내부 레지스트리 위치를 사용하여 이미지에 태그를 지정합니다. 예를 들어 docker.io/centos:centos7 이미지를 이미 로컬로 가져온 경우 다음을 수행합니다.
```
docker tag docker.io/centos:centos7 172.30.48.125:5000/test/my-image
```
```
$ docker tag docker.io/centos:centos7 172.30.48.125:5000/test/my-image
```
Copy to Clipboard Toggle word wrap

마지막으로 이미지를 내부 레지스트리로 푸시합니다. 예를 들어 다음과 같습니다.

docker push 172.30.48.125:5000/test/my-image

$ docker push 172.30.48.125:5000/test/my-image
The push refers to a repository [172.30.48.125:5000/test/my-image] (len: 1)
c8a648134623: Pushed
2bf4902415e3: Pushed
latest: digest: sha256:be8bc4068b2f60cf274fc216e4caba6aa845fff5fa29139e6e7497bb57e48d67 size: 6273

Copy to Clipboard

Toggle word wrap

이미지 스트림이 생성되었는지 확인합니다.

oc get is

$ oc get is
NAME       DOCKER REPO                        TAGS      UPDATED
my-image   172.30.48.125:5000/test/my-image   latest    3 seconds ago

Copy to Clipboard

Toggle word wrap

13.8. 이미지 스트림 변경 시 업데이트 트리거
링크 복사

이미지 스트림 태그가 새 이미지를 참조하도록 업데이트되면 OpenShift Container Platform은 이전 이미지를 사용하는 리소스로 새 이미지를 롤아웃하는 작업을 자동으로 수행할 수 있습니다. 이는 이미지 스트림 태그를 참조하는 리소스 유형에 따라 다양한 방식으로 구성됩니다.

13.8.1. OpenShift 리소스
링크 복사

ImageStreamTags를 변경하여 OpenShift DeploymentConfigs 및 BuildConfigs를 자동으로 트리거할 수 있습니다. 트리거된 작업은 업데이트된 ImageStreamTag에서 참조하는 이미지의 새 값을 사용하여 실행할 수 있습니다. 이 기능 사용에 대한 자세한 내용은 BuildConfig 트리거 및 DeploymentConfig 트리거 에 대한 설명서를 참조하십시오.

13.8.2. Kubernetes 리소스
링크 복사

API 정의의 일부로 포함된 DeploymentConfigs 및 BuildConfigs와 달리, Kubernetes 리소스에 트리거를 위한 필드가 없습니다. 대신 OpenShift Container Platform에서는 주석을 사용하여 사용자가 트리거를 요청할 수 있습니다. 주석은 다음과 같이 정의됩니다.

Key: image.openshift.io/triggers
Value: array of triggers, where each item has the schema:
[
 {
   "from" :{
     "kind": "ImageStreamTag", // required, the resource to trigger from, must be ImageStreamTag
     "name": "example:latest", // required, the name of an ImageStreamTag
     "namespace": "myapp",     // optional, defaults to the namespace of the object
   },
   // required, JSON path to change
   // Note that this field is limited today, and only accepts a very specific set
   // of inputs (a JSON path expression that precisely matches a container by ID or index).
   // For pods this would be "spec.containers[?(@.name='web')].image".
   "fieldPath": "spec.template.spec.containers[?(@.name='web')].image",
   // optional, set to true to temporarily disable this trigger.
   "paused": "false"
 },
 ...
]

Key: image.openshift.io/triggers
Value: array of triggers, where each item has the schema:
[
 {
   "from" :{
     "kind": "ImageStreamTag", // required, the resource to trigger from, must be ImageStreamTag
     "name": "example:latest", // required, the name of an ImageStreamTag
     "namespace": "myapp",     // optional, defaults to the namespace of the object
   },
   // required, JSON path to change
   // Note that this field is limited today, and only accepts a very specific set
   // of inputs (a JSON path expression that precisely matches a container by ID or index).
   // For pods this would be "spec.containers[?(@.name='web')].image".
   "fieldPath": "spec.template.spec.containers[?(@.name='web')].image",
   // optional, set to true to temporarily disable this trigger.
   "paused": "false"
 },
 ...
]

Copy to Clipboard

Toggle word wrap

OpenShift Container Platform에서 Pod 템플릿(예: CronJobs, Deployments, StatefulSets, DaemonSets, DaemonSets, Jobs, ReplicaSets, ReplicationControllers)을 모두 포함하는 코어 Kubernetes 리소스 중 하나를 확인하고 이 주석은 트리거에서 참조하는 ImageStreamTag와 현재 연결된 이미지를 사용하여 오브젝트를 업데이트하려고 합니다. 업데이트는 지정된 fieldPath에 대해 수행됩니다.

다음 예에서 example:latest 이미지 스트림 태그가 업데이트되면 트리거가 실행됩니다. 실행 시 웹 컨테이너에 대한 오브젝트의 Pod 템플릿 이미지 참조가 새 이미지 값으로 업데이트됩니다. 포드 템플릿이 배포 정의의 일부인 경우 pod 템플릿에 대한 변경으로 배포가 자동으로 트리거되어 새 이미지를 효과적으로 롤아웃합니다.

image.openshift.io/triggers=[{"from":{"kind":"ImageStreamTag","name":"example:latest"},"fieldPath":"spec.template.spec.containers[?(@.name='web')].image"}]

image.openshift.io/triggers=[{"from":{"kind":"ImageStreamTag","name":"example:latest"},"fieldPath":"spec.template.spec.containers[?(@.name='web')].image"}]

Copy to Clipboard

Toggle word wrap

Deployments에 이미지 트리거를 추가할 때 oc set triggers 명령을 사용할 수도 있습니다. 예를 들어 다음 명령은 example:latest 이미지 스트림 태그가 업데이트되면 배포 내의 web 컨테이너가 새 이미지 값으로 업데이트되도록 이미지 변경 트리거를 example이라는 배포에 추가합니다.

oc set triggers deploy/example --from-image=example:latest -c web

$ oc set triggers deploy/example --from-image=example:latest -c web

Copy to Clipboard

Toggle word wrap

배포를 일시 중지하지 않으면 이 pod 템플릿 업데이트로 인해 새 이미지 값으로 배포가 자동으로 수행됩니다.

13.9. 이미지 스트림 정의 작성
링크 복사

전체 이미지 스트림에 대한 이미지 스트림 정의를 작성하여 이미지 스트림을 정의할 수 있습니다. 이를 통해 oc 명령을 실행하지 않고 다른 클러스터에 정의를 배포할 수 있습니다.

이미지 스트림 정의는 이미지 스트림과 가져올 특정 태그에 대한 정보를 지정합니다.

이미지 스트림 오브젝트 정의

apiVersion: v1
kind: ImageStream
metadata:
  name: ruby
  annotations:
    openshift.io/display-name: Ruby 
spec:
  tags:
    - name: '2.0' 
      annotations:
        openshift.io/display-name: Ruby 2.0 
        description: >- 
          Build and run Ruby 2.0 applications on CentOS 7. For more information
          about using this builder image, including OpenShift considerations,
          see
          https://github.com/sclorg/s2i-ruby-container/tree/master/2.0/README.md.
        iconClass: icon-ruby 
        sampleRepo: 'https://github.com/sclorg/ruby-ex.git' 
        tags: 'builder,ruby' 
        supports: 'ruby' 
        version: '2.0' 
      from:
        kind: DockerImage 
        name: 'docker.io/openshift/ruby-20-centos7:latest'

apiVersion: v1
kind: ImageStream
metadata:
  name: ruby
  annotations:
    openshift.io/display-name: Ruby

1


spec:
  tags:
    - name: '2.0'

2


      annotations:
        openshift.io/display-name: Ruby 2.0

3


        description: >-

4


          Build and run Ruby 2.0 applications on CentOS 7. For more information
          about using this builder image, including OpenShift considerations,
          see
          https://github.com/sclorg/s2i-ruby-container/tree/master/2.0/README.md.
        iconClass: icon-ruby

5


        sampleRepo: 'https://github.com/sclorg/ruby-ex.git'

6


        tags: 'builder,ruby'

7


        supports: 'ruby'

8


        version: '2.0'

9


      from:
        kind: DockerImage

10


        name: 'docker.io/openshift/ruby-20-centos7:latest'

11

Copy to Clipboard

Toggle word wrap

1: 전체 이미지 스트림에 대한 간단하고 사용자에게 친숙한 이름입니다.
2: 이 태그를 버전이라고 합니다. 태그는 드롭다운 메뉴에 나타납니다.
3: 이미지 스트림 내에서 이 태그의 사용자에게 친숙한 이름입니다. 이 정보는 간략하고 적절한 경우 버전 정보를 포함해야 합니다.
4: 태그에 대한 설명으로, 사용자가 이미지를 제공하는 기능을 이해하기에 충분한 세부 정보가 포함되어 있습니다. 여기에는 추가 지침에 대한 링크가 포함될 수 있습니다. 설명을 몇 문장으로 제한하십시오.
5: 이 태그에 표시할 아이콘입니다. 가능한 경우 기존 로고 아이콘 에서 선택합니다. FontAwesome 및 Patternfly 의 아이콘도 사용할 수 있습니다. 또는 이미지 스트림을 사용하는 OpenShift Container Platform 클러스터에 추가할 수 있는 CSS 사용자 정의를 통해 아이콘을 제공합니다. 존재하는 아이콘 클래스를 지정하거나 일반 아이콘으로 대체되지 않도록 해야 합니다.
6: 이 빌더 이미지 태그와 함께 작동하고 샘플 실행 중인 애플리케이션을 생성하는 소스 리포지토리의 URL입니다.
7: 이미지 스트림 태그가 연결된 카테고리입니다. 카탈로그에 표시하려면 builder 태그가 필요합니다. 제공된 카탈로그 카테고리 중 하나와 연결하는 태그를 추가합니다. 콘솔 상수 파일에 있는 CATALOG_CATEGORIES 의 id 및 categoryAliases 를 참조합니다. 카테고리는 전체 클러스터에 맞게 사용자 지정할 수도 있습니다.
8: 이 이미지는 지원하는 언어입니다. 이 값은 oc new-app 호출 중에 잠재적인 빌더 이미지를 제공된 소스 리포지토리에 일치시키는 데 사용됩니다.
9: 이 태그의 버전 정보입니다.
10: 이 이미지 스트림 태그가 참조하는 오브젝트의 유형입니다. 유효한 값은 DockerImage,ImageStreamTag, ImageStreamImage 입니다.
11: 이 이미지 스트림 태그가 가져오는 오브젝트입니다.

ImageStream 에 정의할 수 있는 필드에 대한 자세한 내용은 Imagestream API 및 ImagestreamTag API 를 참조하십시오.

14장. 할당량 및 제한 범위
링크 복사

14.1. 개요
링크 복사

할당량 및 제한 범위를 사용하여 클러스터 관리자는 제한 조건을 설정하여 프로젝트에 사용되는 컴퓨팅 리소스의 수 또는 오브젝트 수를 제한할 수 있습니다. 이를 통해 클러스터 관리자는 모든 프로젝트에서 리소스를 보다 효율적으로 관리하고 할당할 수 있으며, 클러스터 크기에 적합한 프로젝트보다 많은 프로젝트가 사용되지 않도록 합니다.

개발자는 Pod 및 컨테이너 수준에서 컴퓨팅 리소스에 대한 요청 및 제한을 설정할 수도 있습니다.

다음 섹션에서는 할당량 및 제한 범위 설정, 제한 범위 설정, 제한 적용 방법 및 자체 Pod 및 컨테이너에서 컴퓨팅 리소스를 요청하거나 제한할 수 있는 방법을 이해하는 데 도움이 됩니다.

14.2. 할당량
링크 복사

ResourceQuota 오브젝트로 정의하는 리소스 할당량은 프로젝트당 집계 리소스 사용을 제한하는 제약 조건을 제공합니다. 이는 프로젝트에서 생성할 수 있는 오브젝트의 수량을 유형별로 제한하고 해당 프로젝트의 리소스에서 사용할 수 있는 컴퓨팅 리소스 및 스토리지의 총 양을 제한할 수 있습니다.

참고

할당량은 클러스터 관리자가 설정하며 지정된 프로젝트로 범위가 지정됩니다.

14.2.1. 할당량 보기
링크 복사

웹 콘솔에서 프로젝트의 할당량 페이지로 이동하면 프로젝트 할당량에 정의된 모든 하드 제한과 관련된 사용량 통계를 볼 수 있습니다.

CLI를 사용하여 할당량 세부 정보를 볼 수도 있습니다.

먼저 프로젝트에 정의된 할당량 목록을 가져옵니다. 예를 들어 demoproject라는 프로젝트의 경우 다음과 같습니다.
```
oc get quota -n demoproject
```
```
$ oc get quota -n demoproject
NAME                AGE
besteffort          11m
compute-resources   2m
core-object-counts  29m
```
Copy to Clipboard Toggle word wrap

그런 다음 관심 있는 할당량을 설명합니다(예: core-object-counts 할당량).

oc describe quota core-object-counts -n demoproject

$ oc describe quota core-object-counts -n demoproject
Name:			core-object-counts
Namespace:		demoproject
Resource		Used	Hard
--------		----	----
configmaps		3	10
persistentvolumeclaims	0	4
replicationcontrollers	3	20
secrets			9	10
services		2	10

Copy to Clipboard

Toggle word wrap

전체 할당량 정의는 오브젝트에서 oc export 를 실행하여 볼 수 있습니다. 다음은 몇 가지 샘플 할당량 정의를 보여줍니다.

core-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10" 
    persistentvolumeclaims: "4" 
    replicationcontrollers: "20" 
    secrets: "10" 
    services: "10"

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10"

1


    persistentvolumeclaims: "4"

2


    replicationcontrollers: "20"

3


    secrets: "10"

4


    services: "10"

5

Copy to Clipboard

Toggle word wrap

1: 프로젝트에 존재할 수 있는 총 ConfigMap 오브젝트 수입니다.
2: 프로젝트에 존재할 수 있는 총 PVC(영구 볼륨 클레임) 수입니다.
3: 프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다.
4: 프로젝트에 존재할 수 있는 총 시크릿 수입니다.
5: 프로젝트에 존재할 수 있는 총 서비스 수입니다.

openshift-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10"

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10"

1

Copy to Clipboard

Toggle word wrap

1: 프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.

compute-resources.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" 
    requests.cpu: "1" 
    requests.memory: 1Gi 
    limits.cpu: "2" 
    limits.memory: 2Gi

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"

1


    requests.cpu: "1"

2


    requests.memory: 1Gi

3


    limits.cpu: "2"

4


    limits.memory: 2Gi

5

Copy to Clipboard

Toggle word wrap

1: 프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.
2: 터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 코어 1개를 초과할 수 없습니다.
3: 터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 1Gi를 초과할 수 없습니다.
4: 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 코어 2개를 초과할 수 없습니다.
5: 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 2Gi를 초과할 수 없습니다.

besteffort.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1" 
  scopes:
  - BestEffort

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1"

1


  scopes:
  - BestEffort

2

Copy to Clipboard

Toggle word wrap

1: 프로젝트에 존재할 수 있는 BestEffort quality가 있는 터미널이 아닌 상태의 총 Pod 수입니다.
2: 메모리 또는 CPU에 대해 서비스 품질이 BestEffort 인 일치하는 Pod로만 할당량을 제한합니다.

compute-resources-long-running.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4" 
    limits.cpu: "4" 
    limits.memory: "2Gi" 
  scopes:
  - NotTerminating

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4"

1


    limits.cpu: "4"

2


    limits.memory: "2Gi"

3


  scopes:
  - NotTerminating

4

Copy to Clipboard

Toggle word wrap

1: 터미널이 아닌 상태의 총 Pod 수입니다.
2: 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
3: 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
4: 할당량을 spec.activeDeadlineSeconds가 nil로 설정된 일치하는 Pod로만 제한합니다. 빌드 Pod는 RestartNever 정책을 적용하지 않는 한 NotTerminating에 해당합니다.

compute-resources-time-bound.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2" 
    limits.cpu: "1" 
    limits.memory: "1Gi" 
  scopes:
  - Terminating

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2"

1


    limits.cpu: "1"

2


    limits.memory: "1Gi"

3


  scopes:
  - Terminating

4

Copy to Clipboard

Toggle word wrap

1: 터미널이 아닌 상태의 총 Pod 수입니다.
2: 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
3: 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
4: 할당량을 spec.activeDeadlineSeconds >=0인 일치하는 Pod로만 제한합니다. 예를 들어 이 할당량은 빌드 또는 배포자 Pod에 대해 부과되지만 웹 서버 또는 데이터베이스와 같이 오래 실행되는 Pod는 아닙니다.

storage-consumption.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10" 
    requests.storage: "50Gi" 
    gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 
    silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 
    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 
    bronze.storageclass.storage.k8s.io/requests.storage: "0" 
    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0"

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10"

1


    requests.storage: "50Gi"

2


    gold.storageclass.storage.k8s.io/requests.storage: "10Gi"

3


    silver.storageclass.storage.k8s.io/requests.storage: "20Gi"

4


    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5"

5


    bronze.storageclass.storage.k8s.io/requests.storage: "0"

6


    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0"

7

Copy to Clipboard

Toggle word wrap

1: 프로젝트의 총 영구 볼륨 클레임 수
2: 프로젝트의 모든 영구 볼륨 클레임에서 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
3: 프로젝트의 모든 영구 볼륨 클레임에서 골드 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
4: 프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
5: 프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스의 총 클레임 수는 이 값을 초과할 수 없습니다.
6: 프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 스토리지를 요청할 수 없습니다.
7: 프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 클레임을 생성할 수 없습니다.

14.2.2. 할당량으로 관리되는 리소스
링크 복사

다음은 할당량으로 관리할 수 있는 컴퓨팅 리소스 및 오브젝트 유형 세트를 설명합니다.

참고

status.phase in (Failed, Succeeded)이 True인 경우 Pod는 터미널 상태에 있습니다.

Expand

표 14.1. 할당량으로 관리되는 컴퓨팅 리소스
리소스 이름	설명
`cpu`	터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. `cpu` 및 `requests.cpu` 는 동일한 값이며 서로 바꿔 사용할 수 있습니다.
`memory`	터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. `memory` 및 `requests.memory` 는 동일한 값이며 서로 바꿔 사용할 수 있습니다.
`requests.cpu`	터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. `cpu` 및 `requests.cpu` 는 동일한 값이며 서로 바꿔 사용할 수 있습니다.
`requests.memory`	터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. `memory` 및 `requests.memory` 는 동일한 값이며 서로 바꿔 사용할 수 있습니다.
`limits.cpu`	터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
`limits.memory`	터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.

Expand

표 14.2. 할당량으로 관리되는 스토리지 리소스
리소스 이름	설명
`requests.storage`	상태와 관계없이 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다.
`persistentVolumeClaims`	프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다.
`<storage-class-name>.storageclass.storage.k8s.io/requests.storage`	상태와 관계없이 일치하는 스토리지 클래스가 있는 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다.
`<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims`	프로젝트에 존재할 수 있는, 일치하는 스토리지 클래스가 있는 총 영구 볼륨 클레임 수입니다.

Expand

표 14.3. 할당량으로 관리되는 오브젝트 수
리소스 이름	설명
`pods`	프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.
`ReplicationControllers`	프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다.
`resourcequotas`	프로젝트에 존재할 수 있는 총 리소스 할당량 수입니다.
`services`	프로젝트에 존재할 수 있는 총 서비스 수입니다.
`secrets`	프로젝트에 존재할 수 있는 총 시크릿 수입니다.
`configmaps`	프로젝트에 존재할 수 있는 총 `ConfigMap` 오브젝트 수입니다.
`persistentVolumeClaims`	프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다.
`openshift.io/imagestreams`	프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.

14.2.3. 할당량 범위
링크 복사

각 할당량에는 일련의 관련 범위가 있을 수 있습니다. 할당량은 열거된 범위의 교집합과 일치하는 경우에만 리소스의 사용량을 측정합니다.

할당량에 범위를 추가하면 할당량을 적용할 수 있는 리소스 세트가 제한됩니다. 허용된 설정을 벗어난 리소스를 지정하면 검증 오류가 발생합니다.

Expand

범위	설명
Terminating	`spec.activeDeadlineSeconds©= 0`인 Pod와 일치합니다.
NotTerminating	`spec.activeDeadlineSeconds`가 `nil`인 Pod와 일치합니다.
BestEffort	`cpu` 또는 `memory` 에 대해 최상의 작업 품질을 제공하는 Pod와 일치합니다. 컴퓨팅 리소스 커밋에 대한 자세한 내용은 QoS 클래스를 참조하십시오.
NotBestEffort	`cpu` 및 `memory` 에 최상의 작업 품질을 제공하지 않는 Pod와 일치합니다.

BestEffort 범위는 할당량을 제한하여 다음 리소스를 제한합니다.

pods

Terminating,NotTerminating, NotBestEffort 범위는 할당량을 제한하여 다음 리소스를 추적합니다.

pods
memory
requests.memory
limits.memory
cpu
requests.cpu
limits.cpu

14.2.4. 할당량 적용
링크 복사

프로젝트에 대한 리소스 할당량이 처음 생성되면 프로젝트에서 업데이트된 사용량 통계를 계산할 때까지 할당량 제약 조건을 위반할 수 있는 새 리소스 생성 기능을 제한합니다.

할당량이 생성되고 사용량 통계가 업데이트되면 프로젝트에서 새 콘텐츠 생성을 허용합니다. 리소스를 생성하거나 수정할 때는 리소스 생성 또는 수정 요청에 따라 할당량 사용이 즉시 증가합니다.

리소스를 삭제할 때는 프로젝트에 대한 다음 할당량 통계 전체 재계산 중 할당량 사용이 감소합니다. 프로젝트 수정이 할당량 사용 제한을 초과하면 서버에서 작업을 거부합니다. 할당량 제약 조건을 위반하는 적절한 오류 메시지와 현재 관찰된 사용량 통계가 시스템에 설명되어 있습니다.

14.2.5. 요청 Versus Limits
링크 복사

컴퓨팅 리소스를 할당할 때 각 컨테이너는 CPU 및 메모리에 대해 각각 요청 및 제한 값을 지정할 수 있습니다. 할당량은 이러한 값 중을 제한할 수 있습니다.

할당량에 requests.cpu 또는 requests.memory 에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스를 명시적으로 요청해야 합니다. 할당량에 limits.cpu 또는 limits.memory 에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스에 대한 제한을 명시적으로 지정해야 합니다.

Pod 및 컨테이너에서 요청 및 제한을 설정하는 방법에 대한 자세한 내용은 컴퓨팅 리소스를 참조하십시오.

14.3. 제한 범위
링크 복사

LimitRange 오브젝트에서 정의하는 제한 범위는 Pod, 컨테이너, 이미지 스트림 및 영구 볼륨 클레임 수준에서 프로젝트의 컴퓨팅 리소스 제약 조건을 열거하고, Pod, 컨테이너, 이미지 스트림 또는 영구 볼륨 클레임에서 사용할 수 있는 리소스 양을 지정합니다.

모든 리소스 생성 및 수정 요청은 프로젝트의 각 LimitRange 오브젝트에 대해 평가됩니다. 리소스가 열거된 제약 조건을 위반하는 경우 리소스가 거부됩니다. 리소스에서 명시적 값을 설정하지 않고 제약 조건에서 기본값을 지원하는 경우 기본값이 리소스에 적용됩니다.

참고

제한 범위는 클러스터 관리자가 설정하며 지정된 프로젝트로 범위가 지정됩니다.

14.3.1. 제한 범위 보기
링크 복사

웹 콘솔에서 프로젝트의 할당량 페이지로 이동하면 프로젝트에 정의된 제한 범위를 볼 수 있습니다.

CLI를 사용하여 제한 범위 세부 정보를 볼 수도 있습니다.

먼저 프로젝트에 정의된 제한 범위 목록을 가져옵니다. 예를 들어 demoproject라는 프로젝트의 경우 다음과 같습니다.
```
oc get limits -n demoproject
```
```
$ oc get limits -n demoproject
NAME              AGE
resource-limits   6d
```
Copy to Clipboard Toggle word wrap

그런 다음 관심 있는 제한 범위(예: resource-limits 제한 범위)를 설명합니다.

oc describe limits resource-limits -n demoproject

$ oc describe limits resource-limits -n demoproject
Name:                           resource-limits
Namespace:                      demoproject
Type                            Resource                Min     Max     Default Request Default Limit   Max Limit/Request Ratio
----                            --------                ---     ---     --------------- -------------   -----------------------
Pod                             cpu                     200m    2       -               -               -
Pod                             memory                  6Mi     1Gi     -               -               -
Container                       cpu                     100m    2       200m            300m            10
Container                       memory                  4Mi     1Gi     100Mi           200Mi           -
openshift.io/Image              storage                 -       1Gi     -               -               -
openshift.io/ImageStream        openshift.io/image      -       12      -               -               -
openshift.io/ImageStream        openshift.io/image-tags -       10      -               -               -

Copy to Clipboard

Toggle word wrap

개체에서 oc export 를 실행하여 전체 제한 범위 정의를 볼 수 있습니다. 다음은 제한 범위 정의의 예를 보여줍니다.

코어 제한 범위 오브젝트 정의

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits" 
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2" 
        memory: "1Gi" 
      min:
        cpu: "200m" 
        memory: "6Mi" 
    - type: "Container"
      max:
        cpu: "2" 
        memory: "1Gi" 
      min:
        cpu: "100m" 
        memory: "4Mi" 
      default:
        cpu: "300m" 
        memory: "200Mi" 
      defaultRequest:
        cpu: "200m" 
        memory: "100Mi" 
      maxLimitRequestRatio:
        cpu: "10"

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits"

1


spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2"

2


        memory: "1Gi"

3


      min:
        cpu: "200m"

4


        memory: "6Mi"

5


    - type: "Container"
      max:
        cpu: "2"

6


        memory: "1Gi"

7


      min:
        cpu: "100m"

8


        memory: "4Mi"

9


      default:
        cpu: "300m"

10


        memory: "200Mi"

11


      defaultRequest:
        cpu: "200m"

12


        memory: "100Mi"

13


      maxLimitRequestRatio:
        cpu: "10"

14

Copy to Clipboard

Toggle word wrap

1: 제한 범위 오브젝트의 이름입니다.
2: Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최대 CPU 양입니다.
3: Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최대 메모리 양입니다.
4: Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최소 CPU 양입니다.
5: Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최소 메모리 양입니다.
6: Pod의 단일 컨테이너에서 요청할 수 있는 최대 CPU 양입니다.
7: Pod의 단일 컨테이너에서 요청할 수 있는 최대 메모리 양입니다.
8: Pod의 단일 컨테이너에서 요청할 수 있는 최소 CPU 양입니다.
9: Pod의 단일 컨테이너에서 요청할 수 있는 최소 메모리 양입니다.
10: 지정되지 않은 경우 컨테이너가 사용하도록 제한될 기본 CPU 양입니다.
11: 지정되지 않은 경우 컨테이너에서 사용할 기본 메모리 양입니다.
12: 지정되지 않은 경우 컨테이너에서 사용할 기본 CPU 양입니다.
13: 지정되지 않은 경우 컨테이너에서 사용할 기본 메모리 양입니다.
14: 컨테이너가 요청 이상의 제한 비율로 만들 수 있는 최대 CPU 버스트입니다.

CPU 및 메모리 측정 방법에 대한 자세한 내용은 Compute Resources 를 참조하십시오.

14.3.2. 컨테이너 제한
링크 복사

지원되는 리소스:

CPU
메모리

지원되는 제한 조건:

지정된 경우 컨테이너당 true를 유지해야 합니다.

Expand

표 14.4. 컨테이너
제약 조건	동작
`분`	`min[resource]` less than or equal to `container.resources.requests[resource]` (필수) `container/resources.limits[resource]` (선택 사항) 구성에서 `min` CPU를 정의하는 경우 요청 값은 CPU 값보다 커야 합니다. 제한 값을 지정할 필요가 없습니다.
`max`	`container.resources.limits[resource]` (필수) `Max[resource]` 구성에서 `max` CPU를 정의하는 경우 요청 값을 정의할 필요가 없지만 최대 CPU 제약 조건을 충족하는 제한 값을 설정해야 합니다.
`MaxLimitRequestRatio`	`maxLimitRequestRatio[resource]` less than or equal to ( `container.resources.limits[resource]` / `container.resources.requests[resource]`) 구성에서 `maxLimitRequestRatio` 값을 정의하는 경우 새 컨테이너에 request 및 limit 값이 모두 있어야 합니다. 또한 OpenShift Container Platform은 제한 요청을 통해 제한을 분할하여 요청 비율을 요청하는 제한을 계산합니다. 이 값은 음수가 아닌 1보다 큰 정수여야 합니다. 예를 들어 컨테이너에 `limit` 값에 `cpu: 500` 이 있고 `request` 값에 `cpu: 100` 이 있는 경우 `cpu` 의 요청 비율은 `5` 입니다. 이 비율은 `maxLimitRequestRatio`보다 작거나 같아야 합니다.

지원되는 기본값:

default[resource]: 기본값은 container.resources.limit[resource] to specified value if none입니다.
기본 Requests[resource]: 기본값은 container.resources.requests[resource] 를 지정하지 않은 경우 값을 지정합니다.

14.3.3. Pod 제한
링크 복사

지원되는 리소스:

CPU
메모리

지원되는 제한 조건:

Pod의 모든 컨테이너에서 다음 사항이 충족되어야 합니다.

Expand

표 14.5. Pod
제약 조건	실행 동작
`분`	`min[resource]` less than or equal to `container.resources.requests[resource]` (필수) `container.resources.limits[resource]` (선택 사항)
`max`	`container.resources.limits[resource]` (필수) `Max[resource]`
`MaxLimitRequestRatio`	`maxLimitRequestRatio[resource]` less than or equal to ( `container.resources.limits[resource]` / `container.resources.requests[resource]`)

14.4. 컴퓨팅 리소스
링크 복사

노드에서 실행되는 각 컨테이너는 컴퓨팅 리소스를 사용하는데, 이는 측정 가능한 수량으로, 요청, 할당 및 소비될 수 있습니다.

Pod 구성 파일을 작성할 때 클러스터의 Pod를 더 잘 예약하고 만족스러운 성능을 보장하기 위해 각 컨테이너에 필요한 CPU 및 메모리(RAM)를 선택적으로 지정할 수 있습니다.

CPU는 밀리코어라는 단위로 측정됩니다. 클러스터의 각 노드는 운영 체제를 검사하여 노드의 CPU 코어 양을 확인한 다음 해당 값을 1000으로 곱하여 총 용량을 표시합니다. 예를 들어 노드에 2개의 코어가 있는 경우 노드의 CPU 용량이 2000m로 표시됩니다. 단일 코어의/10을 사용하려면 100m로 표시됩니다.

메모리는 바이트 단위로 측정됩니다. 또한SI와 함께 사용할 수 있습니다 (E, P, T, G, M, K) 또는 전원 2개 -equivalents (Ei, Pi, Ti, Mi, Ki)와 함께 사용할 수 있습니다.

apiVersion: v1
kind: Pod
spec:
  containers:
  - image: openshift/hello-openshift
    name: hello-openshift
    resources:
      requests:
        cpu: 100m 
        memory: 200Mi 
      limits:
        cpu: 200m 
        memory: 400Mi

apiVersion: v1
kind: Pod
spec:
  containers:
  - image: openshift/hello-openshift
    name: hello-openshift
    resources:
      requests:
        cpu: 100m

1


        memory: 200Mi

2


      limits:
        cpu: 200m

3


        memory: 400Mi

4

Copy to Clipboard

Toggle word wrap

1: 컨테이너는 100m CPU를 요청합니다.
2: 컨테이너는 200Mi 메모리를 요청합니다.
3: 컨테이너는 200m CPU를 제한합니다.
4: 컨테이너는 400Mi 메모리를 제한합니다.

14.4.1. CPU 요청
링크 복사

Pod의 각 컨테이너는 노드에 요청하는 CPU 양을 지정할 수 있습니다. 스케줄러는 CPU 요청을 사용하여 컨테이너에 적합한 노드를 찾습니다.

CPU 요청은 컨테이너에서 사용할 수 있는 최소 CPU 양을 나타내지만 CPU에 대한 경합이 없는 경우 노드에서 사용 가능한 모든 CPU를 사용할 수 있습니다. 노드에 CPU 경합이 있는 경우 CPU 요청은 컨테이너에서 사용할 수 있는 CPU 시간 동안 시스템의 모든 컨테이너에서 상대적 가중치를 제공합니다.

노드에서 CPU 요청은 커널 CFS 공유에 매핑되어 이 동작을 적용합니다.

14.4.2. 컴퓨팅 리소스 보기
링크 복사

Pod의 컴퓨팅 리소스를 보려면 다음을 수행합니다.

oc describe pod ruby-hello-world-tfjxt

$ oc describe pod ruby-hello-world-tfjxt
Name:       ruby-hello-world-tfjxt
Namespace:      default
Image(s):     ruby-hello-world
Node:       /
Labels:       run=ruby-hello-world
Status:       Pending
Reason:
Message:
IP:
Replication Controllers:  ruby-hello-world (1/1 replicas created)
Containers:
  ruby-hello-world:
    Container ID:
    Image ID:
    Image:    ruby-hello-world
    QoS Tier:
      cpu:  Burstable
      memory: Burstable
    Limits:
      cpu:  200m
      memory: 400Mi
    Requests:
      cpu:    100m
      memory:   200Mi
    State:    Waiting
    Ready:    False
    Restart Count:  0
    Environment Variables:

Copy to Clipboard

Toggle word wrap

14.4.3. CPU 제한
링크 복사

Pod의 각 컨테이너는 노드에서 사용하도록 제한되는 CPU 양을 지정할 수 있습니다. CPU 제한은 컨테이너에서 노드와의 경합과 관계없이 컨테이너에서 사용할 수 있는 최대 CPU 양을 제어합니다. 컨테이너가 지정된 제한을 초과하려고 하면 시스템이 컨테이너를 제한합니다. 이를 통해 컨테이너는 노드에 예약된 Pod 수와 관계없이 일관된 서비스 수준을 유지할 수 있습니다.

14.4.4. 메모리 요청
링크 복사

기본적으로 컨테이너는 노드에서 최대한 많은 메모리를 사용할 수 있습니다. 클러스터에서 Pod 배치를 개선하려면 컨테이너를 실행하는 데 필요한 메모리 양을 지정합니다. 그러면 스케줄러는 Pod를 노드에 바인딩하기 전에 사용 가능한 노드 메모리 용량을 고려합니다. 컨테이너는 요청을 지정할 때에도 노드에서 최대한 많은 메모리를 사용할 수 있습니다.

14.4.5. 메모리 제한
링크 복사

메모리 제한을 지정하면 컨테이너에서 사용할 수 있는 메모리 양을 제한할 수 있습니다. 예를 들어 제한을 200Mi로 지정하면 노드에서 해당 양의 메모리를 사용하는 컨테이너가 제한됩니다. 컨테이너가 지정된 메모리 제한을 초과하면 종료되고 컨테이너 재시작 정책에 따라 영향을 받을 수 있습니다.

14.4.6. 서비스 계층 (Quality of Service Tiers)
링크 복사

생성된 컴퓨팅 리소스는 QoS( Quality of Service )로 분류됩니다. 세 개의 계층이 있으며 각각 각 리소스에 지정된 요청 및 제한 값을 기반으로 합니다.

Expand

서비스 품질	설명
BestEffort	요청 및 제한이 지정되지 않은 경우 제공됩니다.
Burstable	지정된 제한보다 작은 요청이 지정된 경우 제공됩니다.
Guaranteed	지정된 요청과 동일한 제한이 지정될 때 제공됩니다.

컨테이너에 요청 및 제한이 설정되어 각 컴퓨팅 리소스에 대해 다른 서비스 품질을 초래하는 경우 Burstable 로 분류됩니다.

서비스 품질은 리소스가 압축 가능한지 여부에 따라 다양한 리소스에 영향을 미칩니다. CPU는 압축할 수 있는 리소스인 반면 메모리는 압축할 수 없는 리소스입니다.

CPU 리소스가 있는 경우:

BestEffort CPU 컨테이너는 노드에서 사용 가능한 만큼의 CPU를 사용할 수 있지만 가장 낮은 우선 순위로 실행됩니다.
Burstable CPU 컨테이너는 요청된 최소 CPU 양을 받을 수 있도록 보장되지만 추가 CPU 시간을 얻지 못할 수도 있습니다. 초과 CPU 리소스는 노드의 모든 컨테이너에서 요청된 양을 기반으로 배포됩니다.
Guaranteed CPU 컨테이너는 추가 CPU 사이클이 있더라도 요청된 양을 받을 수 있으며 더 이상 제공되지 않습니다. 이는 노드의 다른 활동과 관계없이 일관된 성능 수준을 제공합니다.

메모리 리소스의 경우:

BestEffort 메모리 컨테이너는 노드에서 사용할 수 있는 만큼의 메모리를 사용할 수 있지만 스케줄러가 메모리가 충분한 노드에 해당 컨테이너를 요구 사항을 충족할 수 있다는 보장은 없습니다. 또한 BestEffort 컨테이너는 노드에 메모리 이벤트가 부족하면 종료될 가능성이 가장 큽니다.
Burstable 메모리 컨테이너는 요청된 메모리 양을 얻기 위해 노드에 예약되지만 더 많이 사용할 수 있습니다. 노드에 메모리 부족 이벤트가 있는 경우 메모리를 복구하려고 할 때 BestEffort 컨테이너를 수행한 후 Burstable 컨테이너가 종료될 수 있습니다.
Guaranteed 메모리 컨테이너는 요청된 메모리의 양을 가져오지만 더 이상은 제공되지 않습니다. 메모리 부족 이벤트가 발생하는 경우 시스템에 더 이상 BestEffort 또는 Burstable 컨테이너가 없는 경우에만 종료됩니다.

14.4.7. CLI를 통해 컴퓨팅 리소스 지정
링크 복사

CLI를 통해 컴퓨팅 리소스를 지정하려면 다음을 수행합니다.

oc run ruby-hello-world --image=ruby-hello-world --limits=cpu=200m,memory=400Mi --requests=cpu=100m,memory=200Mi

$ oc run ruby-hello-world --image=ruby-hello-world --limits=cpu=200m,memory=400Mi --requests=cpu=100m,memory=200Mi

Copy to Clipboard

Toggle word wrap

14.4.8. 불투명 정수 리소스
링크 복사

opaque 정수 리소스를 사용하면 클러스터 운영자가 시스템에서 알 수 없는 새 노드 수준 리소스를 제공할 수 있습니다. 사용자는 CPU 및 메모리와 유사하게 Pod 사양에서 이러한 리소스를 사용할 수 있습니다. 스케줄러는 사용 가능한 양보다 더 많은 용량이 Pod에 동시에 할당되지 않도록 리소스 계정을 수행합니다.

참고

불투명 정수 리소스는 현재 Alpha이며 리소스 계정만 구현됩니다. 이러한 리소스에 대한 리소스 할당량 또는 제한 범위 지원은 없으며 QoS에 영향을 미치지 않습니다.

OpenShift Container Platform은 리소스가 무엇인지 알 수 없지만 해당 리소스를 충분히 사용할 수 있는 경우에만 노드에 Pod를 예약하므로 opaque 정수 리소스는 opaque라고 합니다. 정수 리소스(예: 정수 리소스 )를 사용할 수 있거나 정수 단위로 광고 해야 하기 때문에 정수 리소스라고 합니다. API 서버는 이러한 리소스의 수량을 정수로 제한합니다. 유효한 수량의 예는 3,3000m 및 3Ki 입니다.

클러스터 관리자는 일반적으로 리소스를 생성하고 사용 가능하게 만듭니다. 불투명 정수 리소스 생성에 대한 자세한 내용은 관리자 가이드의 Opaque Integer Resources 을 참조하십시오.

포드에서 opaque 정수 리소스를 사용하려면 Pod를 편집하여 opaque 리소스의 이름을 spec.containers[].resources.requests 필드의 키로 포함하도록 Pod를 편집합니다.

예를 들어 다음 Pod는 두 개의 CPU와 하나의 foo ( opaque 리소스)를 요청합니다.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        pod.alpha.kubernetes.io/opaque-int-resource-foo: 1

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myimage
    resources:
      requests:
        cpu: 2
        pod.alpha.kubernetes.io/opaque-int-resource-foo: 1

Copy to Clipboard

Toggle word wrap

Pod는 모든 리소스 요청이 충족되는 경우에만 예약됩니다(CPU, 메모리, 모든 불투명 리소스 포함). 포드는 PENDING 상태로 유지되지만 모든 노드에서 리소스 요청을 충족할 수 없습니다.

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  FirstSeen  LastSeen	Count	From		  SubObjectPath	Type	  Reason	    Message
  ---------  --------	-----	----		  -------------	--------  ------	    -------
  14s	     0s		6	default-scheduler		Warning	  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient pod.alpha.kubernetes.io/opaque-int-resource-foo (1).

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  FirstSeen  LastSeen	Count	From		  SubObjectPath	Type	  Reason	    Message
  ---------  --------	-----	----		  -------------	--------  ------	    -------
  14s	     0s		6	default-scheduler		Warning	  FailedScheduling  No nodes are available that match all of the following predicates:: Insufficient pod.alpha.kubernetes.io/opaque-int-resource-foo (1).

Copy to Clipboard

Toggle word wrap

14.5. 프로젝트 리소스 제한
링크 복사

클러스터 관리자가 프로젝트별로 리소스 제한을 설정할 수 있습니다. 개발자는 이러한 제한을 생성, 편집 또는 삭제할 수 있는 기능은 없지만 액세스 권한이 있는 프로젝트의 경우 볼 수 있습니다.

15장. Pod Presets를 사용하여 포드에 정보 삽입
링크 복사

15.1. 개요
링크 복사

Pod 사전 설정은 Pod 에 사용자 지정 정보를 생성하는 대로 해당 정보를 삽입하는 오브젝트입니다.

중요

OpenShift Container Platform 3.7부터 Pod 사전 설정은 더 이상 지원되지 않습니다.

Pod 사전 설정 오브젝트를 사용하여 삽입할 수 있습니다.

Secret 오브젝트
ConfigMap 오브젝트
스토리지 볼륨
컨테이너 볼륨 마운트
환경 변수

개발자는 Pod 레이블이 PodPreset의 라벨 선택기와 일치하는지 확인하여 해당 정보를 Pod에 추가합니다. Pod의 레이블 은 Pod를 일치하는 라벨 선택기 가 있는 하나 이상의 Pod 사전 설정 오브젝트와 연결합니다.

개발자는 포드 사전 설정을 사용하여 Pod에서 사용할 서비스에 대한 세부 정보를 알 필요 없이 포드를 프로비저닝할 수 있습니다. 관리자는 개발자가 포드를 배포하지 않고 개발자의 구성 항목을 보이지 않게 유지할 수 있습니다. 예를 들어 관리자는 시크릿 및 환경 변수를 통해 데이터베이스의 이름, 사용자 이름 및 암호를 제공하는 Pod 사전 설정을 생성할 수 있습니다. 포드 개발자는 Pod의 모든 정보를 포함하는 데 사용할 레이블을 알고 있어야 합니다. 개발자는 Pod 사전 설정을 생성하고 동일한 모든 작업을 수행할 수도 있습니다. 예를 들어 개발자는 환경 변수를 여러 포드에 자동으로 삽입하는 사전 설정을 생성할 수 있습니다.

Pod 사전 설정이 Pod에 적용되면 OpenShift Container Platform은 Pod 사양을 수정하여 삽입 가능한 데이터를 추가하고 Pod 사양에서 사전 설정한 Pod에 의해 수정되었음을 표시합니다. 주석은 양식의 일부입니다.

podpreset.admission.kubernetes.io/<pod-preset name>: `resource version`

podpreset.admission.kubernetes.io/<pod-preset name>: `resource version`

Copy to Clipboard

Toggle word wrap

클러스터에서 Pod 사전 설정을 사용하려면 다음을 수행합니다.

관리자는 /etc/origin/master/master -config.yaml 을 통해 Pod 사전 설정 승인 컨트롤러 플러그인을 활성화해야 합니다.
Pod 사전 설정자는 Pod 사전 설정을 통해 API 유형 settings.k8s.io/v1alpha1/podpreset 을 활성화하고 Pod 사전 설정 포드에 삽입 가능한 정보를 추가해야 합니다.

포드 생성에 오류가 발생하면 Pod가 사전 설정된 Pod의 삽입 리소스 없이 Pod가 생성됩니다.

Pod 사양에서 podpreset.admission.kubernetes.io/exclude: "true" 매개변수를 사용하여 Pod 사전 정의된 변경 사항으로 특정 Pod를 제외할 수 있습니다. 아래 Pod 사양 예를 참조하십시오.

참고

Pod Preset 기능은 서비스 카탈로그 가 설치된 경우에만 사용할 수 있습니다.

Pod 사전 설정 오브젝트 샘플

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1 
metadata:
  name: allow-database 
spec:
  selector:
    matchLabels:
      role: frontend 
  env:
    - name: DB_PORT 
      value: "6379" 
  envFrom:
    - configMapRef: 
      name: etcd-env-config
    - secretKeyRef: 
      name: test-secret
  volumeMounts: 
    - mountPath: /cache
      name: cache-volume
  volumes: 
    - name: cache-volume
      emptyDir: {}

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1

1


metadata:
  name: allow-database

2


spec:
  selector:
    matchLabels:
      role: frontend

3


  env:
    - name: DB_PORT

4


      value: "6379"

5


  envFrom:
    - configMapRef:

6


      name: etcd-env-config
    - secretKeyRef:

7


      name: test-secret
  volumeMounts:

8


    - mountPath: /cache
      name: cache-volume
  volumes:

9


    - name: cache-volume
      emptyDir: {}

Copy to Clipboard

Toggle word wrap

1: settings.k8s.io/v1alpha1 API를 지정합니다.
2: 사전 정의된 Pod의 이름입니다. 이 이름은 Pod 주석에 사용됩니다.
3: Pod 사양의 라벨과 일치하는 라벨 선택기입니다.
4 5: 컨테이너에 전달할 환경 변수를 생성합니다.
6: Pod 사양에 ConfigMap 을 추가합니다.
7: Pod 사양에 보안 오브젝트를 추가합니다.
8: 컨테이너 내에서 외부 스토리지 볼륨을 마운트해야 하는 위치를 지정합니다.
9: 컨테이너에서 사용할 수 있는 스토리지 볼륨을 정의합니다.

Pod 사양 샘플

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend 
spec:
  containers:
    - name: website
      image: ecorp/website
      ports:
        - containerPort: 80

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend

1


spec:
  containers:
    - name: website
      image: ecorp/website
      ports:
        - containerPort: 80

Copy to Clipboard

Toggle word wrap

1: Pod 사전 설정의 라벨 선택기와 일치해야 하는 레이블입니다.

Pod 사전 설정 후 샘플 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/allow-database: "resource version" 
spec:
  containers:
    - name: website
      image: ecorp/website
      volumeMounts: 
        - mountPath: /cache
          name: cache-volume
      ports:
        - containerPort: 80
      env: 
        - name: DB_PORT
          value: "6379"
      envFrom: 
        - configMapRef:
          name: etcd-env-config
        - secretKeyRef:
          name: test-secret
  volumes: 
    - name: cache-volume
      emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/allow-database: "resource version"

1


spec:
  containers:
    - name: website
      image: ecorp/website
      volumeMounts:

2


        - mountPath: /cache
          name: cache-volume
      ports:
        - containerPort: 80
      env:

3


        - name: DB_PORT
          value: "6379"
      envFrom:

4


        - configMapRef:
          name: etcd-env-config
        - secretKeyRef:
          name: test-secret
  volumes:

5


    - name: cache-volume
      emptyDir: {}

Copy to Clipboard

Toggle word wrap

1: Pod 사양이 수정되지 않도록 구성되어 있지 않은 경우 Pod 사전 설정을 표시하도록 추가된 주석이 삽입되었습니다.
2: 볼륨 마운트가 Pod에 추가됩니다.
3: 환경 변수가 포드에 추가됩니다.
4: Pod에 추가된 ConfigMap 및 secrets 오브젝트입니다.
5: 볼륨 마운트가 Pod에 추가됩니다.

Pod 사전 설정에서 Pod를 제외하는 샘플 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: no-podpreset
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/exclude: "true" 
spec:
  containers:
    - name: hello-pod
      image: docker.io/ocpqe/hello-pod

apiVersion: v1
kind: Pod
metadata:
  name: no-podpreset
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/exclude: "true"

1


spec:
  containers:
    - name: hello-pod
      image: docker.io/ocpqe/hello-pod

Copy to Clipboard

Toggle word wrap

1: 이 매개변수를 추가하여 이 pod가 Pod 사전 설정 기능에 의해 삽입되지 않도록 합니다.

15.2. Pod 사전 설정 생성
링크 복사

다음 예제에서는 Pod 사전 설정을 생성하고 사용하는 방법을 보여줍니다.

Admission Controller 추가: 관리자는 /etc/origin/master/master-config.yaml 파일을 확인하여 Pod 사전 설정 승인 컨트롤러 플러그인이 있는지 확인할 수 있습니다. 승인 컨트롤러가 없는 경우 다음을 사용하여 플러그인을 추가합니다.

admissionConfig:
  pluginConfig:
    PodPreset:
      configuration:
        kind: DefaultAdmissionConfig
        apiVersion: v1
        disable: false

admissionConfig:
  pluginConfig:
    PodPreset:
      configuration:
        kind: DefaultAdmissionConfig
        apiVersion: v1
        disable: false

Copy to Clipboard

Toggle word wrap

그런 다음 OpenShift Container Platform 서비스를 다시 시작하십시오.

systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

Copy to Clipboard

Toggle word wrap

Pod Preset 생성: 관리자 또는 개발자는 settings.k8s.io/v1alpha1 API, 삽입할 정보, Pod와 일치하는 라벨 선택기를 사용하여 사전 정의된 Pod를 생성합니다.

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1
metadata:
  name: allow-database
spec:
  selector:
    matchLabels:
      role: frontend
  env:
    - name: DB_PORT
      value: "6379"
  volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
    - name: cache-volume
      emptyDir: {}

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1
metadata:
  name: allow-database
spec:
  selector:
    matchLabels:
      role: frontend
  env:
    - name: DB_PORT
      value: "6379"
  volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
    - name: cache-volume
      emptyDir: {}

Copy to Clipboard

Toggle word wrap

Pod 생성

개발자는 Pod 사전 설정의 라벨 선택기와 일치하는 라벨을 사용하여 Pod를 생성합니다.

Pod 사전 설정의 라벨 선택기와 일치하는 라벨을 사용하여 표준 Pod 사양을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
spec:
  containers:
    - name: website
      image: ecorp/website
      ports:
        - containerPort: 80

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
spec:
  containers:
    - name: website
      image: ecorp/website
      ports:
        - containerPort: 80

Copy to Clipboard

Toggle word wrap

Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap

생성 후 Pod 사양을 확인합니다.

oc get pod website -o yaml

$ oc get pod website -o yaml

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/allow-database: "resource version"

1


spec:
  containers:
    - name: website
      image: ecorp/website
      volumeMounts:

2


        - mountPath: /cache
          name: cache-volume
      ports:
        - containerPort: 80
      env:

3


        - name: DB_PORT
          value: "6379"
  volumes:
    - name: cache-volume
      emptyDir: {}

Copy to Clipboard

Toggle word wrap

1 2 3: 주석이 존재하며 컨테이너 스토리지 및 환경 변수가 삽입됩니다.

15.3. 여러 Pod Presets 사용
링크 복사

여러 Pod 사전 설정을 사용하여 여러 Pod 삽입 정책을 삽입할 수 있습니다.

Pod 사전 설정 승인 컨트롤러 플러그인이 활성화되어 있는지 확인합니다.

환경 변수, 마운트 지점 및/또는 스토리지 볼륨을 사용하여 다음과 유사하게 Pod 사전 설정을 생성합니다.

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1
metadata:
  name: allow-database
spec:
  selector:
    matchLabels:
      role: frontend 
  env:
    - name: DB_PORT
      value: "6379"
  volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
    - name: cache-volume
      emptyDir: {}

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1
metadata:
  name: allow-database
spec:
  selector:
    matchLabels:
      role: frontend

1


  env:
    - name: DB_PORT
      value: "6379"
  volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
    - name: cache-volume
      emptyDir: {}

Copy to Clipboard

Toggle word wrap

1: Pod 라벨과 일치하는 라벨 선택기입니다.

다음과 유사한 두 번째 Pod 사전 설정을 생성합니다.

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1
metadata:
  name: proxy
spec:
  selector:
    matchLabels:
      role: frontend 
  volumeMounts:
    - mountPath: /etc/proxy/configs
      name: proxy-volume
  volumes:
    - name: proxy-volume
      emptyDir: {}

kind: PodPreset
apiVersion: settings.k8s.io/v1alpha1
metadata:
  name: proxy
spec:
  selector:
    matchLabels:
      role: frontend

1


  volumeMounts:
    - mountPath: /etc/proxy/configs
      name: proxy-volume
  volumes:
    - name: proxy-volume
      emptyDir: {}

Copy to Clipboard

Toggle word wrap

1: Pod 라벨과 일치하는 라벨 선택기입니다.

표준 Pod 사양을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend 
spec:
  containers:
    - name: website
      image: ecorp/website
      ports:
        - containerPort: 80

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend

1


spec:
  containers:
    - name: website
      image: ecorp/website
      ports:
        - containerPort: 80

Copy to Clipboard

Toggle word wrap

1: Pod 사전 설정 라벨 선택기와 일치하도록 라벨입니다.

Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap

생성 후 Pod 사양을 확인합니다.

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/allow-database: "resource version" 
    podpreset.admission.kubernetes.io/proxy: "resource version" 
spec:
  containers:
    - name: website
      image: ecorp/website
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
        - mountPath: /etc/proxy/configs
          name: proxy-volume
      ports:
        - containerPort: 80
      env:
        - name: DB_PORT
          value: "6379"
  volumes:
    - name: cache-volume
      emptyDir: {}
    - name: proxy-volume
      emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/allow-database: "resource version"

1


    podpreset.admission.kubernetes.io/proxy: "resource version"

2


spec:
  containers:
    - name: website
      image: ecorp/website
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
        - mountPath: /etc/proxy/configs
          name: proxy-volume
      ports:
        - containerPort: 80
      env:
        - name: DB_PORT
          value: "6379"
  volumes:
    - name: cache-volume
      emptyDir: {}
    - name: proxy-volume
      emptyDir: {}

Copy to Clipboard

Toggle word wrap

1 2: 여러 Pod 사전 설정이 삽입되었음을 나타내는 주석입니다.

15.4. Pod 사전 설정 삭제
링크 복사

다음 명령을 사용하여 사전 설정된 Pod를 삭제할 수 있습니다.

oc delete podpreset <name>

$ oc delete podpreset <name>

Copy to Clipboard

Toggle word wrap

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

oc delete podpreset allow-database

$ oc delete podpreset allow-database

podpreset "allow-database" deleted

Copy to Clipboard

Toggle word wrap

16장. 클러스터로 트래픽 가져오기
링크 복사

16.1. 클러스터로 트래픽 가져오기
링크 복사

OpenShift Container Platform에서는 클러스터에서 실행되는 서비스와 클러스터 외부에서 통신할 수 있는 여러 방법을 제공합니다.

참고

이 섹션의 절차에는 클러스터 관리자가 수행해야 하는 사전 요구 사항이 필요합니다.

관리자는 광범위한 외부 IP 주소에서 해당 서비스에 고유 외부 IP 주소를 할당하여 외부 트래픽이 도달할 수 있는 서비스 끝점을 노출할 수 있습니다. 관리자는 CIDR 표기법을 사용하여 주소 범위를 지정할 수 있으므로 애플리케이션 사용자가 외부 IP 주소에 대한 클러스터에 대한 요청을 수행할 수 있습니다.

각 IP 주소는 각 서비스에 고유한 엔드포인트가 있도록 하나의 서비스에만 할당해야 합니다. 잠재적인 포트 충돌은 첫 번째 서비스 기반에서 처리됩니다.

권장 사항( order or preference)은 다음과 같습니다.

HTTP/HTTPS가 있는 경우 라우터 를 사용합니다.
HTTPS 이외의 TLS 암호화 프로토콜(예: TLS 및 SNI 헤더의 TLS)이 있는 경우 라우터 를 사용합니다.
그렇지 않으면 로드 밸런서, 외부 IP 또는 NodePort 를 사용합니다.

Expand

방법	목적
라우터 사용	HTTPS 이외의 HTTP/HTTPS 트래픽 및 TLS 암호화 프로토콜(예: SNI 헤더가 있는 TLS)에 액세스할 수 있습니다.
로드 밸런서 서비스를 사용하여 공용 IP 자동 할당	풀에서 할당된 IP 주소를 통해 비표준 포트로의 트래픽을 허용합니다.
서비스에 외부 IP를 수동으로 할당	특정 IP 주소를 통해 비표준 포트로의 트래픽을 허용합니다.
NodePort 구성	클러스터의 모든 노드에 서비스를 공개합니다.

16.2. 라우터를 사용하여 클러스터로 트래픽 가져오기
링크 복사

16.2.1. 개요
링크 복사

라우터를 사용하는 것이 OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하는 가장 일반적인 방법입니다.

라우터 는 외부 요청을 수락하고 구성된 경로 를 기반으로 프록시하도록 구성됩니다. 이는 웹 애플리케이션을 다루는 HTTP/HTTPS(SNI)/TLS(SNI)로 제한됩니다.

16.2.2. 관리자 사전 요구 사항
링크 복사

이 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다. 예를 들어 클러스터의 특정 노드 또는 기타 IP 주소를 가리키도록 이름을 DNS로 구성할 수 있습니다. DNS 와일드카드 기능을 사용하여 이름 하위 집합을 클러스터의 IP 주소로 구성할 수 있습니다. 이를 통해 사용자는 관리자의 추가 주의 없이 클러스터 내에서 경로를 설정할 수 있습니다.
각 노드의 로컬 방화벽에서 IP 주소에 대한 요청이 허용하는지 확인합니다.
적절한 사용자 액세스를 허용하는 ID 공급자를 사용하도록 OpenShift Container Platform 클러스터를 구성합니다.
클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
Copy to Clipboard Toggle word wrap
클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

16.2.2.1. 공용 IP 범위 정의
링크 복사

서비스에 대한 액세스를 허용하는 첫 번째 단계는 마스터 구성 파일에서 외부 IP 주소 범위를 정의하는 것입니다.

클러스터 admin 역할의 사용자로 OpenShift Container Platform에 로그인합니다.

oc login

$ oc login
Authentication required (openshift)
Username: admin
Password:
Login successful.

You have access to the following projects and can switch between them with 'oc project <projectname>':
  * default
Using project "default".

Copy to Clipboard

Toggle word wrap

다음과 같이 /etc/origin/master/master-config.yaml 파일에서 externalIPNetworkCIDRs 매개변수를 구성합니다.
```
networkConfig:
  externalIPNetworkCIDRs:
  - <ip_address>/<cidr>
```
```
networkConfig:
  externalIPNetworkCIDRs:
  - <ip_address>/<cidr>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
networkConfig:
  externalIPNetworkCIDRs:
  - 192.168.120.0/24
```
```
networkConfig:
  externalIPNetworkCIDRs:
  - 192.168.120.0/24
```
Copy to Clipboard Toggle word wrap

OpenShift Container Platform 마스터 서비스를 다시 시작하여 변경 사항을 적용합니다.

systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

Copy to Clipboard

Toggle word wrap

Important

IP 주소 풀은 클러스터의 하나 이상의 노드에서 종료되어야 합니다.

16.2.3. 프로젝트 및 서비스 만들기
링크 복사

노출하려는 프로젝트 및 서비스가 존재하지 않는 경우 먼저 프로젝트를 생성한 다음 서비스를 생성합니다.

프로젝트와 서비스가 이미 존재하는 경우 다음 단계로 이동합니다. 서비스 노출로 이동하여 경로 만들기를 참조하십시오.

OpenShift Container Platform에 로그인합니다.
서비스에 사용할 새 프로젝트를 생성합니다.
```
oc new-project <project_name>
```
```
$ oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc new-project external-ip
```
```
$ oc new-project external-ip
```
Copy to Clipboard Toggle word wrap

oc new-app 명령을 사용하여 서비스를 생성합니다.

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

oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.access.redhat.com/openshift3/mysql-55-rhel7

$ oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.access.redhat.com/openshift3/mysql-55-rhel7

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 새 서비스가 생성되었는지 확인합니다.

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   <none>        3306/TCP   13m

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   <none>        3306/TCP   13m

Copy to Clipboard

Toggle word wrap

기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

16.2.4. 경로 생성을 위한 서비스 노출
링크 복사

oc expose 명령을 사용하여 서비스를 경로로 노출해야 합니다.

서비스를 노출하려면 다음을 수행하십시오.

OpenShift Container Platform에 로그인합니다.
노출하려는 서비스가 있는 프로젝트에 로그인합니다.
```
oc project project1
```
```
$ oc project project1
```
Copy to Clipboard Toggle word wrap
다음 명령을 실행하여 매니페스트를 생성합니다.
```
oc expose service <service-name>
```
```
oc expose service <service-name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc expose service mysql-55-rhel7
route "mysql-55-rhel7" exposed
```
```
oc expose service mysql-55-rhel7
route "mysql-55-rhel7" exposed
```
Copy to Clipboard Toggle word wrap
마스터에서 cURL과 같은 툴을 사용하여 서비스의 클러스터 IP 주소를 사용하여 서비스에 연결할 수 있는지 확인합니다.
```
curl <pod-ip>:<port>
```
```
curl <pod-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 172.30.131.89:3306
```
```
curl 172.30.131.89:3306
```
Copy to Clipboard Toggle word wrap
이 섹션의 예제에서는 클라이언트 애플리케이션이 필요한 MySQL 서비스를 사용합니다. 패킷이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 서비스에 연결된 것입니다.
MySQL 클라이언트가 있는 경우 표준 CLI 명령으로 로그인하십시오.
```
mysql -h 172.30.131.89 -u admin -p
```
```
$ mysql -h 172.30.131.89 -u admin -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
```
Copy to Clipboard Toggle word wrap

16.2.5. 라우터 구성
링크 복사

관리자와 협력하여 외부 요청을 수락하고 구성된 경로를 기반으로 프록시하도록 라우터를 구성합니다.

관리자는 와일드카드 DNS 항목을 만든 다음 라우터를 설정할 수 있습니다. 그런 다음 관리자에게 문의하지 않고도 에지 라우터를 셀프 서비스 할 수 있습니다.

라우터에는 관리자가 사용자가 특정 패턴을 필요로 하는 호스트 이름 또는 호스트 이름을 자체 프로비저닝할 수 있는지를 관리자가 지정할 수 있는 제어 기능이 있습니다.

다양한 프로젝트에서 경로 집합이 생성되는 경우 라우터 세트에서 전체 경로 세트를 사용할 수 있습니다. 각 라우터는 경로 집합에서 경로를 허용(또는 선택)합니다. 기본적으로 모든 라우터는 모든 경로를 허용합니다.

모든 프로젝트의 모든 레이블을 볼 수 있는 권한이 있는 라우터는 레이블을 기반으로 인정할 경로를 선택할 수 있습니다. 이를 라우터 분할 이라고 합니다. 이 기능은 들어오는 트래픽 부하를 일련의 라우터 간에 분산시키고 특정 라우터로 트래픽을 격리할 때 유용합니다. 예를 들어 회사 A는 하나의 라우터로, 회사 B는 다른 라우터로 이동합니다.

라우터는 특정 노드에서 실행되므로 노드가 특정 노드에서 실행되므로 노드가 트래픽 수신이 중지됩니다. 다른 노드에 중복 라우터를 만들고 고가용성 을 사용하여 노드가 실패하면 라우터 IP 주소를 전환하여 이러한 영향을 줄일 수 있습니다.

16.2.6. VIP를 사용하여 IP Failover 구성
링크 복사

선택적으로 관리자는 IP 페일오버를 구성할 수 있습니다.

IP 페일오버는 노드 집합에서 VIP(가상 IP) 주소 풀을 관리합니다. 세트의 모든 VIP는 세트에서 선택한 노드에서 서비스를 제공합니다. 단일 노드를 사용할 수 있는 경우 VIP가 제공됩니다. 노드에 VIP를 명시적으로 배포할 수 있는 방법은 없습니다. 따라서 VIP가 없는 노드와 여러 VIP가 있는 다른 노드가 있을 수 있습니다. 노드가 하나만 있는 경우 모든 VIP가 노드에 있습니다.

VIP는 클러스터 외부에서 라우팅할 수 있어야 합니다.

IP 페일오버를 구성하려면 다음을 수행합니다.

마스터에서 ipfailover 서비스 계정에 충분한 보안 권한이 있는지 확인합니다.
```
oc adm policy add-scc-to-user privileged -z ipfailover
```
```
oc adm policy add-scc-to-user privileged -z ipfailover
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 IP 페일오버를 생성합니다.

oc adm ipfailover --virtual-ips=<exposed-ip-address> --watch-port=<exposed-port> --replicas=<number-of-pods> --create

oc adm ipfailover --virtual-ips=<exposed-ip-address> --watch-port=<exposed-port> --replicas=<number-of-pods> --create

Copy to Clipboard

Toggle word wrap

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

oc adm ipfailover --virtual-ips="172.30.233.169" --watch-port=32315 --replicas=4 --create
--> Creating IP failover ipfailover ...
    serviceaccount "ipfailover" created
    deploymentconfig "ipfailover" created
--> Success

oc adm ipfailover --virtual-ips="172.30.233.169" --watch-port=32315 --replicas=4 --create
--> Creating IP failover ipfailover ...
    serviceaccount "ipfailover" created
    deploymentconfig "ipfailover" created
--> Success

Copy to Clipboard

Toggle word wrap

16.3. 로드 밸런서를 사용하여 클러스터로 트래픽 가져오기
링크 복사

16.3.1. 개요
링크 복사

특정 외부 IP 주소가 필요하지 않은 경우 OpenShift Container Platform 클러스터에 대한 외부 액세스를 허용하도록 로드 밸런서 서비스를 구성할 수 있습니다.

로드 밸런서 서비스에서는 구성된 풀에서 고유한 IP를 할당합니다. 로드 밸런서에는 VIP(가상 IP) 일 수 있지만 초기 로드 밸런싱을 위한 단일 머신인 단일 에지 라우터 IP가 있습니다.

이 프로세스는 다음과 같습니다.

관리자는 사전 요구 사항을 수행합니다.
노출할 서비스가 없는 경우 개발자는 프로젝트와 서비스를 생성합니다.
개발자가 경로를 생성하기 위해 서비스를 노출합니다.
개발자는 로드 밸런서 서비스를 생성합니다.
네트워크 관리자는 서비스에 대한 네트워킹을 구성합니다.

16.3.2. 관리자 사전 요구 사항
링크 복사

이 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다. 예를 들어 클러스터의 특정 노드 또는 기타 IP 주소를 가리키도록 이름을 DNS로 구성할 수 있습니다. DNS 와일드카드 기능을 사용하여 이름 하위 집합을 클러스터의 IP 주소로 구성할 수 있습니다. 이를 통해 사용자는 관리자의 추가 주의 없이 클러스터 내에서 경로를 설정할 수 있습니다.
각 노드의 로컬 방화벽에서 IP 주소에 대한 요청이 허용하는지 확인합니다.
적절한 사용자 액세스를 허용하는 ID 공급자를 사용하도록 OpenShift Container Platform 클러스터를 구성합니다.
클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
Copy to Clipboard Toggle word wrap
클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

16.3.2.1. 공용 IP 범위 정의
링크 복사

서비스에 대한 액세스를 허용하는 첫 번째 단계는 마스터 구성 파일에서 외부 IP 주소 범위를 정의하는 것입니다.

클러스터 admin 역할의 사용자로 OpenShift Container Platform에 로그인합니다.

oc login

$ oc login
Authentication required (openshift)
Username: admin
Password:
Login successful.

You have access to the following projects and can switch between them with 'oc project <projectname>':
  * default
Using project "default".

Copy to Clipboard

Toggle word wrap

다음과 같이 /etc/origin/master/master-config.yaml 파일에서 externalIPNetworkCIDRs 매개변수를 구성합니다.
```
networkConfig:
  externalIPNetworkCIDRs:
  - <ip_address>/<cidr>
```
```
networkConfig:
  externalIPNetworkCIDRs:
  - <ip_address>/<cidr>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
networkConfig:
  externalIPNetworkCIDRs:
  - 192.168.120.0/24
```
```
networkConfig:
  externalIPNetworkCIDRs:
  - 192.168.120.0/24
```
Copy to Clipboard Toggle word wrap

OpenShift Container Platform 마스터 서비스를 다시 시작하여 변경 사항을 적용합니다.

systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

Copy to Clipboard

Toggle word wrap

Important

IP 주소 풀은 클러스터의 하나 이상의 노드에서 종료되어야 합니다.

16.3.3. 프로젝트 및 서비스 만들기
링크 복사

노출하려는 프로젝트 및 서비스가 존재하지 않는 경우 먼저 프로젝트를 생성한 다음 서비스를 생성합니다.

프로젝트와 서비스가 이미 존재하는 경우 다음 단계로 이동합니다. 서비스 노출로 이동하여 경로 만들기를 참조하십시오.

OpenShift Container Platform에 로그인합니다.
서비스에 사용할 새 프로젝트를 생성합니다.
```
oc new-project <project_name>
```
```
$ oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc new-project external-ip
```
```
$ oc new-project external-ip
```
Copy to Clipboard Toggle word wrap

oc new-app 명령을 사용하여 서비스를 생성합니다.

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

oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.access.redhat.com/openshift3/mysql-55-rhel7

$ oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.access.redhat.com/openshift3/mysql-55-rhel7

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 새 서비스가 생성되었는지 확인합니다.

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   <none>        3306/TCP   13m

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   <none>        3306/TCP   13m

Copy to Clipboard

Toggle word wrap

기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

16.3.4. 경로 생성을 위한 서비스 노출
링크 복사

oc expose 명령을 사용하여 서비스를 경로로 노출해야 합니다.

서비스를 노출하려면 다음을 수행하십시오.

OpenShift Container Platform에 로그인합니다.
노출하려는 서비스가 있는 프로젝트에 로그인합니다.
```
oc project project1
```
```
$ oc project project1
```
Copy to Clipboard Toggle word wrap
다음 명령을 실행하여 매니페스트를 생성합니다.
```
oc expose service <service-name>
```
```
oc expose service <service-name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc expose service mysql-55-rhel7
route "mysql-55-rhel7" exposed
```
```
oc expose service mysql-55-rhel7
route "mysql-55-rhel7" exposed
```
Copy to Clipboard Toggle word wrap
마스터에서 cURL과 같은 툴을 사용하여 서비스의 클러스터 IP 주소를 사용하여 서비스에 연결할 수 있는지 확인합니다.
```
curl <pod-ip>:<port>
```
```
curl <pod-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 172.30.131.89:3306
```
```
curl 172.30.131.89:3306
```
Copy to Clipboard Toggle word wrap
이 섹션의 예제에서는 클라이언트 애플리케이션이 필요한 MySQL 서비스를 사용합니다. 패킷이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 서비스에 연결된 것입니다.
MySQL 클라이언트가 있는 경우 표준 CLI 명령으로 로그인하십시오.
```
mysql -h 172.30.131.89 -u admin -p
```
```
$ mysql -h 172.30.131.89 -u admin -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
```
Copy to Clipboard Toggle word wrap

그런 다음 다음 작업을 수행합니다.

로드 밸런서 서비스 생성
네트워킹 설정
IP 페일오버 구성

16.3.5. 로드 밸런서 서비스 생성
링크 복사

로드 밸런서 서비스를 생성하려면 다음을 수행합니다.

OpenShift Container Platform에 로그인합니다.
노출하려는 서비스가 있는 프로젝트를 로드합니다. 프로젝트 또는 서비스가 없는 경우 프로젝트 및 서비스 만들기를 참조하십시오.
```
oc project project1
```
```
$ oc project project1
```
Copy to Clipboard Toggle word wrap
필요한 경우 마스터 노드에서 텍스트 파일을 열고 다음 텍스트를 붙여넣어 파일을 편집합니다.
예 16.1. 로드 밸런서 구성 파일 샘플
apiVersion: v1 kind: Service metadata: name: egress-2
1
spec: ports: - name: db port: 3306
2
loadBalancerIP: type: LoadBalancer
3
selector: name: mysql
4
Copy to Clipboard Toggle word wrap
1
로드 밸런서 서비스를 설명하는 이름을 입력합니다.
2
노출하려는 서비스가 수신 대기 중인 포트와 동일한 포트를 입력합니다.
3
유형으로 loadbalancer를 입력합니다.
4
서비스 이름을 입력합니다.
파일을 저장하고 종료합니다.
다음 명령을 실행하여 서비스를 생성합니다.
```
oc create -f <file-name>
```
```
oc create -f <file-name>
```
Copy to Clipboard Toggle word wrap
예를 들면 다음과 같습니다.
```
oc create -f mysql-lb.yaml
```
```
oc create -f mysql-lb.yaml
```
Copy to Clipboard Toggle word wrap

새 서비스를 보려면 다음 명령을 실행합니다.

oc get svc
NAME              CLUSTER-IP       EXTERNAL-IP                   PORT(S)                   AGE
egress-2          172.30.236.167   172.29.121.74,172.29.121.74   3306/TCP                  6s

oc get svc
NAME              CLUSTER-IP       EXTERNAL-IP                   PORT(S)                   AGE
egress-2          172.30.236.167   172.29.121.74,172.29.121.74   3306/TCP                  6s

Copy to Clipboard

Toggle word wrap

서비스에는 외부 IP 주소가 자동으로 할당됩니다.

마스터에서 cURL과 같은 도구를 사용하여 공개 IP 주소로 서비스에 도달할 수 있는지 확인합니다.
```
curl <public-ip>:<port>
```
```
$ curl <public-ip>:<port>
```
Copy to Clipboard Toggle word wrap
++의 예:
```
curl 172.29.121.74:3306
```
```
$ curl 172.29.121.74:3306
```
Copy to Clipboard Toggle word wrap
이 섹션의 예제에서는 클라이언트 애플리케이션이 필요한 MySQL 서비스를 사용합니다. 패킷이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 서비스에 연결된 것입니다.
MySQL 클라이언트가 있는 경우 표준 CLI 명령으로 로그인하십시오.
```
mysql -h 172.30.131.89 -u admin -p
```
```
$ mysql -h 172.30.131.89 -u admin -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
```
Copy to Clipboard Toggle word wrap

16.3.6. 네트워킹 구성
링크 복사

다음 단계는 다른 노드에서 노출된 서비스에 액세스하는 데 필요한 네트워킹을 구성하는 일반적인 지침입니다. 네트워크 환경이 다르므로 사용자 환경 내에서 수행해야 하는 특정 구성이 네트워크 관리자에게 문의하십시오.

이 단계에서는 모든 시스템이 동일한 서브넷에 있다고 가정합니다.

노드에서 다음을 수행합니다.

네트워크를 다시 시작하여 네트워크가 작동 중인지 확인합니다.
```
service network restart
```
```
$ service network restart
Restarting network (via systemctl):  [  OK  ]
```
Copy to Clipboard Toggle word wrap
네트워크가 작동하지 않으면 다음 명령을 실행할 때 네트워크에 연결할 수 없는 오류 메시지가 표시됩니다.
마스터에서 노출된 서비스의 IP 주소와 마스터 호스트의 IP 주소 간에 경로를 추가합니다. 네트워킹 경로에 넷마스크를 사용하는 경우 넷마스크 옵션과 넷마스크 를 사용하여 다음을 사용합니다.
```
route add -net 172.29.121.74 netmask 255.255.0.0 gw 10.16.41.22 dev eth0
```
```
$ route add -net 172.29.121.74 netmask 255.255.0.0 gw 10.16.41.22 dev eth0
```
Copy to Clipboard Toggle word wrap
cURL과 같은 도구를 사용하여 공용 IP 주소로 서비스에 도달할 수 있는지 확인하십시오.
```
curl <public-ip>:<port>
```
```
$ curl <public-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 172.29.121.74:3306
```
```
curl 172.29.121.74:3306
```
Copy to Clipboard Toggle word wrap
패킷 이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 노드에서 서비스에 액세스할 수 있습니다.

클러스터에 없는 시스템에서 다음을 수행합니다.

네트워크를 다시 시작하여 네트워크가 작동 중인지 확인합니다.
```
service network restart
```
```
$ service network restart
Restarting network (via systemctl):  [  OK  ]
```
Copy to Clipboard Toggle word wrap
네트워크가 작동하지 않으면 다음 명령을 실행할 때 네트워크에 연결할 수 없는 오류 메시지가 표시됩니다.
마스터에서 노출된 서비스의 IP 주소와 마스터 호스트의 IP 주소 간에 경로를 추가합니다. 네트워킹 경로에 넷마스크를 사용하는 경우 넷마스크 옵션과 넷마스크 를 사용하여 다음을 사용합니다.
```
route add -net 172.29.121.74 netmask 255.255.0.0 gw 10.16.41.22 dev eth0
```
```
$ route add -net 172.29.121.74 netmask 255.255.0.0 gw 10.16.41.22 dev eth0
```
Copy to Clipboard Toggle word wrap
공용 IP 주소를 사용하여 서비스에 연결할 수 있는지 확인합니다.
```
curl <public-ip>:<port>
```
```
$ curl <public-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 172.29.121.74:3306
```
```
curl 172.29.121.74:3306
```
Copy to Clipboard Toggle word wrap
패킷 이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 클러스터 외부에서 서비스에 액세스할 수 있습니다.

16.3.7. VIP를 사용하여 IP Failover 구성
링크 복사

선택적으로 관리자는 IP 페일오버를 구성할 수 있습니다.

IP 페일오버는 노드 집합에서 VIP(가상 IP) 주소 풀을 관리합니다. 세트의 모든 VIP는 세트에서 선택한 노드에서 서비스를 제공합니다. 단일 노드를 사용할 수 있는 경우 VIP가 제공됩니다. 노드에 VIP를 명시적으로 배포할 수 있는 방법은 없습니다. 따라서 VIP가 없는 노드와 여러 VIP가 있는 다른 노드가 있을 수 있습니다. 노드가 하나만 있는 경우 모든 VIP가 노드에 있습니다.

VIP는 클러스터 외부에서 라우팅할 수 있어야 합니다.

IP 페일오버를 구성하려면 다음을 수행합니다.

마스터에서 ipfailover 서비스 계정에 충분한 보안 권한이 있는지 확인합니다.
```
oc adm policy add-scc-to-user privileged -z ipfailover
```
```
oc adm policy add-scc-to-user privileged -z ipfailover
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 IP 페일오버를 생성합니다.

oc adm ipfailover --virtual-ips=<exposed-ip-address> --watch-port=<exposed-port> --replicas=<number-of-pods> --create

oc adm ipfailover --virtual-ips=<exposed-ip-address> --watch-port=<exposed-port> --replicas=<number-of-pods> --create

Copy to Clipboard

Toggle word wrap

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

oc adm ipfailover --virtual-ips="172.30.233.169" --watch-port=32315 --replicas=4 --create
--> Creating IP failover ipfailover ...
    serviceaccount "ipfailover" created
    deploymentconfig "ipfailover" created
--> Success

oc adm ipfailover --virtual-ips="172.30.233.169" --watch-port=32315 --replicas=4 --create
--> Creating IP failover ipfailover ...
    serviceaccount "ipfailover" created
    deploymentconfig "ipfailover" created
--> Success

Copy to Clipboard

Toggle word wrap

16.4. 서비스 외부 IP를 사용하여 클러스터로 트래픽 가져오기
링크 복사

16.4.1. 개요
링크 복사

서비스를 노출하는 한 가지 방법은 클러스터 외부에서 액세스할 수 있도록 외부 IP 액세스 권한을 서비스에 직접 할당하는 것입니다.

공용 IP 주소 범위를 정의하는 데 표시된 대로 사용할 IP 주소 범위를 생성했는지 확인합니다.

서비스에서 외부 IP를 설정하면 OpenShift Container Platform은 해당 IP 주소를 대상으로 하는 클러스터 노드에서 들어오는 트래픽이 내부 pod 중 하나로 전송되도록 IP 테이블 규칙을 설정합니다. 이는 내부 서비스 IP 주소와 유사하지만 외부 IP는 이 서비스가 지정된 IP에서 외부에 노출되어야 함을 OpenShift Container Platform에 알립니다. 관리자는 클러스터의 노드 중 하나에서 호스트 (node) 인터페이스에 IP 주소를 할당해야 합니다. 또는 주소를 VIP(가상 IP) 로 사용할 수 있습니다.

이러한 IP는 OpenShift Container Platform에서 관리되지 않으며 관리자는 이 IP가 있는 노드에 트래픽이 도달하는지 확인해야 합니다.

참고

다음은 비HA 솔루션이며 IP 페일오버 를 구성하지 않습니다. 서비스를 고가용성으로 만들려면 IP 페일오버가 필요합니다.

이 프로세스는 다음과 같습니다.

관리자는 사전 요구 사항을 수행합니다.
노출할 서비스가 없는 경우 개발자는 프로젝트와 서비스를 생성합니다.
개발자가 경로를 생성하기 위해 서비스를 노출합니다.
개발자가 서비스에 IP 주소를 할당합니다.
네트워크 관리자는 서비스에 대한 네트워킹을 구성합니다.

16.4.2. 관리자 사전 요구 사항
링크 복사

이 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다. 예를 들어 클러스터의 특정 노드 또는 기타 IP 주소를 가리키도록 이름을 DNS로 구성할 수 있습니다. DNS 와일드카드 기능을 사용하여 이름 하위 집합을 클러스터의 IP 주소로 구성할 수 있습니다. 이를 통해 사용자는 관리자의 추가 주의 없이 클러스터 내에서 경로를 설정할 수 있습니다.
각 노드의 로컬 방화벽에서 IP 주소에 대한 요청이 허용하는지 확인합니다.
적절한 사용자 액세스를 허용하는 ID 공급자를 사용하도록 OpenShift Container Platform 클러스터를 구성합니다.
클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
Copy to Clipboard Toggle word wrap
클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

16.4.2.1. 공용 IP 범위 정의
링크 복사

서비스에 대한 액세스를 허용하는 첫 번째 단계는 마스터 구성 파일에서 외부 IP 주소 범위를 정의하는 것입니다.

클러스터 admin 역할의 사용자로 OpenShift Container Platform에 로그인합니다.

oc login

$ oc login
Authentication required (openshift)
Username: admin
Password:
Login successful.

You have access to the following projects and can switch between them with 'oc project <projectname>':
  * default
Using project "default".

Copy to Clipboard

Toggle word wrap

다음과 같이 /etc/origin/master/master-config.yaml 파일에서 externalIPNetworkCIDRs 매개변수를 구성합니다.
```
networkConfig:
  externalIPNetworkCIDRs:
  - <ip_address>/<cidr>
```
```
networkConfig:
  externalIPNetworkCIDRs:
  - <ip_address>/<cidr>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
networkConfig:
  externalIPNetworkCIDRs:
  - 192.168.120.0/24
```
```
networkConfig:
  externalIPNetworkCIDRs:
  - 192.168.120.0/24
```
Copy to Clipboard Toggle word wrap

OpenShift Container Platform 마스터 서비스를 다시 시작하여 변경 사항을 적용합니다.

systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

Copy to Clipboard

Toggle word wrap

Important

IP 주소 풀은 클러스터의 하나 이상의 노드에서 종료되어야 합니다.

16.4.3. 프로젝트 및 서비스 만들기
링크 복사

노출하려는 프로젝트 및 서비스가 존재하지 않는 경우 먼저 프로젝트를 생성한 다음 서비스를 생성합니다.

프로젝트와 서비스가 이미 존재하는 경우 다음 단계로 이동합니다. 서비스 노출로 이동하여 경로 만들기를 참조하십시오.

OpenShift Container Platform에 로그인합니다.
서비스에 사용할 새 프로젝트를 생성합니다.
```
oc new-project <project_name>
```
```
$ oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc new-project external-ip
```
```
$ oc new-project external-ip
```
Copy to Clipboard Toggle word wrap

oc new-app 명령을 사용하여 서비스를 생성합니다.

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

oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.access.redhat.com/openshift3/mysql-55-rhel7

$ oc new-app \
    -e MYSQL_USER=admin \
    -e MYSQL_PASSWORD=redhat \
    -e MYSQL_DATABASE=mysqldb \
    registry.access.redhat.com/openshift3/mysql-55-rhel7

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 새 서비스가 생성되었는지 확인합니다.

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   <none>        3306/TCP   13m

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   <none>        3306/TCP   13m

Copy to Clipboard

Toggle word wrap

기본적으로 새 서비스에는 외부 IP 주소가 없습니다.

16.4.4. 경로 생성을 위한 서비스 노출
링크 복사

oc expose 명령을 사용하여 서비스를 경로로 노출해야 합니다.

서비스를 노출하려면 다음을 수행하십시오.

OpenShift Container Platform에 로그인합니다.
노출하려는 서비스가 있는 프로젝트에 로그인합니다.
```
oc project project1
```
```
$ oc project project1
```
Copy to Clipboard Toggle word wrap
다음 명령을 실행하여 매니페스트를 생성합니다.
```
oc expose service <service-name>
```
```
oc expose service <service-name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc expose service mysql-55-rhel7
route "mysql-55-rhel7" exposed
```
```
oc expose service mysql-55-rhel7
route "mysql-55-rhel7" exposed
```
Copy to Clipboard Toggle word wrap
마스터에서 cURL과 같은 툴을 사용하여 서비스의 클러스터 IP 주소를 사용하여 서비스에 연결할 수 있는지 확인합니다.
```
curl <pod-ip>:<port>
```
```
curl <pod-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 172.30.131.89:3306
```
```
curl 172.30.131.89:3306
```
Copy to Clipboard Toggle word wrap
이 섹션의 예제에서는 클라이언트 애플리케이션이 필요한 MySQL 서비스를 사용합니다. 패킷이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 서비스에 연결된 것입니다.
MySQL 클라이언트가 있는 경우 표준 CLI 명령으로 로그인하십시오.
```
mysql -h 172.30.131.89 -u admin -p
```
```
$ mysql -h 172.30.131.89 -u admin -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.

MySQL [(none)]>
```
Copy to Clipboard Toggle word wrap

그런 다음 다음 작업을 수행합니다.

서비스에 IP 주소 할당
네트워킹 설정
IP 페일오버 구성

16.4.5. 서비스에 IP 주소 할당
링크 복사

서비스에 외부 IP 주소를 할당하려면 다음을 수행합니다.

OpenShift Container Platform에 로그인합니다.
노출하려는 서비스가 있는 프로젝트를 로드합니다. 프로젝트 또는 서비스가 없는 경우 사전 요구 사항에서 프로젝트 및 서비스 만들기 를 참조하십시오.
다음 명령을 실행하여 액세스하려는 서비스에 외부 IP 주소를 할당합니다. 외부 IP 주소 범위의 IP 주소를 사용합니다.
```
oc patch svc <name> -p '{"spec":{"externalIPs":["<ip_address>"]}}'
```
```
oc patch svc <name> -p '{"spec":{"externalIPs":["<ip_address>"]}}'
```
Copy to Clipboard Toggle word wrap
& lt;name >은 서비스 이름이고 -p 는 서비스 JSON 파일에 적용할 패치를 나타냅니다. 대괄호 안의 표현식에서 지정된 IP 주소를 지정된 서비스에 할당합니다.
예를 들어 다음과 같습니다.
```
oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'

"mysql-55-rhel7" patched
```
```
oc patch svc mysql-55-rhel7 -p '{"spec":{"externalIPs":["192.174.120.10"]}}'

"mysql-55-rhel7" patched
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 서비스에 공용 IP가 있는지 확인합니다.

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP     PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   192.174.120.10  3306/TCP   13m

oc get svc
NAME               CLUSTER-IP      EXTERNAL-IP     PORT(S)    AGE
mysql-55-rhel7     172.30.131.89   192.174.120.10  3306/TCP   13m

Copy to Clipboard

Toggle word wrap

마스터에서 cURL과 같은 도구를 사용하여 공개 IP 주소로 서비스에 도달할 수 있는지 확인합니다.
```
curl <public-ip>:<port>
```
```
$ curl <public-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 192.168.120.10:3306
```
```
curl 192.168.120.10:3306
```
Copy to Clipboard Toggle word wrap
패킷이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 서비스에 연결된 것입니다.
MySQL 클라이언트가 있는 경우 표준 CLI 명령으로 로그인하십시오.
```
mysql -h 192.168.120.10 -u admin -p
```
```
$ mysql -h 192.168.120.10 -u admin -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.

MySQL [(none)]>
```
Copy to Clipboard Toggle word wrap

16.4.6. 네트워킹 구성
링크 복사

외부 IP 주소를 할당한 후에는 해당 IP에 대한 경로를 생성해야 합니다.

다음 단계는 다른 노드에서 노출된 서비스에 액세스하는 데 필요한 네트워킹을 구성하는 일반적인 지침입니다. 네트워크 환경이 다르므로 사용자 환경 내에서 수행해야 하는 특정 구성이 네트워크 관리자에게 문의하십시오.

참고

이 단계에서는 모든 시스템이 동일한 서브넷에 있다고 가정합니다.

마스터에서 다음을 수행합니다.

네트워크를 다시 시작하여 네트워크가 작동 중인지 확인합니다.
```
service network restart
```
```
$ service network restart
Restarting network (via systemctl):  [  OK  ]
```
Copy to Clipboard Toggle word wrap
네트워크가 작동하지 않으면 다음 명령을 실행할 때 네트워크에 연결할 수 없는 오류 메시지가 표시됩니다.
노출하려는 서비스의 외부 IP 주소와 ifconfig 명령 출력에서 호스트 IP와 연결된 장치 이름을 사용하여 다음 명령을 실행합니다.
```
ip address add <external-ip> dev <device>
```
```
$ ip address add <external-ip> dev <device>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
ip address add 192.168.120.10 dev eth0
```
```
$ ip address add 192.168.120.10 dev eth0
```
Copy to Clipboard Toggle word wrap
필요한 경우 다음 명령을 실행하여 마스터가 있는 호스트 서버의 IP 주소를 가져옵니다.
```
ifconfig
```
```
$ ifconfig
```
Copy to Clipboard Toggle word wrap
UP, BROADCAST, RUNNING,MULTICAST 와 유사한 장치를 찾습니다.
```
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.16.41.22  netmask 255.255.248.0  broadcast 10.16.47.255
        ...
```
```
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.16.41.22  netmask 255.255.248.0  broadcast 10.16.47.255
        ...
```
Copy to Clipboard Toggle word wrap
마스터가 상주하는 호스트의 IP 주소와 마스터 호스트의 게이트웨이 IP 주소 간에 경로를 추가합니다. 네트워킹 경로에 넷마스크를 사용하는 경우 넷마스크 옵션과 넷마스크 를 사용하여 다음을 사용합니다.
```
route add -host <host_ip_address> netmask <netmask> gw <gateway_ip_address> dev <device>
```
```
$ route add -host <host_ip_address> netmask <netmask> gw <gateway_ip_address> dev <device>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
route add -host 10.16.41.22 netmask 255.255.248.0 gw 10.16.41.254 dev eth0
```
```
$ route add -host 10.16.41.22 netmask 255.255.248.0 gw 10.16.41.254 dev eth0
```
Copy to Clipboard Toggle word wrap
netstat -nr 명령은 게이트웨이 IP 주소를 제공합니다.
```
netstat -nr
```
```
$ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.16.41.254    0.0.0.0         UG        0 0          0 eth0
```
Copy to Clipboard Toggle word wrap
노출된 서비스의 IP 주소와 마스터 호스트의 IP 주소 간에 경로를 추가합니다.
```
route add -net 192.174.120.0/24 gw 10.16.41.22 eth0
```
```
$ route add -net 192.174.120.0/24 gw 10.16.41.22 eth0
```
Copy to Clipboard Toggle word wrap

노드에서 다음을 수행합니다.

네트워크를 다시 시작하여 네트워크가 작동 중인지 확인합니다.
```
service network restart
```
```
$ service network restart
Restarting network (via systemctl):  [  OK  ]
```
Copy to Clipboard Toggle word wrap
네트워크가 작동하지 않으면 다음 명령을 실행할 때 네트워크에 연결할 수 없는 오류 메시지가 표시됩니다.

노드가 있는 호스트의 IP 주소와 노드 호스트의 게이트웨이 IP 간에 경로를 추가합니다. 네트워킹 경로에 넷마스크를 사용하는 경우 넷마스크 옵션과 넷마스크 를 사용하여 다음을 사용합니다.

route add -net 10.16.40.0 netmask 255.255.248.0 gw 10.16.47.254 eth0

$ route add -net 10.16.40.0 netmask 255.255.248.0 gw 10.16.47.254 eth0

Copy to Clipboard

Toggle word wrap

ifconfig 명령은 호스트 IP를 표시합니다.

ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.16.41.71  netmask 255.255.248.0  broadcast 10.19.41.255

ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.16.41.71  netmask 255.255.248.0  broadcast 10.19.41.255

Copy to Clipboard

Toggle word wrap

netstat -nr 명령은 게이트웨이 IP를 표시합니다.

netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.16.41.254    0.0.0.0         UG        0 0          0 eth0

netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.16.41.254    0.0.0.0         UG        0 0          0 eth0

Copy to Clipboard

Toggle word wrap

노출된 서비스의 IP 주소와 마스터 노드가 상주하는 호스트 시스템의 IP 주소 간에 경로를 추가합니다.
```
route add -net 192.174.120.0 netmask 255.255.255.0 gw 10.16.41.22 dev eth0
```
```
$ route add -net 192.174.120.0 netmask 255.255.255.0 gw 10.16.41.22 dev eth0
```
Copy to Clipboard Toggle word wrap
cURL과 같은 도구를 사용하여 공용 IP 주소로 서비스에 도달할 수 있는지 확인하십시오.
```
curl <public-ip>:<port>
```
```
$ curl <public-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 192.168.120.10:3306
```
```
curl 192.168.120.10:3306
```
Copy to Clipboard Toggle word wrap
패킷 이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 노드에서 서비스에 액세스할 수 있습니다.

클러스터에 없는 시스템에서 다음을 수행합니다.

네트워크를 다시 시작하여 네트워크가 작동 중인지 확인합니다.
```
service network restart
```
```
$ service network restart
Restarting network (via systemctl):  [  OK  ]
```
Copy to Clipboard Toggle word wrap
네트워크가 작동하지 않으면 다음 명령을 실행할 때 네트워크에 연결할 수 없는 오류 메시지가 표시됩니다.
원격 호스트의 IP 주소와 원격 호스트의 게이트웨이 IP 간에 경로를 추가합니다. 네트워킹 경로에 넷마스크를 사용하는 경우 넷마스크 옵션과 넷마스크 를 사용하여 다음을 사용합니다.
```
route add -net 10.16.64.0 netmask 255.255.248.0 gw 10.16.71.254 eno1
```
```
$ route add -net 10.16.64.0 netmask 255.255.248.0 gw 10.16.71.254 eno1
```
Copy to Clipboard Toggle word wrap
마스터에서 노출된 서비스의 IP 주소와 마스터 호스트의 IP 주소 간에 경로를 추가합니다.
```
route add -net 192.174.120.0 netmask 255.255.248.0 gw 10.16.41.22
```
```
$ route add -net 192.174.120.0 netmask 255.255.248.0 gw 10.16.41.22
```
Copy to Clipboard Toggle word wrap
cURL과 같은 도구를 사용하여 공용 IP 주소로 서비스에 도달할 수 있는지 확인하십시오.
```
curl <public-ip>:<port>
```
```
$ curl <public-ip>:<port>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
curl 192.168.120.10:3306
```
```
curl 192.168.120.10:3306
```
Copy to Clipboard Toggle word wrap
패킷 이 잘못됨이라는 메시지가 포함된 문자열이 표시되면 클러스터 외부에서 서비스에 액세스할 수 있습니다.

16.4.7. VIP를 사용하여 IP Failover 구성
링크 복사

선택적으로 관리자는 IP 페일오버를 구성할 수 있습니다.

IP 페일오버는 노드 집합에서 VIP(가상 IP) 주소 풀을 관리합니다. 세트의 모든 VIP는 세트에서 선택한 노드에서 서비스를 제공합니다. 단일 노드를 사용할 수 있는 경우 VIP가 제공됩니다. 노드에 VIP를 명시적으로 배포할 수 있는 방법은 없습니다. 따라서 VIP가 없는 노드와 여러 VIP가 있는 다른 노드가 있을 수 있습니다. 노드가 하나만 있는 경우 모든 VIP가 노드에 있습니다.

VIP는 클러스터 외부에서 라우팅할 수 있어야 합니다.

IP 페일오버를 구성하려면 다음을 수행합니다.

마스터에서 ipfailover 서비스 계정에 충분한 보안 권한이 있는지 확인합니다.
```
oc adm policy add-scc-to-user privileged -z ipfailover
```
```
oc adm policy add-scc-to-user privileged -z ipfailover
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 IP 페일오버를 생성합니다.

oc adm ipfailover --virtual-ips=<exposed-ip-address> --watch-port=<exposed-port> --replicas=<number-of-pods> --create

oc adm ipfailover --virtual-ips=<exposed-ip-address> --watch-port=<exposed-port> --replicas=<number-of-pods> --create

Copy to Clipboard

Toggle word wrap

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

oc adm ipfailover --virtual-ips="172.30.233.169" --watch-port=32315 --replicas=4 --create
--> Creating IP failover ipfailover ...
    serviceaccount "ipfailover" created
    deploymentconfig "ipfailover" created
--> Success

oc adm ipfailover --virtual-ips="172.30.233.169" --watch-port=32315 --replicas=4 --create
--> Creating IP failover ipfailover ...
    serviceaccount "ipfailover" created
    deploymentconfig "ipfailover" created
--> Success

Copy to Clipboard

Toggle word wrap

16.5. NodePort를 사용하여 클러스터로 트래픽 가져오기
링크 복사

16.5.1. 개요
링크 복사

NodePort를 사용하여 클러스터 의 모든 노드에 서비스 nodePort를 노출합니다.

NodePort를 사용하려면 추가 포트 리소스가 필요합니다.

노드 포트는 서비스를 노드 IP 주소의 정적 포트에 노출합니다.

NodePort는 기본적으로 30000-32767 범위에 있습니다. 즉 NodePort가 서비스의 의도한 포트(예: 8080)와 일치하지 않을 수 있습니다(예: 8080은 31020)로 노출될 수 있습니다.

관리자는 외부 IP가 모든 노드의 로컬 방화벽 규칙으로 라우팅되고 열려 있는 포트에 액세스할 수 있는지 확인해야 합니다.

NodePort 및 외부 IP는 독립적이며 둘 다 동시에 사용할 수 있습니다.

16.5.2. 관리자 사전 요구 사항
링크 복사

이 절차를 시작하기 전에 관리자는 다음을 수행해야 합니다.

요청이 클러스터에 도달할 수 있도록 외부 포트를 클러스터 네트워킹 환경으로 설정합니다. 예를 들어 클러스터의 특정 노드 또는 기타 IP 주소를 가리키도록 이름을 DNS로 구성할 수 있습니다. DNS 와일드카드 기능을 사용하여 이름 하위 집합을 클러스터의 IP 주소로 구성할 수 있습니다. 이를 통해 사용자는 관리자의 추가 주의 없이 클러스터 내에서 경로를 설정할 수 있습니다.
각 노드의 로컬 방화벽에서 IP 주소에 대한 요청이 허용하는지 확인합니다.
적절한 사용자 액세스를 허용하는 ID 공급자를 사용하도록 OpenShift Container Platform 클러스터를 구성합니다.
클러스터 관리자 역할의 사용자가 한 명 이상 있는지 확인합니다. 이 역할을 사용자에게 추가하려면 다음 명령을 실행합니다.
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
```
oc adm policy add-cluster-role-to-user cluster-admin username
```
Copy to Clipboard Toggle word wrap
클러스터에 대한 네트워크 액세스 권한이 있는 마스터와 노드가 클러스터 외부에 각각 1개 이상씩 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 이 절차에서는 외부 시스템이 클러스터와 동일한 서브넷에 있다고 가정합니다. 다른 서브넷에 있는 외부 시스템에 필요한 추가 네트워킹은 이 주제에서 다루지 않습니다.

16.5.3. 서비스 구성
링크 복사

서비스를 생성하거나 수정할 때 nodePort의 포트 번호를 지정합니다. 포트를 수동으로 지정하지 않은 경우 시스템에서 포트를 할당합니다.

마스터 노드에 로그인합니다.
사용하려는 프로젝트가 없는 경우 서비스에 대한 새 프로젝트를 생성합니다.
```
oc new-project <project_name>
```
```
$ oc new-project <project_name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc new-project external-ip
```
```
$ oc new-project external-ip
```
Copy to Clipboard Toggle word wrap

서비스 정의를 편집하여 spec.type:NodePort 를 지정하고 선택적으로 30000-32767 범위에서 포트를 지정합니다.

apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    name: mysql
spec:
  type: NodePort
  ports:
    - port: 3036
      nodePort: 30036
      name: http
  selector:
    name: mysql

apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    name: mysql
spec:
  type: NodePort
  ports:
    - port: 3036
      nodePort: 30036
      name: http
  selector:
    name: mysql

Copy to Clipboard

Toggle word wrap

다음 명령을 실행하여 서비스를 생성합니다.
```
oc new-app <file-name>
```
```
$ oc new-app <file-name>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc new-app mysql.yaml
```
```
oc new-app mysql.yaml
```
Copy to Clipboard Toggle word wrap

다음 명령을 실행하여 새 서비스가 생성되었는지 확인합니다.

oc get svc

NAME             CLUSTER_IP       EXTERNAL_IP   PORT(S)                      AGE
mysql            172.30.89.219    <nodes>       3036:30036/TCP               2m

oc get svc

NAME             CLUSTER_IP       EXTERNAL_IP   PORT(S)                      AGE
mysql            172.30.89.219    <nodes>       3036:30036/TCP               2m

Copy to Clipboard

Toggle word wrap

외부 IP는 < nodes> 로 나열되고 노드 포트가 나열됩니다.

< NodeIP>:<NodePort > 주소를 사용하여 서비스에 액세스할 수 있어야 합니다.

17장. 라우트
링크 복사

17.1. 개요
링크 복사

OpenShift Container Platform 경로 는 www.example.com 와 같은 호스트 이름에 서비스를 노출하므로 외부 클라이언트가 이름으로 연결할 수 있습니다.

호스트 이름에 대한 DNS 확인이 라우팅과 별도로 처리됩니다. 관리자는 OpenShift Container Platform 라우터로 항상 올바르게 확인되는 클라우드 도메인을 구성하거나 라우터와 독립적으로 DNS 레코드를 수정해야 할 수 있습니다.

17.2. 경로 생성
링크 복사

웹 콘솔 또는 CLI를 사용하여 비보안 경로 및 보안 경로를 생성할 수 있습니다.

웹 콘솔을 사용하여 탐색의 애플리케이션 섹션에 있는 Routes 페이지로 이동할 수 있습니다.

경로 생성을 클릭하여 프로젝트에 경로를 정의하고 생성합니다.

그림 17.1. 웹 콘솔을 사용하여 경로 생성

CLI를 사용하면 다음 예제에서는 안전하지 않은 경로가 생성됩니다.

oc expose svc/frontend --hostname=www.example.com

$ oc expose svc/frontend --hostname=www.example.com

Copy to Clipboard

Toggle word wrap

--name 옵션을 사용하여 지정하지 않는 한 새 경로는 서비스에서 이름을 상속합니다.

보안되지 않은 경로 생성 된 YAML의 YAML 정의

apiVersion: v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  path: "/test" 
  to:
    kind: Service
    name: frontend

apiVersion: v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  path: "/test"

1


  to:
    kind: Service
    name: frontend

Copy to Clipboard

Toggle word wrap

1: 경로 기반 라우팅 의 경우 URL과 비교할 수 있는 경로 구성 요소를 지정합니다.

CLI를 사용하여 경로 구성에 대한 자세한 내용은 경로 유형을 참조하십시오.

보안되지 않은 경로는 기본 구성이므로 가장 쉽게 설정할 수 있습니다. 그러나 보안 경로 는 연결을 비공개로 유지할 수 있는 보안을 제공합니다. 키와 인증서로 암호화된 보안 HTTPS 경로를 생성하려면(별도로 생성하고 서명해야 하는PEM-format 파일) create route command를 사용하고 선택적으로 인증서와 키를 제공할 수 있습니다.

참고

TLS 는 HTTPS 및 기타 암호화된 프로토콜용 SSL을 대체합니다.

oc create route edge --service=frontend \
    --cert=${MASTER_CONFIG_DIR}/ca.crt \
    --key=${MASTER_CONFIG_DIR}/ca.key \
    --ca-cert=${MASTER_CONFIG_DIR}/ca.crt \
    --hostname=www.example.com

$ oc create route edge --service=frontend \
    --cert=${MASTER_CONFIG_DIR}/ca.crt \
    --key=${MASTER_CONFIG_DIR}/ca.key \
    --ca-cert=${MASTER_CONFIG_DIR}/ca.crt \
    --hostname=www.example.com

Copy to Clipboard

Toggle word wrap

보안 경로 생성 된 Above의 YAML 정의

apiVersion: v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

apiVersion: v1
kind: Route
metadata:
  name: frontend
spec:
  host: www.example.com
  to:
    kind: Service
    name: frontend
  tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
    caCertificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----

Copy to Clipboard

Toggle word wrap

현재 암호로 보호된 키 파일은 지원되지 않습니다. HAProxy는 시작 시 암호를 입력하라는 메시지를 표시하며 이 프로세스를 자동화할 방법이 없습니다. 키 파일에서 암호를 제거하려면 다음을 실행합니다.

openssl rsa -in <passwordProtectedKey.key> -out <new.key>

# openssl rsa -in <passwordProtectedKey.key> -out <new.key>

Copy to Clipboard

Toggle word wrap

키와 인증서를 지정하지 않고 보안 경로를 생성할 수 있습니다. 이 경우 라우터의 기본 인증서가 TLS 종료에 사용됩니다.

참고

OpenShift Container Platform의 TLS 종료는 사용자 정의 인증서를 제공하기 위해 SNI 를 사용합니다. 포트 443에서 수신된 비SNI 트래픽은 TLS 종료 및 요청된 호스트 이름과 일치하지 않는 기본 인증서로 처리되어 검증 오류가 발생합니다.

모든 유형의 TLS 종료 및 경로 기반 라우팅 에 대한 자세한 내용은 아키텍처 섹션에서 확인할 수 있습니다.

17.3. 경로 끝점이 쿠키 이름을 제어하도록 허용
링크 복사

OpenShift Container Platform은 모든 트래픽이 동일한 끝점에 도달하도록 하여 스테이트풀(stateful) 애플리케이션 트래픽을 사용할 수 있는 고정 세션을 제공합니다. 그러나 재시작, 스케일링 또는 구성 변경 등으로 인해 끝점 pod가 종료되면 이러한 상태 저장 특성이 사라질 수 있습니다.

OpenShift Container Platform에서는 쿠키를 사용하여 세션 지속성을 구성할 수 있습니다. 라우터는 사용자 요청을 처리할 끝점을 선택하고 세션에 대한 쿠키를 생성합니다. 쿠키는 요청에 대한 응답으로 다시 전달되고 사용자는 세션의 다음 요청과 함께 쿠키를 다시 보냅니다. 쿠키는 세션을 처리하는 끝점을 라우터에 알려 클라이언트 요청이 쿠키를 사용하여 동일한 Pod로 라우팅되도록 합니다.

쿠키 이름을 설정하여 경로에 자동 생성되는 기본 쿠키 이름을 덮어쓸 수 있습니다. 쿠키를 삭제하여 다음 요청에서 끝점을 다시 선택하도록 할 수 있습니다. 그러므로 서버에 과부하가 걸리면 클라이언트의 요청을 제거하고 재분배합니다.

원하는 쿠키 이름으로 경로에 주석을 답니다.

oc annotate route <route_name> router.openshift.io/cookie_name="<your_cookie_name>"

$ oc annotate route <route_name> router.openshift.io/cookie_name="<your_cookie_name>"

Copy to Clipboard

Toggle word wrap

예를 들어 my_cookie 를 새 쿠키 이름으로 지정하려면 다음을 수행합니다.

oc annotate route my_route router.openshift.io/cookie_name="my_cookie"

$ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"

Copy to Clipboard

Toggle word wrap

쿠키를 저장하고 경로에 액세스합니다.
```
curl $my_route -k -c /tmp/my_cookie
```
```
$ curl $my_route -k -c /tmp/my_cookie
```
Copy to Clipboard Toggle word wrap

18장. 외부 서비스 통합
링크 복사

18.1. 개요
링크 복사

많은 OpenShift Container Platform 애플리케이션은 외부 데이터베이스 또는 외부 SaaS 끝점과 같은 외부 리소스를 사용합니다. 이러한 외부 리소스는 네이티브 OpenShift Container Platform 서비스로 모델링할 수 있으므로 다른 내부 서비스와 마찬가지로 애플리케이션에서 작업할 수 있습니다.

송신 트래픽 은 방화벽 규칙 또는 Egress 라우터로 제어할 수 있습니다. 이를 통해 애플리케이션 서비스에 대한 고정 IP 주소가 허용됩니다.

18.2. 외부 데이터베이스의 서비스 정의
링크 복사

외부 서비스의 가장 일반적인 유형 중 하나는 외부 데이터베이스입니다. 외부 데이터베이스를 지원하려면 애플리케이션에 다음이 필요합니다.

통신할 끝점입니다.
다음을 포함한 인증 정보 및 좌표 세트:
- 사용자 이름
- 암호
- 데이터베이스 이름

외부 데이터베이스와 통합하기 위한 솔루션에는 다음이 포함됩니다.

SaaS 공급자를 OpenShift Container Platform 서비스로 나타내는 Service 오브젝트입니다.
서비스에 대한 하나 이상의 Endpoints.
인증 정보가 포함된 적절한 pod의 환경 변수입니다.

다음 단계에서는 외부 MySQL 데이터베이스와 통합하는 시나리오를 간략하게 설명합니다.

18.2.1. 1단계: 서비스 정의
링크 복사

IP 주소와 끝점을 제공하거나 FQDN(정규화된 도메인 이름)을 제공하여 서비스를 정의할 수 있습니다.

18.2.1.1. IP 주소 사용
링크 복사

외부 데이터베이스를 나타내는 OpenShift Container Platform 서비스를 생성합니다. 이는 내부 서비스를 생성하는 것과 유사합니다. 서비스의 Selector 필드에 차이가 있습니다.
내부 OpenShift Container Platform 서비스는 Selector 필드를 사용하여 레이블 을 사용하여 포드를 서비스와 연결합니다. EndpointsController 시스템 구성 요소는 선택기와 일치하는 Pod와 선택기를 지정하는 서비스의 끝점을 동기화합니다. 서비스 프록시 및 OpenShift Container Platform 라우터 는 서비스의 끝점 간에 서비스에 대한 요청을 부하 분산합니다.
외부 리소스를 나타내는 서비스에는 연결된 포드가 필요하지 않습니다. 대신 Selector 필드를 설정되지 않은 상태로 두십시오. 이는 외부 서비스를 나타내며 EndpointsController 에서 서비스를 무시하고 끝점을 수동으로 지정할 수 있습니다.
```
  kind: "Service"
  apiVersion: "v1"
  metadata:
    name: "external-mysql-service"
  spec:
    ports:
      -
        name: "mysql"
        protocol: "TCP"
        port: 3306
        targetPort: 3306 
        nodePort: 0
  selector: {} 
```
```
  kind: "Service"
  apiVersion: "v1"
  metadata:
    name: "external-mysql-service"
  spec:
    ports:
      -
        name: "mysql"
        protocol: "TCP"
        port: 3306
        targetPort: 3306 
```
1
```
        nodePort: 0
  selector: {} 
```
2
Copy to Clipboard Toggle word wrap
1
선택 사항: 서비스가 연결을 전달하는 백업 Pod의 포트입니다.
2
비워 둘 selector 필드입니다.
다음으로 서비스에 필요한 끝점을 만듭니다. 그러면 서비스 프록시 및 라우터에서 서비스로 전송된 트래픽을 보낼 위치를 제공합니다.
```
  kind: "Endpoints"
  apiVersion: "v1"
  metadata:
    name: "external-mysql-service" 
  subsets: 
    -
      addresses:
        -
          ip: "10.0.0.0" 
      ports:
        -
          port: 3306 
          name: "mysql"
```
```
  kind: "Endpoints"
  apiVersion: "v1"
  metadata:
    name: "external-mysql-service" 
```
1
```
  subsets: 
```
2
```
    -
      addresses:
        -
          ip: "10.0.0.0" 
```
3
```
      ports:
        -
          port: 3306 
```
4
```
          name: "mysql"
```
Copy to Clipboard Toggle word wrap
1
이전 단계에서 정의한 대로 Service 인스턴스의 이름입니다.
2
둘 이상의 제공된 경우 서비스에 대한 트래픽은 제공된 끝점 간에 부하 분산됩니다.
3
엔드포인트 IP는 루프백(127.0.0.0/8), 링크-로컬(169.254.0.0/16) 또는 링크-로컬 멀티캐스트(224.0.0.0/24)일 수 없습니다.
4
포트 및 이름 정의는 이전 단계에서 정의한 서비스의 포트 및 이름 값과 일치해야 합니다.

18.2.1.2. 외부 도메인 이름 사용
링크 복사

외부 도메인 이름을 사용하면 외부 서비스의 IP 주소 변경에 대해 걱정할 필요가 없기 때문에 외부 서비스 연결 기능을 보다 쉽게 관리할 수 있습니다.

ExternalName 서비스에는 선택기 또는 정의된 포트 또는 엔드포인트가 없으므로 ExternalName 서비스를 사용하여 트래픽을 외부 서비스로 보낼 수 있습니다.

kind: "Service"
apiVersion: "v1"
metadata:
  name: "external-mysql-service"
spec:
  type: ExternalName
  externalName: example.domain.name
selector: {}

kind: "Service"
apiVersion: "v1"
metadata:
  name: "external-mysql-service"
spec:
  type: ExternalName
  externalName: example.domain.name
selector: {}

1

Copy to Clipboard

Toggle word wrap

1: 비워 둘 selector 필드입니다.

외부 도메인 이름 서비스를 사용하면 시스템에서 externalName 필드의 DNS 이름(이전 예제의example.domain.name )이 서비스를 지원하는 리소스의 위치임을 알립니다. Kubernetes DNS 서버에 대해 DNS 요청이 생성되면 클라이언트가 반환된 이름을 조회하여 IP 주소를 가져오도록 CNAME 레코드에서 externalName 을 반환합니다.

18.2.2. 2 단계: 서비스 사용
링크 복사

이제 서비스와 끝점이 정의되었으므로 적절한 컨테이너에서 환경 변수를 설정하여 서비스를 사용할 자격 증명에 대한 적절한 Pod 액세스 권한을 부여합니다.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "my-app-deployment"
spec: 
  strategy:
    type: "Rolling"
    rollingParams:
      updatePeriodSeconds: 1 
      intervalSeconds: 1 
      timeoutSeconds: 120
  replicas: 2
  selector:
    name: "frontend"
  template:
    metadata:
      labels:
        name: "frontend"
    spec:
      containers:
        -
          name: "helloworld"
          image: "origin-ruby-sample"
          ports:
            -
              containerPort: 3306
              protocol: "TCP"
          env:
            -
              name: "MYSQL_USER"
              value: "${MYSQL_USER}" 
            -
              name: "MYSQL_PASSWORD"
              value: "${MYSQL_PASSWORD}" 
            -
              name: "MYSQL_DATABASE"
              value: "${MYSQL_DATABASE}"

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
  name: "my-app-deployment"
spec:

1


  strategy:
    type: "Rolling"
    rollingParams:
      updatePeriodSeconds: 1

2


      intervalSeconds: 1

3


      timeoutSeconds: 120
  replicas: 2
  selector:
    name: "frontend"
  template:
    metadata:
      labels:
        name: "frontend"
    spec:
      containers:
        -
          name: "helloworld"
          image: "origin-ruby-sample"
          ports:
            -
              containerPort: 3306
              protocol: "TCP"
          env:
            -
              name: "MYSQL_USER"
              value: "${MYSQL_USER}"

4


            -
              name: "MYSQL_PASSWORD"
              value: "${MYSQL_PASSWORD}"

5


            -
              name: "MYSQL_DATABASE"
              value: "${MYSQL_DATABASE}"

6

Copy to Clipboard

Toggle word wrap

1: DeploymentConfig 의 다른 필드는 생략됩니다.
2: 개별 Pod 업데이트 사이에 대기하는 시간입니다.
3: 업데이트 후 배포 상태를 폴링할 때까지 대기하는 시간입니다.
4: 서비스에 사용할 사용자 이름입니다.
5: 서비스와 함께 사용할 암호입니다.
6: 데이터베이스 이름입니다.

외부 데이터베이스 환경 변수

애플리케이션에서 외부 서비스를 사용하는 것은 내부 서비스를 사용하는 것과 유사합니다. 이전 단계에서 설명한 자격 증명을 사용하여 서비스에 대한 환경 변수 및 추가 환경 변수가 할당됩니다. 예를 들어 MySQL 컨테이너는 다음과 같은 환경 변수를 수신합니다.

EXTERNAL_MYSQL_SERVICE_SERVICE_HOST=<ip_address>
EXTERNAL_MYSQL_SERVICE_SERVICE_PORT=<port_number>
MYSQL_USERNAME=<mysql_username>
MYSQL_PASSWORD=<mysql_password>
MYSQL_DATABASE_NAME=<mysql_database>

애플리케이션은 환경에서 서비스에 대한 좌표와 자격 증명을 읽고 서비스를 통해 데이터베이스와의 연결을 설정합니다.

18.3. 외부 SaaS 공급자
링크 복사

외부 서비스의 일반적인 유형은 외부 SaaS 엔드포인트입니다. 외부 SaaS 공급자를 지원하려면 애플리케이션에 다음이 필요합니다.

통신할 끝점
다음과 같은 인증 정보 세트:
1. API 키
2. 사용자 이름
3. 암호

다음 단계에서는 외부 SaaS 공급자와 통합하는 시나리오를 간략하게 설명합니다.

18.3.1. IP 주소 및 끝점 사용
링크 복사

외부 서비스를 나타내는 OpenShift Container Platform 서비스를 생성합니다. 이는 내부 서비스를 생성하는 것과 유사하지만 서비스의 Selector 필드에 차이가 있습니다.
내부 OpenShift Container Platform 서비스는 Selector 필드를 사용하여 레이블 을 사용하여 포드를 서비스와 연결합니다. EndpointsController 라는 시스템 구성 요소는 선택기와 일치하는 Pod와 선택기를 지정하는 서비스의 끝점을 동기화합니다. 서비스 프록시 및 OpenShift Container Platform 라우터 는 서비스의 끝점 간에 서비스에 대한 요청을 부하 분산합니다.
외부 리소스를 나타내는 서비스에는 해당 포드를 연결할 필요가 없습니다. 대신 Selector 필드를 설정되지 않은 상태로 두십시오. 이렇게 하면 EndpointsController 에서 서비스를 무시하고 끝점을 수동으로 지정할 수 있습니다.
```
  kind: "Service"
  apiVersion: "v1"
  metadata:
    name: "example-external-service"
  spec:
    ports:
      -
        name: "mysql"
        protocol: "TCP"
        port: 3306
        targetPort: 3306 
        nodePort: 0
  selector: {} 
```
```
  kind: "Service"
  apiVersion: "v1"
  metadata:
    name: "example-external-service"
  spec:
    ports:
      -
        name: "mysql"
        protocol: "TCP"
        port: 3306
        targetPort: 3306 
```
1
```
        nodePort: 0
  selector: {} 
```
2
Copy to Clipboard Toggle word wrap
1
선택 사항: 서비스가 연결을 전달하는 백업 Pod의 포트입니다.
2
비워 둘 selector 필드입니다.

다음으로 서비스 프록시 및 라우터로 전송되는 트래픽을 보낼 위치에 대한 정보가 포함된 서비스의 끝점을 생성합니다.

kind: "Endpoints"
apiVersion: "v1"
metadata:
  name: "example-external-service" 
subsets: 
- addresses:
  - ip: "10.10.1.1"
  ports:
  - name: "mysql"
    port: 3306

kind: "Endpoints"
apiVersion: "v1"
metadata:
  name: "example-external-service"

1


subsets:

2


- addresses:
  - ip: "10.10.1.1"
  ports:
  - name: "mysql"
    port: 3306

Copy to Clipboard

Toggle word wrap

1: Service 인스턴스의 이름입니다.
2: 서비스에 대한 트래픽은 여기에 제공된 하위 집합 간에 로드 밸런싱됩니다.

이제 서비스와 끝점이 정의되었으므로 적절한 컨테이너에서 환경 변수를 설정하여 서비스를 사용할 수 있는 인증 정보를 Pod에 제공합니다.

  kind: "DeploymentConfig"
  apiVersion: "v1"
  metadata:
    name: "my-app-deployment"
  spec:  
    strategy:
      type: "Rolling"
      rollingParams:
        timeoutSeconds: 120
    replicas: 1
    selector:
      name: "frontend"
    template:
      metadata:
        labels:
          name: "frontend"
      spec:
        containers:
          -
            name: "helloworld"
            image: "openshift/openshift/origin-ruby-sample"
            ports:
              -
                containerPort: 3306
                protocol: "TCP"
            env:
              -
                name: "SAAS_API_KEY" 
                value: "<SaaS service API key>"
              -
                name: "SAAS_USERNAME" 
                value: "<SaaS service user>"
              -
                name: "SAAS_PASSPHRASE" 
                value: "<SaaS service passphrase>"

  kind: "DeploymentConfig"
  apiVersion: "v1"
  metadata:
    name: "my-app-deployment"
  spec:

1


    strategy:
      type: "Rolling"
      rollingParams:
        timeoutSeconds: 120
    replicas: 1
    selector:
      name: "frontend"
    template:
      metadata:
        labels:
          name: "frontend"
      spec:
        containers:
          -
            name: "helloworld"
            image: "openshift/openshift/origin-ruby-sample"
            ports:
              -
                containerPort: 3306
                protocol: "TCP"
            env:
              -
                name: "SAAS_API_KEY"

2


                value: "<SaaS service API key>"
              -
                name: "SAAS_USERNAME"

3


                value: "<SaaS service user>"
              -
                name: "SAAS_PASSPHRASE"

4


                value: "<SaaS service passphrase>"

Copy to Clipboard

Toggle word wrap

1: DeploymentConfig 의 다른 필드는 생략됩니다.
2: SAAS_API_KEY: 서비스에서 사용할 API 키입니다.
3: SAAS_USERNAME: 서비스에서 사용할 사용자 이름입니다.
4: SAAS_PASSPHRASE: 서비스에서 사용할 암호입니다.

이러한 변수는 컨테이너에 환경 변수로 추가됩니다. 환경 변수를 사용하면 서비스 간 통신이 가능하며 API 키, 사용자 이름 및 암호 인증 또는 인증서와 같은 추가 매개 변수가 필요하지 않을 수 있습니다.

외부 SaaS 공급자 환경 변수

마찬가지로 내부 서비스를 사용하는 경우 애플리케이션에 서비스의 환경 변수 및 이전 단계에 설명된 인증 정보가 포함된 추가 환경 변수가 할당됩니다. 이전 예에서 컨테이너는 다음 환경 변수를 수신합니다.

EXAMPLE_EXTERNAL_SERVICE_SERVICE_HOST=<ip_address>
EXAMPLE_EXTERNAL_SERVICE_SERVICE_PORT=<port_number>
SAAS_API_KEY=<saas_api_key>
SAAS_USERNAME=<saas_username>
SAAS_PASSPHRASE=<saas_passphrase>

애플리케이션은 환경에서 서비스의 좌표와 자격 증명을 읽고 서비스와의 연결을 설정합니다.

18.3.2. 외부 도메인 이름 사용
링크 복사

ExternalName 서비스에는 선택기 또는 정의된 포트 또는 엔드포인트가 없습니다. ExternalName 서비스를 사용하여 클러스터 외부의 외부 서비스에 트래픽을 할당할 수 있습니다.

  kind: "Service"
  apiVersion: "v1"
  metadata:
    name: "external-mysql-service"
  spec:
    type: ExternalName
    externalName: example.domain.name
  selector: {}

  kind: "Service"
  apiVersion: "v1"
  metadata:
    name: "external-mysql-service"
  spec:
    type: ExternalName
    externalName: example.domain.name
  selector: {}

1

Copy to Clipboard

Toggle word wrap

1: 비워 둘 selector 필드입니다.

ExternalName 서비스를 사용하면 이전예제의 externalName 필드 값(예.domain.name )을 자동으로 CNAME 레코드를 삽입하고, 서비스 이름을 외부 DNS 주소에 직접 매핑하고 엔드포인트 레코드의 필요성을 우회하여 서비스를 매핑합니다.

19장. 장치 관리자 사용
링크 복사

19.1. 장치 관리자가 수행하는 작업
링크 복사

중요

장치 관리자는 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

장치 관리자는 장치 플러그인이라는 Kubelet 플러그인을 사용하여 특수 노드 하드웨어 리소스를 알리기 위한 메커니즘을 제공하는 Kubelet 기능입니다. ???

모든 공급 업체는 업스트림 코드 변경없이 특수 하드웨어를 알리기 위해 장치 플러그인을 구현할 수 있습니다.

장치 관리자는 장치를 확장 리소스(Extended Resources)으로 공개합니다. 사용자 pod는 다른 확장 리소스 를 요청하는 데 사용되는 동일한 제한/요청 메커니즘을 사용하여 장치 관리자에 의해 공개된 장치를 사용할 수 있습니다.

19.1.1. 등록
링크 복사

시작 시 장치 플러그인은 /var/lib/kubelet/device-plugins/kubelet.sock 에서 Register 를 호출하는 장치 관리자에 자신을 등록하고 장치 관리자 요청을 제공하기 위해 /var/lib/kubelet/device-plugins/<plugin>.sock 에서 gRPC 서비스를 시작합니다.

19.1.2. 장치 검색 및 상태 모니터링
링크 복사

장치 관리자는 새 등록 요청을 처리하는 동안 장치 플러그인 서비스에서 ListAndWatch 원격 프로 시저 호출 (RPC)을 시작합니다. 이에 응답하여 Device Manger는 플러그인에서 gRPC 스트림을 통해 장치 오브젝트 목록을 가져옵니다. 장치 관리자는 플러그인에서 새 업데이트의 유무에 대해 스트림을 모니터링합니다. 플러그인 측에서도 플러그인은 스트림을 열린 상태로 유지하고 장치 상태가 변경될 때마다 동일한 스트리밍 연결을 통해 새 장치 목록이 장치 관리자로 전송됩니다.

19.1.3. 장치 할당
링크 복사

새로운 pod 승인 요청을 처리하는 동안 Kubelet은 장치 할당을 위해 요청된 Extended Resources를 장치 관리자에게 전달합니다. 장치 관리자는 데이터베이스에서 해당 플러그인이 존재하는지 확인합니다. 플러그인이 존재하고 로컬 캐시로 할당 가능한 디바이스가 있는 경우 Allocate RPC가 특정 디바이스 플러그인에서 호출됩니다.

또한 장치 플러그인은 드라이버 설치, 장치 초기화 및 장치 재설정과 같은 몇 가지 다른 장치 별 작업을 수행할 수 있습니다. 이러한 기능은 구현마다 다릅니다.

19.2. 장치 관리자 활성화
링크 복사

장치 관리자는 장치 플러그인을 구현하여 업스트림 코드 변경없이 특수 하드웨어를 사용할 수 있습니다.

대상 노드 또는 노드에서 장치 관리자 지원을 활성화합니다.

cat /etc/origin/node/node-config.yaml
...
kubeletArguments:
...
  feature-gates:
  - DevicePlugins=true

systemctl restart atomic-openshift-node

# cat /etc/origin/node/node-config.yaml
...
kubeletArguments:
...
  feature-gates:
  - DevicePlugins=true

# systemctl restart atomic-openshift-node

Copy to Clipboard

Toggle word wrap

노드에서 /var/lib/kubelet/device-plugins/kubelet.sock이 작성되었는지 확인하여 장치 관리자가 실제로 사용 가능한지 확인합니다. 이는 장치 관리자의 gRPC 서버가 새 플러그인 등록을 수신하는 UNIX 도메인 소켓입니다. 이 소켓 파일은 장치 관리자가 활성화된 경우에만 Kubelet을 시작할 때 생성됩니다.

20장. 장치 플러그인 사용
링크 복사

20.1. 어떤 장치 플러그인입니까?
링크 복사

중요

장치 플러그인은 기술 프리뷰에 있으며 프로덕션 워크로드를 위한 것이 아닙니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

장치 플러그인을 사용하면 사용자 정의 코드를 작성하지 않고 OpenShift Container Platform Pod에서 특정 장치 유형(GPU, InfiniBand 또는 벤더별 초기화 및 설정이 필요한 기타 유사한 컴퓨팅 리소스)을 사용할 수 있습니다. 장치 플러그인은 클러스터 전체에서 하드웨어 장치를 소비할 수 있는 일관되고 이식 가능한 솔루션을 제공합니다. 장치 플러그인은 확장 메커니즘을 통해 이러한 장치를 지원하여 컨테이너에서 이러한 장치를 사용할 수 있도록 하고, 이러한 장치의 상태 점검을 제공하며 안전하게 공유합니다.

장치 플러그인은 특정 하드웨어 리소스를 관리하는 노드 (external to atomic-openshift-node.service)에서 실행되는 gRPC 서비스입니다. 모든 장치 플러그인은 다음 원격 프로 시저 호출 (RPC)을 지원해야합니다.

service DevicePlugin {
      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plugin can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
}

service DevicePlugin {
      // ListAndWatch returns a stream of List of Devices
      // Whenever a Device state change or a Device disappears, ListAndWatch
      // returns the new list
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}

      // Allocate is called during container creation so that the Device
      // Plugin can run device specific operations and instruct Kubelet
      // of the steps to make the Device available in the container
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
}

Copy to Clipboard

Toggle word wrap

20.1.1. 장치 플러그인 예
링크 복사

참고

간편한 장치 플러그인 참조 구현을 위해 장치 관리자 코드에 vendor/k8s.io/kubernetes/pkg/kubelet/cm/deviceplugin/device_plugin_stub.go 스텁 장치 플러그인이 있습니다.

20.2. 장치 플러그인 배포 방법
링크 복사

장치 플러그인 배포에는 DaemonSets가 권장되는 방법입니다. ???
시작 시 장치 플러그인은 노드의 /var/lib/kubelet/device-plugin/ 에 UNIX 도메인 소켓을 만들어 장치 관리자 의 RPC를 제공하려고 합니다.
장치 플러그인은 하드웨어 리소스, 호스트 파일 시스템에 대한 액세스 및 소켓 생성을 관리해야 하므로 권한 있는 보안 컨텍스트에서 실행해야 합니다.
배포 단계에 대한 보다 구체적인 세부 사항은 각 장치 플러그인 구현에서 확인할 수 있습니다.

21장. 보안
링크 복사

21.1. 보안 사용
링크 복사

이 주제에서는 시크릿의 중요한 속성에 대해 설명하고 개발자가 이를 사용하는 방법에 대한 개요를 제공합니다.

Secret 오브젝트 유형에서는 암호, OpenShift Container Platform 클라이언트 구성 파일, dockercfg 파일, 개인 소스 리포지토리 자격 증명 등과 같은 중요한 정보를 보유하는 메커니즘을 제공합니다. 보안은 Pod에서 중요한 콘텐츠를 분리합니다. 볼륨 플러그인을 사용하여 컨테이너에 보안을 마운트하거나 시스템에서 보안을 사용하여 Pod 대신 조치를 수행할 수 있습니다.

YAML 보안 오브젝트 정의

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque 
data: 
  username: dmFsdWUtMQ0K 
  password: dmFsdWUtMg0KDQo=
stringData: 
  hostname: myapp.mydomain.com

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque

1


data:

2


  username: dmFsdWUtMQ0K

3


  password: dmFsdWUtMg0KDQo=
stringData:

4


  hostname: myapp.mydomain.com

5

Copy to Clipboard

Toggle word wrap

1

보안의 키 이름과 값의 구조를 나타냅니다.

2

data 필드에서 허용되는 키 형식은 Kubernetes 구분자 용어집의 DNS_SUBDOMAIN 값에 있는 지침을 충족해야 합니다.

3

데이터 맵의 키와 관련된 값은 base64로 인코딩되어야 합니다.

4

stringData 맵의 키와 관련된 값은 일반 텍스트 문자열로 구성됩니다.

5

stringData 맵의 항목이 base64로 변환된 후 해당 항목이 자동으로 data 맵으로 이동합니다. 이 필드는 쓰기 전용이며 값은 data 필드를 통해서만 반환됩니다.

로컬 .docker/config.json 파일에서 보안을 생성합니다.

oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

$ oc create secret generic dockerhub \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

Copy to Clipboard

Toggle word wrap

이 명령은 dockerhub라는 보안의 JSON 사양을 생성한 후 오브젝트를 생성합니다.

YAML 보안 오브젝트 정의

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque 
data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque

1


data:
  username: dXNlci1uYW1l
  password: cGFzc3dvcmQ=

Copy to Clipboard

Toggle word wrap

1: 불투명 보안을 지정합니다.

Docker 구성 JSON 파일 시크릿 오브젝트 정의

apiVersion: v1
kind: Secret
metadata:
  name: aregistrykey
  namespace: myapps
type: kubernetes.io/dockerconfigjson 
data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

apiVersion: v1
kind: Secret
metadata:
  name: aregistrykey
  namespace: myapps
type: kubernetes.io/dockerconfigjson

1


data:
  .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==

2

Copy to Clipboard

Toggle word wrap

1: 보안에서 Docker 구성 JSON 파일을 사용하도록 지정합니다.
2: base64로 인코딩된 Docker 구성 JSON 파일의 출력

21.1.1. 보안 속성
링크 복사

주요 속성은 다음과 같습니다.

보안 데이터는 정의와는 별도로 참조할 수 있습니다.
보안 데이터 볼륨은 임시 파일 저장 기능(tmpfs)에 의해 지원되며 노드에 저장되지 않습니다.
보안 데이터는 네임스페이스 내에서 공유할 수 있습니다.

21.1.2. 보안 생성
링크 복사

먼저 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다.

보안 생성 시 다음을 수행합니다.

보안 데이터를 사용하여 보안 오브젝트를 생성합니다.
Pod 서비스 계정을 업데이트하여 보안에 대한 참조를 허용합니다.
보안을 환경 변수로 사용하거나 secret 볼륨을 사용하여 파일로 사용하는 Pod를 생성합니다.

create 명령을 사용하여 JSON 또는 YAML 파일에서 보안 오브젝트를 생성할 수 있습니다.

oc create -f <filename>

$ oc create -f <filename>

Copy to Clipboard

Toggle word wrap

21.1.3. 보안 유형
링크 복사

type 필드의 값은 보안의 키 이름과 값의 구조를 나타냅니다. 유형을 사용하면 보안 오브젝트에 사용자 이름과 키를 적용할 수 있습니다. 검증을 수행하지 않으려면 기본값인 opaque 유형을 사용합니다.

보안 데이터에 특정 키 이름이 있는지 확인하기 위해 서버 측 최소 검증을 트리거하려면 다음 유형 중 하나를 지정합니다.

kubernetes.io/service-account-token. 서비스 계정 토큰입니다.
kubernetes.io/dockercfg. 필수 Docker 자격 증명으로 .dockercfg 파일을 사용합니다.
kubernetes.io/dockerconfigjson. 필수 Docker 자격 증명으로 .docker/config.json 파일을 사용합니다.
kubernetes.io/basic-auth. 기본 인증에 사용합니다.
kubernetes.io/ssh-auth. SSH 키 인증에 사용합니다.
kubernetes.io/tls. TLS 인증 기관과함께 사용

검증을 수행하지 않으려면 type= Opaque를 지정합니다. 즉 보안에서 키 이름 또는 값에 대한 규칙을 준수하도록 요청하지 않습니다. opaque 보안에는 임의의 값을 포함할 수 있는 비정형 key:value 쌍을 사용할 수 있습니다.

참고

example.com/my-secret-type과 같은 다른 임의의 유형을 지정할 수 있습니다. 이러한 유형은 서버 측에 적용되지 않지만 보안 생성자가 해당 유형의 키/값 요구 사항을 준수하도록 의도했음을 나타냅니다.

다른 시크릿 유형의 예는 보안 사용의 코드 샘플을 참조하십시오.

21.1.4. 보안 업데이트
링크 복사

보안 값을 수정해도 이미 실행 중인 Pod에서 사용하는 값은 동적으로 변경되지 않습니다. 보안을 변경하려면 원래 Pod를 삭제하고 새 Pod를 생성해야 합니다(대개 동일한 PodSpec 사용).

보안 업데이트 작업에서는 새 컨테이너 이미지를 배포하는 것과 동일한 워크플로를 따릅니다. kubectl rolling-update 명령을 사용할 수 있습니다.

보안의 resourceVersion 값은 참조 시 지정되지 않습니다. 따라서 Pod가 시작되는 동시에 보안이 업데이트되는 경우 Pod에 사용될 보안의 버전이 정의되지 않습니다.

참고

현재는 Pod가 생성될 때 사용된 보안 오브젝트의 리소스 버전을 확인할 수 없습니다. 컨트롤러에서 이전 resourceVersion 을 사용하여 재시작할 수 있도록 Pod에서 이 정보를 보고하도록 계획되어 있습니다. 그동안 기존 보안 데이터를 업데이트하지 말고 고유한 이름으로 새 보안을 생성하십시오.

21.2. 볼륨 및 환경 변수의 보안
링크 복사

보안 데이터가 있는 YAML 파일의 예를 참조하십시오.

시크릿을 생성한 후 다음을 수행할 수 있습니다.

보안을 참조할 Pod를 생성합니다.
```
oc create -f <your_yaml_file>.yaml
```
```
$ oc create -f <your_yaml_file>.yaml
```
Copy to Clipboard Toggle word wrap
로그를 가져옵니다.
```
oc logs secret-example-pod
```
```
$ oc logs secret-example-pod
```
Copy to Clipboard Toggle word wrap
Pod를 삭제합니다.
```
oc delete pod secret-example-pod
```
```
$ oc delete pod secret-example-pod
```
Copy to Clipboard Toggle word wrap

21.3. 이미지 가져오기 보안
링크 복사

자세한 내용은 이미지 가져오기 시크릿 사용을 참조하십시오.

21.4. 소스 복제 보안
링크 복사

빌드 중 소스 복제 보안을 사용하는 방법에 대한 자세한 내용은 빌드 입력을 참조하십시오.

21.5. 서비스 제공 인증서 보안
링크 복사

서비스 제공 인증서 보안은 즉시 사용 가능한 인증서가 필요한 복잡한 미들웨어 애플리케이션을 지원하기 위한 것입니다. 해당 설정은 관리자 툴에서 노드 및 마스터에 대해 생성하는 서버 인증서와 동일합니다.

서비스와의 통신을 보호하려면 클러스터에서 서명된 제공 인증서/키 쌍을 네임스페이스의 보안에 생성하도록 합니다. 이 작업을 수행하려면 보안에 사용할 값으로 서비스에 service.alpha.openshift.io/serving-cert-secret-name 주석을 설정합니다. 그러면 PodSpec 에서 해당 보안을 마운트할 수 있습니다. 사용 가능한 경우 Pod가 실행됩니다. 인증서는 내부 서비스 DNS 이름인 <service.name>.<service.namespace>.svc에 적합합니다.

인증서 및 키는 PEM 형식이며 각각 tls.crt 및 tls.key에 저장됩니다. 인증서/키 쌍은 만료 시기가 다가오면 자동으로 교체됩니다. 보안의 service.alpha.openshift.io/expiry 주석에서 RFC3339 형식으로 된 만료 날짜를 확인합니다.

기타 Pod는 해당 Pod에 자동으로 마운트되는 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt 파일의 CA 번들을 사용하여 내부 DNS 이름에만 서명되는 클러스터 생성 인증서를 신뢰할 수 있습니다.

이 기능의 서명 알고리즘은 x509.SHA256WithRSA입니다. 직접 교대하려면 생성된 보안을 삭제합니다. 새 인증서가 생성됩니다.

21.6. 제한 사항
링크 복사

보안을 사용하려면 Pod에서 보안을 참조해야 합니다. 보안은 다음 세 가지 방법으로 Pod에서 사용할 수 있습니다.

컨테이너에 대한 환경 변수를 채우기 위해 다음을 수행합니다.
하나 이상의 컨테이너에 마운트된 볼륨에서 파일로 사용.
Pod의 이미지를 가져올 때 kubelet으로 사용.

볼륨 유형 보안은 볼륨 메커니즘을 사용하여 데이터를 컨테이너에 파일로 작성합니다. imagePullSecrets 는 서비스 계정을 사용하여 네임스페이스의 모든 Pod에 보안을 자동으로 삽입합니다.

템플릿에 보안 정의가 포함된 경우, 제공된 보안을 사용하는 템플릿에서만 시크릿 볼륨 소스가 검증되고 지정된 오브젝트 참조가 실제로 Secret 유형의 오브젝트를 가리키는지 확인하는 것입니다. 따라서 보안을 생성한 후 해당 보안을 사용하는 Pod를 생성해야 합니다. 가장 효과적인 방법은 서비스 계정을 사용하여 자동으로 삽입되도록 하는 것입니다.

Secret API 오브젝트는 네임스페이스에 있습니다. 동일한 네임스페이스에 있는 Pod만 참조할 수 있습니다.

개별 보안은 1MB로 제한됩니다. 이는 대규모 보안이 생성되어 apiserver 및 kubelet 메모리가 소진되는 것을 막기 위한 것입니다. 그러나 작은 보안을 많이 생성해도 메모리가 소모될 수 있습니다.

21.6.1. 시크릿 데이터 키
링크 복사

보안키는 DNS 하위 도메인에 있어야 합니다.

21.7. 예제
링크 복사

예 21.1. 파일 4개를 생성할 YAML 보안

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: dmFsdWUtMQ0K     
  password: dmFsdWUtMQ0KDQo= 
stringData:
  hostname: myapp.mydomain.com 
  secret.properties: |-     
    property1=valueA
    property2=valueB

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: dmFsdWUtMQ0K

1


  password: dmFsdWUtMQ0KDQo=

2


stringData:
  hostname: myapp.mydomain.com

3


  secret.properties: |-

4


    property1=valueA
    property2=valueB

Copy to Clipboard

Toggle word wrap

1: 파일에 디코딩된 값이 포함되어 있습니다.
2: 파일에 디코딩된 값이 포함되어 있습니다.
3: 파일에 제공된 문자열이 포함되어 있습니다.
4: 파일에 제공된 데이터가 포함되어 있습니다.

예 21.2. 보안 데이터로 볼륨의 파일을 채우는 Pod의 YAML

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:
          # name must match the volume name below
          - name: secret-volume
            mountPath: /etc/secret-volume
            readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:
          # name must match the volume name below
          - name: secret-volume
            mountPath: /etc/secret-volume
            readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

예 21.3. 보안 데이터로 환경 변수를 채우는 Pod의 YAML

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: username
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: username
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

예 21.4. 보안 데이터로 환경 변수를 채우는 빌드 구성의 YAML

apiVersion: v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:
            name: test-secret
            key: username

apiVersion: v1
kind: BuildConfig
metadata:
  name: secret-example-bc
spec:
  strategy:
    sourceStrategy:
      env:
      - name: TEST_SECRET_USERNAME_ENV_VAR
        valueFrom:
          secretKeyRef:
            name: test-secret
            key: username

Copy to Clipboard

Toggle word wrap

21.8. 문제 해결
링크 복사

로 서비스 인증서 생성이 실패하면 서비스의 service.alpha.openshift.io/serving-cert-generation-error 주석이 포함됩니다.

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60

Copy to Clipboard

Toggle word wrap

인증서를 생성한 서비스가 더 이상 존재하지 않거나 serviceUID 가 다릅니다. 이전 보안을 제거하고 서비스 service.alpha.openshift.io/serving-cert-generation-error , service.alpha.openshift.io/serving-cert-generation-error -num 주석을 지워 인증서를 강제로 다시 생성해야 합니다.

oc delete secret <secret_name>
oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-
oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-num-

$ oc delete secret <secret_name>
$ oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-
$ oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-num-

Copy to Clipboard

Toggle word wrap

참고

주석을 제거하는 명령에는 제거할 주석 이름 뒤에 - 가 있습니다.

22장. ConfigMaps
링크 복사

22.1. 개요
링크 복사

많은 애플리케이션에서는 구성 파일, 명령줄 인수 및 환경 변수를 조합한 구성이 필요합니다. 컨테이너화된 애플리케이션을 이식하기 위해 이러한 구성 아티팩트를 이미지 콘텐츠와 분리해야 합니다.

ConfigMap 오브젝트는 컨테이너를 OpenShift Container Platform과 무관하게 유지하면서 구성 데이터로 컨테이너를 삽입하는 메커니즘을 제공합니다. ConfigMap 을 사용하여 개별 속성 또는 전체 구성 파일 또는 JSON Blob과 같은 세분화된 정보를 저장할 수 있습니다.

ConfigMap API 오브젝트에는 Pod에서 사용하거나 컨트롤러와 같은 시스템 구성 요소의 구성 데이터를 저장하는 데 사용할 수 있는 구성 데이터의 키-값 쌍이 있습니다. ConfigMap 은 보안 과 유사하지만 민감한 정보가 포함되지 않은 문자열 작업을 보다 편리하게 지원하도록 설계되었습니다.

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

ConfigMap 오브젝트 정의

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data: 
  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3

kind: ConfigMap
apiVersion: v1
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data:

1


  example.property.1: hello
  example.property.2: world
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3

Copy to Clipboard

Toggle word wrap

1: 구성 데이터를 포함합니다.

다양한 방법으로 Pod에서 구성 데이터를 사용할 수 있습니다. ConfigMap 을 사용하여 다음을 수행할 수 있습니다.

환경 변수 값을 채웁니다.
컨테이너에서 명령줄 인수를 설정합니다.
볼륨에 구성 파일을 채웁니다.

사용자 및 시스템 구성 요소 모두 구성 데이터를 ConfigMap 에 저장할 수 있습니다.

22.2. ConfigMap 생성
링크 복사

다음 명령을 사용하여 디렉터리, 특정 파일 또는 리터럴 값에서 ConfigMap 을 쉽게 생성할 수 있습니다.

oc create configmap <configmap_name> [options]

$ oc create configmap <configmap_name> [options]

Copy to Clipboard

Toggle word wrap

다음 섹션에서는 ConfigMap 을 생성할 수 있는 다양한 방법을 다룹니다.

22.2.1. Directories에서 생성
링크 복사

ConfigMap 을 채우려는 데이터가 이미 포함된 일부 파일이 있는 디렉토리를 고려하십시오.

ls example-files
cat example-files/game.properties
cat example-files/ui.properties

$ ls example-files
game.properties
ui.properties

$ cat example-files/game.properties
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

$ cat example-files/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Copy to Clipboard

Toggle word wrap

다음 명령을 사용하여 이 디렉터리의 각 파일의 콘텐츠를 포함하는 ConfigMap 을 생성할 수 있습니다.

oc create configmap game-config \
    --from-file=example-files/

$ oc create configmap game-config \
    --from-file=example-files/

Copy to Clipboard

Toggle word wrap

--from-file 옵션이 디렉토리를 가리키는 경우 해당 디렉터리의 각 파일은 ConfigMap 의 키를 채우는 데 사용됩니다. 여기서 키 이름은 파일 이름이고 키의 값은 파일의 내용입니다.

예를 들어 위의 명령은 다음 ConfigMap 을 생성합니다.

oc describe configmaps game-config

$ oc describe configmaps game-config
Name:           game-config
Namespace:      default
Labels:         <none>
Annotations:    <none>

Data

game.properties:        121 bytes
ui.properties:          83 bytes

Copy to Clipboard

Toggle word wrap

맵에 있는 두 개의 키는 명령에 지정된 디렉터리의 파일 이름에서 생성되는 것을 확인할 수 있습니다. 해당 키의 콘텐츠가 커질 수 있으므로 oc describe 의 출력은 키와 크기의 이름만 표시합니다.

키 값을 표시하려면 oc에서 -o 옵션을 사용하여 오브젝트를 가져올 수 있습니다.

oc get configmaps game-config -o yaml

$ oc get configmaps game-config -o yaml

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:34:05Z
  name: game-config
  namespace: default
  resourceVersion: "407"-
  selflink: /api/v1/namespaces/default/configmaps/game-config
  uid: 30944725-d66e-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

22.2.2. 파일에서 생성
링크 복사

특정 파일을 사용하여 --from-file 옵션을 전달하여 CLI에 여러 번 전달할 수도 있습니다. 다음은 Creating from Directories 예제에 동일한 결과를 제공합니다.

특정 파일을 지정하는 ConfigMap 생성:

oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties

$ oc create configmap game-config-2 \
    --from-file=example-files/game.properties \
    --from-file=example-files/ui.properties

Copy to Clipboard

Toggle word wrap

결과 확인:

oc get configmaps game-config-2 -o yaml

$ oc get configmaps game-config-2 -o yaml

apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config-2
  namespace: default
  resourceVersion: "516"
  selflink: /api/v1/namespaces/default/configmaps/game-config-2
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

또한 key=value 표현식을 전달하여 --from-file 옵션을 사용하여 개별 파일에 사용할 키를 설정할 수도 있습니다. 예를 들어 다음과 같습니다.

키-값 쌍을 지정하는 ConfigMap 을 생성합니다.

oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties

$ oc create configmap game-config-3 \
    --from-file=game-special-key=example-files/game.properties

Copy to Clipboard

Toggle word wrap

결과 확인:

oc get configmaps game-config-3 -o yaml

$ oc get configmaps game-config-3 -o yaml

apiVersion: v1
data:
  game-special-key: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  selflink: /api/v1/namespaces/default/configmaps/game-config-3
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

22.2.3. Lite Values에서 생성
링크 복사

ConfigMap 에 리터럴 값을 제공할 수도 있습니다. --from-literal 옵션은 명령줄에서 직접 리터럴 값을 제공할 수 있는 key=value 구문을 사용합니다.

리터럴 값을 지정하는 ConfigMap 생성:

oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm

$ oc create configmap special-config \
    --from-literal=special.how=very \
    --from-literal=special.type=charm

Copy to Clipboard

Toggle word wrap

결과 확인:

oc get configmaps special-config -o yaml

$ oc get configmaps special-config -o yaml

apiVersion: v1
data:
  special.how: very
  special.type: charm
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  selflink: /api/v1/namespaces/default/configmaps/special-config
  uid: dadce046-d673-11e5-8cd0-68f728db1985

Copy to Clipboard

Toggle word wrap

22.3. 사용 사례: Pod에서 ConfigMap 사용
링크 복사

다음 섹션에서는 Pod에서 ConfigMap 오브젝트를 사용하는 경우 몇 가지 사용 사례에 대해 설명합니다.

22.3.1. 환경 변수에서 사용
링크 복사

ConfigMap 을 사용하여 개별 환경 변수를 채우거나 유효한 환경 변수 이름을 형성하는 모든 키의 환경 변수를 채울 수 있습니다. 예를 들어 다음 ConfigMap을 고려하십시오.

두 개의 환경 변수가 있는 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config 
  namespace: default
data:
  special.how: very 
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config

1


  namespace: default
data:
  special.how: very

2


  special.type: charm

3

Copy to Clipboard

Toggle word wrap

1: ConfigMap 의 이름입니다.
2 3: 삽입할 환경 변수입니다.

하나의 환경 변수가 있는 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config 
  namespace: default
data:
  log_level: INFO

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-config

1


  namespace: default
data:
  log_level: INFO

2

Copy to Clipboard

Toggle word wrap

1: ConfigMap 의 이름입니다.
2: 삽입할 환경 변수입니다.

configMapKeyRef 섹션을 사용하여 Pod에서 이 ConfigMap 의 키를 사용할 수 있습니다.

특정 환경 변수를 삽입하도록 구성된 샘플 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env: 
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config 
              key: special.how 
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config 
              key: special.type 
              optional: true 
      envFrom: 
        - configMapRef:
            name: env-config 
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:

1


        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config

2


              key: special.how

3


        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config

4


              key: special.type

5


              optional: true

6


      envFrom:

7


        - configMapRef:
            name: env-config

8


  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

1: ConfigMap 에서 지정된 환경 변수를 가져오는 스탠자입니다.
2 4: 특정 환경 변수를 가져올 ConfigMap 의 이름입니다.
3 5: ConfigMap 에서 가져올 환경 변수입니다.
6: 환경 변수를 선택적으로 만듭니다. 선택적으로 지정된 ConfigMap 및 키가 없는 경우에도 Pod가 시작됩니다.
7: ConfigMap 에서 모든 환경 변수를 가져오는 스탠자입니다.
8: 모든 환경 변수를 가져올 ConfigMap 의 이름입니다.

이 Pod가 실행되면 출력에 다음 행이 포함됩니다.

SPECIAL_LEVEL_KEY=very
log_level=INFO

SPECIAL_LEVEL_KEY=very
log_level=INFO

Copy to Clipboard

Toggle word wrap

22.3.2. 명령줄 인수 설정
링크 복사

ConfigMap 을 사용하여 컨테이너에서 명령 또는 인수 값을 설정할 수도 있습니다. 이 작업은 Kubernetes 대체 구문 $(VAR_NAME) 을 사용하여 수행됩니다. 다음 ConfigMap을 고려하십시오.

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Copy to Clipboard

Toggle word wrap

명령줄에 값을 삽입하려면 환경 변수 사용 사례에서 사용하는 것처럼 환경 변수로 사용할 키를 사용해야 합니다. ??? 그런 다음 $(VAR_NAME) 구문을 사용하여 컨테이너의 명령에서 참조할 수 있습니다.

특정 환경 변수를 삽입하도록 구성된 샘플 Pod 사양

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.type
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

이 Pod가 실행되면 test-container 컨테이너의 출력은 다음과 같습니다.

very charm

very charm

Copy to Clipboard

Toggle word wrap

22.3.3. 볼륨에서 사용
링크 복사

볼륨에서 ConfigMap 을 사용할 수도 있습니다. 다음 예제 ConfigMap 으로 다시 돌아갑니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  special.how: very
  special.type: charm

Copy to Clipboard

Toggle word wrap

볼륨에 이 ConfigMap 을 사용하기 위한 몇 가지 다른 옵션이 있습니다. 가장 기본적인 방법은 키가 파일 이름이고 파일의 내용은 키 값인 파일로 볼륨을 채우는 것입니다.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/special.how" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

이 Pod가 실행되면 출력은 다음과 같습니다.

very

very

Copy to Clipboard

Toggle word wrap

ConfigMap 키가 프로젝션된 볼륨 내의 경로를 제어할 수도 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/path/to/special-key" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: special.how
          path: path/to/special-key
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

이 Pod가 실행되면 출력은 다음과 같습니다.

very

very

Copy to Clipboard

Toggle word wrap

22.4. 예: Redis 구성
링크 복사

실제 예제의 경우 ConfigMap 을 사용하여 Redis를 구성할 수 있습니다. Redis를 캐시로 사용하는 데 권장되는 구성으로 Redis를 삽입하려면 Redis 구성 파일에 다음이 포함되어야 합니다.

maxmemory 2mb
maxmemory-policy allkeys-lru

maxmemory 2mb
maxmemory-policy allkeys-lru

Copy to Clipboard

Toggle word wrap

구성 파일이 example-files/redis/redis-config 에 있는 경우 ConfigMap 을 생성합니다.

구성 파일을 지정하는 ConfigMap 을 생성합니다.

oc create configmap example-redis-config \
    --from-file=example-files/redis/redis-config

$ oc create configmap example-redis-config \
    --from-file=example-files/redis/redis-config

Copy to Clipboard

Toggle word wrap

결과 확인:

oc get configmap example-redis-config -o yaml

$ oc get configmap example-redis-config -o yaml

apiVersion: v1
data:
  redis-config: |
    maxmemory 2mb
    maxmemory-policy allkeys-lru
kind: ConfigMap
metadata:
  creationTimestamp: 2016-04-06T05:53:07Z
  name: example-redis-config
  namespace: default
  resourceVersion: "2985"
  selflink: /api/v1/namespaces/default/configmaps/example-redis-config
  uid: d65739c1-fbbb-11e5-8a72-68f728db1985

Copy to Clipboard

Toggle word wrap

이제 이 ConfigMap 을 사용하는 Pod를 생성합니다.

다음과 같은 Pod 정의를 생성하여 파일에 저장합니다(예: redis-pod.yaml ).

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: kubernetes/redis:v1
    env:
    - name: MASTER
      value: "true"
    ports:
    - containerPort: 6379
    resources:
      limits:
        cpu: "0.1"
    volumeMounts:
    - mountPath: /redis-master-data
      name: data
    - mountPath: /redis-master
      name: config
  volumes:
    - name: data
      emptyDir: {}
    - name: config
      configMap:
        name: example-redis-config
        items:
        - key: redis-config
          path: redis.conf

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: kubernetes/redis:v1
    env:
    - name: MASTER
      value: "true"
    ports:
    - containerPort: 6379
    resources:
      limits:
        cpu: "0.1"
    volumeMounts:
    - mountPath: /redis-master-data
      name: data
    - mountPath: /redis-master
      name: config
  volumes:
    - name: data
      emptyDir: {}
    - name: config
      configMap:
        name: example-redis-config
        items:
        - key: redis-config
          path: redis.conf

Copy to Clipboard

Toggle word wrap

Pod를 생성합니다.
```
oc create -f redis-pod.yaml
```
```
$ oc create -f redis-pod.yaml
```
Copy to Clipboard Toggle word wrap

새로 생성된 Pod에는 example-redis-config ConfigMap 의 redis-config 키를 redis.conf 라는 파일에 배치하는 ConfigMap 볼륨이 있습니다. 이 볼륨은 Redis 컨테이너의 /redis-master 디렉터리에 마운트되어 구성 파일을 /redis-master/redis.conf 에 배치하며, 여기에서 이미지가 마스터의 Redis 구성 파일을 찾습니다.

이 Pod에 oc exec 를 입력하고 redis-cli 툴을 실행하는 경우 구성이 올바르게 적용되었는지 확인할 수 있습니다.

oc exec -it redis redis-cli

$ oc exec -it redis redis-cli
127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2097152"
127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"

Copy to Clipboard

Toggle word wrap

22.5. 제한 사항
링크 복사

ConfigMap 은 Pod에서 사용하기 전에 생성해야 합니다. 컨트롤러는 누락된 구성 데이터를 허용하도록 작성할 수 있습니다. 사례별로 ConfigMap 을 통해 구성된 개별 구성 요소를 참조하십시오.

ConfigMap 오브젝트는 프로젝트에 있습니다. 동일한 프로젝트의 Pod에서만 참조할 수 있습니다.

Kubelet은 API 서버에서 가져오는 Pod에 대한 ConfigMap 만 지원합니다. 여기에는 CLI를 사용하여 생성하거나 복제 컨트롤러에서 간접적으로 생성된 모든 Pod가 포함됩니다. OpenShift Container Platform 노드의 --manifest-url 플래그, --config 플래그 또는 해당 REST API를 사용하여 생성된 Pod는 포함하지 않습니다(포드를 생성하는 일반적인 방법은 아님).

23장. Downward API
링크 복사

23.1. 개요
링크 복사

Downward API는 컨테이너가 OpenShift Container Platform에 결합하지 않고 API 오브젝트에 대한 정보를 사용할 수 있도록 하는 메커니즘입니다. 이러한 정보에는 Pod 이름, 네임스페이스, 리소스 값이 포함됩니다. 컨테이너는 환경 변수 또는 볼륨 플러그인을 사용하여 Downward API의 정보를 사용할 수 있습니다.

23.2. 필드 선택
링크 복사

Pod 내의 필드는 FieldRef API 유형을 사용하여 선택합니다. FieldRef 에는 다음 두 개의 필드가 있습니다.

Expand

필드	설명
`fieldPath`	Pod와 관련하여 선택할 필드의 경로입니다.
`apiVersion`	`fieldPath` 선택기를 해석할 API 버전입니다.

현재 v1 API에서 유효한 선택기는 다음과 같습니다.

Expand

선택기	설명
`metadata.name`	Pod의 이름입니다. 이는 환경 변수와 볼륨 모두에서 지원됩니다.
`metadata.namespace`	Pod의 네임스페이스입니다. 환경 변수와 볼륨 모두에서 지원됩니다.
`metadata.labels`	Pod의 라벨입니다. 볼륨에서만 지원되며 환경 변수에서는 지원되지 않습니다.
`metadata.annotations`	Pod의 주석입니다. 볼륨에서만 지원되며 환경 변수에서는 지원되지 않습니다.
`status.podIP`	Pod의 IP입니다. 환경 변수에서만 지원되며 볼륨에서는 지원되지 않습니다.

apiVersion 필드가 지정되지 않은 경우 기본값은 포함된 Pod 템플릿의 API 버전입니다.

23.3. Downward API를 사용하여 컨테이너 값 사용
링크 복사

23.3.1. 환경 변수 사용
링크 복사

Downward API를 사용하는 한 가지 메커니즘은 컨테이너의 환경 변수를 사용하는 것입니다. EnvVar 유형의 value From 필드 (of type EnvVarSource)는 변수 값이 value 필드에서 지정된 리터럴 값 대신 FieldRef 소스에서 제공되도록 지정하는 데 사용됩니다. 향후 추가 소스가 지원될 수 있습니다. 현재 소스의 fieldRef 필드를 사용하여 Downward API에서 필드를 선택합니다.

프로세스에 변수 값이 변경되었음을 알리는 방식으로 프로세스를 시작한 후에는 환경 변수를 업데이트할 수 없으므로 Pod의 상수 특성만 이러한 방식으로 사용할 수 있습니다. 환경 변수를 사용하여 지원되는 필드는 다음과 같습니다.

Pod 이름

포드 네임스페이스

pod.yaml 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: MY_POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap
컨테이너의 로그에 MY_POD_NAME 및 MY_POD_NAMESPACE 값이 있는지 확인합니다.
```
oc logs -p dapi-env-test-pod
```
```
$ oc logs -p dapi-env-test-pod
```
Copy to Clipboard Toggle word wrap

23.3.2. 볼륨 플러그인 사용
링크 복사

Downward API를 사용하는 또 다른 메커니즘은 볼륨 플러그인을 사용하는 것입니다. Downward API 볼륨 플러그인은 파일에 예상된 구성된 필드가 있는 볼륨을 생성합니다. VolumeSource API 오브젝트의 metadata 필드는 이 볼륨을 구성하는 데 사용됩니다. 플러그인은 다음 필드를 지원합니다.

Pod 이름
포드 네임스페이스
Pod 주석
Pod 라벨

예 23.1. Downward API 볼륨 플러그인 구성

spec:
  volumes:
    - name: podinfo
      downwardAPI:: 
        items: 
          -name: "labels" 
           fieldRef:
              fieldPath: metadata.labels

spec:
  volumes:
    - name: podinfo
      downwardAPI::

1


        items:

2


          -name: "labels"

3


           fieldRef:
              fieldPath: metadata.labels

4

Copy to Clipboard

Toggle word wrap

1: 볼륨 소스의 metadata 필드는 Downward API 볼륨을 구성합니다.
2: items 필드에는 볼륨에 project할 필드 목록이 있습니다.
3: 필드를 배치할 파일의 이름입니다.
4: 프로젝트에 사용할 필드의 선택기입니다.

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

volume-pod.yaml 파일을 생성합니다.

kind: Pod
apiVersion: v1
metadata:
  labels:
    zone: us-east-coast
    cluster: downward-api-test-cluster1
    rack: rack-123
  name: dapi-volume-test-pod
  annotations:
    annotation1: "345"
    annotation2: "456"
spec:
  containers:
    - name: volume-test-container
      image: gcr.io/google_containers/busybox
      command: ["sh", "-c", "cat /tmp/etc/pod_labels /tmp/etc/pod_annotations"]
      volumeMounts:
        - name: podinfo
          mountPath: /tmp/etc
          readOnly: false
  volumes:
  - name: podinfo
    downwardAPI:
      defaultMode: 420
      items:
      - fieldRef:
          fieldPath: metadata.name
        path: pod_name
      - fieldRef:
          fieldPath: metadata.namespace
        path: pod_namespace
      - fieldRef:
          fieldPath: metadata.labels
        path: pod_labels
      - fieldRef:
          fieldPath: metadata.annotations
        path: pod_annotations
  restartPolicy: Never

kind: Pod
apiVersion: v1
metadata:
  labels:
    zone: us-east-coast
    cluster: downward-api-test-cluster1
    rack: rack-123
  name: dapi-volume-test-pod
  annotations:
    annotation1: "345"
    annotation2: "456"
spec:
  containers:
    - name: volume-test-container
      image: gcr.io/google_containers/busybox
      command: ["sh", "-c", "cat /tmp/etc/pod_labels /tmp/etc/pod_annotations"]
      volumeMounts:
        - name: podinfo
          mountPath: /tmp/etc
          readOnly: false
  volumes:
  - name: podinfo
    downwardAPI:
      defaultMode: 420
      items:
      - fieldRef:
          fieldPath: metadata.name
        path: pod_name
      - fieldRef:
          fieldPath: metadata.namespace
        path: pod_namespace
      - fieldRef:
          fieldPath: metadata.labels
        path: pod_labels
      - fieldRef:
          fieldPath: metadata.annotations
        path: pod_annotations
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

volume-pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f volume-pod.yaml
```
```
$ oc create -f volume-pod.yaml
```
Copy to Clipboard Toggle word wrap

컨테이너의 로그를 확인하고 구성된 필드가 있는지 확인합니다.

oc logs -p dapi-volume-test-pod

$ oc logs -p dapi-volume-test-pod
cluster=downward-api-test-cluster1
rack=rack-123
zone=us-east-coast
annotation1=345
annotation2=456
kubernetes.io/config.source=api

Copy to Clipboard

Toggle word wrap

23.4. Downward API를 사용하여 컨테이너 리소스 사용
링크 복사

Pod를 생성할 때 이미지 및 애플리케이션 작성자가 특정 환경에 대한 이미지를 올바르게 생성할 수 있도록 Downward API를 사용하여 컴퓨팅 리소스 요청 및 제한에 대한 정보를 삽입할 수 있습니다.

환경 변수 및 볼륨 플러그인 방법을 모두 사용하여 이 작업을 수행할 수 있습니다.

23.4.1. 환경 변수 사용
링크 복사

Pod 구성을 생성할 때 spec.container 필드의 resources 필드 콘텐츠에 해당하는 환경 변수를 지정합니다.

....
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox:1.24
      command: [ "/bin/sh", "-c", "env" ]
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              resource: limits.memory
....

....
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox:1.24
      command: [ "/bin/sh", "-c", "env" ]
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      env:
        - name: MY_CPU_REQUEST
          valueFrom:
            resourceFieldRef:
              resource: requests.cpu
        - name: MY_CPU_LIMIT
          valueFrom:
            resourceFieldRef:
              resource: limits.cpu
        - name: MY_MEM_REQUEST
          valueFrom:
            resourceFieldRef:
              resource: requests.memory
        - name: MY_MEM_LIMIT
          valueFrom:
            resourceFieldRef:
              resource: limits.memory
....

Copy to Clipboard

Toggle word wrap

리소스 제한이 컨테이너 구성에 포함되지 않은 경우 Downward API의 기본값은 노드의 CPU 및 메모리 할당 가능 값으로 설정됩니다.

pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap

23.4.2. 볼륨 플러그인 사용
링크 복사

Pod 구성을 생성할 때 spec.volumes.downwardAPI.items 필드를 사용하여 spec.resources 필드에 해당하는 원하는 리소스를 설명합니다.

....
spec:
  containers:
    - name: client-container
      image: gcr.io/google_containers/busybox:1.24
      command: ["sh", "-c", "while true; do echo; if [[ -e /etc/cpu_limit ]]; then cat /etc/cpu_limit; fi; if [[ -e /etc/cpu_request ]]; then cat /etc/cpu_request; fi; if [[ -e /etc/mem_limit ]]; then cat /etc/mem_limit; fi; if [[ -e /etc/mem_request ]]; then cat /etc/mem_request; fi; sleep 5; done"]
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      volumeMounts:
        - name: podinfo
          mountPath: /etc
          readOnly: false
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.cpu
          - path: "cpu_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.cpu
          - path: "mem_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.memory
          - path: "mem_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.memory
....

....
spec:
  containers:
    - name: client-container
      image: gcr.io/google_containers/busybox:1.24
      command: ["sh", "-c", "while true; do echo; if [[ -e /etc/cpu_limit ]]; then cat /etc/cpu_limit; fi; if [[ -e /etc/cpu_request ]]; then cat /etc/cpu_request; fi; if [[ -e /etc/mem_limit ]]; then cat /etc/mem_limit; fi; if [[ -e /etc/mem_request ]]; then cat /etc/mem_request; fi; sleep 5; done"]
      resources:
        requests:
          memory: "32Mi"
          cpu: "125m"
        limits:
          memory: "64Mi"
          cpu: "250m"
      volumeMounts:
        - name: podinfo
          mountPath: /etc
          readOnly: false
  volumes:
    - name: podinfo
      downwardAPI:
        items:
          - path: "cpu_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.cpu
          - path: "cpu_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.cpu
          - path: "mem_limit"
            resourceFieldRef:
              containerName: client-container
              resource: limits.memory
          - path: "mem_request"
            resourceFieldRef:
              containerName: client-container
              resource: requests.memory
....

Copy to Clipboard

Toggle word wrap

리소스 제한이 컨테이너 구성에 포함되지 않은 경우 Downward API의 기본값은 노드의 CPU 및 메모리 할당 가능 값으로 설정됩니다.

volume-pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f volume-pod.yaml
```
```
$ oc create -f volume-pod.yaml
```
Copy to Clipboard Toggle word wrap

23.5. Downward API를 사용하여 보안 사용
링크 복사

Pod를 생성할 때 이미지 및 애플리케이션 작성자가 특정 환경에 대한 이미지를 생성할 수 있도록 하향 API를 사용하여 보안을 삽입할 수 있습니다.

23.5.1. 환경 변수 사용
링크 복사

secret.yaml 파일을 생성합니다.

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  password: cGFzc3dvcmQ=
  username: ZGV2ZWxvcGVy
type: kubernetes.io/basic-auth

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
data:
  password: cGFzc3dvcmQ=
  username: ZGV2ZWxvcGVy
type: kubernetes.io/basic-auth

Copy to Clipboard

Toggle word wrap

secret.yaml 파일에서 보안을 생성합니다.
```
oc create -f secret.yaml
```
```
oc create -f secret.yaml
```
Copy to Clipboard Toggle word wrap

위의 Secret 에서 username 필드를 참조하는 pod.yaml 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: username
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: username
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap
컨테이너의 로그에 MY_SECRET_USERNAME 값이 있는지 확인합니다.
```
oc logs -p dapi-env-test-pod
```
```
$ oc logs -p dapi-env-test-pod
```
Copy to Clipboard Toggle word wrap

23.6. Downward API를 사용하여 ConfigMap 사용
링크 복사

Pod를 생성할 때 이미지 및 애플리케이션 작성자가 특정 환경에 대한 이미지를 생성할 수 있도록 Downward API를 사용하여 ConfigMap 값을 삽입할 수 있습니다.

23.6.1. 환경 변수 사용
링크 복사

configmap.yaml 파일을 생성합니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap
data:
  mykey: myvalue

apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap
data:
  mykey: myvalue

Copy to Clipboard

Toggle word wrap

configmap.yaml 파일에서 ConfigMap 을 생성합니다.
```
oc create -f configmap.yaml
```
```
oc create -f configmap.yaml
```
Copy to Clipboard Toggle word wrap

위의 ConfigMap 을 참조하는 pod.yaml 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_CONFIGMAP_VALUE
          valueFrom:
            configMapKeyRef:
              name: myconfigmap
              key: mykey
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_CONFIGMAP_VALUE
          valueFrom:
            configMapKeyRef:
              name: myconfigmap
              key: mykey
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap
컨테이너의 로그에 MY_CONFIGMAP_VALUE 값이 있는지 확인합니다.
```
oc logs -p dapi-env-test-pod
```
```
$ oc logs -p dapi-env-test-pod
```
Copy to Clipboard Toggle word wrap

23.7. 환경 변수 참조
링크 복사

Pod를 생성할 때 $() 구문을 사용하여 이전에 정의한 환경 변수의 값을 참조할 수 있습니다. 환경 변수 참조를 확인할 수 없는 경우에는 값이 제공된 문자열로 그대로 유지됩니다.

23.7.1. 환경 변수 참조 사용
링크 복사

기존 environment variable을 참조하는 pod.yaml 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_EXISTING_ENV
          value: my_value
        - name: MY_ENV_VAR_REF_ENV
          value: $(MY_EXISTING_ENV)
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_EXISTING_ENV
          value: my_value
        - name: MY_ENV_VAR_REF_ENV
          value: $(MY_EXISTING_ENV)
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap
컨테이너의 로그에 MY_ENV_VAR_REF_ENV 값이 있는지 확인합니다.
```
oc logs -p dapi-env-test-pod
```
```
$ oc logs -p dapi-env-test-pod
```
Copy to Clipboard Toggle word wrap

23.7.2. 환경 변수 참조 이스케이프
링크 복사

Pod를 생성할 때 이중 달러 기호를 사용하여 환경 변수 참조를 이스케이프할 수 있습니다. 그러면 해당 값이 제공된 값의 단일 달러 기호 버전으로 설정됩니다.

기존 environment variable을 참조하는 pod.yaml 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_NEW_ENV
          value: $$(SOME_OTHER_ENV)
  restartPolicy: Never

apiVersion: v1
kind: Pod
metadata:
  name: dapi-env-test-pod
spec:
  containers:
    - name: env-test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "-c", "env" ]
      env:
        - name: MY_NEW_ENV
          value: $$(SOME_OTHER_ENV)
  restartPolicy: Never

Copy to Clipboard

Toggle word wrap

pod.yaml 파일에서 Pod를 생성합니다.
```
oc create -f pod.yaml
```
```
$ oc create -f pod.yaml
```
Copy to Clipboard Toggle word wrap
컨테이너의 로그에 MY_NEW_ENV 값이 있는지 확인합니다.
```
oc logs -p dapi-env-test-pod
```
```
$ oc logs -p dapi-env-test-pod
```
Copy to Clipboard Toggle word wrap

24장. 예상 볼륨
링크 복사

24.1. 개요
링크 복사

예상 볼륨 은 여러 기존 볼륨 소스를 동일한 디렉터리에 매핑합니다.

현재 다음 유형의 볼륨 소스를 예측할 수 있습니다.

보안
Config Map
Downward API

참고

모든 소스는 Pod와 동일한 네임스페이스에 있어야 합니다.

예상 볼륨은 해당 볼륨 소스의 조합을 단일 디렉터리에 매핑할 수 있어 사용자는 다음을 수행할 수 있습니다.

단일 디렉터리를 다양한 정보 소스와 합성할 수 있도록 여러 보안의 키, configmaps 및 Downward API 정보를 사용하여 단일 볼륨을 자동으로 채웁니다.
여러 보안의 키, configmaps 및 Downward API 정보를 사용하여 단일 볼륨을 채우고 각 항목에 대한 경로를 명시적으로 지정하여 해당 볼륨의 콘텐츠를 완전히 제어할 수 있습니다.

24.2. 시나리오 예
링크 복사

다음 일반 시나리오에서는 예상 볼륨을 사용하는 방법을 보여줍니다.

ConfigMap, 보안, Downward API. 예상 볼륨을 사용하여 암호가 포함된 구성 데이터가 있는 컨테이너를 배포할 수 있습니다. 이러한 리소스를 사용하는 애플리케이션은 Kubernetes에 OpenStack을 배포할 수 있습니다. 구성 데이터는 서비스가 프로덕션 또는 테스트에 사용될 것인지에 따라 다르게 수집되어야 할 수도 있습니다. Pod에 프로덕션 또는 테스트로 레이블이 지정되면 Downward API 선택기 metadata.labels 를 사용하여 올바른 OpenStack 구성을 생성할 수 있습니다.
ConfigMap + 시크릿. 예상 볼륨을 사용하면 구성 데이터 및 암호와 관련된 컨테이너를 배포할 수 있습니다. 예를 들어 vault 암호 파일을 사용하여 암호 해독되는 몇 가지 민감한 암호화된 작업으로 구성 맵으로 저장된 Ansible 플레이북을 실행할 수 있습니다.
구성 맵 + Downward API 예상 볼륨을 사용하면 Pod 이름(metadata.name 선택기를 통해 제공)을 포함하여 구성을 생성할 수 있습니다. 그러면 이 애플리케이션에서 IP 추적을 사용하지 않고 소스를 쉽게 확인할 수 있도록 요청과 함께 Pod 이름을 전달할 수 있습니다.
보안 + Downward API 예상 볼륨을 사용하면 보안을 공개키로 사용하여 Pod의 네임스페이스(metadata.namespace 선택기를 통해 제공)를 암호화할 수 있습니다. 이 예제에서는 운영자가 애플리케이션을 사용하여 암호화된 전송을 사용하지 않고도 네임스페이스 정보를 안전하게 전달할 수 있습니다.

24.3. Pod 사양의 예
링크 복사

다음은 예상되는 볼륨을 생성하는 Pod 사양의 예입니다.

예 24.1. 시크릿, Downward API 및 configmap이 있는 Pod

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts: 
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true 
  volumes: 
  - name: all-in-one 
    projected:
      defaultMode: 0400 
      sources:
      - secret:
          name: mysecret 
          items:
            - key: username
              path: my-group/my-username 
      - downwardAPI: 
          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap: 
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config
              mode: 0777

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:

1


    - name: all-in-one
      mountPath: "/projected-volume"

2


      readOnly: true

3


  volumes:

4


  - name: all-in-one

5


    projected:
      defaultMode: 0400

6


      sources:
      - secret:
          name: mysecret

7


          items:
            - key: username
              path: my-group/my-username

8


      - downwardAPI:

9


          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:

10


          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config
              mode: 0777

11

Copy to Clipboard

Toggle word wrap

1: 보안이 필요한 각 컨테이너에 volumeMounts 섹션을 추가합니다.
2: 보안이 표시될 미사용 디렉터리의 경로를 지정합니다.
3: readOnly를 true로 설정합니다.
4: volumes 블록을 추가하여 각 예상 볼륨 소스를 나열합니다.
5: 볼륨에 이름을 지정합니다.
6: 파일에 대한 실행 권한을 설정합니다.
7: 보안을 추가합니다. 보안 오브젝트의 이름을 입력합니다. 사용하려는 모든 시크릿을 나열해야 합니다.
8: mountPath 아래에 보안 파일의 경로를 지정합니다. 여기에서 보안 파일은 /projected-volume/my-group/my-config 에 있습니다.
9: Downward API 소스를 추가합니다.
10: 구성 맵 소스를 추가합니다.
11: 특정 예상에 대한 모드 설정

참고

Pod에 컨테이너가 여러 개 있는 경우 각 컨테이너에 volumeMounts 섹션이 있어야 하지만 volumes 섹션은 하나만 있으면 됩니다.

예 24.2. 기본이 아닌 권한 모드가 설정된 보안이 여러 개인 Pod

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      defaultMode: 0755
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      defaultMode: 0755
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

Copy to Clipboard

Toggle word wrap

참고

defaultMode는 각 볼륨 소스가 아닌 예상 수준에서만 지정할 수 없습니다. 하지만 위에서 설명한 대로 개별 예상마다 mode를 명시적으로 설정할 수 있습니다.

24.4. 경로 지정 고려 사항
링크 복사

예상 볼륨을 생성할 때 볼륨 파일 경로와 관련된 다음 상황을 고려하십시오.

구성된 경로가 동일할 때 키 간 충돌

동일한 경로를 사용하여 여러 개의 키를 구성하면 Pod 사양이 유효한 것으로 승인되지 않습니다. 다음 예제에서 mysecret 및 myconfigmap에 지정된 경로는 동일합니다.

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/data
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/data

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/data
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/data

Copy to Clipboard

Toggle word wrap

구성된 경로가 없는 키 간 충돌

발생할 수 있는 유일한 런타임 검증은 Pod 생성 시 모든 경로가 알려진 경우이며 위의 시나리오와 유사합니다. 이 경우에 해당하지 않으면 충돌이 발생할 때 최근 지정된 리소스가 이전의 모든 리소스를 덮어씁니다(Pod 생성 후 업데이트된 리소스 포함).

하나의 경로는 명시적이고 다른 경로는 자동으로 예상될 때의 충돌

사용자가 지정한 경로가 자동 예상 데이터와 일치하여 충돌이 발생하는 경우 위에서와 마찬가지로 자동 예상 데이터가 이전의 모든 리소스를 덮어씁니다.

24.5. Pod의 예상 볼륨 구성
링크 복사

다음 예제에서는 예상 볼륨을 사용하여 기존 Secret 볼륨 소스를 마운트하는 방법을 보여줍니다.

단계를 사용하여 로컬 파일에서 사용자 이름과 암호 Secrets 를 생성할 수 있습니다. 그런 다음 예상 볼륨을 사용하여 하나의 컨테이너를 실행하는 Pod를 생성하여 동일한 공유 디렉터리에 보안을 마운트합니다.

보안이 포함된 파일을 생성합니다.
예를 들어 다음과 같습니다.
```
nano secret.yaml
```
```
$ nano secret.yaml
```
Copy to Clipboard Toggle word wrap
다음을 입력하여 암호 및 사용자 정보를 적절하게 바꿉니다.
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  pass: MWYyZDFlMmU2N2Rm
  user: YWRtaW4=
```
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  pass: MWYyZDFlMmU2N2Rm
  user: YWRtaW4=
```
Copy to Clipboard Toggle word wrap
user 및 pass 값은 base64로 인코딩된 유효한 문자열일 수 있습니다. 여기에 사용되는 예제는 base64로 인코딩된 값 user: admin,pass:1f2d1e2e67df 입니다.
```
echo -n "admin" | base64
echo -n "1f2d1e2e67df" | base64
```
```
$ echo -n "admin" | base64
YWRtaW4=
$ echo -n "1f2d1e2e67df" | base64
MWYyZDFlMmU2N2Rm
```
Copy to Clipboard Toggle word wrap
다음 명령을 사용하여 보안을 생성합니다.
```
oc create -f <secrets-filename>
```
```
$ oc create -f <secrets-filename>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc create -f secret.yaml
```
```
$ oc create -f secret.yaml
secret "mysecret" created
```
Copy to Clipboard Toggle word wrap

다음 명령을 사용하여 보안이 생성되었는지 확인할 수 있습니다.

oc get secret <secret-name>
oc get secret <secret-name> -o yaml

$ oc get secret <secret-name>
$ oc get secret <secret-name> -o yaml

Copy to Clipboard

Toggle word wrap

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

oc get secret mysecret

$ oc get secret mysecret
NAME       TYPE      DATA      AGE
mysecret   Opaque    2         17h

Copy to Clipboard

Toggle word wrap

oc get secret mysecret -o yaml
apiVersion: v1
data:
  pass: MWYyZDFlMmU2N2Rm
  user: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: 2017-05-30T20:21:38Z
  name: mysecret
  namespace: default
  resourceVersion: "2107"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: 959e0424-4575-11e7-9f97-fa163e4bd54c
type: Opaque

oc get secret mysecret -o yaml
apiVersion: v1
data:
  pass: MWYyZDFlMmU2N2Rm
  user: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: 2017-05-30T20:21:38Z
  name: mysecret
  namespace: default
  resourceVersion: "2107"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: 959e0424-4575-11e7-9f97-fa163e4bd54c
type: Opaque

Copy to Clipboard

Toggle word wrap

volumes 섹션이 포함된 다음과 유사한 Pod 구성 파일을 생성합니다.

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume
spec:
  containers:
  - name: test-projected-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

Copy to Clipboard

Toggle word wrap

구성 파일에서 Pod를 생성합니다.
```
oc create -f <your_yaml_file>.yaml
```
```
$ oc create -f <your_yaml_file>.yaml
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc create -f secret-pod.yaml
```
```
$ oc create -f secret-pod.yaml
pod "test-projected-volume" created
```
Copy to Clipboard Toggle word wrap
Pod 컨테이너가 실행 중인지 확인한 다음 Pod 변경 사항을 확인합니다.
```
oc get pod <name>
```
```
$ oc get pod <name>
```
Copy to Clipboard Toggle word wrap
출력은 다음과 유사합니다.
```
oc get pod test-projected-volume
```
```
$ oc get pod test-projected-volume
NAME                    READY     STATUS    RESTARTS   AGE
test-projected-volume   1/1       Running   0          14s
```
Copy to Clipboard Toggle word wrap
다른 터미널에서 oc exec 명령을 사용하여 실행 중인 컨테이너에 쉘을 엽니다.
```
oc exec -it <pod> <command>
```
```
$ oc exec -it <pod> <command>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc exec -it test-projected-volume -- /bin/sh
```
```
$ oc exec -it test-projected-volume -- /bin/sh
```
Copy to Clipboard Toggle word wrap

쉘에서 projected-volumes 디렉터리에 예상 소스가 포함되어 있는지 확인합니다.

/ # ls
bin               home              root              tmp
dev               proc              run               usr
etc               projected-volume  sys               var

/ # ls
bin               home              root              tmp
dev               proc              run               usr
etc               projected-volume  sys               var

Copy to Clipboard

Toggle word wrap

25장. Daemonsets 사용
링크 복사

25.1. 개요
링크 복사

daemonset은 OpenShift Container Platform 클러스터의 특정 노드 또는 모든 노드에서 Pod의 복제본을 실행하는 데 사용할 수 있습니다.

데몬 세트를 사용하여 공유 스토리지를 생성하거나 클러스터의 모든 노드에서 로깅 Pod를 실행하거나 모든 노드에 모니터링 에이전트를 배포합니다.

보안상의 이유로 클러스터 관리자만 데몬 세트를 생성할 수 있습니다. (사용자 데몬 세트 권한 부여.)

데몬 세트에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.

중요

DaemonSet 예약은 프로젝트의 기본 노드 선택기와 호환되지 않습니다. 비활성화하지 않으면 기본 노드 선택기와 병합하여 daemonset이 제한됩니다. 이로 인해 병합된 노드 선택기에서 선택하지 않은 노드에 Pod가 자주 다시 생성되고 이로 인해 클러스터에 불필요한 부하가 발생합니다.

따라서,

데몬 세트 사용을 시작하기 전에 네임스페이스 주석 openshift.io/ node-selector 를 빈 문자열로 설정하여 네임스페이스에서 기본 프로젝트 수준 노드 선택기를 비활성화합니다.

oc patch namespace myproject -p \
    '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'

# oc patch namespace myproject -p \
    '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'

Copy to Clipboard

Toggle word wrap

새 프로젝트를 생성하는 경우 oc adm new-project --node-selector="" 를 사용하여 기본 노드 선택기를 덮어씁니다.

25.2. 데몬 세트 생성
링크 복사

데몬 세트를 생성할 때 nodeSelector 필드를 사용하여 데몬 세트에서 복제본을 배포해야 하는 노드를 나타냅니다.

daemonset yaml 파일을 정의합니다.

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: hello-daemonset
spec:
  selector:
      matchLabels:
        name: hello-daemonset 
  template:
    metadata:
      labels:
        name: hello-daemonset 
    spec:
      nodeSelector: 
        type: infra
      containers:
      - image: openshift/hello-openshift
        imagePullPolicy: Always
        name: registry
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
      serviceAccount: default
      terminationGracePeriodSeconds: 10

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: hello-daemonset
spec:
  selector:
      matchLabels:
        name: hello-daemonset

1


  template:
    metadata:
      labels:
        name: hello-daemonset

2


    spec:
      nodeSelector:

3


        type: infra
      containers:
      - image: openshift/hello-openshift
        imagePullPolicy: Always
        name: registry
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
      serviceAccount: default
      terminationGracePeriodSeconds: 10

Copy to Clipboard

Toggle word wrap

1: daemonset에 속하는 Pod를 결정하는 라벨 선택기입니다.
2: Pod 템플릿의 라벨 선택기입니다. 위의 라벨 선택기와 일치해야 합니다.
3: 배포해야 하는 노드 Pod 복제본을 결정하는 노드 선택기입니다.

daemonset 오브젝트를 생성합니다.
```
oc create -f daemonset.yaml
```
```
oc create -f daemonset.yaml
```
Copy to Clipboard Toggle word wrap

Pod가 생성되었고 각 노드에 Pod 복제본이 있는지 확인하려면 다음을 수행합니다.

daemonset Pod를 찾습니다.

oc get pods

$ oc get pods
hello-daemonset-cx6md   1/1       Running   0          2m
hello-daemonset-e3md9   1/1       Running   0          2m

Copy to Clipboard

Toggle word wrap

Pod를 보고 Pod가 노드에 배치되었는지 확인합니다.

oc describe pod/hello-daemonset-cx6md|grep Node
oc describe pod/hello-daemonset-e3md9|grep Node

$ oc describe pod/hello-daemonset-cx6md|grep Node
Node:        openshift-node01.hostname.com/10.14.20.134
$ oc describe pod/hello-daemonset-e3md9|grep Node
Node:        openshift-node02.hostname.com/10.14.20.137

Copy to Clipboard

Toggle word wrap

중요

DaemonSet의 Pod 템플릿을 업데이트하면 기존 Pod 복제본에 영향을 미치지 않습니다.
DaemonSet을 삭제한 다음 다른 템플릿과 동일한 라벨 선택기를 사용하여 새 DaemonSet을 생성하면 기존 Pod 복제본을 일치하는 라벨이 있는 것으로 인식하므로 Pod 템플릿에 일치하지 않는 경우에도 복제본을 업데이트하거나 새 복제본을 생성하지 않습니다.
노드 라벨을 변경하면 DaemonSet은 새 라벨과 일치하는 노드에 Pod를 추가하고 새 라벨과 일치하지 않는 노드에서 Pod를 삭제합니다.

DaemonSet을 업데이트하려면 이전 복제본 또는 노드를 삭제하여 새 Pod 복제본을 강제로 생성합니다.

26장. Pod 자동 확장
링크 복사

26.1. 개요
링크 복사

HorizontalPodAutoscaler 오브젝트에서 정의하는 수평 Pod 자동 스케일러는 해당 복제 컨트롤러 또는 배포 구성에 속하는 Pod에서 수집한 메트릭을 기반으로 시스템이 복제 컨트롤러 또는 배포 구성의 스케일링을 자동으로 늘리거나 줄이는 방법을 지정합니다.

26.2. Horizontal Pod Autoscaler 사용 요구사항
링크 복사

수평 Pod 자동 스케일러를 사용하려면 클러스터 관리자가 클러스터 메트릭을 올바르게 구성해야 합니다.

26.3. 지원되는 지표
링크 복사

수평 Pod 자동 스케일러에서는 다음 메트릭을 지원합니다.

Expand

표 26.1. 메트릭
메트릭	설명	API 버전
CPU 사용	요청된 CPU의 백분율	`autoscaling/v1`, `autoscaling/v2beta1`
메모리 사용률	요청된 메모리의 백분율입니다.	`autoscaling/v2beta1`

26.4. 자동 확장
링크 복사

oc autoscale 명령을 사용하여 수평 Pod 자동 스케일러를 생성하고 실행하려는 최소 및 최대 Pod 수와 Pod에서 대상으로 하는 CPU 사용률 또는 메모리 사용률 을 지정할 수 있습니다.

중요

메모리 사용률의 자동 스케일링은 기술 프리뷰 기능 전용입니다.

수평 포드 자동 스케일러가 생성되면 포드의 지표에 대해verify를 쿼리하려고 시도합니다. VRF가 초기 메트릭을 얻는 데 1 ~ 2 분이 걸릴 수 있습니다.

HPA에서 메트릭을 사용할 수 있는 후 수평 Pod 자동 스케일러는 현재 메트릭 사용률과 원하는 메트릭 사용률의 비율을 계산하고 그에 따라 확장 또는 축소합니다. 스케일링은 주기적인 간격으로 발생하지만 메트릭이 제공 될 때까지 1 ~ 2 분이 걸릴 수 있습니다.

복제 컨트롤러의 경우 이러한 스케일링은 복제 컨트롤러의 복제본과 직접적으로 일치합니다. 배포 구성의 경우 스케일링은 배포 구성의 복제본 수와 직접적으로 일치합니다. 자동 스케일링은 Complete 단계에서 최신 배포에만 적용됩니다.

OpenShift Container Platform은 리소스를 자동으로 차지하여 시작하는 동안과 같이 리소스가 급증하는 동안 불필요한 자동 스케일링을 방지합니다. unready 상태의 Pod는 확장 시 CPU 사용량이 0이고, 축소 시에는 자동 스케일러에서 Pod를 무시합니다. 알려진 메트릭이 없는 Pod는 확장 시 CPU 사용량이 0%이고, 축소 시에는 100%입니다. 이를 통해 HPA를 결정하는 동안 안정성이 향상됩니다. 이 기능을 사용하려면 준비 상태 점검 을 구성하여 새 Pod를 사용할 준비가 되었는지 확인해야 합니다.

26.5. CPU 사용률의 자동 스케일링
링크 복사

oc autoscale 명령을 사용하여 언제든지 실행할 최대 Pod 수를 지정합니다. 선택 옵션으로 최소 Pod 수와 Pod에서 목표로 하는 평균 CPU 사용률을 지정할 수 있습니다. 그러지 않으면 OpenShift Container Platform 서버에서 기본값이 지정됩니다.

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

oc autoscale dc/frontend --min 1 --max 10 --cpu-percent=80

$ oc autoscale dc/frontend --min 1 --max 10 --cpu-percent=80
deploymentconfig "frontend" autoscaled

Copy to Clipboard

Toggle word wrap

위 예제에서는 수평 Pod 자동 스케일러의 autoscaling/v1 버전을 사용할 때 다음과 같은 정의로 수평 Pod 자동 스케일러를 생성합니다.

예 26.1. 수평 Pod 자동 스케일러 오브젝트 정의

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend 
spec:
  scaleTargetRef:
    kind: DeploymentConfig 
    name: frontend 
    apiVersion: apps/v1 
    subresource: scale
  minReplicas: 1 
  maxReplicas: 10 
  targetCPUUtilizationPercentage: 80

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend

1


spec:
  scaleTargetRef:
    kind: DeploymentConfig

2


    name: frontend

3


    apiVersion: apps/v1

4


    subresource: scale
  minReplicas: 1

5


  maxReplicas: 10

6


  targetCPUUtilizationPercentage: 80

7

Copy to Clipboard

Toggle word wrap

1: 이 수평 Pod 자동 스케일러 오브젝트의 이름입니다.
2: 스케일링할 오브젝트의 종류
3: 스케일링할 오브젝트의 이름입니다.
4: 스케일링할 오브젝트의 API 버전입니다.
5: 축소할 최소 복제본 수
6: 확장할 최대 복제본 수
7: 각 Pod가 사용해야 하는 요청된 CPU의 백분율

또는 oc autoscale 명령은 수평 Pod 자동 스케일러의 v2beta1 버전을 사용할 때 다음 정의로 수평 Pod 자동 스케일러를 생성합니다.

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-cpu 
spec:
  scaleTargetRef:
    apiVersion: apps/v1 
    kind: ReplicationController 
    name: hello-hpa-cpu 
  minReplicas: 1 
  maxReplicas: 10 
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 50

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-cpu

1


spec:
  scaleTargetRef:
    apiVersion: apps/v1

2


    kind: ReplicationController

3


    name: hello-hpa-cpu

4


  minReplicas: 1

5


  maxReplicas: 10

6


  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 50

7

Copy to Clipboard

Toggle word wrap

1: 이 수평 Pod 자동 스케일러 오브젝트의 이름입니다.
2: 스케일링할 오브젝트의 API 버전입니다.
3: 스케일링할 오브젝트의 종류
4: 스케일링할 오브젝트의 이름입니다.
5: 축소할 최소 복제본 수
6: 확장할 최대 복제본 수
7: 각 Pod가 사용해야 하는 요청된 CPU의 평균 백분율입니다.

26.6. 메모리 사용률의 자동 스케일링
링크 복사

중요

메모리 사용률의 자동 스케일링은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

CPU 기반 자동 스케일링과 달리 메모리 기반 자동 스케일링에는 oc autoscale 명령을 사용하는 대신 YAML을 사용하여 자동 스케일러를 지정해야 합니다. 필요한 경우 최소 Pod 수와 Pod에서 대상으로 하는 평균 메모리 사용률을 지정할 수 있습니다. 그러지 않으면 OpenShift Container Platform 서버의 기본값이 제공됩니다.

메모리 기반 자동 스케일링은 v2beta1 버전의 autoscaling API에서만 사용할 수 있습니다. 클러스터의 master-config.yaml 파일에 다음을 추가하여 메모리 기반 자동 스케일링을 활성화합니다.
```
...
apiServerArguments:
  runtime-config:
  - apis/autoscaling/v2beta1=true
...
```
```
...
apiServerArguments:
  runtime-config:
  - apis/autoscaling/v2beta1=true
...
```
Copy to Clipboard Toggle word wrap

hpa.yaml 과 같은 파일에 다음을 배치합니다.

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory 
spec:
  scaleTargetRef:
    apiVersion: apps/v1 
    kind: ReplicationController 
    name: hello-hpa-memory 
  minReplicas: 1 
  maxReplicas: 10 
  metrics:
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 50

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-resource-metrics-memory

1


spec:
  scaleTargetRef:
    apiVersion: apps/v1

2


    kind: ReplicationController

3


    name: hello-hpa-memory

4


  minReplicas: 1

5


  maxReplicas: 10

6


  metrics:
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 50

7

Copy to Clipboard

Toggle word wrap

1: 이 수평 Pod 자동 스케일러 오브젝트의 이름입니다.
2: 스케일링할 오브젝트의 API 버전입니다.
3: 스케일링할 오브젝트의 종류
4: 스케일링할 오브젝트의 이름입니다.
5: 축소할 최소 복제본 수
6: 확장할 최대 복제본 수
7: 각 Pod가 사용해야 하는 요청된 메모리의 평균 백분율입니다.

그런 다음 위 파일에서 자동 스케일러를 생성합니다.
```
oc create -f hpa.yaml
```
```
$ oc create -f hpa.yaml
```
Copy to Clipboard Toggle word wrap

중요

메모리 기반 자동 스케일링이 작동하려면 메모리 사용량이 복제본 수에 비례하여 증가 및 감소해야 합니다. 평균적으로 다음과 같습니다.

복제본 수가 증가하면 Pod당 메모리(작업 집합) 사용량이 전반적으로 감소해야 합니다.
복제본 수가 감소하면 Pod별 메모리 사용량이 전반적으로 증가해야 합니다.

메모리 기반 자동 스케일링을 사용하기 전에 OpenShift 웹 콘솔을 사용하여 애플리케이션의 메모리 동작을 확인하고 애플리케이션이 이러한 요구 사항을 충족하는지 확인합니다.

26.7. Horizontal Pod Autoscaler 보기
링크 복사

수평 Pod 자동 스케일러의 상태를 보려면 다음을 수행합니다.

oc get 명령을 사용하여 CPU 사용률 및 Pod 제한에 대한 정보를 확인합니다.
```
oc get hpa/hpa-resource-metrics-cpu
```
```
$ oc get hpa/hpa-resource-metrics-cpu
NAME                         REFERENCE                                 TARGET    CURRENT  MINPODS        MAXPODS    AGE
hpa-resource-metrics-cpu     DeploymentConfig/default/frontend/scale   80%       79%      1              10         8d
```
Copy to Clipboard Toggle word wrap
출력에는 다음이 포함됩니다.
- 대상. 배포 구성으로 제어되는 모든 Pod의 대상 평균 CPU 사용률입니다.
- 현재. 배포 구성에서 제어하는 모든 Pod의 현재 CPU 사용률입니다.
- Minpods/Maxpods. 자동 스케일러에서 설정할 수 있는 최소 및 최대 복제본 수입니다.

수평 Pod 자동 스케일러 오브젝트에 대한 자세한 정보는 oc describe 명령을 사용합니다.

oc describe hpa/hpa-resource-metrics-cpu

$ oc describe hpa/hpa-resource-metrics-cpu
Name:                           hpa-resource-metrics-cpu
Namespace:                      default
Labels:                         <none>
CreationTimestamp:              Mon, 26 Oct 2015 21:13:47 -0400
Reference:                      DeploymentConfig/default/frontend/scale
Target CPU utilization:         80%

1


Current CPU utilization:        79%

2


Min replicas:                   1

3


Max replicas:                   4

4


ReplicationController pods:     1 current / 1 desired
Conditions:

5


  Type                  Status  Reason                  Message
  ----                  ------  ------                  -------
  AbleToScale           True    ReadyForNewScale        the last scale time was sufficiently old as to warrant a new scale
  ScalingActive         True    ValidMetricFound        the HPA was able to successfully calculate a replica count from pods metric http_requests
  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptable range
Events:

Copy to Clipboard

Toggle word wrap

1: 각 Pod에서 사용해야 하는 요청된 메모리의 평균 백분율입니다.
2: 배포 구성에서 제어하는 모든 Pod의 현재 CPU 사용률입니다.
3: 축소할 최소 복제본 수입니다.
4: 확장할 최대 복제본 수입니다.
5: v2alpha1 API를 사용한 오브젝트가 있으면 상태 조건이 표시됩니다.

26.7.1. Horizontal Pod Autoscaler 상태 조건 보기
링크 복사

설정된 상태 조건을 사용하여 수평 Pod 자동 스케일러가 스케일링할 수 있는지 여부와 현재 제한되어 있는지 여부를 확인할 수 있습니다.

수평 Pod 자동 스케일러 상태 조건은 v2beta1 버전의 autoscaling API에서 사용할 수 있습니다.

kubernetesMasterConfig:
  ...
  apiServerArguments:
    runtime-config:
    - apis/autoscaling/v2beta1=true

kubernetesMasterConfig:
  ...
  apiServerArguments:
    runtime-config:
    - apis/autoscaling/v2beta1=true

Copy to Clipboard

Toggle word wrap

다음 상태 조건이 설정됩니다.

AbleToScale 은 수평 Pod 자동 스케일러가 스케일링을 가져오고 업데이트할 수 있는지 여부와 백오프 조건이 스케일링을 방지하는지 여부를 나타냅니다.
- True 조건은 스케일링이 허용되었음을 나타냅니다.
- False 조건은 지정된 이유로 스케일링이 허용되지 않음을 나타냅니다.
ScalingActive 는 수평 Pod 자동 스케일러가 활성화되어 있는지(대상의 복제본 수가 0이 아님) 원하는 스케일링을 계산할 수 있는지 여부를 나타냅니다.
- True 조건은 메트릭이 제대로 작동함을 나타냅니다.
- False 조건은 일반적으로 메트릭을 가져오는 데 문제가 있음을 나타냅니다.
ScalingLimited 는 최대 복제본 수 또는 최소 복제본 수에 도달했기 때문에 자동 스케일링이 허용되지 않음을 나타냅니다.
- True 조건은 스케일링을 위해 최소 또는 최대 복제본 수를 늘리거나 줄여야 함을 나타냅니다.
- False 조건은 요청된 스케일링이 허용됨을 나타냅니다.

이 행을 추가하거나 편집하려면 OpenShift Container Platform 서비스를 다시 시작하십시오.

systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

# systemctl restart atomic-openshift-master-api atomic-openshift-master-controllers

Copy to Clipboard

Toggle word wrap

수평 Pod 자동 스케일러에 영향을 미치는 조건을 보려면 oc describe hpa 를 사용합니다. conditions는 status.conditions 필드에 나타납니다.

oc describe hpa cm-test

$ oc describe hpa cm-test
Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:

1


  Type                  Status  Reason                  Message
  ----                  ------  ------                  -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Events:

Copy to Clipboard

Toggle word wrap

1

수평 Pod 자동 스케일러의 상태 메시지입니다.

AbleToScale 조건은 HPA가 스케일링을 가져오고 업데이트할 수 있는지와 백오프 관련 조건으로 스케일링을 방지할 수 있는지 여부를 나타냅니다.
ScalingActive 조건은 HPA가 활성화되어 있는지(예: 대상의 복제본 수가 0이 아님) 원하는 스케일링을 계산할 수 있는지 여부를 나타냅니다. 'False' 상태는 일반적으로 메트릭을 가져오는 데 문제가 있음을 나타냅니다.
ScalingLimited 조건은 원하는 스케일링이 수평 Pod 자동 스케일러의 최댓값 또는 최솟값으로 제한되었음을 나타냅니다. True 상태는 일반적으로 수평 Pod 자동 스케일러에서 최소 또는 최대 복제본 수 제약 조건을 늘리거나 줄여야 함을 나타냅니다.

다음은 스케일링할 수 없는 Pod의 예입니다.

Conditions:
  Type           Status    Reason            Message
  ----           ------    ------            -------
  AbleToScale    False     FailedGetScale    the HPA controller was unable to get the target's current scale: replicationcontrollers/scale.extensions "hello-hpa-cpu" not found

Conditions:
  Type           Status    Reason            Message
  ----           ------    ------            -------
  AbleToScale    False     FailedGetScale    the HPA controller was unable to get the target's current scale: replicationcontrollers/scale.extensions "hello-hpa-cpu" not found

Copy to Clipboard

Toggle word wrap

다음은 스케일링에 필요한 메트릭을 가져올 수 없는 Pod의 예입니다.

Conditions:
  Type                  Status    Reason                    Message
  ----                  ------    ------                    -------
  AbleToScale           True     SucceededGetScale          the HPA controller was able to get the target's current scale
  ScalingActive         False    FailedGetResourceMetric    the HPA was unable to compute the replica count: unable to get metrics for resource cpu: no metrics returned from heapster

Conditions:
  Type                  Status    Reason                    Message
  ----                  ------    ------                    -------
  AbleToScale           True     SucceededGetScale          the HPA controller was able to get the target's current scale
  ScalingActive         False    FailedGetResourceMetric    the HPA was unable to compute the replica count: unable to get metrics for resource cpu: no metrics returned from heapster

Copy to Clipboard

Toggle word wrap

다음은 요청된 자동 스케일링이 필요한 최솟값보다 적은 Pod의 예입니다.

Conditions:
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Events:

Conditions:
  Type              Status    Reason              Message
  ----              ------    ------              -------
  AbleToScale       True      ReadyForNewScale    the last scale time was sufficiently old as to warrant a new scale
  ScalingActive     True      ValidMetricFound    the HPA was able to successfully calculate a replica count from pods metric http_request
  ScalingLimited    False     DesiredWithinRange  the desired replica count is within the acceptable range
Events:

Copy to Clipboard

Toggle word wrap

27장. 볼륨 관리
링크 복사

27.1. 개요
링크 복사

컨테이너는 기본적으로 영구적이 아니며 재시작 시 저장된 콘텐츠가 지워집니다. 볼륨은 Pod 및 해당 컨테이너에서 사용할 수 있는 마운트된 파일 시스템으로, 다수의 호스트-로컬 또는 네트워크 연결 스토리지 끝점에서 지원할 수 있습니다.

볼륨의 파일 시스템에 오류가 없는지 확인한 후 오류가 있고 가능한 경우 오류를 복구하기 위해 OpenShift Container Platform에서는 mount 유틸리티 이전에 fsck 유틸리티를 호출합니다. 이러한 작업은 볼륨을 추가하거나 기존 볼륨을 업데이트할 때 수행됩니다.

가장 간단한 볼륨 유형은 단일 머신의 임시 디렉터리인 emptyDir입니다. 관리자는 Pod에 자동으로 연결된 영구 볼륨을 요청할 수도 있습니다.

참고

클러스터 관리자가 FSGroup 매개변수를 활성화하면 Pod의 FSGroup을 기반으로 한 할당량에 따라 emptyDir 볼륨 스토리지가 제한될 수 있습니다.

CLI 명령 oc volume 을 사용하여 복제 컨트롤러 또는 배포 구성과 같은 Pod 템플릿이 있는 모든 오브젝트에 대한 볼륨 및 볼륨 마운트를 추가,업데이트 또는 제거할 수 있습니다. Pod의 볼륨 또는 Pod 템플릿이 있는 오브젝트도 나열 할 수 있습니다.

27.2. 일반 CLI 사용
링크 복사

oc volume 명령에서는 다음과 같은 일반 구문을 사용합니다.

oc volume <object_selection> <operation> <mandatory_parameters> <optional_parameters>

$ oc volume <object_selection> <operation> <mandatory_parameters> <optional_parameters>

Copy to Clipboard

Toggle word wrap

이 주제에서는 후속 예제에서 < object_type> / <name > 양식을 < object_selection > 형식으로 사용합니다. 다음 옵션 중 하나를 선택할 수 있습니다.

Expand

표 27.1. 오브젝트 선택
구문	설명	예
`<object_type> <name>`	유형 `<object_type>`의 `<name>`을 선택합니다.	`deploymentConfig registry`
`<object_type>/<name>`	유형 `<object_type>`의 `<name>`을 선택합니다.	`deploymentConfig/registry`
`<object_type>` `--selector=<object_label_selector>`	지정된 라벨 선택기와 일치하는 유형 `<object_type>`의 리소스를 선택합니다.	`deploymentConfig` `--selector="name=registry"`
`<object_type> --all`	유형 `<object_type>`의 모든 리소스를 선택합니다.	`deploymentConfig --all`
`-f` 또는 `--filename=<file_name>`	리소스를 편집하는 데 사용할 파일 이름, 디렉터리 또는 URL입니다.	`-f registry-deployment-config.json`

& lt;operation& gt;는 --add,--remove 또는 --list 중 하나일 수 있습니다.

모든 <mandatory_parameters > 또는 < optional_parameters >는 선택한 작업에 한정되며 이후 섹션에서 설명합니다.

27.3. 볼륨 추가
링크 복사

볼륨, 볼륨 마운트 또는 둘 다를 Pod 템플릿에 추가하려면 다음을 실행합니다.

oc volume <object_type>/<name> --add [options]

$ oc volume <object_type>/<name> --add [options]

Copy to Clipboard

Toggle word wrap

Expand

표 27.2. 볼륨 추가에 지원되는 옵션
옵션	설명	기본
`--name`	볼륨 이름입니다.	지정하지 않으면 자동으로 생성됩니다.
`-t, --type`	볼륨 소스의 이름입니다. 지원되는 값은 `emptyDir`, `hostPath`, `secret`, `configmap`, `persistentVolumeClaim` 또는 `projected`입니다.	`emptyDir`
`-c, --containers`	이름으로 컨테이너를 선택합니다. 문자와 일치하는 와일드카드 `'*'`를 사용할 수도 있습니다.	`'*'`
`-m, --mount-path`	선택한 컨테이너 내부의 마운트 경로입니다.
`--path`	호스트 경로입니다. `--type=hostPath`에 대한 필수 매개변수입니다.
`--secret-name`	보안의 이름입니다. `--type=secret`에 대한 필수 매개변수입니다.
`--configmap-name`	구성 맵의 이름입니다. `--type=configmap`에 대한 필수 매개변수입니다.
`--claim-name`	영구 볼륨 클레임의 이름입니다. `--type=persistentVolumeClaim`에 대한 필수 매개변수입니다.
`--source`	JSON 문자열로 된 볼륨 소스 세부 정보입니다. 필요한 볼륨 소스를 `--type`에서 지원하지 않는 경우 사용하는 것이 좋습니다.
`-o, --output`	수정된 오브젝트를 서버에서 업데이트하는 대신 표시합니다. 지원되는 값은 `json`, `yaml`입니다.
`--output-version`	지정된 버전으로 수정된 오브젝트를 출력합니다.	`api-version`

예제

배포 구성 레지스트리에 새 볼륨 소스 emptyDir 을 추가합니다.

oc volume dc/registry --add

$ oc volume dc/registry --add

Copy to Clipboard

Toggle word wrap

복제 컨트롤러 r1 의 시크릿 $ecret 로 볼륨 v1 을 추가하고 /data:의 컨테이너 내부에 마운트합니다.

oc volume rc/r1 --add --name=v1 --type=secret --secret-name='$ecret' --mount-path=/data

$ oc volume rc/r1 --add --name=v1 --type=secret --secret-name='$ecret' --mount-path=/data

Copy to Clipboard

Toggle word wrap

클레임 이름이 pvc1 인 기존 영구 볼륨 v1 을 디스크의 배포 구성 dc.json 에 추가하고, /data 의 컨테이너 c1 에 볼륨을 마운트하고, 서버에서 배포 구성을 업데이트합니다.

oc volume -f dc.json --add --name=v1 --type=persistentVolumeClaim \
  --claim-name=pvc1 --mount-path=/data --containers=c1

$ oc volume -f dc.json --add --name=v1 --type=persistentVolumeClaim \
  --claim-name=pvc1 --mount-path=/data --containers=c1

Copy to Clipboard

Toggle word wrap

모든 복제 컨트롤러 버전 5125c45f9f563 을 사용하여 Git 리포지토리 https://github.com/namespace1/project1 를 기반으로 볼륨 v1 을 추가합니다.

oc volume rc --all --add --name=v1 \
  --source='{"gitRepo": {

$ oc volume rc --all --add --name=v1 \
  --source='{"gitRepo": {
                "repository": "https://github.com/namespace1/project1",
                "revision": "5125c45f9f563"
            }}'

Copy to Clipboard

Toggle word wrap

27.4. 볼륨 업데이트
링크 복사

기존 볼륨 또는 볼륨 마운트를 업데이트하는 것은 볼륨 추가 와 동일하지만 --overwrite 옵션이 있습니다.

oc volume <object_type>/<name> --add --overwrite [options]

$ oc volume <object_type>/<name> --add --overwrite [options]

Copy to Clipboard

Toggle word wrap

예제

복제 컨트롤러 r1 의 기존 볼륨 v1 을 기존 영구 볼륨 클레임 pvc1 로 교체합니다.

oc volume rc/r1 --add --overwrite --name=v1 --type=persistentVolumeClaim --claim-name=pvc1

$ oc volume rc/r1 --add --overwrite --name=v1 --type=persistentVolumeClaim --claim-name=pvc1

Copy to Clipboard

Toggle word wrap

v1 볼륨의 경우 배포 구성 d1 마운트 지점을 /opt 로 변경합니다.

oc volume dc/d1 --add --overwrite --name=v1 --mount-path=/opt

$ oc volume dc/d1 --add --overwrite --name=v1 --mount-path=/opt

Copy to Clipboard

Toggle word wrap

27.5. 볼륨 제거
링크 복사

Pod 템플릿에서 볼륨 또는 볼륨 마운트를 제거하려면 다음을 수행합니다.

oc volume <object_type>/<name> --remove [options]

$ oc volume <object_type>/<name> --remove [options]

Copy to Clipboard

Toggle word wrap

Expand

표 27.3. 볼륨 제거에 지원되는 옵션
옵션	설명	기본
`--name`	볼륨 이름입니다.
`-c, --containers`	이름으로 컨테이너를 선택합니다. 문자와 일치하는 와일드카드 `'*'`를 사용할 수도 있습니다.	`'*'`
`--confirm`	한 번에 여러 개의 볼륨을 제거할 것임을 나타냅니다.
`-o, --output`	수정된 오브젝트를 서버에서 업데이트하는 대신 표시합니다. 지원되는 값은 `json`, `yaml`입니다.
`--output-version`	지정된 버전으로 수정된 오브젝트를 출력합니다.	`api-version`

예제

배포 구성 d1 에서 볼륨 v1 제거:

oc volume dc/d1 --remove --name=v1

$ oc volume dc/d1 --remove --name=v1

Copy to Clipboard

Toggle word wrap

배포 구성 d1 의 컨테이너 c1 에서 볼륨 v1 을 마운트 해제하고 d1 의 컨테이너에서 참조하지 않는 경우 볼륨 v1 을 제거합니다.

oc volume dc/d1 --remove --name=v1 --containers=c1

$ oc volume dc/d1 --remove --name=v1 --containers=c1

Copy to Clipboard

Toggle word wrap

복제 컨트롤러 r1 의 모든 볼륨 제거:

oc volume rc/r1 --remove --confirm

$ oc volume rc/r1 --remove --confirm

Copy to Clipboard

Toggle word wrap

27.6. 볼륨 나열
링크 복사

Pod 또는 Pod 템플릿의 볼륨 또는 볼륨 마운트를 나열하려면 다음을 수행합니다.

oc volume <object_type>/<name> --list [options]

$ oc volume <object_type>/<name> --list [options]

Copy to Clipboard

Toggle word wrap

볼륨에서 지원하는 옵션을 나열합니다.

Expand

옵션	설명	기본
`--name`	볼륨 이름입니다.
`-c, --containers`	이름으로 컨테이너를 선택합니다. 문자와 일치하는 와일드카드 `'*'`를 사용할 수도 있습니다.	`'*'`

예제

Pod p1 에 대한 모든 볼륨을 나열합니다.

oc volume pod/p1 --list

$ oc volume pod/p1 --list

Copy to Clipboard

Toggle word wrap

모든 배포 구성에 정의된 볼륨 v1 을 나열합니다.

oc volume dc --all --name=v1

$ oc volume dc --all --name=v1

Copy to Clipboard

Toggle word wrap

27.7. 하위 경로 지정
링크 복사

volumeMounts.subPath 속성을 사용하여 볼륨의 루트 대신 볼륨 내부에 subPath 를 지정합니다. subPath 를 사용하면 단일 Pod에서 여러 용도로 하나의 볼륨을 공유할 수 있습니다.

볼륨의 파일 목록을 보려면 oc rsh 명령을 실행합니다.

oc rsh <pod>

$ oc rsh <pod>
sh-4.2$ ls /path/to/volume/subpath/mount
example_file1 example_file2 example_file3

Copy to Clipboard

Toggle word wrap

subPath를 지정합니다.

subPath 사용량의 예

apiVersion: v1
kind: Pod
metadata:
  name: my-site
spec:
    containers:
    - name: mysql
      image: mysql
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql 
    - name: php
      image: php
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html 
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-site-data

apiVersion: v1
kind: Pod
metadata:
  name: my-site
spec:
    containers:
    - name: mysql
      image: mysql
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql

1


    - name: php
      image: php
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html

2


    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-site-data

Copy to Clipboard

Toggle word wrap

1: 데이터베이스는 mysql 폴더에 저장됩니다.
2: HTML 콘텐츠는 html 폴더에 저장됩니다.

28장. 영구 볼륨 사용
링크 복사

28.1. 개요
링크 복사

PersistentVolume 오브젝트는 OpenShift Container Platform 클러스터의 스토리지 리소스입니다. GCE 영구 디스크, AWS Elastic Block Store(EBS) 및 NFS 마운트와 같은 소스에서 PersistentVolume 오브젝트를 생성하여 클러스터 관리자가 스토리지를 프로비저닝합니다.

참고

설치 및 구성 가이드에서는 NFS,GlusterFS,Ceph RBD,OpenStack Cinder,AWS EBS,GCE Persistent Disk,iSCSI 및 Fibre Channel 을 사용하여 영구 스토리지로 OpenShift Container Platform 클러스터를 프로비저닝할 때 클러스터 관리자를 위한 지침을 제공합니다.

리소스에 대한 클레임을 배치하여 스토리지를 사용할 수 있습니다. PersistentVolumeClaim 오브젝트를 사용하여 스토리지 리소스를 요청할 수 있습니다. 클레임은 일반적으로 요청과 일치하는 볼륨과 쌍으로 연결됩니다.

28.2. 스토리지 요청
링크 복사

프로젝트에 PersistentVolumeClaim 오브젝트를 생성하여 스토리지를 요청할 수 있습니다.

영구 볼륨 클레임 오브젝트 정의

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "claim1"
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "1Gi"
  volumeName: "pv0001"

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "claim1"
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "1Gi"
  volumeName: "pv0001"

Copy to Clipboard

Toggle word wrap

28.3. 볼륨 및 클레임 바인딩
링크 복사

PersistentVolume 은 특정 리소스입니다. PersistentVolumeClaim 은 스토리지 크기와 같은 특정 속성이 있는 리소스에 대한 요청입니다. 둘 사이의 는 사용 가능한 볼륨에 대한 클레임과 일치하고 함께 바인딩하는 프로세스입니다. 이를 통해 Pod에서 클레임을 볼륨으로 사용할 수 있습니다. OpenShift Container Platform은 클레임을 지원하는 볼륨을 찾아 Pod에 마운트합니다.

CLI를 사용하여 쿼리하면 클레임 또는 볼륨이 바인딩되었는지 여부를 확인할 수 있습니다.

oc get pvc
oc get pv

$ oc get pvc
NAME        LABELS    STATUS    VOLUME
claim1      map[]     Bound     pv0001

$ oc get pv
NAME                LABELS              CAPACITY            ACCESSMODES         STATUS    CLAIM
pv0001              map[]               5368709120          RWO                 Bound     yournamespace / claim1

Copy to Clipboard

Toggle word wrap

28.4. Pod의 볼륨으로 클레임
링크 복사

PersistentVolumeClaim 은 포드에서 볼륨으로 사용합니다. OpenShift Container Platform은 Pod와 동일한 네임스페이스에 지정된 이름으로 클레임을 찾은 다음 클레임을 사용하여 마운트할 해당 볼륨을 찾습니다.

클레임을 포함하는 Pod 정의

apiVersion: "v1"
kind: "Pod"
metadata:
  name: "mypod"
  labels:
    name: "frontendhttp"
spec:
  containers:
    -
      name: "myfrontend"
      image: openshift/hello-openshift
      ports:
        -
          containerPort: 80
          name: "http-server"
      volumeMounts:
        -
          mountPath: "/var/www/html"
          name: "pvol"
  volumes:
    -
      name: "pvol"
      persistentVolumeClaim:
        claimName: "claim1"

apiVersion: "v1"
kind: "Pod"
metadata:
  name: "mypod"
  labels:
    name: "frontendhttp"
spec:
  containers:
    -
      name: "myfrontend"
      image: openshift/hello-openshift
      ports:
        -
          containerPort: 80
          name: "http-server"
      volumeMounts:
        -
          mountPath: "/var/www/html"
          name: "pvol"
  volumes:
    -
      name: "pvol"
      persistentVolumeClaim:
        claimName: "claim1"

Copy to Clipboard

Toggle word wrap

28.5. 볼륨 및 클레임 사전 바인딩
링크 복사

PersistentVolumeClaim 을 바인딩할 PersistentVolume 을 정확히 알고 있는 경우 volumeName 필드를 사용하여 PVC에 PV를 지정할 수 있습니다. 이 방법은 일반적인 일치 및 바인딩 프로세스를 건너뜁니다. PVC는 volumeName 에 지정된 이름과 동일한 PV에만 바인딩할 수 있습니다. 해당 이름의 PV가 존재하고 사용 가능한 경우 PV가 PVC의 라벨 선택기, 액세스 모드 및 리소스 요청을 충족하는지 여부와 관계없이 PV 및 PVC가 바인딩됩니다.

예 28.1. volumeName을 사용한 영구 볼륨 클레임 오브젝트 정의

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "claim1"
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "1Gi"
  volumeName: "pv0001"

apiVersion: "v1"
kind: "PersistentVolumeClaim"
metadata:
  name: "claim1"
spec:
  accessModes:
    - "ReadWriteOnce"
  resources:
    requests:
      storage: "1Gi"
  volumeName: "pv0001"

Copy to Clipboard

Toggle word wrap

중요

claimRefs 를 설정하는 기능은 설명된 사용 사례에 대한 임시 해결 방법입니다. 개발 중인 볼륨을 요청할 수 있는 사용자를 제한하기 위한 장기 솔루션.

참고

클러스터 관리자는 먼저 사용자 대신 claimRefs 를 설정하는 데 의존하기 전에 selector-label 볼륨 바인딩 을 구성하는 것을 고려해야 합니다.

또한 클러스터 관리자가 다른 사용자의 클레임에 대해서만 볼륨을 "활성"하여 다른 사람의 클레임이 수행하기 전에 바인딩할 수 있도록 할 수도 있습니다. 이 경우 관리자는 claimRef 필드를 사용하여 PV에 PVC를 지정할 수 있습니다. PV는 claimRef 에 지정된 이름과 네임스페이스가 동일한 PVC에만 바인딩할 수 있습니다. 레이블 선택기는 무시되지만 PV 및 PVC가 바인딩되려면 PVC의 액세스 모드 및 리소스 요청을 계속 충족해야 합니다.

claimRef를 사용하는 영구 볼륨 오브젝트 정의

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Recycle
  claimRef:
    name: claim1
    namespace: default

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 1Gi
  accessModes:
  - ReadWriteOnce
  nfs:
    path: /tmp
    server: 172.17.0.2
  persistentVolumeReclaimPolicy: Recycle
  claimRef:
    name: claim1
    namespace: default

Copy to Clipboard

Toggle word wrap

PVC에 volumeName 을 지정하면 변경하기 전에 다른 PVC가 지정된 PV에 바인딩되지 않습니다. 클레임은 PV를 사용할 수 있을 때까지 보류 중 상태로 유지됩니다.

PV에 claimRef 를 지정하면 지정된 PVC가 다른 PV에 바인딩되지 않습니다. PVC는 일반 바인딩 프로세스에 따라 바인딩할 다른 PV를 선택할 수 있습니다. 따라서 이러한 시나리오를 방지하고 클레임이 원하는 볼륨에 바인딩되는지 확인하려면 volumeName 과 claimRef 가 모두 지정되었는지 확인해야 합니다.

pv.kubernetes.io/bound-by-controller 주석의 Bound PV 및 PVC 쌍을 검사하여 volumeName 및 claimRef 설정에 영향을 주면 일치 및 바인딩 프로세스에 영향을 미칠 수 있습니다. volumeName 및/또는 claimRef 를 직접 설정하는 PV 및 PVC에는 이러한 주석이 없지만 일반 PV 및 PVC는 "yes" 로 설정됩니다.

PV의 claimRef 가 일부 PVC 이름과 네임스페이스로 설정되고 Retain 또는 Recycle 회수 정책에 따라 회수되는 경우 PVC 또는 전체 네임스페이스가 더 이상 존재하지 않는 경우에도 claimRef 가 동일한 PVC 이름 및 네임스페이스로 설정된 상태로 유지됩니다.

29장. 영구 볼륨 확장
링크 복사

29.1. 영구 볼륨 클레임 만료 활성화
링크 복사

볼륨 확장은 기술 프리뷰 기능이므로 OpenShift Container Platform 3.9 클러스터에서 기본적으로 활성화되어 있지 않습니다. OpenShift Container Platform 관리자가 특정 사용 사례에 대해 이 기능을 활성화하려는 다른 이유가 있을 수 있습니다.

참고

Red Hat 기술 프리뷰 기능 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

OpenShift Container Platform 사용자가 PVC(영구 볼륨 클레임)를 확장할 수 있도록 OpenShift Container Platform 관리자는 allowVolumeExpansion 을 true 로 설정하여 StorageClass를 생성하거나 업데이트해야 합니다. 해당 클래스에서 생성된 PVC만 확장할 수 있습니다.

그 외에도 OpenShift Container Platform 관리자는 ExpandPersistentVolumes 기능 플래그를 활성화하고 PersistentVolumeClaimResize 승인 컨트롤러를 켜야 합니다. PersistentVolumeClaimResize 승인 컨트롤러에 대한 자세한 내용은 Admission Controllers 를 참조하십시오.

기능 게이트를 활성화하려면 시스템에서 ExpandPersistentVolumes 를 true 로 설정합니다.

클러스터의 모든 노드에서 node-config.yaml을 구성합니다.

cat /etc/origin/node/node-config.yaml
...
kubeletArguments:
...
  feature-gates:
  - ExpandPersistentVolumes=true
systemctl restart atomic-openshift-node

# cat /etc/origin/node/node-config.yaml
...
kubeletArguments:
...
  feature-gates:
  - ExpandPersistentVolumes=true
# systemctl restart atomic-openshift-node

Copy to Clipboard

Toggle word wrap

마스터 API 및 컨트롤러 관리자에서 ExpandPersistentVolumes 기능 게이트를 활성화합니다.

cat /etc/origin/master/master-config.yaml
...
kubernetesMasterConfig:
  apiServerArguments:
  ...
    feature-gates:
    - ExpandPersistentVolumes=true
  controllerArguments:
    ...
    feature-gates:
    - ExpandPersistentVolumes=true

systemctl restart atomic-openshift-master-api

# cat /etc/origin/master/master-config.yaml
...
kubernetesMasterConfig:
  apiServerArguments:
  ...
    feature-gates:
    - ExpandPersistentVolumes=true
  controllerArguments:
    ...
    feature-gates:
    - ExpandPersistentVolumes=true

# systemctl restart atomic-openshift-master-api

Copy to Clipboard

Toggle word wrap

29.2. GlusterFS 기반 영구 볼륨 클레임 확장
링크 복사

OpenShift Container Platform 관리자가 allowVolumeExpansion 이 true 로 설정된 StorageClass를 생성하면 필요한 경우 PVC를 편집하고 새 크기를 요청할 수 있습니다.

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

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: gluster-mysql
spec:
  storageClass: "storageClassWithFlagSet"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: gluster-mysql
spec:
  storageClass: "storageClassWithFlagSet"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

1

Copy to Clipboard

Toggle word wrap

1: spec.resources.requests 를 업데이트하여 확장된 볼륨을 요청할 수 있습니다.

29.3. 파일 시스템을 사용하여 영구 볼륨 클레임 확장
링크 복사

파일 시스템 크기 조정이 필요한 볼륨 유형(예: GCE PD, EBS, Cinder)을 기반으로 하는 PVC를 확장하는 작업은 2단계 프로세스입니다. 이 프로세스에는 일반적으로 CloudProvider에서 볼륨 개체를 확장한 다음 실제 노드에서 파일 시스템을 확장하는 작업이 포함됩니다.

노드의 파일 시스템을 배양하는 것은 볼륨으로 새 Pod가 시작될 때만 수행됩니다.

다음 프로세스에서는 이전에 allowVolumeExpansion 이 true 로 설정된 StorageClass에서 PVC가 생성되었다고 가정합니다.

PVC를 편집하고 spec.resources.requests를 편집하여 새 크기를 요청합니다. CloudProvider 오브젝트 크기 조정이 완료되면 PVC가 FileSystemResizePending 으로 설정됩니다.
다음 명령을 입력하여 조건을 확인합니다.

  oc describe pvc <pvc_name>

  oc describe pvc <pvc_name>

Copy to Clipboard

Toggle word wrap

CloudProvider 오브젝트 크기 조정이 완료되면 영구 볼륨(PV) 오브젝트는 PersistentVolume.Spec.Capacity 에 새로 요청된 크기를 반영합니다. 이 시점에서 PVC에서 새 Pod를 생성하거나 다시 생성하여 파일 시스템 크기 조정을 완료할 수 있습니다. Pod가 실행되면 새로 요청된 크기를 사용할 수 있으며 FileSystemResizePending 조건이 PVC에서 제거됩니다.

29.4. 볼륨 확장 시 실패에서 복구
링크 복사

마스터 또는 노드에서 기본 스토리지를 확장하는 경우 OpenShift Container Platform 관리자는 PVC 상태를 수동으로 복구하고 관리자의 개입없이 컨트롤러에 의해 지속적으로 재시도되는 크기 조정 요청을 취소할 수 있습니다.

현재 이 작업은 다음 단계를 완료하여 수동으로 수행할 수 있습니다.

PVC( claim)에 바인딩된 PV를 Retain 회수 정책으로 표시합니다. PV를 편집하고 persistentVolumeReclaimPolicy를 Retain으로 변경하여 수행할 수 있습니다.
PVC를 삭제합니다(나중에 다시 생성됨).
새로 생성된 PVC가 Retain으로 표시된 PV에 바인딩할 수 있도록 PV를 수동으로 편집하고 PV 사양에서 claimRef 항목을 삭제합니다. PV가 Available로 표시됩니다. 사전 바인딩 PVC에 대한 자세한 내용은 볼륨 및 클레임 사전 바인딩 을 참조하십시오.
기본 스토리지 공급자가 할당할 수 있는 작은 크기 또는 크기로 PVC를 다시 생성합니다. 또한 PVC의 volumeName 필드를 PV 이름으로 설정합니다. 이렇게 하면 PVC가 프로비저닝된 PV에만 바인딩됩니다.
PV에서 회수 정책을 복구합니다.

30장. 원격 명령 실행
링크 복사

30.1. 개요
링크 복사

CLI를 사용하여 컨테이너에서 원격 명령을 실행할 수 있습니다. 이를 통해 컨테이너의 일상적인 작업에 대해 일반 Linux 명령을 실행할 수 있습니다.

중요

보안상의 이유로 cluster-admin 사용자가 명령을 실행하는 경우를 제외하고 권한 있는 컨테이너에 액세스하면 oc exec 명령이 작동하지 않습니다. 자세한 내용은 CLI 작업 주제를 참조하십시오.

30.2. 기본 사용량
링크 복사

원격 컨테이너 명령 실행에 대한 지원은 CLI에 빌드됩니다.

oc exec <pod> [-c <container>] <command> [<arg_1> ... <arg_n>]

$ oc exec <pod> [-c <container>] <command> [<arg_1> ... <arg_n>]

Copy to Clipboard

Toggle word wrap

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

oc exec mypod date

$ oc exec mypod date
Thu Apr  9 02:21:53 UTC 2015

Copy to Clipboard

Toggle word wrap

30.3. 프로토콜
링크 복사

클라이언트는 Kubernetes API 서버에 대한 요청을 발행하여 컨테이너에서 원격 명령 실행을 시작합니다.

/proxy/minions/<node_name>/exec/<namespace>/<pod>/<container>?command=<command>

/proxy/minions/<node_name>/exec/<namespace>/<pod>/<container>?command=<command>

Copy to Clipboard

Toggle word wrap

위 URL에서

<node_name>은 노드의 FQDN입니다.
<namespace>는 대상 Pod의 네임스페이스입니다.
<pod>는 대상 Pod의 이름입니다.
<container>는 대상 컨테이너의 이름입니다.
<command>는 실행하기를 원하는 명령입니다.

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

/proxy/minions/node123.openshift.com/exec/myns/mypod/mycontainer?command=date

/proxy/minions/node123.openshift.com/exec/myns/mypod/mycontainer?command=date

Copy to Clipboard

Toggle word wrap

또한 클라이언트는 요청에 매개변수를 추가하여 다음에 대한 여부를 표시할 수 있습니다.

클라이언트에서 원격 컨테이너의 명령(stdin)에 입력을 보내야 합니다.
클라이언트의 터미널이 TTY입니다.
원격 컨테이너의 명령에서 stdout의 출력을 클라이언트로 보내야 합니다.
원격 컨테이너의 명령에서 stderr의 출력을 클라이언트로 보내야 합니다.

클라이언트는 API 서버로 exec 요청을 보낸 후 다중 스트림을 지원하는 연결로 연결을 업그레이드합니다. 현재 구현에서는 SPDY를 사용합니다.

클라이언트는 stdin, stdout, stderr에 대해 각각 하나의 스트림을 생성합니다. 클라이언트는 스트림을 구분하기 위해 스트림의 streamType 헤더를 stdin, stdout, stderr 중 하나로 설정합니다.

클라이언트는 원격 명령 실행 요청을 완료하면 모든 스트림, 업그레이드된 연결, 기본 연결을 종료합니다.

참고

자세한 내용은 관리자가 아키텍처 가이드를 참조하십시오.

31장. 컨테이너에서 또는 컨테이너에 파일 복사
링크 복사

31.1. 개요
링크 복사

CLI를 사용하여 컨테이너의 원격 디렉터리로 또는 원격 디렉터리에서 로컬 파일을 복사할 수 있습니다. 이는 백업 및 복원 목적으로 Pod로 또는 Pod에서 데이터베이스 아카이브를 복사하는 데 유용한 툴입니다. 실행 중인 Pod에서 소스 파일의 핫 재로드를 지원하는 경우 개발 디버깅을 위해 소스 코드 변경 사항을 실행 중인 Pod에 복사하는 데도 사용할 수 있습니다.

31.2. 기본 사용량
링크 복사

컨테이너에서 또는 컨테이너에 로컬 파일 복사 지원은 CLI에 빌드됩니다.

oc rsync <source> <destination> [-c <container>]

$ oc rsync <source> <destination> [-c <container>]

Copy to Clipboard

Toggle word wrap

예를 들어 로컬 디렉터리를 Pod 디렉터리에 복사하려면 다음을 수행합니다.

oc rsync /home/user/source devpod1234:/src

$ oc rsync /home/user/source devpod1234:/src

Copy to Clipboard

Toggle word wrap

Pod 디렉터리를 로컬 디렉터리에 복사하려면 다음을 수행합니다.

oc rsync devpod1234:/src /home/user/source

$ oc rsync devpod1234:/src /home/user/source

Copy to Clipboard

Toggle word wrap

31.3. 데이터베이스 백업 및 복원
링크 복사

oc rsync 를 사용하여 기존 데이터베이스 컨테이너의 데이터베이스 아카이브를 새 데이터베이스 컨테이너의 영구 볼륨 디렉터리로 복사합니다.

참고

MySQL은 아래 예제에서 사용됩니다. mysql|MYSQL 을 pgsql|PGSQL 또는 mongodb|MONGODB 로 바꾸고 마이그레이션 가이드 를 참조하여 지원되는 각 데이터베이스 이미지에 대해 정확한 명령을 찾습니다. 이 예제에서는 기존 데이터베이스 컨테이너를 가정합니다.

실행 중인 데이터베이스 Pod에서 기존 데이터베이스를 백업합니다.

oc rsh <existing db container>
mkdir /var/lib/mysql/data/db_archive_dir
mysqldump --skip-lock-tables -h ${MYSQL_SERVICE_HOST} -P ${MYSQL_SERVICE_PORT:-3306} \
  -u ${MYSQL_USER} --password="$MYSQL_PASSWORD" --all-databases > /var/lib/mysql/data/db_archive_dir/all.sql
exit

$ oc rsh <existing db container>
# mkdir /var/lib/mysql/data/db_archive_dir
# mysqldump --skip-lock-tables -h ${MYSQL_SERVICE_HOST} -P ${MYSQL_SERVICE_PORT:-3306} \
  -u ${MYSQL_USER} --password="$MYSQL_PASSWORD" --all-databases > /var/lib/mysql/data/db_archive_dir/all.sql
# exit

Copy to Clipboard

Toggle word wrap

아카이브 파일을 로컬 머신에 원격으로 동기화합니다.

oc rsync <existing db container with db archive>:/var/lib/mysql/data/db_archive_dir /tmp/.

$ oc rsync <existing db container with db archive>:/var/lib/mysql/data/db_archive_dir /tmp/.

Copy to Clipboard

Toggle word wrap

위에서 만든 데이터베이스 아카이브 파일을 로드할 두 번째 MySQL 포드를 시작합니다. MySQL 포드에는 고유한 DATABASE_SERVICE_NAME 이 있어야 합니다.

oc new-app mysql-persistent \
  -p MYSQL_USER=<archived mysql username> \
  -p MYSQL_PASSWORD=<archived mysql password> \
  -p MYSQL_DATABASE=<archived database name> \
  -p DATABASE_SERVICE_NAME='mysql2'
oc rsync /tmp/db_archive_dir new_dbpod1234:/var/lib/mysql/data
oc rsh new_dbpod1234

$ oc new-app mysql-persistent \
  -p MYSQL_USER=<archived mysql username> \
  -p MYSQL_PASSWORD=<archived mysql password> \
  -p MYSQL_DATABASE=<archived database name> \
  -p DATABASE_SERVICE_NAME='mysql2'

1


$ oc rsync /tmp/db_archive_dir new_dbpod1234:/var/lib/mysql/data
$ oc rsh new_dbpod1234

Copy to Clipboard

Toggle word wrap

1: MySQL 이 기본값입니다. 이 예제에서는 mysql2 가 생성됩니다.

적절한 명령을 사용하여 복사된 데이터베이스 아카이브 디렉터리에서 새 데이터베이스 컨테이너의 데이터베이스를 복원합니다.

MySQL

cd /var/lib/mysql/data/db_archive_dir
mysql -u root
source all.sql
GRANT ALL PRIVILEGES ON <dbname>.* TO '<your username>'@'localhost'; FLUSH PRIVILEGES;
cd ../; rm -rf /var/lib/mysql/data/db_backup_dir

$ cd /var/lib/mysql/data/db_archive_dir
$ mysql -u root
$ source all.sql
$ GRANT ALL PRIVILEGES ON <dbname>.* TO '<your username>'@'localhost'; FLUSH PRIVILEGES;
$ cd ../; rm -rf /var/lib/mysql/data/db_backup_dir

Copy to Clipboard

Toggle word wrap

이제 보관된 데이터베이스가 있는 프로젝트에 두 개의 MySQL 데이터베이스 포드가 실행되고 있습니다.

31.4. 요구 사항
링크 복사

oc rsync 명령은 클라이언트의 머신에 있는 경우 로컬 rsync 명령을 사용합니다. 이를 위해서는 원격 컨테이너에 rsync 명령도 있어야 합니다.

rsync 가 로컬 또는 원격 컨테이너에 없는 경우 tar 아카이브는 로컬에 생성되고 컨테이너로 전송되며 여기에서 tar 이 파일을 추출하는 데 사용됩니다. 원격 컨테이너에서 tar 를 사용할 수 없는 경우 복사가 실패합니다.

tar 복사 방법은 rsync 와 동일한 기능을 제공하지 않습니다. 예를 들어 rsync 는 대상 디렉터리가 없는 경우 대상 디렉터리를 생성하고 소스와 대상 간에 다른 파일만 보냅니다.

참고

Windows에서는 oc rsync 명령과 함께 사용할 수 있도록 cwRsync 클라이언트를 설치하고 PATH에 추가해야 합니다.

31.5. 복사 소스 지정
링크 복사

oc rsync 명령의 소스 인수는 로컬 디렉터리 또는 pod 디렉터리를 가리켜야 합니다. 개별 파일은 현재 지원되지 않습니다.

Pod 디렉터리를 지정할 때는 디렉터리 이름 앞에 Pod 이름을 붙여야 합니다.

<pod name>:<dir>

<pod name>:<dir>

Copy to Clipboard

Toggle word wrap

표준 rsync 와 마찬가지로 디렉터리 이름이 경로 구분자(/)로 끝나는 경우 디렉터리의 콘텐츠만 대상에 복사됩니다. 그렇지 않으면 디렉터리 자체는 모든 콘텐츠가 있는 대상에 복사됩니다.

31.6. 복사 대상 지정
링크 복사

oc rsync 명령의 대상 인수는 디렉터리를 가리켜야 합니다. 해당 디렉터리가 존재하지 않지만 rsync가 복사에 사용되는 경우 사용자를 위해 디렉터리가 생성됩니다.

31.7. 대상의 파일 삭제
링크 복사

--delete 플래그는 로컬 디렉터리에 없는 파일을 원격 디렉터리에서 삭제하는 데 사용할 수 있습니다.

31.8. 파일 변경 시 연속 동기화
링크 복사

--watch 옵션을 사용하면 명령에서 파일 시스템 변경의 소스 경로를 모니터링하고 변경이 발생하면 변경 사항을 동기화합니다. 이 인수를 사용하면 명령이 영구적으로 실행됩니다.

빠르게 변경되는 파일 시스템으로 인해 동기화를 연속으로 호출하지 않도록 동기화는 잠시 후에 수행됩니다.

--watch 옵션을 사용할 때의 동작은 일반적으로 oc rsync에 전달되는 인수를 포함하여 oc rsync를 수동으로 반복해서 호출하는 것과 사실상 동일합니다. 따라서 -delete와 같이 oc rsync를 수동으로 호출하는 데 사용하는 것과 같은 플래그를 통해 해당 동작을 제어할 수 있습니다.

31.9. 고급 Rsync 기능
링크 복사

oc rsync 명령은 표준 rsync보다 적은 수의 명령줄 옵션을 표시합니다. oc rsync (예: --exclude-from=FILE 옵션)에서 사용할 수 없는 표준 rsync 명령줄 옵션을 사용하려는 경우 다음과 같이 표준 rsync 's --rsh (-e) 옵션 또는 RSYNC_RSH 환경 변수를 해결 방법으로 사용할 수 있습니다.

rsync --rsh='oc rsh' --exclude-from=FILE SRC POD:DEST

$ rsync --rsh='oc rsh' --exclude-from=FILE SRC POD:DEST

Copy to Clipboard

Toggle word wrap

또는 다음을 수행합니다.

export RSYNC_RSH='oc rsh'
rsync --exclude-from=FILE SRC POD:DEST

$ export RSYNC_RSH='oc rsh'
$ rsync --exclude-from=FILE SRC POD:DEST

Copy to Clipboard

Toggle word wrap

위의 두 가지 예 모두 oc rsh를 원격 쉘 프로그램으로 사용하여 원격 Pod에 연결할 수 있도록 표준 rsync를 구성하고 oc rsync를 실행하는 대신 사용할 수 있습니다.

32장. 포트 전달
링크 복사

32.1. 개요
링크 복사

OpenShift Container Platform에서는 Kubernetes 에 기본 제공되는 기능을 사용하여 Pod로 포트 전달을 지원합니다. 자세한 내용은 아키텍처를 참조하십시오.

CLI를 사용하여 하나 이상의 로컬 포트를 Pod로 전달할 수 있습니다. 이 경우 지정된 포트 또는 임의의 포트에서 로컬로 수신 대기하고 Pod의 지정된 포트와 데이터를 주고받을 수 있습니다.

32.2. 기본 사용량
링크 복사

포트 전달에 대한 지원은 CLI에 빌드됩니다.

oc port-forward <pod> [<local_port>:]<remote_port> [...[<local_port_n>:]<remote_port_n>]

$ oc port-forward <pod> [<local_port>:]<remote_port> [...[<local_port_n>:]<remote_port_n>]

Copy to Clipboard

Toggle word wrap

CLI는 사용자가 지정한 각 로컬 포트에서 수신 대기하고 아래에 설명된 프로토콜 을 통해 전달합니다.

포트는 다음 형식을 사용하여 지정할 수 있습니다.

`5000`	클라이언트는 포트 5000에서 로컬로 수신 대기하고 Pod의 5000으로 전달합니다.
`6000:5000`	클라이언트는 포트 6000에서 로컬로 수신 대기하고 Pod의 5000으로 전달합니다.
`:5000` 또는 `0:5000`	클라이언트는 사용 가능한 로컬 포트를 선택하고 Pod의 5000으로 전달합니다.

예를 들어 포트 5000 및 6000 에서 로컬로 수신하고 Pod의 포트 5000 및 6000 에서 또는 Pod에서 데이터를 전달하려면 다음을 실행합니다.

oc port-forward <pod> 5000 6000

$ oc port-forward <pod> 5000 6000

Copy to Clipboard

Toggle word wrap

로컬로 포트 8888 에서 수신 대기하고 Pod의 5000 으로 전달하려면 다음을 실행합니다.

oc port-forward <pod> 8888:5000

$ oc port-forward <pod> 8888:5000

Copy to Clipboard

Toggle word wrap

사용 가능한 포트에서 로컬로 수신하고 Pod의 5000 으로 전달하려면 다음을 실행합니다.

oc port-forward <pod> :5000

$ oc port-forward <pod> :5000

Copy to Clipboard

Toggle word wrap

또는 다음을 수행합니다.

oc port-forward <pod> 0:5000

$ oc port-forward <pod> 0:5000

Copy to Clipboard

Toggle word wrap

32.3. 프로토콜
링크 복사

클라이언트는 Kubernetes API 서버에 대한 요청을 발행하여 Pod로의 포트 전달을 시작합니다.

/proxy/minions/<node_name>/portForward/<namespace>/<pod>

/proxy/minions/<node_name>/portForward/<namespace>/<pod>

Copy to Clipboard

Toggle word wrap

위 URL에서

<node_name>은 노드의 FQDN입니다.
<namespace>는 대상 Pod의 네임스페이스입니다.
<pod>는 대상 Pod의 이름입니다.

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

/proxy/minions/node123.openshift.com/portForward/myns/mypod

/proxy/minions/node123.openshift.com/portForward/myns/mypod

Copy to Clipboard

Toggle word wrap

클라이언트는 API 서버로 포트 전달 요청을 보낸 후 다중 스트림을 지원하는 연결로 연결을 업그레이드합니다. 현재 구현에서는 SPDY를 사용합니다.

클라이언트는 Pod에 대상 포트가 포함된 port 헤더를 사용하여 스트림을 생성합니다. 스트림에 기록된 모든 데이터는 Kubelet을 통해 대상 Pod 및 포트로 전달됩니다. 마찬가지로 이렇게 전달된 연결에 대해 Pod에서 전송되는 모든 데이터는 클라이언트의 동일한 스트림으로 다시 전달됩니다.

클라이언트는 포트 전달 요청을 완료하면 모든 스트림, 업그레이드된 연결, 기본 연결을 종료합니다.

참고

자세한 내용은 관리자가 아키텍처 가이드를 참조하십시오.

33장. 공유 메모리
링크 복사

33.1. 개요
링크 복사

Linux에는 System V 및 POSIX의 두 가지 유형의 공유 메모리 개체가 있습니다. 포드의 컨테이너는 포드 인프라 컨테이너의 IPC 네임스페이스를 공유하므로 System V 공유 메모리 오브젝트를 공유할 수 있습니다. 이 문서에서는 POSIX 공유 메모리 오브젝트도 공유할 수 있는 방법에 대해 설명합니다.

33.2. POSIX 공유 메모리
링크 복사

POSIX 공유 메모리를 사용하려면 tmpfs를 /dev/shm 에 마운트해야 합니다. 포드의 컨테이너는 마운트 네임스페이스를 공유하지 않으므로 볼륨을 사용하여 Pod의 각 컨테이너에 동일한 /dev/shm 을 제공합니다. 다음 예제에서는 두 컨테이너 간에 POSIX 공유 메모리를 설정하는 방법을 보여줍니다.

shared-memory.yaml

---
apiVersion: v1
id: hello-openshift
kind: Pod
metadata:
  name: hello-openshift
  labels:
    name: hello-openshift
spec:
  volumes:                          
    - name: dshm
      emptyDir:
        medium: Memory
  containers:
    - image: kubernetes/pause
      name: hello-container1
      ports:
        - containerPort: 8080
          hostPort: 6061
      volumeMounts:                 
        - mountPath: /dev/shm
          name: dshm
    - image: kubernetes/pause
      name: hello-container2
      ports:
        - containerPort: 8081
          hostPort: 6062
      volumeMounts:                 
        - mountPath: /dev/shm
          name: dshm

---
apiVersion: v1
id: hello-openshift
kind: Pod
metadata:
  name: hello-openshift
  labels:
    name: hello-openshift
spec:
  volumes:

1


    - name: dshm
      emptyDir:
        medium: Memory
  containers:
    - image: kubernetes/pause
      name: hello-container1
      ports:
        - containerPort: 8080
          hostPort: 6061
      volumeMounts:

2


        - mountPath: /dev/shm
          name: dshm
    - image: kubernetes/pause
      name: hello-container2
      ports:
        - containerPort: 8081
          hostPort: 6062
      volumeMounts:

3


        - mountPath: /dev/shm
          name: dshm

Copy to Clipboard

Toggle word wrap

1: tmpfs 볼륨 dshm 을 지정합니다.
2: dshm 을 통해 hello-container1 에 대해 POSIX 공유 메모리를 활성화합니다.
3: dshm 을 통해 hello-container2 에 대해 POSIX 공유 메모리를 활성화합니다.

shared-memory.yaml 파일을 사용하여 Pod를 생성합니다.

oc create -f shared-memory.yaml

$ oc create -f shared-memory.yaml

Copy to Clipboard

Toggle word wrap

34장. 애플리케이션 상태
링크 복사

34.1. 개요
링크 복사

소프트웨어 시스템에서 일시적인 문제(예: 임시 연결 손실), 구성 오류 또는 외부 종속 항목의 문제로 인해 구성 요소가 비정상 상태가 될 수 있습니다. OpenShift Container Platform 애플리케이션에는 비정상 상태의 컨테이너를 탐지하고 처리하는 다양한 옵션이 있습니다.

34.2. 프로브를 사용한 컨테이너 상태 점검
링크 복사

프로브는 실행 중인 컨테이너에서 진단을 주기적으로 수행하는 Kubernetes 작업입니다. 현재 두 가지 유형의 프로브가 존재하며 각각 다른 용도로 사용됩니다.

Expand

활성 프로브

활성 상태 프로브는 구성된 컨테이너가 여전히 실행 중인지 확인합니다. 활성 상태 프로브가 실패하면 kubelet에서 재시작 정책에 따라 컨테이너를 종료합니다. 포드 구성의 template.spec.containers.livenessprobe 스탠자를 구성하여 활성 점검을 설정합니다.

준비 프로브

준비 상태 프로브는 컨테이너가 서비스 요청을 준비가 되었는지 확인합니다. 준비 상태 프로브가 컨테이너에 실패하면 끝점 컨트롤러에서 모든 서비스의 끝점에서 해당 IP 주소가 제거되었는지 확인합니다. 준비 상태 프로브는 컨테이너가 실행 중인 경우에도 끝점 컨트롤러에 알리는 데 사용할 수 있으며 프록시에서 트래픽을 수신해서는 안 됩니다. 포드 구성의 template.spec.containers.readinessprobe 스탠자를 구성하여 준비 상태 점검을 설정합니다.

프로브의 정확한 타이밍은 두 가지 필드로 제어되며 두 필드 모두 초 단위로 표시됩니다.

Expand

필드	설명
`initialDelaySeconds`	컨테이너가 프로브를 시작하기 전에 대기하는 시간입니다.
`timeoutSeconds`	프로브가 완료될 때까지 대기하는 시간(기본값: `1`)입니다. 이 시간이 초과되면 OpenShift Container Platform은 프로브가 실패한 것으로 간주합니다.

두 프로브 모두 다음 세 가지 방법으로 구성할 수 있습니다.

HTTP 확인

kubelet은 웹 후크를 사용하여 컨테이너의 상태를 확인합니다. HTTP 응답 코드가 200에서 399 사이인 경우 확인은 성공한 것으로 간주됩니다. 다음은 HTTP 확인 방법을 사용한 준비 상태 점검 예제입니다.

예 34.1. 준비 상태 HTTP 검사

...
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

...
readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

Copy to Clipboard

Toggle word wrap

HTTP 검사는 완전히 초기화될 때 HTTP 상태 코드를 반환하는 애플리케이션에 적합합니다.

컨테이너 실행 확인

kubelet은 컨테이너 내부에서 명령을 실행합니다. 상태가 0인 검사를 종료하면 성공으로 간주됩니다. 다음은 컨테이너 실행 방법을 사용한 활성 점검 예제입니다.

예 34.2. 활성 컨테이너 실행 확인

...
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/health
  initialDelaySeconds: 15
...

...
livenessProbe:
  exec:
    command:
    - cat
    - /tmp/health
  initialDelaySeconds: 15
...

Copy to Clipboard

Toggle word wrap

참고

timeoutSeconds 매개변수는 컨테이너 실행 검사의 준비 및 활성 상태 프로브에 영향을 미치지 않습니다. OpenShift Container Platform이 컨테이너에 대한 exec 호출에 시간을 초과할 수 없기 때문에 프로브 자체 내에서 시간 초과를 구현할 수 있습니다. 프로브에 시간 초과를 구현하는 한 가지 방법은 timeout 매개변수를 사용하여 활성 상태 또는 준비 상태 프로브를 실행하는 것입니다.

[...]
       livenessProbe:
        exec:
          command:
            - /bin/bash
            - '-c'
            - timeout 60 /opt/eap/bin/livenessProbe.sh 
        timeoutSeconds: 1
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 3
[...]

[...]
       livenessProbe:
        exec:
          command:
            - /bin/bash
            - '-c'
            - timeout 60 /opt/eap/bin/livenessProbe.sh

1


        timeoutSeconds: 1
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 3
[...]

Copy to Clipboard

Toggle word wrap

1: 프로브 스크립트의 시간 제한 값 및 경로입니다.

TCP 소켓 확인

kubelet은 컨테이너에 대한 소켓을 열려고 합니다. 검사에서 연결을 설정할 수 있는 경우에만 컨테이너는 정상으로 간주됩니다. 다음은 TCP 소켓 확인 방법을 사용한 활성 점검 예제입니다.

예 34.3. 활성 TCP 소켓 확인

...
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

...
livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  timeoutSeconds: 1
...

Copy to Clipboard

Toggle word wrap

TCP 소켓 확인은 초기화가 완료될 때까지 수신 대기를 시작하지 않는 애플리케이션에 적합합니다.

상태 점검에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.

35장. 이벤트
링크 복사

35.1. 개요
링크 복사

OpenShift Container Platform의 이벤트는 OpenShift Container Platform 클러스터의 API 오브젝트에 발생하는 이벤트를 기반으로 모델링됩니다. OpenShift Container Platform은 이벤트를 통해 리소스와 관계없이 실제 이벤트에 대한 정보를 기록할 수 있습니다. 또한 개발자와 관리자는 통합된 방식으로 시스템 구성 요소에 대한 정보를 사용할 수 있습니다.

35.2. CLI를 사용하여 이벤트 보기
링크 복사

다음 명령을 사용하여 지정된 프로젝트의 이벤트 목록을 가져올 수 있습니다.

oc get events [-n <project>]

$ oc get events [-n <project>]

Copy to Clipboard

Toggle word wrap

35.3. 콘솔에서 이벤트 보기
링크 복사

웹 콘솔에서 프로젝트의 이벤트를 찾아보기 → 이벤트 페이지에서 볼 수 있습니다. Pod 및 배포와 같은 기타 많은 오브젝트에는 해당 오브젝트와 관련된 이벤트를 표시하는 자체 이벤트 탭도 있습니다.

35.4. 포괄적인 이벤트 목록
링크 복사

이 섹션에서는 OpenShift Container Platform의 이벤트에 대해 설명합니다.

Expand

표 35.1. 구성 이벤트
이름	설명
`FailedValidation`	Pod 구성 검증에 실패했습니다.

Expand

표 35.2. 컨테이너 이벤트
이름	설명
`BackOff`	백오프로 컨테이너를 재시작하지 못했습니다.
`Created`	컨테이너가 생성되었습니다.
`실패`	가져오기/생성/시작이 실패했습니다.
`Killing`	컨테이너를 종료합니다.
`started`	컨테이너가 시작되었습니다.
`Preempting`	다른 Pod를 선점합니다.
`ExceededGracePeriod`	컨테이너 런타임이 지정된 유예 기간 내에 Pod를 중지하지 않았습니다.

Expand

표 35.3. 상태 이벤트
이름	설명
`Unhealthy`	컨테이너 상태가 비정상입니다.

Expand

표 35.4. 이미지 이벤트
이름	설명
`BackOff`	Ctr Start를 백오프하고 이미지를 가져옵니다.
`ErrImageNeverPull`	이미지의 NeverPull Policy를 위반했습니다.
`실패`	이미지를 가져오지 못했습니다.
`InspectFailed`	이미지를 검사하지 못했습니다.
`Pulled`	이미지를 가져왔거나 컨테이너 이미지가 머신에 이미 있습니다.
`Pulling`	이미지를 가져오는 중입니다.

Expand

표 35.5. 이미지 관리자 이벤트
이름	설명
`FreeDiskSpaceFailed`	디스크 공간을 비우지 못했습니다.
`InvalidDiskCapacity`	디스크 용량이 유효하지 않습니다.

Expand

표 35.6. 노드 이벤트
이름	설명
`FailedMount`	볼륨을 마운트하지 못했습니다.
`HostNetworkNotSupported`	호스트 네트워크가 지원되지 않습니다.
`HostPortConflict`	호스트/포트가 충돌합니다.
`InsufficientFreeCPU`	사용 가능한 CPU가 충분하지 않습니다.
`InsufficientFreeMemory`	사용 가능한 메모리가 충분하지 않습니다.
`KubeletSetupFailed`	kubelet 설정에 실패했습니다.
`NilShaper`	정의되지 않은 쉐이퍼입니다.
`NodeNotReady`	노드가 준비되지 않았습니다.
`NodeNotSchedulable`	노드를 예약할 수 없습니다.
`NodeReady`	노드가 준비되었습니다.
`NodeSchedulable`	노드를 예약할 수 있습니다.
`NodeSelectorMismatching`	노드 선택기가 일치하지 않습니다.
`OutOfDisk`	디스크가 없습니다.
`Rebooted`	노드가 재부팅되었습니다.
`Starting`	kubelet을 시작합니다.
`FailedAttachVolume`	볼륨을 연결할 수 없습니다.
`FailedDetachVolume`	볼륨을 분리할 수 없습니다.
`VolumeResizeFailed`	볼륨을 확장/축소할 수 없습니다.
`VolumeResizeSuccessful`	볼륨을 확장/축소했습니다.
`FileSystemResizeFailed`	파일 시스템을 확장/축소하지 못했습니다.
`FileSystemResizeSuccessful`	파일 시스템을 확장/축소했습니다.
`FailedUnMount`	볼륨을 마운트 해제하지 못했습니다.
`FailedMapVolume`	볼륨을 매핑하지 못했습니다.
`FailedUnmapDevice`	장치를 매핑 해제하지 못했습니다.
`AlreadyMountedVolume`	볼륨이 이미 마운트되어 있습니다.
`SuccessfulDetachVolume`	볼륨이 분리되었습니다.
`SuccessfulMountVolume`	볼륨을 마운트했습니다.
`SuccessfulUnMountVolume`	볼륨을 마운트 해제했습니다.
`ContainerGCFailed`	컨테이너 가비지 컬렉션에 실패했습니다.
`ImageGCFailed`	이미지 가비지 컬렉션에 실패했습니다.
`FailedNodeAllocatableEnforcement`	시스템 예약 Cgroup 제한을 적용하지 못했습니다.
`NodeAllocatableEnforced`	시스템 예약 Cgroup 제한을 적용했습니다.
`UnsupportedMountOption`	지원되지 않는 마운트 옵션입니다.
`SandboxChanged`	Pod 샌드박스가 변경되었습니다.
`FailedCreatePodSandBox`	Pod 샌드박스를 생성하지 못했습니다.
`FailedPodSandBoxStatus`	실패한 Pod 샌드박스 상태입니다.

Expand

표 35.7. Pod 작업자 이벤트
이름	설명
`FailedSync`	Pod 동기화에 실패했습니다.

Expand

표 35.8. 시스템 이벤트
이름	설명
`SystemOOM`	클러스터에 OOM(메모리 부족) 상황이 있습니다.

Expand

표 35.9. Pod 이벤트
이름	설명
`FailedKillPod`	Pod를 중지하지 못했습니다.
`FailedCreatePodContainer`	Pod contianer를 생성하지 못했습니다.
`실패`	Pod 데이터 디렉터리를 생성하지 못했습니다.
`NetworkNotReady`	네트워크가 준비되지 않았습니다.
`FailedCreate`	생성하는 동안 오류가 발생했습니다(`<error-msg>`).
`SuccessfulCreate`	Pod가 생성되었습니다(`<pod-name>`).
`FailedDelete`	삭제하는 동안 오류가 발생했습니다(`<error-msg>`).
`SuccessfulDelete`	Pod가 삭제되었습니다(`<pod-id>`).

Expand

표 35.10. 수평 Pod 자동 스케일러 이벤트
이름	설명
SelectorRequired	선택기가 필요합니다.
`InvalidSelector`	선택기를 해당 내부 선택기 오브젝트로 변환할 수 없습니다.
`FailedGetObjectMetric`	HPA에서 복제본 수를 계산할 수 없었습니다.
`InvalidMetricSourceType`	알 수 없는 메트릭 소스 유형입니다.
`ValidMetricFound`	HPA에서 복제본 수를 성공적으로 계산할 수 있었습니다.
`FailedConvertHPA`	지정된 HPA를 변환하지 못했습니다.
`FailedGetScale`	HPA 컨트롤러에서 대상의 현재 규모를 가져올 수 없었습니다.
`SucceededGetScale`	HPA 컨트롤러에서 대상의 현재 규모를 가져올 수 있었습니다.
`FailedComputeMetricsReplicas`	나열된 메트릭을 기반으로 원하는 복제본 수를 계산하지 못했습니다.
`FailedRescale`	새 크기: `<size>`, 이유: `<msg>`, 오류: `<error-msg>`
`SuccessfulRescale`	새 크기: `<size>`, 이유: `<msg>`
`FailedUpdateStatus`	상태를 업데이트하지 못했습니다.

Expand

표 35.11. 네트워크 이벤트(openshift-sdn)
이름	설명
`Starting`	OpenShift-SDN을 시작합니다.
`NetworkFailed`	Pod의 네트워크 인터페이스가 손실되어 Pod가 중지됩니다.

Expand

표 35.12. 네트워크 이벤트(kube-proxy)
이름	설명
`NeedPods`	서비스 포트 `<serviceName>:<port>`에 Pod가 필요합니다.

Expand

표 35.13. 볼륨 이벤트
이름	설명
`FailedBinding`	사용 가능한 영구 볼륨이 없으며 스토리지 클래스가 설정되지 않았습니다.
`VolumeMismatch`	볼륨 크기 또는 클래스가 클레임에서 요청한 것과 다릅니다.
`VolumeFailedRecycle`	재생기 Pod를 생성하는 동안 오류가 발생했습니다.
`VolumeRecycled`	볼륨이 재생될 때 발생합니다.
`RecyclerPod`	Pod가 재생될 때 발생합니다.
`VolumeDelete`	볼륨이 삭제될 때 발생합니다.
`VolumeFailedDelete`	볼륨을 삭제할 때 오류가 발생했습니다.
`ExternalProvisioning`	클레임에 대한 볼륨이 수동으로 또는 외부 소프트웨어를 통해 프로비저닝되는 경우 발생합니다.
`ProvisioningFailed`	볼륨을 프로비저닝하지 못했습니다.
`ProvisioningCleanupFailed`	프로비저닝된 볼륨을 정리하는 동안 오류가 발생했습니다.
`ProvisioningSucceeded`	볼륨이 성공적으로 프로비저닝될 때 발생합니다.
`WaitForFirstConsumer`	Pod가 예약될 때까지 바인딩이 지연됩니다.

Expand

표 35.14. 라이프사이클 후크
이름	설명
`FailedPostStartHook`	핸들러에서 Pod를 시작하지 못했습니다.
`FailedPreStopHook`	핸들러에서 사전 정지하지 못했습니다.
`UnfinishedPreStopHook`	사전 정지 후크가 완료되지 않았습니다.

Expand

표 35.15. 배포
이름	설명
`DeploymentCancellationFailed`	배포를 취소하지 못했습니다.
`DeploymentCancelled`	배포가 취소되었습니다.
`DeploymentCreated`	새 복제 컨트롤러가 생성되었습니다.
`IngressIPRangeFull`	서비스에 할당할 수 있는 수신 IP가 없습니다.

Expand

표 35.16. 스케줄러 이벤트
이름	설명
`FailedScheduling`	Pod(`<pod-namespace>/<pod-name>`)를 예약하지 못했습니다. 이 이벤트는 `AssumePodVolumes` 실패, 바인딩 거부 등과 같은 다양한 이유로 발생합니다.
`Preempted`	`<node-name>` 노드의 `<preemptor-namespace>/<preemptor-name>`에 의해 발생합니다.
`Scheduled`	`<pod-name>`을(를) `<node-name>`에 할당했습니다.

Expand

표 35.17. DaemonSet 이벤트
이름	설명
`SelectingAll`	이 데몬 세트는 모든 Pod를 선택합니다. 비어 있지 않은 선택기가 필요합니다.
`FailedPlacement`	`<node-name>`에 Pod를 배치하지 못했습니다.
`FailedDaemonPod`	`<node-name>` 노드에 실패한 데몬 Pod `<pod-name>`이(가) 있어 종료하려고 합니다.

Expand

표 35.18. LoadBalancer 서비스 이벤트
이름	설명
`CreatingLoadBalancerFailed`	로드 밸런서 생성 중 오류가 발생했습니다.
`DeletingLoadBalancer`	로드 밸런서를 삭제하는 중입니다.
`EnsuringLoadBalancer`	로드 밸런서를 확인하는 중입니다.
`EnsuredLoadBalancer`	로드 밸런서를 확인했습니다.
`UnAvailableLoadBalancer`	`LoadBalancer` 서비스에 사용 가능한 노드가 없습니다.
`LoadBalancerSourceRanges`	새 `LoadBalancerSourceRanges`를 나열합니다. 예를 들면 `<old-source-range> → <new-source-range>`입니다.
`LoadbalancerIP`	새 IP 주소를 나열합니다. 예를 들면 `<old-ip> → <new-ip>`입니다.
`ExternalIP`	외부 IP 주소를 나열합니다. 예를 들면 `Added: <external-ip>`입니다.
`UID`	새 UID를 나열합니다. 예를 들면 `<old-service-uid> → <new-service-uid>`입니다.
`externalTrafficPolicy`	새 `ExternalTrafficPolicy`를 나열합니다. 예를 들면 < `old-policy> → <new-ploicy> 입니다`.
`HealthCheckNodePort`	새 `HealthCheckNodePort`를 나열합니다. 예를 들면 `<old-node-port> → <new-node-port>`입니다.
`UpdatedLoadBalancer`	새 호스트로 로드 밸런서를 업데이트했습니다.
`LoadBalancerUpdateFailed`	새 호스트로 로드 밸런서를 업데이트하는 동안 오류가 발생했습니다.
`DeletingLoadBalancer`	로드 밸런서를 삭제하는 중입니다.
`DeletingLoadBalancerFailed`	로드 밸런서를 삭제하는 동안 오류가 발생했습니다.
`DeletedLoadBalancer`	로드 밸런서를 삭제했습니다.

36장. 환경 변수 관리
링크 복사

36.1. 설정 및 설정 해제 환경 변수
링크 복사

OpenShift Container Platform에서는 복제 컨트롤러 또는 배포 구성과 같이 Pod 템플릿이 있는 오브젝트의 환경 변수를 설정하거나 해제하는 oc set env 명령을 제공합니다. Pod의 환경 변수 또는 Pod 템플릿이 있는 오브젝트도 나열할 수 있습니다. 이 명령은 BuildConfig 오브젝트에도 사용할 수 있습니다.

36.2. 환경 변수 나열
링크 복사

Pod 또는 Pod 템플릿의 환경 변수를 나열하려면 다음을 수행합니다.

oc set env <object-selection> --list [<common-options>]

$ oc set env <object-selection> --list [<common-options>]

Copy to Clipboard

Toggle word wrap

이 예에서는 Pod p1 의 모든 환경 변수를 나열합니다.

oc set env pod/p1 --list

$ oc set env pod/p1 --list

Copy to Clipboard

Toggle word wrap

36.3. 환경 변수 설정
링크 복사

Pod 템플릿에서 환경 변수를 설정하려면 다음을 수행합니다.

oc set env <object-selection> KEY_1=VAL_1 ... KEY_N=VAL_N [<set-env-options>] [<common-options>]

$ oc set env <object-selection> KEY_1=VAL_1 ... KEY_N=VAL_N [<set-env-options>] [<common-options>]

Copy to Clipboard

Toggle word wrap

환경 옵션을 설정합니다.

Expand

옵션	설명
`-e, --env=<KEY>=<VAL>`	환경 변수의 지정된 키 값 쌍을 설정합니다.
`--overwrite`	기존 환경 변수 업데이트를 확인합니다.

다음 예제에서 두 명령 모두 배포 구성 레지스트리 의 환경 변수 STORAGE 를 수정합니다. 첫 번째는 값이 /data 인 입니다. 두 번째 업데이트(값: /opt )입니다.

oc set env dc/registry STORAGE=/data
oc set env dc/registry --overwrite STORAGE=/opt

$ oc set env dc/registry STORAGE=/data
$ oc set env dc/registry --overwrite STORAGE=/opt

Copy to Clipboard

Toggle word wrap

다음 예제에서는 이름이 RAILS_ 로 시작하고 서버의 복제 컨트롤러 r1 에 추가하는 현재 쉘에서 환경 변수를 찾습니다.

env | grep RAILS_ | oc set env rc/r1 -e -

$ env | grep RAILS_ | oc set env rc/r1 -e -

Copy to Clipboard

Toggle word wrap

다음 예제에서는 rc.json 파일에 정의된 복제 컨트롤러를 수정하지 않습니다. 대신 업데이트된 환경 STORAGE=/local 을 사용하여 새 파일 rc.yaml 에 YAML 오브젝트를 작성합니다.

oc set env -f rc.json STORAGE=/opt -o yaml > rc.yaml

$ oc set env -f rc.json STORAGE=/opt -o yaml > rc.yaml

Copy to Clipboard

Toggle word wrap

36.3.1. 자동으로 추가된 환경 변수
링크 복사

Expand

표 36.1. 자동으로 추가된 환경 변수
변수 이름
`<SVCNAME>_SERVICE_HOST`
`<SVCNAME>_SERVICE_PORT`

사용 예

TCP 포트 53을 공개하고 클러스터 IP 주소 10.0.0.11이 할당된 서비스 KUBERNETES 는 다음 환경 변수를 생성합니다.

KUBERNETES_SERVICE_PORT=53
MYSQL_DATABASE=root
KUBERNETES_PORT_53_TCP=tcp://10.0.0.11:53
KUBERNETES_SERVICE_HOST=10.0.0.11

KUBERNETES_SERVICE_PORT=53
MYSQL_DATABASE=root
KUBERNETES_PORT_53_TCP=tcp://10.0.0.11:53
KUBERNETES_SERVICE_HOST=10.0.0.11

Copy to Clipboard

Toggle word wrap

참고

oc rsh 명령을 사용하여 컨테이너에 SSH로 연결하고 oc set env 를 실행하여 사용 가능한 모든 변수를 나열합니다.

36.4. 환경 변수 설정 해제
링크 복사

Pod 템플릿에서 환경 변수를 설정 해제하려면 다음을 수행합니다.

oc set env <object-selection> KEY_1- ... KEY_N- [<common-options>]

$ oc set env <object-selection> KEY_1- ... KEY_N- [<common-options>]

Copy to Clipboard

Toggle word wrap

중요

후행 하이픈(-, U+2D)이 필요합니다.

이 예제에서는 배포 구성 d1 에서 환경 변수 ENV1 및 ENV2 를 제거합니다.

oc set env dc/d1 ENV1- ENV2-

$ oc set env dc/d1 ENV1- ENV2-

Copy to Clipboard

Toggle word wrap

이렇게 하면 모든 복제 컨트롤러에서 환경 변수 ENV 가 제거됩니다.

oc set env rc --all ENV-

$ oc set env rc --all ENV-

Copy to Clipboard

Toggle word wrap

이렇게 하면 복제 컨트롤러 r1 의 컨테이너 c1 에서 환경 변수 ENV 가 제거됩니다.

oc set env rc r1 --containers='c1' ENV-

$ oc set env rc r1 --containers='c1' ENV-

Copy to Clipboard

Toggle word wrap

37장. 작업
링크 복사

37.1. 개요
링크 복사

복제 컨트롤러와 달리 작업은 완료할 수 있는 복제본 수가 있는 Pod를 실행합니다. 작업에서는 작업의 전반적인 진행률을 추적하고 활성 상태에 있거나 성공 또는 실패한 Pod에 대한 정보를 사용하여 해당 상태를 업데이트합니다. 작업을 삭제하면 생성된 Pod 복제본이 모두 정리됩니다. 작업은 Kubernetes API의 일부이며 다른 오브젝트 유형과 같이 oc 명령으로 관리할 수 있습니다.

작업에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.

37.2. 작업 생성
링크 복사

작업 구성은 다음 주요 부분으로 구성됩니다.

포드가 생성할 애플리케이션을 설명하는 Pod 템플릿입니다.
작업을 실행해야 하는 병렬로 실행 중인 Pod 복제본 수를 지정하는 선택적 병렬 처리 매개 변수입니다. 지정하지 않으면 기본값은 completions 매개변수의 값입니다.
작업을 실행해야 하는 Pod 수를 지정하는 선택적 completions 매개변수입니다. 지정하지 않으면 이 값은 기본적으로 1로 설정됩니다.

다음은 작업 리소스의 예입니다.

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1    
  completions: 1    
  template:         
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  parallelism: 1

1


  completions: 1

2


  template:

3


    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: OnFailure

4

Copy to Clipboard

Toggle word wrap

작업을 병렬로 실행해야 하는 Pod 복제본 수에 대한 선택적 값입니다. 기본값은 완료입니다.
작업이 완료된 것으로 표시하는 데 필요한 성공적인 Pod 완료 횟수의 선택적 값입니다. 기본값은 1입니다.
컨트롤러에서 생성하는 Pod용 템플릿입니다.
Pod의 재시작 정책입니다. 이 정책은 작업 컨트롤러에 적용되지 않습니다. 자세한 내용은 37.2.1절. “알려진 제한 사항” 를 참조하십시오.

oc run 을 사용하여 단일 명령에서 작업을 생성하고 시작할 수도 있습니다. 다음 명령은 이전 예제에서 지정한 것과 동일한 작업을 생성하고 시작합니다.

oc run pi --image=perl --replicas=1  --restart=OnFailure \
    --command -- perl -Mbignum=bpi -wle 'print bpi(2000)'

$ oc run pi --image=perl --replicas=1  --restart=OnFailure \
    --command -- perl -Mbignum=bpi -wle 'print bpi(2000)'

Copy to Clipboard

Toggle word wrap

37.2.1. 알려진 제한 사항
링크 복사

작업 사양 재시작 정책은 작업 컨트롤러가 아닌Pod에만 적용됩니다. 그러나 작업 컨트롤러는 작업을 완료할 때까지 계속 재시도하도록 하드 코딩되어 있습니다.

따라서 restartPolicy: Never 또는 --restart=Never는 restartPolicy: OnFailure 또는 --restart=OnFailure와 동일하게 작동합니다. 즉 작업이 실패하면 작업이 성공할 때까지 (또는 작업을 수동으로 삭제할 때까지) 자동으로 재시작됩니다. 이 정책은 재시작을 수행하는 하위 시스템만 설정합니다.

Never 정책에서는 작업 컨트롤러에서 재시작을 수행합니다. 시도할 때마다 작업 컨트롤러에서 작업 상태의 실패 수를 늘리고 새 Pod를 생성합니다. 즉 실패할 때마다 Pod 수가 증가합니다.

OnFailure 정책에서는 kubelet에서 재시작을 수행합니다. 시도할 때마다 작업 상태의 실패 횟수가 늘어나는 것은 아닙니다. 또한 kubelet은 동일한 노드에서 Pod를 시작하여 실패한 작업을 재시도합니다.

37.3. 작업 스케일링
링크 복사

oc scale 명령을 --replicas 옵션과 함께 사용하여 작업을 확장하거나 축소할 수 있습니다. 이 경우 작업의 경우 spec.parallelism 매개변수를 수정합니다. 그러면 Pod 복제본 수가 병렬로 실행되고 작업을 실행합니다.

다음 명령은 위의 예제 작업을 사용하고 parallelism 매개변수를 3으로 설정합니다.

oc scale job pi --replicas=3

$ oc scale job pi --replicas=3

Copy to Clipboard

Toggle word wrap

참고

복제 컨트롤러 확장은 또한 --replicas 옵션과 함께 oc scale 명령을 사용하지만 대신 복제 컨트롤러 구성의 replicas 매개 변수를 변경합니다.

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

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

최대 기간은 시스템에서 첫 번째 Pod가 예약되는 시점부터 계산되며 작업을 활성 상태로 유지할 수 있는 기간을 정의합니다. 전체 실행 시간을 추적하며 완료 횟수(작업 실행에 필요한 Pod 복제본 수)와 관련이 없습니다. 지정된 타임아웃에 도달하면 OpenShift Container Platform에서 작업을 종료합니다.

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

  spec:
    activeDeadlineSeconds: 1800

  spec:
    activeDeadlineSeconds: 1800

Copy to Clipboard

Toggle word wrap

37.5. 작업 백오프 실패 정책
링크 복사

구성 또는 기타 유사한 이유로 인해 설정된 재시도 횟수가 설정된 후 작업이 실패로 간주될 수 있습니다. 작업의 재시도 횟수를 지정하려면 .spec.backoffLimit 속성을 설정합니다. 이 필드의 기본값은 6입니다. 작업과 연결된 실패한 Pod는 급격한 백오프 지연(10 초,20 초,40 초)을 6분으로 제한하여 컨트롤러에서 다시 생성합니다. 컨트롤러 확인 중 실패한 새 Pod가 표시되지 않으면 제한이 재설정됩니다.

38장. OpenShift Pipeline
링크 복사

38.1. 개요
링크 복사

OpenShift Pipelines를 사용하면 OpenShift에서 애플리케이션의 빌드, 배포 및 승격을 제어할 수 있습니다. Jenkins Pipeline 빌드 전략, Jenkinsfile 및 OpenShift DSL(Domain Specific Language)(OpenShift Jenkins 클라이언트 플러그인에서 제공하는 OpenShift 도메인 특정 언어)의 조합을 사용하여 모든 시나리오에 대한 고급 빌드, 테스트, 배포 및 승격 파이프라인을 생성할 수 있습니다.

38.2. OpenShift Jenkins Client Plug-in
링크 복사

OpenShift Jenkins 클라이언트 플러그인 은 애플리케이션의 JenkinsFile 내에서 OpenShift DSL을 사용할 수 있도록 Jenkins 마스터에 설치해야 합니다. 이 플러그인은 OpenShift Jenkins 이미지를 사용할 때 기본적으로 설치되고 활성화됩니다.

이 플러그인을 설치 및 구성하는 방법에 대한 자세한 내용은 파이프라인 실행 구성을 참조하십시오.

38.2.1. OpenShift DSL
링크 복사

OpenShift Jenkins 클라이언트 플러그인은 Jenkins 슬레이브에서 OpenShift API와 통신할 수 있는 유창한 DSL을 제공합니다. OpenShift DSL은 Groovy 구문을 기반으로 하며 생성, 빌드, 배포 및 삭제와 같은 애플리케이션의 라이프사이클을 제어하는 방법을 제공합니다.

API에 대한 자세한 내용은 실행 중인 Jenkins 인스턴스 내에서 플러그인의 온라인 문서에 포함됩니다. 이를 찾으려면 다음을 수행합니다.

새 Pipeline Item을 생성합니다.
DSL 텍스트 영역 아래의 파이프라인 구문 을 클릭합니다.
왼쪽 탐색 메뉴에서 글로벌 변수 참조 를 클릭합니다.

38.3. Jenkins Pipeline 전략
링크 복사

프로젝트 내에서 OpenShift Pipeline을 활용하려면 Jenkins 파이프라인 빌드 전략을 사용해야 합니다. 이 전략에서는 기본적으로 소스 리포지토리의 루트에서 jenkinsfile을 사용하지만 다음과 같은 구성 옵션을 제공합니다.

BuildConfig 내의 인라인 jenkinsfile 필드
소스 contextDir 에 상대적으로 사용할 jenkinsfile 의 위치를 참조하는 BuildConfig 내의 jenkinsfilePath 필드입니다.

참고

선택적 jenkinsfilePath 필드는 소스 contextDir에 상대적으로 사용할 파일의 이름을 지정합니다. contextDir이 생략된 경우 기본값은 리포지토리의 루트입니다. jenkinsfilePath가 생략된 경우 기본값은 jenkinsfile입니다.

Jenkins Pipeline 전략에 대한 자세한 내용은 Pipeline Strategy Options 를 참조하십시오.

38.4. Jenkinsfile
링크 복사

jenkinsfile 은 표준 Groovy 언어 구문을 활용하여 애플리케이션의 구성, 빌드 및 배포를 세부적으로 제어할 수 있습니다.

jenkinsfile 은 다음 방법 중 하나로 제공할 수 있습니다.

소스 코드 리포지토리에 있는 파일
jenkinsfile 필드를 사용하여 빌드 구성의 일부로 포함

첫 번째 옵션을 사용하는 경우 다음 위치 중 하나의 애플리케이션 소스 코드 리포지토리에 jenkinsfile을 포함해야 합니다.

리포지토리 루트에 있는 jenkinsfile이라는 파일
리포지토리의 소스 contextDir 루트에 있는 jenkinsfile이라는 파일
BuildConfig의 JenkinsPiplineStrategy 섹션에 있는 jenkinsfilePath 필드를 통해 지정된 파일 이름(제공되는 경우 소스 contextDir 에 상대적인)이며, 그러지 않으면 기본값은 리포지토리의 루트입니다.

jenkinsfile 은 Jenkins 슬레이브 Pod에서 실행됩니다. OpenShift DSL을 사용하려면 OpenShift 클라이언트 바이너리를 사용할 수 있어야 합니다.

38.5. tutorial
링크 복사

Jenkins Pipeline을 사용하여 애플리케이션을 빌드하고 배포하는 전체 단계는 Jenkins Pipeline Tutorial 를 참조하십시오.

38.6. 고급 주제
링크 복사

38.6.1. Jenkins 자동 프로비저닝 비활성화
링크 복사

파이프라인 빌드 구성이 생성되면 OpenShift에서 현재 프로젝트에 프로비저닝된 Jenkins 마스터 Pod가 있는지 확인합니다. Jenkins 마스터를 찾을 수 없으면 자동으로 생성됩니다. 이 동작이 바람직하지 않거나 OpenShift 외부에 Jenkins 서버를 사용하려는 경우 비활성화할 수 있습니다.

자세한 내용은 Pipeline Execution 구성을 참조하십시오.

38.6.2. Slave Pod 구성
링크 복사

Kubernetes 플러그인 은 공식 Jenkins 이미지에도 사전 설치되어 있습니다. 이 플러그인을 사용하면 Jenkins 마스터에서 OpenShift에 슬레이브 Pod를 생성하고 실행 중인 작업을 수행하여 확장성을 달성하고 특정 작업에 대한 특정 런타임을 제공할 수 있습니다.

Kubernetes 플러그인을 사용하여 슬레이브 Pod를 구성하는 방법에 대한 자세한 내용은 Kubernetes 플러그인 을 참조하십시오.

39장. Cron Jobs
링크 복사

39.1. 개요
링크 복사

cron 작업은 작업 실행 방법을 구체적으로 예약할 수 있도록 하여 일반 작업을 기반으로 빌드됩니다. ??? cron 작업은 Kubernetes API의 일부이며 다른 오브젝트 유형과 같이 oc 명령으로 관리할 수 있습니다.

주의

cron 작업에서는 작업 오브젝트를 대략적으로 일정 실행 시간당 한 번 생성하지만, 작업을 생성하지 못하거나 두 개의 작업이 생성될 수 있는 상황이 있습니다. 따라서 작업이 idempotent여야 하며 기록 제한을 구성해야 합니다.

39.2. Cron 작업 생성
링크 복사

cron 작업 구성은 다음 주요 부분으로 구성됩니다.

cron 형식으로 지정된 스케줄입니다.
다음 작업을 생성할 때 사용되는 작업 템플릿입니다.
어떠한 이유로 예약된 시간을 놓치는 경우 작업을 시작하는 선택적 데드라인(초)입니다. 누락된 작업 실행은 실패한 작업으로 간주됩니다. 지정하지 않으면 데드라인이 없습니다.
concurrency Policy: cron 작업 내에서 동시 작업을 처리하는 방법을 지정하는 선택적 동시성 정책입니다. 다음 동시성 정책 중 하나만 지정할 수 있습니다. 지정하지 않는 경우 기본값은 동시 실행을 허용하는 것입니다.
- allow 를 사용하면 Cron Jobs가 동시에 실행될 수 있습니다.
- Forbid는 동시 실행을 금지하고 이전 실행이 아직 완료되지 않은 경우 다음 실행을 건너뜁니다.
- Replace는 현재 실행 중인 작업을 취소하고 새 작업으로 교체합니다.
cron 작업의 중지를 허용하는 선택적 플래그입니다. true로 설정하면 이후의 모든 실행이 일시 중지됩니다.

다음은 CronJob 리소스의 예입니다.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: pi
spec:
  schedule: "*/1 * * * *"  
  jobTemplate:             
    spec:
      template:
        metadata:
          labels:          
            parent: "cronjobpi"
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: OnFailure

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: pi
spec:
  schedule: "*/1 * * * *"

1


  jobTemplate:

2


    spec:
      template:
        metadata:
          labels:

3


            parent: "cronjobpi"
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: OnFailure

4

Copy to Clipboard

Toggle word wrap

작업 스케줄입니다. 이 예제에서는 작업은 분마다 실행됩니다.
작업 템플릿입니다. 이는 작업 예제 와 유사합니다.
이 cron 작업에서 생성한 작업에 라벨을 설정합니다.
Pod의 재시작 정책입니다. 이 정책은 작업 컨트롤러에 적용되지 않습니다. 자세한 내용은 알려진 문제 및 제한을 참조하십시오.

참고

모든 cron 작업 일정 시간은 작업이 시작되는 마스터의 시간대를 기반으로 합니다.

oc run 을 사용하여 단일 명령에서 cron 작업을 생성하고 시작할 수도 있습니다. 다음 명령은 이전 예제에서 지정한 것과 동일한 cron 작업을 생성하고 시작합니다.

oc run pi --image=perl --schedule='*/1 * * * *' \
    --restart=OnFailure --labels parent="cronjobpi" \
    --command -- perl -Mbignum=bpi -wle 'print bpi(2000)'

$ oc run pi --image=perl --schedule='*/1 * * * *' \
    --restart=OnFailure --labels parent="cronjobpi" \
    --command -- perl -Mbignum=bpi -wle 'print bpi(2000)'

Copy to Clipboard

Toggle word wrap

oc run 을 사용하면 --schedule 옵션은 cron 형식의 일정을 허용합니다.

참고

cron 작업을 생성할 때 oc run 은 Never 또는 OnFailure 재시작 정책(--restart)만 지원합니다.

작은 정보

더 이상 필요하지 않은 cron 작업을 삭제합니다.

oc delete cronjob/<cron_job_name>

$ oc delete cronjob/<cron_job_name>

Copy to Clipboard

Toggle word wrap

이렇게 하면 불필요한 아티팩트가 생성되지 않습니다.

39.3. Cron 작업 후 정리
링크 복사

.spec.successfulJobsHistoryLimit 및 .spec.failedJobsHistoryLimit 필드는 선택 사항입니다. 해당 필드는 유지해야 하는 완료된 작업 수 및 실패한 작업 수를 지정합니다. 기본적으로 각각 3과 1로 설정됩니다. 제한을 0으로 설정하면 해당 종류의 작업을 완료한 후 작업을 유지하지 않습니다.

cron 작업에서는 작업 또는 Pod와 같은 아티팩트 리소스를 남겨 둘 수 있습니다. 사용자는 이전 작업과 Pod가 올바르게 정리되도록 기록 제한을 구성하는 것이 중요합니다. 현재 cron 작업 사양 내에는 다음을 담당하는 두 개의 필드가 있습니다.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: pi
spec:
  successfulJobsHistoryLimit: 3 
  failedJobsHistoryLimit: 1     
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
  ...

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: pi
spec:
  successfulJobsHistoryLimit: 3

1


  failedJobsHistoryLimit: 1

2


  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
  ...

Copy to Clipboard

Toggle word wrap

1 1 1: 유지해야 하는 성공적으로 완료한 작업의 수입니다(기본값: 3).
2 2 2: 유지해야 하는 실패한 작업의 수입니다(기본값: 1).

40장. URL에서 생성
링크 복사

40.1. 개요
링크 복사

Create From URL은 이미지 스트림, 이미지 태그 또는 템플릿에서 URL을 구성할 수 있는 기능입니다.

URL에서 생성은 명시적으로 허용 목록에 지정된 네임스페이스의 이미지 스트림 또는 템플릿에서만 작동합니다. 허용 목록에 기본적으로 openshift 네임스페이스가 포함되어 있습니다. 허용 목록에 네임스페이스를 추가하려면 Create from URL Namespace Whitelist를 참조하십시오.

사용자 지정 버튼을 정의할 수 있습니다.

이러한 버튼은 적절한 쿼리 문자열을 사용하여 정의된 URL 패턴을 활용합니다. 사용자에게 프로젝트를 선택하라는 메시지가 표시됩니다. 그런 다음 URL 워크플로우에서 생성이 계속됩니다.

40.2. 이미지 스트림 및 이미지 태그 사용
링크 복사

40.2.1. 쿼리 문자열 매개변수
링크 복사

Expand

이름	설명	필수 항목	스키마	기본값
`imageStream`	사용할 이미지 스트림에 정의된 값 `metadata.name` 입니다.	true	string
`imageTag`	사용할 이미지 스트림에 정의된 `spec.tags.name` 값입니다.	true	string
`namespace`	사용할 이미지 스트림 및 이미지 태그가 포함된 네임스페이스의 이름입니다.	false	string	`openshift`
`name`	이 애플리케이션에 대해 생성된 리소스를 식별합니다.	false	string
`sourceURI`	애플리케이션 소스 코드를 포함하는 Git 리포지토리 URL입니다.	false	string
`sourceRef`	`sourceURI` 에 지정된 애플리케이션 소스 코드에 대한 분기, 태그 또는 커밋입니다.	false	string
`contextDir`	빌드의 컨텍스트 디렉터리로 사용되는 `sourceURI` 에 지정된 애플리케이션 소스 코드의 하위 디렉터리입니다.	false	string

참고

매개변수 값에서 예약된 문자는 URL 인코딩해야 합니다.

40.2.1.1. 예제
링크 복사

 create?imageStream=nodejs&imageTag=4&name=nodejs&sourceURI=https%3A%2F%2Fgithub.com%2Fopenshift%2Fnodejs-ex.git&sourceRef=master&contextDir=%2F

 create?imageStream=nodejs&imageTag=4&name=nodejs&sourceURI=https%3A%2F%2Fgithub.com%2Fopenshift%2Fnodejs-ex.git&sourceRef=master&contextDir=%2F

Copy to Clipboard

Toggle word wrap

40.3. 템플릿 사용
링크 복사

40.3.1. 쿼리 문자열 매개변수
링크 복사

Expand

이름	설명	필수 항목	스키마	기본값
`template`	사용할 템플릿에 정의된 `metadata.name` 의 값입니다.	true	string
`templateParamsMap`	템플릿 매개변수 이름과 재정의하려는 해당 값이 포함된 JSON 매개변수 맵입니다.	false	JSON
`namespace`	사용할 템플릿이 포함된 네임스페이스의 이름입니다.	false	string	`openshift`

참고

매개변수 값에서 예약된 문자는 URL 인코딩해야 합니다.

40.3.1.1. 예제
링크 복사

 create?template=nodejs-mongodb-example&templateParamsMap={"SOURCE_REPOSITORY_URL"%3A"https%3A%2F%2Fgithub.com%2Fopenshift%2Fnodejs-ex.git"}

 create?template=nodejs-mongodb-example&templateParamsMap={"SOURCE_REPOSITORY_URL"%3A"https%3A%2F%2Fgithub.com%2Fopenshift%2Fnodejs-ex.git"}

Copy to Clipboard

Toggle word wrap

41장. 사용자 정의 리소스 정의에서 오브젝트 생성
링크 복사

41.1. Kubernetes 사용자 정의 리소스 정의
링크 복사

Kubernetes API에서 리소스는 특정 종류의 API 오브젝트 컬렉션을 저장하는 끝점입니다. 예를 들어 기본 제공 Pod 리소스에는 Pod 오브젝트 컬렉션이 포함되어 있습니다.

사용자 정의 리소스 는 Kubernetes API를 확장하거나 자체 API를 프로젝트 또는 클러스터에 도입할 수 있는 오브젝트입니다.

CRD( 사용자 정의 리소스 정의 ) 파일은 자체 오브젝트 유형을 정의하고 API 서버에서 전체 라이프사이클을 처리할 수 있도록 합니다.

참고

클러스터 관리자만 CRD를 생성할 수 있지만 CRD에 대한 읽기 및 쓰기 권한이 있는 경우 CRD에서 오브젝트를 생성할 수 있습니다.

41.2. CRD에서 사용자 정의 오브젝트 생성
링크 복사

사용자 지정 오브젝트에는 임의의 JSON 코드가 포함된 사용자 지정 필드가 포함될 수 있습니다.

사전 요구 사항

CRD를 생성합니다.

절차

사용자 지정 오브젝트에 대한 YAML 정의를 생성합니다. 다음 예제 정의에서는 cronSpec 및 image 사용자 정의 필드가 kind CronTab 의 사용자 지정 오브젝트에 설정됩니다. kind는 사용자 정의 리소스 정의 오브젝트의 spec.kind 필드에서 제공됩니다.
사용자 정의 오브젝트의 YAML 파일의 예
```
apiVersion: "stable.example.com/v1" 
kind: CronTab 
metadata:
  name: my-new-cron-object 
  finalizers: 
  - finalizer.stable.example.com
spec: 
  cronSpec: "* * * * /5"
  image: my-awesome-cron-image
```
```
apiVersion: "stable.example.com/v1" 
```
1
```
kind: CronTab 
```
2
```
metadata:
  name: my-new-cron-object 
```
3
```
  finalizers: 
```
4
```
  - finalizer.stable.example.com
spec: 
```
5
```
  cronSpec: "* * * * /5"
  image: my-awesome-cron-image
```
Copy to Clipboard Toggle word wrap
1
사용자 정의 리소스 정의에서 그룹 이름 및 API 버전(이름/버전)을 지정합니다.
2
사용자 정의 리소스 정의에 유형을 지정합니다.
3
오브젝트의 이름을 지정합니다.
4
해당하는 경우 오브젝트의 종료자를 지정합니다. 종료자를 사용하면 컨트롤러에서 오브젝트를 삭제하기 전에 완료해야 하는 조건을 구현할 수 있습니다.
5
오브젝트 유형별 조건을 지정합니다.
오브젝트 파일을 생성한 후 오브젝트를 생성합니다.
```
oc create -f <file-name>.yaml
```
```
oc create -f <file-name>.yaml
```
Copy to Clipboard Toggle word wrap

41.3. 사용자 정의 오브젝트 관리
링크 복사

오브젝트를 생성한 후 사용자 지정 리소스를 관리할 수 있습니다.

사전 요구 사항

CRD(사용자 정의 리소스 정의)를 생성합니다.
CRD에서 오브젝트를 생성합니다.

절차

특정 유형의 사용자 정의 리소스에 대한 정보를 얻으려면 다음을 입력합니다.
```
oc get <kind>
```
```
oc get <kind>
```
Copy to Clipboard Toggle word wrap
예를 들어 다음과 같습니다.
```
oc get crontab

NAME                 KIND
my-new-cron-object   CronTab.v1.stable.example.com
```
```
oc get crontab

NAME                 KIND
my-new-cron-object   CronTab.v1.stable.example.com
```
Copy to Clipboard Toggle word wrap
리소스 이름은 대소문자를 구분하지 않으며 CRD에 정의된 단수형 또는 복수형 양식과 짧은 이름을 사용할 수 있습니다. 예를 들어 다음과 같습니다.
```
oc get crontabs
oc get crontab
oc get ct
```
```
oc get crontabs
oc get crontab
oc get ct
```
Copy to Clipboard Toggle word wrap

사용자 정의 리소스의 원시 YAML 데이터를 볼 수도 있습니다.

oc get <kind> -o yaml

oc get <kind> -o yaml

Copy to Clipboard

Toggle word wrap

oc get ct -o yaml

apiVersion: v1
items:
- apiVersion: stable.example.com/v1
  kind: CronTab
  metadata:
    clusterName: ""
    creationTimestamp: 2017-05-31T12:56:35Z
    deletionGracePeriodSeconds: null
    deletionTimestamp: null
    name: my-new-cron-object
    namespace: default
    resourceVersion: "285"
    selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
    uid: 9423255b-4600-11e7-af6a-28d2447dc82b
  spec:
    cronSpec: '* * * * /5' 
    image: my-awesome-cron-image

oc get ct -o yaml

apiVersion: v1
items:
- apiVersion: stable.example.com/v1
  kind: CronTab
  metadata:
    clusterName: ""
    creationTimestamp: 2017-05-31T12:56:35Z
    deletionGracePeriodSeconds: null
    deletionTimestamp: null
    name: my-new-cron-object
    namespace: default
    resourceVersion: "285"
    selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
    uid: 9423255b-4600-11e7-af6a-28d2447dc82b
  spec:
    cronSpec: '* * * * /5'

1


    image: my-awesome-cron-image

2

Copy to Clipboard

Toggle word wrap

1 2: 오브젝트를 생성하는 데 사용한 YAML의 사용자 정의 데이터가 표시됩니다.

42장. 애플리케이션 메모리 크기 조정
링크 복사

42.1. 개요
링크 복사

이 페이지는 다음에서 OpenShift Container Platform을 사용하는 애플리케이션 개발자에게 지침을 제공하기 위한 것입니다.

컨테이너화된 애플리케이션 구성 요소의 메모리 및 위험 요구 사항을 확인하고 해당 요구 사항에 맞게 컨테이너 메모리 매개변수를 구성합니다.
구성된 컨테이너 메모리 매개변수를 최적으로 준수하도록 컨테이너화된 애플리케이션 런타임(예: OpenJDK)을 구성합니다.
컨테이너에서 실행과 연결된 메모리 관련 오류 조건을 진단 및 해결합니다.

42.2. 배경 정보
링크 복사

계속하기 전에 OpenShift Container Platform에서 컴퓨팅 리소스를 관리하는 방법에 대한 개요를 완전히 확인하는 것이 좋습니다.

애플리케이션 메모리 크기를 조정하는 데 필요한 주요 포인트는 다음과 같습니다.

각 종류의 리소스(메모리, CPU, 스토리지)에 대해 OpenShift Container Platform을 사용하면 선택적 요청 및 제한 값을 Pod의 각 컨테이너에 배치할 수 있습니다. 이 페이지의 목적을 위해, 당사는 메모리 요청 및 메모리 제한에만 관심이 있습니다.
메모리 요청
- 메모리 요청 값을 지정하면 OpenShift Container Platform 스케줄러에 영향을 미칩니다. 스케줄러는 노드에 컨테이너를 예약할 때 메모리 요청을 고려한 다음 컨테이너 사용을 위해 선택한 노드에서 요청된 메모리를 차단합니다.
- 노드의 메모리가 소모되면 OpenShift Container Platform에서 메모리 사용량이 메모리 요청을 가장 많이 초과하는 컨테이너를 제거하는 작업에 우선순위를 부여합니다. 메모리 소모가 심각한 경우 노드 OOM 종료자는 유사한 메트릭을 기반으로 컨테이너에서 프로세스를 선택하고 종료할 수 있습니다.
메모리 제한
- 메모리 제한 값을 지정하면 컨테이너의 모든 프로세스에 할당될 수 있는 메모리에 대한 하드 제한을 제공합니다.
- 컨테이너의 모든 프로세스에서 할당한 메모리가 메모리 제한을 초과하면 노드 OOM 킬러가 즉시 컨테이너의 프로세스를 선택하고 종료합니다.
- 메모리 요청 및 제한을 둘 다 지정하면 메모리 제한 값이 메모리 요청보다 크거나 같아야 합니다.
관리
- 클러스터 관리자는 메모리 요청 값, 제한 값, 둘 또는 둘 다에 대한 할당량을 할당할 수 있습니다.
- 클러스터 관리자는 메모리 요청 값, 제한 값, 둘 또는 둘 다에 대한 기본값을 할당할 수 있습니다.
- 클러스터 관리자는 클러스터 과다 할당을 관리하기 위해 개발자가 지정하는 메모리 요청 값을 덮어쓸 수 있습니다. 이는 예를 들어 OpenShift Online에서 수행됩니다.

42.3. 전략
링크 복사

OpenShift Container Platform에서 애플리케이션 메모리 크기를 조정하는 단계는 다음과 같습니다.

예상되는 컨테이너 메모리 사용량 확인
필요한 경우 경험적으로 예상되는 평균 및 최대 컨테이너 메모리 사용량을 결정합니다(예: 별도의 부하 테스트를 통해). 컨테이너에서 잠재적으로 병렬로 실행될 수 있는 모든 프로세스를 고려해야 합니다(예: 기본 애플리케이션에서 보조 스크립트를 생성하는지의 여부).
위험 유형 확인
제거와 관련된 위험 유형을 확인합니다. 위험 성향이 낮으면 컨테이너는 예상되는 최대 사용량과 백분율로 된 안전 범위에 따라 메모리를 요청해야 합니다. 위험 성향이 높으면 예상되는 사용량에 따라 메모리를 요청하는 것이 더 적합할 수 있습니다.
컨테이너 메모리 요청 설정
위 내용에 따라 컨테이너 메모리 요청을 설정합니다. 요청이 애플리케이션 메모리 사용량을 더 정확하게 나타낼수록 좋습니다. 요청이 너무 높으면 클러스터 및 할당량 사용이 비효율적입니다. 요청이 너무 낮으면 애플리케이션 제거 가능성이 커집니다.
필요한 경우 컨테이너 메모리 제한 설정
필요한 경우 컨테이너 메모리 제한을 설정합니다. 제한을 설정하면 컨테이너에 있는 모든 프로세스의 메모리 사용량 합계가 제한을 초과하는 경우 컨테이너 프로세스가 즉시 종료되는 효과가 있어 이로 인한 장단점이 발생합니다. 다른 한편으로는 예상치 못한 과도한 메모리 사용을 조기에 확인할 수 있습니다(“빠른 실패”). 그러나 이로 인해 프로세스가 갑자기 종료됩니다.
일부 OpenShift Container Platform 클러스터에는 제한 값을 설정해야 할 수 있습니다. 일부는 제한에 따라 요청을 덮어쓸 수 있습니다. 일부 애플리케이션 이미지에서는 요청 값보다 탐지하기 쉬운 설정된 제한 값을 사용합니다.
메모리 제한을 설정하는 경우 예상되는 최대 컨테이너 메모리 사용량과 백분율로 된 안전 범위 이상으로 설정해야 합니다.
애플리케이션이 튜닝되었는지 확인
적절한 경우 구성된 요청 및 제한 값과 관련하여 애플리케이션이 튜닝되었는지 확인합니다. 이 단계는 특히 JVM과 같이 메모리를 풀링하는 애플리케이션과 관련이 있습니다. 이 페이지의 나머지 부분에서는 이 작업에 대해 설명합니다.

42.4. OpenShift Container Platform에서 OpenJDK 크기 조정
링크 복사

기본 OpenJDK 설정은 컨테이너화된 환경에서는 제대로 작동하지 않으며 이로 인해 컨테이너에서 OpenJDK를 실행할 때마다 몇 가지 추가 Java 메모리 설정을 항상 제공해야 합니다.

JVM 메모리 레이아웃은 복잡하고 버전에 따라 다르며 자세한 설명은 이 문서의 범위를 벗어납니다. 그러나 최소한 다음 세 가지 메모리 관련 작업은 컨테이너에서 OpenJDK를 실행하기 위한 시작점으로서 중요합니다.

JVM 최대 힙 크기를 덮어씁니다.
적절한 경우 JVM에서 사용하지 않는 메모리를 운영 체제에 제공하도록 유도합니다.
컨테이너 내의 모든 JVM 프로세스가 적절하게 구성되었는지 확인합니다.

컨테이너에서 실행하기 위해 JVM 워크로드를 최적으로 튜닝하는 것은 이 문서의 범위를 벗어나며 다양한 JVM 옵션을 추가로 설정하는 작업이 포함될 수 있습니다.

42.4.1. JVM 최대 힙 크기 덮어쓰기
링크 복사

대다수의 Java 워크로드에서 JVM 힙은 메모리를 가장 많이 사용하는 단일 소비 항목입니다. 현재 OpenJDK는 기본적으로 OpenJDK가 컨테이너에서 실행되는지의 여부와 관계없이 컴퓨팅 노드 메모리의 최대 1/4(1/-XX:MaxRAMFraction)을 힙에 사용할 수 있도록 허용합니다. 따라서 특히 컨테이너 메모리 제한도 설정된 경우 이 동작을 덮어쓰는 것이 중요합니다.

위 작업은 두 가지 이상의 방법으로 수행할 수 있습니다.

컨테이너 메모리 제한이 설정되어 있고 JVM에서 실험 옵션을 지원하는 경우 -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap을 설정합니다.
이 명령은 -XX:MaxRAM을 컨테이너 메모리 제한으로 설정하고 최대 힙 크기(-XX:MaxHeapSize / -Xmx)를 1/-XX:MaxRAMFraction(기본값: 1/4)으로 설정합니다.
-XX:MaxRAM, -XX:MaxHeapSize 또는 -Xmx 중 하나를 직접 덮어씁니다.
이 옵션을 수행하려면 값을 하드 코딩해야 하지만 안전한 여백을 계산할 수 있다는 장점이 있습니다.

42.4.2. JVM에서 사용되지 않는 메모리를 운영 체제에 릴리스하도록 유도
링크 복사

기본적으로 OpenJDK는 사용하지 않는 메모리를 운영 체제에 적극적으로 반환하지 않습니다. 이는 대다수의 컨테이너화된 Java 워크로드에 적합할 수 있습니다. 그러나 추가 프로세스가 네이티브인지 추가 JVM인지 또는 이 둘의 조합인지와 관계없이 컨테이너 내에서 추가 활성 프로세스가 JVM과 공존하는 워크로드는 주목할 만한 예외입니다.

OpenShift Container Platform Jenkins maven 슬레이브 이미지는 다음 JVM 인수를 사용하여 JVM에서 사용하지 않는 메모리를 운영 체제에 릴리스하도록 유도합니다. -XX: +UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicy90 이러한 인수는 할당된 메모리가 사용 중인 메모리의 110%(-XX:MaxHeapFreeRatio)를 초과할 때마다 힙 메모리를 운영 체제에 반환하기 위한 것으로, 가비지 수집기에서 최대 20%(-XX:GCTimeRatio)의 CPU 시간을 사용합니다. 애플리케이션 힙 할당은 항상 초기 힙 할당(-XX:InitialHeapSize / -Xms로 덮어씀)보다 적지 않습니다. 자세한 내용은 OpenShift에서 Java 풋프린트 튜닝(1부), OpenShift에서 Java 풋프린트 튜닝(2부), OpenJDK 및 컨테이너에서 확인할 수 있습니다.

42.4.3. 컨테이너에서 모든 JVM 프로세스 확인
링크 복사

동일한 컨테이너에서 여러 개의 JVM이 실행되는 경우 모든 JVM이 올바르게 구성되어 있는지 확인해야 합니다. 워크로드가 많은 경우 각 JVM에 백분율로 된 메모리 예산을 부여하여 추가 안전 범위를 충분히 유지해야 합니다.

대다수의 Java 툴에서는 다양한 환경 변수(JAVA_OPTS, GRADLE_OPTS, MAVEN_OPTS 등)를 사용하여 JVM을 구성하며, 올바른 설정을 올바른 JVM에 전달하는 것이 어려울 수 있습니다.

OpenJDK는 항상 JAVA_TOOL_OPTIONS 환경 변수를 준수하고 JAVA_TOOL_OPTIONS에 지정된 값은 JVM 명령줄에 지정된 다른 옵션에서 덮어씁니다. 기본적으로 OpenShift Container Platform Jenkins maven 슬레이브 이미지는 JAVA_TOOL_OPTIONS="-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true" 를 설정하여 이러한 옵션이 기본적으로 슬레이브 이미지에서 실행되도록 합니다. 이러한 설정을 통해 추가 옵션이 필요하지 않다고 보장할 수는 없지만 유용한 시작점이 될 수 있습니다.

42.5. Pod에서 메모리 요청 및 제한 찾기
링크 복사

Pod 내에서 메모리 요청 및 제한을 동적으로 검색하려는 애플리케이션에서는 Downward API를 사용해야 합니다. 다음 코드 조각은 이 작업을 수행하는 방법을 보여줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: fedora:latest
    command:
    - sleep
    - "3600"
    env:
    - name: MEMORY_REQUEST
      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: requests.memory
    - name: MEMORY_LIMIT
      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: limits.memory
    resources:
      requests:
        memory: 384Mi
      limits:
        memory: 512Mi

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: test
    image: fedora:latest
    command:
    - sleep
    - "3600"
    env:
    - name: MEMORY_REQUEST
      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: requests.memory
    - name: MEMORY_LIMIT
      valueFrom:
        resourceFieldRef:
          containerName: test
          resource: limits.memory
    resources:
      requests:
        memory: 384Mi
      limits:
        memory: 512Mi

Copy to Clipboard

Toggle word wrap

oc rsh test
env | grep MEMORY | sort

# oc rsh test
$ env | grep MEMORY | sort
MEMORY_LIMIT=536870912
MEMORY_REQUEST=402653184

Copy to Clipboard

Toggle word wrap

메모리 제한 값은 /sys/fs/cgroup/memory/memory.limit_in_bytes 파일을 통해 컨테이너 내부에서도 확인할 수 있습니다.

42.6. OOM Kill 진단
링크 복사

컨테이너에 있는 모든 프로세스의 총 메모리 사용량이 메모리 제한을 초과하거나 노드 메모리 소모가 심각한 경우 OpenShift Container Platform은 컨테이너의 프로세스를 종료할 수 있습니다.

프로세스가 OOM 종료된 경우 컨테이너가 즉시 종료되지 않을 수 있습니다. 컨테이너 PID 1 프로세스에서 SIGKILL을 수신하면 컨테이너가 즉시 종료됩니다. 그 외에는 컨테이너 동작이 기타 프로세스의 동작에 따라 달라집니다.

컨테이너가 즉시 종료되지 않으면 다음과 같이 OOM 종료를 탐지할 수 있습니다.

코드 137로 종료된 컨테이너 프로세스는 SIGKILL 신호가 수신되었음을 나타냅니다.
/sys/fs/cgroup/memory/memory.oom_control 의 oom_kill 카운터가 증가합니다.

grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
sed -e '' </dev/zero  # provoke an OOM kill
echo $?
grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control

$ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
oom_kill 0
$ sed -e '' </dev/zero  # provoke an OOM kill
Killed
$ echo $?
137
$ grep '^oom_kill ' /sys/fs/cgroup/memory/memory.oom_control
oom_kill 1

Copy to Clipboard

Toggle word wrap

Pod에서 하나 이상의 프로세스가 OOM 종료된 경우 나중에 Pod가 종료되면(즉시 여부와 관계없이) 단계는 실패, 이유는 OOM 종료가 됩니다. restartPolicy 값에 따라 OOM 종료 Pod가 다시 시작될 수 있습니다. 재시작하지 않으면 ReplicationController와 같은 컨트롤러에서 Pod의 실패 상태를 확인하고 새 Pod를 생성하여 이전 Pod를 교체합니다.

재시작하지 않으면 Pod 상태는 다음과 같습니다.

oc get pod test
oc get pod test -o yaml

$ oc get pod test
NAME      READY     STATUS      RESTARTS   AGE
test      0/1       OOMKilled   0          1m

$ oc get pod test -o yaml
...
status:
  containerStatuses:
  - name: test
    ready: false
    restartCount: 0
    state:
      terminated:
        exitCode: 137
        reason: OOMKilled
  phase: Failed

Copy to Clipboard

Toggle word wrap

재시작되는 경우 상태는 다음과 같습니다.

oc get pod test
oc get pod test -o yaml

$ oc get pod test
NAME      READY     STATUS    RESTARTS   AGE
test      1/1       Running   1          1m

$ oc get pod test -o yaml
...
status:
  containerStatuses:
  - name: test
    ready: true
    restartCount: 1
    lastState:
      terminated:
        exitCode: 137
        reason: OOMKilled
    state:
      running:
  phase: Running

Copy to Clipboard

Toggle word wrap

42.7. 제거된 Pod 진단
링크 복사

노드의 메모리가 소모되면 OpenShift Container Platform은 해당 노드에서 Pod를 제거할 수 있습니다. 메모리 소모 범위에 따라 제거가 정상적으로 수행되지 않을 수 있습니다. 정상 제거는 SIGTERM 신호를 수신하는 각 컨테이너의 기본 프로세스(PID 1)를 나타냅니다. 그런 다음 프로세스가 아직 종료되지 않은 경우 SIGKILL 신호를 나중에 표시합니다. 비정상적인 제거에서는 각 컨테이너의 기본 프로세스에서 SIGKILL 신호를 즉시 수신합니다.

제거된 Pod에는 단계 Failed 및 reason Evicted 가 있습니다. restartPolicy 값과 관계없이 재시작되지 않습니다. 그러나 ReplicationController와 같은 컨트롤러는 Pod의 실패 상태를 확인하고 새 Pod를 생성하여 이전 Pod를 교체합니다.

oc get pod test
oc get pod test -o yaml

$ oc get pod test
NAME      READY     STATUS    RESTARTS   AGE
test      0/1       Evicted   0          1m

$ oc get pod test -o yaml
...
status:
  message: 'Pod The node was low on resource: [MemoryPressure].'
  phase: Failed
  reason: Evicted

Copy to Clipboard

Toggle word wrap

OpenShift Container Platform 3.9 개발자 참조

1장. 개요링크 복사링크가 클립보드에 복사되었습니다!

2장. 애플리케이션 라이프 사이클 관리링크 복사링크가 클립보드에 복사되었습니다!

2.1. 개발 프로세스 계획링크 복사링크가 클립보드에 복사되었습니다!

2.1.1. 개요링크 복사링크가 클립보드에 복사되었습니다!

2.1.2. OpenShift Container Platform을 개발 환경으로 사용링크 복사링크가 클립보드에 복사되었습니다!

2.1.3. OpenShift Container Platform에 배포할 애플리케이션 가져오기링크 복사링크가 클립보드에 복사되었습니다!

2.2. 새 애플리케이션 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.1. 개요링크 복사링크가 클립보드에 복사되었습니다!

2.2.2. CLI를 사용하여 애플리케이션 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.1. 소스 코드에서 애플리케이션 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.2. 이미지에서 애플리케이션 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.3. 템플릿에서 애플리케이션 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4. 애플리케이션 생성 추가 수정링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.1. 환경 변수 지정링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.2. 빌드 환경 변수 지정링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.3. 라벨 지정링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.4. 생성 없이 출력 보기링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.5. 다른 이름으로 오브젝트 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.6. 다른 프로젝트에서 오브젝트 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.7. 여러 오브젝트 생성링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.8. 단일 Pod에서 이미지 및 소스 그룹화링크 복사링크가 클립보드에 복사되었습니다!

2.2.2.4.9. 이미지, 템플릿 및 기타 입력 검색링크 복사링크가 클립보드에 복사되었습니다!

2.2.3. 웹 콘솔을 사용하여 애플리케이션 생성링크 복사링크가 클립보드에 복사되었습니다!

2.3. 환경 간 애플리케이션 승격링크 복사링크가 클립보드에 복사되었습니다!

2.3.1. 개요링크 복사링크가 클립보드에 복사되었습니다!

2.3.2. 애플리케이션 구성 요소링크 복사링크가 클립보드에 복사되었습니다!

2.3.2.1. API 오브젝트링크 복사링크가 클립보드에 복사되었습니다!

2.3.2.2. 이미지링크 복사링크가 클립보드에 복사되었습니다!

2.3.2.3. 요약링크 복사링크가 클립보드에 복사되었습니다!

2.3.3. 배포 환경링크 복사링크가 클립보드에 복사되었습니다!

2.3.3.1. 고려 사항링크 복사링크가 클립보드에 복사되었습니다!

2.3.3.2. 요약링크 복사링크가 클립보드에 복사되었습니다!

2.3.4. 방법 및 도구링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.1. API 오브젝트 관리링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.1.1. API 오브젝트 상태 내보내기링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.1.2. API 오브젝트 상태 가져오기링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.1.2.1. 초기 생성링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.1.2.2. 반복적 수정링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2. 이미지 및 이미지 스트림 관리링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.1. 이미지 이동링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.1.1. 태그 환경에서 레지스트리를 공유하는 경우링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.1.2. 태그 환경에서 다른 레지스트리를 사용하는 경우링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.2. 배포링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.3. Jenkins를 사용하여 승격 흐름 자동화링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.4. Egree Caveats링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.4.1. API 오브젝트 참조링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.2.4.2. 이미지 레지스트리 참조링크 복사링크가 클립보드에 복사되었습니다!

2.3.4.3. 요약링크 복사링크가 클립보드에 복사되었습니다!

2.3.5. 시나리오 및 예링크 복사링크가 클립보드에 복사되었습니다!

2.3.5.1. 프로모션에 대한 설정링크 복사링크가 클립보드에 복사되었습니다!

2.3.5.2. 반복 가능한 프로모션 프로세스링크 복사링크가 클립보드에 복사되었습니다!

2.3.5.3. Jenkins를 사용하여 반복 가능한 승격 프로세스링크 복사링크가 클립보드에 복사되었습니다!

3장. 인증링크 복사링크가 클립보드에 복사되었습니다!

3.1. 웹 콘솔 인증링크 복사링크가 클립보드에 복사되었습니다!

3.2. CLI 인증링크 복사링크가 클립보드에 복사되었습니다!

4장. 권한 부여링크 복사링크가 클립보드에 복사되었습니다!

4.1. 개요링크 복사링크가 클립보드에 복사되었습니다!

4.2. 사용자가 Pod를 만들 수 있는지 확인링크 복사링크가 클립보드에 복사되었습니다!

4.3. 인증된 사용자로 수행할 수 있는 작업 확인링크 복사링크가 클립보드에 복사되었습니다!

5장. 프로젝트링크 복사링크가 클립보드에 복사되었습니다!

5.1. 개요링크 복사링크가 클립보드에 복사되었습니다!

5.2. 프로젝트 생성링크 복사링크가 클립보드에 복사되었습니다!

5.2.1. 웹 콘솔 사용링크 복사링크가 클립보드에 복사되었습니다!

5.2.2. CLI 사용링크 복사링크가 클립보드에 복사되었습니다!

5.3. 프로젝트 보기링크 복사링크가 클립보드에 복사되었습니다!

5.4. 프로젝트 상태 확인링크 복사링크가 클립보드에 복사되었습니다!

5.5. 라벨로 필터링링크 복사링크가 클립보드에 복사되었습니다!

5.6. 페이지 번호 표시링크 복사링크가 클립보드에 복사되었습니다!

5.7. 프로젝트 삭제링크 복사링크가 클립보드에 복사되었습니다!

6장. 애플리케이션 마이그레이션링크 복사링크가 클립보드에 복사되었습니다!

6.1. 개요링크 복사링크가 클립보드에 복사되었습니다!

6.2. 데이터베이스 애플리케이션 마이그레이션링크 복사링크가 클립보드에 복사되었습니다!

6.2.1. 개요링크 복사링크가 클립보드에 복사되었습니다!

6.2.2. 지원되는 데이터베이스링크 복사링크가 클립보드에 복사되었습니다!

6.2.3. MySQL링크 복사링크가 클립보드에 복사되었습니다!

6.2.4. PostgreSQL링크 복사링크가 클립보드에 복사되었습니다!

6.2.5. MongoDB링크 복사링크가 클립보드에 복사되었습니다!

6.3. 웹 프레임워크 애플리케이션 마이그레이션링크 복사링크가 클립보드에 복사되었습니다!

1장. 개요
링크 복사

2장. 애플리케이션 라이프 사이클 관리
링크 복사

2.1. 개발 프로세스 계획
링크 복사

2.1.1. 개요
링크 복사

2.1.2. OpenShift Container Platform을 개발 환경으로 사용
링크 복사

2.1.3. OpenShift Container Platform에 배포할 애플리케이션 가져오기
링크 복사

2.2. 새 애플리케이션 생성
링크 복사

2.2.1. 개요
링크 복사

2.2.2. CLI를 사용하여 애플리케이션 생성
링크 복사

2.2.2.1. 소스 코드에서 애플리케이션 생성
링크 복사

2.2.2.2. 이미지에서 애플리케이션 생성
링크 복사

2.2.2.3. 템플릿에서 애플리케이션 생성
링크 복사

2.2.2.4. 애플리케이션 생성 추가 수정
링크 복사

2.2.2.4.1. 환경 변수 지정
링크 복사

2.2.2.4.2. 빌드 환경 변수 지정
링크 복사

2.2.2.4.3. 라벨 지정
링크 복사

2.2.2.4.4. 생성 없이 출력 보기
링크 복사

2.2.2.4.5. 다른 이름으로 오브젝트 생성
링크 복사

2.2.2.4.6. 다른 프로젝트에서 오브젝트 생성
링크 복사

2.2.2.4.7. 여러 오브젝트 생성
링크 복사

2.2.2.4.8. 단일 Pod에서 이미지 및 소스 그룹화
링크 복사

2.2.2.4.9. 이미지, 템플릿 및 기타 입력 검색
링크 복사

2.2.3. 웹 콘솔을 사용하여 애플리케이션 생성
링크 복사

2.3. 환경 간 애플리케이션 승격
링크 복사

2.3.1. 개요
링크 복사

2.3.2. 애플리케이션 구성 요소
링크 복사

2.3.2.1. API 오브젝트
링크 복사

2.3.2.2. 이미지
링크 복사

2.3.2.3. 요약
링크 복사

2.3.3. 배포 환경
링크 복사

2.3.3.1. 고려 사항
링크 복사

2.3.3.2. 요약
링크 복사

2.3.4. 방법 및 도구
링크 복사

2.3.4.1. API 오브젝트 관리
링크 복사

2.3.4.1.1. API 오브젝트 상태 내보내기
링크 복사

2.3.4.1.2. API 오브젝트 상태 가져오기
링크 복사

2.3.4.1.2.1. 초기 생성
링크 복사

2.3.4.1.2.2. 반복적 수정
링크 복사

2.3.4.2. 이미지 및 이미지 스트림 관리
링크 복사

2.3.4.2.1. 이미지 이동
링크 복사

2.3.4.2.1.1. 태그 환경에서 레지스트리를 공유하는 경우
링크 복사

2.3.4.2.1.2. 태그 환경에서 다른 레지스트리를 사용하는 경우
링크 복사

2.3.4.2.2. 배포
링크 복사

2.3.4.2.3. Jenkins를 사용하여 승격 흐름 자동화
링크 복사

2.3.4.2.4. Egree Caveats
링크 복사

2.3.4.2.4.1. API 오브젝트 참조
링크 복사

2.3.4.2.4.2. 이미지 레지스트리 참조
링크 복사

2.3.4.3. 요약
링크 복사

2.3.5. 시나리오 및 예
링크 복사

2.3.5.1. 프로모션에 대한 설정
링크 복사

2.3.5.2. 반복 가능한 프로모션 프로세스
링크 복사

2.3.5.3. Jenkins를 사용하여 반복 가능한 승격 프로세스
링크 복사

3장. 인증
링크 복사

3.1. 웹 콘솔 인증
링크 복사

3.2. CLI 인증
링크 복사

4장. 권한 부여
링크 복사

4.1. 개요
링크 복사

4.2. 사용자가 Pod를 만들 수 있는지 확인
링크 복사

4.3. 인증된 사용자로 수행할 수 있는 작업 확인
링크 복사

5장. 프로젝트
링크 복사

5.1. 개요
링크 복사

5.2. 프로젝트 생성
링크 복사

5.2.1. 웹 콘솔 사용
링크 복사

5.2.2. CLI 사용
링크 복사

5.3. 프로젝트 보기
링크 복사

5.4. 프로젝트 상태 확인
링크 복사

5.5. 라벨로 필터링
링크 복사

5.6. 페이지 번호 표시
링크 복사

5.7. 프로젝트 삭제
링크 복사

6장. 애플리케이션 마이그레이션
링크 복사

6.1. 개요
링크 복사

6.2. 데이터베이스 애플리케이션 마이그레이션
링크 복사

6.2.1. 개요
링크 복사

6.2.2. 지원되는 데이터베이스
링크 복사

6.2.3. MySQL
링크 복사

6.2.4. PostgreSQL
링크 복사

6.2.5. MongoDB
링크 복사

6.3. 웹 프레임워크 애플리케이션 마이그레이션
링크 복사

6.3.1. 개요
링크 복사

6.3.2. Python
링크 복사