# 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の権限について](/ja/packages/learn-github-packages/about-permissions-for-github-packages#granular-permissions-for-userorganization-scoped-packages) を参照してください。

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

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

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

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

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

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

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

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

内部またはプライベートのパッケージを参照するパブリック リポジトリから codespace を起動する場合は、パブリック リポジトリに内部パッケージへのアクセスを手動で許可する必要があります。 これにより、内部パッケージが誤って公開されるのを防ぐことができます。 詳しくは、「[パッケージのアクセス制御と可視性の設定](/ja/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package)」をご覧ください。

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

Organization のリポジトリのサブセットがパッケージにアクセスできるようにする場合、またはパブリック リポジトリで起動された codespace から内部またはプライベートのパッケージへのアクセスを許可する場合は、パッケージのアクセス設定にリポジトリを手動で追加できます。 詳しくは、「[パッケージのアクセス制御と可視性の設定](/ja/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package)」をご覧ください。

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

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

GitHub Actionsを使用してパッケージを発行することをお勧めします。 詳細については、「[Docker イメージの発行](/ja/actions/tutorials/publish-packages/publish-docker-images)」および「[Node.jsパッケージの公開](/ja/actions/tutorials/publish-packages/publish-nodejs-packages)」を参照してください。

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

シークレットを定義して、 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 のアカウント固有のシークレットの管理](/ja/codespaces/managing-your-codespaces/managing-your-account-specific-secrets-for-github-codespaces)」および「[リポジトリまたは Organization の開発環境シークレットの管理](/ja/codespaces/managing-codespaces-for-your-organization/managing-development-environment-secrets-for-your-repository-or-organization)」を参照してください。

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

<img src="/assets/images/help/codespaces/secret-repository-access.png" alt='Screenshot of the "Repository access" dropdown menu with the options "All repositories," "Private repositories," and "Selected repositories."' style="width:400px;"/>

### 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のプライベート イメージ レジストリの場合は、次のシークレットを作成できます。

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

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

![リポジトリの "Codespaces シークレット" 設定のスクリーンショット。 ACR コンテナー レジストリの 3 つのシークレットが設定されています。](/assets/images/help/codespaces/codespaces-image-registry-secret-example.png)

シークレットを追加したら、新しい環境変数をコンテナーに渡すために、現在の codespace を停止してから開始することが必要になる場合があります。 詳しくは、「[GitHub Codespaces で Visual Studio Code コマンド パレットを使用する](/ja/codespaces/reference/using-the-vs-code-command-palette-in-codespaces#suspending-or-stopping-a-codespace)」をご覧ください。

#### AWS Elastic Container Registry へのアクセス

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

```shell
*_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 を使用してフェッチされた承認トークンを提供できます。

```shell
*_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 の[プライベート レジストリ認証に関するドキュメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html)を参照してください。

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

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

* [DockerHub](https://docs.docker.com/engine/reference/commandline/info/) - `https://index.docker.io/v1/`
* [GitHub コンテナー レジストリ](/ja/packages/working-with-a-github-packages-registry/working-with-the-container-registry) - `ghcr.io`
* [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/) - `<registry name>.azurecr.io`
* [AWS Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) - `<aws_account_id>.dkr.ecr.<region>.amazonaws.com`
* [Google Cloud Container Registry](https://cloud.google.com/container-registry/docs/overview#registries) - `gcr.io` (米国)、`eu.gcr.io` (ヨーロッパ)、`asia.gcr.io` (アジア)

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

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