イメージ・レジストリーのセットアップ

イメージ・レジストリー・ソリューションの選択

コンテナー・イメージは、クラスターにアプリをデプロイするためにクラスターがアクセスできるコンテナー・レジストリーに保管する必要があります。 Red Hat OpenShift クラスターの組み込みレジストリー、特定のユーザーにアクセス権限が制限されているプライベート・レジストリー、またはパブリック・レジストリーを使用することを選択できます。 以下の表を参照して、お客様のユース・ケースに最適なオプションを選択してください。

内部 Red Hat OpenShift コンテナー・レジストリー (OCR)

クラスターには内部 Red Hat OpenShift コンテナー・レジストリーがセットアップされているので、Red Hat OpenShift はクラスター内からアプリケーション・ライフサイクルを自動的にビルド、デプロイ、および管理できます。 イメージは、クラスターの作成時にプロビジョンされるバッキング用の IBM Cloud クラシック・ファイル・ストレージ・デバイスに保管されます。 ストレージが足りない場合は、デバイスのサイズを変更できます。 ユース・ケース:

• クラスター単位で実行される Red Hat OpenShift ネイティブのイメージのストリーム、ビルド、およびアプリのデプロイメント・プロセス。
• イメージはクラスター内のすべてのプロジェクトで共有できます。そのアクセスは RBAC 役割によって制御されます。
• 脆弱点スキャンなどの拡張機能のために、内部レジストリーに CloudForms などの他の Red Hat 製品を統合できます。
• ユーザーがパブリック・ネットワークを介してレジストリーからイメージをプルできるように、経路を使用して内部レジストリーを公開するオプション。
• プライベート・レジストリー (IBM Cloud Container Registry など) を使用してイメージのプルまたはイメージのプッシュを行うように内部レジストリーをセットアップするオプション。

詳しくは、内部レジストリーの使用を参照してください。

プライベート・レジストリー

プライベート・レジストリーは、無許可ユーザーからイメージを保護するのに適した選択肢です。 プライベート・レジストリーは、アクセス権限、ストレージ割り当て量、イメージ・トラスト、その他の機能が意図したとおりに機能するように、クラスター管理者がセットアップする必要があります。 デフォルトでは、Red Hat OpenShift クラスター は、default プロジェクトのイメージ・プル・シークレットを介してプライベート IBM Cloud Container Registry と統合されます。IBM Cloud Container Registry は、独自のイメージを保管するための高可用性マルチテナント・プライベート・レジストリーです。 また、IBM 提供のイメージをグローバル icr.io レジストリーからプルしたり、使用権を持つ適格なレジストリーから、ライセンス交付を受けたソフトウェアをプルしたりすることもできます。 IBM Cloud Container Registry では、IBM Cloud の IAM および請求処理との統合を利用して、複数のクラスターのイメージを管理できます。 内部レジストリーと一緒に IBM Cloud Container Registry を使用することの利点:

• ローカル・イメージ・キャッシュにより、内部レジストリーを使用するビルドを高速化。
• 他のプロジェクトのデプロイメントでイメージ・ストリームを参照できるため、プル・シークレットを各プロジェクトにコピーする必要がない。
• 複数のクラスター間でイメージを共有できるので、複数のレジストリーにイメージをプッシュする必要がない。
• イメージの脆弱性の自動スキャン。
• IBM Cloud の IAM ポリシーおよび分離されたリージョンのレジストリーによるアクセスの制御。
• クラスター内のストレージ・スペースや接続されたストレージ・デバイスを必要としないイメージの保持。 イメージの数量を管理するポリシーを設定して、過剰なスペース使用を防止することも可能。
• VPC インフラストラクチャー上のバージョン 4 クラスター: プライベート・レジストリー・サービス・エンドポイントを使用することで、プライベート・クラウド・サービス・エンドポイントしか使用しないクラスターでもレジストリーにアクセスできる。
• ストレージおよびイメージ・プル・トラフィックの割り当て量を設定できるのでイメージの保管、使用量、および請求処理の制御性が向上する。
• 使用権を持つレジストリーから、ライセンス交付を受けた IBM コンテンツをプルできる。

始めに、以下のトピックを参照してください。

• IBM Cloud Container Registry の概要。
• IBM Cloud Container Registry から内部レジストリーのイメージ・ストリームにイメージをインポートする。
• IBM Cloud Container Registry の使用。

パブリック・レジストリー

Docker Hub などのパブリック・レジストリーを使用すると、チーム、会社、クラスター、またはクラウド・プロバイダー間でイメージを共有できます。 パブリック・レジストリーには、プライベート・レジストリー・コンポーネントを利用できるものもあります。 ユース・ケース:

• パブリック・ネットワークでのイメージのプッシュおよびプル。
• 複数のクラウド・プロバイダーでコンテナーを素早くテストする。
• 脆弱点スキャンやアクセス管理などのエンタープライズ・グレードの機能が不要。

詳しくは、パブリック・レジストリーの資料 ( Quay や Docker Hubなど) を参照してください。

内部レジストリーへのイメージの保管

Red Hat OpenShift クラスターには、デフォルトで内部レジストリーがあります。 内部レジストリー内のイメージはバックアップされますが、Red Hat OpenShift on IBM Cloud クラスターのインフラストラクチャー・プロバイダーに応じて異なる方法でバックアップされます。

クラシック・クラスター

Red Hat OpenShift クラスターは、デフォルトで、 File Storage for Classic をバッキング・ストレージとして使用する内部レジストリーを使用してセットアップされます。 クラスターを削除すると、内部レジストリーとそのレジストリー内のイメージも削除されます。 イメージを保持する必要がある場合は、プライベート・レジストリー (IBM Cloud Container Registry など) を使用するか、イメージを永続ストレージ (Object Storage など) にバックアップするか、または独立した別個の Red Hat OpenShift コンテナー・レジストリー (OCR) クラスターを作成することを検討してください。 詳しくは、 Red Hat OpenShift 資料を参照してください。

VPC クラスター

Red Hat OpenShift クラスターの内部レジストリーは、アカウント内の IBM Cloud Object Storage インスタンスで自動的に作成されるバケットにイメージをバックアップします。 オブジェクト・ストレージ・バケットに保管されているデータは、クラスターを削除しても残ります。

クラシック、VPC、または Satellite のクラスター

オプションで、内部レジストリー・ポッドが実行されるワーカー・ノードの emptyDir にデータを保管するように内部レジストリーをセットアップすることを選択できます。 このデータは永続的ではないので、ポッドまたはワーカー・ノードが再始動された場合には、保管データが削除され、リカバリー不能になることに注意してください。 大きなイメージからコンテナーを定期的にビルドする場合は、イメージを emptyDir でローカルに保管することでパフォーマンスが向上する可能性があります。

oc describe pvc -n openshift-image-registry image-registry-storage

内部イメージ・レジストリーの削除

Virtual Private Cloud

内部イメージ・レジストリーを使用しない場合は、以下のステップを実行して削除できます。

1. 内部レジストリー構成のコピーを保存します。

   oc get configs.imageregistry.operator.openshift.io cluster -o yaml > configs.yaml
   

2. 以下のパッチ・コマンドを実行して、イメージ・レジストリーの管理状態を Removed に変更します。

   kubectl patch configs.imageregistry.operator.openshift.io cluster -p '{"spec":{"managementState":"Removed"}}' --type='merge'
   

3. 管理状態を変更すると、クラスター内の openshift-image-registry 名前空間からイメージ・レジストリー・サービスとデプロイメントが削除されます。 以下のコマンドを実行して、削除されたことを確認できます。 イメージ・レジストリーのデプロイメントとサービスのみが削除されることに注意してください。 イメージ・レジストリー・オペレーターのデプロイメントとサービスは残ります。

   oc get deployment -n openshift-image-registry
   

   oc get svc -n openshift-image-registry
   

内部レジストリーのためのセキュアな外部経路のセットアップ

デフォルトでは、Red Hat OpenShift クラスターの内部レジストリーは、内部 IP アドレスを割り当てられたサービスを介して使用できます。 内部レジストリーをパブリック・ネットワークに公開するには、セキュアな再暗号化経路をセットアップします。 例えば、他のプロジェクトやクラスターでのデプロイメントでパブリック・レジストリーとして機能するように、クラスターの内部レジストリーをセットアップできます。

始める前に

• クラスターに対してマネージャーの IBM Cloud IAM サービス・アクセス役割を持っていることを確認します。
• パブリック経路を使用して内部レジストリーを公開するためにパブリック・ネットワークに接続できるクラスターであることを確認します。
• ローカル・マシンに Docker をインストールします。
• Red Hat OpenShift クラスターにアクセスします。

内部レジストリーを使用するために、そのレジストリーにアクセスするためのパブリック経路をセットアップします。 次に、レジストリーにアクセスするための資格情報が含まれるイメージ・プル・シークレットを作成します。これにより、他のプロジェクトのデプロイメントでこのレジストリーからイメージをプルできるようになります。

1. openshift-image-registry プロジェクトから、内部レジストリー用の image-registry サービスが存在することを確認します。

   oc get svc -n openshift-image-registry
   

   出力例

   NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
   image-registry            ClusterIP      172.21.xxx.xxx    <none>          5000/TCP                     36d
   image-registry-operator   ClusterIP      None             <none>          60000/TCP                     36d
   

2. image-registry サービスのために、reencrypt の TLS 終端処理を使用するセキュアな経路を作成します。 再暗号化では、ルーターは、証明書を使用して TLS 接続を終端してから、別の証明書を使用して内部レジストリーへの接続を再暗号化します。 この方式を使用すると、ユーザーと内部レジストリーの間の接続パスの全体が暗号化されます。 独自のカスタム・ドメイン・ネームを指定するには、 --hostname オプションを含めます。

   oc create route reencrypt --service=image-registry -n openshift-image-registry
   

3. ** 経路に割り当てられたホスト名 (HOST/PORT) と **PORTimage-registry を取得します。

   oc get route image-registry -n openshift-image-registry
   

   出力例

   NAME              HOST/PORT                                                                                                  PATH      SERVICES          PORT       TERMINATION   WILDCARD
   image-registry   image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud             image-registry   5000-tcp   reencrypt     None
   

4. 経路を編集して ロード・バランシング戦略 を source に設定し、パススルー経路セットアップの場合と同様に、同じクライアント IP アドレスが同じサーバーに到達するようにします。 この戦略を設定するには、metadata.annotations セクションにアノテーション「haproxy.router.openshift.io/balance: source」を追加します。 構成ファイルは、Red Hat OpenShift アプリケーション・コンソールで編集するか、またはコマンド・ラインで次のコマンドを実行して編集します。

   oc edit route image-registry -n openshift-image-registry
   

   アノテーションを追加します。

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
   annotations:
       haproxy.router.openshift.io/balance: source
   ...
   

5. ローカル・システムからプロキシーまたはファイアウォールを経由してパブリック・エンドポイントにアクセスすることが、企業のネットワーク・ポリシーによって禁止されている場合は、以下の手順に従って、内部レジストリー用に作成した経路のサブドメインへのアクセスを許可します。

6. ホスト名として経路を使用して内部レジストリーにログインします。

   docker login -u $(oc whoami) -p $(oc whoami -t) image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud
   

7. ログインしたら、サンプルの hello-world アプリを内部レジストリーにプッシュしてみます。

   1. DockerHub から hello-world イメージをプルするか、ローカル・マシンでイメージを作成します。

      docker pull hello-world
      

   2. 内部レジストリーのホスト名、イメージのデプロイ先のプロジェクト、イメージ名とタグを指定して、ローカル・イメージにタグを付けます。

      docker tag hello-world:latest image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
      

   3. クラスターの内部レジストリーにイメージをプッシュします。

      docker push image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud/<project>/<image_name>:<tag>
      

   4. イメージが Red Hat OpenShift イメージ・ストリームに追加されていることを確認します。

      oc get imagestream
      

      出力例

      NAME          DOCKER REPO                                                            TAGS      UPDATED
      hello-world   image-registry-openshift-image-registry.svc:5000/default/hello-world   latest    7 hours ago
      

8. プロジェクトのデプロイメントで、この内部レジストリーからイメージをプルできるように、内部レジストリーにアクセスするための資格情報を保持するイメージ・プル・シークレットをプロジェクト内に作成します。 次に、そのイメージ・プル・シークレットを各プロジェクトのデフォルトのサービス・アカウントに追加します。

   1. デフォルトのサービス・アカウントで使用されているイメージ・プル・シークレットをリストし、default-dockercfg で始まるシークレットをメモします。

      oc describe sa default
      

      出力例

      ...
      Image pull secrets:
      all-icr-io
      default-dockercfg-mpcn4
      ...
      

   2. 構成ファイルの data フィールドから、エンコードされたシークレット情報を取得します。

      oc get secret <default-dockercfg-name> -o yaml
      

      出力例

      apiVersion: v1
      data:
        .dockercfg: ey...=
      

   3. data フィールドの値をデコードします。

      echo "<ey...=>" | base64 -D
      

      出力例

      {"172.21.xxx.xxx:5000":{"username":"serviceaccount","password":"eyJ...
      

   4. 内部レジストリーの新規イメージ・プル・シークレットを作成します。

      • secret_name: イメージ・プル・シークレットに internal-registry などの名前を付けます。
      • --namespace: イメージ・プル・シークレットを作成するプロジェクト (default など) を入力します。
      • --docker-server: 内部サービス IP アドレス (172.21.xxx.xxx:5000) の代わりに、ポート (image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud:5000) を使用して image-registry 経路のホスト名を入力します。
      • --docker-username: 上記のイメージ・プル・シークレットの "username" (serviceaccount など) をコピーします。
      • --docker-password: 上記のイメージ・プル・シークレットの "password" をコピーします。
      • --docker-email: Docker の E メール・アドレスがある場合は、その値を入力します。 ない場合は、a@b.c のような架空の E メール・アドレスを入力します。 この E メールは、Kubernetes シークレットの作成には必要ですが、作成後は使用されません。

      oc create secret image-registry internal-registry --namespace default --docker-server image-registry-openshift-image-registry.<cluster_name>-<ID_string>.<region>.containers.appdomain.cloud:5000 --docker-username serviceaccount --docker-password <eyJ...> --docker-email a@b.c
      

   5. イメージ・プル・シークレットをプロジェクトのデフォルトのサービス・アカウントに追加します。

      oc patch -n <namespace_name> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"<image_pull_secret_name>"}}]'
      

   6. 内部レジストリーからイメージをプルする必要があるプロジェクトごとに、この手順を繰り返します。

アクセス可能な経路が内部レジストリーにセットアップされたので、このレジストリーにログインし、イメージをプッシュ/プルすることができます。 詳しくは、 Red Hat OpenShift 資料を参照してください。

IBM Cloud Container Registry から内部レジストリーのイメージ・ストリームにイメージをインポートする

デフォルトでは、Red Hat OpenShift on IBM Cloud クラスターは、icr.io プロジェクトのリモートのプライベート IBM Cloud Container Registry default ドメインからイメージをプルするようにセットアップされます。 イメージを イメージ・ストリームとしてタグ付けすることにより、 IBM Cloud Container Registry から Red Hat OpenShift クラスターの内部レジストリーにイメージをインポートできます。 このセットアップでは、内部レジストリーのローカル・キャッシュを使用してイメージからアプリをデプロイできるので、アプリ・デプロイメントのビルドが高速化されます。 また、他のプロジェクトのデプロイメントでもイメージ・ストリームを参照できるので、各プロジェクトに IBM Cloud Container Registry のイメージ・プル・シークレットの資格情報を作成する必要がありません。

IBM Cloud Container Registry のイメージを更新しても、自動的にイメージが Red Hat OpenShift クラスターの内部レジストリーにプルされることはありません。 代わりに、 定期的なインポートを構成するか、これらのステップを繰り返してイメージにタグを付けます。 デプロイメントで使用するイメージ・プル・ポリシーによっては、デプロイメントの再始動が必要になる場合もあります。

ビルド、イメージ・ストリーム、内部レジストリーがどのように連携して機能するか調べることができます。 Red Hat OpenShift 資料を読むか、 コンテナー・イメージの管理に関するこのブログを参照してください。

1. Red Hat OpenShift クラスターにアクセスします。

2. イメージをイメージ・ストリームにプルする default プロジェクトに切り替えます。 default プロジェクトには、icr.io レジストリーにアクセスするための資格情報が既にセットアップされています。

   oc project default
   

3. IBM Cloud Container Registry にあるイメージをリストします。 Red Hat OpenShift クラスターの内部レジストリーにプルしたいイメージの リポジトリー と タグ をメモします。

   ibmcloud cr images
   

4. そのイメージに、IBM Cloud Container Registry 名前空間から内部レジストリーにイメージ・ストリームとしてプルするためのタグを付けます。 詳しくは、 Red Hat OpenShift の資料 を参照するか、 oc tag --help を実行してください。

   oc tag <region>.icr.io/<namespace>/<image>:<tag> default/<image>:<tag> --reference-policy=local [--scheduled]
   

   • <region>.icr.io/<namespace>/<image>:<tag>: 前に取得したリポジトリーおよびタグの情報を使用して、プルするイメージの IBM Cloud Container Registry 領域、名前空間、イメージ、およびタグ名を入力します。
   • default/<image>:<tag>: IBM Cloud Container Registry タグ付きイメージから作成する内部イメージ・ストリームの情報を入力します。 このイメージ・ストリームは default プロジェクトに作成します。このプロジェクトは、プロジェクトを指定しない場合にイメージ・ストリームが作成されるプロジェクトでもあります。 <image>:<tag> の値は通常、前に取得した値と一致します。
   • --reference-policy=local: この値には local を設定します。これにより、IBM Cloud Container Registry のイメージのコピーが内部レジストリーのローカル・キャッシュにインポートされ、イメージ・ストリームとしてクラスターのプロジェクトで使用できるようになります。 この値を指定しない場合は、デプロイメントでイメージ・ストリームを使用するときに IBM Cloud Container Registry があらためて参照されるので、プロジェクトに資格情報が必要になります。
   • --scheduled: IBM Cloud Container Registry から内部レジストリーへのイメージの定期的なインポートをセットアップするには、このオプションを設定します。 デフォルトの頻度は 15 分です。 詳しくは、 Red Hat OpenShift 資料を参照してください。

5. イメージ・ストリームが作成されたことを確認します。

   oc get imagestreams
   

6. イメージ・ストリームがイメージを IBM Cloud Container Registry から正常にプルしたことを確認します。 出力で、最新のタグ付け元 イメージが * <region>.icr.io/<namespace>/<image>@<digest> イメージと一致することを確認します。

   oc describe is/<imagestream>
   

   出力例

   NAME:            <imagestream>
   Namespace:        default
   Created:        2 days ago
   Labels:            <none>
   Annotations:        openshift.io/image.dockerRepositoryCheck=2020-03-31T09:41:36Z
   Image Repository:    image-registry.openshift-image-registry.svc:5000/default/ant1
   Image Lookup:        local=false
   Unique Images:        1
   Tags:                1
   
   latest
       tagged from <region>.icr.io/<namespace>/<image>:<tag>
   
       * <region>.icr.io/<namespace>/<image>@<digest>
           2 days ago
   

これで、開発者はアプリのデプロイメントでイメージ・ストリームを使用できるようになりました。 ローカルにプルされた内部レジストリー内のイメージから、イメージを正常にビルドできます。 イメージ・ストリームはクラスターのローカルにあるので、プロジェクト内に IBM Cloud Container Registry へのイメージ・プル・シークレットをセットアップする必要はありません。

IBM Cloud Container Registry にイメージをプッシュするように内部レジストリーのビルドをセットアップする

Red Hat OpenShift on IBM Cloud クラスターで ビルド を作成するときに、 IBM Cloud Container Registryの 外部リポジトリーにイメージをプッシュするように内部レジストリーをセットアップする ことができます。 デフォルトでは、クラスターの default プロジェクトのイメージ・プル・シークレットには、IBM Cloud Container Registry からイメージをプルするための読み取り権限しかありません。 イメージをプッシュするには、書き込み権限を持つシークレットを追加する必要があります。

1. Red Hat OpenShift クラスターにアクセスします。

2. default プロジェクトに切り替えます。

   oc project default
   

3. レジストリーでイメージのプルとプッシュを行えるように、IBM Cloud IAM の API キーをセットアップする手順Readerに従って、Writerとicr.ioのサービス・アクセス役割を持つ API キーをセットアップします。

   プロジェクトにアクセスできるユーザーは誰でも、このシークレットを使用してイメージをプライベート・レジストリーにプッシュできることに注意してください。 クラスター内で誰がどのようなアクションを実行したかを監視できるように、ロギングとモニタリングのツールをセットアップすることをお勧めします。

4. イメージをプッシュする icr.io リージョンごとに、前の手順を繰り返します。

5. シークレットをビルドのサービス・アカウントに追加し、ビルド構成ファイルでそのシークレットを参照します。 詳しくは、 Red Hat OpenShift 資料を参照してください。

   1. 先ほど作成したシークレットを、クラスター内のすべてのビルドで使用する builder 役割にリンクすることで、シークレットをビルドのサービス・アカウントに追加します。

      oc secrets link builder <secret_name>
      

   2. ビルド構成をリストし、IBM Cloud Container Registry に対するプッシュとプルのアクセス権限を付与するものをメモします。

      oc get bc
      

   3. 先ほど作成した、IBM Cloud Container Registry に対するWriterのサービス・アクセス権限を持つシークレットを使用するように、ビルド構成のイメージ・プッシュ・シークレットを設定します。

      oc set build-secret --push bc/<build_config_name> <secret_name>
      

   4. 最初のビルドのイメージをプルするレジストリーからプルできるように、ビルド構成のイメージ・プル・シークレットを設定します。 例えば、ソース・イメージが IBM Cloud Container Registry リポジトリーにある場合は、先ほど作成した、IBM Cloud Container Registry に対するReaderのサービス・アクセス権限を持つシークレットを使用できます。

      oc set build-secret --pull bc/<build_config_name> <secret_name>
      

6. IBM Cloud Container Registry にプッシュできるようにビルドのサービス・アカウントとビルド構成ファイルを更新したら、ビルドを再始動します。

   oc start-build <build_name>
   

7. ビルド・ポッドの名前 (<build>-2-build など) を取得します。

   oc get pods
   

8. ビルドのログを確認し、イメージがプッシュされた場所をメモします。

   oc logs <build_pod>
   

   イメージが正常にプッシュされたログの例。

   ...
   Successfully pushed <region>.icr.io/<namespace>/<build_name>@sha256:<hash>
   Push successful
   

9. プライベート・レジストリー内のイメージを確認して、イメージが作成されていることを確認します。

   ibmcloud cr image list
   

   出力例

   Repository                                Tag       Digest     Namespace     Created         Size     Security status   
   <region>.icr.io/<namespace>/<build_name>  latest    <digest>   <namespace>   2 minutes ago   182 MB   33 Issues  
   

これで、この Red Hat OpenShift のビルドは、IBM Cloud Container Registry との間でイメージのプルとプッシュを行えるようになりました。

IBM Cloud Container Registry の使用

デフォルトでは、Red Hat OpenShift on IBM Cloud クラスターは、icr.io プロジェクトのリモートのプライベート IBM Cloud Container Registry default ドメインからイメージをプルするようにセットアップされます。 IBM Cloud Container Registry に保管されているイメージを他のプロジェクトで使用するには、イメージ・ストリームで内部レジストリーにイメージをプルするか、プロジェクトごとに各グローバル・レジストリーおよびリージョン・レジストリーのイメージ・プル・シークレットを作成します。

イメージを内部レジストリーにインポートするには、IBM Cloud Container Registry から内部レジストリーのイメージ・ストリームにイメージをインポートするを参照してください。

外部の IBM Cloud Container Registry からイメージを直接プルするには、以下のトピックを参照してください。

• レジストリーからイメージをプルすることをクラスターに許可する方法について。
• プロジェクトの all-icr-io シークレットを、イメージをプルするプロジェクトにコピーするdefault。
• 独自のイメージ・プル・シークレットの作成。
• デプロイメント構成またはプロジェクト・サービス・アカウントへのイメージ・プル・シークレットの追加。

プライベート・レジストリーからイメージをプルする権限をクラスターに与える方法について

レジストリーからイメージをプルするために、Red Hat OpenShift on IBM Cloud クラスターは特別なタイプの Kubernetes シークレットである imagePullSecret を使用します。 このイメージ・プル・シークレットには、コンテナー・レジストリーにアクセスするための資格情報が保管されます。

コンテナー・レジストリーとして以下を使用できます。

• 自分が所有している IBM Cloud Container Registry のプライベート名前空間。
• 別の IBM Cloud Container Registry アカウントが所有している IBM Cloud のプライベート名前空間。
• その他のプライベート・レジストリー (Docker など)。

ただし、デフォルトでは、クラスターは、IBM Cloud Container Registry 内のアカウントの名前空間からのみイメージをプルし、それらのイメージからクラスター内の default Red Hat OpenShift プロジェクトにコンテナーをデプロイするようにセットアップされます。 クラスターの他のプロジェクトでイメージをプルしたり、他のコンテナー・レジストリーからイメージをプルしたりする必要がある場合は、イメージ・プル・シークレットを独自でセットアップする必要があります。

API キーのイメージ・プル・シークレットを使用するように既存のクラスターを更新する

新しい Red Hat OpenShift on IBM Cloud クラスターでは、IBM Cloud Container Registry へのアクセス権限を与えるために、イメージ・プル・シークレットに API キーを保管します。 それらのイメージ・プル・シークレットを使用すれば、icr.io レジストリー・ドメインに保管されているイメージからコンテナーをデプロイできます。 クラスターの作成時にイメージ・プル・シークレットを使用しなかった場合は、シークレットをクラスターに追加できます。

開始前に

1. Red Hat OpenShift クラスターにアクセスします。

2. IBM Cloud に対する Red Hat OpenShift on IBM Cloud IAM のオペレーターまたは管理者のプラットフォーム・アクセス役割の許可があることを確認します。 アカウント所有者は、次のコマンドを実行することでユーザーにこの役割を付与できます。

   ibmcloud iam user-policy-create EMAIL --service-name containers-kubernetes --roles "Administrator,Operator"
   

3. すべてのリージョンとリソース・グループにおける、IBM Cloud に対する IBM Cloud Container Registry IAM 管理者プラットフォーム・アクセス役割。 ポリシーのスコープを特定のリージョンまたはリソース・グループに設定することはできません。 アカウント所有者は、次のコマンドを実行することでユーザーにこの役割を付与できます。

   シークレットが正常に作成されたことを確認します。

   ibmcloud iam user-policy-create <your_user_email> --service-name container-registry --roles Administrator
   

4. アカウントでサービス ID の作成を制限している場合は、**「ID およびアクセス管理」に対する「サービス ID 作成者」**の役割を追加します (コンソールの場合)(API または CLI の場合は iam-identity)。

5. アカウントで API キーの作成を制限している場合は、**「ID およびアクセス管理」に対する「ユーザー API キー作成者」**の役割を追加します (コンソールの場合)(API または CLI の場合は iam-identity)。

イメージ・プル・シークレットを使用してデフォルト以外の IBM Cloud プロジェクトから他の Red Hat OpenShift アカウントまたは外部プライベート・レジストリーにあるイメージにアクセスする方法

default 以外の Red Hat OpenShift プロジェクトにコンテナーをデプロイしたり、他の IBM Cloud アカウントに保管されているイメージを使用したり、外部プライベート・レジストリーに保管されているイメージを使用したりするには、クラスター内に独自のイメージ・プル・シークレットをセットアップします。 さらに、独自のイメージ・プル・シークレットを作成して、特定のレジストリー・イメージ名前空間または操作 (push や pull など) にアクセス権を制限する IAM アクセス・ポリシーを適用することも可能です。

イメージ・プル・シークレットを作成したら、コンテナーがそのシークレットを使用してレジストリーからイメージをプルすることを許可する必要があります。 イメージ・プル・シークレットをプロジェクトのサービス・アカウントに追加することも、各デプロイメントでシークレットを参照することもできます。 手順については、イメージ・プル・シークレットを使用したコンテナーのデプロイを参照してください。

イメージ・プル・シークレットは、それらが作成された対象の Red Hat OpenShift プロジェクトに対してのみ有効です。 コンテナーをデプロイする名前空間ごとに、以下の手順を繰り返してください。

始める前に

1. IBM Cloud Container Registry に名前空間をセットアップして、その名前空間にイメージをプッシュします。
2. クラスターを作成します。
3. Red Hat OpenShift クラスターにアクセスします。

独自のイメージ・プル・シークレットを使用する方法としては、以下の選択肢があります。

• デフォルトの Red Hat OpenShift プロジェクトからクラスター内の他のプロジェクトへの イメージ・プル・シークレットをコピーします。
• 新しい IAM API キー資格情報を作成して、それらをイメージ・プル・シークレット内に保管することで、他の IBM Cloud アカウント内のイメージにアクセスしたり、特定のレジストリー・ドメインやレジストリー名前空間へのアクセスを制限する IAM ポリシーを適用したりする。
• 外部プライベート・レジストリーのイメージにアクセスするためのイメージ・プル・シークレットを作成する。

デプロイメントで使用するプロジェクトにイメージ・プル・シークレットを既に作成した場合は、作成済みの imagePullSecret を使用したコンテナーのデプロイを参照してください。

イメージ・プル・シークレットを使用したコンテナーのデプロイ

ポッド・デプロイメントでイメージ・プル・シークレットを定義するか、Kubernetes サービス・アカウントにイメージ・プル・シークレットを保管して、プロジェクトで Kubernetes サービス・アカウントを指定しないすべてのデプロイメントで使用できるようにすることができます。

クラスターでイメージ・プル・シークレットを使用する方法を計画するときには、以下の選択肢があります。

• ポッド・デプロイメントでイメージ・プル・シークレットを参照する: プロジェクト内のすべてのポッドに対してデフォルトでレジストリーへのアクセス権限を付与しない場合は、このオプションを使用します。 開発者は、レジストリーにアクセスする必要がある各ポッドのデプロイメントに、イメージ・プル・シークレットを含めることができます。
• Kubernetes サービス・アカウントにイメージ・プル・シークレットを保管する: 選択した Red Hat OpenShift プロジェクト内のすべてのデプロイメントについて、レジストリー内のイメージへのアクセス権限を付与する場合は、このオプションを使用します。 Kubernetes サービス・アカウントにイメージ・プル・シークレットを保管するには、以下の手順を使用します。

使用権付きソフトウェアをプルするようにクラスターをセットアップする

使用権付きソフトウェアをプルするように Red Hat OpenShift on IBM Cloud クラスターをセットアップできます。使用権付きソフトウェアとは、IBM から使用のライセンス交付を受けた、Helm チャート内でパッケージ化されている保護されたコンテナー・イメージの集合です。 使用権付きソフトウェアは、IBM Cloud Container Registry の cp.icr.io という特別なドメインに保管されます。 このドメインにアクセスするには、クラスターの使用権キーを使用してイメージ・プル・シークレットを作成し、この使用権付きソフトウェアをデプロイする各プロジェクトの Kubernetes サービス・アカウントにこのイメージ・プル・シークレットを追加する必要があります。

始める前に、Red Hat OpenShift クラスターにアクセスします。

1. 使用権付きソフトウェア・ライブラリーのための使用権キーを取得します。

   1. MyIBM.com にログインし、 「Container software library」 セクションまでスクロールします。 **「ライブラリーの表示」**をクリックします。
   2. **「Access your container software」>「Entitlement keys」ページで、「キーのコピー」**をクリックします。 このキーは、コンテナー・ソフトウェア・ライブラリー内のすべての使用権付きソフトウェアへのアクセスを許可します。

2. 使用権付きコンテナーをデプロイするプロジェクトでイメージ・プル・シークレットを作成して、使用権付きレジストリー cp.icr.io にアクセスできるようにします。 先ほど取得した使用権キーを --docker-password の値として使用します。 詳しくは、他のプライベート・レジストリー内に保管されているイメージへのアクセスを参照してください。

   oc create secret docker-registry entitled-cp-icr-io --docker-server=cp.icr.io --docker-username=cp --docker-password=<entitlement_key> --docker-email=<docker_email> -n <project>
   

3. 名前空間のサービス・アカウントにイメージ・プル・シークレットを追加して、そのプロジェクトのすべてのコンテナーが使用権キーを使用して使用権付きイメージをプルできるようにします。 詳しくは、イメージ・プル・シークレットを使用したコンテナーのデプロイを参照してください。

   oc patch -n <project> serviceaccount/default --type='json' -p='[{"op":"add","path":"/imagePullSecrets/-","value":{"name":"entitled-cp-icr-io"}}]'
   

4. 使用権付きレジストリー内のイメージからコンテナーをビルドするポッドをプロジェクト内で作成します。

   oc run <pod_name> --image=cp.icr.io/<image_name> -n <project> --generator=run-pod/v1
   

5. ポッドが**「実行中」**状況になっていることを検証することによって、使用権付きイメージからコンテナーが正常にビルドされたことを確認します。

   oc get pod <pod_name> -n <project>
   

次に何をしますか? entitled Helm チャート・リポジトリーをセットアップできます。使用権付きソフトウェアを取り込んでいる Helm チャートはそこに保管されています。 クラスター内に Helm が既にインストールされている場合は、helm repo add entitled https://raw.githubusercontent.com/IBM/charts/master/repo/entitled を実行します。

グローバル・プル・シークレットへのプライベート・レジストリーの追加

OpenShift Container Platform では、クラスター内のすべてのワーカー・ノードがプライベート・レジストリーからのイメージのプルに使用できるグローバル・イメージ・プル・シークレットをセットアップできます。

デフォルトの Red Hat OpenShift on IBM Cloud コンポーネントをデプロイできるように、Red Hat OpenShift クラスターにはデフォルトで、以下のレジストリー用のグローバル・イメージ・プル・シークレットがあります。

• cloud.openshift.com
• quay.io
• registry.connect.redhat.com
• registry.redhat.io

グローバル・プル・シークレットを、デフォルトの Red Hat レジストリーに対する資格情報が含まれていないプル・シークレットに置き換えないでください。 これを行うと、クラスターにインストールされているデフォルトの Red Hat OpenShift コンポーネント (OperatorHub など) は、これらのレジストリーからイメージをプルできないために失敗する可能性があります。

始める前に

• jq JSON プロセッサーのコマンド・ライン・パッケージをダウンロードします。 jq を使用して、デフォルトのグローバル・プル・シークレットの JSON 値を、追加するプライベート・レジストリーのプル・シークレットと結合します。
• Red Hat OpenShift クラスターにアクセスします。

プライベート・レジストリーを追加するには、pull-secret プロジェクトのグローバルなopenshift-configを編集します。

1. プライベート・レジストリーにアクセスするための資格情報が入ったシークレット値を作成し、デコードしたそのシークレット値を JSON ファイル形式で保管します。 シークレット値を作成すると、資格情報が自動的に base64 でエンコードされます。 --dry-run オプションを使用すると、シークレット値だけが作成され、クラスター内にはシークレット・オブジェクトが作成されません。 その後、後でグローバル・プル・シークレットで使用するために、デコードしたシークレット値を JSON ファイル形式で保管しています。

   oc create secret docker-registry <secret_name> --docker-server=<registry_URL> --docker-username=<docker_username> --docker-password=<docker_password> --docker-email=<docker_email> --dry-run=true --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode > myregistryconfigjson
   

   --namespace <project>

   必須。 シークレットを使用してコンテナーをデプロイする、クラスターの Red Hat OpenShift プロジェクト。 クラスター内の使用可能なプロジェクトをリストするには、oc get ns を実行します。

   <secret_name>

   必須。 イメージ・プル・シークレットに使用する名前。

   --docker-server <registry_URL>

   必須。 プライベート・イメージが保管されているレジストリーの URL。

   --docker-username <docker_username>

   必須。 プライベート・レジストリーにログインするためのユーザー名。

   --docker-password <token_value>

   必須。 プライベート・レジストリーにログインするためのパスワード (トークン値など)。

   --docker-email <docker-email>

   必須。 Docker E メール・アドレスがある場合は、その値を入力します。 ない場合は、a@b.c などの架空の E メール・アドレスを入力します。 この E メールは、Kubernetes シークレットの作成には必要ですが、作成後は使用されません。

   --dry-run=true

   シークレット値のみを作成し、シークレット・オブジェクトを作成してクラスターに保管しない場合は、このオプションを含めます。

   --output="jsonpath={.data.\.dockerconfigjson}"

   Kubernetes シークレットの data セクションから .dockerconfigjson 値のみを取得します。

   | base64 --decode > myregistryconfigjson

   デコードしたシークレット・データをローカルの myregistryconfigjson ファイルにダウンロードします。

2. デフォルトのグローバル・プル・シークレットのシークレット値をデコードしたものを取得し、その値を dockerconfigjson ファイルに保管します。

   oc get secret pull-secret -n openshift-config --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode > dockerconfigjson
   

3. ダウンロードしたプライベート・レジストリーのプル・シークレットの myregistryconfigjson ファイルを、デフォルトのグローバル・プル・シークレットの dockerconfigjson ファイルと結合します。

   jq -s '.[0] * .[1]' dockerconfigjson myregistryconfigjson > dockerconfigjson-merged
   

4. 結合した dockerconfigjson-merged ファイルを使用して、グローバル・プル・シークレットを更新します。

   oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=dockerconfigjson-merged
   

5. グローバル・プル・シークレットが更新されたことを確認します。 プライベート・レジストリーおよび Red Hat のデフォルトの各レジストリーが、以下のコマンドの出力にあることを確認します。

   oc get secret pull-secret -n openshift-config --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
   

   出力例

   {
       "auths": {
           "cloud.openshift.com": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "quay.io": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "registry.connect.redhat.com": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "registry.redhat.io": {
               "auth": "<encoded_string>",
               "email": "email@example.com"
           },
           "<private_registry>": {
               "username": "iamapikey",
               "password": "<encoded_string>",
               "email": "email@example.com",
               "auth": "<encoded_string>"
           }
       }
   }
   

6. グローバル構成の変更を反映するには、クラスター内のすべてのワーカー・ノードを再ロードします。

   1. クラスターのワーカー・ノードの ID をメモします。

      ibmcloud oc worker ls -c <cluster_name_or_ID>
      

   2. クラシック・クラスターの場合 各ワーカー・ノードを再ロードします。 複数の -w オプションを含めることで複数のワーカー・ノードを再ロードできますが、停止を回避するために、アプリ用に十分な数のワーカー・ノードを同時に実行したままにしておく必要があります。

      ibmcloud oc worker reload -c <cluster_name_or_ID> -w <workerID_1> -w <workerID_2>
      

   3. VPC クラスターの場合 各ワーカー・ノードを置き換えます。 始める前に、ご使用のクラスターにその他のワーカー・ノードが十分にあることを確認して、ポッドのスケジュールを変更し、ポッドの実行を続行できるようにしてください。

      ibmcloud oc worker replace --cluster <cluster_name_or_ID> --worker <worker_node_ID>
      

7. ワーカー・ノードが正常な状態に戻ったら、ワーカー・ノードでグローバル・プル・シークレットが更新されていることを確認します。

   1. デバッグ・ポッドを開始して、ワーカー・ノードにログインします。 <node_name> には、前に取得した プライベート IP を使用します。

      oc debug node/<node_name>
      

   2. ワーカー・ノードのファイルを表示するために、ルート・ディレクトリーをホストに変更します。

      chroot /host
      

   3. Docker 構成ファイルに、設定したグローバル・プル・シークレットに一致するレジストリー資格情報があることを確認します。

      vi /.docker/config.json
      

IBM Cloud Kubernetes Service containerd カスタム・レジストリー構成の更新

Kubernetes バージョン 1.22 以降では、ワーカー・ノード上で containerd 構成ファイルを使用して、コンテナー・レジストリーからのプルを構成できます。 daemonset を使用して、クラスター内のすべてのノードの構成を更新することができます。これにより、ワーカー・ノードの再ロード時や新規ワーカーの追加時に構成がワイプされなくなります。

server = "https://docker.io"
[host."https://registry-1.docker.io"]
capabilities = ["pull", "resolve"]

apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
    name: containerd-dockerhub-registry-config
name: containerd-dockerhub-registry-config
namespace: kube-system
spec:
selector:
    matchLabels:
    name: containerd-dockerhub-registry-config
template:
    metadata:
    labels:
        name: containerd-dockerhub-registry-config
    spec:
    initContainers:
    - image: alpine:3.13.6
        name: containerd-dockerhub-registry-config
        command:
        - /bin/sh
        - -c
        - |
            #!/bin/sh
            set -uo pipefail
            cat << EOF > /etc/containerd/certs.d/docker.io/hosts.toml
            server = "https://docker.io"
            [host."https://registry-1.docker.io"]
            capabilities = ["pull", "resolve"]
            EOF
        volumeMounts:
        - mountPath: /etc/containerd/certs.d/docker.io/
        name: dockerhub-registry-config
    containers:
    - name: pause
        image: "us.icr.io/armada-master/pause:3.5"
        imagePullPolicy: IfNotPresent
    volumes:
    - name: dockerhub-registry-config
        hostPath:
        path: /etc/containerd/certs.d/docker.io/