검색

4.7. 사용자 정의 카탈로그 관리

download PDF

dedicated-admin 역할 및 Operator 카탈로그 유지 관리자가 있는 관리자는 AWS의 Red Hat OpenShift Service의 OLM(Operator Lifecycle Manager)에서 번들 형식을 사용하여 패키지된 사용자 정의 카탈로그를 생성하고 관리할 수 있습니다.

중요

Kubernetes는 후속 릴리스에서 제거된 특정 API를 주기적으로 사용하지 않습니다. 결과적으로 Operator는 API를 제거한 Kubernetes 버전을 사용하는 AWS의 Red Hat OpenShift Service 버전에서 시작하여 제거된 API를 사용할 수 없습니다.

클러스터가 사용자 정의 카탈로그를 사용하는 경우 Operator 작성자가 워크로드 문제를 방지하고 호환되지 않는 업그레이드를 방지하는 방법에 대한 자세한 내용은 AWS 버전에서 Red Hat OpenShift Service와 Operator 호환성 제어를 참조하십시오.

4.7.1. 사전 요구 사항

4.7.2. 파일 기반 카탈로그

파일 기반 카탈로그는 OLM(Operator Lifecycle Manager) 카탈로그 형식의 최신 버전입니다. 일반 텍스트 기반(JSON 또는 YAML)과 이전 SQLite 데이터베이스 형식의 선언적 구성 진화이며 완전히 이전 버전과 호환됩니다.

중요

AWS 4.11의 Red Hat OpenShift Service는 파일 기반 카탈로그 형식의 기본 Red Hat 제공 Operator 카탈로그 릴리스입니다. 더 이상 사용되지 않는 SQLite 데이터베이스 형식으로 릴리스된 4.10을 통해 AWS 4.6의 Red Hat OpenShift Service에 대한 기본 Red Hat 제공 Operator 카탈로그입니다.

SQLite 데이터베이스 형식과 관련된 opm 하위 명령, 플래그 및 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 이 기능은 계속 지원되며 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 사용하는 카탈로그에 사용해야 합니다.

opm index prune 와 같은 SQLite 데이터베이스 형식을 사용하기 위한 opm 하위 명령 및 플래그는 파일 기반 카탈로그 형식에서는 작동하지 않습니다. 파일 기반 카탈로그 작업에 대한 자세한 내용은 Operator Framework 패키징 형식을 참조하십시오.

4.7.2.1. 파일 기반 카탈로그 이미지 생성

opm CLI를 사용하여 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 대체하는 일반 텍스트 파일 기반 카탈로그 형식(JSON 또는 YAML)을 사용하는 카탈로그 이미지를 생성할 수 있습니다.

사전 요구 사항

  • opm CLI를 설치했습니다.
  • podman 버전 1.9.3 이상이 있습니다.
  • 번들 이미지가 빌드되어 Docker v2-2 를 지원하는 레지스트리로 푸시됩니다.

프로세스

  1. 카탈로그를 초기화합니다.

    1. 다음 명령을 실행하여 카탈로그의 디렉터리를 생성합니다.

      $ mkdir <catalog_dir>
    2. opm generate dockerfile 명령을 실행하여 카탈로그 이미지를 빌드할 수 있는 Dockerfile을 생성합니다.

      $ opm generate dockerfile <catalog_dir> \
          -i registry.redhat.io/openshift4/ose-operator-registry:v4 1
      1
      -i 플래그를 사용하여 공식 Red Hat 기본 이미지를 지정합니다. 그러지 않으면 Dockerfile에서 기본 업스트림 이미지를 사용합니다.

      Dockerfile은 이전 단계에서 생성한 카탈로그 디렉터리와 동일한 상위 디렉터리에 있어야 합니다.

      디렉터리 구조의 예

      . 1
      ├── <catalog_dir> 2
      └── <catalog_dir>.Dockerfile 3

      1
      상위 디렉터리
      2
      카탈로그 디렉터리
      3
      opm generate dockerfile 명령으로 생성된 Dockerfile
    3. opm init 명령을 실행하여 카탈로그를 Operator의 패키지 정의로 채웁니다.

      $ opm init <operator_name> \ 1
          --default-channel=preview \ 2
          --description=./README.md \ 3
          --icon=./operator-icon.svg \ 4
          --output yaml \ 5
          > <catalog_dir>/index.yaml 6
      1
      Operator 또는 패키지, 이름
      2
      서브스크립션이 지정되지 않은 경우 기본값으로 설정된 채널
      3
      Operator의 README.md 또는 기타 문서 경로
      4
      Operator 아이콘 경로
      5
      출력 형식: JSON 또는 YAML
      6
      카탈로그 구성 파일을 생성하는 경로

      이 명령은 지정된 카탈로그 구성 파일에 olm.package 선언적 구성 blob을 생성합니다.

  2. opm render 명령을 실행하여 카탈로그에 번들을 추가합니다.

    $ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \ 1
        --output=yaml \
        >> <catalog_dir>/index.yaml 2
    1
    번들 이미지의 가져오기 사양
    2
    카탈로그 구성 파일의 경로
    참고

    채널에는 하나 이상의 번들이 포함되어야 합니다.

  3. 번들에 채널 항목을 추가합니다. 예를 들어 다음 예제를 사양에 맞게 수정하고 < catalog_dir>/index.yaml 파일에 추가합니다.

    채널 항목 예

    ---
    schema: olm.channel
    package: <operator_name>
    name: preview
    entries:
      - name: <operator_name>.v0.1.0 1

    1
    <operator_name> 뒤의 마침표(.)를 버전 v 앞에 포함해야 합니다. 그렇지 않으면 항목이 opm validate 명령을 전달하지 못합니다.
  4. 파일 기반 카탈로그를 확인합니다.

    1. 카탈로그 디렉터리에 대해 opm validate 명령을 실행합니다.

      $ opm validate <catalog_dir>
    2. 오류 코드가 0인지 확인합니다.

      $ echo $?

      출력 예

      0

  5. podman build 명령을 실행하여 카탈로그 이미지를 빌드합니다.

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
  6. 카탈로그 이미지를 레지스트리로 푸시합니다.

    1. 필요한 경우 podman login 명령을 실행하여 대상 레지스트리로 인증합니다.

      $ podman login <registry>
    2. podman push 명령을 실행하여 카탈로그 이미지를 푸시합니다.

      $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>

추가 리소스

4.7.2.2. 파일 기반 카탈로그 이미지 업데이트 또는 필터링

opm CLI를 사용하여 파일 기반 카탈로그 형식을 사용하는 카탈로그 이미지를 업데이트하거나 필터링할 수 있습니다. 기존 카탈로그 이미지의 콘텐츠를 추출하면 필요에 따라 카탈로그를 수정할 수 있습니다. 예를 들면 다음과 같습니다.

  • 패키지 추가
  • 패키지 제거
  • 기존 패키지 항목 업데이트
  • 패키지, 채널 및 번들당 사용 중단 메시지 세부 정보

그런 다음 업데이트된 카탈로그 버전으로 이미지를 다시 빌드할 수 있습니다.

사전 요구 사항

  • 워크스테이션에 다음이 있습니다.

    • opm CLI입니다.
    • podman 버전 1.9.3 이상.
    • 파일 기반 카탈로그 이미지입니다.
    • 이 카탈로그와 관련된 워크스테이션에서 최근에 초기화된 카탈로그 디렉터리 구조입니다.

      초기화된 카탈로그 디렉터리가 없는 경우 디렉터리를 생성하고 Dockerfile을 생성합니다. 자세한 내용은 "파일 기반 카탈로그 이미지 생성" 절차의 " catalog" 단계를 참조하십시오.

프로세스

  1. YAML 형식의 카탈로그 이미지의 콘텐츠를 카탈로그 디렉터리의 index.yaml 파일에 추출합니다.

    $ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \
        -o yaml > <catalog_dir>/index.yaml
    참고

    또는 -o json 플래그를 사용하여 JSON 형식으로 출력할 수 있습니다.

  2. 결과 index.yaml 파일의 내용을 사양으로 수정합니다.

    중요

    번들이 카탈로그에 게시되면 사용자 중 하나가 설치되었다고 가정합니다. 해당 버전이 설치된 사용자를 방지하려면 카탈로그의 이전에 게시된 모든 번들에 현재 또는 최신 채널 헤드에 대한 업데이트 경로가 있는지 확인합니다.

    • Operator를 추가하려면 "파일 기반 카탈로그 이미지 생성" 프로세스에서 패키지, 번들 및 채널 항목을 생성하는 단계를 수행합니다.
    • Operator를 제거하려면 패키지와 관련된 olm.package,olm.channel, olm.bundle blobs 세트를 삭제합니다. 다음 예제에서는 카탈로그에서 example-operator 패키지를 제거하려면 삭제해야 하는 세트를 보여줍니다.

      예 4.2. 삭제된 항목의 예

      ---
      defaultChannel: release-2.7
      icon:
        base64data: <base64_string>
        mediatype: image/svg+xml
      name: example-operator
      schema: olm.package
      ---
      entries:
      - name: example-operator.v2.7.0
        skipRange: '>=2.6.0 <2.7.0'
      - name: example-operator.v2.7.1
        replaces: example-operator.v2.7.0
        skipRange: '>=2.6.0 <2.7.1'
      - name: example-operator.v2.7.2
        replaces: example-operator.v2.7.1
        skipRange: '>=2.6.0 <2.7.2'
      - name: example-operator.v2.7.3
        replaces: example-operator.v2.7.2
        skipRange: '>=2.6.0 <2.7.3'
      - name: example-operator.v2.7.4
        replaces: example-operator.v2.7.3
        skipRange: '>=2.6.0 <2.7.4'
      name: release-2.7
      package: example-operator
      schema: olm.channel
      ---
      image: example.com/example-inc/example-operator-bundle@sha256:<digest>
      name: example-operator.v2.7.0
      package: example-operator
      properties:
      - type: olm.gvk
        value:
          group: example-group.example.io
          kind: MyObject
          version: v1alpha1
      - type: olm.gvk
        value:
          group: example-group.example.io
          kind: MyOtherObject
          version: v1beta1
      - type: olm.package
        value:
          packageName: example-operator
          version: 2.7.0
      - type: olm.bundle.object
        value:
          data: <base64_string>
      - type: olm.bundle.object
        value:
          data: <base64_string>
      relatedImages:
      - image: example.com/example-inc/example-related-image@sha256:<digest>
        name: example-related-image
      schema: olm.bundle
      ---
    • Operator에 대한 사용 중단 메시지를 추가하거나 업데이트하려면 패키지의 index .yaml 파일과 동일한 디렉터리에precations.yaml 파일이 있는지 확인합니다. deprecations.yaml 파일 형식에 대한 자세한 내용은 "olm.deprecations 스키마"를 참조하십시오.
  3. 변경 사항을 저장하십시오.
  4. 카탈로그를 확인합니다.

    $ opm validate <catalog_dir>
  5. 카탈로그를 다시 빌드합니다.

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
  6. 업데이트된 카탈로그 이미지를 레지스트리로 푸시합니다.

    $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>

검증

  1. 웹 콘솔에서 관리 클러스터 설정 구성 페이지의 OperatorHub 구성 리소스로 이동합니다.
  2. 업데이트된 카탈로그 이미지의 pull 사양을 사용하도록 카탈로그 소스를 추가하거나 기존 카탈로그 소스를 업데이트합니다.

    자세한 내용은 이 섹션의 "추가 리소스"의 "클러스터에 카탈로그 소스 추가"를 참조하십시오.

  3. 카탈로그 소스가 READY 상태인 후 Operator OperatorHub 페이지로 이동하여 수행된 변경 사항이 Operator 목록에 반영되었는지 확인합니다.

4.7.3. SQLite 기반 카탈로그

중요

Operator 카탈로그의 SQLite 데이터베이스 형식은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 AWS의 Red Hat OpenShift Service에 계속 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새 배포에는 사용하지 않는 것이 좋습니다.

AWS의 Red Hat OpenShift Service에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 Red Hat OpenShift Service on AWS 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

4.7.3.1. SQLite 기반 인덱스 이미지 생성

opm CLI를 사용하여 SQLite 데이터베이스 형식을 기반으로 인덱스 이미지를 생성할 수 있습니다.

사전 요구 사항

  • opm CLI를 설치했습니다.
  • podman 버전 1.9.3 이상이 있습니다.
  • 번들 이미지가 빌드되어 Docker v2-2 를 지원하는 레지스트리로 푸시됩니다.

프로세스

  1. 새 인덱스를 시작합니다.

    $ opm index add \
        --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \1
        --tag <registry>/<namespace>/<index_image_name>:<tag> \2
        [--binary-image <registry_base_image>] 3
    1
    인덱스에 추가할 번들 이미지를 쉼표로 구분한 목록입니다.
    2
    인덱스 이미지에 포함할 이미지 태그입니다.
    3
    선택 사항: 카탈로그 제공에 사용할 대체 레지스트리 기본 이미지입니다.
  2. 인덱스 이미지를 레지스트리로 내보냅니다.

    1. 필요한 경우 대상 레지스트리로 인증합니다.

      $ podman login <registry>
    2. 인덱스 이미지를 내보냅니다.

      $ podman push <registry>/<namespace>/<index_image_name>:<tag>

4.7.3.2. SQLite 기반 인덱스 이미지 업데이트

사용자 정의 인덱스 이미지를 참조하는 카탈로그 소스를 사용하도록 OperatorHub를 구성한 후 dedicated-admin 역할의 관리자는 번들 이미지를 인덱스 이미지에 추가하여 클러스터에서 사용 가능한 Operator를 최신 상태로 유지할 수 있습니다.

opm index add 명령을 사용하여 기존 인덱스 이미지를 업데이트할 수 있습니다.

사전 요구 사항

  • opm CLI를 설치했습니다.
  • podman 버전 1.9.3 이상이 있습니다.
  • 인덱스 이미지가 빌드되어 레지스트리로 푸시됩니다.
  • 인덱스 이미지를 참조하는 기존 카탈로그 소스가 있습니다.

프로세스

  1. 번들 이미지를 추가하여 기존 인덱스를 업데이트합니다.

    $ opm index add \
        --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1
        --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2
        --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3
        --pull-tool podman 4
    1
    --bundles 플래그는 인덱스에 추가할 쉼표로 구분된 추가 번들 이미지 목록을 지정합니다.
    2
    --from-index 플래그는 이전에 내보낸 인덱스를 지정합니다.
    3
    --tag 플래그는 업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다.
    4
    --pull-tool 플래그는 컨테이너 이미지를 가져오는 데 사용되는 툴을 지정합니다.

    다음과 같습니다.

    <registry>
    quay.io 또는 mirror.example.com 과 같은 레지스트리의 호스트 이름을 지정합니다.
    <namespace>
    ocs-dev 또는 abc 와 같은 레지스트리의 네임스페이스를 지정합니다.
    <new_bundle_image>
    ocs-operator 와 같이 레지스트리에 추가할 새 번들 이미지를 지정합니다.
    <digest>
    번들 이미지의 SHA 이미지 ID 또는 다이제스트(예: c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 )를 지정합니다.
    <existing_index_image>
    이전에 내보낸 이미지(예: abc-redhat-operator-index )를 지정합니다.
    <existing_tag>
    이전에 푸시한 이미지 태그(예: 4)를 지정합니다.
    <updated_tag>
    4.1 과 같이 업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다.

    명령 예

    $ opm index add \
        --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
        --from-index mirror.example.com/abc/abc-redhat-operator-index:4 \
        --tag mirror.example.com/abc/abc-redhat-operator-index:4.1 \
        --pull-tool podman

  2. 업데이트된 인덱스 이미지를 내보냅니다.

    $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
  3. OLM(Operator Lifecycle Manager)이 정기적으로 카탈로그 소스에서 참조하는 인덱스 이미지를 자동으로 폴링하면 새 패키지가 성공적으로 추가되었는지 확인합니다.

    $ oc get packagemanifests -n openshift-marketplace

4.7.3.3. SQLite 기반 인덱스 이미지 필터링

Operator 번들 포맷을 기반으로 하는 인덱스 이미지는 Operator 카탈로그의 컨테이너화된 스냅샷입니다. 지정된 패키지 목록을 제외한 모든 인덱스를 필터링하거나 정리할 수 있습니다. 이 목록은 원하는 Operator만 포함하는 소스 인덱스 복사본을 생성합니다.

사전 요구 사항

  • podman 버전 1.9.3 이상이 있습니다.
  • grpcurl (타사 명령줄 툴)이 있습니다.
  • opm CLI를 설치했습니다.
  • Docker v2-2 를 지원하는 레지스트리에 액세스할 수 있습니다.

프로세스

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

    $ podman login <target_registry>
  2. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

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

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

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4...
      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 명령을 실행한 터미널 세션에서 CtrlC를 눌러 컨테이너 프로세스를 중지합니다.
  3. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

    $ opm index prune \
        -f registry.redhat.io/redhat/redhat-operator-index:v4 \1
        -p advanced-cluster-management,jaeger-product,quay-operator \2
        [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \3
        -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4 4
    1
    정리할 인덱스입니다.
    2
    쉼표로 구분된 보관할 패키지 목록입니다.
    3
    IBM Power® 및 IBM Z® 이미지에만 필요합니다. AWS 클러스터 메이저 및 마이너 버전의 대상 Red Hat OpenShift Service와 일치하는 태그가 있는 Operator 레지스트리 기본 이미지입니다.
    4
    빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.
  4. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

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

    <namespace>는 레지스트리의 기존 네임스페이스입니다.

4.7.4. 카탈로그 소스 및 Pod 보안 승인

Pod 보안 표준을 보장하기 위해 Pod 보안 승인이 AWS 4.11의 Red Hat OpenShift Service에 도입되었습니다. SQLite 기반 카탈로그 형식 및 AWS 4.11에서 Red Hat OpenShift Service on AWS 4.11 전에 릴리스된 opm CLI 툴 버전을 사용하여 빌드된 카탈로그 소스는 제한된 Pod 보안 적용에서 실행할 수 없습니다.

AWS 4의 Red Hat OpenShift Service에서 네임스페이스에는 기본적으로 제한된 Pod 보안 적용 기능이 없으며 기본 카탈로그 소스 보안 모드는 legacy 로 설정됩니다.

모든 네임스페이스에 대한 기본 제한된 적용은 향후 AWS 릴리스에서 Red Hat OpenShift Service에 포함될 예정입니다. 제한된 적용이 발생하면 카탈로그 소스 Pod에 대한 Pod 사양의 보안 컨텍스트가 제한된 Pod 보안 표준과 일치해야 합니다. 카탈로그 소스 이미지에 다른 Pod 보안 표준이 필요한 경우 네임스페이스의 Pod 보안 승인 레이블을 명시적으로 설정해야 합니다.

참고

restricted로 SQLite 기반 카탈로그 소스 Pod를 실행하지 않으려면 AWS 4의 Red Hat OpenShift Service에서 카탈로그 소스를 업데이트할 필요가 없습니다.

그러나 제한된 Pod 보안 적용에서 카탈로그 소스를 실행하려면 지금 작업을 수행하는 것이 좋습니다. 카탈로그 소스가 제한된 Pod 보안 적용에서 실행되도록 하지 않으면 카탈로그 소스가 향후 AWS 릴리스의 Red Hat OpenShift Service에서 실행되지 않을 수 있습니다.

카탈로그 작성자는 다음 작업 중 하나를 완료하여 제한된 Pod 보안 적용과 호환성을 활성화할 수 있습니다.

  • 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션합니다.
  • AWS 4.11 이상에서 Red Hat OpenShift Service와 함께 릴리스된 opm CLI 툴 버전으로 카탈로그 이미지를 업데이트합니다.
참고

SQLite 데이터베이스 카탈로그 형식은 더 이상 사용되지 않지만 Red Hat에서 계속 지원합니다. 향후 릴리스에서는 SQLite 데이터베이스 형식이 지원되지 않으며 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션해야 합니다. AWS 4.11의 Red Hat OpenShift Service에서 기본 Red Hat 제공 Operator 카탈로그는 파일 기반 카탈로그 형식으로 릴리스됩니다. 파일 기반 카탈로그는 제한된 Pod 보안 적용과 호환됩니다.

SQLite 데이터베이스 카탈로그 이미지를 업데이트하거나 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션하지 않으려면 승격된 권한으로 실행되도록 카탈로그를 구성할 수 있습니다.

4.7.4.1. SQLite 데이터베이스 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션

더 이상 사용되지 않는 SQLite 데이터베이스 형식 카탈로그를 파일 기반 카탈로그 형식으로 업데이트할 수 있습니다.

사전 요구 사항

  • SQLite 데이터베이스 카탈로그 소스가 있습니다.
  • dedicated-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 워크스테이션의 AWS 4에서 Red Hat OpenShift Service와 함께 릴리스된 opm CLI 툴의 최신 버전이 있습니다.

프로세스

  1. 다음 명령을 실행하여 SQLite 데이터베이스 카탈로그를 파일 기반 카탈로그로 마이그레이션합니다.

    $ opm migrate <registry_image> <fbc_directory>
  2. 다음 명령을 실행하여 파일 기반 카탈로그에 대한 Dockerfile을 생성합니다.

    $ opm generate dockerfile <fbc_directory> \
      --binary-image \
      registry.redhat.io/openshift4/ose-operator-registry:v4

다음 단계

  • 생성된 Dockerfile을 빌드, 태그를 지정하고 레지스트리로 내보낼 수 있습니다.

4.7.4.2. SQLite 데이터베이스 카탈로그 이미지 다시 빌드

AWS에서 Red Hat OpenShift Service 버전으로 릴리스된 opm CLI 툴의 최신 버전으로 SQLite 데이터베이스 카탈로그 이미지를 다시 빌드할 수 있습니다.

사전 요구 사항

  • SQLite 데이터베이스 카탈로그 소스가 있습니다.
  • dedicated-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 워크스테이션의 AWS 4에서 Red Hat OpenShift Service와 함께 릴리스된 opm CLI 툴의 최신 버전이 있습니다.

프로세스

  • 다음 명령을 실행하여 최신 버전의 opm CLI 툴로 카탈로그를 다시 빌드합니다.

    $ opm index add --binary-image \
      registry.redhat.io/openshift4/ose-operator-registry:v4 \
      --from-index <your_registry_image> \
      --bundles "" -t \<your_registry_image>

4.7.4.3. 승격된 권한으로 실행되도록 카탈로그 구성

SQLite 데이터베이스 카탈로그 이미지를 업데이트하거나 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션하지 않으려면 다음 작업을 수행하여 기본 Pod 보안 적용이 restricted로 변경될 때 카탈로그 소스가 실행되도록 할 수 있습니다.

  • 카탈로그 소스 정의에서 카탈로그 보안 모드를 legacy로 수동으로 설정합니다. 이 작업을 수행하면 기본 카탈로그 보안 모드가 restricted로 변경되는 경우에도 기존 권한으로 카탈로그가 실행됩니다.
  • 기준 또는 권한 있는 Pod 보안 시행을 위해 카탈로그 소스 네임스페이스에 레이블을 지정합니다.
참고

SQLite 데이터베이스 카탈로그 형식은 더 이상 사용되지 않지만 Red Hat에서 계속 지원합니다. 향후 릴리스에서는 SQLite 데이터베이스 형식이 지원되지 않으며 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션해야 합니다. 파일 기반 카탈로그는 제한된 Pod 보안 적용과 호환됩니다.

사전 요구 사항

  • SQLite 데이터베이스 카탈로그 소스가 있습니다.
  • dedicated-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.
  • 기준선 또는 권한 있는 Pod 보안 승인 표준으로 Pod 실행을 지원하는 대상 네임스페이스가 있습니다.

프로세스

  1. 다음 예와 같이 spec.grpcPodConfig.securityContextConfig 레이블을 legacy 로 설정하여 CatalogSource 정의를 편집합니다.

    CatalogSource 정의의 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: my-catsrc
      namespace: my-ns
    spec:
      sourceType: grpc
      grpcPodConfig:
        securityContextConfig: legacy
      image: my-image:latest

    작은 정보

    AWS 4의 Red Hat OpenShift Service에서 spec.grpcPodConfig.securityContextConfig 필드는 기본적으로 legacy 로 설정됩니다. 향후 AWS에서 Red Hat OpenShift Service의 릴리스에서는 기본 설정이 restricted 로 변경될 예정입니다. 제한된 적용으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.

  2. 다음 예와 같이 <namespace>.yaml 파일을 편집하여 카탈로그 소스 네임스페이스에 승격된 Pod 보안 승인 표준을 추가합니다.

    &lt ;namespace>.yaml 파일 예

    apiVersion: v1
    kind: Namespace
    metadata:
    ...
      labels:
        security.openshift.io/scc.podSecurityLabelSync: "false" 1
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: baseline 2
      name: "<namespace_name>"

    1
    네임스페이스에 security.openshift.io/scc.podSecurityLabelSync=false 라벨을 추가하여 Pod 보안 레이블 동기화를 끕니다.
    2
    Pod 보안 승인 pod-security.kubernetes.io/enforce 레이블을 적용합니다. 레이블을 baseline 또는 privileged 로 설정합니다. 네임스페이스의 다른 워크로드에 권한 있는 프로필이 필요하지 않는 한 기준 Pod 보안 프로필을 사용합니다.

4.7.5. 클러스터에 카탈로그 소스 추가

AWS 클러스터의 Red Hat OpenShift Service에 카탈로그 소스를 추가하면 사용자를 위한 Operator를 검색하고 설치할 수 있습니다. dedicated-admin 역할의 관리자는 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성할 수 있습니다. OperatorHub는 카탈로그 소스를 사용하여 사용자 인터페이스를 채웁니다.

작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 검색 페이지에서 프로젝트를 선택하고 리소스 드롭다운을 클릭하고 CatalogSource 를 검색합니다. 개별 소스를 생성, 업데이트, 삭제, 비활성화 및 활성화할 수 있습니다.

사전 요구 사항

  • 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.
  • dedicated-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

프로세스

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

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace 1
        annotations:
          olm.catalogImageTemplate: 2
            "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
      spec:
        sourceType: grpc
        grpcPodConfig:
          securityContextConfig: <security_mode> 3
        image: <registry>/<namespace>/<index_image_name>:<tag> 4
        displayName: My Operator Catalog
        publisher: <publisher_name> 5
        updateStrategy:
          registryPoll: 6
            interval: 30m
      1
      카탈로그 소스를 모든 네임스페이스의 사용자가 전역적으로 사용할 수 있도록 하려면 openshift-marketplace 네임스페이스를 지정합니다. 그러지 않으면 카탈로그의 범위가 지정되고 해당 네임스페이스에 대해서만 사용할 수 있도록 다른 네임스페이스를 지정할 수 있습니다.
      2
      선택 사항: olm.catalogImageTemplate 주석을 인덱스 이미지 이름으로 설정하고 이미지 태그의 템플릿을 구성할 때 표시된 대로 하나 이상의 Kubernetes 클러스터 버전 변수를 사용합니다.
      3
      legacy 또는 restricted 를 지정합니다. 필드가 설정되지 않은 경우 기본값은 legacy 입니다. 향후 AWS 릴리스에서 Red Hat OpenShift Service는 기본값이 제한 될 예정입니다. 제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.
      4
      인덱스 이미지를 지정합니다. 이미지 이름 다음에 태그를 지정하는 경우(예: :v4 ) 카탈로그 소스 Pod는 Always 의 이미지 가져오기 정책을 사용합니다. 즉, Pod는 컨테이너를 시작하기 전에 항상 이미지를 가져옵니다. 다이제스트를 지정하는 경우(예: @sha256:<id >) 이미지 가져오기 정책은 IfNotPresent 입니다. 즉 Pod는 노드에 없는 경우에만 이미지를 가져옵니다.
      5
      카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다.
      6
      카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.
    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

이제 AWS 웹 콘솔의 Red Hat OpenShift Service의 OperatorHub 페이지에서 Operator를 설치할 수 있습니다.

4.7.6. 사용자 정의 카탈로그 제거

dedicated-admin 역할의 관리자는 관련 카탈로그 소스를 삭제하여 이전에 클러스터에 추가된 사용자 정의 Operator 카탈로그를 제거할 수 있습니다.

사전 요구 사항

  • dedicated-admin 역할의 사용자로 클러스터에 액세스할 수 있습니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 검색으로 이동합니다.
  2. Project: 목록에서 프로젝트를 선택합니다.
  3. 리소스 목록에서 CatalogSource 를 선택합니다.
  4. 제거할 카탈로그의 옵션 메뉴 kebab 를 선택한 다음 카탈로그 소스 삭제를 클릭합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.