Skip to main content

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

Dockerレジストリの利用

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

GitHub Packages は、GitHub Free、GitHub Pro、Organization の GitHub Free、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Server 3.0 以降、GitHub AE で利用できます。 GitHub Enterprise Server インスタンスのアップグレードについて詳しくは、「新しいリリースへのアップグレードについて」を参照してく� さい。また、現在のリリース バージョンからのアップグレード パスについては、アップグレード アシスタント を参照してく� さい。

注: サイト管理者はそれぞれのサポートされているパッケージの種類を有効化あるいは無効化できるので、このパッケージの種類はインスタンスで利用できないかもしれません。 詳細については、「エンタープライズ向けのパッケージ サポートの構成」を参照してく� さい。

Dockerサポートについて

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

GitHub Packages への認証を行う

パッケージを発行、インストール、および削除するには、アクセス トークンが必要です。

個人アクセス トークン (PAT) を使用し、GitHub Packages または GitHub Enterprise Server API の認証を受けることができます。 個人トークンを作成する際には、必要に応じて様々なスコープをトークンに割り当てできます。 PAT のパッケージ関連のスコープの詳細については、「GitHub パッケージのアクセス許可について」を参照してく� さい。

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

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

GitHub Actions ワークフローで使用される GITHUB_TOKEN の詳細については、「ワークフローで認証する」を参照してく� さい。

個人アクセストークンでの認証

GitHub Packages内でパッケージを公開及びインストールするためには、適切なスコープで個人アクセストークンを使わなければなりません。 詳しくは、「GitHub Packages について」をご覧く� さい。

docker login コマンドを使い、Docker で GitHub Packages の認証を受けることができます。

クレデンシャルをセキュアに保つために、個人アクセス トークンは自分のコンピューターのローカル ファイルに保存し、ローカル ファイルからトークンを読み取る 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 を の URL に、~/TOKEN.txt を GitHub Enterprise Server の個人アクセス トークンへのファイル パスに置き換えてく� さい。

詳細については、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
    > <� >
    > 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 を のホスト名で、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
  3. ま� パッケージの Docker イメージをビルドしていないならビルドしてく� さい。OWNER をリポジトリを所有するユーザーもしくは Organization アカウントの名前で、REPOSITORY をプロジェクトを含むリポジトリの名前で、IMAGE_NAME をパッケージもしくはイメージの名前で、VERSION をビルド時点のパッケージ バージョンで、HOSTNAME を のホスト名で、もしもイメージが現在の作業ディレクトリ中になければ 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
  4. GitHub Packagesにイメージを公開してく� さい。 インスタンスで Subdomain Isolation が有効になっている� �合:

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

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

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

    ノート: イメージのプッシュは 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 を のホスト名で、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 を使って行ってく� さい。

参考資料