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

4.8.1. 前提条件

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

4.8.2. ファイルベースのカタログ

ファイルベースのカタログは、Operator Lifecycle Manager(OLM) のカタログ形式の最新の反復になります。この形式は、プレーンテキストベース (JSON または YAML) であり、以前の SQLite データベース形式の宣言的な設定の進化であり、完全な下位互換性があります。

ファイルベースのカタログ仕様の詳細は、Operator Framework packaging format を参照してください。

4.8.2.1. ファイルベースのカタログイメージの作成

プレーンテキストの ファイルベースのカタログ 形式 (JSON または YAML) を使用するカタログイメージを作成できます。これは、非推奨の SQLite データベース形式の後継です。opm CLI は、ファイルベースの形式でカタログを初期化し、新しいレコードをそのカタログにレンダリングして、カタログが有効であることを検証するのに役立つツールを提供します。

前提条件

opm バージョン 1.18.0+
podman version 1.9.3+
Docker v2-2 をサポートするレジストリーにビルドされ、プッシュされるバンドルイメージ。
重要
OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

手順

カタログイメージをビルドします。

$ podman build . \
    -f <operator_name>-index.Dockerfile \
    -t <registry>/<namespace>/<catalog_image_name>:<tag>

カタログイメージをレジストリーにプッシュします。
1. 必要な場合は、ターゲットレジストリーで認証します。
```
$ podman login <registry>
```
2. カタログイメージをプッシュします。
```
$ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
```

4.8.3. SQLite ベースのカタログ

重要

Operator カタログの SQLite データベース形式は非推奨の機能です。非推奨の機能は依然として OpenShift Container Platform に含まれており、引き続きサポートされますが、本製品の今後のリリースで削除されるため、新規デプロイメントでの使用は推奨されません。

OpenShift Container Platform で非推奨となったか、または削除された主な機能の最新の一覧については、OpenShift Container Platform リリースノートの 非推奨および削除された機能セクションを参照してください。

4.8.3.1. SQLite ベースのインデックスイメージの作成

opm CLI を使用して、SQLite データベース形式に基づいてインデックスイメージを作成できます。

前提条件

opm バージョン 1.18.0+
podman version 1.9.3+
Docker v2-2 をサポートするレジストリーにビルドされ、プッシュされるバンドルイメージ。
重要
OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

手順

新しいインデックスを開始します。
```
$ 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
オプション: カタログを提供するために使用する代替レジストリーベースイメージ。
インデックスイメージをレジストリーにプッシュします。
1. 必要な場合は、ターゲットレジストリーで認証します。
```
$ podman login <registry>
```
2. インデックスイメージをプッシュします。
```
$ podman push <registry>/<namespace>/<index_image_name>:<tag>
```

4.8.3.2. SQLite ベースのインデックスイメージの更新

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

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

前提条件

opm バージョン 1.18.0+
podman version 1.9.3+
レジストリーにビルドされ、プッシュされるインデックスイメージ。
インデックスイメージを参照する既存のカタログソース。

手順

バンドルイメージを追加して、既存のインデックスを更新します。
```
$ 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.9 など、以前にプッシュされたイメージタグを指定します。
<updated_tag>
4.9.1 など、更新されたインデックスイメージに適用するイメージタグを指定します。
コマンドの例
```
$ opm index add \
    --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
    --from-index mirror.example.com/abc/abc-redhat-operator-index:4.9 \
    --tag mirror.example.com/abc/abc-redhat-operator-index:4.9.1 \
    --pull-tool podman
```

更新されたインデックスイメージをプッシュします。

$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>

Operator Lifecycle Manager (OLM) がカタログソースで参照されるインデックスイメージを一定間隔で自動的にポーリングした後に、新規パッケージが正常に追加されたことを確認します。
```
$ oc get packagemanifests -n openshift-marketplace
```

4.8.3.3. SQLite ベースのインデックスイメージのフィルターリング

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

前提条件

podman version 1.9.3+
grpcurl(サードパーティーのコマンドラインツール)
opm バージョン 1.18.0+
Docker v2-2 をサポートするレジストリーへのアクセス
重要
OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。

手順

4.8.4. クラスターへのカタログソースの追加

カタログソースを OpenShift Container Platform クラスターに追加すると、ユーザーの Operator の検出およびインストールが可能になります。クラスター管理者は、インデックスイメージを参照する CatalogSource オブジェクトを作成できます。OperatorHub はカタログソースを使用してユーザーインターフェイスを設定します。

前提条件

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

手順

インデックスイメージを参照する 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
  image: <registry>/<namespace>/<index_image_name>:<tag> 3
  displayName: My Operator Catalog
  publisher: <publisher_name> 4
  updateStrategy:
    registryPoll: 5
      interval: 30m
```
  1
  カタログソースを全 namespace のユーザーがグローバルに利用できるようにする場合は、openshift-marketplace namespace を指定します。それ以外の場合は、そのカタログの別の namespace を対象とし、その namespace のみが利用できるように指定できます。
  2
  任意: olm.catalogImageTemplate アノテーションをカタログイメージ名に設定し、イメージタグのテンプレートを作成する際に、1 つ以上の Kubernetes クラスターバージョン変数を使用します。
  3
  インデックスイメージを指定します。
  4
  カタログを公開する名前または組織名を指定します。
  5
  カタログソースは新規バージョンの有無を自動的にチェックし、最新の状態を維持します。
2. このファイルを使用して CatalogSource オブジェクトを作成します。
```
$ oc apply -f catalogSource.yaml
```

以下のリソースが正常に作成されていることを確認します。

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

カタログソースを確認します。

$ oc get catalogsource -n openshift-marketplace

出力例

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

パッケージマニフェストを確認します。

$ oc get packagemanifest -n openshift-marketplace

出力例

NAME                          CATALOG               AGE
jaeger-product                My Operator Catalog   93s

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

関連情報

CatalogSource オブジェクト仕様についての詳細は、Operator Lifecycle Manager の概念およびリソースカタログソースを参照してください。
インデックスイメージがプライベートレジストリーでホストされ、認証が必要な場合は、プライベートレジストリーからの Operator のイメージへのアクセスを参照してください。

4.8.5. プライベートレジストリーからの 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. プライベートレジストリーにログインして、レジストリー認証情報ファイルを作成または更新します。
```
$ podman login <registry>:<port>
```
  注記
  レジストリー認証情報のファイルパスは、レジストリーへのログインに使用されるコンテナーツールによって異なります。podman CLI の場合、デフォルトの場所は ${XDG_RUNTIME_DIR}/containers/auth.json です。docker CLI の場合、デフォルトの場所は /root/.docker/config.json です。
2. シークレットごとに 1 つのレジストリーに対してのみ認証情報を追加し、別のシークレットで複数のレジストリーの認証情報を管理することが推奨されます。これ以降の手順で、複数のシークレットを CatalogSource オブジェクトに含めることができ、OpenShift Container Platform はイメージのプル時に使用する単一の仮想認証情報ファイルにシークレットをマージします。
  レジストリー認証情報ファイルは、デフォルトで複数のレジストリーまたはリポジトリーの詳細を 1 つのレジストリーに保存できます。ファイルの現在の内容を確認します。以下に例を示します。
  複数のレジストリーの認証情報を保存するファイル
```
{
    "auths": {
        "registry.redhat.io": {
            "auth": "FrNHNydQXdzclNqdg=="
        },
        "quay.io": {
            "auth": "fegdsRib21iMQ=="
        },
        "https://quay.io/my-namespace/my-user/my-image": {
            "auth": "eWfjwsDdfsa221=="
        },
        "https://quay.io/my-namespace/my-user": {
            "auth": "feFweDdscw34rR=="
        },
        "https://quay.io/my-namespace": {
            "auth": "frwEews4fescyq=="
        }
    }
}
```
  これ以降の手順で、シークレットの作成にこのファイルが使用されるため、保存できる詳細は 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 フラグを更新して別のレジストリー認証情報ファイルのパスを指定します。

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 セクションを追加し、必要なシークレットを指定します。

サブスクライブされた 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

関連情報

レジストリーの認証情報に使用されるものを含むシークレットの種類に関する詳細は、シークレットの概要を参照してください。
このシークレットの変更が与える影響についての詳細は、グローバルクラスタープルシークレットの更新を参照してください。
namespace ごとにプルシークレットをサービスアカウントにリンクする方法に関する詳細は、Pod が他のセキュリティー保護されたレジストリーからイメージを参照できるようにする設定を参照してください。

4.8.6. デフォルトの 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 Configuration OperatorHub ページから、Sources タブをクリックして、個別のソースを作成し、削除し、無効にし、有効にすることができます。

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

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

手順

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

4.8.1. 前提条件

4.8.2. ファイルベースのカタログ

4.8.2.1. ファイルベースのカタログイメージの作成

4.8.3. SQLite ベースのカタログ

4.8.3.1. SQLite ベースのインデックスイメージの作成

4.8.3.2. SQLite ベースのインデックスイメージの更新

4.8.3.3. SQLite ベースのインデックスイメージのフィルターリング

4.8.4. クラスターへのカタログソースの追加

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

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

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

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links