✕

codespace がプライベートレジストリにアクセスできるようにする

GitHub Codespacesがプライベート レジストリ内のコンテナー イメージまたはその他のパッケージにアクセスすることを許可できます。

この記事で

プライベートレジストリと GitHub Codespaces について

レジストリは、コンテナー イメージまたはその他のパッケージを格納、管理、フェッチするためのセキュリティで保護された領域です。 レジストリには次のような多くの例があります。

  •           GitHub の Container registry、Azure Container Registry、DockerHub (コンテナーイメージ用)
  • Node.js パッケージ向けのnpm registry。

GitHub Packagesを含む特定のContainer registry レジストリは、認証資格情報を指定しなくても、コードスペースの作成時にパッケージをGitHub Codespacesにシームレスにプルできるように構成できます。

他のコンテナー イメージ レジストリにアクセスするには、 GitHub にシークレットを作成してアクセスの詳細を格納します。これにより、 GitHub Codespaces はそのレジストリに格納されているイメージにアクセスできます。

詳細なアクセス許可を持つレジストリに格納されているパッケージへのアクセス

GitHub Packages Container registryを含む詳細なアクセス許可をサポートするレジストリは、パッケージを使用GitHub Codespacesするための最も簡単な方法を提供します。 詳細なアクセス許可とシームレスなGitHub Packages アクセスをサポートするGitHub Codespaces レジストリの一覧については、GitHub Packagesの権限について を参照してください。

codespace と同じリポジトリに公開されたパッケージへのアクセス

codespace が起動されたのと同じリポジトリ内のパッケージを公開すると、codespace の作成時にそのパッケージを自動的にフェッチできるようになります。 パッケージの公開時に [リポジトリからアクセス権を継承する] オプションの選択を解除していない限り、追加の資格情報を指定する必要はありません。

パッケージ公開元リポジトリからのアクセス権の継承

既定では、パッケージにより公開元のリポジトリのアクセス設定が継承されます。 たとえば、リポジトリがパブリックの場合、パッケージもパブリックになります。 リポジトリがプライベートの場合、パッケージもプライベートですが、リポジトリからアクセスできます。

この動作は、 [リポジトリからアクセス権を継承する] オプションによって制御されます。 ** **経由で発行する場合、GitHub Actionsが選択されますが、personal access tokenを使用してレジストリに直接発行する場合は選択されません。

パッケージの公開時に [リポジトリからアクセス権を継承する] オプションを選択しなかった場合は、公開されたパッケージのアクセス制御にリポジトリを手動で追加できます。 詳しくは、「パッケージのアクセス制御と可視性の設定」をご覧ください。

Organization に公開されたパッケージにアクセスすると、codespace が起動します。

Organization 内のすべての codespace からパッケージにアクセスできるようにする場合は、内部可視性を設定したパッケージを公開することをお勧めします。 これにより、codespace を起動するリポジトリがパブリックである場合以外は、Organization 内のすべての codespace にパッケージが自動的に表示されます。

内部またはプライベートのパッケージを参照するパブリック リポジトリから codespace を起動する場合は、パブリック リポジトリに内部パッケージへのアクセスを手動で許可する必要があります。 これにより、内部パッケージが誤って公開されるのを防ぐことができます。 詳しくは、「パッケージのアクセス制御と可視性の設定」をご覧ください。

Organization 内のリポジトリのサブセットからプライベート パッケージへのアクセス

Organization のリポジトリのサブセットがパッケージにアクセスできるようにする場合、またはパブリック リポジトリで起動された codespace から内部またはプライベートのパッケージへのアクセスを許可する場合は、パッケージのアクセス設定にリポジトリを手動で追加できます。 詳しくは、「パッケージのアクセス制御と可視性の設定」をご覧ください。

codespace からのパッケージの公開

codespace からレジストリへのシームレスなアクセスは、パッケージのプルに限定されます。 コードスペース内からパッケージを発行する場合は、personal access token (classic) スコープでwrite:packagesを使用する必要があります。

GitHub Actionsを使用してパッケージを発行することをお勧めします。 詳細については、「Docker イメージの発行」および「Node.jsパッケージの公開」を参照してください。

他のレジストリに格納されているイメージへのアクセス

シークレットを定義して、 GitHub Codespaces が GitHubの Container registry以外のコンテナー イメージ レジストリにアクセスできるようにします。 シームレス アクセスをサポートしていないレジストリからコンテナー イメージにアクセスする場合、 GitHub Codespaces は、レジストリのサーバー名、ユーザー名、および personal access token を定義する 3 つのシークレットが存在するかどうかを確認します。 これらのシークレットが見つかった場合、 GitHub Codespaces はコードスペース内でレジストリを使用できるようにします。

  • <*>_CONTAINER_REGISTRY_SERVER
  • <*>_CONTAINER_REGISTRY_USER
  • <*>_CONTAINER_REGISTRY_PASSWORD

シークレットは、ユーザ、リポジトリ、または Organization レベルで保存できるため、異なる Codespaces 間で安全に共有できます。 プライベート イメージ レジストリのシークレットのセットを作成するときは、名前の "<*>" を一貫した識別子に置き換える必要があります。 詳細については、「GitHub Codespaces のアカウント固有のシークレットの管理」および「リポジトリまたは Organization の開発環境シークレットの管理」を参照してください。

ユーザーまたは Organization のレベルでシークレットを設定する場合は、ドロップダウン リストからアクセス ポリシーを選択して、codespace を作成するリポジトリにシークレットを割り当てるようにしてください。

Screenshot of the "Repository access" dropdown menu with the options "All repositories," "Private repositories," and "Selected repositories."

Docker イメージを codespace にプルする

GitHub Codespaces は Docker を使用するため、実行時にコードスペース内にプライベート Docker イメージをプルするには、Docker in Docker を使用できる必要があります。 これを可能にするために、Docker へのログインに必要なシークレットが、codespace 内の ~/.docker/config.json ファイルに自動的に追加されます。 これは、onCreateCommand ライフサイクル フックの後ですが、postCreateCommand、postStartCommand、postAttachCommand の前に発生します。 その結果、postCreateCommand は Docker-in-Docker を使用して Docker イメージを codespace にプルできますが、onCreateCommand はプルできません。 このため、Docker-in-Docker はビルド前の作成時には使用できません。

codespace が実行されると、codespace でターミナルを開き、コマンド docker pull PRIVATE-IMAGE-URL を実行できます。

シークレットの例

Azureのプライベート イメージ レジストリの場合は、次のシークレットを作成できます。

ACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io
ACR_CONTAINER_REGISTRY_USER = acr-user-here
ACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>

一般的なイメージ レジストリについては、「一般的なイメージ レジストリ サーバー」をご覧ください。 AWS Elastic Container Registry (ECR) へのアクセスは異なることに注意してください。

リポジトリの "Codespaces シークレット" 設定のスクリーンショット。 ACR コンテナー レジストリの 3 つのシークレットが設定されています。

シークレットを追加したら、新しい環境変数をコンテナーに渡すために、現在の codespace を停止してから開始することが必要になる場合があります。 詳しくは、「GitHub Codespaces で Visual Studio Code コマンド パレットを使用する」をご覧ください。

AWS Elastic Container Registry へのアクセス

AWS Elastic Container Registry (ECR) にアクセスするには、AWS アクセス キー ID と秘密鍵を指定できます。 GitHub は、ユーザーの代わりにアクセス トークンを取得してログインできます。

*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>
*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>

また、資格情報のスワップ (例: sts:GetServiceBearerToken) と ECR 読み取り操作 (AmazonEC2ContainerRegistryFullAccess または ReadOnlyAccess) を実行するための適切な AWS IAM アクセス許可があることを確認する必要があります。

または、 GitHub が代わりに資格情報の交換を実行したくない場合は、AWS の API または CLI を使用してフェッチされた承認トークンを提供できます。

*_CONTAINER_REGISTRY_SERVER = <ECR_URL>
*_CONTAINER_REGISTRY_USER = AWS
*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>

これらのトークンは有効期間が短く、定期的に更新する必要があるため、アクセス キー ID とシークレットを指定することをお勧めします。

*_CONTAINER_REGISTRY_SERVER が ECR URL である限り、これらのシークレットには任意の名前を付けることができますが、複数の ECR レジストリを扱う場合を除き、ECR_CONTAINER_REGISTRY_* を使用することをお勧めします。

詳しくは、AWS ECR のプライベート レジストリ認証に関するドキュメントを参照してください。

一般的なイメージ レジストリ サーバー

一般的なイメージ レジストリ サーバーの一部を次に示します。

プライベート イメージ レジストリ アクセスのデバッグ

プライベート イメージ レジストリからイメージをプルするときに問題が発生した場合は、上記で定義したシークレットの値を使用して、docker login -u <user> -p <password> <server> を実行できることを確認してください。 ログインに失敗した場合は、ログイン資格情報が有効であること、およびコンテナー イメージをフェッチするためのサーバーに対する適切なアクセス許可があることを確かめます。 ログインに成功した場合は、ユーザー、リポジトリ、または組織レベルで、適切な GitHub Codespaces シークレットにこれらの値が適切にコピーされていることを確認してから、もう一度やり直してください。