Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-03-26. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

Dockerレジストリの利用

GitHub Packages Dockerレジストリを使ってDockerイメージをプッシュやプルできます。

注: サイト管理者はそれぞれのサポートされているパッケージの種類を有効化あるいは無効化できるので、このパッケージの種類はインスタンスで利用できないかもしれません。 詳しくは、「Enterprise 向けのパッケージエコシステムサポートを設定する」を参照してください。

Dockerサポートについて

Dockerイメージをインストールあるいは公開する際に、Dockerレジストリは現在Windowsイメージのような外部レイヤーをサポートしません。

GitHub Packages への認証を行う

非公開パッケージ、内部パッケージ、公開パッケージを発行、インストール、削除するには、アクセス トークンが必要です。

personal access token を使って、GitHub Packages または GitHub Enterprise Server API の認証を受けることができます。 personal access token を作成するときは、必要に応じてさまざまなスコープをトークンに割り当てることができます。 personal access token のパッケージ関連のスコープの詳細については、「GitHub Packagesの権限について」を参照してください。

GitHub Actionsワークフロー内でGitHub Packagesレジストリに認証を受けるには、以下の方法が使えます。

  • GITHUB_TOKEN では、ワークフロー リポジトリに関連付けられているパッケージを発行します。
  • read:packages 以上のスコープが設定された personal access token では、他のプライベート リポジトリ (GITHUB_TOKEN ではアクセスできない) に関連付けられているパッケージがインストールされます。

GitHub Actions ワークフローで使われる GITHUB_TOKEN の詳細については、「自動トークン認証」を参照してください。

personal access token で認証を行う

GitHub Packages でパッケージを発行およびインストールするには、適切なスコープで personal access token を使う必要があります。 詳しくは、「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 ログインに関するページを参照してください。

イメージを公開する

注: GitHub Packages Docker レジストリは、今後の GitHub Enterprise Server リリースで Container registry に置き換えられ、コンテナーのサポートが向上します。

注釈: イメージ名には小文字のみを使用する必要があります。

GitHub Packages は、リポジトリごとに複数の最上位 Docker イメージをサポートしています。 リポジトリは任意の数のイメージタグを持つことができます。 10GB以上のDockerイメージの公開やインストールの際には、サービスのパフォーマンスが低下するかもしれず、各レイヤーは5GBが上限です。 詳しくは、Docker ドキュメントの「Docker タグ」を参照してください。

パッケージを公開した後は、GitHub上でそのパッケージを見ることができます。 詳しくは、「パッケージの表示」を参照してください。

  1. docker images を使って、Docker イメージのイメージ名と ID を確認してください。

    $ docker images
    > <&nbsp>
    > REPOSITORY        TAG        IMAGE ID       CREATED      SIZE
    > IMAGE_NAME        VERSION    IMAGE_ID       4 weeks ago  1.11MB
    
  2. 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
  1. パッケージの 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
  1. GitHub Packagesにイメージを公開してください。

インスタンスで Subdomain Isolation が有効になっている場合:

docker push docker.HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION

インスタンスで Subdomain Isolation が無効になっている場合:

docker push HOSTNAME/OWNER/REPOSITORY/IMAGE_NAME:VERSION
 <div class="ghd-alert ghd-alert-accent ghd-spotlight-accent">

ノート: イメージのプッシュは 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

画像のダウンロード

注: 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

ノート: イメージのプルは IMAGE_NAME:SHA を使うのではなく、IMAGE_NAME:VERSION を使って行ってください。

参考資料