지원콘솔개발자평가판 시작연락처

3.5. oc-mirror 플러그인 v2를 사용하여 연결이 끊긴 설치의 이미지 미러링

프라이빗 레지스트리의 미러링된 OpenShift Container Platform 컨테이너 이미지에서 클러스터를 설치하는 경우 직접 인터넷 연결 없이 제한된 네트워크에서 클러스터를 실행할 수 있습니다. 이 레지스트리는 클러스터가 실행될 때마다 실행되어야 합니다.

oc-mirror OpenShift CLI(oc) 플러그인을 사용할 수 있는 것처럼 oc-mirror 플러그인 v2를 사용하여 완전히 또는 부분적으로 연결이 끊긴 환경의 미러 레지스트리에 이미지를 미러링할 수도 있습니다. 공식 Red Hat 레지스트리에서 필요한 이미지를 다운로드하려면 인터넷 연결이 있는 시스템에서 oc-mirror 플러그인 v2를 실행해야 합니다.

중요

oc-mirror 플러그인 v2는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

3.5.1. 사전 요구 사항

  • 컨테이너 이미지 레지스트리에 대한 기존 솔루션이 없는 경우 OpenShift Container Platform 구독자에게 Red Hat OpenShift의 미러 레지스트리가 제공됩니다. 이 미러 레지스트리는 서브스크립션에 포함되어 있으며 소규모 컨테이너 레지스트리 역할을 합니다. 이 레지스트리를 사용하여 연결이 끊긴 설치에 필요한 OpenShift Container Platform 컨테이너 이미지를 미러링할 수 있습니다.
  • 프로비저닝된 클러스터의 모든 시스템은 미러 레지스트리에 액세스할 수 있어야 합니다. 레지스트리에 연결할 수 없는 경우 설치, 업데이트 또는 워크로드 재배치와 같은 일상적인 작업과 같은 작업이 실패할 수 있습니다. 미러 레지스트리는 고가용성 방식으로 작동하여 OpenShift Container Platform 클러스터의 프로덕션 가용성과 일치하도록 해야 합니다.

고급 워크플로

다음 단계에서는 oc-mirror 플러그인 v2를 사용하여 이미지를 미러 레지스트리에 미러링하는 방법에 대한 고급 워크플로를 간략하게 설명합니다.

  1. 이미지 세트 구성 파일을 생성합니다.

  2. 다음 워크플로우 중 하나를 사용하여 대상 미러 레지스트리에 설정된 이미지를 미러링합니다.

    • 대상 미러 레지스트리(mirror to mirror)에 직접 설정된 이미지를 미러링합니다.

      • 이미지 세트를 디스크로 미러링하고(Mirror-to-Disk) tar 파일을 대상 환경으로 전송한 다음 이미지 세트를 대상 미러 레지스트리(Disk-to-Mirror)로 미러링합니다.
  3. oc-mirror 플러그인 v2에서 생성한 리소스를 사용하도록 클러스터를 구성합니다.
  4. 필요에 따라 대상 미러 레지스트리를 업데이트하려면 다음 단계를 반복합니다.

3.5.2. oc-mirror 플러그인 v2 정보

oc-mirror OpenShift CLI(oc) 플러그인은 필요한 모든 OpenShift Container Platform 콘텐츠 및 기타 이미지를 미러 레지스트리에 미러링하는 단일 툴입니다.

oc-mirror의 새로운 기술 프리뷰 버전을 사용하려면 oc-mirror 플러그인 v2 명령줄에 --v2 플래그를 추가합니다.

oc-mirror 플러그인 v2에는 다음과 같은 기능이 있습니다.

  • 이미지가 이전에 미러링되었는지 여부와 관계없이 이미지 세트 구성에 지정된 전체 이미지 세트가 미러링된 레지스트리에 미러링되었는지 확인합니다.
  • 메타데이터 대신 캐시 시스템을 사용합니다.
  • 새 이미지만 아카이브에 통합하여 최소한의 아카이브 크기를 유지합니다.
  • 미러링 날짜별로 선택한 콘텐츠로 미러링 아카이브를 생성합니다.
  • 증분 변경 대신 전체 이미지 세트에 대한 ImageContentSourcePolicy (ICSP) 대신 ImageDigestMirrorSet (IDMS), ImageTagMirrorSet (ITMS)을 생성할 수 있습니다.
  • 번들 이름으로 Operator 버전을 저장합니다.
  • 자동 정리를 수행하지 않습니다. 이제 V2에는 Delete 기능이 있어 사용자에게 이미지 삭제를 보다 효과적으로 제어할 수 있습니다.
  • registries.conf 에 대한 지원을 제공합니다. 이 변경으로 동일한 캐시를 사용하는 동안 여러 개의 enclaves로 미러링할 수 있습니다.

3.5.2.1. oc-mirror 플러그인 v2 호환성 및 지원

oc-mirror 플러그인 v2는 OpenShift Container Platform에서 지원됩니다.

참고

aarch64,ppc64le 및 s390x 아키텍처에서 oc-mirror 플러그인 v2는 OpenShift Container Platform 버전 4.14 이상에서만 지원됩니다.

미러링해야 하는 OpenShift Container Platform 버전에 관계없이 사용 가능한 최신 oc-mirror 플러그인 v2 버전을 사용합니다.

3.5.3. 미러 호스트 준비

이미지 미러링에 oc-mirror 플러그인 v2를 사용하려면 플러그인을 설치하고 컨테이너 이미지에 대한 인증 정보가 있는 파일을 생성하여 Red Hat에서 미러로 미러링할 수 있습니다.

3.5.3.1. oc-mirror OpenShift CLI 플러그인 설치

oc-mirror OpenShift CLI 플러그인을 설치하여 연결이 끊긴 환경에서 이미지 세트를 관리합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다. 완전히 연결이 끊긴 환경에서 이미지 세트를 미러링하는 경우 다음을 확인하십시오.

    • 인터넷에 액세스할 수 있는 호스트에 oc-mirror 플러그인을 설치했습니다.
    • 연결이 끊긴 환경의 호스트는 대상 미러 레지스트리에 액세스할 수 있습니다.
  • oc-mirror 를 사용하는 운영 체제에서 Cryostat 매개변수를 0022 로 설정해야 합니다.
  • 사용 중인 RHEL 버전에 대해 올바른 바이너리를 설치했습니다.

프로세스

  1. oc-mirror CLI 플러그인을 다운로드합니다.

    1. OpenShift Cluster Manager 의 다운로드 페이지로 이동합니다.
    2. OpenShift 연결 설치 툴 섹션에서 OpenShift Client(oc) 미러 플러그인 다운로드를 클릭하고 파일을 저장합니다.

  2. 아카이브를 추출합니다. 

    $ tar xvzf oc-mirror.tar.gz

  3. 필요한 경우 플러그인 파일을 실행 가능하게 업데이트합니다. 

    $ chmod +x oc-mirror
    참고

    oc-mirror 파일의 이름을 바꾸지 마십시오.

  4. 파일을 PATH 에 배치하여 oc-mirror CLI 플러그인을 설치합니다(예: /usr/local/bin:) 

    $ sudo mv oc-mirror /usr/local/bin/.

검증

  • 다음 명령을 실행하여 oc-mirror v2의 플러그인이 성공적으로 설치되었는지 확인합니다. 

    $ oc mirror --v2 --help

3.5.3.2. 이미지를 미러링할 수 있는 인증 정보 설정

Red Hat에서 미러로 이미지를 미러링할 수 있는 컨테이너 이미지 레지스트리 인증 정보 파일을 생성합니다.

주의

클러스터를 설치할 때 이 이미지 레지스트리 인증 정보 파일을 풀 시크릿(pull secret)으로 사용하지 마십시오. 클러스터를 설치할 때 이 파일을 지정하면 클러스터의 모든 시스템에 미러 레지스트리에 대한 쓰기 권한이 부여됩니다.

주의

이 프로세스에서는 미러 레지스트리의 컨테이너 이미지 레지스트리에 대한 쓰기 권한이 있어야 하며 인증 정보를 레지스트리 풀 시크릿에 추가해야 합니다.

사전 요구 사항

  • 연결이 끊긴 환경에서 사용할 미러 레지스트리를 구성했습니다.
  • 미러 레지스트리에서 이미지를 미러링할 이미지 저장소 위치를 확인했습니다.
  • 이미지를 해당 이미지 저장소에 업로드할 수 있는 미러 레지스트리 계정을 제공하고 있습니다.

프로세스

설치 호스트에서 다음 단계를 수행합니다.

  1. Red Hat OpenShift Cluster Manager에서 registry.redhat.io 풀 시크릿을 다운로드합니다.

  2. 풀 시크릿을 JSON 형식으로 복사합니다. 

    $ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 1
    1
    풀 시크릿을 저장할 폴더의 경로와 생성한 JSON 파일의 이름을 지정합니다.

    파일의 내용은 다음 예와 유사합니다. 

    {
  "auths": {
    "cloud.openshift.com": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "quay.io": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "registry.connect.redhat.com": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    },
    "registry.redhat.io": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    }
  }
}
  3. 파일을 $XDG_RUNTIME_DIR/containers/auth.json 으로 저장합니다.

  4. 미러 레지스트리에 대한 base64로 인코딩된 사용자 이름 및 암호 또는 토큰을 생성합니다. 

    $ echo -n '<user_name>:<password>' | base64 -w0 1
BGVtbYk3ZHAtqXs=
    1
    <user_name> 및 <password>의 경우 레지스트리에 설정한 사용자 이름 및 암호를 지정합니다.

  5. JSON 파일을 편집하고 레지스트리를 설명하는 섹션을 추가합니다. 

      "auths": {
    "<mirror_registry>": { 1
      "auth": "<credentials>", 2
      "email": "you@example.com"
    }
  },
    1
    미러 레지스트리가 콘텐츠를 제공하는 데 사용하는 레지스트리 도메인 이름과 포트(선택 사항)를 지정합니다. 예: registry.example.com 또는 registry.example.com:8443
    2
    미러 레지스트리에 대해 base64로 인코딩된 사용자 이름 및 암호를 지정합니다.

    파일은 다음 예제와 유사합니다. 

    {
  "auths": {
    "registry.example.com": {
      "auth": "BGVtbYk3ZHAtqXs=",
      "email": "you@example.com"
    },
    "cloud.openshift.com": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "quay.io": {
      "auth": "b3BlbnNo...",
      "email": "you@example.com"
    },
    "registry.connect.redhat.com": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    },
    "registry.redhat.io": {
      "auth": "NTE3Njg5Nj...",
      "email": "you@example.com"
    }
  }
}

3.5.4. 미러 레지스트리로 이미지 세트 미러링

미러 레지스트리로 이미지를 미러링하면 안전하고 제어된 환경에서 필요한 이미지를 사용할 수 있으므로 더 원활한 배포, 업데이트 및 유지 관리 작업을 수행할 수 있습니다.

3.5.4.1. 이미지 세트 구성 빌드

oc-mirror 플러그인 v2는 이미지 세트 구성을 입력 파일로 사용하여 미러링에 필요한 이미지를 결정합니다.

ImageSetConfiguration 입력 파일의 예

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v2alpha1
mirror:
  platform:
    channels:
    - name: stable-4.13
      minVersion: 4.13.10
      maxVersion: 4.13.10
    graph: true
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
      packages:
       - name: aws-load-balancer-operator
       - name: 3scale-operator
       - name: node-observability-operator
  additionalImages:
   - name: registry.redhat.io/ubi8/ubi:latest
   - name: registry.redhat.io/ubi9/ubi@sha256:20f695d2a91352d4eaa25107535126727b5945bff38ed36a3e59590f495046f0

3.5.4.2. 부분적으로 연결이 끊긴 환경에서 이미지 세트 미러링

인터넷 액세스가 제한된 환경에서 oc-mirror 플러그인 v2를 사용하여 이미지 세트를 레지스트리에 미러링할 수 있습니다.

사전 요구 사항

  • oc-mirror 플러그인 v2를 실행하는 환경의 인터넷 및 미러 레지스트리에 액세스할 수 있습니다.

프로세스

  • 다음 명령을 실행하여 지정된 이미지 세트 구성의 이미지를 지정된 레지스트리로 미러링합니다. 

    $ oc mirror -c isc.yaml --workspace file://<file_path> docker://<mirror_registry_url> --v2 1
    1
    이미지가 저장되고 삭제해야 하는 미러 레지스트리의 URL 또는 주소를 지정합니다.

검증

  1. < file_path> 디렉터리에 생성된 working-dir 디렉터리 내에서 cluster-resources 디렉터리로 이동합니다.
  2. ImageDigestMirrorSet,ImageTagMirrorSet 및 CatalogSource 리소스에 YAML 파일이 있는지 확인합니다.

다음 단계

  • oc-mirror 플러그인 v2에서 생성한 리소스를 사용하도록 클러스터를 구성합니다.

3.5.4.3. 완전히 연결이 끊긴 환경에서 이미지 세트 미러링

OpenShift Container Platform 클러스터가 공용 인터넷에 액세스할 수 없는 완전히 연결이 끊긴 환경에서 이미지 세트를 미러링할 수 있습니다.

  1. mirror to disk: 미러링을 위해 이미지 세트가 포함된 아카이브를 준비합니다. 인터넷 액세스가 필요합니다.
  2. 수동 단계: 연결이 끊긴 미러 레지스트리의 네트워크로 아카이브를 전송합니다.
  3. 미러링할 디스크: 아카이브에서 대상 연결이 끊긴 레지스트리로 이미지 세트를 미러링하려면 미러 레지스트리에 액세스할 수 있는 환경에서 oc-mirror 플러그인 v2를 실행합니다.
3.5.4.3.1. 미러에서 디스크로 미러링

oc-mirror 플러그인 v2를 사용하여 이미지 세트를 생성하고 콘텐츠를 디스크에 저장할 수 있습니다. 그런 다음 생성된 이미지 세트를 연결이 끊긴 환경으로 전송하고 대상 레지스트리로 미러링할 수 있습니다.

oc-mirror 플러그인 v2는 이미지 세트 구성에 지정된 소스에서 컨테이너 이미지를 검색하고 로컬 디렉터리의 tar 아카이브에 추가합니다.

프로세스

  • 다음 명령을 실행하여 지정된 이미지 세트 구성의 이미지를 디스크에 미러링합니다. 

    $ oc mirror -c isc.yaml file://<file_path> --v2 1
    1
    필요한 파일 경로를 추가합니다.

검증

  1. 생성된 &lt ;file_path&gt; 디렉터리로 이동합니다.
  2. 아카이브 파일이 생성되었는지 확인합니다.

다음 단계

  • oc-mirror 플러그인 v2에서 생성한 리소스를 사용하도록 클러스터를 구성합니다.
3.5.4.3.2. 디스크에서 미러로 미러링

oc-mirror 플러그인 v2를 사용하여 디스크에서 대상 미러 레지스트리로 이미지 세트를 미러링할 수 있습니다.

oc-mirror 플러그인 v2는 로컬 디스크에서 컨테이너 이미지를 검색하여 지정된 미러 레지스트리로 전송합니다.

프로세스

  • 디스크에서 이미지 세트 파일을 처리하고 다음 명령을 실행하여 콘텐츠를 대상 미러 레지스트리에 미러링합니다. 

    $ oc mirror -c isc.yaml --from file://<file_path> docker://<mirror_registry_url> --v2 1
    1
    이미지가 저장되고 삭제해야 하는 미러 레지스트리의 URL 또는 주소를 지정합니다.

검증

  1. < file_path> 디렉터리에 생성된 working-dir 디렉터리 내에서 cluster-resources 디렉터리로 이동합니다.
  2. ImageDigestMirrorSet,ImageTagMirrorSet 및 CatalogSource 리소스에 YAML 파일이 있는지 확인합니다.

다음 단계

  • oc-mirror 플러그인 v2에서 생성한 리소스를 사용하도록 클러스터를 구성합니다.

3.5.5. 추가 리소스

3.5.6. v2에서 생성한 사용자 정의 리소스 정보

oc-mirror 플러그인 v2, ImageDigestMirrorSet (IDMS) 및 ImageTagMirrorSet (ITMS)은 태그가 참조하는 이미지가 하나 이상 발견되면 기본적으로 생성됩니다. 이러한 세트에는 릴리스의 다이제스트 또는 태그, Operator 카탈로그 및 추가 이미지에서 참조하는 이미지의 미러가 포함되어 있습니다.

IDMS( ImageDigestMirrorSet )는 미러 레지스트리를 소스 레지스트리로 연결하고 다이제스트 사양을 사용하여 이미지 가져오기 요청을 전달합니다. 그러나 ImagetagMirrorSet (ITMS) 리소스는 이미지 태그를 사용하여 이미지 가져오기 요청을 리디렉션합니다.

OLM(Operator Lifecycle Manager)은 CatalogSource 리소스를 사용하여 미러 레지스트리에서 사용 가능한 Operator에 대한 정보를 검색합니다.

OSUS 서비스는 UpdateService 리소스를 사용하여 연결이 끊긴 환경에 Cincinnati 그래프를 제공합니다.

3.5.6.1. oc-mirror 플러그인 v2에서 생성한 리소스를 사용하도록 클러스터 구성

미러 레지스트리로 이미지를 미러링한 후 생성된 ImageDigestMirrorSet (IDMS), ImageTagMirrorSet (ITMS), CatalogSource 및 UpdateService 를 클러스터에 적용해야 합니다.

중요

oc-mirror 플러그인 v2에서 IDMS 및 ITMS 파일은 oc-mirror 플러그인 v1의 ICSP 파일과 달리 전체 이미지 세트를 다룹니다. 따라서 IDMS 및 ITMS 파일에는 증분 미러링 중에 새 이미지만 추가하는 경우에도 세트의 모든 이미지가 포함됩니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  • 다음 명령을 실행하여 결과 디렉터리의 YAML 파일을 클러스터에 적용합니다. 

    $ oc apply -f <path_to_oc-mirror_workspace>/working-dir/cluster-resources

검증

  1. 다음 명령을 실행하여 ImageDigestMirrorSet 리소스가 성공적으로 설치되었는지 확인합니다. 

    $ oc get imagedigestmirrorset

  2. 다음 명령을 실행하여 ImageTagMirrorSet 리소스가 성공적으로 설치되었는지 확인합니다. 

    $ oc get imagetagmirrorset

  3. 다음 명령을 실행하여 CatalogSource 리소스가 성공적으로 설치되었는지 확인합니다. 

    $ oc get catalogsource -n openshift-marketplace

3.5.7. 연결이 끊긴 환경에서 이미지 삭제

oc-mirror 플러그인 v2를 사용하려면 이전에 배포된 이미지를 삭제해야 합니다. oc-mirror 플러그인 v2에서 더 이상 자동 정리를 수행하지 않습니다.

oc-mirror 플러그인 v2를 사용할 때 이미지 구성을 삭제하려면 DeleteImageSetConfiguration 파일을 생성해야 합니다. 이렇게 하면 ImageSetConfig.yaml 을 사용하여 변경할 때 필요한 이미지 또는 배포된 이미지를 실수로 삭제하지 않습니다.

다음 예에서 DeleteImageSetConfiguration 은 다음을 제거합니다.

  • OpenShift Container Platform 릴리스 4.13.3의 모든 이미지
  • 카탈로그 이미지 redhat-operator-index v4.12.
  • aws-load-balancer-operator v0.0.1 번들 및 모든 관련 이미지
  • 해당 다이제스트에서 참조하는 ubi 및 ubi-minimal 이미지입니다.

예: DeleteImageSetConfig

apiVersion: mirror.openshift.io/v2alpha1
kind: DeleteImageSetConfiguration
delete:
  platform:
    channels:
      - name: stable-4.13
        minVersion: 4.13.3
        maxVersion: 4.13.3
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12
      packages:
      - name: aws-load-balancer-operator
         minVersion: 0.0.1
         maxVersion: 0.0.1
  additionalImages:
    - name: registry.redhat.io/ubi8/ubi@sha256:bce7e9f69fb7d4533447232478fd825811c760288f87a35699f9c8f030f2c1a6
    - name: registry.redhat.io/ubi8/ubi-minimal@sha256:8bedbe742f140108897fb3532068e8316900d9814f399d676ac78b46e740e34e

중요

mirror-to-disk 및 disk-to-mirror 워크플로우를 사용하여 미러링 문제를 줄이는 것이 좋습니다.

이미지 삭제 워크플로우에서 oc-mirror 플러그인 v2는 이미지의 매니페스트만 삭제하므로 레지스트리에 사용된 스토리지를 줄일 수 없습니다.

매니페스트가 삭제된 이미지와 같은 불필요한 이미지에서 스토리지 공간을 확보하려면 컨테이너 레지스트리에서 가비지 수집기를 활성화해야 합니다. 가비지 수집기가 활성화되면 레지스트리는 더 이상 매니페스트에 대한 참조가 없는 이미지 Blob을 삭제하여 이전에 삭제된 Blob에서 차지한 스토리지를 줄입니다. 가비지 수집기 활성화는 컨테이너 레지스트리에 따라 다릅니다.

중요

이미지를 삭제할 때 Operator 카탈로그 이미지 삭제를 건너뛰려면 DeleteImageSetConfiguration 파일의 Operator 카탈로그 이미지 아래에 특정 Operator를 나열해야 합니다. 이렇게 하면 카탈로그 이미지가 아닌 지정된 Operator만 삭제됩니다.

Operator 카탈로그 이미지만 지정하면 해당 카탈로그 내의 모든 Operator와 카탈로그 이미지 자체가 삭제됩니다.

3.5.7.1. 연결이 끊긴 환경에서 이미지 삭제

oc-mirror 플러그인 v2를 사용하여 연결이 끊긴 환경에서 이미지를 삭제하려면 절차를 따르십시오.

프로세스

  1. 이전 이미지를 삭제하는 YAML 파일을 생성합니다. 

    $ oc mirror delete --config delete-image-set-config.yaml --workspace file://<previously_mirrored_work_folder> --v2 --generate docker://<remote_registry>

    다음과 같습니다.

    • <previously_mirrored_work_folder >: 미러링 프로세스 중에 이미지가 이전에 미러링되었거나 저장된 디렉토리를 사용합니다.
    • <remote_registry >: 이미지가 삭제될 원격 컨테이너 레지스트리의 URL 또는 주소를 삽입합니다.
  2. 생성된 &lt ;previously_mirrored_work_folder>/delete 디렉터리로 이동합니다.
  3. delete-images.yaml 파일이 생성되었는지 확인합니다.
  4. 파일에 나열된 각 이미지가 더 이상 클러스터에 필요하지 않으며 레지스트리에서 안전하게 제거할 수 있는지 수동으로 확인합니다.

  5. 삭제 YAML 파일을 생성한 후 원격 레지스트리에서 이미지를 삭제합니다. 

    $ oc mirror delete --v2 --delete-yaml-file <previously_mirrored_work_folder>/working-dir/delete/delete-images.yaml docker://<remote_registry>

    다음과 같습니다.

    • <previously_mirrored_work_folder > : 이전에 미러링된 작업 폴더를 지정합니다.

      중요

      mirror-to-mirror 절차를 사용하는 경우 이미지가 로컬에 캐시되지 않으므로 로컬 캐시에서 이미지를 삭제할 수 없습니다.

3.5.8. 미러링을 위해 선택한 이미지 확인

oc-mirror 플러그인 v2를 사용하여 실제로 이미지를 미러링하지 않는 테스트 실행(dry run)을 수행할 수 있습니다. 이를 통해 미러링할 이미지 목록을 검토할 수 있습니다. 예행 실행을 사용하여 이미지 세트 구성에서 오류를 조기에 파악할 수 있습니다. 미러-디스크 워크플로우에서 예행 실행을 실행하는 경우 oc-mirror 플러그인 v2는 이미지 세트 내의 모든 이미지를 캐시에서 사용할 수 있는지 확인합니다. 누락된 이미지는 missing.txt 파일에 나열됩니다. 미러링 전에 예행 실행이 수행되면 missing.txt 및 mapping.txt 파일에 동일한 이미지 목록이 포함됩니다.

3.5.8.1. oc-mirror 플러그인 v2에 대한 시험 실행 수행

이미지를 미러링하지 않고 시험 실행을 수행하여 이미지 세트 구성을 확인합니다. 이렇게 하면 설정이 올바르며 의도하지 않은 변경을 방지할 수 있습니다.

프로세스

  • 테스트 실행을 수행하려면 oc mirror 명령을 실행하고 --dry-run 인수를 명령에 추가합니다. 

    $ oc mirror -c <image_set_config_yaml> --from file://<oc_mirror_workspace_path> docker://<mirror_registry_url> --dry-run --v2

    다음과 같습니다.

    • <image_set_config_yaml >: 방금 생성한 이미지 세트 구성 파일을 사용합니다.
    • <oc_mirror_workspace_path > : 작업 공간 경로의 주소를 삽입합니다.

    • <mirror_registry_url >: 이미지가 삭제될 원격 컨테이너 레지스트리의 URL 또는 주소를 삽입합니다.

      출력 예

      $ oc mirror --config /tmp/isc_dryrun.yaml file://<oc_mirror_workspace_path> --dry-run --v2

[INFO]   : :warning:  --v2 flag identified, flow redirected to the oc-mirror v2 version. This is Tech Preview, it is still under development and it is not production ready.
[INFO]   : :wave: Hello, welcome to oc-mirror
[INFO]   : :gear:  setting up the environment for you...
[INFO]   : :twisted_rightwards_arrows: workflow mode: mirrorToDisk
[INFO]   : :sleuth_or_spy:  going to discover the necessary images...
[INFO]   : :mag: collecting release images...
[INFO]   : :mag: collecting operator images...
[INFO]   : :mag: collecting additional images...
[WARN]   : :warning:  54/54 images necessary for mirroring are not available in the cache.
[WARN]   : List of missing images in : CLID-19/working-dir/dry-run/missing.txt.
please re-run the mirror to disk process
[INFO]   : :page_facing_up: list of all images for mirroring in : CLID-19/working-dir/dry-run/mapping.txt
[INFO]   : mirror time     : 9.641091076s
[INFO]   : :wave: Goodbye, thank you for using oc-mirror

검증

  1. 생성된 작업 공간 디렉터리로 이동합니다. 

    $ cd <oc_mirror_workspace_path>
  2. 생성된 mapping.txt 및 missing.txt 파일을 검토합니다. 이러한 파일에는 미러링된 모든 이미지 목록이 포함되어 있습니다.

3.5.8.2. oc-mirror 플러그인 v2 오류 문제 해결

oc-mirror 플러그인 v2는 이제 모든 이미지 미러링 오류를 별도의 파일에 기록하므로 오류를 더 쉽게 추적하고 진단할 수 있습니다.

중요

릴리스 또는 릴리스 구성 요소 이미지를 미러링하는 동안 오류가 발생하면 중요합니다. 이렇게 하면 미러링 프로세스가 즉시 중지됩니다.

Operator, Operator 관련 이미지 또는 추가 이미지 미러링 관련 오류로 인해 미러링 프로세스가 중지되지 않습니다. 미러링은 계속되고 oc-mirror 플러그인 v2는 8개의 이미지마다 업데이트됩니다.

이미지가 미러링되지 않고 해당 이미지가 하나 이상의 Operator 번들의 일부로 미러링되는 경우 oc-mirror 플러그인 v2는 사용자에게 Operator가 불완전함을 알립니다. 그러면 오류의 영향을 받는 Operator 번들이 명확하게 표시됩니다.

프로세스

  1. 서버 관련 문제를 확인합니다.

    오류 예

    [ERROR]  : [Worker] error mirroring image localhost:55000/openshift/graph-image:latest error: copying image 1/4 from manifest list: trying to reuse blob sha256:edab65b863aead24e3ed77cea194b6562143049a9307cd48f86b542db9eecb6e at destination: pinging container registry localhost:5000: Get "https://localhost:5000/v2/": http: server gave HTTP response to HTTPS client

    1. oc-mirror 플러그인 v2 출력 디렉터리에 있는 working-dir/logs 폴더에서 mirroring_error_date_time.log 파일을 엽니다.
    2. HTTP 500 오류, 만료된 토큰 또는 타임아웃과 같이 일반적으로 서버 측 문제를 나타내는 오류 메시지를 찾습니다.
    3. 문제가 지속되면 미러링 프로세스 다시 시도하거나 지원에 문의합니다.

  2. Operator의 불완전한 미러링을 확인합니다.

    오류 예

    error mirroring image docker://registry.redhat.io/3scale-amp2/zync-rhel9@sha256:8bb6b31e108d67476cc62622f20ff8db34efae5d58014de9502336fcc479d86d (Operator bundles: [3scale-operator.v0.11.12] - Operators: [3scale-operator]) error: initializing source docker://localhost:55000/3scale-amp2/zync-rhel9:8bb6b31e108d67476cc62622f20ff8db34efae5d58014de9502336fcc479d86d: reading manifest 8bb6b31e108d67476cc62622f20ff8db34efae5d58014de9502336fcc479d86d in localhost:55000/3scale-amp2/zync-rhel9: manifest unknown
error mirroring image docker://registry.redhat.io/3scale-amp2/3scale-rhel7-operator-metadata@sha256:de0a70d1263a6a596d28bf376158056631afd0b6159865008a7263a8e9bf0c7d error: skipping operator bundle docker://registry.redhat.io/3scale-amp2/3scale-rhel7-operator-metadata@sha256:de0a70d1263a6a596d28bf376158056631afd0b6159865008a7263a8e9bf0c7d because one of its related images failed to mirror
error mirroring image docker://registry.redhat.io/3scale-amp2/system-rhel7@sha256:fe77272021867cc6b6d5d0c9bd06c99d4024ad53f1ab94ec0ab69d0fda74588e (Operator bundles: [3scale-operator.v0.11.12] - Operators: [3scale-operator]) error: initializing source docker://localhost:55000/3scale-amp2/system-rhel7:fe77272021867cc6b6d5d0c9bd06c99d4024ad53f1ab94ec0ab69d0fda74588e: reading manifest fe77272021867cc6b6d5d0c9bd06c99d4024ad53f1ab94ec0ab69d0fda74588e in localhost:55000/3scale-amp2/system-rhel7: manifest unknown

    1. 콘솔 또는 로그 파일에서 불완전한 Operator를 나타내는 경고를 확인합니다.

      Operator가 불완전한 것으로 표시되는 경우 해당 Operator와 관련된 이미지를 미러링하지 못할 수 있습니다.

    2. 누락된 이미지를 수동으로 미러링하거나 미러링 프로세스를 다시 시도합니다.

  3. 생성된 클러스터 리소스와 관련된 오류가 있는지 확인합니다. 일부 이미지가 미러링되지 않더라도 oc-mirror v2는 성공적으로 미러링된 이미지에 대한 IDMS.yaml 및 ITMS.yaml 파일과 같은 클러스터 리소스를 계속 생성합니다.

    1. 생성된 파일의 출력 디렉터리를 확인합니다.
    2. 이러한 파일이 특정 이미지에 대해 누락된 경우 미러링 프로세스 중에 해당 이미지에 대한 중요한 오류가 발생하지 않았는지 확인합니다.

이러한 단계를 수행하면 문제를 더 잘 진단하고 원활한 미러링을 보장할 수 있습니다.

3.5.9. enclave 지원의 이점

Enclave 지원은 네트워크의 특정 부분에 대한 내부 액세스를 제한합니다. 방화벽 경계를 통한 인바운드 및 아웃바운드 트래픽 액세스를 허용하는 DMZ(비밀화 영역) 네트워크와 달리 enclaves는 방화벽 경계를 통과하지 않습니다.

중요

Enclave 지원은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

새로운 enclave 지원 기능은 하나 이상의 중간 연결이 끊긴 네트워크 뒤에서 보호되는 여러 enclav에 미러링이 필요한 시나리오에 적합합니다.

Enclave 지원에는 다음과 같은 이점이 있습니다.

  • 여러 개의 enclaves의 콘텐츠를 미러링하고 단일 내부 레지스트리에 중앙 집중화할 수 있습니다. 일부 고객은 미러링된 컨텐츠에서 보안 검사를 실행하려고 하므로 이 설정을 사용하면 이러한 검사를 모두 한 번에 실행할 수 있습니다. 그런 다음 콘텐츠는 다운스트림으로 미러링되기 전에 비정형됩니다.
  • 각 enclave에 대해 인터넷에서 미러링 프로세스를 다시 시작하지 않고 중앙 집중식 내부 레지스트리에서 직접 콘텐츠를 미러링할 수 있습니다.
  • 네트워크 단계 간의 데이터 전송을 최소화하여 Blob 또는 이미지가 한 단계에서 다른 단계로만 전송되도록 할 수 있습니다.

3.5.9.1. Enclave 미러링 워크플로

Enclave 지원

이전 이미지는 인터넷 연결이 있고 없이 환경을 포함하여 다양한 환경에서 oc-mirror 플러그인을 사용하는 흐름을 간략하게 설명합니다.

인터넷 연결이 있는 환경:

  1. 사용자는 oc-mirror 플러그인 v2를 실행하여 온라인 레지스트리의 콘텐츠를 로컬 디스크 디렉터리로 미러링합니다.
  2. 미러링된 콘텐츠는 오프라인 환경으로 전송하기 위해 디스크에 저장됩니다.

연결이 끊긴 엔터프라이즈 환경(인터넷 없음):

  • 흐름 1:

    • 사용자는 oc-mirror 플러그인 v2를 실행하여 온라인 환경에서 enterprise-registry.in 레지스트리로 전송된 디스크 디렉터리에서 미러링된 콘텐츠를 로드합니다.

  • 흐름 2:

    1. registries.conf 파일을 업데이트한 후 사용자는 oc-mirror 플러그인 v2를 실행하여 enterprise-registry.in 레지스트리의 콘텐츠를 enclave 환경으로 미러링합니다.
    2. 콘텐츠는 enclave로 전송하기 위해 디스크 디렉터리에 저장됩니다.

Enclave 환경 (인터넷 없음):

  • 사용자는 oc-mirror 플러그인 v2를 실행하여 디스크 디렉터리의 콘텐츠를 enclave-registry.in 레지스트리로 로드합니다.

이미지는 이러한 환경에서 데이터 흐름을 시각적으로 나타내며 oc-mirror를 사용하여 인터넷 연결 없이 연결이 끊긴 환경을 처리합니다.

3.5.9.2. enclave에 미러링

enclave에 미러링할 때는 먼저 필요한 이미지를 하나 이상의 enclav에서 엔터프라이즈 중앙 레지스트리로 전송해야 합니다.

중앙 레지스트리는 보안 네트워크, 특히 연결이 끊긴 환경 내에 있으며 공용 인터넷에 직접 연결되지 않습니다. 그러나 사용자는 공용 인터넷에 액세스할 수 있는 환경에서 oc mirror 를 실행해야 합니다.

프로세스

  1. 연결이 끊긴 환경에서 oc-mirror 플러그인 v2를 실행하기 전에 registries.conf 파일을 생성합니다. 파일의 TOML 형식은 이 사양에 설명되어 있습니다.

    참고

    $HOME/.config/containers/registries.conf 또는 /etc/containers/registries.conf 아래에 파일을 저장하는 것이 좋습니다.

    registries.conf예

    [[registry]]
location="registry.redhat.io"
[[registry.mirror]]
location="<enterprise-registry.in>"

[[registry]]
location="quay.io"
[[registry.mirror]]
location="<enterprise-registry.in>"

  2. 미러 아카이브를 생성합니다.

    1. 모든 OpenShift Container Platform 콘텐츠를 < file_path>/enterprise-content 아래의 아카이브로 수집하려면 다음 명령을 실행합니다. 

      $ oc mirror --v2 -c isc.yaml file://<file_path>/enterprise-content

      isc.yaml의 예

      apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    architectures:
      - "amd64"
    channels:
      - name: stable-4.15
        minVersion: 4.15.0
        maxVersion: 4.15.3

      아카이브가 생성되면 연결이 끊긴 환경으로 전송됩니다. 전송 메커니즘은 oc-mirror 플러그인 v2의 일부가 아닙니다. 엔터프라이즈 네트워크 관리자는 전송 전략을 결정합니다.

      경우에 따라 디스크가 물리적으로 한 위치에서 연결 해제되고 연결이 끊긴 환경의 다른 컴퓨터에 연결되어 있음을 전송이 수동으로 수행됩니다. 다른 경우에는 FTP(Secure File Transfer Protocol) 또는 기타 프로토콜이 사용됩니다.

  3. 아카이브 전송이 완료되면 다음 예에 설명된 대로 관련 아카이브 콘텐츠를 레지스트리(예의entrerpise_registry.in )에 미러링하기 위해 oc-mirror 플러그인 v2를 다시 실행할 수 있습니다. 

    $ oc mirror --v2 -c isc.yaml --from file://<disconnected_environment_file_path>/enterprise-content docker://<enterprise_registry.in>/

    다음과 같습니다.

    • --from 은 아카이브가 포함된 폴더를 가리킵니다. file:// 로 시작합니다.
    • docker:// 는 미러링의 대상이 최종 인수입니다. 이는 docker 레지스트리이기 때문입니다.
    • -c (--config)는 필수 인수입니다. oc-mirror 플러그인 v2가 결국 아카이브의 하위 부분만 레지스트리에 미러링할 수 있습니다. 하나의 아카이브에는 여러 OpenShift Container Platform 릴리스가 포함될 수 있지만 연결이 끊긴 환경 또는 enclave는 몇 개만 미러링할 수 있습니다.

  4. enclave에 미러링할 콘텐츠를 설명하는 imageSetConfig YAML 파일을 준비합니다.

    isc-enclave.yaml의 예

    apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    architectures:
      - "amd64"
    channels:
      - name: stable-4.15
        minVersion: 4.15.2
        maxVersion: 4.15.2

    연결이 끊긴 레지스트리에 액세스할 수 있는 머신에서 oc-mirror 플러그인 v2를 실행해야 합니다. 이전 예에서 연결이 끊긴 환경 enterprise-registry.in 에 액세스할 수 있습니다.

  5. 그래프 URL 업데이트

    graph:true 를 사용하는 경우 oc-mirror 플러그인 v2는 cincinnati API 끝점에 도달하려고 시도합니다. 이 환경의 연결이 끊어지면 UPDATE_URL_OVERRIDE 환경 변수 OSUS(OpenShift Update Service)의 URL을 참조하도록 환경 변수 UPDATE_URL_OVERRIDE를 내보내야 합니다. 

    $ export UPDATE_URL_OVERRIDE=https://<osus.enterprise.in>/graph

    OpenShift 클러스터에서 OSUS를 설정하는 방법에 대한 자세한 내용은 "OpenShift Update Service를 사용하여 연결이 끊긴 환경에서 클러스터 업그레이드"를 참조하십시오.

참고

OpenShift Container Platform EUS (Extended Update Support) 버전을 업그레이드할 때 현재 버전과 대상 버전 간에 중간 버전이 필요할 수 있습니다. 예를 들어 현재 버전이 4.14 이고 대상 버전이 4.16 인 경우 oc-mirror 플러그인 v2를 사용할 때 ImageSetConfiguration 에 4.15.8 과 같은 버전을 포함해야 할 수 있습니다.

oc-mirror 플러그인 v2가 항상 자동으로 감지되지 않을 수 있으므로 필요한 중간 버전을 확인하고 구성에 수동으로 추가하려면 Cincinnati 그래프 웹 페이지를 확인하십시오.

  1. enclave의 엔터프라이즈 레지스트리에서 미러 아카이브를 생성합니다.

    enclave1 용 아카이브를 준비하기 위해 사용자는 해당 enclave에 특정한 imageSetConfiguration 을 사용하여 엔터프라이즈 연결이 끊긴 환경에서 oc-mirror 플러그인 v2를 실행합니다. 이렇게 하면 enclave에 필요한 이미지만 미러링됩니다. 

    $ oc mirror --v2 -c isc-enclave.yaml
file:///disk-enc1/

    이 작업은 모든 OpenShift Container Platform 콘텐츠를 아카이브로 수집하고 디스크에 아카이브를 생성합니다.

  2. 아카이브가 생성되면 enclave1 네트워크로 전송됩니다. 전송 메커니즘은 oc-mirror 플러그인 v2의 책임이 아닙니다.

  3. enclave 레지스트리에 콘텐츠를 미러링

    아카이브 전송이 완료되면 사용자는 관련 아카이브 콘텐츠를 레지스트리에 미러링하기 위해 oc-mirror 플러그인 v2를 다시 실행할 수 있습니다. 

    $ oc mirror --v2 -c isc-enclave.yaml --from file://local-disk docker://registry.enc1.in

    enclave1 의 OpenShift Container Platform 클러스터 관리자는 이제 해당 클러스터를 설치하거나 업그레이드할 준비가 되었습니다.

3.5.10. Operator 카탈로그에서 필터링이 작동하는 방법

oc-mirror 플러그인 v2는 imageSetConfig 의 정보를 처리하여 미러링을 위한 번들 목록을 선택합니다.

oc-mirror 플러그인 v2는 미러링을 위한 번들을 선택할 때 GVK(그룹 버전 종류) 또는 번들 종속성을 유추하지 않고 미러링 세트에서 생략합니다. 대신 사용자 지침을 엄격하게 준수합니다. 필요한 종속 패키지 및 해당 버전을 명시적으로 지정해야 합니다.

번들 버전은 일반적으로 의미 체계 버전 관리 표준(SemVer)을 사용하며 채널 내의 번들을 버전별로 정렬할 수 있습니다. ImageSetConfig 에서 특정 범위에 속하는 구두를 선택할 수 있습니다.

이 선택 알고리즘은 oc-mirror 플러그인 v1에 비해 일관된 결과를 보장합니다. 그러나 대체, 건너뛰기 및 skip Range 와 같은 업그레이드 그래프 세부 정보는 포함되지 않습니다. 이 접근 방식은 OLM 알고리즘과 다릅니다. minVersion 과 maxVersion 사이의 업그레이드 경로가 잠재적으로 짧아지므로 클러스터를 업그레이드하는 데 필요한 것보다 많은 번들을 미러링할 수 있습니다.

표 3.4. 다음 표를 사용하여 다양한 시나리오에 포함된 번들 버전을 확인하십시오.
ImageSetConfig Operator 필터링예상되는 번들 버전

시나리오 1 

mirror:
 operators:
   - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10

카탈로그의 각 패키지에 대해 해당 패키지의 기본 채널의 헤드 버전에 해당하는 1개의 번들입니다.

시나리오 2 

mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
      full: true

지정된 카탈로그의 모든 채널의 모든 번들

시나리오 3 

mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
     packages:
    - name: compliance-operator

해당 패키지의 기본 채널의 헤드 버전에 해당하는 하나의 번들

시나리오 4 

mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
      full: true
      - packages:
          - name: elasticsearch-operator

지정된 패키지에 대한 모든 채널의 모든 번들

시나리오 5 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
       minVersion: 5.6.0

minVersion 에서 기본 채널의 모든 번들은 그래프 업그레이드에서 가장 짧은 경로에 의존하지 않는 해당 패키지의 채널 헤드까지입니다.

시나리오 6 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        maxVersion: 6.0.0

기본 채널의 모든 번들에 해당 패키지의 maxVersion 보다 낮은 모든 번들이 있습니다.

시나리오 7 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        minVersion: 5.6.0
        maxVersion: 6.0.0

해당 패키지의 minVersion 과 maxVersion 사이의 기본 채널의 모든 번들입니다. 여러 채널이 필터링에 포함되어 있어도 채널 헤드가 포함되지 않습니다.

시나리오 8 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        channels
          - name: stable

해당 패키지의 선택한 채널의 헤드 번들입니다.

시나리오 9 

mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.10
      full: true
      - packages:
          - name: elasticsearch-operator
            channels:
               - name: 'stable-v0'

지정된 패키지 및 채널에 대한 모든 번들입니다.

시나리오 10 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        channels
          - name: stable
          - name: stable-5.5

해당 패키지의 선택한 각 채널에 대한 헤드 번들입니다.

시나리오 11 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        channels
          - name: stable
            minVersion: 5.6.0

해당 패키지의 선택한 채널 내에서 minVersion 부터 채널 헤드까지 모든 버전을 사용합니다. 이 시나리오에서는 업그레이드 그래프에서 가장 짧은 경로를 사용하지 않습니다.

시나리오 12 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        channels
          - name: stable
            maxVersion: 6.0.0

해당 패키지의 선택한 채널 내에서 최대 maxVersion 까지 모든 버전(업그레이드 그래프에서 가장 짧은 경로에 의존하지 않음). 여러 채널이 필터링에 포함되어 있어도 채널 헤드가 포함되지 않습니다.

시나리오 13 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
       channels
          - name: stable
            minVersion: 5.6.0
            maxVersion: 6.0.0

해당 패키지의 선택한 채널 내에서 minVersion 과 maxVersion 사이의 모든 버전이 업그레이드 그래프에서 가장 짧은 경로에 의존하지 않습니다. 여러 채널이 필터링에 포함되어 있어도 채널 헤드가 포함되지 않습니다.

시나리오 14 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
    packages:
    - name: aws-load-balancer-operator
      bundles:
      - name: aws-load-balancer-operator.v1.1.0
    - name: 3scale-operator
      bundles:
      - name: 3scale-operator.v0.10.0-mas

각 패키지에 지정된 번들만 필터링에 포함됩니다.

시나리오 15 

mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        channels
          - name: stable
        minVersion: 5.6.0
        maxVersion: 6.0.0

이 시나리오를 사용하지 마십시오. minVersion 또는 maxVersion 으로 패키지를 필터링하는 것은 허용되지 않습니다.

시나리오 16 

mirror:
  operators:
   - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: compliance-operator
        channels
          - name: stable
        minVersion: 5.6.0
        maxVersion: 6.0.0

이 시나리오를 사용하지 마십시오. full:true 및 minVersion 또는 maxVersion 을 사용하여 필터링할 수 없습니다.

시나리오 17 

mirror:
  operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
      full: true
    packages:
    - name: compliance-operator
        channels
          - name: stable
            minVersion: 5.6.0
            maxVersion: 6.0.0

이 시나리오를 사용하지 마십시오. full:true 및 minVersion 또는 maxVersion 을 사용하여 필터링할 수 없습니다.

3.5.11. oc-mirror 플러그인 v2의 이미지 세트 구성 매개변수

oc-mirror 플러그인 v2에는 미러링할 이미지를 정의하는 이미지 세트 구성 파일이 필요합니다. 다음 표에는 ImageSetConfiguration 리소스에 사용 가능한 매개변수가 나열되어 있습니다.

참고

minVersion 및 maxVersion 속성을 사용하여 특정 Operator 버전 범위를 필터링하면 여러 채널 헤드 오류가 발생할 수 있습니다. 오류 메시지는 여러 채널 헤드 가 있음을 나타냅니다. 필터가 적용되면 Operator의 업데이트 그래프가 잘립니다.

OLM에는 모든 Operator 채널에 정확히 하나의 엔드 포인트, 즉 최신 버전의 Operator가 있는 업데이트 그래프를 형성하는 버전이 포함되어 있어야 합니다. 필터 범위가 적용되면 해당 그래프는 두 개 이상의 개별 그래프 또는 두 개 이상의 끝점이 있는 그래프로 전환할 수 있습니다.

이 오류를 방지하려면 최신 버전의 Operator를 필터링하지 마십시오. Operator에 따라 오류가 계속 실행되는 경우 maxVersion 속성을 늘리거나 minVersion 속성을 줄여야 합니다. 모든 Operator 그래프는 다를 수 있으므로 오류가 해결될 때까지 이러한 값을 조정해야 할 수 있습니다.

표 3.5. ImageSetConfiguration 매개변수
매개변수설명값

apiVersion

ImageSetConfiguration 콘텐츠의 API 버전입니다.

문자열 예: mirror.openshift.io/v2alpha1

archiveSize

이미지 세트 내의 각 아카이브 파일의 최대 크기(GiB)입니다.

정수 예: 4

kubeVirtContainer

true 로 설정하면 HyperShift KubeVirt CoreOS 컨테이너의 이미지를 포함합니다.

부울 예 ImageSetConfiguration 파일: 

apiVersion: mirror.openshift.io/v2alpha1
kind: ImageSetConfiguration
mirror:
  platform:
    channels:
    - name: stable-4.16
      minVersion: 4.16.0
      maxVersion: 4.16.0
    kubeVirtContainer: true

mirror

이미지 세트의 구성입니다.

개체

mirror.additionalImages

이미지 세트의 추가 이미지 구성입니다.

개체 배열

예제: 

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest

mirror.additionalImages.name

미러링할 이미지의 태그 또는 다이제스트입니다.

문자열 예: registry.redhat.io/ubi8/ubi:latest

mirror.blockedImages

미러링을 차단할 이미지의 전체 태그, 다이제스트 또는 패턴입니다.

문자열 배열 예: docker.io/ Cryostat/alpine

mirror.operators

이미지 세트의 Operator 구성

개체 배열

예제: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:4.17
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'

mirror.operators.catalog

이미지 세트에 포함할 Operator 카탈로그입니다.

문자열 예: registry.redhat.io/redhat/redhat-operator-index:v4.15

mirror.operators.full

true 인 경우 전체 카탈로그, Operator 패키지 또는 Operator 채널을 다운로드합니다.

부울 값은 false 입니다.

mirror.operators.packages

Operator 패키지 구성입니다.

개체 배열

예제: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:4.17
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'

mirror.operators.packages.name

이미지 세트에 포함할 Operator 패키지 이름입니다.

문자열 예: elasticsearch-operator

mirror.operators.packages.channels

Operator 패키지 채널 구성

개체

mirror.operators.packages.channels.name

이미지 세트에 포함할 Operator 채널 이름은 패키지 내에서 고유합니다.

문자열 Eample: fast 또는 stable-v4.15

mirror.operators.packages.channels.maxVersion

Operator의 가장 높은 버전은 존재하는 모든 채널에서 미러링됩니다.

문자열 예: 5.2.3-31

mirror.operators.packages.channels.minVersion

존재하는 모든 채널에 미러링할 가장 낮은 버전의 Operator

문자열 예: 5.2.3-31

mirror.operators.packages.maxVersion

존재하는 모든 채널에 미러링할 Operator의 가장 높은 버전입니다.

문자열 예: 5.2.3-31

mirror.operators.packages.minVersion

존재하는 모든 채널에 미러링할 Operator의 가장 낮은 버전입니다.

문자열 예: 5.2.3-31

mirror.operators.packages.bundles

선택한 번들 구성

개체 배열

예제: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:4.17
    packages:
    - name: 3scale-operator
      bundles:
      - name: 3scale-operator.v0.10.0-mas

mirror.operators.packages.bundles.name

미러용으로 선택한 번들의 이름입니다(카탈로그에 표시됨).

문자열 예 : 3scale-operator.v0.10.0-mas

mirror.operators.targetCatalog

참조된 카탈로그를 미러링하는 대체 이름 및 선택적 네임스페이스 계층 구조

문자열 예: my-namespace/my-operator-catalog

mirror.operators.targetCatalogSourceTemplate

oc-mirror 플러그인 v2에서 생성한 catalogSource 사용자 정의 리소스를 완료하는 데 사용할 템플릿의 디스크 경로입니다.

문자열 예: /tmp/catalog-source_template.yaml 템플릿 파일의 예: 

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: discarded
  namespace: openshift-marketplace
spec:
  image: discarded
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 30m0s

mirror.operators.targetTag

targetName 또는 targetCatalog 에 추가할 대체 태그입니다.

문자열 예: v1

mirror.platform

이미지 세트의 플랫폼 구성입니다.

개체

mirror.platform.architectures

미러링할 플랫폼 릴리스 페이로드의 아키텍처입니다.

문자열 배열은 다음과 같습니다. 

architectures:
  - amd64
  - arm64
  - multi
  - ppc64le
  - s390x

기본값은 amd64 입니다. 값 multi 를 사용하면 사용 가능한 모든 아키텍처에 대해 미러링이 지원되므로 개별 아키텍처를 지정할 필요가 없습니다.

mirror.platform.channels

이미지 세트의 플랫폼 채널 구성입니다.

오브젝트 배열은 다음과 같습니다. 

channels:
  - name: stable-4.12
  - name: stable-4.17

mirror.platform.channels.full

true 인 경우 minVersion 을 채널의 첫 번째 릴리스로 설정하고 maxVersion 을 채널의 마지막 릴리스로 설정합니다.

부울 값 기본값은 false입니다.

mirror.platform.channels.name

릴리스 채널의 이름

문자열 예: stable-4.15

mirror.platform.channels.minVersion

미러링할 참조된 플랫폼의 최소 버전입니다.

문자열 예: 4.12.6

mirror.platform.channels.maxVersion

참조된 플랫폼의 가장 높은 버전을 미러링합니다.

문자열 예: 4.15.1

mirror.platform.channels.shortestPath

경로 미러링 또는 전체 범위 미러링을 전환합니다.

부울 값 기본값은 false입니다.

mirror.platform.channels.type

미러링할 플랫폼의 유형

문자열 예: ocp 또는 okd. 기본값은 ocp 입니다.

mirror.platform.graph

OSUS 그래프가 이미지 세트에 추가되고 나중에 미러에 게시되는지 여부를 나타냅니다.

부울 값 기본값은 false입니다.

3.5.11.1. ImageSet 구성 매개변수 삭제

oc-mirror 플러그인 v2를 사용하려면 미러 레지스트리에서 삭제할 이미지를 정의하는 삭제 이미지 세트 구성 파일이 있어야 합니다. 다음 표에는 DeleteImageSetConfiguration 리소스에 사용 가능한 매개변수가 나열되어 있습니다.

표 3.6. DeleteImageSetConfiguration 매개변수
매개변수설명값

apiVersion

DeleteImageSetConfiguration 콘텐츠의 API 버전입니다.

문자열 예: mirror.openshift.io/v2alpha1

삭제

삭제할 이미지 세트의 구성입니다.

개체

delete.additionalImages

삭제 이미지 세트의 추가 이미지 구성입니다.

오브젝트 배열은 다음과 같습니다. 

additionalImages:
  - name: registry.redhat.io/ubi8/ubi:latest

delete.additionalImages.name

삭제할 이미지의 태그 또는 다이제스트입니다.

문자열 예: registry.redhat.io/ubi8/ubi:latest

delete.operators

삭제 이미지 세트의 Operator 구성입니다.

오브젝트 배열은 다음과 같습니다. 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:{product-version}
    packages:
      - name: elasticsearch-operator
        minVersion: '2.4.0'

delete.operators.catalog

삭제 이미지 세트에 포함할 Operator 카탈로그입니다.

문자열 예: registry.redhat.io/redhat/redhat-operator-index:v4.15

delete.operators.full

true인 경우 전체 카탈로그, Operator 패키지 또는 Operator 채널을 삭제합니다.

부울 값 기본값은 false입니다.

delete.operators.packages

Operator 패키지 구성

오브젝트 배열은 다음과 같습니다. 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:{product-version}
    packages:
      - name: elasticsearch-operator
        minVersion: '5.2.3-31'

delete.operators.packages.name

삭제 이미지 세트에 포함할 Operator 패키지 이름입니다.

문자열 예: elasticsearch-operator

delete.operators.packages.channels

Operator 패키지 채널 구성

개체

delete.operators.packages.channels.name

삭제 이미지 세트에 포함할 Operator 채널 이름(패키지 내에서 고유함)입니다.

문자열 예: fast 또는 stable-v4.15

delete.operators.packages.channels.maxVersion

선택한 채널 내에서 삭제할 Operator의 가장 높은 버전입니다.

문자열 예: 5.2.3-31

delete.operators.packages.channels.minVersion

존재하는 선택 범위 내에서 삭제할 Operator의 가장 낮은 버전입니다.

문자열 예: 5.2.3-31

delete.operators.packages.maxVersion

존재하는 모든 채널에서 삭제할 Operator의 가장 높은 버전입니다.

문자열 예: 5.2.3-31

delete.operators.packages.minVersion

존재하는 모든 채널에서 삭제할 Operator의 가장 낮은 버전입니다.

문자열 예: 5.2.3-31

delete.operators.packages.bundles

선택한 번들 구성

개체 배열

동일한 Operator에 대해 채널과 번들을 모두 선택할 수 없습니다.

예제: 

operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:{product-version}
    packages:
    - name: 3scale-operator
      bundles:
      - name: 3scale-operator.v0.10.0-mas

delete.operators.packages.bundles.name

삭제할 번들의 이름(카탈로그에 표시됨)

문자열 예 : 3scale-operator.v0.10.0-mas

delete.platform

이미지 세트의 플랫폼 구성

개체

delete.platform.architectures

삭제할 플랫폼 릴리스 페이로드의 아키텍처입니다.

문자열 배열은 다음과 같습니다. 

architectures:
  - amd64
  - arm64
  - multi
  - ppc64le
  - s390x

기본값은 amd64입니다.

delete.platform.channels

이미지 세트의 플랫폼 채널 구성입니다.

개체 배열

예제: 

channels:
  - name: stable-4.12
  - name: stable-4.17

delete.platform.channels.full

true 인 경우 minVersion 을 채널의 첫 번째 릴리스로 설정하고 maxVersion 을 채널의 마지막 릴리스로 설정합니다.

부울 값 기본값은 false입니다.

delete.platform.channels.name

릴리스 채널의 이름

문자열 예: stable-4.15

delete.platform.channels.minVersion

삭제할 참조 플랫폼의 최소 버전입니다.

문자열 예: 4.12.6

delete.platform.channels.maxVersion

삭제할 가장 높은 버전의 참조 플랫폼입니다.

문자열 예: 4.15.1

delete.platform.channels.shortestPath

가장 짧은 경로를 삭제하고 전체 범위를 삭제하는 사이를 전환합니다.

부울 값 기본값은 false입니다.

delete.platform.channels.type

삭제할 플랫폼의 유형

문자열 예: ocp 또는 okd 기본값은 ocp입니다.

delete.platform.graph

미러 레지스트리에서도 OSUS 그래프가 삭제되었는지 여부를 확인합니다.

부울 값 기본값은 false입니다.

3.5.12. oc-mirror 플러그인 v2에 대한 명령 참조

다음 표에서는 oc-mirror 플러그인 v2의 oc mirror 하위 명령 및 플래그를 설명합니다.

표 3.7. oc-mirror 플러그인 v2의 하위 명령 및 플래그
하위 명령설명

help

모든 하위 명령에 대한 도움말 표시

version

oc-mirror 버전을 출력합니다.

삭제

원격 레지스트리 및 로컬 캐시의 이미지를 삭제합니다.

표 3.8. oc mirror 플래그
플래그설명

--authfile

인증 파일의 문자열 경로를 표시합니다. 기본값은 ${XDG_RUNTIME_DIR}/containers/auth.json 입니다.

-c, --config <string>

이미지 세트 구성 파일의 경로를 지정합니다.

--dest-tls-verify

HTTPS가 필요하며 컨테이너 레지스트리 또는 데몬에 액세스할 때 인증서를 확인합니다.

--dry-run

이미지를 미러링하지 않고 작업 출력

--from <string>

oc-mirror 플러그인 v2를 실행하여 대상 레지스트리를 로드하여 생성된 이미지 세트 아카이브의 경로를 지정합니다.

-h, --help

도움말 표시

--loglevel

문자열 로그 수준을 표시합니다. 지원되는 값에는 info, debug, trace, error가 포함됩니다. 기본값은 info 입니다.

-p,--port

oc-mirror 플러그인 v2 로컬 스토리지 인스턴스에서 사용하는 HTTP 포트를 결정합니다. 기본값은 55000 입니다.

--max-nested-paths <int>

중첩된 경로를 제한하는 대상 레지스트리의 최대 중첩된 경로 수를 지정합니다. 기본값은 0입니다.

--secure-policy

기본값은 false 입니다. 기본값이 아닌 값을 설정하면 명령은 서명 확인을 위한 보안 정책인 서명 확인을 활성화합니다.

--since

지정된 날짜 이후의 모든 새 콘텐츠를 포함합니다(format: yyyy-mm-dd). 제공되지 않으면 이전 미러링 이후 새 콘텐츠가 미러링됩니다.

--src-tls-verify

HTTPS가 필요하며 컨테이너 레지스트리 또는 데몬에 액세스할 때 인증서를 확인합니다.

--strict-archive

기본값은 false 입니다. 값을 설정하면 이 명령은 imageSetConfig CR(사용자 정의 리소스)에 설정된 archiveSize 보다 엄격하게 적은 아카이브를 생성합니다. 보관 중인 파일이 archiveSize (GB)를 초과하는 경우 미러링은 오류가 발생했습니다.

-v,--version

oc-mirror 플러그인 v2의 버전을 표시합니다.

--workspace

리소스 및 내부 아티팩트가 생성되는 문자열 oc-mirror 플러그인 v2 작업 영역을 결정합니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.