절차

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.

3. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.

   참고

   서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

4. 설치를 클릭합니다.

   설치된 Operators 페이지에서 Migration Toolkit for Containers Operator는 openshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

5. Migration Toolkit for Containers Operator를 클릭합니다.
6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
7. 생성을 클릭합니다.
8. 워크로드 → 포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

프로세스

1. Red Hat Customer Portal 자격 증명을 사용하여 registry.redhat.io에 로그인합니다.

   $ sudo podman login registry.redhat.io

2. operator.yml 파일을 다운로드합니다.

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./

3. controller-3.yml 파일을 다운로드합니다.

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./

4. OpenShift Container Platform 3 클러스터에 로그인합니다.

5. 클러스터가 registry.redhat.io로 인증할 수 있는지 확인합니다.

   $ oc run test --image registry.redhat.io/ubi8 --command sleep infinity

6. Migration Toolkit for Containers Operator 오브젝트 생성:

   $ oc create -f operator.yml

   출력 예

   namespace/openshift-migration created
   rolebinding.rbac.authorization.k8s.io/system:deployers created
   serviceaccount/migration-operator created
   customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
   role.rbac.authorization.k8s.io/migration-operator created
   rolebinding.rbac.authorization.k8s.io/migration-operator created
   clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
   deployment.apps/migration-operator created
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

   1

   Error from server (AlreadyExists) 메시지를 무시할 수 있습니다. 이 메시지는 Migration Toolkit for Containers Operator가 이후 릴리스에서 제공되는 OpenShift Container Platform 3 이전 버전용 리소스를 생성하기 때문에 발생합니다.

7. MigrationController 오브젝트를 만듭니다.

   $ oc create -f controller-3.yml

8. Velero 및 Restic Pod가 실행 중인지 확인합니다.

   $ oc get pods -n openshift-migration

프로세스

1. registry.redhat.io로 인증합니다.

   $ podman login registry.redhat.io

2. 대상 레지스트리로 인증합니다.

   $ podman login <target_registry>

3. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

   1. 컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.6

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.6...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

   2. 별도의 터미널 세션에서 grpcurl 명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

   3. packages.out 파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.

      패키지 목록 조각의 예

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

   4. podman run 명령을 실행한 터미널 세션에서 Ctrl 및 C를 눌러 컨테이너 프로세스를 중지합니다.

4. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

   $ opm index prune \
       -f registry.redhat.io/redhat/redhat-operator-index:v4.6 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.6] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6 4

   1

   정리할 인덱스입니다.

   2

   쉼표로 구분된 보관할 패키지 목록입니다.

   3

   IBM Power Systems 및 IBM Z 이미지에만 필요합니다. 대상 OpenShift Container Platform 클러스터 주 버전 및 부 버전과 일치하는 태그가 있는 Operator 레지스트리 기본 이미지입니다.

   4

   빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.

5. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

   $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6

   <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

프로세스

1. Red Hat 제공 카탈로그를 미러링하려면 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 registry.redhat.io로 인증합니다.

   $ podman login registry.redhat.io

2. oc adm catalog mirror 명령은 인덱스 이미지의 콘텐츠를 추출하여 미러링에 필요한 매니페스트를 생성합니다. 명령의 기본 동작은 매니페스트를 생성한 다음 인덱스 이미지 자체뿐만 아니라 인덱스 이미지의 모든 이미지 콘텐츠를 미러 레지스트리에 자동으로 미러링합니다. 또는 미러 레지스트리가 완전히 연결이 끊긴 호스트 또는 에어갭(Airgap) 호스트에 있는 경우 먼저 콘텐츠를 이동식 미디어로 미러링하고 미디어를 연결이 끊긴 환경으로 이동한 다음 미디어에서 레지스트리로 해당 콘텐츠를 미러링할 수 있습니다.

   • 옵션 A: 미러 레지스트리가 무제한 네트워크 액세스 권한이 있는 워크스테이션과 동일한 네트워크에 있는 경우 워크스테이션에서 다음 작업을 수행합니다.

     1. 미러 레지스트리에 인증이 필요한 경우 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>

     2. 다음 명령을 실행하여 콘텐츠를 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6

        1

        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.6 과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.

        2

        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

        3

        선택 사항: 필요한 경우 레지스트리 자격 증명 파일의 위치를 지정합니다.

        4

        선택 사항: 대상 레지스트리에 대한 신뢰성을 구성하지 않으려면 --insecure 플래그를 추가합니다.

        5

        선택 사항: 여러 변형을 사용할 수 있을 때 선택할 인덱스 이미지의 플랫폼 및 아키텍처를 지정합니다. 이미지는 '<platform>/<arch>[/<variant>]’로 전달됩니다. 이는 인덱스에서 참조하는 이미지에는 적용되지 않습니다. 유효한 값은 linux/amd64, linux/ppc64le 및 linux/s390x입니다.

        6

        선택 사항: 미러링에 필요한 매니페스트만 생성하고 실제로 이미지 콘텐츠를 레지스트리에 미러링하지 않습니다. 이 선택 사항은 미러링할 항목을 검토하는 데 유용할 수 있으며 패키지의 서브 세트만 필요한 경우 매핑 목록을 변경할 수 있습니다. 그런 다음 oc image mirror 명령과 함께 mapping.txt 파일을 사용하여 이후 단계에서 수정된 이미지 목록을 미러링할 수 있습니다. 이 플래그는 카탈로그에서 콘텐츠의 고급 선택적 미러링에만 사용됩니다. 이전에 인덱스 이미지를 정리하기 위해 사용한 경우 opm index prune 명령은 대부분의 카탈로그 관리 사용 사례에 적합합니다.

        출력 예

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1

        명령으로 생성된 임시 index.db 데이터베이스용 디렉터리입니다.

        2

        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.

   • 옵션 B: 미러 레지스트리가 연결이 끊긴 호스트에 있는 경우 다음 작업을 수행합니다.

     1. 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 콘텐츠를 로컬 파일에 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.6 과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.

        2

        현재 디렉터리의 로컬 파일에 콘텐츠를 미러링합니다.

        출력 예

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1

        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.

        2

        제공된 인덱스 이미지를 기반으로 확장된 file:// 경로를 기록합니다. 이 경로는 이후 단계에서 사용됩니다.

     2. 현재 디렉터리에 생성된 v2/ 디렉터리를 이동식 미디어로 복사합니다.
     3. 물리적으로 미디어를 제거하고 연결이 끊긴 환경의 호스트에 연결하여 미러 레지스트리에 액세스할 수 있습니다.

     4. 미러 레지스트리에 인증이 필요한 경우 연결이 끊긴 환경의 호스트에서 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>

     5. v2/ 디렉터리가 포함된 상위 디렉터리에서 다음 명령을 실행하여 로컬 파일에서 미러 레지스트리로 이미지를 업로드합니다.

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        이전 명령 출력의 file:// 경로를 지정합니다.

        2

        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

3. 콘텐츠를 레지스트리에 미러링한 후 현재 디렉터리에 생성된 매니페스트 디렉터리를 검사합니다.

   참고

   매니페스트 디렉터리 이름은 이후 단계에서 사용됩니다.

   이전 단계에서 동일한 네트워크의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

   manifests-<index_image_name>-<random_number>

   이전 단계에서 연결이 끊긴 호스트의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

   manifests-index/<namespace>/<index_image_name>-<random_number>

   매니페스트 디렉터리에는 다음 파일이 포함되어 있으며, 이 중 일부는 추가 수정이 필요할 수 있습니다.

   • catalogSource.yaml 파일은 인덱스 이미지 태그 및 기타 관련 메타데이터로 미리 채워진 CatalogSource 오브젝트에 대한 기본 정의입니다. 이 파일은 있는 그대로 사용하거나 카탈로그 소스를 클러스터에 추가하도록 수정할 수 있습니다.

     중요

     콘텐츠를 로컬 파일에 미러링한 경우 metadata.name 필드에서 .name 필드에서 백슬래시(/) 문자를 제거하려면 catalogSource.yaml 파일을 수정해야 합니다. 그러지 않으면 오브젝트 생성을 시도할 때 "잘못된 리소스 이름" 오류로 인해 실패합니다.

   • imageContentSourcePolicy.yaml 파일은 Operator 매니페스트에 저장된 이미지 참조와 미러링된 레지스트리 간에 변환하도록 노드를 구성할 수 있는 ImageContentSourcePolicy 오브젝트를 정의합니다.

     참고

     클러스터에서 ImageContentSourcePolicy 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에 대한 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

   • mapping.txt 파일에는 모든 소스 이미지와 대상 레지스트리에서 매핑할 위치가 포함되어 있습니다. 이 파일은 oc image mirror 명령과 호환되며 미러링 구성을 추가로 사용자 정의하는 데 사용할 수 있습니다.

     중요

     미러링 프로세스 중 --manifests-only 플래그를 사용한 후 미러링할 패키지의 서브 세트를 추가로 트리밍하려면 mapping.txt 파일을 수정하고 oc image mirror 명령으로 파일을 사용하는 데 대한 “패키지 매니페스트 형식 카탈로그 이미지 미러링” 절차의 단계를 참조하십시오. 추가 조치를 수행한 후 이 프로세스를 계속할 수 있습니다.

4. 연결 해제된 클러스터에 액세스할 수 있는 호스트에서 매니페스트 디렉터리에 imageContentSourcePolicy.yaml 파일을 지정하도록 다음 명령을 실행하여 ImageContentSourcePolicy 오브젝트를 생성합니다.

   $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

   여기서 <path/to/manifests/dir>은 미러링된 콘텐츠의 매니페스트 디렉터리 경로입니다.

프로세스

1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다.

   1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.6 1
        displayName: My Operator Catalog
        publisher: <publisher_name> 2
        updateStrategy:
          registryPoll: 3
            interval: 30m

      1

      인덱스 이미지를 지정합니다.

      2

      카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다.

      3

      카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.

   2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml

2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

   1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

절차

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.

3. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.

   참고

   서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

4. 설치를 클릭합니다.

   설치된 Operators 페이지에서 Migration Toolkit for Containers Operator는 openshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

5. Migration Toolkit for Containers Operator를 클릭합니다.
6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
7. 생성을 클릭합니다.
8. 워크로드 → 포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

절차

1. 무제한 네트워크 액세스가 가능한 워크스테이션에서 Red Hat Customer Portal 자격 증명을 사용하여 registry.redhat.io에 로그인합니다.

   $ sudo podman login registry.redhat.io

2. operator.yml 파일을 다운로드합니다.

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./

3. controller-3.yml 파일을 다운로드합니다.

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./

4. OpenShift Container Platform 4 클러스터에서 oc adm catalog mirror 를 실행할 때 작성된 mapping.txt 파일에서 Operator 이미지 값을 확보합니다.

   $ grep openshift-migration-rhel7-operator ./mapping.txt | grep rhmtc

   출력은 registry.redhat.io 이미지와 미러 레지스트리 이미지 간의 매핑을 보여줍니다.

   출력 예

   registry.redhat.io/rhmtc/openshift-migration-rhel7-operator@sha256:468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a=<registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator

5. Operator 구성 파일에서 image 및 REGISTRY 값을 업데이트합니다.

   containers:
     - name: ansible
       image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 1
   ...
     - name: operator
       image: <registry.apps.example.com>/rhmtc/openshift-migration-rhel7-operator@sha256:<468a6126f73b1ee12085ca53a312d1f96ef5a2ca03442bcb63724af5e2614e8a> 2
   ...
       env:
       - name: REGISTRY
         value: <registry.apps.example.com> 3

   1

   mapping.txt 파일에 미러 레지스트리와 Operator 이미지의 sha256 값을 지정합니다.

   2

   mapping.txt 파일에 미러 레지스트리와 Operator 이미지의 sha256 값을 지정합니다.

   3

   미러 레지스트리를 지정합니다.

6. OpenShift Container Platform 3 클러스터에 로그인합니다.

7. Migration Toolkit for Containers Operator 오브젝트 생성:

   $ oc create -f operator.yml

   출력 예

   namespace/openshift-migration created
   rolebinding.rbac.authorization.k8s.io/system:deployers created
   serviceaccount/migration-operator created
   customresourcedefinition.apiextensions.k8s.io/migrationcontrollers.migration.openshift.io created
   role.rbac.authorization.k8s.io/migration-operator created
   rolebinding.rbac.authorization.k8s.io/migration-operator created
   clusterrolebinding.rbac.authorization.k8s.io/migration-operator created
   deployment.apps/migration-operator created
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-builders" already exists 1
   Error from server (AlreadyExists): error when creating "./operator.yml":
   rolebindings.rbac.authorization.k8s.io "system:image-pullers" already exists

   1

   Error from server (AlreadyExists) 메시지를 무시할 수 있습니다. 이 메시지는 Migration Toolkit for Containers Operator가 이후 릴리스에서 제공되는 OpenShift Container Platform 3 이전 버전용 리소스를 생성하기 때문에 발생합니다.

8. MigrationController 오브젝트를 만듭니다.

   $ oc create -f controller-3.yml

9. Velero 및 Restic Pod가 실행 중인지 확인합니다.

   $ oc get pods -n openshift-migration

절차

1. OpenShift Container Platform 콘솔에서 Operators > 설치된 Operators로 이동합니다.

   보류 중인 업그레이드가 있는 Operator에 업그레이드 사용 가능 상태가 표시됩니다.

2. Migration Toolkit for Containers Operator를 클릭합니다.
3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업그레이드는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
5. 업그레이드에 사용할 수 있는 리소스를 보고 승인을 클릭합니다.
6. Operator → 설치된 Operator 페이지로 이동하여 업그레이드 진행 상황을 모니터링합니다. 완료되면 상태가 성공 및 최신으로 변경됩니다.
7. 워크로드 → Pod를 클릭하여 MTC pod가 실행 중인지 확인합니다.

절차

1. Red Hat Customer Portal 자격 증명을 사용하여 registry.redhat.io에 로그인합니다.

   $ sudo podman login registry.redhat.io

2. 최신 operator.yml 파일을 다운로드합니다.

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/operator.yml ./ 1

   1

   필요한 경우 z-stream 릴리스를 지정할 수 있습니다.

3. Migration Toolkit for Containers Operator를 대체합니다.

   $ oc replace --force -f operator.yml

4. 변경 사항을 적용합니다.

   • MTC 1.1.2 및 이전 버전의 경우 Restic pod를 삭제합니다.

     $ oc delete pod <restic_pod>

   • MTC 1.2 이상 버전의 경우:

     1. migration-operator 배포를 0으로 확장하여 배포를 중지합니다.

        $ oc scale -n openshift-migration --replicas=0 deployment/migration-operator

     2. migration-operator 배포를 1로 확장하여 배포를 시작하고 변경 사항을 적용합니다.

        $ oc scale -n openshift-migration --replicas=1 deployment/migration-operator

5. migration-operator가 업그레이드되었는지 확인합니다.

   $ oc -o yaml -n openshift-migration get deployment/migration-operator | grep image: | awk -F ":" '{ print $NF }'

6. 최신 controller-3.yml 파일을 다운로드합니다.

   $ sudo podman cp $(sudo podman create \
     registry.redhat.io/rhmtc/openshift-migration-rhel7-operator:v1.4):/controller-3.yml ./

7. migration-controller 오브젝트를 만듭니다.

   $ oc create -f controller-3.yml

8. OpenShift Container Platform 버전이 3.10 이하인 경우 직접 이미지 마이그레이션 및 직접 볼륨 마이그레이션을 활성화하려면 migration-controller 서비스 계정의 보안 컨텍스트 제약 조건을 anyuid로 설정합니다.

   $ oc adm policy add-scc-to-user anyuid -z migration-controller -n openshift-migration

9. MTC pod가 실행 중인지 확인합니다.

   $ oc get pods -n openshift-migration

10. 이전에 OpenShift Container Platform 3 클러스터를 MTC 웹 콘솔에 추가한 경우 업그레드 프로세스에서 openshift-migration 네임스페이스를 삭제하고 복원하므로 웹 콘솔에서 서비스 계정 토큰을 업데이트해야 합니다.

    1. 서비스 계정 토큰을 확보합니다.

       $ oc sa get-token migration-controller -n openshift-migration

    2. MTC 웹 콘솔에서 클러스터를 클릭합니다.
    3. 클러스터 옆에 있는 옵션 메뉴를 클릭하고 편집을 선택합니다.
    4. 서비스 계정 토큰 필드에 새 서비스 계정 토큰을 입력합니다.
    5. 클러스터 업데이트를 클릭한 다음 닫기를 클릭합니다.

절차

1. MigrationController Pod를 실행하는 클러스터에 로그인합니다.

2. MigPlan CR 매니페스트를 가져옵니다.

   $ oc get migplan <migplan> -o yaml -n openshift-migration

3. 다음 매개변수 값을 업데이트하고 파일을 migplan.yaml로 저장합니다.

   ...
   spec:
     indirectImageMigration: true
     indirectVolumeMigration: true

4. MigPlan CR 매니페스트를 교체하여 변경 사항을 적용합니다.

   $ oc replace -f migplan.yaml -n openshift-migration

5. 업데이트된 MigPlan CR 매니페스트를 가져와 변경 사항을 확인합니다.

   $ oc get migplan <migplan> -o yaml -n openshift-migration

프로세스

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링(이 경우 OCS)을 사용하여 OpenShift Container Storage Operator를 찾습니다.
3. OpenShift Container Storage Operator를 선택하고 설치를 클릭합니다.
4. 업데이트 채널, 설치 모드 및 승인 전략을 선택합니다.

5. 설치를 클릭합니다.

   설치된 운영자 페이지에서 OpenShift Container Storage Operator가 openshift-storage 프로젝트에 Succeeded 상태로 나타납니다.

프로세스

1. OpenShift Container Platform 클러스터에 로그인합니다.

   $ oc login

2. 다음과 같은 내용과 함께 NooBaa CR 구성 파일, noobaa.yml을 생성합니다.

   apiVersion: noobaa.io/v1alpha1
   kind: NooBaa
   metadata:
     name: noobaa
     namespace: openshift-storage
   spec:
    dbResources:
      requests:
        cpu: 0.5 1
        memory: 1Gi
    coreResources:
      requests:
        cpu: 0.5 2
        memory: 1Gi

   1 2

   매우 작은 클러스터의 경우 cpu 값을 0.1로 변경할 수 있습니다.

3. NooBaa 오브젝트를 생성합니다.

   $ oc create -f noobaa.yml

4. 다음과 같은 내용과 함께 BackingStore CR 구성 파일 bs.yml을 생성합니다.

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: mcg-pv-pool-bs
     namespace: openshift-storage
   spec:
     pvPool:
       numVolumes: 3 1
       resources:
         requests:
           storage: 50Gi 2
       storageClass: gp2 3
     type: pv-pool

   1

   영구 볼륨 풀에서 볼륨 수를 지정합니다.

   2

   볼륨의 크기를 지정합니다.

   3

   스토리지 클래스를 지정합니다.

5. BackingStore 오브젝트를 생성합니다.

   $ oc create -f bs.yml

6. 다음과 같은 내용으로 BucketClass CR 구성 파일, bc.yml을 생성합니다.

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     labels:
       app: noobaa
     name: mcg-pv-pool-bc
     namespace: openshift-storage
   spec:
     placementPolicy:
       tiers:
       - backingStores:
         - mcg-pv-pool-bs
         placement: Spread

7. BucketClass 오브젝트를 생성합니다.

   $ oc create -f bc.yml

8. 다음과 같은 내용과 함께 ObjectBucketClaim CR 구성 파일, obc.yml을 생성합니다.

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: migstorage
     namespace: openshift-storage
   spec:
     bucketName: migstorage 1
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: mcg-pv-pool-bc

   1

   MTC 웹 콘솔에 복제 리포지토리를 추가하기 위한 버킷 이름을 기록합니다.

9. ObjectBucketClaim 오브젝트를 생성합니다.

   $ oc create -f obc.yml

10. 리소스 생성 프로세스를 보고 ObjectBucketClaim 상태가 Bound인지 확인합니다.

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    이 프로세스는 5-10분 정도 걸릴 수 있습니다.

11. MTC 웹 콘솔에 복제 리포지토리를 추가할 때 필요한 다음 값을 확보하고 기록합니다.

    • S3 끝점:

      $ oc get route -n openshift-storage s3

    • S3 공급자 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode

    • S3 공급자 보안 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

절차

1. 소스 및 대상 클러스터에 내부 레지스트리를 노출합니다.
2. 비보안 레지스트리를 사용하는 경우 /etc/container/registries.conf의 [registries.insecure] 섹션에 레지스트리 호스트 값을 추가하여 Podman TLS 확인 오류가 발생하지 않도록 합니다.

3. 소스 클러스터 레지스트리에 로그인합니다.

   $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <source_cluster>

4. 대상 클러스터 레지스트리에 로그인합니다.

   $ podman login -u $(oc whoami) -p $(oc whoami -t) --tls-verify=false <target_cluster>

5. 더 이상 사용되지 않는 이미지를 가져옵니다.

   $ podman pull <source_cluster>/openshift/<image>

6. 대상 클러스터 레지스트리의 이미지를 태그합니다.

   $ podman tag <source_cluster>/openshift/<image> <target_cluster>/openshift/<image>

7. 대상 클러스터 4 레지스트리로 이미지를 푸시합니다.

   $ podman push <target_cluster>/openshift/<image>

8. 이미지에 대상 클러스터에 유효한 이미지 스트림이 있는지 확인합니다.

   $ oc get imagestream -n openshift | grep <image>

   출력 예

   <image>    <target_cluster>/openshift/<image>     <versions>
   more...      6 seconds ago

절차

1. MigrationController Pod가 실행되는 클러스터에 로그인합니다.

2. MigrationController CR 매니페스트를 가져옵니다.

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

3. stunnel_tcp_proxy 매개변수를 추가합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: <stunnel_proxy> 1

   1

   Stunnel 프록시를 지정합니다. http://<user_name>:<password>@<ip_address>:<port>

4. 매니페스트를 migration-controller.yaml로 저장합니다.

5. 업데이트된 매니페스트를 적용합니다.

   $ oc replace -f migration-controller.yaml -n openshift-migration

절차

1. MTC를 설치한 OpenShift Container Platform 클러스터에 로그인합니다.

2. 다음 명령을 입력하여 MTC 웹 콘솔 URL을 확보합니다.

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   출력은 https://migration-openshift-migration.apps.cluster.openshift.com과 유사합니다.

3. 브라우저를 시작하고 MTC 웹 콘솔로 이동합니다.

   참고

   Migration Toolkit for Containers Operator를 설치한 직후 MTC 웹 콘솔에 액세스하려고 하면 Operator가 여전히 클러스터를 구성하고 있기 때문에 콘솔이 로드되지 않을 수 있습니다. 몇 분 기다렸다가 다시 시도하십시오.

4. 자체 서명된 CA 인증서를 사용하는 경우 소스 클러스터 API 서버의 CA 인증서를 수락하라는 메시지가 표시됩니다. 웹 페이지는 나머지 인증서 수락 프로세스를 안내합니다.
5. OpenShift Container Platform 사용자 이름 및 암호로 로그인합니다.

프로세스

1. 클러스터에 로그인합니다.

2. migration-controller 서비스 계정 토큰을 확보합니다.

   $ oc sa get-token migration-controller -n openshift-migration

   출력 예

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. MTC 웹 콘솔에서 클러스터를 클릭합니다.
4. 클러스터 추가를 클릭합니다.

5. 다음 필드를 작성합니다.

   • 클러스터 이름: 클러스터 이름은 소문자(a-z) 및 숫자(0-9)를 포함할 수있습니다. 공백이나 국제 문자를 포함해서는 안 됩니다.
   • URL: API 서버 URL을 지정합니다(예: https://<www.example.com>:8443 ).
   • 서비스 계정 토큰: migration-controller 서비스 계정 토큰을 붙여넣습니다.

   • 이미지 레지스트리에 노출된 경로 호스트: 직접 이미지 마이그레이션을 사용하는 경우 소스 클러스터의 이미지 레지스트리에 노출된 경로를 지정합니다(예: www.example.apps.cluster.com).

     포트를 지정할 수 있습니다. 기본 포트는 5000입니다.

   • Azure 클러스터: Azure 스냅샷을 사용하여 데이터를 복사하는 경우 이 옵션을 선택해야 합니다.
   • Azure 리소스 그룹: Azure 클러스터가 선택된 경우 이 필드가 표시됩니다. Azure 리소스 그룹을 지정합니다.
   • SSL 확인 필요 : 선택 사항: 이 옵션을 선택하여 클러스터에 대한 SSL 연결을 확인합니다.
   • CA 번들 파일: Require SSL 확인이 선택되어 있으면 이 필드가 표시됩니다. 자체 서명된 인증서에 대한 사용자 정의 CA 인증서 번들 파일을 생성한 경우 찾아보기를 클릭하고 CA 번들 파일을 선택하여 업로드합니다.

6. 클러스터 추가를 클릭합니다.

   클러스터가 클러스터 목록에 나타납니다.

프로세스

1. MTC 웹 콘솔에서 복제 리포지토리를 클릭합니다.
2. 리포지토리 추가를 클릭합니다.

3. 스토리지 공급자 유형을 선택하고 다음 필드를 작성합니다.

   • AWS S3, MCG 및 일반 S3 공급자용 AWS:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • S3 버킷 이름: 생성한 S3 버킷의 이름을 지정합니다.
     • S3 버킷 영역: S3 버킷 리전을 지정합니다. AWS S3의 경우 필수입니다. 다른 S3 공급자의 경우 선택 사항입니다.
     • S3 끝점: 버킷이 아닌 S3 서비스의 URL을 지정합니다(예: https://<s3-storage.apps.cluster.com&gt;). 일반 S3 공급자의 경우 필수입니다. https:// 접두사를 사용해야 합니다.
     • S3 공급자 액세스 키: AWS의 경우 <AWS_SECRET_ACCESS_KEY> 또는 MCG의 경우 S3 공급자 액세스 키를 지정합니다.
     • S3 공급자 보안 액세스 키: AWS의 경우 <AWS_ACCESS_KEY_ID> 또는 MCG의 경우 S3 공급자 보안 액세스 키를 지정합니다.
     • SSL 확인 필요 : 일반 S3 공급자를 사용하는 경우 이 확인란을 지웁니다.
     • 사용자 정의 CA 번들을 사용하는 경우 찾아보기를 클릭하고 Base64 인코딩된 CA 번들 파일을 찾습니다.

   • GCP:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • GCP 버킷 이름: GCP 버킷의 이름을 지정합니다.
     • GCP 자격 증명 JSON blob: credentials-velero 파일에서 문자열을 지정합니다.

   • Azure:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • Azure 리소스 그룹: Azure Blob 스토리지의 리소스 그룹을 지정합니다.
     • Azure 스토리지 계정 이름: Azure Blob 스토리지 계정 이름을 지정합니다.
     • Azure 인증 정보 - INI 파일 콘텐츠: credentials-velero 파일에서 문자열을 지정합니다.
4. 리포지토리 추가를 클릭하고 연결 유효성 검사를 기다립니다.

5. 닫기를 클릭합니다.

   새 리포지토리가 복제 리포지토리 목록에 나타납니다.

절차

1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
2. 마이그레이션 계획 추가를 클릭합니다.

3. 계획 이름을 입력하고 다음 클릭합니다.

   마이그레이션 계획 이름에서 253자의 소문자 영숫자(a-z, 0-9)를 초과해서는 안 되며 공백이나 밑줄(_)을 포함해서는 안 됩니다.

4. 소스 클러스터를 선택합니다.
5. 대상 클러스터를 선택합니다.
6. 복제 리포지토리를 선택합니다.
7. 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
8. 소스 클러스터, 대상 클러스터, 리포지토리를 선택하고 다음을 클릭합니다.
9. 네임스페이스 페이지에서 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.

10. 영구 볼륨 페이지에서 각 PV의 마이그레이션 유형을 클릭합니다.

    • 복사 옵션은 소스 클러스터의 PV에 있는 데이터를 복제 리포지토리에 복사한 다음 대상 클러스터에서 비슷한 특성을 가진 새로 생성된 PV에 데이터를 복원합니다.
    • 이동 옵션은 소스 클러스터에서 원격 볼륨(예: NFS)을 마운트 해제하고 원격 볼륨을 가리키는 대상 클러스터에 PV 리소스를 생성한 다음 대상 클러스터에 원격 볼륨을 마운트합니다. 대상 클러스터에서 실행되는 애플리케이션은 소스 클러스터와 동일한 원격 볼륨을 사용합니다.
11. 다음을 클릭합니다.

12. 복사 옵션 페이지에서 각 PV에 대한 복사 방법을 선택합니다.

    • 스냅샷 복사는 클라우드 공급자의 스냅샷 기능을 사용하여 데이터를 백업 및 복원합니다. 파일 시스템 복사.보다 훨씬 빠릅니다.

    • 파일 시스템 복사는 소스 클러스터에서 파일을 백업하고 대상 클러스터에서 해당 파일을 복원합니다.

      직접 볼륨 마이그레이션에는 파일 시스템 복사 방법이 필요합니다.

13. 복사 확인을 선택하여 파일 시스템 복사로 마이그레이션된 데이터를 확인할 수 있습니다. 데이터는 각 소스 파일에 대한 체크섬을 생성하고 복원 후 체크섬을 확인합니다. 데이터 확인으로 성능이 크게 저하합니다.

14. 대상 스토리지 클래스를 선택합니다.

    파일 시스템 복사를 선택한 경우 대상 스토리지 클래스를 변경할 수 있습니다.

15. 다음을 클릭합니다.

16. 마이그레이션 옵션 페이지에서 소스 클러스터에 대해 노출된 이미지 레지스트리 경로를 지정한 경우 직접 이미지 마이그레이션 옵션이 선택됩니다. 파일 시스템 복사로 데이터를 마이그레이션하는 경우 직접 PV 마이그레이션 옵션이 선택됩니다.

    직접 마이그레이션 옵션은 소스 클러스터에서 대상 클러스터로 직접 이미지 및 파일을 복사합니다. 이 옵션은 소스 클러스터에서 복제 리포지토리로 이미지 및 파일을 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사합니다.

17. 다음을 클릭합니다.

18. 선택 사항: 후크 페이지에서 후크 추가를 클릭하여 마이그레이션 계획에 후크를 추가합니다.

    후크는 사용자 지정 코드를 실행합니다. 단일 마이그레이션 계획에 최대 4개의 후크를 추가할 수 있습니다. 각 후크는 다른 마이그레이션 단계에서 실행됩니다.

    1. 웹 콘솔에 표시할 후크 이름을 입력합니다.
    2. 후크가 Ansible 플레이북인 경우 Ansible 플레이북을 선택하고 찾아보기를 클릭하여 플레이북을 업로드하거나 필드에 플레이북 콘텐츠를 붙여넣습니다.
    3. 선택 사항: 기본 후크 이미지를 사용하지 않는 경우 Ansible 런타임 이미지를 지정합니다.

    4. 후크가 Ansible 플레이북이 아닌 경우 사용자 정의 컨테이너 이미지를 선택하고 이미지 이름과 경로를 지정합니다.

       사용자 정의 컨테이너 이미지에는 Ansible 플레이북이 포함될 수 있습니다.

    5. 소스 클러스터 또는 대상 클러스터를 선택합니다.
    6. 서비스 계정 이름과 서비스 계정 네임스페이스를 입력합니다.

    7. 후크의 마이그레이션 단계를 선택합니다.

       • preBackup: 애플리케이션 워크로드를 소스 클러스터에서 백업하기 전에
       • postBackup: 소스 클러스터에서 애플리케이션 워크로드를 백업한 후
       • preRestore: 대상 클러스터에서 애플리케이션 워크로드를 복원하기 전에
       • postRestore: 대상 클러스터에서 애플리케이션 워크로드를 복원한 후
    8. 추가를 클릭합니다.

19. 완료를 클릭합니다.

    마이그레이션 계획이 마이그레이션 계획 목록에 표시됩니다.

프로세스

1. 소스 클러스터에 로그인합니다.

2. 오래된 이미지 삭제:

   $ oc adm prune images

3. MTC 웹 콘솔에 로그인하고 마이그레이션 계획을 클릭합니다.

4. 마이그레이션 계획 옆에 있는 옵션 메뉴 를 클릭하고 단계를 선택하여 애플리케이션을 중지하지 않고 소스 클러스터에서 대상 클러스터로 데이터를 복사합니다.

   실제 마이그레이션 시간을 줄이기 위해 단계를 여러 번 실행할 수 있습니다.

5. 애플리케이션 워크로드를 마이그레이션할 준비가 되면 마이그레이션 계획 외의 옵션 메뉴 를 선택하고 마이그레이션을 선택합니다.
6. 선택 사항: 마이그레이션 창에서 마이그레이션 중에 소스 클러스터에서 애플리케이션을 중지하지 않음을 선택할 수 있습니다.
7. 마이그레이션을 클릭합니다.

8. 마이그레이션이 완료되면 OpenShift Container Platform 웹 콘솔에서 애플리케이션이 성공적으로 마이그레이션되었는지 확인합니다.

   1. 홈 → 프로젝트를 클릭합니다.
   2. 마이그레이션된 프로젝트를 클릭하여 상태를 봅니다.
   3. 경로 섹션에서 위치를 클릭하여 해당되는 경우 애플리케이션이 작동하는지 확인합니다.
   4. 워크로드 → 포드를 클릭하여 포드가 마이그레이션된 네임스페이스에서 실행 중인지 확인합니다.
   5. 스토리지 → 영구 볼륨을 클릭하여 마이그레이션된 영구 볼륨이 올바르게 프로비저닝되었는지 확인합니다.

프로세스

1. host-cluster.yaml이라는 host 클러스터에 대한 MigCluster CR 매니페스트를 생성합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: host
     namespace: openshift-migration
   spec:
     isHostCluster: true

2. host 클러스터에 대한 MigCluster CR을 생성합니다.

   $ oc create -f host-cluster.yaml -n openshift-migration

3. cluster-secret.yaml이라는 각 원격 클러스터에 대한 Secret CR 매니페스트를 생성합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1

   1

   원격 클러스터의 base64로 인코딩된 migration-controller 서비스 계정(SA) 토큰을 지정합니다.

   다음 명령을 실행하여 SA 토큰을 확보할 수 있습니다.

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

4. 각 원격 클러스터에 대한 Secret CR을 생성합니다.

   $ oc create -f cluster-secret.yaml

5. remote-cluster.yaml이라는 각 원격 클러스터에 대해 MigCluster CR 매니페스트를 생성합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster>
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 1
     insecure: false 2
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 3
       namespace: openshift-config
     url: <remote_cluster_url> 4

   1

   선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 노출된 레지스트리 경로를 지정합니다(예: docker-registry-default.apps.example.com ).

   2

   false인 경우 SSL 확인이 활성화됩니다. CA 인증서가 필요하지 않거나 true인 경우 확인되지 않습니다.

   3

   원격 클러스터의 Secret CR을 지정합니다.

   4

   원격 클러스터의 URL을 지정합니다.

6. 각 원격 클러스터에 대해 MigCluster CR을 생성합니다.

   $ oc create -f remote-cluster.yaml -n openshift-migration

7. 모든 클러스터가 Ready 상태에 있는지 확인합니다.

   $ oc describe cluster <cluster_name>

8. storage-secret.yaml이라는 복제 리포지토리의 Secret CR 매니페스트를 생성합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 1
     aws-secret-access-key: <secret_key_base64> 2

   1

   base64 형식으로 키 ID를 지정합니다.

   2

   base64 형식으로 시크릿 키를 지정합니다.

   AWS 인증 정보는 기본적으로 base64로 인코딩됩니다. 다른 스토리지 공급자를 사용하는 경우 각 키로 다음 명령을 실행하여 인증 정보를 인코딩해야 합니다.

   $ echo -n "<key>" | base64 -w 0 1

   1

   키 ID 또는 시크릿 키를 지정합니다. 두 키 모두 base64로 인코딩되어야 합니다.

9. 복제 리포지토리에 대한 Secret CR을 생성합니다.

   $ oc create -f storage-secret.yaml

10. migstorage.yaml이라는 복제 리포지토리에 대한 MigStorage CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5

    1

    버킷 이름을 지정합니다.

    2

    오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.

    3

    스토리지 공급자를 지정합니다.

    4

    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.

    5

    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 스토리지 공급자를 지정합니다.

11. MigStorage CR을 생성합니다.

    $ oc create -f migstorage.yaml -n openshift-migration

12. MigStorage CR이 Ready 상태에 있는지 확인합니다.

    $ oc describe migstorage <migstorage_name>

13. migplan.yaml이라는 MigPlan CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration

    1

    false인 경우 직접 이미지 마이그레이션이 활성화됩니다.

    2

    false인 경우 직접 볼륨 마이그레이션이 활성화됩니다.

    3

    MigStorage CR 인스턴스의 이름을 지정합니다.

    4

    마이그레이션할 하나 이상의 네임스페이스를 지정합니다.

    5

    소스 클러스터 MigCluster 인스턴스의 이름을 지정합니다.

14. MigPlan CR을 만듭니다.

    $ oc create -f migplan.yaml -n openshift-migration

15. MigPlan 인스턴스를 보고 Ready 상태인지 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration

16. migmigration.yaml이라는 MigMigration CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4

    1

    MigPlan CR 이름을 지정합니다.

    2

    true인 경우 마이그레이션 전에 소스 클러스터의 포드가 중지됩니다.

    3

    애플리케이션을 중지하지 않고 대부분의 데이터를 복사하는 단계 마이그레이션이 true인 경우 수행됩니다.

    4

    true인 경우 완료된 마이그레이션이 롤백됩니다.

17. MigPlan CR에 정의된 마이그레이션을 시작하도록 MigMigration CR을 생성합니다.

    $ oc create -f migmigration.yaml -n openshift-migration

18. MigMigration CR을 확인하여 마이그레이션 진행 상황을 확인합니다.

    $ oc watch migmigration <migmigration_name> -n openshift-migration

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

    출력 예

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

절차

1. MigrationController 사용자 지정 (CR) 매니페스트를 편집합니다.

   $ oc edit migrationcontroller -n openshift-migration

2. 다음 매개 변수를 업데이트합니다.

   ...
   mig_controller_limits_cpu: "1" 1
   mig_controller_limits_memory: "10Gi" 2
   ...
   mig_controller_requests_cpu: "100m" 3
   mig_controller_requests_memory: "350Mi" 4
   ...
   mig_pv_limit: 100 5
   mig_pod_limit: 100 6
   mig_namespace_limit: 10 7
   ...

   1

   MigrationController CR에서 사용할 수 있는 CPU 수를 지정합니다.

   2

   MigrationController CR에서 사용할 수 있는 메모리 양을 지정합니다.

   3

   MigrationController CR 요청에 사용할 수 있는 CPU 단위 수를 지정합니다. 100m은 0.1 CPU 단위(100 * 1e-3)를 나타냅니다.

   4

   MigrationController CR 요청에 사용할 수 있는 메모리 양을 지정합니다.

   5

   마이그레이션할 수 있는 영구 볼륨 수를 지정합니다.

   6

   마이그레이션할 수 있는 포드 수를 지정합니다.

   7

   마이그레이션할 수 있는 네임스페이스 수를 지정합니다.

3. 업데이트된 매개 변수를 사용하여 변경 사항을 확인하는 마이그레이션 계획을 생성합니다.

   마이그레이션 계획이 MigrationController CR 제한을 초과하는 경우 MTC 콘솔은 마이그레이션 계획을 저장할 때 경고 메시지를 표시합니다.

절차

1. MigrationController 사용자 지정 매니페스트를 편집합니다.

   $ oc edit migrationcontroller <migration_controller> -n openshift-migration

2. 특정 리소스를 제외하는 매개 변수를 추가하거나 자체 제외 매개 변수가 없는 경우 excluded_resources 매개 변수에 리소스를 추가하여 spec 섹션을 업데이트합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   spec:
     disable_image_migration: true 1
     disable_pv_migration: true 2
     ...
     excluded_resources: 3
     - imagetags
     - templateinstances
     - clusterserviceversions
     - packagemanifests
     - subscriptions
     - servicebrokers
     - servicebindings
     - serviceclasses
     - serviceinstances
     - serviceplans
     - operatorgroups
     - events

   1

   마이그레이션에서 이미지 스트림을 제외하려면 disable_image_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController Pod가 다시 시작되면 imagestreams 가 excluded_resources 에 추가됩니다.

   2

   마이그레이션 계획에서 PV를 제외하려면 disable_pv_migration: true를 추가합니다. excluded_resources 매개 변수를 편집하지 마십시오. MigrationController Pod가 다시 시작되면 persistentvolumes 및 persistentvolumeclaims 가 excluded_resources 에 추가됩니다. PV 마이그레이션을 비활성화하면 마이그레이션 계획을 생성할 때 PV 검색도 비활성화됩니다.

   3

   OpenShift Container Platform 리소스를 excluded_resources 목록에 추가할 수 있습니다. 기본 제외 리소스를 삭제하지 마십시오. 이러한 리소스는 마이그레이션에 문제가 있으므로 제외해야 합니다.

3. 변경 사항이 적용되도록 MigrationController 포드가 다시 시작될 때까지 2분 정도 기다립니다.

4. 리소스가 제외되었는지 확인합니다.

   $ oc get deployment -n openshift-migration migration-controller -o yaml | grep EXCLUDED_RESOURCES -A1

   출력에는 제외된 리소스가 포함됩니다.

   출력 예

       - name: EXCLUDED_RESOURCES
         value:
         imagetags,templateinstances,clusterserviceversions,packagemanifests,subscriptions,servicebrokers,servicebindings,serviceclasses,serviceinstances,serviceplans,imagestreams,persistentvolumes,persistentvolumeclaims

프로세스

1. MTC 콘솔로 이동하여 브라우저 웹 검사로 요소를 검사합니다.

2. MigrationUI 포드 로그를 확인합니다.

   $ oc logs <MigrationUI_Pod> -n openshift-migration

프로세스

1. OpenShift Container Platform 웹 콘솔에서 Operator → 설치된 Operator로 이동합니다.
2. Migration Toolkit for Containers Operator를 클릭합니다.
3. MigrationController 탭에서 migration-controller를 클릭합니다.

4. YAML 탭에서 다음 매개 변수 값을 업데이트합니다.

   spec:
     restic_timeout: 1h 1

   1

   유효한 단위는 h(시간), m(분) 및 s(초)입니다(예: 3h30m15s).

5. 저장을 클릭합니다.

프로세스

1. 대상 클러스터에 로그인합니다.

2. Restore CR을 보기:

   $ oc describe <registry-example-migration-rvwcm> -n openshift-migration

   출력은 PodVolumeRestore 오류가 있는 영구 볼륨을 식별합니다.

   출력 예

   status:
     phase: Completed
     podVolumeRestoreErrors:
     - kind: PodVolumeRestore
       name: <registry-example-migration-rvwcm-98t49>
       namespace: openshift-migration
     podVolumeRestoreResticErrors:
     - kind: PodVolumeRestore
       name: <registry-example-migration-rvwcm-98t49>
       namespace: openshift-migration

3. PodVolumeRestore CR 보기:

   $ oc describe <migration-example-rvwcm-98t49>

   출력은 오류를 기록한 Restic pod를 식별합니다.

   출력 예

     completionTimestamp: 2020-05-01T20:49:12Z
     errors: 1
     resticErrors: 1
     ...
     resticPod: <restic-nr2v5>

4. Restic pod 로그를 보고 오류를 찾습니다.

   $ oc logs -f <restic-nr2v5>

프로세스

1. MigMigration CR의 상태를 확인합니다.

   $ oc get migmigration <migmigration> -o yaml

   출력 예

   status:
     conditions:
     - category: Warn
       durable: true
       lastTransitionTime: "2021-01-26T20:48:40Z"
       message: 'Final Restore openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf: partially failed on destination cluster'
       status: "True"
       type: VeleroFinalRestorePartiallyFailed
     - category: Advisory
       durable: true
       lastTransitionTime: "2021-01-26T20:48:42Z"
       message: The migration has completed with warnings, please look at `Warn` conditions.
       reason: Completed
       status: "True"
       type: SucceededWithWarnings

2. Velero describe 명령을 사용하여 Restore CR의 상태를 확인합니다.

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore describe <restore>

   출력 예

   Phase:  PartiallyFailed (run 'velero restore logs ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf' for more information)
   
   Errors:
     Velero:     <none>
     Cluster:    <none>
     Namespaces:
       migration-example:  error restoring example.com/migration-example/migration-example: the server could not find the requested resource

3. Velero logs 명령을 사용하여 Restore CR 로그를 확인합니다.

   $ oc exec $(oc get pods -n openshift-migration -o name | grep velero) -n openshift-migration -- ./velero restore logs <restore>

   출력 예

   time="2021-01-26T20:48:37Z" level=info msg="Attempting to restore migration-example: migration-example" logSource="pkg/restore/restore.go:1107" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf
   time="2021-01-26T20:48:37Z" level=info msg="error restoring migration-example: the server could not find the requested resource" logSource="pkg/restore/restore.go:1170" restore=openshift-migration/ccc7c2d0-6017-11eb-afab-85d0007f5a19-x4lbf

   Restore CR 로그 오류 메시지인 the server could not find the requested resource은 부분적으로 실패한 마이그레이션의 원인을 나타냅니다.

프로세스

1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
2. 마이그레이션 계획 옆의 옵션 메뉴 를 클릭하고 롤백 을 선택합니다.

3. 롤백을 클릭하고 롤백이 완료될 때까지 기다립니다.

   마이그레이션 계획 세부 사항에서 롤백 성공이 표시됩니다.

4. 소스 클러스터의 OpenShift Container Platform 웹 콘솔에서 롤백이 성공했는지 확인합니다.

   1. 홈 → 프로젝트를 클릭합니다.
   2. 마이그레이션된 프로젝트를 클릭하여 상태를 봅니다.
   3. 경로 섹션에서 위치를 클릭하여 해당되는 경우 애플리케이션이 작동하는지 확인합니다.
   4. 워크로드 → 포드를 클릭하여 포드가 마이그레이션된 네임스페이스에서 실행 중인지 확인합니다.
   5. 스토리지 → 영구 볼륨을 클릭하여 마이그레이션된 영구 볼륨이 올바르게 프로비저닝되었는지 확인합니다.

절차

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.

3. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.

   참고

   서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

4. 설치를 클릭합니다.

   설치된 Operators 페이지에서 Migration Toolkit for Containers Operator는 openshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

5. Migration Toolkit for Containers Operator를 클릭합니다.
6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
7. 생성을 클릭합니다.
8. 워크로드 → 포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

절차

1. OpenShift Container Platform 웹 콘솔에서 카탈로그 → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.

3. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.

   참고

   서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

4. 설치를 클릭합니다.

   설치된 Operators 페이지에서 Migration Toolkit for Containers Operator는 openshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

5. Migration Toolkit for Containers Operator를 클릭합니다.
6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.

7. migration-controller 사용자 정의 리소스 매니페스트에서 다음 매개변수를 업데이트합니다.

   spec:
   ...
     migration_controller: false
     migration_ui: false
   ...
     deprecated_cors_configuration: true 1

   1

   deprecated_cors_configuration 매개 변수와 해당 값을 추가합니다.

8. 생성을 클릭합니다.
9. 워크로드 → Pod를 클릭하여 MTC pod가 실행 중인지 확인합니다.

프로세스

1. registry.redhat.io로 인증합니다.

   $ podman login registry.redhat.io

2. 대상 레지스트리로 인증합니다.

   $ podman login <target_registry>

3. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

   1. 컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.6

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.6...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

   2. 별도의 터미널 세션에서 grpcurl 명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

   3. packages.out 파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.

      패키지 목록 조각의 예

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

   4. podman run 명령을 실행한 터미널 세션에서 Ctrl 및 C를 눌러 컨테이너 프로세스를 중지합니다.

4. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

   $ opm index prune \
       -f registry.redhat.io/redhat/redhat-operator-index:v4.6 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.6] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6 4

   1

   정리할 인덱스입니다.

   2

   쉼표로 구분된 보관할 패키지 목록입니다.

   3

   IBM Power Systems 및 IBM Z 이미지에만 필요합니다. 대상 OpenShift Container Platform 클러스터 주 버전 및 부 버전과 일치하는 태그가 있는 Operator 레지스트리 기본 이미지입니다.

   4

   빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.

5. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

   $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6

   <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

프로세스

1. Red Hat 제공 카탈로그를 미러링하려면 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 registry.redhat.io로 인증합니다.

   $ podman login registry.redhat.io

2. oc adm catalog mirror 명령은 인덱스 이미지의 콘텐츠를 추출하여 미러링에 필요한 매니페스트를 생성합니다. 명령의 기본 동작은 매니페스트를 생성한 다음 인덱스 이미지 자체뿐만 아니라 인덱스 이미지의 모든 이미지 콘텐츠를 미러 레지스트리에 자동으로 미러링합니다. 또는 미러 레지스트리가 완전히 연결이 끊긴 호스트 또는 에어갭(Airgap) 호스트에 있는 경우 먼저 콘텐츠를 이동식 미디어로 미러링하고 미디어를 연결이 끊긴 환경으로 이동한 다음 미디어에서 레지스트리로 해당 콘텐츠를 미러링할 수 있습니다.

   • 옵션 A: 미러 레지스트리가 무제한 네트워크 액세스 권한이 있는 워크스테이션과 동일한 네트워크에 있는 경우 워크스테이션에서 다음 작업을 수행합니다.

     1. 미러 레지스트리에 인증이 필요한 경우 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>

     2. 다음 명령을 실행하여 콘텐츠를 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6

        1

        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.6 과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.

        2

        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

        3

        선택 사항: 필요한 경우 레지스트리 자격 증명 파일의 위치를 지정합니다.

        4

        선택 사항: 대상 레지스트리에 대한 신뢰성을 구성하지 않으려면 --insecure 플래그를 추가합니다.

        5

        선택 사항: 여러 변형을 사용할 수 있을 때 선택할 인덱스 이미지의 플랫폼 및 아키텍처를 지정합니다. 이미지는 '<platform>/<arch>[/<variant>]’로 전달됩니다. 이는 인덱스에서 참조하는 이미지에는 적용되지 않습니다. 유효한 값은 linux/amd64, linux/ppc64le 및 linux/s390x입니다.

        6

        선택 사항: 미러링에 필요한 매니페스트만 생성하고 실제로 이미지 콘텐츠를 레지스트리에 미러링하지 않습니다. 이 선택 사항은 미러링할 항목을 검토하는 데 유용할 수 있으며 패키지의 서브 세트만 필요한 경우 매핑 목록을 변경할 수 있습니다. 그런 다음 oc image mirror 명령과 함께 mapping.txt 파일을 사용하여 이후 단계에서 수정된 이미지 목록을 미러링할 수 있습니다. 이 플래그는 카탈로그에서 콘텐츠의 고급 선택적 미러링에만 사용됩니다. 이전에 인덱스 이미지를 정리하기 위해 사용한 경우 opm index prune 명령은 대부분의 카탈로그 관리 사용 사례에 적합합니다.

        출력 예

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1

        명령으로 생성된 임시 index.db 데이터베이스용 디렉터리입니다.

        2

        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.

   • 옵션 B: 미러 레지스트리가 연결이 끊긴 호스트에 있는 경우 다음 작업을 수행합니다.

     1. 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 콘텐츠를 로컬 파일에 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.6 과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.

        2

        현재 디렉터리의 로컬 파일에 콘텐츠를 미러링합니다.

        출력 예

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1

        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.

        2

        제공된 인덱스 이미지를 기반으로 확장된 file:// 경로를 기록합니다. 이 경로는 이후 단계에서 사용됩니다.

     2. 현재 디렉터리에 생성된 v2/ 디렉터리를 이동식 미디어로 복사합니다.
     3. 물리적으로 미디어를 제거하고 연결이 끊긴 환경의 호스트에 연결하여 미러 레지스트리에 액세스할 수 있습니다.

     4. 미러 레지스트리에 인증이 필요한 경우 연결이 끊긴 환경의 호스트에서 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>

     5. v2/ 디렉터리가 포함된 상위 디렉터리에서 다음 명령을 실행하여 로컬 파일에서 미러 레지스트리로 이미지를 업로드합니다.

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        이전 명령 출력의 file:// 경로를 지정합니다.

        2

        Operator 콘텐츠를 미러링할 대상 레지스트리와 네임스페이스를 지정합니다. 여기서 <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

3. 콘텐츠를 레지스트리에 미러링한 후 현재 디렉터리에 생성된 매니페스트 디렉터리를 검사합니다.

   참고

   매니페스트 디렉터리 이름은 이후 단계에서 사용됩니다.

   이전 단계에서 동일한 네트워크의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

   manifests-<index_image_name>-<random_number>

   이전 단계에서 연결이 끊긴 호스트의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

   manifests-index/<namespace>/<index_image_name>-<random_number>

   매니페스트 디렉터리에는 다음 파일이 포함되어 있으며, 이 중 일부는 추가 수정이 필요할 수 있습니다.

   • catalogSource.yaml 파일은 인덱스 이미지 태그 및 기타 관련 메타데이터로 미리 채워진 CatalogSource 오브젝트에 대한 기본 정의입니다. 이 파일은 있는 그대로 사용하거나 카탈로그 소스를 클러스터에 추가하도록 수정할 수 있습니다.

     중요

     콘텐츠를 로컬 파일에 미러링한 경우 metadata.name 필드에서 .name 필드에서 백슬래시(/) 문자를 제거하려면 catalogSource.yaml 파일을 수정해야 합니다. 그러지 않으면 오브젝트 생성을 시도할 때 "잘못된 리소스 이름" 오류로 인해 실패합니다.

   • imageContentSourcePolicy.yaml 파일은 Operator 매니페스트에 저장된 이미지 참조와 미러링된 레지스트리 간에 변환하도록 노드를 구성할 수 있는 ImageContentSourcePolicy 오브젝트를 정의합니다.

     참고

     클러스터에서 ImageContentSourcePolicy 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에 대한 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

   • mapping.txt 파일에는 모든 소스 이미지와 대상 레지스트리에서 매핑할 위치가 포함되어 있습니다. 이 파일은 oc image mirror 명령과 호환되며 미러링 구성을 추가로 사용자 정의하는 데 사용할 수 있습니다.

     중요

     미러링 프로세스 중 --manifests-only 플래그를 사용한 후 미러링할 패키지의 서브 세트를 추가로 트리밍하려면 mapping.txt 파일을 수정하고 oc image mirror 명령으로 파일을 사용하는 데 대한 “패키지 매니페스트 형식 카탈로그 이미지 미러링” 절차의 단계를 참조하십시오. 추가 조치를 수행한 후 이 프로세스를 계속할 수 있습니다.

4. 연결 해제된 클러스터에 액세스할 수 있는 호스트에서 매니페스트 디렉터리에 imageContentSourcePolicy.yaml 파일을 지정하도록 다음 명령을 실행하여 ImageContentSourcePolicy 오브젝트를 생성합니다.

   $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

   여기서 <path/to/manifests/dir>은 미러링된 콘텐츠의 매니페스트 디렉터리 경로입니다.

프로세스

1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다.

   1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.6 1
        displayName: My Operator Catalog
        publisher: <publisher_name> 2
        updateStrategy:
          registryPoll: 3
            interval: 30m

      1

      인덱스 이미지를 지정합니다.

      2

      카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다.

      3

      카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.

   2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml

2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

   1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

절차

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.

3. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.

   참고

   서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

4. 설치를 클릭합니다.

   설치된 Operators 페이지에서 Migration Toolkit for Containers Operator는 openshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

5. Migration Toolkit for Containers Operator를 클릭합니다.
6. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
7. 생성을 클릭합니다.
8. 워크로드 → 포드를 클릭하여 MTC 포드가 실행 중인지 확인합니다.

절차

1. 키워드로 필터링 필드를 사용하여 Migration Toolkit for Containers Operator를 찾습니다.

2. Migration Toolkit for Containers Operator를 선택하고 설치를 클릭합니다.

   참고

   서브스크립션 승인 옵션을 자동으로 변경하지 마십시오. 소스 및 대상 클러스터에서 Migration Toolkit for Containers 버전이 동일해야 합니다.

3. 설치를 클릭합니다.

   설치된 Operators 페이지에서 Migration Toolkit for Containers Operator는 openshift-migration 프로젝트에 Succeeded 상태로 나타납니다.

4. Migration Toolkit for Containers Operator를 클릭합니다.
5. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.
6. 생성을 클릭합니다.
7. 워크로드 → Pod를 클릭하여 MTC pod가 실행 중인지 확인합니다.

절차

1. OpenShift Container Platform 콘솔에서 Operators > 설치된 Operators로 이동합니다.

   보류 중인 업그레이드가 있는 Operator에 업그레이드 사용 가능 상태가 표시됩니다.

2. Migration Toolkit for Containers Operator를 클릭합니다.
3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업그레이드는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
5. 업그레이드에 사용할 수 있는 리소스를 보고 승인을 클릭합니다.
6. Operator → 설치된 Operator 페이지로 이동하여 업그레이드 진행 상황을 모니터링합니다. 완료되면 상태가 성공 및 최신으로 변경됩니다.
7. Migration Toolkit for Containers Operator를 클릭합니다.
8. 제공된 API 아래에서 마이그레이션 컨트롤러 타일을 찾고 인스턴스 작성을 클릭합니다.

9. 소스 클러스터에서 MTC를 업그레이드하는 경우 MigrationController CR(사용자 정의 리소스) 매니페스트에서 다음 매개변수를 업데이트합니다.

   spec:
   ...
     migration_controller: false
     migration_ui: false
   ...
     deprecated_cors_configuration: true

   대상 클러스터에서 MigrationController CR 매니페스트를 업데이트할 필요가 없습니다.

10. 생성을 클릭합니다.
11. 워크로드 → Pod를 클릭하여 MTC pod가 실행 중인지 확인합니다.

절차

1. MigrationController Pod를 실행하는 클러스터에 로그인합니다.

2. MigPlan CR 매니페스트를 가져옵니다.

   $ oc get migplan <migplan> -o yaml -n openshift-migration

3. 다음 매개변수 값을 업데이트하고 파일을 migplan.yaml로 저장합니다.

   ...
   spec:
     indirectImageMigration: true
     indirectVolumeMigration: true

4. MigPlan CR 매니페스트를 교체하여 변경 사항을 적용합니다.

   $ oc replace -f migplan.yaml -n openshift-migration

5. 업데이트된 MigPlan CR 매니페스트를 가져와 변경 사항을 확인합니다.

   $ oc get migplan <migplan> -o yaml -n openshift-migration

프로세스

1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
2. 키워드로 필터링(이 경우 OCS)을 사용하여 OpenShift Container Storage Operator를 찾습니다.
3. OpenShift Container Storage Operator를 선택하고 설치를 클릭합니다.
4. 업데이트 채널, 설치 모드 및 승인 전략을 선택합니다.

5. 설치를 클릭합니다.

   설치된 운영자 페이지에서 OpenShift Container Storage Operator가 openshift-storage 프로젝트에 Succeeded 상태로 나타납니다.

프로세스

1. OpenShift Container Platform 클러스터에 로그인합니다.

   $ oc login

2. 다음과 같은 내용과 함께 NooBaa CR 구성 파일, noobaa.yml을 생성합니다.

   apiVersion: noobaa.io/v1alpha1
   kind: NooBaa
   metadata:
     name: noobaa
     namespace: openshift-storage
   spec:
    dbResources:
      requests:
        cpu: 0.5 1
        memory: 1Gi
    coreResources:
      requests:
        cpu: 0.5 2
        memory: 1Gi

   1 2

   매우 작은 클러스터의 경우 cpu 값을 0.1로 변경할 수 있습니다.

3. NooBaa 오브젝트를 생성합니다.

   $ oc create -f noobaa.yml

4. 다음과 같은 내용과 함께 BackingStore CR 구성 파일 bs.yml을 생성합니다.

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: mcg-pv-pool-bs
     namespace: openshift-storage
   spec:
     pvPool:
       numVolumes: 3 1
       resources:
         requests:
           storage: 50Gi 2
       storageClass: gp2 3
     type: pv-pool

   1

   영구 볼륨 풀에서 볼륨 수를 지정합니다.

   2

   볼륨의 크기를 지정합니다.

   3

   스토리지 클래스를 지정합니다.

5. BackingStore 오브젝트를 생성합니다.

   $ oc create -f bs.yml

6. 다음과 같은 내용으로 BucketClass CR 구성 파일, bc.yml을 생성합니다.

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     labels:
       app: noobaa
     name: mcg-pv-pool-bc
     namespace: openshift-storage
   spec:
     placementPolicy:
       tiers:
       - backingStores:
         - mcg-pv-pool-bs
         placement: Spread

7. BucketClass 오브젝트를 생성합니다.

   $ oc create -f bc.yml

8. 다음과 같은 내용과 함께 ObjectBucketClaim CR 구성 파일, obc.yml을 생성합니다.

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: migstorage
     namespace: openshift-storage
   spec:
     bucketName: migstorage 1
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: mcg-pv-pool-bc

   1

   MTC 웹 콘솔에 복제 리포지토리를 추가하기 위한 버킷 이름을 기록합니다.

9. ObjectBucketClaim 오브젝트를 생성합니다.

   $ oc create -f obc.yml

10. 리소스 생성 프로세스를 보고 ObjectBucketClaim 상태가 Bound인지 확인합니다.

    $ watch -n 30 'oc get -n openshift-storage objectbucketclaim migstorage -o yaml'

    이 프로세스는 5-10분 정도 걸릴 수 있습니다.

11. MTC 웹 콘솔에 복제 리포지토리를 추가할 때 필요한 다음 값을 확보하고 기록합니다.

    • S3 끝점:

      $ oc get route -n openshift-storage s3

    • S3 공급자 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_ACCESS_KEY_ID }}' | base64 --decode

    • S3 공급자 보안 액세스 키:

      $ oc get secret -n openshift-storage migstorage -o go-template='{{ .data.AWS_SECRET_ACCESS_KEY }}' | base64 --decode

절차

1. MigrationController Pod가 실행되는 클러스터에 로그인합니다.

2. MigrationController CR 매니페스트를 가져옵니다.

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

3. stunnel_tcp_proxy 매개변수를 추가합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: migration-controller
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: <stunnel_proxy> 1

   1

   Stunnel 프록시를 지정합니다. http://<user_name>:<password>@<ip_address>:<port>

4. 매니페스트를 migration-controller.yaml로 저장합니다.

5. 업데이트된 매니페스트를 적용합니다.

   $ oc replace -f migration-controller.yaml -n openshift-migration

절차

1. MTC를 설치한 OpenShift Container Platform 클러스터에 로그인합니다.

2. 다음 명령을 입력하여 MTC 웹 콘솔 URL을 확보합니다.

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   출력은 https://migration-openshift-migration.apps.cluster.openshift.com과 유사합니다.

3. 브라우저를 시작하고 MTC 웹 콘솔로 이동합니다.

   참고

   Migration Toolkit for Containers Operator를 설치한 직후 MTC 웹 콘솔에 액세스하려고 하면 Operator가 여전히 클러스터를 구성하고 있기 때문에 콘솔이 로드되지 않을 수 있습니다. 몇 분 기다렸다가 다시 시도하십시오.

4. 자체 서명된 CA 인증서를 사용하는 경우 소스 클러스터 API 서버의 CA 인증서를 수락하라는 메시지가 표시됩니다. 웹 페이지는 나머지 인증서 수락 프로세스를 안내합니다.
5. OpenShift Container Platform 사용자 이름 및 암호로 로그인합니다.

프로세스

1. 클러스터에 로그인합니다.

2. migration-controller 서비스 계정 토큰을 확보합니다.

   $ oc sa get-token migration-controller -n openshift-migration

   출력 예

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

3. MTC 웹 콘솔에서 클러스터를 클릭합니다.
4. 클러스터 추가를 클릭합니다.

5. 다음 필드를 작성합니다.

   • 클러스터 이름: 클러스터 이름은 소문자(a-z) 및 숫자(0-9)를 포함할 수있습니다. 공백이나 국제 문자를 포함해서는 안 됩니다.
   • URL: API 서버 URL을 지정합니다(예: https://<www.example.com>:8443 ).
   • 서비스 계정 토큰: migration-controller 서비스 계정 토큰을 붙여넣습니다.

   • 이미지 레지스트리에 노출된 경로 호스트: 직접 이미지 마이그레이션을 사용하는 경우 소스 클러스터의 이미지 레지스트리에 노출된 경로를 지정합니다(예: www.example.apps.cluster.com).

     포트를 지정할 수 있습니다. 기본 포트는 5000입니다.

   • Azure 클러스터: Azure 스냅샷을 사용하여 데이터를 복사하는 경우 이 옵션을 선택해야 합니다.
   • Azure 리소스 그룹: Azure 클러스터가 선택된 경우 이 필드가 표시됩니다. Azure 리소스 그룹을 지정합니다.
   • SSL 확인 필요 : 선택 사항: 이 옵션을 선택하여 클러스터에 대한 SSL 연결을 확인합니다.
   • CA 번들 파일: Require SSL 확인이 선택되어 있으면 이 필드가 표시됩니다. 자체 서명된 인증서에 대한 사용자 정의 CA 인증서 번들 파일을 생성한 경우 찾아보기를 클릭하고 CA 번들 파일을 선택하여 업로드합니다.

6. 클러스터 추가를 클릭합니다.

   클러스터가 클러스터 목록에 나타납니다.

프로세스

1. MTC 웹 콘솔에서 복제 리포지토리를 클릭합니다.
2. 리포지토리 추가를 클릭합니다.

3. 스토리지 공급자 유형을 선택하고 다음 필드를 작성합니다.

   • AWS S3, MCG 및 일반 S3 공급자용 AWS:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • S3 버킷 이름: 생성한 S3 버킷의 이름을 지정합니다.
     • S3 버킷 영역: S3 버킷 리전을 지정합니다. AWS S3의 경우 필수입니다. 다른 S3 공급자의 경우 선택 사항입니다.
     • S3 끝점: 버킷이 아닌 S3 서비스의 URL을 지정합니다(예: https://<s3-storage.apps.cluster.com&gt;). 일반 S3 공급자의 경우 필수입니다. https:// 접두사를 사용해야 합니다.
     • S3 공급자 액세스 키: AWS의 경우 <AWS_SECRET_ACCESS_KEY> 또는 MCG의 경우 S3 공급자 액세스 키를 지정합니다.
     • S3 공급자 보안 액세스 키: AWS의 경우 <AWS_ACCESS_KEY_ID> 또는 MCG의 경우 S3 공급자 보안 액세스 키를 지정합니다.
     • SSL 확인 필요 : 일반 S3 공급자를 사용하는 경우 이 확인란을 지웁니다.
     • 사용자 정의 CA 번들을 사용하는 경우 찾아보기를 클릭하고 Base64 인코딩된 CA 번들 파일을 찾습니다.

   • GCP:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • GCP 버킷 이름: GCP 버킷의 이름을 지정합니다.
     • GCP 자격 증명 JSON blob: credentials-velero 파일에서 문자열을 지정합니다.

   • Azure:

     • 복제 리포지터리 이름: MTC 웹 콘솔에서 복제 리포지토리 이름을 지정합니다.
     • Azure 리소스 그룹: Azure Blob 스토리지의 리소스 그룹을 지정합니다.
     • Azure 스토리지 계정 이름: Azure Blob 스토리지 계정 이름을 지정합니다.
     • Azure 인증 정보 - INI 파일 콘텐츠: credentials-velero 파일에서 문자열을 지정합니다.
4. 리포지토리 추가를 클릭하고 연결 유효성 검사를 기다립니다.

5. 닫기를 클릭합니다.

   새 리포지토리가 복제 리포지토리 목록에 나타납니다.

절차

1. MTC 웹 콘솔에서 마이그레이션 계획을 클릭합니다.
2. 마이그레이션 계획 추가를 클릭합니다.

3. 계획 이름을 입력하고 다음 클릭합니다.

   마이그레이션 계획 이름에서 253자의 소문자 영숫자(a-z, 0-9)를 초과해서는 안 되며 공백이나 밑줄(_)을 포함해서는 안 됩니다.

4. 소스 클러스터를 선택합니다.
5. 대상 클러스터를 선택합니다.
6. 복제 리포지토리를 선택합니다.
7. 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.
8. 소스 클러스터, 대상 클러스터, 리포지토리를 선택하고 다음을 클릭합니다.
9. 네임스페이스 페이지에서 마이그레이션할 프로젝트를 선택하고 다음을 클릭합니다.

10. 영구 볼륨 페이지에서 각 PV의 마이그레이션 유형을 클릭합니다.

    • 복사 옵션은 소스 클러스터의 PV에 있는 데이터를 복제 리포지토리에 복사한 다음 대상 클러스터에서 비슷한 특성을 가진 새로 생성된 PV에 데이터를 복원합니다.
    • 이동 옵션은 소스 클러스터에서 원격 볼륨(예: NFS)을 마운트 해제하고 원격 볼륨을 가리키는 대상 클러스터에 PV 리소스를 생성한 다음 대상 클러스터에 원격 볼륨을 마운트합니다. 대상 클러스터에서 실행되는 애플리케이션은 소스 클러스터와 동일한 원격 볼륨을 사용합니다.
11. 다음을 클릭합니다.

12. 복사 옵션 페이지에서 각 PV에 대한 복사 방법을 선택합니다.

    • 스냅샷 복사는 클라우드 공급자의 스냅샷 기능을 사용하여 데이터를 백업 및 복원합니다. 파일 시스템 복사.보다 훨씬 빠릅니다.

    • 파일 시스템 복사는 소스 클러스터에서 파일을 백업하고 대상 클러스터에서 해당 파일을 복원합니다.

      직접 볼륨 마이그레이션에는 파일 시스템 복사 방법이 필요합니다.

13. 복사 확인을 선택하여 파일 시스템 복사로 마이그레이션된 데이터를 확인할 수 있습니다. 데이터는 각 소스 파일에 대한 체크섬을 생성하고 복원 후 체크섬을 확인합니다. 데이터 확인으로 성능이 크게 저하합니다.

14. 대상 스토리지 클래스를 선택합니다.

    파일 시스템 복사를 선택한 경우 대상 스토리지 클래스를 변경할 수 있습니다.

15. 다음을 클릭합니다.

16. 마이그레이션 옵션 페이지에서 소스 클러스터에 대해 노출된 이미지 레지스트리 경로를 지정한 경우 직접 이미지 마이그레이션 옵션이 선택됩니다. 파일 시스템 복사로 데이터를 마이그레이션하는 경우 직접 PV 마이그레이션 옵션이 선택됩니다.

    직접 마이그레이션 옵션은 소스 클러스터에서 대상 클러스터로 직접 이미지 및 파일을 복사합니다. 이 옵션은 소스 클러스터에서 복제 리포지토리로 이미지 및 파일을 복사한 다음 복제 리포지토리에서 대상 클러스터로 복사합니다.

17. 다음을 클릭합니다.

18. 선택 사항: 후크 페이지에서 후크 추가를 클릭하여 마이그레이션 계획에 후크를 추가합니다.

    후크는 사용자 지정 코드를 실행합니다. 단일 마이그레이션 계획에 최대 4개의 후크를 추가할 수 있습니다. 각 후크는 다른 마이그레이션 단계에서 실행됩니다.

    1. 웹 콘솔에 표시할 후크 이름을 입력합니다.
    2. 후크가 Ansible 플레이북인 경우 Ansible 플레이북을 선택하고 찾아보기를 클릭하여 플레이북을 업로드하거나 필드에 플레이북 콘텐츠를 붙여넣습니다.
    3. 선택 사항: 기본 후크 이미지를 사용하지 않는 경우 Ansible 런타임 이미지를 지정합니다.

    4. 후크가 Ansible 플레이북이 아닌 경우 사용자 정의 컨테이너 이미지를 선택하고 이미지 이름과 경로를 지정합니다.

       사용자 정의 컨테이너 이미지에는 Ansible 플레이북이 포함될 수 있습니다.

    5. 소스 클러스터 또는 대상 클러스터를 선택합니다.
    6. 서비스 계정 이름과 서비스 계정 네임스페이스를 입력합니다.

    7. 후크의 마이그레이션 단계를 선택합니다.

       • preBackup: 애플리케이션 워크로드를 소스 클러스터에서 백업하기 전에
       • postBackup: 소스 클러스터에서 애플리케이션 워크로드를 백업한 후
       • preRestore: 대상 클러스터에서 애플리케이션 워크로드를 복원하기 전에
       • postRestore: 대상 클러스터에서 애플리케이션 워크로드를 복원한 후
    8. 추가를 클릭합니다.

19. 완료를 클릭합니다.

    마이그레이션 계획이 마이그레이션 계획 목록에 표시됩니다.

프로세스

1. 소스 클러스터에 로그인합니다.

2. 오래된 이미지 삭제:

   $ oc adm prune images

3. MTC 웹 콘솔에 로그인하고 마이그레이션 계획을 클릭합니다.

4. 마이그레이션 계획 옆에 있는 옵션 메뉴 를 클릭하고 단계를 선택하여 애플리케이션을 중지하지 않고 소스 클러스터에서 대상 클러스터로 데이터를 복사합니다.

   실제 마이그레이션 시간을 줄이기 위해 단계를 여러 번 실행할 수 있습니다.

5. 애플리케이션 워크로드를 마이그레이션할 준비가 되면 마이그레이션 계획 외의 옵션 메뉴 를 선택하고 마이그레이션을 선택합니다.
6. 선택 사항: 마이그레이션 창에서 마이그레이션 중에 소스 클러스터에서 애플리케이션을 중지하지 않음을 선택할 수 있습니다.
7. 마이그레이션을 클릭합니다.

8. 마이그레이션이 완료되면 OpenShift Container Platform 웹 콘솔에서 애플리케이션이 성공적으로 마이그레이션되었는지 확인합니다.

   1. 홈 → 프로젝트를 클릭합니다.
   2. 마이그레이션된 프로젝트를 클릭하여 상태를 봅니다.
   3. 경로 섹션에서 위치를 클릭하여 해당되는 경우 애플리케이션이 작동하는지 확인합니다.
   4. 워크로드 → 포드를 클릭하여 포드가 마이그레이션된 네임스페이스에서 실행 중인지 확인합니다.
   5. 스토리지 → 영구 볼륨을 클릭하여 마이그레이션된 영구 볼륨이 올바르게 프로비저닝되었는지 확인합니다.

프로세스

1. host-cluster.yaml이라는 host 클러스터에 대한 MigCluster CR 매니페스트를 생성합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: host
     namespace: openshift-migration
   spec:
     isHostCluster: true

2. host 클러스터에 대한 MigCluster CR을 생성합니다.

   $ oc create -f host-cluster.yaml -n openshift-migration

3. cluster-secret.yaml이라는 각 원격 클러스터에 대한 Secret CR 매니페스트를 생성합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 1

   1

   원격 클러스터의 base64로 인코딩된 migration-controller 서비스 계정(SA) 토큰을 지정합니다.

   다음 명령을 실행하여 SA 토큰을 확보할 수 있습니다.

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

4. 각 원격 클러스터에 대한 Secret CR을 생성합니다.

   $ oc create -f cluster-secret.yaml

5. remote-cluster.yaml이라는 각 원격 클러스터에 대해 MigCluster CR 매니페스트를 생성합니다.

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster>
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 1
     insecure: false 2
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 3
       namespace: openshift-config
     url: <remote_cluster_url> 4

   1

   선택 사항: 직접 이미지 마이그레이션을 사용하는 경우 노출된 레지스트리 경로를 지정합니다(예: docker-registry-default.apps.example.com ).

   2

   false인 경우 SSL 확인이 활성화됩니다. CA 인증서가 필요하지 않거나 true인 경우 확인되지 않습니다.

   3

   원격 클러스터의 Secret CR을 지정합니다.

   4

   원격 클러스터의 URL을 지정합니다.

6. 각 원격 클러스터에 대해 MigCluster CR을 생성합니다.

   $ oc create -f remote-cluster.yaml -n openshift-migration

7. 모든 클러스터가 Ready 상태에 있는지 확인합니다.

   $ oc describe cluster <cluster_name>

8. storage-secret.yaml이라는 복제 리포지토리의 Secret CR 매니페스트를 생성합니다.

   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 1
     aws-secret-access-key: <secret_key_base64> 2

   1

   base64 형식으로 키 ID를 지정합니다.

   2

   base64 형식으로 시크릿 키를 지정합니다.

   AWS 인증 정보는 기본적으로 base64로 인코딩됩니다. 다른 스토리지 공급자를 사용하는 경우 각 키로 다음 명령을 실행하여 인증 정보를 인코딩해야 합니다.

   $ echo -n "<key>" | base64 -w 0 1

   1

   키 ID 또는 시크릿 키를 지정합니다. 두 키 모두 base64로 인코딩되어야 합니다.

9. 복제 리포지토리에 대한 Secret CR을 생성합니다.

   $ oc create -f storage-secret.yaml

10. migstorage.yaml이라는 복제 리포지토리에 대한 MigStorage CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigStorage
    metadata:
      name: <storage_name>
      namespace: openshift-migration
    spec:
      backupStorageConfig:
        awsBucketName: <bucket_name> 1
        credsSecretRef:
          name: <storage_secret_ref> 2
          namespace: openshift-config
      backupStorageProvider: <storage_provider_name> 3
      volumeSnapshotConfig:
        credsSecretRef:
          name: <storage_secret_ref> 4
          namespace: openshift-config
      volumeSnapshotProvider: <storage_provider_name> 5

    1

    버킷 이름을 지정합니다.

    2

    오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.

    3

    스토리지 공급자를 지정합니다.

    4

    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 오브젝트 스토리지의 Secrets CR을 지정합니다. 오브젝트 스토리지의 Secrets CR에 저장된 인증 정보가 올바른지 확인해야 합니다.

    5

    선택 사항: 스냅샷을 사용하여 데이터를 복사하는 경우 스토리지 공급자를 지정합니다.

11. MigStorage CR을 생성합니다.

    $ oc create -f migstorage.yaml -n openshift-migration

12. MigStorage CR이 Ready 상태에 있는지 확인합니다.

    $ oc describe migstorage <migstorage_name>

13. migplan.yaml이라는 MigPlan CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigPlan
    metadata:
      name: <migration_plan>
      namespace: openshift-migration
    spec:
      destMigClusterRef:
        name: host
        namespace: openshift-migration
      indirectImageMigration: true 1
      indirectVolumeMigration: true 2
      migStorageRef:
        name: <migstorage_ref> 3
        namespace: openshift-migration
      namespaces:
        - <application_namespace> 4
      srcMigClusterRef:
        name: <remote_cluster_ref> 5
        namespace: openshift-migration

    1

    false인 경우 직접 이미지 마이그레이션이 활성화됩니다.

    2

    false인 경우 직접 볼륨 마이그레이션이 활성화됩니다.

    3

    MigStorage CR 인스턴스의 이름을 지정합니다.

    4

    마이그레이션할 하나 이상의 네임스페이스를 지정합니다.

    5

    소스 클러스터 MigCluster 인스턴스의 이름을 지정합니다.

14. MigPlan CR을 만듭니다.

    $ oc create -f migplan.yaml -n openshift-migration

15. MigPlan 인스턴스를 보고 Ready 상태인지 확인합니다.

    $ oc describe migplan <migplan_name> -n openshift-migration

16. migmigration.yaml이라는 MigMigration CR 매니페스트를 생성합니다.

    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration_name>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan_name> 1
        namespace: openshift-migration
      quiescePods: true 2
      stage: false 3
      rollback: false 4

    1

    MigPlan CR 이름을 지정합니다.

    2

    true인 경우 마이그레이션 전에 소스 클러스터의 포드가 중지됩니다.

    3

    애플리케이션을 중지하지 않고 대부분의 데이터를 복사하는 단계 마이그레이션이 true인 경우 수행됩니다.

    4

    true인 경우 완료된 마이그레이션이 롤백됩니다.

17. MigPlan CR에 정의된 마이그레이션을 시작하도록 MigMigration CR을 생성합니다.

    $ oc create -f migmigration.yaml -n openshift-migration

18. MigMigration CR을 확인하여 마이그레이션 진행 상황을 확인합니다.

    $ oc watch migmigration <migmigration_name> -n openshift-migration

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

    출력 예

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       my_application
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47