6.2. 간단한 컨테이너 빌드
애플리케이션에 대한 아이디어가 있으며 컨테이너화하고 싶은 경우를 살펴보겠습니다.
먼저 buildah 또는 docker와 같은 컨테이너를 빌드하는 도구와 컨테이너에 들어가는 내용을 설명하는 파일(일반적으로 Dockerfile)이 필요합니다.
다음으로 결과 컨테이너 이미지를 넣을 위치가 필요하므로 실행하려는 위치로 끌어올 수 있습니다. 이 위치는 컨테이너 레지스트리입니다.
이러한 각 구성 요소의 몇 가지 예는 사용자가 직접 제공하는 Dockerfile을 제외하고 대부분의 Linux 운영 체제에 기본적으로 설치됩니다.
다음 다이어그램은 이미지를 작성하고 푸시하는 프로세스를 보여줍니다.
그림 6.1. 컨테이너화된 간단한 애플리케이션을 생성하여 레지스트리로 푸시
RHEL(Red Hat Enterprise Linux)을 운영 체제로 실행하는 컴퓨터를 사용하는 경우 컨테이너화된 애플리케이션을 생성하는 프로세스에는 다음 단계가 필요합니다.
- 컨테이너 빌드 도구 설치: RHEL에는 컨테이너를 빌드하고 관리하는 데 사용하는 podman, buildah 및 skopeo가 포함된 도구 세트가 포함되어 있습니다.
-
기본 이미지와 소프트웨어를 결합하는 Dockerfile 생성: 컨테이너 빌드에 대한 정보는
Dockerfile이라는 파일에 입력됩니다. 이 파일에서 빌드한 기본 이미지, 설치한 소프트웨어 패키지 및 컨테이너에 복사한 소프트웨어를 식별합니다. 컨테이너 외부에 노출되는 네트워크 포트 및 컨테이너 내부에 마운트된 볼륨과 같은 매개변수 값도 식별합니다. RHEL 시스템의 디렉터리에 Dockerfile과 컨테이너화된 소프트웨어를 배치합니다. -
buildah 또는 docker 빌드 실행:
buildah build-using-dockerfile또는docker build명령을 실행하여 선택한 기본 이미지를 가져와 로컬에 저장된 컨테이너 이미지를 생성합니다. buildah를 사용하여 Dockerfile 없이 컨테이너 이미지를 빌드할 수도 있습니다. -
태그 지정 및 레지스트리로 푸시: 컨테이너를 저장하고 공유할 레지스트리의 위치를 식별하는 새 컨테이너 이미지에 태그를 추가하십시오. 그런 다음
podman push또는docker push명령을 실행하여 레지스트리에 이미지를 푸시합니다. -
이미지 가져오기 및 실행: podman 또는 docker와 같은 컨테이너 클라이언트 도구가 있는 시스템에서 새 이미지를 식별하는 명령을 실행하십시오. 예를 들어
podman run <image_name>또는docker run <image_name>명령을 실행하십시오. 여기서<image_name>은 새 컨테이너 이미지의 이름이며,quay.io/myrepo/myapp:latest와 비슷합니다. 이미지를 푸시하고 가져오려면 레지스트리에 자격 증명이 필요할 수 있습니다.
컨테이너 이미지를 빌드하고 레지스트리에 푸시하고 실행하는 프로세스에 대한 자세한 내용은 Buildah로 사용자 정의 이미지 빌드를 참조하십시오.
6.2.1. 컨테이너 빌드 도구 옵션
buildah, podman 및 skopeo를 사용하여 컨테이너를 빌드하고 관리하면 OpenShift Container Platform 또는 기타 Kubernetes 환경에서 컨테이너 배포를 위해 특별히 조정된 기능이 포함된 업계 표준 컨테이너 이미지가 생성됩니다. 이러한 툴은 데몬이 없으며 루트 권한 없이 실행할 수 있으므로 오버헤드가 줄어듭니다.
컨테이너 런타임으로 Docker Container Engine에 대한 지원은 Kubernetes 1.20에서 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 그러나 Docker 생성 이미지는 CRI-O를 포함한 모든 런타임에서 클러스터에서 계속 작동합니다. 자세한 내용은 Kubernetes 블로그 공지 를 참조하십시오.
OpenShift Container Platform에서 컨테이너를 궁극적으로 실행할 때는 CRI-O 컨테이너 엔진을 사용합니다. CRI-O는 OpenShift Container Platform 클러스터의 모든 작업자 및 컨트롤 플레인 머신에서 실행되지만 CRI-O는 아직 OpenShift Container Platform 외부의 독립 실행형 런타임으로 지원되지 않습니다.
6.2.2. 기본 이미지 옵션
애플리케이션을 빌드하기 위해 선택한 기본 이미지에는 애플리케이션의 Linux 시스템과 유사한 소프트웨어 세트가 포함되어 있습니다. 고유 이미지를 빌드하면 소프트웨어가 해당 파일 시스템에 배치되고 해당 파일 시스템이 운영 체제를 보는 것처럼 인식합니다. 이 기본 이미지를 선택하면 향후 컨테이너의 안전성, 효율성 및 업그레이드 가능성에 큰 영향을 미칩니다.
Red Hat에서는 Red Hat Universal Base Images(UBI)라는 새로운 기본 이미지 세트를 제공합니다. 이 이미지는 Red Hat Enterprise Linux를 기반으로 하며 과거 Red Hat에서 제공한 기본 이미지와 유사하지만 한 가지 큰 차이점이 있습니다. 이는 Red Hat 서브스크립션이 없이 자유롭게 재배포할 수 있습니다. 결과적으로 공유 방법이나 환경에 따라 다른 이미지를 만드는 것에 대한 걱정 없이 UBI 이미지에서 애플리케이션을 빌드할 수 있습니다.
이 UBI 이미지에는 표준, 초기화 및 최소 버전이 있습니다. Node.js, Perl 또는 Python과 같은 특정 런타임 환경에 종속된 애플리케이션의 기초로 Red Hat Software Collections 이미지를 사용할 수도 있습니다. 이러한 런타임 기본 이미지 중 일부 특수 버전은 S2I(Source-to-Image) 이미지라고 합니다. S2I 이미지를 사용하면 해당 코드를 실행할 준비가 된 기본 이미지 환경에 코드를 삽입할 수 있습니다.
다음 그림과 같이 카탈로그
그림 6.2. 특정 런타임이 필요한 앱에 맞는 S2I 기본 이미지 선택
6.2.3. 레지스트리 옵션
컨테이너 레지스트리에 컨테이너 이미지를 저장하면 다른 사용자와 공유하고 궁극적으로 실행되는 플랫폼에서 사용할 수 있게 됩니다. 무료 계정을 제공하는 대규모 공용 컨테이너 레지스트리 또는 추가 스토리지와 특수 기능을 제공하는 프리미엄 버전을 선택할 수 있습니다. 조직에 독점적이거나 다른 사용자와 선택적으로 공유할 수 있는 고유한 레지스트리도 설치할 수 있습니다.
Red Hat 이미지 및 인증된 파트너 이미지를 얻으려면 Red Hat Registry에서 그릴 수 있습니다. Red Hat Registry는 인증되지 않고 더 이상 사용되지 않는 registry.access.redhat.com과 인증이 필요한 registry.redhat.io의 두 위치로 표시됩니다. Container images section of the Red Hat Ecosystem Catalog에서 Red Hat Registry의 Red Hat 및 파트너 이미지에 관해 알아볼 수 있습니다. Red Hat 컨테이너 이미지를 나열하는 것 외에도 적용된 보안 업데이트를 기반으로 한 상태 점수를 포함하여 해당 이미지의 내용과 품질에 대한 광범위한 정보를 보여줍니다.
대규모 공개 레지스트리에는 Docker Hub 및 Quay.io가 있습니다. Quay.io 레지스트리는 Red Hat이 소유하고 관리합니다. OpenShift Container Platform에 사용되는 많은 구성 요소는 컨테이너 이미지 및 OpenShift Container Platform 자체를 배포하는 데 사용되는 Operator를 포함하여 Quay.io에 저장됩니다. Quay.io는 Helm 차트를 포함하여 다른 유형의 콘텐츠를 저장하는 수단도 제공합니다.
고유한 개인 컨테이너 레지스트리를 원하는 경우 OpenShift Container Platform 자체에는 OpenShift Container Platform과 함께 설치되고 해당 클러스터에서 실행되는 개인 컨테이너 레지스트리가 포함됩니다. Red Hat은 Red Hat Quay라는 개인용 Quay.io 레지스트리 버전도 제공합니다. Red Hat Quay에는 지역 복제, Git 빌드 트리거, Clair 이미지 스캔 및 기타 여러 기능이 포함되어 있습니다.
여기에 언급된 모든 레지스트리는 해당 레지스트리에서 이미지를 다운로드하기 위해 자격 증명이 필요할 수 있습니다. 이러한 인증서 중 일부는 OpenShift Container Platform에서 클러스터 전체에 제공되는 반면 다른 자격 증명은 개인에게 할당될 수 있습니다.
