第9章 ネットワークが制限された環境での Operator Lifecycle Manager の使用
OpenShift Container Platform がネットワークが制限された環境にインストールされている場合、Operator Lifecycle Manager (OLM) は、デフォルトの OperatorHub ソースでは完全なインターネット接続が必要であるため、デフォルトの OperatorHub ソースを使用できなくなります。クラスター管理者はこれらのデフォルトソースを無効にして、ローカルミラーを作成し、OLM がローカルソースから Operator をインストールし、管理するようにできます。
9.1. ネットワークが制限された環境向けの OperatorHub の設定
クラスター管理者は、OLM および OperatorHub をネットワークが制限された環境でローカルコンテンツを使用するように設定できます。
前提条件
- OpenShift Container Platform クラスターおよびその内部レジストリーへのクラスター管理者アクセス
- ネットワークが制限されたクラスターと切り離してインターネット接続が必要なワークステーションを使用する。
- イメージを OpenShift Container Platform クラスターの内部レジストリーにプッシュする場合、レジストリーはルートで公開される必要があります。
-
podman
version 1.4.4+
手順
デフォルトの OperatorSource を無効にします。
disableAllDefaultSources: true
を仕様に追加します。$ oc patch OperatorHub cluster --type json \ -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
これにより、OpenShift Container Platform のインストール時にデフォルトで設定されるデフォルトの OperatorSource が無効になります。
パッケージ一覧を取得します。
デフォルト OperatorSource で使用できるパッケージの一覧を取得するには、ネットワークの制限のない状態でワークステーションから以下の
curl
コマンドを実行します。$ curl https://quay.io/cnr/api/v1/packages?namespace=redhat-operators > packages.txt $ curl https://quay.io/cnr/api/v1/packages?namespace=community-operators >> packages.txt $ curl https://quay.io/cnr/api/v1/packages?namespace=certified-operators >> packages.txt
新規
packages.txt
の各パッケージは、制限されたネットワークカタログに追加できる Operator です。この一覧から、すべての Operator またはユーザーに公開する必要のあるサブセットをプルできます。Operator コンテンツをプルします。
パッケージ一覧の指定された Operator について、リリースされた最新のコンテンツをプルする必要があります。
$ curl https://quay.io/cnr/api/v1/packages/<namespace>/<operator_name>/<release>
この例では、etcd Operator を使用します。
ダイジェストを取得します。
$ curl https://quay.io/cnr/api/v1/packages/community-operators/etcd/0.0.12
その JSON からダイジェストを取り、gzipped アーカイブのプルに使用します。
$ curl -XGET https://quay.io/cnr/api/v1/packages/community-operators/etcd/blobs/sha256/8108475ee5e83a0187d6d0a729451ef1ce6d34c44a868a200151c36f3232822b \ -o etcd.tar.gz
情報をプルするには、アーカイブを
manifests/<operator_name>/
ディレクトリーに必要な他のすべての Operator と共に展開する必要があります。たとえば、manifests/etcd/
という既存のディレクトリーに展開するには、以下を実行します。$ mkdir -p manifests/etcd/ 1 $ tar -xf etcd.tar.gz -C manifests/etcd/
- 1
- 展開された各アーカイブ用に異なるサブディレクトリーを作成し、ファイルが他の Operator の後続の抽出によって上書きされないようにします。
必要に応じて、
part bundle.yaml
コンテンツを分離します。新規の
manifests/<operator_name>
ディレクトリーでは、バンドルを以下のディレクトリー構造で得られるようにします。manifests/ └── etcd ├── 0.0.12 │ ├── clusterserviceversion.yaml │ └── customresourcedefinition.yaml └── package.yaml
ファイルがすでにこの構造にある場合は、この手順を省略できます。ただし、
bundle.yaml
という単一のファイルのみが表示される場合には、まずこのファイルが必要な構造に合わせて分解する必要があります。data.clusterServiceVersion
(一覧の各ファイル) の CSV コンテンツ、data.customResourceDefinition
(一覧の各ファイル) の CRD、およびdata.Package
のパッケージコンテンツをそれぞれの独自のファイルに分離する必要があります。CSV ファイルの作成の場合は、
bundle.yaml
ファイルで以下の行を見つけます。data: clusterServiceVersions: |
これらの行は省略しますが、以下の行で開始する完全な CSV リソースコンテンツで構成される新規ファイルを保存します (先頭に付けられた
-
文字は削除します)。例:
clusterserviceversion.yaml
ファイルスニペットapiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion [...]
CRD ファイルの作成の場合は、
bundle.yaml
ファイルで以下の行を見つけます。customResourceDefinitions: |
以下の行を省略しますが、以下の行で開始するそれぞれの完全な CRD リソースコンテンツで構成される新規ファイルを保存します (先頭に追加された
-
文字は削除します)customresourcedefinition.yaml
ファイルスニペットの例apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition [...]
パッケージファイルの作成の場合は、
bundle.yaml
ファイルで以下の行を見つけます。packages: |
この行は省略しますが、以下の行で始まり、
packageName
エントリーで終了するパッケージコンテンツで構成される新しいファイルを保存します (先頭に付けられた-
文字は削除します) 。package.yaml
ファイルの例channels: - currentCSV: etcdoperator.v0.9.4 name: singlenamespace-alpha - currentCSV: etcdoperator.v0.9.4-clusterwide name: clusterwide-alpha defaultChannel: singlenamespace-alpha packageName: etcd
使用する Operator で必要なイメージを特定します。
各 Opearator の CSV ファイルで
image:
フィールドを検査し、Operator で必要なイメージのプル仕様を特定し、後に使用できるようにこれをメモします。たとえば、以下は etcd Operator CSV の
deployments
仕様になります。spec: serviceAccountName: etcd-operator containers: - name: etcd-operator command: - etcd-operator - --create-crd=false image: quay.io/coreos/etcd-operator@sha256:bd944a211eaf8f31da5e6d69e8541e7cada8f16a9f7a5a570b22478997819943 1 env: - name: MY_POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: MY_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name
- 1
- Operator で必要なイメージです。
Operator カタログイメージを作成します。
以下を Dockerfile に保存します (
custom-registry.Dockerfile
という名前のサンプル)。FROM registry.redhat.io/openshift4/ose-operator-registry:v4.2.24 AS builder COPY manifests manifests RUN /bin/initializer -o ./bundles.db FROM registry.access.redhat.com/ubi7/ubi COPY --from=builder /registry/bundles.db /bundles.db COPY --from=builder /usr/bin/registry-server /registry-server COPY --from=builder /bin/grpc_health_probe /bin/grpc_health_probe EXPOSE 50051 ENTRYPOINT ["/registry-server"] CMD ["--database", "bundles.db"]
podman
コマンドを使用して、Dockerfile からコンテナーイメージを作成して、タグ付けします。$ podman build -f custom-registry.Dockerfile \ -t <local_registry_host_name>:<local_registry_host_port>/<namespace>/custom-registry 1
- 1
- ネットワークが制限された環境用の OpenShift Container Platform クラスターおよびすべての namespace の内部レジストリーのイメージにタグを付けます。
Operator カタログイメージをレジストリーにプッシュします。
新規 Operator カタログイメージは、ネットワークが制限された環境用の OpenShift Container Platform クラスターがアクセスできるレジストリーにプッシュされる必要があります。これは、クラスター自体の内部レジストリー、またはオンプレミスの Quay Enterprise レジストリーなどのクラスターがネットワークアクセスを持つ別のレジストリーの内部レジストリーになります。
以下の例では、ログインしてイメージを内部レジストリー OpenShift Container Platform クラスターにプッシュします。
$ podman push <local_registry_host_name>:<local_registry_host_port>/<namespace>/custom-registry
新規 Operator カタログイメージを参照する CatalogSource を作成します。
以下を
my-operator-catalog.yaml
などのファイルに保存します。apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: my-operator-catalog namespace: openshift-marketplace spec: displayName: My Operator Catalog sourceType: grpc image: <local_registry_host_name>:<local_registry_host_port>/<namespace>/custom-registry:latest
CatalogSource リソースを作成します。
$ oc create -f my-operator-catalog.yaml
CatalogSource およびパッケージマニフェストが正常に作成されていることを確認します。
# 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 etcd My Operator Catalog 34s
Web コンソールの OperatorHub ページからもそれらを表示できるはずです。
使用する Operator で必要なイメージをミラーリングします。
予想される Operator で定義されたイメージを判別します。この例では、
quay.io/coreos/etcd-operator
イメージを必要とする etcd Operator を使用します。重要以下の手順では、Operator イメージのミラーリングについてのみ示し、Operator が管理するコンポーネントのオペランドイメージは扱いません。ただし、オペランドイメージもミラーリングする必要があります。Operator のそれぞれのドキュメントを参照し、必要なオペランドイメージを特定します。
ミラーリングされたイメージを使用するには、まず各イメージの ImageContentSourcePolicy を作成して、Operator カタログイメージのソースの場所を変更する必要があります。例:
apiVersion: operator.openshift.io/v1alpha1 kind: ImageContentSourcePolicy metadata: name: etcd-operator spec: repositoryDigestMirrors: - mirrors: - <local_registry_host_name>:<local_registry_host_port>/coreos/etcd-operator source: quay.io/coreos/etcd-operator
ネットワークの制限のない状態でワークステーションから
oc image mirror
コマンドを使用し、ソースレジストリーからイメージをプルし、ローカルに保存することなくイメージを内部レジストリーにプッシュします。$ oc image mirror quay.io/coreos/etcd-operator \ <local_registry_host_name>:<local_registry_host_port>/coreos/etcd-operator
ネットワークが制限された環境用の OpenShift Container Platform クラスターで Operator を OperatorHub からインストールできます。
追加リソース
- OpenShift Container Platform クラスターの内部レジストリーをクラスター外のアクセスに対して公開する方法についての詳細は、「 Exposing the registry」を参照してください。
- 内部レジストリーへのアクセスについての詳細は、「Accessing the registry」を参照してください。