コンテナー・レジストリーへのアクセス
IBM Cloud® Code Engine で使用されるイメージは通常、レジストリーに保管されます。だれでもアクセスできるレジストリー (パブリック・レジストリー) を使用することも、小さなグループのユーザーだけにアクセスを限定したレジストリー (プライベート・レジストリー) をセットアップすることもできます。
コンテナー・レジストリー (レジストリー) は、コンテナー・イメージを保管するサービスです。 例えば、IBM Cloud Container Registryと Docker Hub はコンテナー・レジストリーです。 コンテナー・レジストリーは、パブリックにすることもプライベートにすることもできます。 パブリックであるコンテナー・レジストリーには、アクセスするための資格情報は必要ありません。 これに対して、プライベート・レジストリーへのアクセスには資格情報が必要です。
Code Engineは、以下のアクションを実行するためにコンテナー・レジストリーへのアクセスを必要とします。
- アプリまたはジョブを実行するためにコンテナー・イメージを取得 (または「プル」) する
- 新しく作成したコンテナー・イメージをイメージ・ビルドの出力として保管する
- ビルドがローカル・ソースから実行されるときにローカル・ファイルを保管および取得する
Code Engine は、システムとレジストリーの間の対話の基礎となる詳細の多くを処理します。
イメージをレジストリーからプルするために、Code Engine は、imagePullSecret
という特別なタイプの Kubernetes シークレットを使用します。 このイメージ・プル・シークレットには、コンテナー・レジストリーにアクセスするための資格情報が保管されます。 イメージをプルするために Code Engine を使用してコンテナー・レジストリーへのアクセス権限を追加すると、イメージ・プル・シークレットが作成されます。 イメージ・プル・シークレットについて詳しくは、
Kubernetes の資料を参照してください。
イメージ・レジストリーのタイプ
イメージは通常、レジストリーに保管されます。だれでもアクセスできるレジストリー (パブリック・レジストリー) を使用することも、小さなグループのユーザーだけにアクセスを限定したレジストリー (プライベート・レジストリー) をセットアップすることもできます。
パブリック Docker Hub などのパブリック・レジストリーは、Docker と Code Engine の取り掛かりとして、最初のアプリケーションまたはジョブを作成するために使用できます。 しかし、エンタープライズ・ワークロードに関しては、無許可ユーザーによるイメージの使用から保護するために、IBM Cloud Container Registryで提供されているようなプライベート・レジストリーを使用してください。 プライベート・レジストリーの場合は、レジストリー・シークレットを使用して、資格情報がプライベート・レジストリーにアクセスできるようにします。
Registry | 説明 |
---|---|
IBM Cloud Container Registry |
このタイプのレジストリーでは、 IBM Cloud Container Registry に独自の保護されたイメージ・リポジトリーをセットアップして、ユーザー間でイメージを安全に保管および共有することができます。
|
他のすべてのプライベート・レジストリー | アクセスを追加して、既存のプライベート・レジストリーを Code Engine に接続します。 アクセスを追加すると、レジストリーの URL と資格情報が Kubernetes シークレットに安全に保存されます。 プライベート・レジストリーでは、 -ソース (Docker Hub、組織が所有するレジストリー、またはその他のプライベート・クラウド・レジストリー) に関係なく、既存のプライベート・レジストリーを使用できます。 |
パブリック Docker Hub | このタイプのレジストリーを使用して、 Docker Hub から Code Engine アプリケーションまたはジョブ
に既存のパブリック・イメージを直接プルします。 重要
パブリック Docker Hub では、以下を行うことができます。 |
レジストリー・シークレットのタイプ
レジストリー内のイメージにアクセスするために、 Code Engine は、以下のいずれかのタイプのレジストリー・シークレットを使用します。
- Code Engine 管理対象シークレット-レジストリーでアカウント内の IBM Cloud Container Registry 名前空間を使用する場合は、 Code Engine に作成させることができます。 コンソールでは、自動的に作成されたこのレジストリー・シークレットは
Code Engine managed secret
と呼ばれます。 CLI では、自動的に作成されるレジストリー・シークレットの名前の形式はce-auto-icr-private-<region>
です。 - ユーザー管理シークレット - これは、ユーザーが作成および管理するシークレットです。 選択したコンテナー・レジストリー (Docker Hub など) のアクセス・トークンを API キーを使用してアカウントからイメージにアクセスするまたは使用できます。 この場合、コンソールにリストされるレジストリー・シークレットは、レジストリー・シークレットの名前です。
レジストリーがパブリックであり、資格情報を必要としない場合 (例えば、 icr.io/codeengine
または Docker Hub パブリックの Code Engine サンプル・イメージ)、レジストリー・シークレットは必要ありません。 この場合、コンソールにリストされるレジストリー・シークレットは None
です。
パブリック・アカウントからイメージへのアクセス
イメージがパブリック・リポジトリー (パブリック Docker Hub など) に保管されている場合は、アプリケーションをデプロイしたりジョブを実行したりする際に、単純にそのイメージを直接参照することができます。 アプリケーションやジョブの使用を開始するにあたってパブリック・レジストリーにイメージを保管することは問題ありませんが、エンタープライズ・イメージはプライベート・レジストリーに保管してください。
自分のアカウントにあるイメージへのコンソールからのアクセス
所有または管理しているアカウントからCode Engineにアクセスする場合、コンソールからアプリ、ジョブ、またはビルドを作成または更新するときに、Code Engineは、アカウント内のIBM Cloud Container Registry名前空間との間でイメージを自動的にプッシュおよびプルできます。Code Engineは、イメージをプッシュするときに名前空間を作成することもできます。 詳しくは、以下のトピックを参照してください。
自分のアカウントからの API キーを使用したイメージへのアクセス
CLI を使用して Code Engine にアクセスしている場合は、まず IAM API キーを作成し、IAM API キーをレジストリー・アクセス権限として Code Engine に保存する必要があります。
以下のステップでは、ユーザー ID の資格情報を保管する API キーを作成します。 ユーザー ID を使用する代わりに、IBM Cloud に対する IBM Cloud Container Registry IAM サービス・アクセス・ポリシーを割り当てたサービス ID の API キーを作成することもできます。 ユーザー ID を認証することを選択する場合は、そのユーザー ID は機能 ID にしてください。あるいは、その特定のユーザーがいなくなっても Code Engine が引き続きレジストリーにアクセスできるように計画しておいてください。
コンソールからの API キーの作成
コンソールから IBM Cloud IAM の API キーを作成するには、以下の手順を実行します。
-
アクセス (IAM) の概要を起動します。
-
**「API キー」**を選択します。
-
**「IBM Cloud API キーの作成」**をクリックします。
-
API キーの名前と説明 (オプション) を入力して**「作成」**をクリックします。
-
API キーをコピーするか、「ダウンロード」をクリックして保存します。
この API キーは再表示できないため、必ず安全な場所に記録してください。
これで API キーを作成できたので、それをレジストリー・アクセス権限として保存します。
CLI を使用した API キーの作成
CLI で IBM Cloud IAM API キーを作成するには、iam api-key-create
コマンドを実行します。 例えば、「My CLI API key」という説明を使用して cliapikey
という API キーを作成し、それを key_file
というファイルに保存するには、以下のコマンドを実行します。
ibmcloud iam api-key-create cliapikey -d "My CLI API key" --file key_file
キーをファイルに保存しないことを選択した場合は、作成時に表示される API キーを記録する必要があります。 後で取得することはできません。
これで API キーを作成できたので、それをレジストリー・アクセス権限として保存します。
異なるアカウントにあるイメージへのアクセス
IBM Cloud の IAM アクセス・ポリシーをユーザーまたはサービス ID に割り当てて、特定のレジストリー・イメージ名前空間または操作 (push や pull など) にアクセス権を制限できます。 それから、API キーを作成して、これらのレジストリー資格情報を Code Engine に保管します。
例えば、他の IBM Cloud アカウント内のイメージにアクセスするには、そのアカウント内のユーザーまたはサービス ID の IBM Cloud Container Registry 資格情報を保管する API キーを作成します。 その後、Code Engine で、そのキーを使用して自分のアカウント内にアクセス権限を作成します。
プライベート Docker Hub アカウントにあるイメージへのアクセス
プライベート Docker Hub アカウントにあるイメージにアクセスするには、自分のパスワードまたはアクセス・トークンを提供することでレジストリー・アクセス権限を作成します。 アクセス・トークンを使用すると、パスワードを変更することなく、より簡単に Docker Hub アカウントへのアクセス権限を付与したり、取り消したりすることができます。 アクセス・トークンおよび Docker Hub について詳しくは、 アクセス・トークンの管理を参照してください。
パスワードを直接使用するか、アクセス・トークンを作成するかを決めた後、レジストリー・アクセス権限を作成します。
Code Engine へのレジストリー・アクセス権限の追加
IBM Cloud Container Registry へのアクセス権限を異なる IBM Cloud アカウント内にセットアップしたり、プライベート Docker Hub アカウントからイメージをプルしたり、Code Engine CLI を使用してイメージをプルまたはプッシュしたりするには、IBM API キーまたは Docker Hub パスワードまたはアクセス・トークンを使用して Code Engine 経由でレジストリー・アクセス権限を作成し、認証キーまたはトークンを自動的に保管することができます。
コンソールを使用したレジストリー・アクセス権限の追加
始めに、プロジェクトを作成します。
- プロジェクトの状況が 「アクティブ」 になったら、 Code Engine 「プロジェクト」ページでプロジェクトの名前をクリックします。
- 「コンポーネント」ページで、**「シークレットおよび構成マップ (Secrets and configmaps)」**をクリックします。
- 「シークレットおよび構成マップ (Secrets and configmaps)」ページで**「作成」**をクリックして、シークレットを作成します。
- 「シークレットまたは構成マップの作成 (Create secret or configmap)」ページで、以下の手順を実行します。
- 「レジストリー・シークレット」 を選択し、 「次へ」 をクリックします。
- 名前を指定します (例:
mysecret-registry
)。 - このシークレットのターゲット・レジストリー ( IBM Cloud Container Registry や Docker Hub など) を指定します。
- レジストリーの場所を指定します。
- ユーザー名を指定します。 このシークレットが IBM Cloud Container Registry用である場合、ユーザー名は
iamapikey
です。 このシークレットが Docker Hub 用の場合は、 Docker ID です。 - ユーザー名の資格情報を入力します。 IBM Cloud Container Registryでは、IAM API キーを使用します。 Docker Hub の場合は、ご使用の Docker Hub パスワードかアクセス・トークンを使用できます。 その他のターゲット・レジストリーの場合は、ユーザー名のパスワードまたは API キーを指定します。
- **「作成」**をクリックして、シークレットを作成します。
これで、コンソールからシークレットが作成されたので、「シークレットと構成マップ (Secrets and configmaps)」ページに移動して、定義されているシークレットと構成マップのリストを表示します。 必要に応じて、フィルターを適用してリストをカスタマイズすることができます。
コンテナー・レジストリーへのアクセス権限は、アプリケーションまたはジョブを作成するとき、またはイメージを作成するときに追加できます。 イメージの構成をクリックし、実行するコンテナー・イメージを指定します。これには、イメージが保管されているレジストリーと、イメージの取得に使用するレジストリー・アクセスが含まれます。
CLI を使用したレジストリー・アクセス権限の追加
CLI バージョン 1.42.0以降、CLI でのシークレットの定義と操作は、 secret
コマンド・グループの下で統一されています。 ibmcloud ce secret
コマンドを参照してください。 秘密のカテゴリー
( basic_auth
、 generic
、 ssh
、 tls
、 registry
など) を指定するには、 --format
オプションを使用します。
registry
コマンド・グループは引き続き使用できますが、統一された secret
コマンド・グループを活用してください。 コンテナー・レジストリーにアクセスするためのシークレットを作成するには、 ibmcloud ce secret create --format registry
コマンドを使用します。 Code Engineでのシークレットの処理について詳しくは、 シークレットの処理 を参照してください。
CLI で IBM Cloud Container Registry または Docker Hub アクセスを追加するには、 secret create --format registry
コマンドを使用します。 このコマンドには、レジストリー・シークレットの名前、レジストリー・サーバーの URL、およびレジストリー・サーバーにアクセスするためのユーザー名とパスワードの情報が必要です。また、他のオプションの引数も使用できます。
オプションの完全なリストについては、 ibmcloud ce secret create
コマンドを参照してください。
例えば、以下のコマンドは、 us.icr.io
レジストリー・サーバー上にある myregistry
という IBM Cloud Container Registry インスタンスへのレジストリー・アクセスを作成します。
ibmcloud ce secret create --format registry --name myregistry --server us.icr.io --username iamapikey --password API_KEY
出力例
Creating registry secret 'myregistry'...
OK
以下の表は、この例の secret create --format registry
コマンドで使用されるオプションを要約しています。 コマンドとそのオプションについて詳しくは、 ibmcloud ce secret create
コマンドを参照してください。
オプション | 説明 |
---|---|
--name |
レジストリー・シークレットの名前。 プロジェクト内で固有の名前を使用します。 この値は必須です。
|
--server |
レジストリー・サーバーの URL を入力します。 Container Registryの場合、サーバー名は<region>.icr.io です。 例えば、us.icr.io です。 Docker Hub の場合、値は https://index.docker.io/v1/ です。 |
--username |
レジストリー・サーバーにアクセスするためのユーザー名を入力します。 Container Registry の場合は iamapikey です。 Docker Hub の場合は、ご使用の Docker ID です。 |
--password |
パスワードを入力します。 Container Registry の場合、パスワードは、ご使用の API キーです。 Docker Hub の場合は、ご使用の Docker Hub パスワードかアクセス・トークンを使用できます。 |
Code Engine ワークロードに対する Container Registry へのアクセスの制御
Code Engine がイメージをプルするときに、 IBM Cloud Container Registry へのアクセスを制御するとします。 例えば、特定の IP アドレスへの Container Registry へのアクセスを制御する必要があるとします。 以下の方法を検討してください。
-
コンテキスト・ベースの制限 を使用します。 コンテキスト・ベースの制限を使用することで、 Code Engine プロジェクトの IP アドレスが変更された場合でも、アクセス権限を変更する必要はありません。 Container Registry へのアクセスをネットワーク・ゾーンに制限できます。ネットワーク・ゾーンには、 Code Engine と、レジストリーへのアクセスが必要なすべてのものが含まれます。
-
IBM Cloud Container Registry へのパブリック・アクセスを無効にし、 Code Engine がパブリック・エンドポイントではなくプライベート・エンドポイントを使用するようにします。 Container Registryへの接続の保護 を参照してください。
-
特定の IP 範囲によるアクセスを制御するには、API エンドポイントを使用して、特定の Code Engine プロジェクトの IP アドレスをフェッチします。 これらの IP アドレスは変更される可能性があることに注意してください。その場合は、適切な手順を実行する必要があります。 Code Engine パブリック IP アドレスとプライベート IP アドレス および Code Engine アプリを許可リストに追加する方法 を参照してください。
レジストリー内のイメージに関する考慮事項
アプリまたはジョブに使用するイメージの名前は、以下のいずれかの形式でなければなりません。
REGISTRY/NAMESPACEorDOCKERUSERorDOCKERORG/REPOSITORY:TAG
。ここで、REGISTRY
とTAG
はオプションです。REGISTRY
を指定しない場合、そのデフォルトはdocker.io
です。TAG
を指定しない場合は、コロン (:) を含めないでください。TAG
のデフォルトはlatest
です。REGISTRY/NAMESPACEorDOCKERUSERorDOCKERORG/REPOSITORY@IMAGEID
ここで、REGISTRY
はオプションです。REGISTRY
が指定されていない場合、 Docker 組織としてのデフォルトはdocker.io
およびibm
です。
コンポーネント | 許可される文字 | Length | 追加のルール |
---|---|---|---|
REGISTRY |
a-zA-Z0-9 -_. --__ |
1-253 | (0-127Periods)(label:1-63,noDashOnEnd) |
NAMESPACE |
a-z 0-9 -_ --__ |
4-30 | (start/end with letterOrNumber) |
DOCKERUSERorDOCKERORG |
a-z 0-9 |
4-30 | |
REPOSITORY |
a-z 0-9 -_. / |
2-255 | (start/end with letterOrNumber) |
TAG |
a-zA-Z0-9 -_. --__.. |
0-128 | (NOT start with periodOrDash) |
IMAGEID |
a-z 0-9 : |
(startwith sha256: noOtherColon) |
イメージ名の各部分は、以下の基準を満たしている必要があります。
REGISTRY
は 253 文字以下でなければならず、小文字または大文字、数字、ピリオド (.)、ハイフン (-)、および下線 (_
) を使用できます。 最後の文字としてダッシュ (.) を使用しないでください。 127 個を超えるピリオド (.) を使用しないでください。これらの間のラベルは 1 文字から 63 文字までの長さにすることができます。NAMESPACE
は 4 文字から 30 文字で、先頭と末尾は小文字または数字でなければなりません。NAMESPACE
には、小文字の英数字、ハイフン (-)、および下線 (_
) を含めることができます。DOCKERUSERorDOCKERORG
は、NAMESPACE
の代わりに Docker レジストリーに使用できます。 Docker ユーザー名または Docker 組織を指定します。 Docker のユーザー名と組織名は、4 文字から 30 文字で、小文字の英数字または数字のみを使用する必要があります。REPOSITORY
は 2 文字から 255 文字で、先頭と末尾は小文字または数字でなければなりません。REPOSITORY
には、小文字の英数字、スラッシュ (/)、ピリオド (.)、ハイフン (-)、および下線 (_
) を使用できます。TAG
は 0 から 128 文字でなければならず、小文字または大文字、数字、ピリオド (.)、ハイフン (-)、および下線 (_
) を使用できます。TAG
は、ピリオドまたはダッシュで始まってはなりません。TAG
を指定しない場合は、コロンも含めないでください。IMAGEID
にはsha256:
という接頭部が付き、小文字と数字を含めることができます。