4.7. カスタムカタログの管理

手順

1. カタログを初期化します。

   1. 次のコマンドを実行して、カタログ用のディレクトリーを作成します。

      $ mkdir <catalog_dir>

   2. opm generate dockerfile コマンドを実行して、カタログイメージを構築できる Dockerfile を生成します。

      $ opm generate dockerfile <catalog_dir> \
          -i registry.redhat.io/openshift4/ose-operator-registry-rhel9: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

   カタログ設定ファイルへのパス。

   注記

   チャネルには、1 つ以上のバンドルが含まれる必要があります。

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>

手順

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 Blob のセットを削除します。次の例は、カタログから example-operator パッケージを削除するために削除する必要があるセットを示しています。

     例4.9 削除されたエントリーの例

     ---
     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 ファイルと同じディレクトリーに deprecations.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. Web コンソールで、Administration Cluster Settings Configuration ページで OperatorHub 設定リソースに移動します。

2. カタログソースを追加するか、既存のカタログソースを更新して、更新されたカタログイメージのプル仕様を使用します。

   詳細は、このセクションの「関連情報」にある「クラスターへのカタログソースの追加」を参照してください。

3. カタログソースが READY 状態になったら、Ecosystem Software Catalog ページに移動します。Type 見出しの下の Operator を選択し、行った変更が Operator のリストに反映されていることを確認します。

手順

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>

手順

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 など、レジストリーの namespace を指定します。

   <new_bundle_image>

   ocs-operator など、レジストリーに追加する新しいバンドルイメージを指定します。

   <digest>

   c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 などのバンドルイメージの SHA イメージ ID またはダイジェストを指定します。

   <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. Operator Lifecycle Manager (OLM) がカタログソースで参照されるインデックスイメージを一定間隔で自動的にポーリングした後に、新規パッケージが正常に追加されたことを確認します。

   $ oc get packagemanifests -n openshift-marketplace

手順

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 コマンドを実行したターミナルセッションで、Ctrl と C を押してコンテナープロセスを停止します。

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-rhel9:v4] \

   3

   
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4 

   4

   1

   プルーニングするインデックス。

   2

   保持するパッケージのコンマ区切りリスト。

   3

   IBM Power® および IBM Z® イメージにのみ必要: OpenShift Dedicated クラスターのターゲットのメジャーバージョンとマイナーバージョンに一致するタグを持つ Operator Registry ベースイメージ。

   4

   ビルドされる新規インデックスイメージのカスタムタグ。

4. 以下のコマンドを実行して、新規インデックスイメージをターゲットレジストリーにプッシュします。

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

   ここで、<namespace> はレジストリー上の既存の namespace になります。

手順

1. 次のコマンドを実行して、SQLite データベースカタログをファイルベースのカタログに移行します。

   $ opm migrate <registry_image> <fbc_directory>

2. 次のコマンドを実行して、ファイルベースのカタログ用の Dockerfile を生成します。

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

手順

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

   ヒント

   OpenShift Dedicated では、spec.grpcPodConfig.securityContextConfig フィールドはデフォルトで legacy に設定されています。OpenShift Dedicated の今後のリリースでは、デフォルト設定が restricted に変更される予定です。カタログを制限付き適用で実行できない場合は、このフィールドを手動で legacy に設定することを推奨します。

2. 次の例に示すように、<namespace>.yaml ファイルを編集して、上位の Pod Security Admission 標準をカタログソース namespace に追加します。

   <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 ラベルを namespace に追加して、Pod のセキュリティーラベルの同期をオフにします。

   2

   Pod セキュリティーアドミッションの pod-security.kubernetes.io/enforce ラベルを適用します。ラベルを baseline または privileged に設定します。namespace 内の他のワークロードが privileged プロファイルを必要としないかぎり、baseline Pod セキュリティープロファイルを使用します。