Note
サイト管理者はサポートされている各パッケージの種類を有効または無効にできるので、このパッケージの種類はインスタンスで利用できない可能性があります。 詳しくは、「Enterprise 向けのパッケージエコシステムサポートを設定する」を参照してください。
Dockerサポートについて
Dockerイメージをインストールあるいは公開する際に、Dockerレジストリは現在Windowsイメージのような外部レイヤーをサポートしません。
Docker Engine v25 は、GitHub Enterprise Server の Docker レジストリと互換性がありません。 代わりに Container registry を使用することをお勧めします。 移行については、「Dockeerレジストリからコンテナレジストリへの移行」を参照してください。
GitHub Packages への認証を行う
Note
GitHub Packages では、personal access token (classic)を使用した認証のみがサポートされています。 詳しくは、「個人用アクセス トークンを管理する」を参照してください。
非公開パッケージ、内部パッケージ、公開パッケージを発行、インストール、削除するには、アクセス トークンが必要です。
personal access token (classic) を使って、GitHub Packages または GitHub Enterprise Server API の認証を受けることができます。 personal access token (classic) を作成するときは、必要に応じてさまざまなスコープをトークンに割り当てることができます。 personal access token (classic) のパッケージ関連のスコープの詳細については、「GitHub Packagesの権限について」を参照してください。
GitHub Actionsワークフロー内でGitHub Packagesレジストリに認証を受けるには、以下の方法が使えます。
GITHUB_TOKEN
では、ワークフロー リポジトリに関連付けられているパッケージを発行します。read:packages
以上のスコープが設定された personal access token (classic) では、他のプライベート リポジトリ (GITHUB_TOKEN
ではアクセスできない) に関連付けられているパッケージがインストールされます。
GitHub Actions ワークフローで使われる GITHUB_TOKEN
の詳細については、「自動トークン認証」を参照してください。
personal access token で認証を行う
GitHub Packages でパッケージを発行およびインストールするには、適切なスコープで personal access token (classic) を使う必要があります。 詳しくは、「GitHub Packages の概要」を参照してください。
docker
login コマンドを使い、Docker で GitHub Packages の認証を受けることができます。
資格情報のセキュリティ保護を保つため、personal access tokenは自分のコンピューターのローカル ファイルに保存し、ローカル ファイルからトークンを読み取る Docker の --password-stdin
フラグを使うことをお勧めします。
もしもインスタンスで Subdomain Isolation が有効化されている場合:
cat ~/TOKEN.txt | docker login docker.HOSTNAME -u USERNAME --password-stdin
インスタンスで Subdomain Isolation が無効になっている場合:
cat ~/TOKEN.txt | docker login HOSTNAME -u USERNAME --password-stdin
この例の login コマンドを使うには、USERNAME
を GitHub Enterprise Server のユーザー名 に、HOSTNAME
を お使いの GitHub Enterprise Server インスタンスの URL に、~/TOKEN.txt
を GitHub Enterprise Server のpersonal access tokenへのファイル パスに、それぞれ置き換えます。
詳細については、Docker ログインに関するページを参照してください。
イメージを公開する
Note
GitHub Packages Docker レジストリは、今後の GitHub Enterprise Server リリースで Container registry に置き換えられ、コンテナーのサポートが向上します。
Note
イメージ名には小文字のみを使う必要があります。
GitHub Packages は、リポジトリごとに複数の最上位 Docker イメージをサポートしています。 リポジトリは任意の数のイメージタグを持つことができます。 10GB以上のDockerイメージの公開やインストールの際には、サービスのパフォーマンスが低下するかもしれず、各レイヤーは5GBが上限です。 詳細については、Docker ドキュメントの「Docker tag」(Docker タグ) を参照してください。
パッケージを公開した後は、GitHub上でそのパッケージを見ることができます。 詳しくは、「パッケージの表示」を参照してください。
-
docker images
を使って、Docker イメージのイメージ名と ID を確認してください。$ docker images > < > > REPOSITORY TAG IMAGE ID CREATED SIZE > IMAGE_NAME VERSION IMAGE_ID 4 weeks ago 1.11MB
-
Docker イメージ ID を使って、Docker イメージにタグを付けます。OWNER はリポジトリを所有している個人アカウントまたは Organization の名前に、REPOSITORY はプロジェクトが含まれるリポジトリの名前に、IMAGE_NAME はパッケージまたはイメージの名前に、 HOSTNAME を お使いの GitHub Enterprise Server インスタンス のホスト名に、そして VERSION をビルド時点のパッケージ バージョンに置き換えます。
インスタンスで Subdomain Isolation が有効になっている場合:
docker tag IMAGE_ID docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
インスタンスで Subdomain Isolation が無効になっている場合:
docker tag IMAGE_ID HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
- パッケージの Docker イメージをまだビルドしていない場合は、イメージをビルドします。OWNER をリポジトリを所有している個人アカウントまたは Organization の名前に、REPOSITORY をプロジェクトが含まれるリポジトリの名前に、IMAGE_NAME をパッケージまたはイメージの名前に、VERSION をビルド時点のパッケージ バージョンに、 HOSTNAME を お使いの GitHub Enterprise Server インスタンス のホスト名に、イメージが現在の作業ディレクトリにない場合は PATH をイメージへのパスに置き換えます。
インスタンスで Subdomain Isolation が有効になっている場合:
docker build -t docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
インスタンスで Subdomain Isolation が無効になっている場合:
docker build -t HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
- GitHub Packagesにイメージを公開してください。
インスタンスで Subdomain Isolation が有効になっている場合:
docker push docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
インスタンスで Subdomain Isolation が無効になっている場合:
docker push HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
Note
イメージのプッシュは IMAGE_NAME:SHA
を使うのではなく、IMAGE_NAME:VERSION
を使って行ってください。
Dockerイメージのプッシュの例
この例では、インスタンスの Subdomain Isolation が有効化されていると仮定します。
monalisa
イメージのバージョン 1.0 を、イメージ ID を使って octocat/octo-app
に公開できます。
$ docker images
> REPOSITORY TAG IMAGE ID CREATED SIZE
> monalisa 1.0 c75bebcdd211 4 weeks ago 1.11MB
# Tag the image with OWNER/REPO/IMAGE_NAME
$ docker tag c75bebcdd211 docker.HOSTNAME/octocat/octo-app/monalisa:1.0
# Push the image to GitHub Packages
$ docker push docker.HOSTNAME/octocat/octo-app/monalisa:1.0
新しい Docker イメージを初めて公開し、monalisa
という名前にできます。
# Build the image with docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
# Assumes Dockerfile resides in the current working directory (.)
$ docker build -t docker.HOSTNAME/octocat/octo-app/monalisa:1.0 .
# Push the image to GitHub Packages
$ docker push docker.HOSTNAME/octocat/octo-app/monalisa:1.0
画像のダウンロード
Note
GitHub Packages Docker レジストリは、今後の GitHub Enterprise Server リリースで Container registry に置き換えられ、コンテナーのサポートが向上します。
docker pull
コマンドを使って、Docker イメージを GitHub Packages からインストールできます。OWNER をリポジトリを所有している個人アカウントまたは Organization の名前に、REPOSITORY はプロジェクトが含まれるリポジトリの名前に、IMAGE_NAME をパッケージまたはイメージの名前に、 HOSTNAME を お使いの GitHub Enterprise Server インスタンス のホスト名に、TAG_NAME をインストールするイメージのタグに置き換えます。
インスタンスで Subdomain Isolation が有効になっている場合:
docker pull docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
インスタンスで Subdomain Isolation が無効になっている場合:
docker pull HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:TAG_NAME
Note
イメージをプルするには IMAGE_NAME:SHA
を使うのではなく、IMAGE_NAME:VERSION
を使う必要があります。