レジストリー
Red Hat OpenShift Service on AWS を使用すると、ソースコードからイメージを構築し、デプロイし、ライフサイクルの管理が可能。
概要
第1章 OpenShift イメージレジストリーの概要
Red Hat OpenShift Service on AWS を使用すると、ソースコードからイメージを構築し、デプロイし、ライフサイクルの管理が可能。これは、イメージをローカルで管理するために Red Hat OpenShift Service on AWS 環境にデプロイできる内部の統合コンテナーイメージレジストリーを提供します。この概要には、OpenShift イメージレジストリーに重点を置いた、Red Hat OpenShift Service on AWS で一般的に使用されるレジストリーの参照情報およびリンクが含まれます。
1.1. OpenShift イメージレジストリーの共通用語集
この用語集では、レジストリーコンテンツで使用される一般的な用語を定義しています。
- コンテナー
- ソフトウェアとそのすべての依存関係を設定する軽量で実行可能なイメージ。コンテナーはオペレーティングシステムを仮想化するため、データセンター、パブリッククラウドまたはプライベートクラウド、ローカルホストでコンテナーを実行できます。
- Image Registry Operator
-
Image Registry Operator は
openshift-image-registrynamespace で実行され、その場所のレジストリーインスタンスを管理します。 - イメージリポジトリー
- イメージリポジトリーは、関連するコンテナーイメージおよびイメージを特定するタグのコレクションです。
- ミラーレジストリー
- ミラーレジストリーは、Red Hat OpenShift Service on AWS イメージのミラーを保持するレジストリーです。
- namespace
- namespace は、単一クラスター内のリソースのグループを分離します。
- pod
- Pod は、Kubernetes における最小の論理単位です。Pod には、ワーカーノードで実行される 1 つ以上のコンテナーが含まれます。
- プライベートレジストリー
- レジストリーは、コンテナーイメージレジストリー API を実装するサーバーです。プライベートレジストリーは、ユーザーがそのコンテンツにアクセスできるようにするために認証が必要なレジストリーです。
- 公開レジストリー
- レジストリーは、コンテナーイメージレジストリー API を実装するサーバーです。公開レジストリーは、その内容を公に提供するレジストリーです。
- Quay.io
- Red Hat により提供および維持されるパブリックな Red Hat Quay Container Registry インスタンスであり、ほとんどのコンテナーイメージと Operator を Red Hat OpenShift Service on AWS クラスターに提供します。
- OpenShift イメージレジストリー
- OpenShift イメージレジストリーは、イメージを管理するために Red Hat OpenShift Service on AWS により提供されるレジストリーです。
- レジストリー認証
- プライベートイメージリポジトリーとの間でイメージをプッシュおよびプルするには、レジストリーで認証情報を使用してユーザーを認証する必要があります。
- ルート
- サービスを公開して、Red Hat OpenShift Service on AWS インスタンス外のユーザーおよびアプリケーションから Pod へのネットワークアクセスを許可します。
- スケールダウン
- レプリカの数を減らすことを意味します。
- スケールアップ
- レプリカの数を増やすことを意味します。
- サービス
- サービスは、一連の Pod で実行中のアプリケーションを公開します。
1.2. 統合 OpenShift イメージレジストリー
Red Hat OpenShift Service on AWS は、クラスター上の標準ワークロードとして実行されるコンテナーイメージレジストリーでビルドを提供します。このレジストリーはインフラストラクチャー Operator によって設定され、管理されます。また、追加設定なしで使用できる、ワークロードを実行するイメージの管理を目的とするソリューションを提供し、既存のクラスターインフラストラクチャーの上部で実行されます。このレジストリーは、他のクラスターワークロードのようにスケールアップまたはスケールダウンでき、特定のインフラストラクチャーのプロビジョニングを必要としません。さらに、クラスターのユーザー認証および認可システムに統合されるため、イメージを作成および取得するためのアクセスは、イメージリソースでユーザーのパーミッションを定義することで制御できます。
通常、レジストリーはクラスター上にビルドされたイメージの公開ターゲットとして、またクラスター上で実行されるワークロードのイメージのソースとして使用されます。新規イメージがレジストリーにプッシュされると、その旨がクラスターに通知されます。他のコンポーネントは、更新されたイメージに対して応答したり、それを使用したりできます。
イメージデータは 2 つの場所に保存されます。実際のイメージデータは、クラウドストレージまたはファイルシステムボリュームなどの設定可能なストレージの場所に格納されます。標準のクラスター API によって公開され、アクセス制御の実行に使用されるイメージメタデータは、標準的な API リソース、特にイメージおよびイメージストリームとして保存されます。
1.3. サードパーティーレジストリー
Red Hat OpenShift Service on AWS はサードパーティーレジストリーからのイメージを使用してコンテナーを作成できますが、これらのレジストリーは統合 OpenShift イメージレジストリーと同じイメージ通知をサポートする可能性はほぼありません。この場合、Red Hat OpenShift Service on AWS はイメージストリームの作成時にリモートレジストリーからタグをフェッチします。取得されたタグを更新するには、oc import-image <stream> を実行します。新規イメージが検出されると、記述したビルドとデプロイメントの応答が生じます。
1.3.1. 認証
Red Hat OpenShift Service on AWS はユーザーが指定する認証情報を使用してプライベートイメージリポジトリーにアクセスするためにレジストリーと通信できます。これにより、Red Hat OpenShift Service on AWS はイメージのプッシュ/プルをプライベートリポジトリーへ/から実行できます。
1.3.1.1. Podman を使用したレジストリー認証
一部のコンテナーイメージレジストリーではアクセス認証が必要です。Podman は、コンテナーおよびコンテナーイメージを管理し、イメージレジストリーと対話するためのオープンソースツールです。Podman を使用して、認証情報の認証、レジストリーイメージのプル、ローカルファイルシステムへのローカルイメージの保存を行なえます。以下は、Podman でレジストリーを認証する一般的な例です。
手順
- Red Hat Ecosystem Catalog を使用して Red Hat リポジトリーから特定のコンテナーイメージを検索し、必要なイメージを選択します。
- Get this image をクリックして、コンテナーイメージのコマンドを見つけます。
次のコマンドを実行してログインし、ユーザー名とパスワードを入力して認証を受けます。
$ podman login registry.redhat.io Username:<your_registry_account_username> Password:<your_registry_account_password>
以下のコマンドを実行してイメージをダウンロードし、ローカルに保存します。
$ podman pull registry.redhat.io/<repository_name>
1.4. Red Hat Quay レジストリー
エンタープライズ向けの高品質なコンテナーイメージレジストリーが必要な場合、Red Hat Quay をホストされたサービスとして、また独自のデータセンターやクラウド環境にインストールするソフトウェアとして使用できます。Red Hat Quay の高度な機能には、geo レプリケーション、イメージのスキャニング、およびイメージのロールバック機能が含まれます。
Quay.io サイトにアクセスし、独自のホストされた Quay レジストリーアカウントをセットアップします。その後、Quay チュートリアルに従って Quay レジストリーにログインし、イメージの管理を開始します。
Red Hat Quay レジストリーへのアクセスは、任意のリモートコンテナーイメージレジストリーと同様に Red Hat OpenShift Service on AWS から実行できます。
1.5. 認証が有効な Red Hat レジストリー
Red Hat Ecosystem Catalog のコンテナーイメージのセクションで利用可能なすべてのコンテナーイメージは、イメージレジストリーの registry.redhat.io でホストされます。
レジストリー registry.redhat.io では、イメージおよび Red Hat OpenShift Service on AWS でホストされるコンテンツへのアクセスに認証が必要です。新規レジストリーへの移行後も、既存レジストリーはしばらく利用可能になります。
Red Hat OpenShift Service on AWS はイメージを registry.redhat.io からプルするため、これを使用できるようにクラスターを設定する必要があります。
新規レジストリーは、以下の方法を使用して標準の OAuth メカニズムを使用します。
- 認証トークン。管理者によって生成されるこれらのトークンは、コンテナーイメージレジストリーに対する認証機能をシステムに付与するサービスアカウントです。サービスアカウントはユーザーアカウントの変更による影響を受けないため、トークンを使用する認証方法の信頼性は高く、復元力もあります。これは、実稼働クラスター用にサポートされている唯一の認証オプションです。
-
Web ユーザー名およびパスワード。これは、
access.redhat.comなどのリソースへのログインに使用する標準的な認証情報のセットです。Red Hat OpenShift Service on AWS でこの認証方法を使用することはできますが、これは実稼働デプロイメントではサポートされません。この認証方法の使用は、Red Hat OpenShift Service on AWS 外のスタンドアロンのプロジェクトに制限されます。
ユーザー名とパスワード、もしくは認証トークンのどちらかを認証情報として podman login を使用し、新規レジストリーのコンテンツにアクセスします。
すべてのイメージストリームは、インストールプルシークレットを使用して認証を行う新規レジストリーを参照します。
認証情報は以下のいずれかの場所に配置する必要があります。
-
openshiftnamespace。openshiftnamespace のイメージストリームがインポートできるように、認証情報はopenshiftnamespace に配置してください。 - ホスト。Kubernetes でイメージをプルする際にホストの認証情報を使用するため、認証情報はホスト上に配置してください。
関連情報
第2章 Red Hat OpenShift Service on AWS のイメージレジストリー Operator
2.1. Red Hat OpenShift Service on AWS のイメージレジストリー
Image Registry Operator は、OpenShift イメージレジストリーの単一インスタンスをインストールし、レジストリーストレージのセットアップを含むすべてのレジストリー設定を管理します。
コントロールプレーンのデプロイ後、Operator はクラスターで検出される設定に基づきデフォルトの configs.imageregistry.operator.openshift.io リソースインスタンスを作成します。
完全な configs.imageregistry.operator.openshift.io リソースを定義するために利用できる十分な情報がない場合、不完全なリソースが定義され、Operator は不足分を示す情報を使用してリソースのステータスを更新します。
Image Registry Operator は openshift-image-registry namespace で実行され、その場所のレジストリーインスタンスも管理します。レジストリーのすべての設定およびワークロードリソースはその namespace に置かれます。
プルーナーを管理するための Image Registory Operator の動作は、Image Registory Operator の ClusterOperator オブジェクトで指定される managementState とは独立しています。Image Registory Operator が Managed の状態ではない場合、イメージプルーナーは Pruning カスタムリソースで設定および管理できます。
ただし、Image Registory Operator の managementState は、デプロイされたイメージプルーナージョブの動作を変更します。
-
Managed: イメージプルーナーの--prune-registryフラグはtrueに設定されます。 -
Removed: イメージプルーナーの--prune-registryフラグはfalseに設定されます。つまり、これは etcd のイメージメタデータのみのプルーニングを実行します。 -
Unmanaged: イメージプルーナーの--prune-registryフラグはfalseに設定されます。
2.2. アベイラビリティーゾーン全体での Image Registry Operator のディストリビューション
Image Registry Operator のデフォルト設定は、イメージレジストリー Pod をトポロジーゾーン全体に分散し、すべての Pod が影響を受ける完全なゾーンに障害が発生した場合のリカバリー時間を防ぎます。
Image Registry Operator は、ゾーン関連のトポロジー制約でデプロイされる場合に、デフォルトで以下に設定されます。
ゾーン関連のトポロジー制約を使用してデプロイされた Image Registry Operator
topologySpreadConstraints:
- labelSelector:
matchLabels:
docker-registry: default
maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
- labelSelector:
matchLabels:
docker-registry: default
maxSkew: 1
topologyKey: node-role.kubernetes.io/worker
whenUnsatisfiable: DoNotSchedule
- labelSelector:
matchLabels:
docker-registry: default
maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
クラスター管理者は、configs.imageregistry.operator.openshift.io/cluster 仕様ファイルを設定して、デフォルトの topologySpreadConstraints をオーバーライドできます。その場合は、指定した制約のみが適用されます。
2.3. Image Registry Operator の設定パラメーター
configs.imageregistry.operator.openshift.io リソースは以下の設定パラメーターを提供します。
| パラメーター | 説明 |
|---|---|
|
|
|
|
|
レジストリーインスタンスの
|
|
| デフォルトで生成されるアップロードのセキュリティーを保護するためにレジストリーで必要な値。 |
|
|
次の
|
|
| マスター API およびアップストリームレジストリーの呼び出し時に使用されるプロキシーを定義します。 |
|
|
|
|
| レジストリーインスタンスが新規イメージのプッシュや既存イメージの削除の試行を拒否するかどうかを示します。 |
|
| API 要求の制限の詳細。指定されたレジストリーインスタンスが追加リソースをキューに入れる前に処理する並列要求の数を制御します。 |
|
|
外部ルートがデフォルトのホスト名を使用して定義されるかどうかを決定します。これが有効にされている場合、ルートは re-encrypt 暗号を使用します。デフォルトは |
|
| 作成する追加ルートの配列。ルートにホスト名および証明書を指定します。 |
|
|
イメージレジストリーのデプロイメントのロールアウトストラテジーを定義します。デフォルトは |
|
| レジストリーのレプリカ数。 |
|
|
バックエンドにリダイレクトするのではなく、レジストリーを介してすべてのデータをルーティングするかどうかを制御します。デフォルトは |
|
|
Image Registry Operator は、AWS 上のクラスターの新規インストールまたはアップグレードで、
|
2.4. イメージレジストリーのデフォルトルートをカスタムリソース定義 (CRD、Custom Resource Definition ) で有効にする
Red Hat OpenShift Service on AWS では、Registry Operator は OpenShift イメージレジストリー機能を制御します。Operator は、configs.imageregistry.operator.openshift.io カスタムリソース定義 (CRD) で定義されます。
イメージレジストリーのデフォルトルートを自動的に有効にする必要がある場合は、Image Registry Operator CRD のパッチを適用します。
手順
Image Registry Operator CRD にパッチを適用します。
$ oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'
2.5. イメージレジストリーアクセス用の追加トラストストアの設定
image.config.openshift.io/cluster カスタムリソースには、イメージレジストリーのアクセス時に信頼される追加の認証局が含まれる config map への参照を含めることができます。
前提条件
- 認証局 (CA) は PEM でエンコードされている。
手順
設定マップを openshift-config namespace に作成し、その名前を image.config.openshift.io カスタムリソースの AdditionalTrustedCA で使用し、追加の CA を指定できます。
設定マップキーは、この CA を信頼するポートがあるレジストリーのホスト名であり、値は各追加レジストリー CA が信頼する証明書のコンテンツです。
イメージレジストリー CA の config map の例
apiVersion: v1
kind: ConfigMap
metadata:
name: my-registry-ca
data:
registry.example.com: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
registry-with-port.example.com..5000: | 1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
- 1
- レジストリーにポートがある場合 (例:
registry-with-port.example.com:5000)、:は..に置き換える必要があります。
以下の手順で追加の CA を設定できます。
追加の CA を設定するには、以下を実行します。
$ oc create configmap registry-config --from-file=<external_registry_address>=ca.crt -n openshift-config
$ oc edit image.config.openshift.io cluster
spec: additionalTrustedCA: name: registry-config
2.6. Image Registry Operator のストレージ認証情報の設定
configs.imageregistry.operator.openshift.io および ConfigMap リソースの他にも、openshift-image-registry namespace 内の別のシークレットリソースによってストレージの認証情報の設定が Operator に提供されます。
image-registry-private-configuration-user シークレットは、ストレージのアクセスおよび管理に必要な認証情報を提供します。これは、デフォルト認証情報が見つからない場合に Operator が使用するデフォルト認証情報をオーバーライドします。
手順
必要なキーが含まれる Red Hat OpenShift Service on AWS シークレットを作成します。
$ oc create secret generic image-registry-private-configuration-user --from-literal=KEY1=value1 --from-literal=KEY2=value2 --namespace openshift-image-registry
第3章 レジストリーへのアクセス
ログおよびメトリクスの表示やレジストリーのセキュリティー保護および公開など、レジストリーへのさまざまなアクセス方法については、以下のセクションを参照してください。
レジストリーに直接アクセスし、podman コマンドを起動できます。これにより、podman push や podman pull などの操作で統合レジストリーに対して、もしくは統合レジストリーからイメージを直接プッシュまたはプルすることができます。これを実行するには、podman login コマンドを使用してレジストリーにログインしている必要があります。実行できる操作は、以下のセクションで説明されているようにユーザーが持つパーミッションによって異なります。
3.1. 前提条件
- cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
- アイデンティティープロバイダー (IDP) を設定している。
podman pullコマンドを使用する場合などにイメージをプルするために、registry-viewerロールがある。このロールを追加するには、以下のコマンドを実行します。$ oc policy add-role-to-user registry-viewer <user_name>
イメージの書き出しやプッシュを実行するために (
podman pushコマンドを使用する場合など)、以下が完了している。ユーザーに
registry-editorロールを指定する。このロールを追加するには、以下のコマンドを実行します。$ oc policy add-role-to-user registry-editor <user_name>
- クラスターに、イメージをプッシュできる既存のプロジェクトを用意する。
3.2. クラスターからレジストリーへの直接アクセス
クラスター内からレジストリーにアクセスできる。
手順
内部ルートを使用して、クラスターからレジストリーにアクセスします。
ノードの名前を取得してノードにアクセスします。
$ oc get nodes
$ oc debug nodes/<node_name>
ノードで
ocやpodmanなどのツールへのアクセスを有効にするには、ルートディレクトリーを/hostに変更します。sh-4.2# chroot /host
アクセストークンを使用してコンテナーイメージレジストリーにログインします。
sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
以下のようなログインを確認するメッセージが表示されるはずです。
Login Succeeded!
注記ユーザー名には任意の値を指定でき、トークンには必要な情報がすべて含まれます。コロンが含まれるユーザー名を指定すると、ログインに失敗します。
Image Registry Operator はルートを作成するため、
default-route-openshift-image-registry.<cluster_name>のようになります。レジストリーに対して
podman pullおよびpodman push操作を実行します。重要任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。
次の例では、以下を使用します。
コンポーネント 値 <registry_ip>
172.30.124.220<port>
5000<project>
openshift<image>
image<tag>
省略 (デフォルトは
latest)任意のイメージをプルします。
sh-4.2# podman pull <name.io>/<image>
新規イメージに
<registry_ip>:<port>/<project>/<image>形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするために Red Hat OpenShift Service on AWS のプル仕様に表示される必要があります。sh-4.2# podman tag <name.io>/<image> image-registry.openshift-image-registry.svc:5000/openshift/<image>
注記指定されたプロジェクトについて
system:image-builderロールを持っている必要があります。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。そうでない場合は、次の手順のpodman pushが失敗します。これをテストするには、新規プロジェクトを作成し、イメージをプッシュできます。新しくタグ付けされたイメージをレジストリーにプッシュします。
sh-4.2# podman push image-registry.openshift-image-registry.svc:5000/openshift/<image>
3.3. レジストリー Pod のステータスの確認
クラスター管理者は、openshift-image-registry プロジェクトで実行されているイメージレジストリー Pod を一覧表示し、それらのステータスを確認できます。
前提条件
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-image-registryプロジェクトの Pod を一覧表示し、それらのステータスを表示します。$ oc get pods -n openshift-image-registry
出力例
NAME READY STATUS RESTARTS AGE cluster-image-registry-operator-764bd7f846-qqtpb 1/1 Running 0 78m image-registry-79fb4469f6-llrln 1/1 Running 0 77m node-ca-hjksc 1/1 Running 0 73m node-ca-tftj6 1/1 Running 0 77m node-ca-wb6ht 1/1 Running 0 77m node-ca-zvt9q 1/1 Running 0 74m
3.4. レジストリーログの表示
oc logs コマンドを使用してレジストリーのログを表示することができます。
手順
デプロイメントで
oc logsコマンドを使用して、コンテナーイメージレジストリーのログを表示します。$ oc logs deployments/image-registry -n openshift-image-registry
出力例
2015-05-01T19:48:36.300593110Z time="2015-05-01T19:48:36Z" level=info msg="version=v2.0.0+unknown" 2015-05-01T19:48:36.303294724Z time="2015-05-01T19:48:36Z" level=info msg="redis not configured" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303422845Z time="2015-05-01T19:48:36Z" level=info msg="using inmemory layerinfo cache" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002 2015-05-01T19:48:36.303433991Z time="2015-05-01T19:48:36Z" level=info msg="Using OpenShift Auth handler" 2015-05-01T19:48:36.303439084Z time="2015-05-01T19:48:36Z" level=info msg="listening on :5000" instance.id=9ed6c43d-23ee-453f-9a4b-031fea646002
3.5. レジストリーメトリクスへのアクセス
OpenShift Container レジストリーは、Prometheus メトリクス のエンドポイントを提供します。Prometheus はスタンドアロンのオープンソースのシステムモニタリングおよびアラートツールキットです。
メトリクスは、レジストリーエンドポイントの /extensions/v2/metrics パスに公開されます。
手順
クラスターロールを使用して、メトリクスクエリーを実行すると、メトリクスにアクセスできます。
クラスターロール
メトリクスにアクセスするために必要なクラスターロールがない場合は、これを作成します。
$ cat <<EOF | oc create -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus-scraper rules: - apiGroups: - image.openshift.io resources: - registry/metrics verbs: - get EOF
このロールをユーザーに追加し、以下のコマンドを実行します。
$ oc adm policy add-cluster-role-to-user prometheus-scraper <username>
メトリクスクエリー
ユーザートークンを取得します。
openshift: $ oc whoami -t
ノードまたは Pod 内でメトリクスクエリーを実行します。次に例を示します。
$ curl --insecure -s -u <user>:<secret> \ 1 https://image-registry.openshift-image-registry.svc:5000/extensions/v2/metrics | grep imageregistry | head -n 20出力例
# HELP imageregistry_build_info A metric with a constant '1' value labeled by major, minor, git commit & git version from which the image registry was built. # TYPE imageregistry_build_info gauge imageregistry_build_info{gitCommit="9f72191",gitVersion="v3.11.0+9f72191-135-dirty",major="3",minor="11+"} 1 # HELP imageregistry_digest_cache_requests_total Total number of requests without scope to the digest cache. # TYPE imageregistry_digest_cache_requests_total counter imageregistry_digest_cache_requests_total{type="Hit"} 5 imageregistry_digest_cache_requests_total{type="Miss"} 24 # HELP imageregistry_digest_cache_scoped_requests_total Total number of scoped requests to the digest cache. # TYPE imageregistry_digest_cache_scoped_requests_total counter imageregistry_digest_cache_scoped_requests_total{type="Hit"} 33 imageregistry_digest_cache_scoped_requests_total{type="Miss"} 44 # HELP imageregistry_http_in_flight_requests A gauge of requests currently being served by the registry. # TYPE imageregistry_http_in_flight_requests gauge imageregistry_http_in_flight_requests 1 # HELP imageregistry_http_request_duration_seconds A histogram of latencies for requests to the registry. # TYPE imageregistry_http_request_duration_seconds summary imageregistry_http_request_duration_seconds{method="get",quantile="0.5"} 0.01296087 imageregistry_http_request_duration_seconds{method="get",quantile="0.9"} 0.014847248 imageregistry_http_request_duration_seconds{method="get",quantile="0.99"} 0.015981195 imageregistry_http_request_duration_seconds_sum{method="get"} 12.260727916000022- 1
<user>オブジェクトは任意ですが、<secret>タグではユーザートークンを使用する必要があります。
第4章 レジストリーの公開
デフォルトで、OpenShift イメージレジストリーのセキュリティーは、TLS 経由でトラフィックを送信できるようにクラスターのインストール時に保護されます。以前のバージョンの Red Hat OpenShift Service on AWS とは異なり、レジストリーはインストール時にクラスター外に公開されません。
4.1. デフォルトレジストリーの手動による公開
クラスター内からデフォルトの OpenShift イメージレジストリーにログインするのではなく、外部からレジストリーにアクセスできるように、このレジストリーをルートに公開します。この外部アクセスにより、ルートアドレスを使用してクラスターの外部からレジストリーにログインし、ルートホストを使用してイメージにタグを付けて既存のプロジェクトにプッシュできます。
前提条件:
以下の前提条件が自動的に実行する。
- Registry Operator をデプロイする。
- Ingress Operator デプロイする。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
configs.imageregistry.operator.openshift.io リソースで defaultRoute パラメーターを使用してルートを公開できます。
defaultRoute を使用してレジストリーを公開するには、以下を実行します。
defaultRouteをtrueに設定します。$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=mergeデフォルトのレジストリールートを取得します。
$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')Ingress Operator の証明書を取得します。
$ oc get secret -n openshift-ingress router-certs-default -o go-template='{{index .data "tls.crt"}}' | base64 -d | sudo tee /etc/pki/ca-trust/source/anchors/${HOST}.crt > /dev/null以下のコマンドを使用して、クラスターのデフォルト証明書がルートを信頼するようにします。
$ sudo update-ca-trust enable
デフォルトのルートを使用して podman にログインします。
$ sudo podman login -u kubeadmin -p $(oc whoami -t) $HOST
4.2. セキュアなレジストリーの手動による公開
クラスター内から OpenShift イメージレジストリーにログインするのではなく、外部からレジストリーにアクセスできるように、このレジストリーをルートに公開します。これにより、ルートアドレスを使用してクラスターの外部からレジストリーにログインし、ルートホストを使用してイメージにタグを付けて既存のプロジェクトにプッシュできます。
前提条件:
以下の前提条件が自動的に実行する。
- Registry Operator をデプロイする。
- Ingress Operator デプロイする。
-
cluster-adminロールを持つユーザーとしてクラスターにアクセスできる。
手順
configs.imageregistry.operator.openshift.io リソースで DefaultRoute パラメーターを使用するか、カスタムルートを使用してルートを公開できます。
DefaultRoute を使用してレジストリーを公開するには、以下を実行します。
DefaultRouteをTrueに設定します。$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=mergepodmanでログインします。$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')$ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST 1- 1
--tls-verify=falseは、ルートのクラスターのデフォルト証明書が信頼されない場合に必要になります。Ingress Operator で、信頼されるカスタム証明書をデフォルト証明書として設定できます。
カスタムルートを使用してレジストリーを公開するには、以下を実行します。
ルートの TLS キーでシークレットを作成します。
$ oc create secret tls public-route-tls \ -n openshift-image-registry \ --cert=</path/to/tls.crt> \ --key=</path/to/tls.key>この手順はオプションです。シークレットを作成しない場合、ルートは Ingress Operator からデフォルトの TLS 設定を使用します。
Registry Operator では、以下のようになります。
spec: routes: - name: public-routes hostname: myregistry.mycorp.organization secretName: public-route-tls ...注記レジストリーのルートのカスタム TLS 設定を指定している場合は
secretNameのみ設定します。
トラブルシューティング