プライベート レジストリと GitHub Codespaces について
レジストリは、コンテナー イメージまたはその他のパッケージを格納、管理、フェッチするためのセキュリティで保護された領域です。 レジストリには次のような多くの例があります。
- GitHub の Container registry、Azure Container Registry、コンテナー イメージ用の DockerHub
- Node.js パッケージの npm registry。
Container registry を含む特定の GitHub Packages は、認証資格情報を指定する必要なく、codespace の作成時にパッケージを GitHub Codespaces にシームレスにプルできるように構成できます。
その他のコンテナー イメージ レジストリにアクセスする場合は、アクセスの詳細を格納するために、GitHub にシークレットを作成することができます。これにより、GitHub Codespaces はそのレジストリに格納されているイメージにアクセスできるようになります。
詳細なアクセス許可を持つレジストリに格納されているパッケージへのアクセス
Container registry を含む詳細なアクセス許可をサポートする GitHub Packages レジストリでは、GitHub Codespaces がパッケージを使用するための最も簡単な方法が提供されます。 詳細なアクセス許可とシームレスな GitHub Codespaces のアクセスをサポートする GitHub Packages レジストリのリストについては、「GitHub Packagesの権限について」をご覧ください。
codespace と同じリポジトリに公開されたパッケージへのアクセス
codespace が起動されたのと同じリポジトリ内のパッケージを公開すると、codespace の作成時にそのパッケージを自動的にフェッチできるようになります。 パッケージの公開時に [リポジトリからアクセス権を継承する] オプションの選択を解除していない限り、追加の資格情報を指定する必要はありません。
パッケージ公開元リポジトリからのアクセス権の継承
既定では、パッケージにより公開元のリポジトリのアクセス設定が継承されます。 たとえば、リポジトリがパブリックの場合、パッケージもパブリックになります。 リポジトリがプライベートの場合、パッケージもプライベートですが、リポジトリからアクセスできます。
この動作は、 [リポジトリからアクセス権を継承する] オプションによって制御されます。 [リポジトリからアクセス権を継承する] は、GitHub Actions を介して公開する場合は既定で選択されますが、personal access token を使用してレジストリに直接公開する場合は選択されません。
パッケージの公開時に [リポジトリからアクセス権を継承する] オプションを選択しなかった場合は、公開されたパッケージのアクセス制御にリポジトリを手動で追加できます。 詳しくは、「パッケージのアクセス制御と可視性の設定」を参照してください。
codespace が起動される Organization に公開されたパッケージへのアクセス
Organization 内のすべての codespace からパッケージにアクセスできるようにする場合は、内部可視性を設定したパッケージを公開することをお勧めします。 これにより、codespace を起動するリポジトリがパブリックである場合以外は、Organization 内のすべての codespace にパッケージが自動的に表示されます。
内部またはプライベートのパッケージを参照するパブリック リポジトリから codespace を起動する場合は、パブリック リポジトリに内部パッケージへのアクセスを手動で許可する必要があります。 これにより、内部パッケージが誤って公開されるのを防ぐことができます。 詳しくは、「パッケージのアクセス制御と可視性の設定」を参照してください。
Organization 内のリポジトリのサブセットからプライベート パッケージへのアクセス
Organization のリポジトリのサブセットがパッケージにアクセスできるようにする場合、またはパブリック リポジトリで起動された codespace から内部またはプライベートのパッケージへのアクセスを許可する場合は、パッケージのアクセス設定にリポジトリを手動で追加できます。 詳しくは、「パッケージのアクセス制御と可視性の設定」を参照してください。
codespace からのパッケージの公開
codespace からレジストリへのシームレスなアクセスは、パッケージのプルに限定されます。 codespace 内からパッケージを公開する場合は、write:packages スコープの personal access token (classic) を使用する必要があります。
GitHub Actions を使用してパッケージを公開することをお勧めします。 詳細については、「Docker イメージの発行」および「Node.jsパッケージの公開」を参照してください。
他のレジストリに格納されているイメージへのアクセス
シークレットを定義して、GitHub Codespaces が GitHub の Container registry 以外のコンテナー イメージ レジストリにアクセスできるようにすることができます。 シームレスなアクセスがサポートされていないレジストリからコンテナー イメージにアクセスする場合、GitHub Codespaces で、レジストリのサーバー名、ユーザー名、personal access token を定義する 3 つのシークレットが存在するかどうかが確認されます。 これらのシークレットが見つかった場合、GitHub Codespaces はレジストリを codespace 内で使用できるようにします。
<*>_CONTAINER_REGISTRY_SERVER<*>_CONTAINER_REGISTRY_USER<*>_CONTAINER_REGISTRY_PASSWORD
シークレットは、ユーザ、リポジトリ、または Organization レベルで保存できるため、異なる Codespaces 間で安全に共有できます。 プライベート イメージ レジストリのシークレットのセットを作成するときは、名前の "<*>" を一貫した識別子に置き換える必要があります。 詳細については、「GitHub Codespaces のアカウント固有のシークレットの管理」および「リポジトリまたは Organization の開発環境シークレットの管理」を参照してください。
ユーザーまたは Organization のレベルでシークレットを設定する場合は、ドロップダウン リストからアクセス ポリシーを選択して、codespace を作成するリポジトリにシークレットを割り当てるようにしてください。
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) へのアクセスは異なることに注意してください。
シークレットを追加したら、新しい環境変数をコンテナーに渡すために、現在の 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 のプライベート レジストリの認証に関するドキュメントを参照してください。
一般的なイメージ レジストリ サーバー
一般的なイメージ レジストリ サーバーの一部を次に示します。
- DockerHub -
https://index.docker.io/v1/ - GitHub Container Registry -
ghcr.io - Azure Container Registry -
<registry name>.azurecr.io - AWS Elastic Container Registry -
<aws_account_id>.dkr.ecr.<region>.amazonaws.com - Google Cloud Container Registry -
gcr.io(米国)、eu.gcr.io(ヨーロッパ)、asia.gcr.io(アジア)
プライベート イメージ レジストリ アクセスのデバッグ
プライベート イメージ レジストリからイメージをプルするときに問題が発生した場合は、上記で定義したシークレットの値を使用して、docker login -u <user> -p <password> <server> を実行できることを確認してください。 ログインに失敗した場合は、ログイン資格情報が有効であること、およびコンテナー イメージをフェッチするためのサーバーに対する適切なアクセス許可があることを確かめます。 ログインに成功した場合は、ユーザー、リポジトリ、または組織のレベルで、これらの値が正しい GitHub Codespaces シークレットに適切にコピーされていることを確認し、もう一度やり直してください。