이미지

Cluster Samples Operator는 기본적으로 또는 글로벌 프록시가 구성된 경우 Managed 상태로 부트 스트랩됩니다. Managed 상태에서는 Cluster Samples Operator가 레지스트리에서 샘플 이미지 스트림과 이미지를 가져오고 필수 샘플 템플릿이 설치되었는지 확인하기 위해 적극적으로 리소스를 관리하며 구성 요소를 활성 상태로 유지합니다.

Cluster Samples Operator가 Removed으로 부트 스트랩되는 상황은 다음과 같습니다.

그러나 Cluster Samples Operator가 IPv6 네트워크에 있고 OpenShift Container Platform 글로벌 프록시가 구성되어 있음을 탐지하면 IPv6 검사가 모든 검사를 대체합니다. 결과적으로 Cluster Samples Operator가 자체적으로 Removed 로 부트스트랩합니다.

apiVersion: samples.operator.openshift.io/v1
kind: Config
metadata:
  name: cluster
spec:
  architectures:
  - x86_64
  managementState: Removed

샘플 이미지 스트림을 생성하거나 업데이트한 후 Cluster Samples Operator는 각 이미지 스트림 태그의 이미지 가져오기 진행 상황을 모니터링합니다.

가져오기에 실패하거나, Cluster Samples Operator 구성이 변경되어 해당 이미지 스트림이 skippedImagestreams 목록에 추가되거나, 관리 상태가 Removed로 변경되는 경우 Cluster Samples Operator는 oc import-image 명령에서 사용하는 것과 동일한 이미지 스트림 이미지 가져오기 API를 통해 가져오기가 성공할 때까지 약 15분마다 가져오기를 다시 시도합니다.

추가 리소스

설치 프로세스 중에 OpenShift Container Platform은 openshift-cluster-samples-operator 네임스페이스에 imagestreamtag-to-image라는 구성 맵을 생성합니다. imagestreamtag-to-image 구성 맵에는 각 이미지 스트림 태그에 대한 이미지 채우기 항목이 포함되어 있습니다.

구성 맵의 데이터 필드에 있는 각 항목의 키 형식은 <image_stream_name>_<image_stream_tag_name>입니다.

OpenShift Container Platform의 연결이 끊긴 설치 프로세스 중에 Cluster Samples Operator의 상태가 Removed로 설정됩니다. Managed로 변경하려면 샘플이 설치됩니다.

이 구성 맵을 사용하여 이미지 스트림을 가져오려면 이미지를 미러링해야 하는 이미지 참조로 사용할 수 있습니다.

자세한 내용은 대체 레지스트리 또는 미러링된 레지스트리에서 Cluster Samples Operator 이미지 스트림 사용을 참조하십시오.

Cluster Samples Operator에서 여러 아키텍처 지원을 시작하면 Managed 상태에서는 아키텍처 목록을 변경할 수 없습니다.

아키텍처 값을 변경하려면 클러스터 관리자가 다음 작업을 수행해야 합니다.

Cluster Samples Operator는 Removed 상태에서도 여전히 시크릿을 처리합니다. Removed 로 전환하기 전에, Managed로 전환하기 전에 Removed 또는 Managed 상태로 전환한 후 시크릿을 생성할 수 있습니다. Managed로 전환한 후 시크릿을 생성하면 시크릿 이벤트가 처리될 때까지 샘플 생성이 지연됩니다. 이 경우 전환하기 전에 모든 샘플을 제거하도록 선택하여 레지스트리 변경을 원활하게 수행할 수 있습니다. 전환 전에 모든 샘플을 제거할 필요는 없습니다.

샘플 리소스는 다음 조건을 해당 상태에서 유지보수합니다.

미러 레지스트리를 생성하려면 먼저 미러 호스트를 준비해야 합니다.

명령줄 인터페이스를 사용하여 OpenShift Container Platform과 상호 작용하기 위해 OpenShift CLI(oc)를 설치할 수 있습니다. Linux, Windows 또는 macOS에 oc를 설치할 수 있습니다.

Linux에서 OpenShift CLI 설치

다음 절차를 사용하여 Linux에서 OpenShift CLI(oc) 바이너리를 설치할 수 있습니다.

OpenShift CLI를 설치한 후 oc 명령을 사용할 수 있습니다.

$ oc <command>

Windows에서 OpenSfhit CLI 설치

다음 절차에 따라 Windows에 OpenShift CLI(oc) 바이너리를 설치할 수 있습니다.

OpenShift CLI를 설치한 후 oc 명령을 사용할 수 있습니다.

C:\> oc <command>

macOS에 OpenShift CLI 설치

다음 절차에 따라 macOS에서 OpenShift CLI(oc) 바이너리를 설치할 수 있습니다.

OpenShift CLI를 설치한 후 oc 명령을 사용할 수 있습니다.

$ oc <command>

설치 프로세스 중에 OpenShift Container Platform은 openshift-cluster-samples-operator 네임스페이스에 imagestreamtag-to-image라는 구성 맵을 생성합니다. imagestreamtag-to-image 구성 맵에는 각 이미지 스트림 태그에 대한 이미지 채우기 항목이 포함되어 있습니다.

구성 맵의 데이터 필드에 있는 각 항목의 키 형식은 <image_stream_name>_<image_stream_tag_name>입니다.

OpenShift Container Platform의 연결이 끊긴 설치 프로세스 중에 Cluster Samples Operator의 상태가 Removed로 설정됩니다. Managed로 변경하려면 샘플이 설치됩니다.

이 구성 맵을 사용하여 이미지 스트림을 가져오려면 이미지를 미러링해야 하는 이미지 참조로 사용할 수 있습니다.

자세한 내용은 대체 레지스트리 또는 미러링된 레지스트리에서 Cluster Samples Operator 이미지 스트림 사용을 참조하십시오.

다음 지침은 이미지가 OpenShift Container Platform에서 사용되는지 여부와 상관없이 일반적인 컨테이너 이미지를 생성하는 경우 적용됩니다.

이미지 재사용

가능한 경우 이미지는 FROM 문을 사용하는 적절한 업스트림 이미지를 기반으로 합니다. 이렇게 하면 이미지가 업데이트되는 경우 사용자가 직접 종속성을 업데이트할 필요 없이 이미지가 업스트림 이미지의 보안 수정 사항을 쉽게 찾을 수 있습니다.

또한 FROM 명령어에 태그 (예: rhel:rhel7)를 사용하여 해당 이미지의 기반이 되는 이미지 버전을 사용자에게 정확히 알려 주십시오. latest 이외의 태그를 사용하면 손상을 유발하는 변경사항이 이미지에 적용되어 latest 버전의 업스트림 이미지에 포함되는 일이 없습니다.

태그 내에서 호환성 유지보수

자체 이미지를 태그하는 경우 태그 내에서 이전 버전과의 호환성을 유지보수합니다. 예를 들어 foo라는 이미지를 제공하는데 버전 1.0이 현재 포함되어 있는 경우 foo:v1 태그를 제공할 수 있습니다. 이미지를 업데이트하면 원본 이미지와 계속 호환되는 한 새 이미지 foo:v1을 계속 태그할 수 있으며 이 태그의 다운스트림 사용자는 손상 없이 업데이트를 가져올 수 있습니다.

나중에 호환되지 않는 업데이트를 릴리스하는 경우 새 태그(예: foo:v2)로 전환해야 합니다. 이렇게 하면 다운스트림 사용자가 마음대로 새 버전으로 이동하면서도 호환되지 않는 새 이미지로 인해 의도치 않게 손상되는 일이 없게 할 수 있습니다. foo:latest를 사용하는 모든 다운스트림 사용자는 호환되지 않는 변경이 적용될 위험을 감수하게 됩니다.

여러 프로세스 방지

하나의 컨테이너에서 데이터베이스 및 SSHD 같은 서비스를 여러 개 시작하지 마십시오. 컨테이너는 간단하며 쉽게 서로 연결하여 여러 프로세스를 오케스트레이션할 수 있으므로 그렇게 할 필요가 없습니다. OpenShift Container Platform을 사용하면 관련 이미지를 단일 pod로 그룹화하여 쉽게 공동 배치하고 공동 관리할 수 있습니다.

컨테이너는 이러한 공동 배치를 통해 통신에 필요한 네트워크 네임스페이스 및 스토리지를 공유할 수 있습니다. 각 이미지를 덜 자주, 독립적으로 업데이트할 수 있으므로 업데이트에서도 중단이 덜 발생합니다. 생성된 프로세스에 대한 라우팅 신호를 관리할 필요가 없으므로 단일 프로세스를 사용하면 신호 처리 흐름이 더욱 명확해집니다.

래퍼 스크립트에 exec 사용

많은 이미지에서는 소프트웨어 실행을 위한 프로세스를 시작하기 전에 래퍼 스크립트를 사용하여 설정을 수행합니다. 이미지에서 이러한 스크립트를 사용하는 경우 해당 스크립트는 exec를 사용하여 소프트웨어가 스크립트 프로세스를 교체하도록 합니다. exec를 사용하지 않으면 컨테이너 런타임에서 보낸 신호가 소프트웨어 프로세스가 아닌 래퍼 스크립트로 갑니다. 이는 원하는 작동이 아닙니다.

어떤 서버의 프로세스를 시작하는 래퍼 스크립트가 있는 경우입니다. 예를 들어 podman run -i를 사용하여 컨테이너를 시작하여 래퍼 스크립트를 실행하면 프로세스가 시작됩니다. CTRL+C를 사용하여 컨테이너를 종료하려 하려는 경우입니다. 래퍼 스크립트에서 exec를 사용하여 서버 프로세스를 시작한 경우 podman 은 SIGINT를 서버 프로세스로 보내며 모든 작업이 예상대로 수행됩니다. 래퍼 스크립트에서 exec를 사용하지 않은 경우 podman은 래퍼 스크립트의 프로세스로 SIGINT를 보내며 프로세스는 아무 일도 없던 것처럼 계속 실행됩니다.

또한 프로세스는 컨테이너에서 실행되는 경우 PID 1로 실행됩니다. 즉, 기본 프로세스가 종료되면 전체 컨테이너가 중지되어 PID 1 프로세스에서 시작한 하위 프로세스가 모두 취소됩니다.

임시 파일 정리

빌드 프로세스 중에 생성한 임시 파일을 모두 제거합니다. 이러한 파일에는 ADD 명령으로 추가된 파일도 포함됩니다. 예를 들어 yum install 작업을 수행한 후에는 yum clean 명령을 실행합니다.

다음과 같이 RUN 문을 생성하면 yum 캐시가 이미지 계층에 생성되는 것을 방지할 수 있습니다.

RUN yum -y install mypackage && yum -y install myotherpackage && yum clean all -y

이 문을 다음과 같이 작성할 수도 있습니다.

RUN yum -y install mypackage
RUN yum -y install myotherpackage && yum clean all -y

그러면 첫 번째 yum 호출에서 해당 계층에 추가 파일을 남기는데 나중에 yum clean 작업을 실행해도 해당 파일을 제거할 수 없습니다. 추가 파일이 최종 이미지에 표시되지 않아도 기본 계층에 남아 있습니다.

현재 컨테이너 빌드 프로세스에서는 이전 계층에서 어떤 항목을 제거한 경우에도 이후 계층에서 명령을 실행하여 이미지가 사용하는 공간을 줄일 수 없습니다. 향후에는 변경될 수도 있습니다. 즉, 이후 계층에서 rm 명령을 수행하는 경우 파일이 숨겨져 있어도 다운로드할 이미지의 전체 크기가 줄어들지 않습니다. 따라서 yum clean 예에서처럼 가능한 경우 파일을 생성한 명령과 동일한 명령에서 파일을 제거하여 계층에 쓰이지 않도록 하는 것이 가장 좋습니다.

또한 단일 RUN 문에서 여러 명령을 수행하면 이미지의 계층 수가 줄어들어 다운로드 및 추출 시간이 단축됩니다.

적절한 순서로 명령어 배치

컨테이너 빌더에서는 Dockerfile을 읽고 맨 위부터 아래로 명령어를 실행합니다. 성공적으로 실행되는 모든 명령은 다음에 이 이미지 또는 다른 이미지가 빌드될 때 재사용할 수 있는 계층을 생성합니다. Dockerfile의 맨 위에는 거의 변경되지 않을 명령어를 배치하는 것이 매우 중요합니다. 이렇게 하면 상위 계층 변경에 의해 캐시가 무효화되지 않으므로 다음에 동일한 이미지를 매우 빠르게 빌드할 수 있습니다.

예를 들어 반복할 파일을 설치하는 ADD 명령과 패키지를 yum install하는 RUN 명령이 포함된 Dockerfile에서 작업하는 경우 다음과 같이 ADD 명령을 마지막에 배치하는 것이 가장 좋습니다.

FROM foo
RUN yum -y install mypackage && yum clean all -y
ADD myfile /test/myfile

이렇게 하면 myfile을 편집하고 podman build 또는 docker build를 다시 실행할 때마다 시스템은 yum 명령에는 캐시된 계층을 재사용하고 ADD 작업에서만 새 계층을 생성합니다.

그러지 않고 다음과 같이 Dockerfile을 작성할 수 있습니다.

FROM foo
ADD myfile /test/myfile
RUN yum -y install mypackage && yum clean all -y

그러면 myfile을 변경하고 podman build 또는 docker build를 다시 실행할 때마다 ADD 작업으로 RUN 계층 캐시가 무효화되어 yum 작업도 다시 실행해야 합니다.

중요한 포트 표시

EXPOSE 명령어는 컨테이너의 포트를 호스트 시스템 및 다른 컨테이너에서 사용할 수 있도록 합니다. podman run 호출을 통해 포트가 노출되도록 지정할 수 있으나 Dockerfile에 EXPOSE 명령어를 사용하면 소프트웨어를 실행하는 데 필요한 포트를 명시적으로 선언하여 사용자 및 소프트웨어 둘 다 더욱 쉽게 이미지를 사용할 수 있습니다.

환경 변수 설정

ENV 명령어로 환경 변수를 설정하는 것이 좋습니다. 한 예로 프로젝트 버전 설정이 있습니다. 이렇게 하면 사용자가 Dockerfile을 보지 않고도 쉽게 버전을 찾을 수 있습니다. 또 다른 예로는 JAVA_HOME 같은 다른 프로세스에서 사용할 수 있는 시스템의 경로 알림이 있습니다.

기본 암호 설정 방지

기본 암호를 설정하지 않도록 합니다. 많은 사용자가 이미지를 확장한 후 기본 암호를 제거하거나 변경하는 것을 잊어 버립니다. 이렇게 되면 프로덕션 단계의 사용자에게 잘 알려진 암호가 할당되는 경우 보안 문제로 이어질 수 있습니다. 암호는 환경 변수를 사용하여 구성할 수 있습니다.

기본 암호를 설정하도록 선택하는 경우 컨테이너가 시작될 때 적절한 경고 메시지가 표시되도록 해야 합니다. 이 메시지에서는 사용자에게 기본 암호 값을 알려주고 설정할 환경 변수와 같은 암호 변경 방법을 설명해야 합니다.

sshd 실행 방지

이미지에서는 sshd를 실행하지 않는 것이 가장 좋습니다. podman exec 또는 docker exec 명령을 사용하여 로컬 호스트에서 실행 중인 컨테이너에 액세스할 수 있습니다. 또는 oc exec 명령 또는 oc rsh 명령을 사용하여 OpenShift Container Platform 클러스터에서 실행 중인 컨테이너에 액세스할 수 있습니다. 이미지에서 sshd를 설치하고 실행하면 추가적인 공격 벡터와 보안 패치 요구 사항이 발생합니다.

영구 데이터 볼륨 사용

이미지에서는 영구 데이터 볼륨을 사용합니다. 이렇게 하면 OpenShift Container Platform에서 컨테이너를 실행하는 노드에 네트워크 스토리지를 마운트하며 컨테이너가 새 노드로 이동하면 해당 노드에 이 스토리지가 다시 연결됩니다. 모든 영구 스토리지 요구에 이 볼륨을 사용하면 컨테이너를 다시 시작하거나 이동해도 콘텐츠가 보존됩니다. 이미지가 컨테이너 내 임의의 위치에 데이터를 쓰는 경우 해당 콘텐츠를 보존할 수 없습니다.

컨테이너가 삭제된 후에도 보존해야 하는 데이터는 모두 볼륨에 써야 합니다. 컨테이너 엔진은 컨테이너의 ephemeral 스토리지에 데이터를 쓰지 않는 모범 사례를 엄격하게 적용하기 위해 사용할 수 있는 readonly 플래그를 컨테이너에서 지원합니다. 지금 이 기능을 기반으로 이미지를 설계하면 나중에 더욱 쉽게 이미지를 활용할 수 있습니다.

Dockerfile에서 명시적으로 볼륨을 정의하면 이미지 사용자가 이미지를 실행할 때 정의해야 하는 볼륨을 쉽게 파악할 수 있습니다.

OpenShift Container Platform에서 볼륨을 사용하는 방법에 대한 자세한 내용은 Kubernetes 문서를 참조하십시오.

다음은 특별히 OpenShift Container Platform에서 사용할 컨테이너 이미지를 생성하는 경우 적용되는 지침입니다.

RUN chgrp -R 0 /some/directory && \
    chmod -R g=u /some/directory

Dockerfile에서 LABEL 명령어를 사용하여 이미지 메타데이터를 정의할 수 있습니다. 레이블은 이미지 또는 컨테이너에 연결된 키 값 쌍이라는 점에서 환경 변수와 유사합니다. 레이블은 실행 중인 애플리케이션에 표시되지 않으며 이미지 및 컨테이너를 빠르게 조회하는 데 사용될 수 있다는 점에서 환경 변수와 다릅니다.

LABEL 명령어에 대한 자세한 내용은 Docker 문서를 참조하십시오.

레이블 이름은 일반적으로 네임스페이스가 지정됩니다. 레이블을 찾아 사용할 프로젝트를 반영하여 네임스페이스를 적절히 설정해야 합니다. OpenShift Container Platform의 경우 네임스페이스는 io.openshift로 설정되어야 하며 Kubernetes의 경우 네임스페이스는 io.k8s입니다.

형식에 대한 자세한 내용은 Docker 사용자 정의 메타데이터 문서를 참조하십시오.

LABEL io.openshift.tags   mongodb,mongodb24,nosql

LABEL io.openshift.wants   mongodb,redis

LABEL io.k8s.description The MySQL 5.5 Server with master-slave replication support

LABEL io.openshift.non-scalable     true

LABEL io.openshift.min-memory 16Gi
LABEL io.openshift.min-cpu     4

빌드 프로세스는 최종 컨테이너 이미지로 통합되는 다음 세 가지 기본 요소로 구성됩니다.

S2I는 첫 번째 FROM 명령으로 빌더 이미지가 포함된 Dockerfile을 생성합니다. 그런 다음 S2I에서 생성된 Dockerfile은 Buildah로 전달됩니다.

스크립트를 빌더 이미지 내에서 실행할 수 있는 경우 모든 프로그래밍 언어로 S2I(Source-to-Image) 스크립트를 작성할 수 있습니다. S2I는 assemble/run/save-artifacts 스크립트를 제공하는 다양한 옵션을 지원합니다. 이러한 위치는 모두 다음 순서에 따라 각 빌드에서 확인합니다.

이미지에 지정된 io.openshift.s2i.scripts-url 라벨과 빌드 구성에 지정된 스크립트 모두 다음 양식 중 하나를 취할 수 있습니다.

S2I 스크립트의 예

다음 예제 S2I 스크립트는 Bash로 작성됩니다. 각 예에서는 tar 콘텐츠가 /tmp/s2i 디렉터리에 압축 해제되어 있다고 가정합니다.

#!/bin/bash

# restore build artifacts
if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then
    mv /tmp/s2i/artifacts/* $HOME/.
fi

# move the application source
mv /tmp/s2i/src $HOME/src

# build application artifacts
pushd ${HOME}
make all

# install the artifacts
make install
popd

#!/bin/bash

# run the application
/opt/application/run.sh

#!/bin/bash

pushd ${HOME}
if [ -d deps ]; then
    # all deps contents to tar stream
    tar cf - deps
fi
popd

#!/bin/bash

# inform the user how to use the image
cat <<EOF
This is a S2I sample builder image, to use it, install
https://github.com/openshift/source-to-image
EOF

test 스크립트의 표준 위치는 test/run입니다. 이 스크립트는 OpenShift Container Platform S2I 이미지 빌더에 의해 호출되며 간단한 Bash 스크립트일 수도 있고 정적 Go 바이너리일 수도 있습니다.

test/run 스크립트는 S2I 빌드를 수행하므로 $PATH에서 S2I 바이너리를 사용할 수 있어야 합니다. 필요한 경우 S2I README의 설치 지침을 따르십시오.

S2I는 애플리케이션 소스 코드와 빌더 이미지를 결합하므로 테스트를 하려면 소스가 실행 가능한 컨테이너 이미지로 변환되는지 확인할 샘플 애플리케이션 소스가 있어야 합니다. 샘플 애플리케이션은 단순하되 assemble 및 run 스크립트의 중요한 단계를 수행해야 합니다.

S2I 도구는 새로운 S2I 이미지 생성 프로세스를 더욱 빠르게 수행할 수 있도록 강력한 생성 도구와 함께 제공됩니다. s2i create 명령에서는 모든 필요한 S2I 스크립트와 테스트 도구를 Makefile과 함께 생성합니다.

$ s2i create _<image name>_ _<destination directory>_

생성된 test/run 스크립트는 유용하게 조정되어야 하지만 개발을 시작하기에 좋은 시작점을 제공합니다.

S2I 이미지 테스트를 로컬에서 실행하는 가장 쉬운 방법은 생성된 Makefile을 사용하는 것입니다.

s2i create 명령을 사용하지 않은 경우 다음 Makefile 템플릿을 복사하고 IMAGE_NAME 매개변수를 이미지 이름으로 교체할 수 있습니다.

IMAGE_NAME = openshift/ruby-20-centos7
CONTAINER_ENGINE := $(shell command -v podman 2> /dev/null | echo docker)

build:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME) .

.PHONY: test
test:
	${CONTAINER_ENGINE} build -t $(IMAGE_NAME)-candidate .
	IMAGE_NAME=$(IMAGE_NAME)-candidate test/run

test 스크립트에서는 테스트할 이미지를 이미 빌드했다고 가정합니다. 필요한 경우 먼저 S2I 이미지를 빌드합니다. 다음 명령 중 하나를 실행합니다.

다음 단계에서는 S2I 이미지 빌더를 테스트하는 기본 워크플로를 설명합니다.

일반적으로 이러한 단계를 실행하면 빌더 이미지가 예상대로 작동하는지 충분히 확인할 수 있습니다.

새로운 S2I 빌더 이미지를 구성하는 Dockerfile 및 기타 아티팩트가 있으면 git 리포지터리에 배치한 후 OpenShift Container Platform을 사용하여 이미지를 빌드하고 푸시할 수 있습니다. 리포지터리를 가리키는 Docker 빌드를 정의합니다.

OpenShift Container Platform 인스턴스가 공용 IP 주소에서 호스트된 경우 S2I 빌더 이미지 GitHub 리포지터리로 푸시할 때마다 빌드가 트리거될 수 있습니다.

ImageChangeTrigger를 사용하면 업데이트된 S2I 빌더 이미지를 기반으로 하는 애플리케이션의 다시 빌드를 트리거할 수도 있습니다.

이미지 스트림은 태그로 식별되는 임의 숫자의 컨테이너 이미지로 구성됩니다. 컨테이너 이미지 리포지터리와 유사하게 관련 이미지에 대한 단일 가상 뷰를 제공합니다.

빌드 및 배포는 이미지 스트림을 모니터링하다가 새 이미지가 추가되거나 이미지가 수정되면 알림을 받고 빌드 또는 배포를 수행하여 각각에 대응할 수 있습니다.

이미지 태그는 리포지터리의 컨테이너 이미지에 적용되는 레이블로, 이미지 스트림에서 특정 이미지를 다른 이미지와 구별하는 역할을 합니다. 일반적으로 태그는 일종의 버전 번호를 나타냅니다. 예를 들어 다음에서는 :v3.11.59-2가 태그입니다.

registry.access.redhat.com/openshift3/jenkins-2-rhel7:v3.11.59-2

이미지에 태그를 더 추가할 수 있습니다. 예를 들어 이미지에 :v3.11.59-2 및 :latest 태그가 할당될 수 있습니다.

OpenShift Container Platform은 docker tag 명령과 유사하지만 이미지가 아닌 이미지 스트림에서 작동하는 oc tag 명령을 제공합니다.

이미지는 시간이 지남에 따라 개선되며 해당 태그를 사용하여 이러한 개선을 반영합니다. 일반적으로 이미지 태그는 항상 빌드된 최신 이미지를 가리킵니다.

v2.0.1-may-2019와 같이 태그 이름에 너무 많은 정보가 포함되어 있으면 태그는 이미지의 한 버전만 가리키며 업데이트되지 않습니다. 기본 이미지 정리 옵션을 사용하는 경우 이러한 이미지는 절대 제거되지 않습니다. 크기가 매우 큰 클러스터에서는 모든 수정된 이미지에 대한 새로운 태그 생성 스키마가 아주 오래된 이미지에 대한 초과 태그 메타데이터로 etcd 데이터 저장소를 채울 수 있습니다.

태그 이름이 v2.0이면 이미지가 수정될 가능성이 높습니다. 그러면 태그 기록이 길어지고, 따라서 이미지 정리기가 오래되고 사용되지 않는 이미지를 제거할 가능성이 높습니다.

태그 이름 지정 규칙은 사용자가 결정하지만 아래에서 <image_name>:<image_tag> 형식으로 된 몇 가지 예를 볼 수 있습니다.

태그 이름에 날짜가 필요한 경우 오래되고 지원되지 않는 이미지와 istags를 정기적으로 검사하여 제거하십시오. 그러지 않으면 오래된 이미지 유지로 인해 리소스 사용량이 증가할 수 있습니다.

OpenShift Container Platform의 이미지 스트림은 태그로 식별되는 0개 이상의 컨테이너 이미지로 구성됩니다.

사용할 수 있는 태그 유형은 다양합니다. 기본 동작에서는 시간의 특정 이미지를 가리키는 permanent 태그를 사용합니다. permanent 태그가 사용 중이고 소스가 변경되는 경우 대상에 대해 태그가 변경되지 않습니다.

tracking 태그는 소스 태그를 가져오는 동안 대상 태그의 메타데이터가 업데이트되었음을 나타냅니다.

이미지 스트림에서 태그를 제거할 수 있습니다.

태그를 사용하면 다음 참조 유형이 사용된 이미지 스트림의 이미지를 참조할 수 있습니다.

이미지 스트림 정의 예를 보면 ImageStreamTag 정의와 DockerImage에 대한 참조는 포함되어 있으나 ImageStreamImage와 관련된 항목은 포함되어 있지 않음을 알 수 있습니다.

이미지 스트림으로 이미지를 가져오거나 태그하는 경우 ImageStreamImage 오브젝트가 OpenShift Container Platform에서 자동으로 생성되기 때문입니다. 이미지 스트림을 생성하는 데 사용하는 이미지 스트림 정의에서는 ImageStreamImage 오브젝트를 명시적으로 정의할 필요가 없습니다.

OpenShift Container Platform은 컨테이너를 생성할 때 컨테이너 imagePullPolicy를 사용하여 컨테이너를 시작하기 전에 이미지를 가져와야 하는지 결정합니다. imagePullPolicy에 가능한 값은 다음 세 가지입니다.

컨테이너 imagePullPolicy 매개변수가 지정되지 않은 경우 OpenShift Container Platform은 이미지 태그를 기반으로 이 매개변수를 설정합니다.

OpenShift 이미지 레지스트리를 사용하는 경우 project-a 의 pod가 project-b 의 이미지를 참조하도록 허용하려면 project-a 의 서비스 계정을 project-b 의 system:image-puller 역할에 바인딩해야 합니다.

Docker 클라이언트의 .dockercfg $HOME/.docker/config.json 파일은 이전에 보안 또는 비보안 레지스트리에 로그인한 적이 있는 경우 인증 정보를 저장하는 Docker 인증 정보 파일입니다.

OpenShift 이미지 레지스트리가 아닌 보안 컨테이너 이미지를 가져오려면 Docker 인증 정보에서 풀 시크릿을 생성하여 서비스 계정에 추가해야 합니다.

Docker 인증 정보 파일과 연결된 풀 암호에는 각각 고유한 인증 정보 세트가 있는 동일한 레지스트리에 대한 여러 참조가 포함될 수 있습니다.

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io/repository-main":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

apiVersion: v1
data:
  .dockerconfigjson: ewogICAiYXV0aHMiOnsKICAgICAgIm0iOnsKICAgICAgIsKICAgICAgICAgImF1dGgiOiJiM0JsYj0iLAogICAgICAgICAiZW1haWwiOiJ5b3VAZXhhbXBsZS5jb20iCiAgICAgIH0KICAgfQp9Cg==
kind: Secret
metadata:
  creationTimestamp: "2021-09-09T19:10:11Z"
  name: pull-secret
  namespace: default
  resourceVersion: "37676"
  uid: e2851531-01bc-48ba-878c-de96cfe31020
type: Opaque

현재 풀 시크릿을 교체하거나 새 풀 시크릿을 추가하여 클러스터의 글로벌 풀 시크릿을 업데이트할 수 있습니다.

이미지 스트림에 대한 일반 정보와 해당 이미지 스트림이 가리키는 모든 태그에 대한 자세한 정보를 얻을 수 있습니다.

이미지 스트림에 태그를 더 추가할 수 있습니다.

외부 이미지에 대해 태그를 추가할 수 있습니다.

이미지 스트림의 다른 태그를 반영하도록 태그를 업데이트할 수 있습니다.

이미지 스트림에서 이전 태그를 제거할 수 있습니다.

Cluster Samples Operator가 더 이상 사용되지 않는 이미지 스트림 태그를 처리하는 방법에 대한 자세한 내용은 Cluster Samples Operator에서 더 이상 사용되지 않는 이미지 스트림 태그 제거를 참조하십시오.

외부 컨테이너 이미지 레지스트리로 작업하는 경우 예를 들어 최신 보안 업데이트를 받기 위해 이미지를 정기적으로 다시 가져오려면 --scheduled 플래그를 사용할 수 있습니다.

Docker 클라이언트의 .dockercfg $HOME/.docker/config.json 파일은 이전에 보안 또는 비보안 레지스트리에 로그인한 적이 있는 경우 인증 정보를 저장하는 Docker 인증 정보 파일입니다.

OpenShift 이미지 레지스트리가 아닌 보안 컨테이너 이미지를 가져오려면 Docker 인증 정보에서 풀 시크릿을 생성하여 서비스 계정에 추가해야 합니다.

Docker 인증 정보 파일과 연결된 풀 암호에는 각각 고유한 인증 정보 세트가 있는 동일한 레지스트리에 대한 여러 참조가 포함될 수 있습니다.

{
   "auths":{
      "cloud.openshift.com":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      },
      "quay.io/repository-main":{
         "auth":"b3Blb=",
         "email":"you@example.com"
      }
   }
}

apiVersion: v1
data:
  .dockerconfigjson: ewogICAiYXV0aHMiOnsKICAgICAgIm0iOnsKICAgICAgIsKICAgICAgICAgImF1dGgiOiJiM0JsYj0iLAogICAgICAgICAiZW1haWwiOiJ5b3VAZXhhbXBsZS5jb20iCiAgICAgIH0KICAgfQp9Cg==
kind: Secret
metadata:
  creationTimestamp: "2021-09-09T19:10:11Z"
  name: pull-secret
  namespace: default
  resourceVersion: "37676"
  uid: e2851531-01bc-48ba-878c-de96cfe31020
type: Opaque

image.config.openshift.io/cluster 사용자 정의 리소스(CR)를 편집하여 이미지 가져오기 및 푸시 작업에 허용되는 레지스트리 목록을 추가하고 선택적으로 레지스트리 내의 개별 리포지토리를 추가할 수 있습니다. OpenShift Container Platform은 이 CR에 대한 변경 사항을 클러스터의 모든 노드에 적용합니다.

이미지를 풀하거나 푸시할 때 컨테이너 런타임은 image.config.openshift.io/cluster CR에서 registrySources 매개변수 아래에 나열된 레지스트리를 검색합니다. allowedRegistries 매개변수 아래에 레지스트리 목록을 생성한 경우 컨테이너 런타임은 해당 레지스트리만 검색합니다. 목록에 없는 레지스트리는 차단됩니다.

spec:
  registrySources:
    insecureRegistries:
    - insecure.com
    allowedRegistries:
    - example.com
    - quay.io
    - registry.redhat.io
    - insecure.com
    - image-registry.openshift-image-registry.svc:5000

image.config.openshift.io/cluster 사용자 정의 리소스(CR)를 편집하여 레지스트리 내의 모든 레지스트리 및 선택적으로 개별 리포지토리를 차단할 수 있습니다. OpenShift Container Platform은 이 CR에 대한 변경 사항을 클러스터의 모든 노드에 적용합니다.

이미지를 풀하거나 푸시할 때 컨테이너 런타임은 image.config.openshift.io/cluster CR에서 registrySources 매개변수 아래에 나열된 레지스트리를 검색합니다. blockedRegistries 매개변수 아래에 레지스트리 목록을 생성한 경우 컨테이너 런타임에서 해당 레지스트리를 검색하지 않습니다. 다른 모든 레지스트리는 허용됩니다.

image.config.openshift.io/cluster 사용자 정의 리소스(CR)를 편집하여 비보안 레지스트리를 추가하거나 선택적으로 레지스트리 내에 개별 저장소를 추가할 수 있습니다. OpenShift Container Platform은 이 CR에 대한 변경 사항을 클러스터의 모든 노드에 적용합니다.

유효한 SSL 인증서를 사용하지 않거나 HTTPS 연결이 필요하지 않은 레지스트리는 안전하지 않은 레지스트리로 간주됩니다.

image.config.openshift.io/cluster 사용자 정의 리소스(CR)를 편집하여 이미지의 단축 이름을 검색하기 위해 레지스트리를 추가할 수 있습니다. OpenShift Container Platform은 이 CR에 대한 변경 사항을 클러스터의 모든 노드에 적용합니다.

이미지 단축 이름을 사용하면 가져오기 사양에 정규화된 도메인 이름을 포함하지 않고도 이미지를 검색할 수 있습니다. 예를 들어 registry.access.redhat.com/rhe7/etcd 대신 rhel7/etcd를 사용할 수 있습니다.

전체 경로를 사용하지 않는 경우 단축 이름을 사용할 수 있습니다. 예를 들어, 클러스터가 DNS가 자주 변경되는 여러 내부 레지스트리를 참조하는 경우 각 변경에 따라 풀 사양에서 정규화된 도메인 이름을 업데이트해야 합니다. 이 경우 이미지 단축 이름을 사용하는 것이 유용할 수 있습니다.

이미지를 풀하거나 푸시할 때 컨테이너 런타임은 image.config.openshift.io/cluster CR에서 registrySources 매개변수 아래에 나열된 레지스트리를 검색합니다. containerRuntimeSearchRegistries 매개변수 아래에 레지스트리 목록을 생성한 경우, 단축 이름으로 이미지를 가져오면 컨테이너 런타임에서 해당 레지스트리를 검색합니다.

MCO(Machine Config Operator)는 image.config.openshift.io/cluster 리소스를 통해 레지스트리에 대한 변경 사항을 확인합니다. MCO가 변경사항을 감지하면 노드를 비우고, 변경 사항을 적용한 다음 노드를 분리합니다. 노드가 Ready 상태가 된 후 containerRuntimeSearchRegistries 매개변수가 추가되면 MCO가 나열된 레지스트리를 사용하여 각 노드에 /etc/containers/registries.conf.d 디렉터리에 파일을 생성합니다. 이 파일은 /host/etc/containers/registries.conf 파일의 정규화되지 않은 검색 레지스트리 목록을 재정의합니다. 정규화되지 않은 검색 레지스트리의 기본 목록으로 돌아갈 수 없습니다.

containerRuntimeSearchRegistries 매개변수는 Podman 및 CRI-O 컨테이너 엔진에서만 작동합니다. 목록의 레지스트리는 빌드 및 이미지 스트림에서 아닌 Pod 사양에서만 사용할 수 있습니다.

image.config.openshift.io/cluster 사용자 지정 리소스에는 이미지 레지스트리 액세스 중에 신뢰할 수 있는 추가 인증 기관이 포함된 구성 맵에 대한 참조가 포함될 수 있습니다.

구성 맵 키는 이 CA가 신뢰할 수있는 포트가 있는 레지스트리의 호스트 이름이며 PEM 인증서 콘텐츠는 신뢰할 수 있는 각 추가 레지스트리 CA의 값입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-registry-ca
data:
  registry.example.com: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  registry-with-port.example.com..5000: | 1
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

다음 절차에 따라 추가 CA를 구성할 수 있습니다.

컨테이너 레지스트리 저장소 미러링을 설정하면 다음을 수행할 수 있습니다.

다음은 OpenShift Container Platform의 저장소 미러링의 몇 가지 속성입니다.

저장소 미러링은 다음과 같은 방법으로 설정할 수 있습니다.

다음 절차에서는 설치 후 미러 구성을 제공합니다. 이때 다음을 식별하는 ImageContentSourcePolicy 오브젝트를 생성할 수 있습니다.

레이블은 pod 같은 생성된 오브젝트를 관리하고 구성하는 데 사용됩니다. 템플릿에 지정된 레이블은 템플릿에서 생성된 모든 오브젝트에 적용됩니다.

재정의할 수 있는 매개변수 목록은 템플릿의 parameters 섹션에 나열되어 있습니다.

CLI를 사용하면 템플릿 정의 파일을 처리하여 오브젝트 목록을 표준 출력으로 반환할 수 있습니다.

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

퀵 스타트를 살펴보려면 템플릿에서 애플리케이션을 생성합니다. 관리자가 이미 OpenShift Container Platform 클러스터에 이러한 템플릿을 이미 설치했을 수 있으며, 이 경우 간단히 웹 콘솔에서 선택할 수 있습니다.

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

템플릿 설명은 템플릿의 기능을 사용자에게 알려주고 웹 콘솔에서 검색할 때 템플릿을 찾도록 도와줍니다. 템플릿 이름 이외의 추가 메타데이터는 선택사항이지만 있으면 유용합니다. 메타데이터에는 일반적인 설명 정보 외에도 태그 세트가 포함되어 있습니다. 유용한 태그에는 템플릿과 관련된 언어의 이름이 포함되어 있습니다(예: Java, PHP, Ruby 등).

다음은 템플릿 설명 메타데이터의 예입니다.

kind: Template
apiVersion: template.openshift.io/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 DeploymentConfig, and
      database DeploymentConfig.  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

템플릿에는 레이블 세트가 포함될 수 있습니다. 이러한 레이블은 템플릿이 인스턴스화될 때 생성되는 각 오브젝트에 추가됩니다. 이런 방식으로 레이블을 정의하면 사용자가 특정 템플릿에서 생성된 모든 오브젝트를 쉽게 찾아서 관리할 수 있습니다.

다음은 템플릿 오브젝트 레이블의 예입니다.

kind: "Template"
apiVersion: "v1"
...
labels:
  template: "cakephp-mysql-example" 1
  app: "${NAME}" 2

매개 변수를 사용하면 템플릿을 인스턴스화할 때 값을 제공하거나 생성할 수 있습니다. 그러면 해당 값이 매개변수가 참조될 때마다 대체됩니다. 참조는 오브젝트 목록 필드의 어떤 필드에서든 정의할 수 있습니다. 임의의 암호를 생성하거나 템플릿을 사용자 지정하는 데 필요한 호스트 이름 또는 기타 사용자별 값을 제공할 수 있도록 하는 데 유용합니다. 매개변수는 다음 두 가지 방법으로 참조할 수 있습니다.

${PARAMETER_NAME} 구문을 사용하는 경우 여러 매개변수 참조가 단일 필드에서 결합될 수 있으며 참조는 "http://${PARAMETER_1}${PARAMETER_2}" 같이 고정된 데이터에 내에 포함될 수 있습니다. 매개변수 값이 둘 다 대체되며 결과 값은 인용된 문자열이 됩니다.

${{PARAMETER_NAME}} 구문을 사용하는 경우 단일 매개변수 참조만 허용되며 선행 및 후행 문자는 허용되지 않습니다. 대체가 수행된 후 결과가 유효한 JSON 오브젝트인 경우 결과 값이 인용되지 않습니다. 결과가 유효한 JSON 값이 아닌 경우 결과 값이 인용되고 표준 문자열로 처리됩니다.

단일 매개변수는 템플릿 내에서 여러 번 참조될 수 있으며 단일 템플릿 내에서 두 대체 구문을 사용하여 참조될 수도 있습니다.

다른 값을 제공하지 않은 경우 사용되는 기본값을 제공할 수 있습니다.

다음은 명시적 값을 기본값으로 설정하는 예입니다.

parameters:
  - name: USERNAME
    description: "The user name for Joe"
    value: joe

매개변수 값은 다음과 같이 매개변수 정의에 지정된 규칙을 기반으로 생성될 수도 있습니다(예: 매개변수 값 생성).

parameters:
  - name: PASSWORD
    description: "The random user password"
    generate: expression
    from: "[a-zA-Z0-9]{12}"

이전 예에서 처리가 완료되면 모든 대문자 및 소문자 영문자와 숫자로 구성된 12자 길이의 임의의 암호가 생성됩니다.

사용 가능한 구문은 완전한 정규식 구문이 아닙니다. 하지만 \w, \d, \a, and \A 수정자를 사용할 수 있습니다.

  parameters:
  - name: singlequoted_example
    generate: expression
    from: '[\A]{10}'
  - name: doublequoted_example
    generate: expression
    from: "[\\A]{10}"

{
    "parameters": [
       {
        "name": "json_example",
        "generate": "expression",
        "from": "[\\A]{10}"
       }
    ]
}

다음은 매개변수 정의 및 참조가 포함된 전체 템플릿의 예입니다.

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
  - kind: BuildConfig
    apiVersion: build.openshift.io/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: apps.openshift.io/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

템플릿의 주요 부분은 템플릿이 인스턴스화될 때 생성되는 오브젝트 목록입니다. 빌드 구성, 배포 구성 또는 서비스와 같은 유효한 API 오브젝트일 수 있습니다. 오브젝트는 정확히 여기에 정의된 대로 생성되며 매개변수 값은 생성 전에 대체됩니다. 이러한 오브젝트 정의는 앞에서 정의한 매개변수를 참조할 수 있습니다.

다음은 오브젝트 목록의 예입니다.

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"

Template Service Broker는 해당 카탈로그에서 인식하는 템플릿 오브젝트마다 하나의 서비스를 알립니다. 기본적으로 이러한 각 서비스는 바인드 가능 상태로 알려집니다. 즉, 일반 사용자가 프로비저닝된 서비스에 대해 바인딩할 수 있습니다.

템플릿 작성자는 템플릿의 특정 오브젝트 필드가 노출되어야 함을 나타낼 수 있습니다. Template Service Broker는 ConfigMap, Secret, Service, Route 오브젝트에서 노출된 필드를 인식하고, 브로커가 지원하는 서비스를 사용자가 바인딩할 때 노출된 필드의 값을 반환합니다.

오브젝트의 필드를 하나 이상 노출하려면 template.openshift.io/expose- 또는 template.openshift.io/base64-expose-로 접두사를 붙인 주석을 템플릿의 오브젝트에 추가합니다.

접두사가 제거된 각 주석 키는 전달되어 bind 응답의 키가 됩니다.

각 주석 값은 Kubernetes JSONPath 표현식이며, 바인딩 시 이를 해석하여 bind 응답에서 값을 반환해야 하는 오브젝트 필드를 식별합니다.

다음은 노출되는 다양한 오브젝트 필드의 예입니다.

kind: Template
apiVersion: template.openshift.io/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: <password>
- 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: route.openshift.io/v1
  metadata:
    name: my-template-route
    annotations:
      template.openshift.io/expose-uri: "http://{.spec.host}{.spec.path}"
  spec:
    path: mypath

위의 부분적인 템플릿을 기반으로 하는 bind 작업에 대한 응답 예는 다음과 같습니다.

{
  "credentials": {
    "username": "foo",
    "password": "YmFy",
    "service_ip_port": "172.30.12.34:8080",
    "uri": "http://route-test.router.default.svc.cluster.local/mypath"
  }
}

템플릿 작성자는 템플릿 내의 특정 오브젝트가 일정 시간 대기한 뒤에 서비스 카탈로그, Template Service Broker 또는 TemplateInstance API의 템플릿 인스턴스화가 완료된 것으로 간주된다고 표시할 수 있습니다.

이 기능을 사용하려면 템플릿에서 다음 주석으로 하나 이상의 오브젝트를 Build, BuildConfig, Deployment, DeploymentConfig, Job 또는 StatefulSet 유형으로 표시하십시오.

"template.alpha.openshift.io/wait-for-ready": "true"

이 주석이 표시된 모든 오브젝트가 준비되었다고 보고할 때까지 템플릿 인스턴스화는 완료되지 않습니다. 마찬가지로 주석이 있는 오브젝트 보고서 중 실패하는 보고서가 있거나 템플릿이 1시간이라는 고정된 제한 시간 내에 준비되지 않으면 템플릿 인스턴스화가 실패합니다.

인스턴스화를 위해 각 오브젝트 유형의 준비 및 실패는 다음과 같이 정의됩니다.

다음은 wait-for-ready 주석을 사용하는 템플릿 추출의 예입니다. 자세한 예는 OpenShift Container Platform 퀵 스타트 템플릿에서 확인할 수 있습니다.

kind: Template
apiVersion: template.openshift.io/v1
metadata:
  name: my-template
objects:
- kind: BuildConfig
  apiVersion: build.openshift.io/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: apps.openshift.io/v1
  metadata:
    name: ...
    annotations:
      template.alpha.openshift.io/wait-for-ready: "true"
  spec:
    ...
- kind: Service
  apiVersion: v1
  metadata:
    name: ...
  spec:
    ...

전체 템플릿을 처음부터 작성하지 않고 프로젝트에서 기존 오브젝트를 YAML 형식으로 내보낸 후 템플릿 형식으로 매개변수 및 기타 사용자 정의를 추가하여 YAML을 수정할 수 있습니다.

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

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

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

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

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

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

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

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

애플리케이션을 OpenShift Container Platform으로 가져오려면 애플리케이션이 상주하는 리포지터리를 지정해야 합니다.

서비스를 공개하여 애플리케이션 경로를 생성할 수 있습니다.

Jenkins 인증은 다음 두 가지 방법으로 관리할 수 있습니다.

Jenkins 서버는 다음 환경 변수로 구성할 수 있습니다.

동일한 프로젝트가 아닌 다른 위치에서 Jenkins를 실행하려는 경우 Jenkins에 액세스 토큰을 제공해야 프로젝트에 액세스할 수 있습니다.

구성을 위한 영구 스토리지가 활성화되도록 마운트된 볼륨을 사용하여 Jenkins 이미지를 실행할 수 있습니다.

공식 OpenShift Container Platform Jenkins 이미지를 사용자 정의하려면 이미지를 S2I(Source-to-Image) 빌더로 사용할 수 있습니다.

S2I를 사용하여 사용자 정의 Jenkins 작업 정의를 복사하거나 플러그인을 추가하거나 제공된 config.xml 파일을 자체 사용자 정의 구성으로 교체할 수 있습니다.

Jenkins 이미지에 수정 사항을 포함하려면 다음 디렉토리 구조의 Git 리포지터리가 있어야 합니다.

pluginId:pluginVersion

configuration/ 디렉토리의 콘텐츠는 /var/lib/jenkins/ 디렉토리에 복사되므로 credentials.xml 같은 추가 파일도 포함할 수 있습니다.

apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: custom-jenkins-build
spec:
  source:                       1
    git:
      uri: https://github.com/custom/repository
    type: Git
  strategy:                     2
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: jenkins:2
        namespace: openshift
    type: Source
  output:                       3
    to:
      kind: ImageStreamTag
      name: custom-jenkins:latest

OpenShift Container Platform Jenkins 이미지에는 Kubernetes 및 OpenShift Container Platform을 사용하여 여러 컨테이너 호스트에서 Jenkins 에이전트를 동적으로 프로비저닝할 수 있는 사전 설치된 Kubernetes 플러그인이 포함되어 있습니다.

Kubernetes 플러그인을 사용하기 위해 OpenShift Container Platform은 Jenkins 에이전트로 사용하기에 적합한 이미지(기본, Maven, Node.js)를 제공합니다.

Maven 및 Node.js 에이전트 이미지 둘 다 OpenShift Container Platform Jenkins 이미지 구성에 Kubernetes pod 템플릿 이미지로 자동 구성됩니다. 해당 구성에는 이 프로젝트를 실행할 수 있는 제한 설정에 따라 모든 Jenkins 작업에 적용할 수 있는 각 이미지의 레이블이 포함되어 있습니다. 레이블이 적용되면 해당 에이전트 이미지를 실행하는 OpenShift Container Platform pod에서 작업이 실행됩니다.

Jenkins 이미지는 Kubernetes 플러그인의 추가 에이전트 이미지 자동 검색 및 자동 구성 기능도 제공합니다.

OpenShift Container Platform 동기화 플러그인을 사용하면 Jenkins 시작 시 Jenkins 이미지가 실행 중인 프로젝트 또는 플러그인 구성에 구체적으로 나열된 프로젝트에서 다음을 검색합니다.

적절한 레이블이 있는 이미지 스트림 또는 적절한 주석이 있는 이미지 스트림 태그를 찾으면 해당 Kubernetes 플러그인 구성이 생성되므로 이미지 스트림에서 제공하는 컨테이너 이미지를 실행하는 Pod에서 Jenkins 작업을 실행하도록 할당할 수 있습니다.

이미지 스트림 또는 이미지 스트림 태그의 이름 및 이미지 참조는 Kubernetes 플러그인 pod 템플릿의 이름 및 이미지 필드에 매핑됩니다. agent-label 키로 이미지 스트림 또는 이미지 스트림 태그 오브젝트에 주석을 설정하여 Kubernetes 플러그인 pod 템플릿의 레이블 필드를 제어할 수 있습니다. 그러지 않으면 이름이 레이블로 사용됩니다.

적절한 레이블이 있는 구성 맵을 찾으면 구성 맵의 키-값 데이터 페이로드에 있는 값에 Jenkins 및 Kubernetes 플러그인 pod 템플릿의 구성 형식과 일치하는 XML(Extensible Markup Language)이 포함되어 있다고 가정합니다. 이미지 스트림 또는 이미지 스트림 태그가 아닌 구성 맵을 사용할 때의 한 가지 주요 이점은 Kubernetes 플러그인 pod 템플릿의 모든 매개변수를 제어할 수 있다는 것입니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
data:
  template1: |-
    <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
      <inheritFrom></inheritFrom>
      <name>template1</name>
      <instanceCap>2147483647</instanceCap>
      <idleMinutes>0</idleMinutes>
      <label>template1</label>
      <serviceAccount>jenkins</serviceAccount>
      <nodeSelector></nodeSelector>
      <volumes/>
      <containers>
        <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          <name>jnlp</name>
          <image>openshift/jenkins-agent-maven-35-centos7:v3.10</image>
          <privileged>false</privileged>
          <alwaysPullImage>true</alwaysPullImage>
          <workingDir>/tmp</workingDir>
          <command></command>
          <args>${computer.jnlpmac} ${computer.name}</args>
          <ttyEnabled>false</ttyEnabled>
          <resourceRequestCpu></resourceRequestCpu>
          <resourceRequestMemory></resourceRequestMemory>
          <resourceLimitCpu></resourceLimitCpu>
          <resourceLimitMemory></resourceLimitMemory>
          <envVars/>
        </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
      </containers>
      <envVars/>
      <annotations/>
      <imagePullSecrets/>
      <nodeProperties/>
    </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>

다음 예제에서는 openshift 네임스페이스에 있는 이미지 스트림을 참조하는 두 개의 컨테이너를 보여줍니다. 하나의 컨테이너는 Pod를 Jenkins 에이전트로 시작하기 위한 JNLP 계약을 처리합니다. 다른 컨테이너는 특정 코딩 언어로 코드를 빌드하는 도구와 함께 이미지를 사용합니다.

kind: ConfigMap
apiVersion: v1
metadata:
  name: jenkins-agent
  labels:
    role: jenkins-agent
data:
  template2: |-
        <org.csanchez.jenkins.plugins.kubernetes.PodTemplate>
          <inheritFrom></inheritFrom>
          <name>template2</name>
          <instanceCap>2147483647</instanceCap>
          <idleMinutes>0</idleMinutes>
          <label>template2</label>
          <serviceAccount>jenkins</serviceAccount>
          <nodeSelector></nodeSelector>
          <volumes/>
          <containers>
            <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
              <name>jnlp</name>
              <image>image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base:latest</image>
              <privileged>false</privileged>
              <alwaysPullImage>true</alwaysPullImage>
              <workingDir>/home/jenkins/agent</workingDir>
              <command></command>
              <args>\$(JENKINS_SECRET) \$(JENKINS_NAME)</args>
              <ttyEnabled>false</ttyEnabled>
              <resourceRequestCpu></resourceRequestCpu>
              <resourceRequestMemory></resourceRequestMemory>
              <resourceLimitCpu></resourceLimitCpu>
              <resourceLimitMemory></resourceLimitMemory>
              <envVars/>
            </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
            <org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
              <name>java</name>
              <image>image-registry.openshift-image-registry.svc:5000/openshift/java:latest</image>
              <privileged>false</privileged>
              <alwaysPullImage>true</alwaysPullImage>
              <workingDir>/home/jenkins/agent</workingDir>
              <command>cat</command>
              <args></args>
              <ttyEnabled>true</ttyEnabled>
              <resourceRequestCpu></resourceRequestCpu>
              <resourceRequestMemory></resourceRequestMemory>
              <resourceLimitCpu></resourceLimitCpu>
              <resourceLimitMemory></resourceLimitMemory>
              <envVars/>
            </org.csanchez.jenkins.plugins.kubernetes.ContainerTemplate>
          </containers>
          <envVars/>
          <annotations/>
          <imagePullSecrets/>
          <nodeProperties/>
        </org.csanchez.jenkins.plugins.kubernetes.PodTemplate>

OpenShift Container Platform 동기화 플러그인이 설치되면 OpenShift Container Platform의 API 서버를 모니터링하여 이미지 스트림, 이미지 스트림 태그 및 구성 맵에 대한 업데이트를 확인하고 Kubernetes 플러그인의 구성을 조정합니다.

적용되는 규칙은 다음과 같습니다.

컨테이너 이미지를 Jenkins 에이전트로 사용하려면 이미지가 에이전트를 진입점으로 실행해야 합니다. 자세한 내용은 공식 Jenkins 문서를 참조하십시오.

구성 맵에서 pod 템플릿 XML의 <serviceAccount> 요소가 결과 pod에 사용된 OpenShift Container Platform 서비스 계정인 경우 서비스 계정 인증 정보가 해당 pod에 마운트됩니다. 권한은 이 서비스 계정과 연결되며 pod에서 허용되는 OpenShift Container Platform 마스터 작업을 제어합니다.

Pod에 사용된 서비스 계정을 사용하는 다음 시나리오를 고려해 보십시오. 이 pod는 OpenShift Container Platform Jenkins 이미지에서 실행되는 Kubernetes 플러그인에 의해 시작됩니다.

OpenShift Container Platform에서 제공하는 Jenkins에 대한 템플릿 예를 사용하는 경우 Jenkins가 실행되는 프로젝트에 대해 jenkins 서비스 계정이 edit 역할로 정의되고 마스터 Jenkins Pod에 해당 서비스 계정이 마운트됩니다.

Jenkins 구성에 삽입된 두 개의 기본 Maven 및 NodeJS pod 템플릿도 Jenkins 마스터와 동일한 서비스 계정을 사용하도록 설정됩니다.

템플릿은 모든 환경 변수를 사전 정의된 기본값으로 정의하는 매개변수 필드를 제공합니다. OpenShift Container Platform은 새로운 Jenkins 서비스 생성을 용이하게 해주는 템플릿을 제공합니다. Jenkins 템플릿은 초기 클러스터를 설정하는 중에 클러스터 관리자에 의해 기본 openshift 프로젝트에서 등록되어야 합니다.

사용 가능한 두 템플릿은 둘 다 배포 구성 및 서비스를 정의합니다. 스토리지 전략에서는 pod를 다시 시작할 때 Jenkins 콘텐츠가 지속되는지 여부에 영향을 미칩니다.

영구 볼륨 (PV) 저장소를 사용하려면 클러스터 관리자가 OpenShift Container Platform 배포에서 영구 볼륨 (PV) 풀을 정의해야 합니다.

원하는 템플릿을 선택한 후 Jenkins를 사용할 수 있도록 템플릿을 인스턴스화해야 합니다.

두 템플릿 모두에서 oc describe 를 실행하여 재정의할 수 있는 모든 매개변수를 확인할 수 있습니다.

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

$ oc describe jenkins-ephemeral

다음 예에서는 openshift-jee-sample BuildConfig 오브젝트로 인해 Jenkins Maven 에이전트 pod가 동적으로 프로비저닝됩니다. pod는 일부 Java 소스 코드를 복제하고 WAR 파일을 빌드하며 두 번째 BuildConfig인 openshift-jee-sample-docker가 실행되도록 합니다. 두 번째 BuildConfig는 컨테이너 이미지에 새 WAR 파일의 계층을 지정합니다.

kind: List
apiVersion: v1
items:
- kind: ImageStream
  apiVersion: image.openshift.io/v1
  metadata:
    name: openshift-jee-sample
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample-docker
  spec:
    strategy:
      type: Docker
    source:
      type: Docker
      dockerfile: |-
        FROM openshift/wildfly-101-centos7:latest
        COPY ROOT.war /wildfly/standalone/deployments/ROOT.war
        CMD $STI_SCRIPTS_PATH/run
      binary:
        asFile: ROOT.war
    output:
      to:
        kind: ImageStreamTag
        name: openshift-jee-sample:latest
- kind: BuildConfig
  apiVersion: build.openshift.io/v1
  metadata:
    name: openshift-jee-sample
  spec:
    strategy:
      type: JenkinsPipeline
      jenkinsPipelineStrategy:
        jenkinsfile: |-
          node("maven") {
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
    triggers:
    - type: ConfigChange

동적으로 생성된 Jenkins 에이전트 pod의 사양을 재정의할 수도 있습니다. 다음에서는 이전 예제를 수정하여 컨테이너 메모리를 재정의하고 환경 변수를 지정합니다.

kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
  name: openshift-jee-sample
spec:
  strategy:
    type: JenkinsPipeline
    jenkinsPipelineStrategy:
      jenkinsfile: |-
        podTemplate(label: "mypod", 1
                    cloud: "openshift", 2
                    inheritFrom: "maven", 3
                    containers: [
            containerTemplate(name: "jnlp", 4
                              image: "openshift/jenkins-agent-maven-35-centos7:v3.10", 5
                              resourceRequestMemory: "512Mi", 6
                              resourceLimitMemory: "512Mi", 7
                              envVars: [
              envVar(key: "CONTAINER_HEAP_PERCENT", value: "0.25") 8
            ])
          ]) {
          node("mypod") { 9
            sh "git clone https://github.com/openshift/openshift-jee-sample.git ."
            sh "mvn -B -Popenshift package"
            sh "oc start-build -F openshift-jee-sample-docker --from-file=target/ROOT.war"
          }
        }
  triggers:
  - type: ConfigChange

기본적으로 pod는 빌드가 완료되면 삭제됩니다. 이 동작은 플러그인 또는 파이프라인 Jenkinsfile 내에서 수정할 수 있습니다.

업스트림 Jenkins는 최근 파이프라인과 함께 podTemplate 파이프라인 DSL을 정의하기 위한 YAML 선언적 형식을 도입했습니다. 이 형식의 예는 OpenShift Container Platform Jenkins 이미지에 정의된 샘플 java-builder pod 템플릿입니다.

def nodeLabel = 'java-buidler'

pipeline {
  agent {
    kubernetes {
      cloud 'openshift'
      label nodeLabel
      yaml """
apiVersion: v1
kind: Pod
metadata:
  labels:
    worker: ${nodeLabel}
spec:
  containers:
  - name: jnlp
    image: image-registry.openshift-image-registry.svc:5000/openshift/jenkins-agent-base:latest
    args: ['\$(JENKINS_SECRET)', '\$(JENKINS_NAME)']
  - name: java
    image: image-registry.openshift-image-registry.svc:5000/openshift/java:latest
    command:
    - cat
    tty: true
"""
    }
  }

  options {
    timeout(time: 20, unit: 'MINUTES')
  }

  stages {
    stage('Build App') {
      steps {
        container("java") {
          sh "mvn --version"
        }
     }
    }
  }
}

제공된 Jenkins Ephemeral 또는 Jenkins Persistent 템플릿으로 배포하는 경우 기본 메모리 제한은 1Gi입니다.

기본적으로 Jenkins 컨테이너에서 실행되는 다른 모든 프로세스에서는 총 512 MiB 이상의 메모리를 사용할 수 없습니다. 더 많은 메모리가 필요한 경우 컨테이너가 중지됩니다. 따라서 가능한 경우 Pipeline은 에이전트 컨테이너에서 외부 명령을 실행하는 것이 좋습니다.

Project 할당량이 허용하는 경우 메모리 관점에서 Jenkins 마스터가 갖추어야 할 사항에 대한 Jenkins 문서의 권장 사항을 참조하십시오. 이러한 권장 사항에서는 Jenkins 마스터에 더 많은 메모리를 할당하지 않도록 합니다.

Jenkins Kubernetes 플러그인에 의해 생성된 에이전트 컨테이너에서 메모리 요청 및 제한 값을 지정하는 것이 좋습니다. 관리자는 Jenkins 구성을 통해 개별 에이전트 이미지를 기반으로 기본값을 설정할 수 있습니다. 메모리 요청 및 제한 매개변수는 개별 컨테이너를 기반으로 재정의할 수도 있습니다.

imagestreamtagJenkins Ephemeral 또는 Jenkins Persistent 템플릿을 인스턴스화하는 경우 MEMORY_LIMIT 매개변수를 재정의하여 Jenkins에서 사용할 수 있는 메모리 크기를 늘릴 수 있습니다.

OpenShift Container Platform Jenkins 에이전트 이미지는 Quay.io 또는 registry.redhat.io에서 사용할 수 있습니다.

Jenkins 이미지는 Red Hat Registry를 통해 사용할 수 있습니다.

$ docker pull registry.redhat.io/openshift4/ose-jenkins:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-10-rhel7:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/jenkins-agent-nodejs-12-rhel7:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-maven:<v4.5.0>

$ docker pull registry.redhat.io/openshift4/ose-jenkins-agent-base:<v4.5.0>

이러한 이미지를 사용하려면 Quay.io 또는 registry.redhat.io 에서 직접 이미지에 액세스하거나 OpenShift Container Platform 컨테이너 이미지 레지스트리로 이미지를 푸시할 수 있습니다.

각 Jenkins 에이전트 컨테이너는 다음 환경 변수를 사용하여 구성할 수 있습니다.

JVM은 모든 Jenkins 에이전트에서 Jenkins JNLP 에이전트를 호스트하고 javac, Maven 또는 Gradle 같은 Java 애플리케이션을 실행하는 데 사용됩니다.

기본적으로 Jenkins JNLP 에이전트 JVM은 힙에 대해 컨테이너 메모리 제한의 50%를 사용합니다. 이 값은 CONTAINER_HEAP_PERCENT 환경 변수를 통해 수정할 수 있습니다. 상한값으로 제한하거나 완전히 재정의할 수도 있습니다.

파이프라인에서 실행되는 쉘 스크립트나 oc 명령과 같이 Jenkins 에이전트 컨테이너에서 실행되는 다른 모든 프로세스는 기본적으로 OOM을 종료하지 않고는 나머지 50%의 메모리 제한을 초과하여 사용할 수 없습니다.

기본적으로 Jenkins 에이전트 컨테이너에서 실행되는 각각의 추가 JVM 프로세스는 힙에 대해 컨테이너 메모리 제한의 최대 25%를 사용합니다. 많은 빌드 워크로드에 대해 이 제한을 튜닝해야 할 수도 있습니다.

OpenShift Container Platform의 Jenkins 에이전트에서 Gradle 빌드를 호스트하면 Jenkins JNLP 에이전트 및 Gradle JVM 외에도 여러 빌드가 지정된 경우 테스트를 실행하는 세 번째 JVM을 Gradle이 생성하므로 복잡성이 더욱 가중됩니다.

다음은 OpenShift Container Platform의 메모리가 제한된 Jenkins 에이전트에서 Gradle 빌드를 실행하기 위한 시작점으로 제안된 설정입니다. 필요에 따라 이러한 설정을 수정할 수 있습니다.

Jenkins 에이전트 pod는 빌드가 완료되거나 중지되면 기본적으로 삭제됩니다. 이 동작은 Kubernetes 플러그인 pod 보존 설정을 통해 변경할 수 있습니다. pod 보존은 각 pod 템플릿에 대한 재정의를 통해 모든 Jenkins 빌드에 대해 설정할 수 있습니다. 지원되는 동작은 다음과 같습니다.

pod 보존은 Pipeline Jenkinsfile에서 재정의할 수 있습니다.

podTemplate(label: "mypod",
  cloud: "openshift",
  inheritFrom: "maven",
  podRetention: onFailure(), 1
  containers: [
    ...
  ]) {
  node("mypod") {
    ...
  }
}

S2I(Source-to-Image)는 소스 코드를 실행할 컨테이너에 소스 코드를 삽입하여 실행할 수 있는 이미지를 생성합니다. 다음과 같은 단계를 수행합니다.

그런 다음 Buildah에서 컨테이너 이미지를 생성합니다.

빌더 이미지는 가장 일반적인 사용 사례를 포함하는 자체 버전의 S2I(Source-to-Image) 스크립트를 제공합니다. 이러한 스크립트가 요구 사항을 충족하지 않으면 S2I는 .s2i/bin 디렉터리에 사용자 지정 설정을 추가하여 덮어쓰는 방법을 제공합니다. 하지만 이렇게 하면 표준 스크립트를 완전히 교체할 수 있습니다. 스크립트 교체가 허용되는 경우도 있지만 다른 시나리오에서는 이미지에 제공된 스크립트의 논리를 유지하면서 스크립트 전 또는 후에 몇 명령을 실행할 수 있습니다. 표준 스크립트를 재사용하려면 사용자 정의 논리를 실행하고 이미지의 기본 스크립트로 추가 작업을 위임하는 래퍼 스크립트를 생성할 수 있습니다.