설치 예시 IBM Process MiningCloud Pak 이미지를 프라이빗 컨테이너 레지스트리에 미러링하여 설치하는 예

v1.4.0 에서 시작하여 플러그인은 ~/.ibm-pak/data/cases/$CASE_NAME/$CASE_VERSION 디렉토리에 component-set-config.yaml 파일을 생성하여 CASE를 oc ibm-pak get 로 다운로드합니다. 이 파일은 다운로드된 모든 CASE을 캡처하여 이 특정 다운로드 중에 정확한 버전을 고정합니다. 이 파일을 사용하여 다른 환경에서 동일한 버전으로 동일한 CASE을 다운로드할 수 있습니다. 이 파일을 소스 코드 저장소에서 확인하고 이 파일을 사용하여 CASEs를 다운로드할 때마다 동일한 환경을 다시 만들 수 있습니다.

다음 명령을 실행하십시오.

oc ibm-pak get ibm-process-mining --insecure --skip-verify --version $CASE_VERSION

제품을 포함해야 하는 고정된 버전으로 CASE을 정의하여 이 파일을 편집할 수도 있습니다. 다음은 예제 파일( my-csc.yaml)의 내용입니다:

name: "example-product"                         # <required> defines the name for the "product"; this is NOT a CASE name, but follows IBM CASE name rules. For more information, see https://ibm.biz/case-yaml
version: "1.0.0"                                # <required> defines a version for the "product"
description: "an example product targeting OCP 4.9" # <optional, but recommended> defines a human readable description for this listing of components
cases:                                          # list of CASEs. First item in the list is assumed to be the "top-level" CASE, and all others are dependencies
- name: ibm-mas
 version: 5.5.2
 launch: true                                  # Exactly one CASE should have this field set to true. The launch scripts of that CASE are used as an entry point while executing 'ibm-pak launch' with a ComponentSetConfig
- name: ibm-cp-common-services
 version: 1.15.2

~/.ibm-pak 디렉터리 구조는 시간이 지남에 따라 CASE를 저장하고 미러링하면서 구축됩니다. 다음 트리는 연결된 미러링을 위한 ~/.ibm-pak 디렉터리 구조의 예를 보여줍니다:

tree ~/.ibm-pak
/root/.ibm-pak
├── config
│   └── config.yaml
├── data
│   ├── cases
│   │   └── YOUR-CASE-NAME
│   │       └── YOUR-CASE-VERSION
│   │           ├── XXXXX
│   │           ├── XXXXX
│   └── mirror
│       └── YOUR-CASE-NAME
│           └── YOUR-CASE-VERSION
│               ├── catalog-sources-linux-amd64.yaml
│               ├── catalog-sources.yaml
│               └── image-content-source-policy.yaml
|               └── image-digest-mirror-set.yaml
|               └── image-set-config.yaml
|
└── logs
   └── oc-ibm_pak.log

oc ibm-pak generate mirror-manifests 명령을 실행하면 ~/.ibm-pak/mirror 디렉터리가 새로 만들어집니다. 이 디렉터리에는 image-content-source-policy.yaml, image-set-config.yaml, catalog-sources.yaml 파일이 있습니다.

다음 트리는 연결이 끊긴 미러링의 ~/.ibm-pak 디렉터리 구조의 예를 보여줍니다:

tree ~/.ibm-pak
/root/.ibm-pak
├── config
│   └── config.yaml
├── data
│   ├── cases
│   │   └── ibm-cp-common-services
│   │       └── 1.9.0
│   │           ├── XXXX
│   │           ├── XXXX
│   └── mirror
│       └── ibm-cp-common-services
│           └── 1.9.0
│               ├── catalog-sources.yaml
│               ├── image-content-source-policy.yaml
│               ├── images-mapping-to-filesystem.txt
│               └── images-mapping-from-filesystem.txt
└── logs
   └── oc-ibm_pak.log

일부 제품은 --filter 인수와 이미지 그룹화를 사용하여 이미지의 하위 집합에 대해서만 미러 매니페스트를 생성하는 기능을 지원합니다. --filter 인수는 에어 갭 설치 중에 어떤 이미지를 미러링할지 사용자 지정할 수 있는 기능을 제공합니다. 이 기능의 예로 ibm-cloud-native-postgresql (표준 또는 엔터프라이즈)의 미러링 관련 변형을 허용하는 그룹이 포함된 ibm-cloud-native-postgresql CASE 을 사용할 수 있습니다. --filter 인수를 사용하여 전체 라이브러리가 아닌 ibm-cloud-native-postgresql 의 변형을 미러링 대상으로 지정합니다. 필터링은 그룹 및 아키텍처에 적용할 수 있습니다. 다음 명령을 고려하세요:

oc ibm-pak generate mirror-manifests \
   ibm-cloud-native-postgresql \
   file://local \
   --final-registry $TARGET_REGISTRY \
   --filter $GROUPS

이 명령은 --filter 인수를 사용하여 업데이트되었습니다. 예를 들어 ibmEdbStandard 과 동일한 $GROUPS 의 경우 미러 매니페스트는 표준 변형에서 ibm-cloud-native-postgresql 과 연결된 이미지에 대해서만 생성됩니다. 결과 이미지 그룹은 ibm-cloud-native-postgresql 이미지 그룹에 있는 이미지와 어떤 그룹에도 연결되지 않은 이미지로 구성됩니다. 이를 통해 제품에 공통 이미지를 포함할 수 있고 미러링해야 하는 이미지 수를 줄일 수 있습니다.

다음 명령을 사용하여 미러링할 모든 이미지와 해당 이미지를 가져올 공개적으로 액세스할 수 있는 레지스트리를 나열할 수 있습니다:

oc ibm-pak describe $CASE_NAME --version $CASE_VERSION --list-mirror-images

이전 명령의 출력에는 두 개의 섹션이 있습니다:

1. 소스에서 대상 레지스트리로 세부 정보 미러링
2. 대상에서 최종 레지스트리로 세부 정보를 미러링합니다.

앞의 명령 출력에서 Registries found 하위 섹션을 기록해 두세요. 이미지를 가져와 로컬 레지스트리에 미러링할 수 있도록 해당 레지스트리에 대해 인증해야 합니다. Top level namespaces found 섹션에는 이미지가 미러링될 네임스페이스 목록이 표시됩니다. 레지스트리에서 네임스페이스 자동 생성을 허용하지 않는 경우 레지스트리(명령 출력의 대상 열에 표시됨) 루트 경로에 이러한 네임스페이스를 수동으로 만들어야 합니다.

예를 들어,

podman login cp.icr.io
Username: cp
Password:
Login Succeeded!

예를 들어 REGISTRY_AUTH_FILE=~/.ibm-pak/auth.json 을 내보낸 다음 podman login 을 수행하면 파일이 레지스트리 자격 증명으로 채워지는 것을 볼 수 있습니다.

docker login 을 사용하는 경우 인증 파일은 일반적으로 컴퓨터의 경우 $HOME/.docker/config.json Linux 또는 Windows의 경우 %USERPROFILE%/.docker/config.json 에 있습니다. docker login 뒤에 해당 위치를 가리키도록 REGISTRY_AUTH_FILE 을 내보내야 합니다. 예를 들어 Linux 에서 다음 명령을 실행할 수 있습니다:

export REGISTRY_AUTH_FILE=$HOME/.docker/config.json