4.4. 카트리지 Versus 이미지

OpenShift v3에서는 OpenShift v2의 카트리지 개념을 대체했습니다.

OpenShift v2의 카트리지는 애플리케이션을 빌드하기 위한 핵심 요소였습니다. 각 카트리지는 필수 라이브러리, 소스 코드, 빌드 메커니즘, 연결 논리 및 라우팅 논리와 애플리케이션 구성 요소를 실행하도록 사전 구성된 환경과 함께 제공되었습니다.

하지만 카트리지에는 단점이 있었습니다. 카트리지를 사용하면 개발자 콘텐츠와 카트리지 콘텐츠를 명확하게 구분할 수 없으며, 애플리케이션의 각 기어에 있는 홈 디렉토리에 대한 소유권이 없었습니다. 또한 카트리지는 대형 바이너리를 위한 최상의 배포 메커니즘이 아니었습니다. 카트리지 내에서 외부 종속성을 사용할 수 있지만, 이렇게 하면 캡슐화의 이점이 사라집니다.

패키징 관점에서 이미지는 카트리지보다 더 많은 작업을 수행하고 캡슐화 및 유연성을 향상합니다. 그러나 카트리지에는 이미지에 존재하지 않는 빌드, 배포 및 라우팅을 위한 논리도 포함되어 있었습니다. OpenShift v3에서는 이러한 추가 요구 사항을 S 2I(Source-to-Image) 및 템플릿 구성에서 충족합니다.

종속성

OpenShift v2에서 카트리지 종속성은 카트리지 매니페스트에서 Configure-Order 또는 Requires 로 정의되었습니다. OpenShift v3에서는 포드 가 사전 정의된 상태에 따라 자체를 가져오는 선언적 모델을 사용합니다. 적용되는 명시적 종속성은 설치 시간 순서가 아닌 런타임에 수행됩니다.

예를 들어 시작하기 전에 다른 서비스를 사용할 수 있어야 할 수 있습니다. 이러한 종속성 점검은 두 구성 요소를 생성할 때뿐만 아니라 항상 적용할 수 있습니다. 따라서 종속성 검사를 런타임으로 푸시하면 시간이 지남에 따라 시스템이 정상 상태를 유지할 수 있습니다.

소프트웨어 컬렉션

OpenShift v2의 카트리지는 기어 내에 함께 배치되는 반면 OpenShift v3의 이미지는 1:1 매핑되며 컨테이너 는 포드를 공동 배치 메커니즘으로 사용합니다.

소스 코드

OpenShift v2에서는 애플리케이션에 하나의 Git 리포지토리가 있는 웹 프레임워크가 하나 이상 있어야 했습니다. OpenShift v3에서는 소스에서 빌드된 이미지를 선택할 수 있으며 해당 소스는 OpenShift 자체 외부에 있을 수 있습니다. 소스가 이미지와 연결이 끊기므로 이미지와 소스 선택은 소스가 선택 사항인 별도의 작업입니다.

Build

OpenShift v2에서는 애플리케이션 기어에서 빌드가 발생했습니다. 이로 인해 리소스 제약으로 인해 확장되지 않은 애플리케이션의 다운타임이 발생했습니다. v3에서는 별도의 컨테이너에서 빌드가 수행됩니다. 또한 OpenShift v2 빌드 결과는 rsync를 사용하여 기어를 동기화했습니다. v3에서 빌드 결과는 먼저 변경할 수 없는 이미지로 커밋되어 내부 레지스트리에 게시됩니다. 그러면 해당 이미지를 클러스터의 모든 노드에서 시작하거나 나중에 로 롤백할 수 있습니다.

라우팅

OpenShift v2에서는 애플리케이션이 확장 가능한지 여부와 애플리케이션의 라우팅 계층이 HA(고가용성)를 위해 활성화되었는지 여부에 따라 미리 선택해야 했습니다. OpenShift v3에서 경로 는 단순히 두 개 이상의 복제본으로 애플리케이션 구성 요소를 확장하여 HA를 사용할 수 있는 최상위 오브젝트입니다. 애플리케이션을 다시 생성하거나 DNS 항목을 변경할 필요가 없습니다.

경로 자체는 이미지와 분리되어 있습니다. 이전에는 카트리지가 기본 경로 세트를 정의했으며 애플리케이션에 별칭을 추가할 수 있었습니다. OpenShift v3에서는 템플릿을 사용하여 이미지의 경로를 원하는 만큼 설정할 수 있습니다. 이러한 경로를 사용하면 시스템 경로와 사용자 별칭을 구분하지 않고 원하는 대로 노출되는 체계, 호스트 및 경로를 수정할 수 있습니다.