サポートコンソール開発者トライアルの開始お問い合わせ

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

以下では、OpenShift Container Platform で Operator Lifecycle Manager (OLM) の Bundle Format を使用してパッケージ化された Operator のカスタムパッケージを使用する方法について説明します。

注記

レガシー形式をしようしたカスタムのカタログなど、Operator のレガシー パッケージマニフェスト形式 のサポートは、OpenShift Container Platform 4.8 以降で削除されます。

重要

Kubernetes は、今後のリリースで削除される特定の API を定期的に非推奨にします。その結果、Operator は API を削除した Kubernetes バージョンを使用する OpenShift Container Platform のバージョン以降、削除された API を使用できなくなります。

クラスターがカスタムカタログを使用している場合に、Operator の作成者がプロジェクトを更新してワークロードの問題や、互換性のないアップグレードを回避できるようにする方法については Operator の互換性の OpenShift Container Platform バージョンへの制御 を参照してください。

関連情報

4.8.1. 前提条件

  • opm CLI をインストールします。

4.8.2. インデックスイメージの作成

opm CLI を使用してインデックスイメージを作成できます。

前提条件

  • opm version 1.12.3+
  • podman version 1.9.3+

  • Docker v2-2 をサポートするレジストリーにビルドされ、プッシュされるバンドルイメージ。

    重要

    OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

手順

  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.8.3. インデックスイメージからのカタログの作成

インデックスイメージから Operator カタログを作成し、これを Operator Lifecycle Manager (OLM) で使用するために OpenShift Container Platform クラスターに適用できます。

前提条件

  • レジストリーにビルドされ、プッシュされるインデックスイメージ。

手順

  1. インデックスイメージを参照する CatalogSource オブジェクトを作成します。

    1. 仕様を以下のように変更し、これを catalogSource.yaml ファイルとして保存します。 

      apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace 1
spec:
  sourceType: grpc
  image: <registry>:<port>/<namespace>/redhat-operator-index:v4.8 2
  displayName: My Operator Catalog
  publisher: <publisher_name> 3
  updateStrategy:
    registryPoll: 4
      interval: 30m
      1
      カタログソースを全 namespace のユーザーがグローバルに利用できるようにする場合は、openshift-marketplace namespace を指定します。それ以外の場合は、そのカタログの別の namespace を対象とし、その namespace のみが利用できるように指定できます。
      2
      インデックスイメージを指定します。
      3
      カタログを公開する名前または組織名を指定します。
      4
      カタログソースは新規バージョンの有無を自動的にチェックし、最新の状態を維持します。

    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

OpenShift Container Platform Web コンソールで、OperatorHub ページから Operator をインストールできるようになりました。

関連情報

4.8.4. インデックスイメージの更新

カスタムインデックスイメージを参照するカタログソースを使用するように OperatorHub を設定した後に、クラスター管理者はバンドルイメージをインデックスイメージに追加して、クラスターで利用可能な Operator を最新の状態に維持することができます。

opm index add コマンドを使用して既存インデックスイメージを更新できます。

前提条件

  • opm version 1.12.3+
  • podman version 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など、レジストリーの namespace を指定します。
    <new_bundle_image>
    ocs-operatorなど、レジストリーに追加する新しいバンドルイメージを指定します。
    <digest>
    c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41などのバンドルイメージの SHA イメージ ID またはダイジェストを指定します。
    <existing_index_image>
    abc-redhat-operator-indexなど、以前にプッシュされたイメージを指定します。
    <existing_tag>
    4.8 など、以前にプッシュされたイメージタグを指定します。
    <updated_tag>
    4.8.1 など、更新されたインデックスイメージに適用するイメージタグを指定します。

    コマンドの例

    $ opm index add \
    --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
    --from-index mirror.example.com/abc/abc-redhat-operator-index:4.8 \
    --tag mirror.example.com/abc/abc-redhat-operator-index:4.8.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

4.8.5. インデックスイメージのプルーニング

Operator Bundle Format に基づくインデックスイメージは、Operator カタログのコンテナー化されたスナップショットです。パッケージの指定された一覧以外のすべてのインデックスをプルーニングできます。これにより、必要な Operator のみが含まれるソースインデックスのコピーを作成できます。

前提条件

  • podman version 1.9.3+
  • grpcurl(サードパーティーのコマンドラインツール)
  • opm バージョン 1.18.0+

  • Docker v2-2 をサポートするレジストリーへのアクセス

    重要

    OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

手順

  1. ターゲットレジストリーで認証します。 

    $ podman login <target_registry>

  2. プルーニングされたインデックスに追加するパッケージの一覧を判別します。

    1. コンテナーでプルーニングするソースインデックスイメージを実行します。以下に例を示します。 

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

      出力例

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.8...
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.8 \1
    -p advanced-cluster-management,jaeger-product,quay-operator \2
    [-i registry.redhat.io/openshift4/ose-operator-registry:v4.8] \3
    -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.8 4
    1
    プルーニングするインデックス。
    2
    保持するパッケージのコンマ区切りリスト。
    3
    IBM Power Systems および IBM Z イメージのみに必要です: ターゲット OpenShift Container Platform クラスターのメジャーバージョンおよびマイナーバージョンに一致するタグを使用する Operator レジストリーのベースイメージです。
    4
    ビルドされる新規インデックスイメージのカスタムタグ。

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

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

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

4.8.6. プライベートレジストリーからの Operator のイメージへのアクセス

Operator Lifecycle Manager (OLM) によって管理される Operator に関連する特定のイメージが、認証コンテナーイメージレジストリー (別名プライベートレジストリー) でホストされる場合、OLM および OperatorHub はデフォルトではイメージをプルできません。アクセスを有効にするために、レジストリーの認証情報が含まれるプルシークレットを作成できます。カタログソースの 1 つ以上のプルシークレットを参照することで、OLM はシークレットの配置を Operator およびカタログ namespace で処理し、インストールを可能にします。

Operator またはそのオペランドで必要な他のイメージでも、プライベートレジストリーへのアクセスが必要になる場合があります。OLM は、このシナリオのターゲットテナント namespace ではシークレットの配置を処理しませんが、認証情報をグローバルクラスタープルシークレットまたは個別の namespace サービスアカウントに追加して、必要なアクセスを有効にできます。

OLM によって管理される Operator に適切なプルアクセスがあるかどうかを判別する際に、以下のタイプのイメージを考慮する必要があります。

インデックスイメージ
CatalogSource オブジェクトは、インデックスイメージを参照できます。このイメージは、Operator のバンドル形式を使用し、イメージレジストリーでホストされるコンテナーイメージとしてパッケージ化されるカタログソースです。インデックスイメージがプライベートレジストリーでホストされる場合、シークレットを使用してプルアクセスを有効にすることができます。
バンドルイメージ
Operator バンドルイメージは、Operator の一意のバージョンを表すコンテナーイメージとしてパッケージ化されるメタデータおよびマニフェストです。カタログソースで参照されるバンドルイメージが 1 つ以上のプライベートレジストリーでホストされる場合、シークレットを使用してプルアクセスを有効にすることができます。
Operator イメージおよびオペランドイメージ

カタログソースからインストールされた Operator が、(Operator イメージ自体に、または監視するオペランドイメージの 1 つに) プライベートイメージを使用する場合、デプロイメントは必要なレジストリー認証にアクセスできないため、Operator はインストールに失敗します。カタログソースのシークレットを参照することで、OLM はオペランドがインストールされているターゲットテナント namespace にシークレットを配置することはできません。

代わりに、認証情報を openshift-config namespace のグローバルクラスタープルシークレットに追加できます。これにより、クラスターのすべての namespace へのアクセスが提供されます。または、クラスター全体へのアクセスの提供が許容されない場合、プルシークレットをターゲットテナント namespace の default のサービスアカウントに追加できます。

前提条件

  • プライベートレジストリーで、以下のうち少なくとも 1 つがホストされます。

    • インデックスイメージまたはカタログイメージ。
    • Operator のバンドルイメージ
    • Operator またはオペランドのイメージ。

手順

  1. 必要な各プライベートレジストリーのシークレットを作成します。

    1. プライベートレジストリーにログインして、レジストリー認証情報ファイルを作成または更新します。 

      $ podman login <registry>:<port>
      注記

      レジストリー認証情報のファイルパスは、レジストリーへのログインに使用されるコンテナーツールによって異なります。podman CLI の場合、デフォルトの場所は ${XDG_RUNTIME_DIR}/containers/auth.json です。docker CLI の場合、デフォルトの場所は /root/.docker/config.json です。

    2. シークレットごとに 1 つのレジストリーに対してのみ認証情報を追加し、別のシークレットで複数のレジストリーの認証情報を管理することが推奨されます。これ以降の手順で、複数のシークレットを CatalogSource オブジェクトに含めることができ、OpenShift Container Platform はイメージのプル時に使用する単一の仮想認証情報ファイルにシークレットをマージします。

      レジストリー認証情報ファイルは、デフォルトで複数のレジストリーの詳細を保存することができます。ファイルの現在の内容を確認します。以下に例を示します。

      2 つのレジストリーの認証情報を保存するファイル

      {
        "auths": {
                "registry.redhat.io": {
                        "auth": "FrNHNydQXdzclNqdg=="
                },
                "quay.io": {
                        "auth": "Xd2lhdsbnRib21iMQ=="
                }
        }
}

      これ以降の手順で、シークレットの作成にこのファイルが使用されるため、保存できる詳細は 1 つのファイルにつき 1 つのレジストリーのみであることを確認してください。これには、以下の方法の 1 つを使用します。

      • podman logout <registry> コマンドを使用して、必要な 1 つのレジストリーのみになるまで、追加のレジストリーの認証情報を削除します。

      • レジストリー認証情報ファイルを編集し、レジストリーの詳細を分離して、複数のファイルに保存します。以下に例を示します。

        1 つのレジストリーの認証情報を保存するファイル

        {
        "auths": {
                "registry.redhat.io": {
                        "auth": "FrNHNydQXdzclNqdg=="
                }
        }
}

        別のレジストリーの認証情報を保存するファイル

        {
        "auths": {
                "quay.io": {
                        "auth": "Xd2lhdsbnRib21iMQ=="
                }
        }
}

    3. プライベートレジストリーの認証情報が含まれるシークレットを openshift-marketplace namespace に作成します。 

      $ oc create secret generic <secret_name> \
    -n openshift-marketplace \
    --from-file=.dockerconfigjson=<path/to/registry/credentials> \
    --type=kubernetes.io/dockerconfigjson

      この手順を繰り返して、他の必要なプライベートレジストリーの追加シークレットを作成し、--from-file フラグを更新して別のレジストリー認証情報ファイルのパスを指定します。

  2. 1 つ以上のシークレットを参照するように既存の CatalogSource オブジェクトを作成または更新します。 

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: my-operator-catalog
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  secrets: 1
  - "<secret_name_1>"
  - "<secret_name_2>"
  image: <registry>:<port>/<namespace>/<image>:<tag>
  displayName: My Operator Catalog
  publisher: <publisher_name>
  updateStrategy:
    registryPoll:
      interval: 30m
    1
    spec.secrets セクションを追加し、必要なシークレットを指定します。

  3. サブスクライブされた Operator によって参照される Operator イメージまたはオペランドイメージにプライベートレジストリーへのアクセスが必要な場合は、クラスター内のすべての namespace または個々のターゲットテナント namespace のいずれかにアクセスを提供できます。

    • クラスター内のすべての namespace へアクセスを提供するには、認証情報を openshift-config namespace のグローバルクラスタープルシークレットに追加します。

      警告

      クラスターリソースは新規のグローバルプルシークレットに合わせて調整する必要がありますが、これにより、クラスターのユーザービリティーが一時的に制限される可能性があります。

      1. グローバルプルシークレットから .dockerconfigjson ファイルを展開します。 

        $ oc extract secret/pull-secret -n openshift-config --confirm

      2. .dockerconfigjson ファイルを、必要なプライベートレジストリーまたはレジストリーの認証情報で更新し、これを新規ファイルとして保存します。 

        $ cat .dockerconfigjson | \
    jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1
    > new_dockerconfigjson
        1
        <registry>:<port>/<namespace> をプライベートレジストリーの詳細に置き換え、<token> を認証情報に置き換えます。

      3. 新規ファイルでグローバルプルシークレットを更新します。 

        $ oc set data secret/pull-secret -n openshift-config \
    --from-file=.dockerconfigjson=new_dockerconfigjson

    • 個別の namespace を更新するには、ターゲットテナント namespace でアクセスが必要な Operator のサービスアカウントにプルシークレットを追加します。

      1. テナント namespace で openshift-marketplace 用に作成したシークレットを再作成します。 

        $ oc create secret generic <secret_name> \
    -n <tenant_namespace> \
    --from-file=.dockerconfigjson=<path/to/registry/credentials> \
    --type=kubernetes.io/dockerconfigjson

      2. テナント namespace を検索して、Operator のサービスアカウントの名前を確認します。 

        $ oc get sa -n <tenant_namespace> 1
        1
        Operator が個別の namespace にインストールされていた場合、その namespace を検索します。Operator がすべての namespace にインストールされていた場合、openshift-operators namespace を検索します。

        出力例

        NAME            SECRETS   AGE
builder         2         6m1s
default         2         6m1s
deployer        2         6m1s
etcd-operator   2         5m18s 1

        1
        インストールされた etcd Operator のサービスアカウント。

      3. シークレットを Operator のサービスアカウントにリンクします。 

        $ oc secrets link <operator_sa> \
    -n <tenant_namespace> \
     <secret_name> \
    --for=pull

関連情報

4.8.7. デフォルトの OperatorHub ソースの無効化

Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。クラスター管理者は、デフォルトカタログのセットを無効にすることができます。

手順

  • disableAllDefaultSources: true を OperatorHub オブジェクトに追加して、デフォルトカタログのソースを無効にします。 

    $ oc patch OperatorHub cluster --type json \
    -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
ヒント

または、Web コンソールを使用してカタログソースを管理できます。Administration Cluster Settings Global Configuration OperatorHub ページから、Sources タブをクリックして、個別のソースを作成し、削除し、無効にし、有効にすることができます。

4.8.8. カスタムカタログの削除

クラスター管理者は、関連するカタログソースを削除して、以前にクラスターに追加されたカスタム Operator カタログを削除できます。

手順

  1. Web コンソールの Administrator パースペクティブで、Administration Cluster Settings に移動します。
  2. Global Configuration タブをクリックしてから、OperatorHub をクリックします。
  3. Sources タブをクリックします。
  4. 削除するカタログの Options メニュー kebab を選択し、Delete CatalogSource をクリックします。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.