4.9. ネットワークが制限された環境での Operator Lifecycle Manager の使用
ネットワークが制限された環境 ( 非接続クラスター としても知られる) にインストールされている OpenShift Container Platform クラスターの場合、デフォルトで Operator Lifecycle Manager (OLM) はリモートレジストリーでホストされる Red Hat が提供する OperatorHub ソースにアクセスできません。それらのリモートソースには完全なインターネット接続が必要であるためです。
ただし、クラスター管理者は、完全なインターネットアクセスのあるワークステーションがある場合には、クラスターがネットワークが制限された環境で OLM を使用できるようにできます。ワークステーションは、リモートソースのローカルミラーを準備するために使用され、コンテンツをミラーレジストリーにプッシュしますが、これにはリモートの OperatorHub コンテンツをプルするのに完全なインターネットアクセスが必要になります。
ミラーレジストリーは bastion ホストに配置することができます。bastion ホストには、ワークステーションと非接続クラスターの両方への接続、または完全に切断されたクラスター、またはミラーリングされたコンテンツを非接続環境に物理的に移動するためにリムーバブルメディアが必要な エアギャップ ホストへの接続が必要です。
以下では、ネットワークが制限された環境で OLM を有効にするために必要な以下のプロセスについて説明します。
- OLM のデフォルトのリモート OperatorHub ソースを無効にします。
- 完全なインターネットアクセスのあるワークステーションを使用して、OperatorHub コンテンツのローカルミラーを作成し、これをミラーレジストリーにプッシュします。
- OLM を、デフォルトのリモートソースからではなくミラーレジストリーのローカルソースから Operator をインストールし、管理するように設定します。
ネットワークが制限された環境で OLM を有効にした後も、引き続き制限のないワークステーションを使用して、Operator の新しいバージョンが更新されるとローカルの OperatorHub ソースを更新された状態に維持することができます。
OLM はローカルソースから Operator を管理できますが、指定された Operator がネットワークが制限された環境で正常に実行されるかどうかは Operator 自体に依存します。以下は、Operator の特長です。
-
関連するイメージ、または Operator がそれらの機能を実行するために必要となる可能性のある他のコンテナーイメージを
ClusterServiceVersion
(CSV) オブジェクトのrelatedImages
パラメーターで一覧表示します。 - 指定されたすべてのイメージを、タグではなくダイジェスト (SHA) で参照します。
Infrastucture Features で Disconnected フィルターを選択することにより、切断モードでの実行をサポートする Red Hat Operator のリストを Red Hat Ecosystem Catalog で検索できます。
4.9.1. 前提条件
-
cluster-admin
権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。 -
デフォルトカタログをプルーニングし、Operator のサブセットのみを選択的にミラーリングするには、
opm
CLI をインストールします。
IBM Z のネットワークが制限された環境で OLM を使用している場合は、レジストリーを配置するディレクトリーに 12 GB 以上を割り当てる必要があります。
4.9.2. デフォルトの OperatorHub ソースの無効化
Red Hat によって提供されるコンテンツを調達する Operator カタログおよびコミュニティープロジェクトは、OpenShift Container Platform のインストール時にデフォルトで OperatorHub に設定されます。ネットワークが制限された環境では、クラスター管理者としてデフォルトのカタログを無効にする必要があります。その後、OperatorHub をローカルカタログソースを使用するように設定できます。
手順
disableAllDefaultSources: true
をOperatorHub
オブジェクトに追加して、デフォルトカタログのソースを無効にします。$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
または、Web コンソールを使用してカタログソースを管理できます。Administration
4.9.3. インデックスイメージのプルーニング
Operator Bundle Format に基づくインデックスイメージは、Operator カタログのコンテナー化されたスナップショットです。パッケージの指定された一覧以外のすべてのインデックスをプルーニングできます。これにより、必要な Operator のみが含まれるソースインデックスのコピーを作成できます。
ネットワークが制限された環境の OpenShift Container Platform クラスターでミラーリングされたコンテンツを使用するように Operator Lifecycle Manager (OLM) を設定する場合、デフォルトカタログから Operator のサブセットのみをミラーリングする必要がある場合に、このプルーニング方法を使用します。
この手順のステップでは、ターゲットレジストリーは、ネットワークアクセスが無制限のワークステーションからアクセスできる既存のミラーレジストリーです。この例では、デフォルトの redhat-operators
カタログのインデックスイメージのプルーニングも示していますが、このプロセスはすべてのインデックスイメージに対して同じです。
前提条件
- ネットワークアクセスが無制限のワークステーション
-
podman
version 1.9.3+ -
grpcurl
(サードパーティーのコマンドラインツール) -
opm
バージョン 1.18.0+ Docker v2-2 をサポートするレジストリーへのアクセス
重要OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。
手順
registry.redhat.io
で認証します。$ podman login registry.redhat.io
ターゲットレジストリーで認証します。
$ podman login <target_registry>
プルーニングされたインデックスに追加するパッケージの一覧を判別します。
コンテナーでプルーニングするソースインデックスイメージを実行します。以下に例を示します。
$ 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
別のターミナルセッションで、
grpcurl
コマンドを使用して、インデックスが提供するパッケージの一覧を取得します。$ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
packages.out
ファイルを検査し、プルーニングされたインデックスに保持したいパッケージ名をこの一覧から特定します。以下に例を示します。パッケージ一覧のスニペットの例
... { "name": "advanced-cluster-management" } ... { "name": "jaeger-product" } ... { { "name": "quay-operator" } ...
-
podman run
コマンドを実行したターミナルセッションで、Ctrl と C を押してコンテナープロセスを停止します。
以下のコマンドを実行して、指定したパッケージ以外のすべてのパッケージのソースインデックスをプルーニングします。
$ 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
以下のコマンドを実行して、新規インデックスイメージをターゲットレジストリーにプッシュします。
$ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.8
ここで、
<namespace>
はレジストリー上の既存の namespace になります。たとえば、olm-mirror
namespace を作成し、ミラーリングされたすべてのコンテンツをプッシュすることができます。
4.9.4. Operator カタログのミラーリング
oc adm catalog mirror
コマンドを使用して、Red Hat が提供するカタログまたはカスタムカタログの Operator コンテンツをコンテナーイメージレジストリーにミラーリングできます。ターゲットレジストリーは Docker v2-2 をサポートする必要があります。ネットワークが制限された環境のクラスターの場合、このレジストリーには、ネットワークが制限されたクラスターのインストール時に作成されたミラーレジストリーなど、クラスターにネットワークアクセスのあるレジストリーを使用できます。
OpenShift Container Platform クラスターの内部レジストリーはターゲットレジストリーとして使用できません。これは、ミラーリングプロセスで必要となるタグを使わないプッシュをサポートしないためです。
oc adm catalog mirror
コマンドは、Red Hat が提供するインデックスイメージであるか、または独自のカスタムビルドされたインデックスイメージであるかに関係なく、ミラーリングプロセス中に指定されるインデックスイメージをターゲットレジストリーに自動的にミラーリングします。次に、ミラーリングされたインデックスイメージを使用して、Operator Lifecycle Manager (OLM) がミラーリングされたカタログを OpenShift Container Platform クラスターにロードできるようにするカタログソースを作成できます。
前提条件
- ネットワークアクセスが無制限のワークステーション
-
podman
バージョン 1.9.3 以降。 - Docker v2-2 をサポートするミラーレジストリーへのアクセス。
-
ミラーリングされた Operator コンテンツを保存するために使用するミラーレジストリー上の namespace を決定します。たとえば、
olm-mirror
namespace を作成できます。 - ミラーレジストリーにインターネットアクセスがない場合は、ネットワークアクセスが無制限のワークステーションにリムーバブルメディアを接続します。
registry.redhat.io
などのプライベートレジストリーを使用している場合、後続の手順で使用するためにREG_CREDS
環境変数をレジストリー認証情報のファイルパスに設定します。たとえばpodman
CLI の場合は、以下のようになります。$ REG_CREDS=${XDG_RUNTIME_DIR}/containers/auth.json
手順
Red Hat が提供するカタログをミラーリングする場合は、ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、
registry.redhat.io
で認証します。$ podman login registry.redhat.io
oc adm catalog mirror
コマンドは、インデックスイメージのコンテンツを抽出し、ミラーリングに必要なマニフェストを生成します。コマンドのデフォルト動作で、マニフェストを生成し、インデックスイメージからのすべてのイメージコンテンツを、インデックスイメージと同様にミラーレジストリーに対して自動的にミラーリングします。または、ミラーレジストリーが完全に非接続または エアギャップ環境のホスト上にある場合、最初にコンテンツをリムーバブルメディアにミラーリングし、メディアを非接続環境に移行してから、メディアからレジストリーにコンテンツをレジストリーに対してミラーリングできます。オプション A: ミラーレジストリーがネットワークアクセスが無制限のワークステーションと同じネットワーク上にある 場合、ワークステーションで以下のアクションを実行します。
ミラーレジストリーに認証が必要な場合は、以下のコマンドを実行してレジストリーにログインします。
$ podman login <mirror_registry>
以下のコマンドを実行してコンテンツをミラーリングします。
$ oc adm catalog mirror \ <index_image> \1 <mirror_registry>:<port>/<namespace> \2 [-a ${REG_CREDS}] \3 [--insecure] \4 [--index-filter-by-os='<platform>/<arch>'] \5 [--manifests-only] 6
- 1
- ミラーリングするカタログのインデックスイメージを指定します。たとえば、これは以前に作成したプルーニングされたインデックスイメージ、または
registry.redhat.io/redhat/redhat-operator-index:v4.8
などのデフォルトカタログのソースインデックスイメージのいずれかである可能性があります。 - 2
- Operator コンテンツをミラーリングするターゲットレジストリーおよび namespace の完全修飾ドメイン名 (FQDN) を指定します。ここで、
<namespace>
はレジストリーの既存の namespace です。たとえば、olm-mirror
namespace を作成し、ミラーリングされたすべてのコンテンツをプッシュすることができます。 - 3
- オプション: 必要な場合は、レジストリー認証情報ファイルの場所を指定します。
registry.redhat.io
には、{REG_CREDS}
が必要です。 - 4
- オプション: ターゲットレジストリーの信頼を設定しない場合は、
--insecure
フラグを追加します。 - 5
- オプション: 複数のバリアントが利用可能な場合に、選択するインデックスイメージのプラットフォームおよびアーキテクチャーを指定します。イメージは
'<platform>/<arch>[/<variant>]'
として渡されます。これはインデックスで参照されるイメージには適用されません。使用できる値は、linux/amd64
、linux/ppc64le
、linux/s390x
および.*
です。 - 6
- オプション: ミラーリングに必要なマニフェストのみを生成し、実際にはイメージコンテンツをレジストリーにミラーリングしません。このオプションは、ミラーリングする内容を確認するのに役立ちます。また、パッケージのサブセットのみが必要な場合に、マッピングの一覧に変更を加えることができます。次に、
mapping.txt
ファイルをoc image mirror
コマンドで使用し、後のステップでイメージの変更済みの一覧をミラーリングできます。このフラグは、カタログからのコンテンツの高度で選択可能なミラーリングにのみ使用することが意図されています。opm index prune
をインデックスイメージをプルーニングするために以前にしている場合、これはほとんどのカタログ管理のユースケースに適しています。
出力例
src image has index label for database path: /database/index.db using database path mapping: /database/index.db:/tmp/153048078 wrote database to /tmp/153048078 1 ... wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2
注記Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、
oc adm catalog mirror
コマンドを実行すると、401
unauthorized エラーで失敗します。回避策として、oc adm catalog mirror
コマンドを実行するときに--max-components = 2
オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は、Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューション記事を参照してください。
オプション B: ミラーレジストリーが非接続ホストにある場合 は、以下のアクションを実行します。
ネットワークアクセスが無制限のワークステーションで以下のコマンドを実行し、コンテンツをローカルファイルにミラーリングします。
$ oc adm catalog mirror \ <index_image> \1 file:///local/index \2 [-a ${REG_CREDS}] \ [--insecure] \ [--index-filter-by-os='<platform>/<arch>']
出力例
... info: Mirroring completed in 5.93s (5.915MB/s) wrote mirroring manifests to manifests-my-index-1614985528 1 To upload local images to a registry, run: oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2
-
現在のディレクトリーに生成される
v2/
ディレクトリーをリムーバブルメディアにコピーします。 - メディアを物理的に削除して、これをミラーレジストリーにアクセスできる非接続環境のホストに割り当てます。
ミラーレジストリーに認証が必要な場合は、非接続環境のホストで以下のコマンドを実行し、レジストリーにログインします。
$ podman login <mirror_registry>
v2/
ディレクトリーを含む親ディレクトリーから以下のコマンドを実行し、ローカルファイルからミラーレジストリーにイメージをアップロードします。$ oc adm catalog mirror \ file://local/index/<repo>/<index_image>:<tag> \1 <mirror_registry>:<port>/<namespace> \2 [-a ${REG_CREDS}] \ [--insecure] \ [--index-filter-by-os='<platform>/<arch>']
注記Red Hat Quay では、ネストされたリポジトリーはサポート対象外です。その結果、
oc adm catalog mirror
コマンドを実行すると、401
unauthorized エラーで失敗します。回避策として、oc adm catalog mirror
コマンドを実行するときに--max-components = 2
オプションを使用して、ネストされたリポジトリーの作成を無効にすることができます。この回避策の詳細は、Unauthorized error thrown while using catalog mirror command with Quay registry のナレッジソリューション記事を参照してください。oc adm catalogmirror
コマンドを再度実行します。新しくミラーリングされたインデックスイメージをソースとして使用し、前の手順で使用したのと同じミラーレジストリーの namespace をターゲットとして使用します。$ oc adm catalog mirror \ <mirror_registry>:<port>/<index_image> \ <mirror_registry>:<port>/<namespace> \ --manifests-only \1 [-a ${REG_CREDS}] \ [--insecure]
- 1
- コマンドがミラーリングされたすべてのコンテンツを再度コピーしないように、このステップには
--manifests-only
フラグが必要です。
重要前のステップで生成された
imageContentSourcePolicy.yaml
ファイルのイメージマッピングをローカルパスから有効なミラー位置に更新する必要があるため、このステップが必要です。そうしないと、後のステップでimageContentSourcePolicy
オブジェクトを作成するときにエラーが発生します。
コンテンツをレジストリーにミラーリングした後に、現在のディレクトリーに生成される manifests ディレクトリーを検査します。
注記manifests ディレクトリー名は後の手順で使用されます。
直前の手順で同じネットワークのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下の形式になります。
manifests-<index_image_name>-<random_number>
直前の手順で非接続ホストのレジストリーにコンテンツをミラーリングする場合、ディレクトリー名は以下の形式になります。
manifests-index/<namespace>/<index_image_name>-<random_number>
manifests ディレクトリーには以下のファイルが含まれており、これらの一部にはさらに変更が必要になる場合があります。
catalogSource.yaml
ファイルは、インデックスイメージタグおよび他の関連するメタデータで事前に設定されるCatalogSource
オブジェクトの基本的な定義です。このファイルは、カタログソースをクラスターに追加するためにそのまま使用したり、変更したりできます。重要ローカルファイルにコンテンツをミラーリングする場合は、
catalogSource.yaml
ファイルを変更してmetadata.name
フィールドからバックスラッシュ (/
) 文字を削除する必要があります。または、オブジェクトの作成を試みると、invalid resource name (無効なリソース名) を示すエラーを出して失敗します。これにより、
imageContentSourcePolicy.yaml
ファイルはImageContentSourcePolicy
オブジェクトを定義します。このオブジェクトは、ノードを Operator マニフェストおよびミラーリングされたレジストリーに保存されるイメージ参照間で変換できるように設定します。注記クラスターが
ImageContentSourcePolicy
オブジェクトを使用してリポジトリーのミラーリングを設定する場合、ミラーリングされたレジストリーにグローバルプルシークレットのみを使用できます。プロジェクトにプルシークレットを追加することはできません。mapping.txt
ファイルには、すべてのソースイメージが含まれ、これはそれらのイメージをターゲットレジストリー内のどこにマップするかを示します。このファイルはoc image mirror
コマンドと互換性があり、ミラーリング設定をさらにカスタマイズするために使用できます。重要ミラーリングのプロセスで
--manifests-only
フラグを使用しており、ミラーリングするパッケージのサブセットをさらにトリミングするには、mapping.txt
ファイルの変更およびoc image mirror
コマンドでのファイルの使用について、OpenShift Container Platform 4.7 ドキュメントの Package Manifest Format カタログイメージのミラーリング の手順を参照してください。これらの追加のアクションを実行した後に、この手順を続行できます。
非接続クラスターへのアクセスのあるホストで、以下のコマンドを実行して manifests ディレクトリーで
imageContentSourcePolicy.yaml
ファイルを指定し、ImageContentSourcePolicy
(ICSP) オブジェクトを作成します。$ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml
ここで、
<path/to/manifests/dir>
は、ミラーリングされたコンテンツについての manifests ディレクトリーへのパスです。ミラーリングされたインデックスイメージおよび Operator コンテンツを参照する
CatalogSource
を作成できるようになりました。
4.9.5. インデックスイメージからのカタログの作成
インデックスイメージから Operator カタログを作成し、これを Operator Lifecycle Manager (OLM) で使用するために OpenShift Container Platform クラスターに適用できます。
前提条件
- レジストリーにビルドされ、プッシュされるインデックスイメージ。
手順
インデックスイメージを参照する
CatalogSource
オブジェクトを作成します。oc adm catalog mirror
コマンドを使用してカタログをターゲットレジストリーにミラーリングする場合、開始点として生成されるcatalogSource.yaml
ファイルをそのまま使用することができます。仕様を以下のように変更し、これを
catalogSource.yaml
ファイルとして保存します。apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog 1 namespace: openshift-marketplace 2 spec: sourceType: grpc image: <registry>:<port>/<namespace>/redhat-operator-index:v4.8 3 displayName: My Operator Catalog publisher: <publisher_name> 4 updateStrategy: registryPoll: 5 interval: 30m
- 1
- レジストリーにアップロードする前にローカルファイルにコンテンツをミラーリングする場合は、
metadata.name
フィールドからバックスラッシュ (/
) 文字を削除し、オブジェクトの作成時に invalid resource name エラーを回避します。 - 2
- カタログソースを全 namespace のユーザーがグローバルに利用できるようにする場合は、
openshift-marketplace
namespace を指定します。それ以外の場合は、そのカタログの別の namespace を対象とし、その namespace のみが利用できるように指定できます。 - 3
- インデックスイメージを指定します。
- 4
- カタログを公開する名前または組織名を指定します。
- 5
- カタログソースは新規バージョンの有無を自動的にチェックし、最新の状態を維持します。
このファイルを使用して
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 をインストールできるようになりました。
関連情報
- インデックスイメージがプライベートレジストリーでホストされ、認証が必要な場合は、プライベートレジストリーからの Operator のイメージへのアクセス を参照してください。
4.9.6. インデックスイメージの更新
カスタムインデックスイメージを参照するカタログソースを使用するように OperatorHub を設定した後に、クラスター管理者はバンドルイメージをインデックスイメージに追加して、クラスターで利用可能な Operator を最新の状態に維持することができます。
opm index add
コマンドを使用して既存インデックスイメージを更新できます。ネットワークが制限された環境の場合、更新されたコンテンツもクラスターにミラーリングする必要があります。
前提条件
-
opm
version 1.12.3+ -
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
ここでは、以下のようになります。
<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
更新されたインデックスイメージをプッシュします。
$ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
Operator カタログのミラーリングの手順にあるステップを再度実行し、更新されたコンテンツをミラーリングします。ただし、
ImageContentSourcePolicy
(ICSP) オブジェクトの作成手順を参照する場合、oc create
コマンドの代わりにoc replace
コマンドを使用します。以下に例を示します。$ oc replace -f ./manifests-redhat-operator-index-<random_number>/imageContentSourcePolicy.yaml
この変更は、オブジェクトがすでに存在し、更新する必要があるために必要になります。
注記通常、
oc apply
コマンドを使用して、oc apply
を使用して以前に作成された既存のオブジェクトを更新できます。ただし、ICSP オブジェクトのmetadata.annotations
フィールドのサイズに関する既知の問題により、現時点ではoc replace
コマンドをこの手順で使用する必要があります。Operator Lifecycle Manager (OLM) がカタログソースで参照されるインデックスイメージを一定間隔で自動的にポーリングした後に、新規パッケージが正常に追加されたことを確認します。
$ oc get packagemanifests -n openshift-marketplace
関連情報