Skip to main content

Enterprise Server 3.15 は、現在リリース候補として使用できます。

Dockerレジストリの利用

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

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

Dockerサポートについて

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

Docker Engine v25 は、GitHub Enterprise Server の Docker レジストリと互換性がありません。 代わりに Container registry を使用することをお勧めします。 移行については、「Dockeerレジストリからコンテナレジストリへの移行」を参照してください。

GitHub Packages への認証を行う

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 ログインに関するページを参照してください。

イメージを公開する

注: 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 を使って行ってください。

参考資料