{"meta":{"title":"codespace がプライベートレジストリにアクセスできるようにする","intro":"GitHub Codespacesがプライベート レジストリ内のコンテナー イメージまたはその他のパッケージにアクセスすることを許可できます。","product":"Codespaces","breadcrumbs":[{"href":"/ja/codespaces","title":"Codespaces"},{"href":"/ja/codespaces/reference","title":"関連項目"},{"href":"/ja/codespaces/reference/allowing-your-codespace-to-access-a-private-registry","title":"プライベート レジストリへのアクセス"}],"documentType":"article"},"body":"# codespace がプライベートレジストリにアクセスできるようにする\n\nGitHub Codespacesがプライベート レジストリ内のコンテナー イメージまたはその他のパッケージにアクセスすることを許可できます。\n\n## プライベートレジストリと GitHub Codespaces について\n\nレジストリは、コンテナー イメージまたはその他のパッケージを格納、管理、フェッチするためのセキュリティで保護された領域です。 レジストリには次のような多くの例があります。\n\n* GitHub の Container registry、Azure Container Registry、DockerHub (コンテナーイメージ用)\n* Node.js パッケージ向けのnpm registry。\n\nGitHub Packagesを含む特定のContainer registry レジストリは、認証資格情報を指定しなくても、コードスペースの作成時にパッケージをGitHub Codespacesにシームレスにプルできるように構成できます。\n\n他のコンテナー イメージ レジストリにアクセスするには、 GitHub にシークレットを作成してアクセスの詳細を格納します。これにより、 GitHub Codespaces はそのレジストリに格納されているイメージにアクセスできます。\n\n## 詳細なアクセス許可を持つレジストリに格納されているパッケージへのアクセス\n\nGitHub Packages\nContainer 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) を参照してください。\n\n### codespace と同じリポジトリに公開されたパッケージへのアクセス\n\ncodespace が起動されたのと同じリポジトリ内のパッケージを公開すると、codespace の作成時にそのパッケージを自動的にフェッチできるようになります。 パッケージの公開時に **\\[リポジトリからアクセス権を継承する]** オプションの選択を解除していない限り、追加の資格情報を指定する必要はありません。\n\n#### パッケージ公開元リポジトリからのアクセス権の継承\n\n既定では、パッケージにより公開元のリポジトリのアクセス設定が継承されます。 たとえば、リポジトリがパブリックの場合、パッケージもパブリックになります。 リポジトリがプライベートの場合、パッケージもプライベートですが、リポジトリからアクセスできます。\n\nこの動作は、 **\\[リポジトリからアクセス権を継承する]** オプションによって制御されます。\n\\*\\*\n\\*\\*経由で発行する場合、GitHub Actionsが選択されますが、personal access tokenを使用してレジストリに直接発行する場合は選択されません。\n\nパッケージの公開時に **\\[リポジトリからアクセス権を継承する]** オプションを選択しなかった場合は、公開されたパッケージのアクセス制御にリポジトリを手動で追加できます。 詳しくは、「[パッケージのアクセス制御と可視性の設定](/ja/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility)」をご覧ください。\n\n### Organization に公開されたパッケージにアクセスすると、codespace が起動します。\n\nOrganization 内のすべての codespace からパッケージにアクセスできるようにする場合は、内部可視性を設定したパッケージを公開することをお勧めします。 これにより、codespace を起動するリポジトリがパブリックである場合以外は、Organization 内のすべての codespace にパッケージが自動的に表示されます。\n\n内部またはプライベートのパッケージを参照するパブリック リポジトリから codespace を起動する場合は、パブリック リポジトリに内部パッケージへのアクセスを手動で許可する必要があります。 これにより、内部パッケージが誤って公開されるのを防ぐことができます。 詳しくは、「[パッケージのアクセス制御と可視性の設定](/ja/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package)」をご覧ください。\n\n### Organization 内のリポジトリのサブセットからプライベート パッケージへのアクセス\n\nOrganization のリポジトリのサブセットがパッケージにアクセスできるようにする場合、またはパブリック リポジトリで起動された codespace から内部またはプライベートのパッケージへのアクセスを許可する場合は、パッケージのアクセス設定にリポジトリを手動で追加できます。 詳しくは、「[パッケージのアクセス制御と可視性の設定](/ja/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#ensuring-github-codespaces-access-to-your-package)」をご覧ください。\n\n### codespace からのパッケージの公開\n\ncodespace からレジストリへのシームレスなアクセスは、パッケージのプルに限定されます。 コードスペース内からパッケージを発行する場合は、personal access token (classic) スコープで`write:packages`を使用する必要があります。\n\nGitHub Actionsを使用してパッケージを発行することをお勧めします。 詳細については、「[Docker イメージの発行](/ja/actions/tutorials/publish-packages/publish-docker-images)」および「[Node.jsパッケージの公開](/ja/actions/tutorials/publish-packages/publish-nodejs-packages)」を参照してください。\n\n## 他のレジストリに格納されているイメージへのアクセス\n\nシークレットを定義して、 GitHub Codespaces が GitHubの Container registry以外のコンテナー イメージ レジストリにアクセスできるようにします。 シームレス アクセスをサポートしていないレジストリからコンテナー イメージにアクセスする場合、 GitHub Codespaces は、レジストリのサーバー名、ユーザー名、および personal access token を定義する 3 つのシークレットが存在するかどうかを確認します。 これらのシークレットが見つかった場合、 GitHub Codespaces はコードスペース内でレジストリを使用できるようにします。\n\n* `<*>_CONTAINER_REGISTRY_SERVER`\n* `<*>_CONTAINER_REGISTRY_USER`\n* `<*>_CONTAINER_REGISTRY_PASSWORD`\n\nシークレットは、ユーザ、リポジトリ、または 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)」を参照してください。\n\nユーザーまたは Organization のレベルでシークレットを設定する場合は、ドロップダウン リストからアクセス ポリシーを選択して、codespace を作成するリポジトリにシークレットを割り当てるようにしてください。\n\n<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;\"/>\n\n### Docker イメージを codespace にプルする\n\nGitHub 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 はビルド前の作成時には使用できません。\n\ncodespace が実行されると、codespace でターミナルを開き、コマンド `docker pull PRIVATE-IMAGE-URL` を実行できます。\n\n### シークレットの例\n\nAzureのプライベート イメージ レジストリの場合は、次のシークレットを作成できます。\n\n```shell\nACR_CONTAINER_REGISTRY_SERVER = mycompany.azurecr.io\nACR_CONTAINER_REGISTRY_USER = acr-user-here\nACR_CONTAINER_REGISTRY_PASSWORD = <PERSONAL_ACCESS_TOKEN>\n```\n\n一般的なイメージ レジストリについては、「[一般的なイメージ レジストリ サーバー](#common-image-registry-servers)」をご覧ください。 AWS Elastic Container Registry (ECR) へのアクセスは異なることに注意してください。\n\n![リポジトリの \"Codespaces シークレット\" 設定のスクリーンショット。 ACR コンテナー レジストリの 3 つのシークレットが設定されています。](/assets/images/help/codespaces/codespaces-image-registry-secret-example.png)\n\nシークレットを追加したら、新しい環境変数をコンテナーに渡すために、現在の codespace を停止してから開始することが必要になる場合があります。 詳しくは、「[GitHub Codespaces で Visual Studio Code コマンド パレットを使用する](/ja/codespaces/reference/using-the-vs-code-command-palette-in-codespaces#suspending-or-stopping-a-codespace)」をご覧ください。\n\n#### AWS Elastic Container Registry へのアクセス\n\nAWS Elastic Container Registry (ECR) にアクセスするには、AWS アクセス キー ID と秘密鍵を指定できます。 GitHub は、ユーザーの代わりにアクセス トークンを取得してログインできます。\n\n```shell\n*_CONTAINER_REGISTRY_SERVER = <ECR_URL>\n*_CONTAINER_REGISTRY_USER = <AWS_ACCESS_KEY_ID>\n*_CONTAINER_REGISTRY_PASSWORD = <AWS_SECRET_KEY>\n```\n\nまた、資格情報のスワップ (例: `sts:GetServiceBearerToken`) と ECR 読み取り操作 (`AmazonEC2ContainerRegistryFullAccess` または `ReadOnlyAccess`) を実行するための適切な AWS IAM アクセス許可があることを確認する必要があります。\n\nまたは、 GitHub が代わりに資格情報の交換を実行したくない場合は、AWS の API または CLI を使用してフェッチされた承認トークンを提供できます。\n\n```shell\n*_CONTAINER_REGISTRY_SERVER = <ECR_URL>\n*_CONTAINER_REGISTRY_USER = AWS\n*_CONTAINER_REGISTRY_PASSWORD = <TOKEN>\n```\n\nこれらのトークンは有効期間が短く、定期的に更新する必要があるため、アクセス キー ID とシークレットを指定することをお勧めします。\n\n`*_CONTAINER_REGISTRY_SERVER` が ECR URL である限り、これらのシークレットには任意の名前を付けることができますが、複数の ECR レジストリを扱う場合を除き、`ECR_CONTAINER_REGISTRY_*` を使用することをお勧めします。\n\n詳しくは、AWS ECR の[プライベート レジストリ認証に関するドキュメント](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html)を参照してください。\n\n### 一般的なイメージ レジストリ サーバー\n\n一般的なイメージ レジストリ サーバーの一部を次に示します。\n\n* [DockerHub](https://docs.docker.com/engine/reference/commandline/info/) - `https://index.docker.io/v1/`\n* [GitHub コンテナー レジストリ](/ja/packages/working-with-a-github-packages-registry/working-with-the-container-registry) - `ghcr.io`\n* [Azure Container Registry](https://docs.microsoft.com/azure/container-registry/) - `<registry name>.azurecr.io`\n* [AWS Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/Registries.html) - `<aws_account_id>.dkr.ecr.<region>.amazonaws.com`\n* [Google Cloud Container Registry](https://cloud.google.com/container-registry/docs/overview#registries) - `gcr.io` (米国)、`eu.gcr.io` (ヨーロッパ)、`asia.gcr.io` (アジア)\n\n## プライベート イメージ レジストリ アクセスのデバッグ\n\nプライベート イメージ レジストリからイメージをプルするときに問題が発生した場合は、上記で定義したシークレットの値を使用して、`docker login -u <user> -p <password> <server>` を実行できることを確認してください。 ログインに失敗した場合は、ログイン資格情報が有効であること、およびコンテナー イメージをフェッチするためのサーバーに対する適切なアクセス許可があることを確かめます。 ログインに成功した場合は、ユーザー、リポジトリ、または組織レベルで、適切な GitHub Codespaces シークレットにこれらの値が適切にコピーされていることを確認してから、もう一度やり直してください。"}