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

Enterprise 向けの GitHub Packages を使い始める

この機能の有効化、サードパーティのストレージの設定、サポートするエコシステムの設定、TLS 証明書の更新を行い、お使いの GitHub Enterprise Server インスタンス で GitHub Packages の使用を開始します。

この機能を使用できるユーザーについて

Site administrators can enable and configure GitHub Packages.

この記事の内容

Note

GitHub Enterprise Server 上の GitHub Packages は、現在クラスタリングをサポートしていません。

ステップ 1: 企業で GitHub Packages が利用できるか確認する

GitHub Packages は GitHub Enterprise Server 3.0 以降で利用できます。 以前のバージョンの GitHub Enterprise Server を使用している場合は、GitHub Packages を使用するようにアップグレードする必要があります。 GitHub Enterprise Server インスタンスのアップグレードについて詳しくは、「新しいリリースへのアップグレードについて」をご覧ください。

ステップ 2: ハードウェア要件を確認する

インスタンスのユーザーに対して Container registry を有効にする予定の場合、少なくともさらに 10% 多くの CPU リソースが必要になります。

ユーザーのアクティビティ レベルとインスタンスの自動化を見直し、ユーザーに適切な CPU をプロビジョニングしていることを確認することをお勧めします。 詳しくは、「インスタンスを監視する」をご覧ください。

お使いの GitHub Enterprise Server インスタンス の最小ハードウェア要件について詳しくは、インスタンスのプラットフォームのハードウェアに関する考慮事項をご覧ください。

既存インスタンスのリソース調節について詳しくは、「CPUあるいはメモリリソースの増加」をご覧ください。

ステップ 3: GitHub Packages を有効化して外部ストレージを設定する

GitHub Enterprise Server 上の GitHub Packages は、外部の blob ストレージを使用してパッケージを保存します。

お使いの GitHub Enterprise Server インスタンス に対して GitHub Packages を有効にした後、サードパーティのストレージ バケットを準備する必要があります。 必要なストレージ容量は、GitHub Packages の使用状況によって異なり、セットアップガイドラインはストレージプロバイダによって異なる場合があります。

サポートされている外部ストレージプロバイダ

  • アマゾン ウェブ サービス (AWS) S3
  • Azure Blob Storage
  • MinIO

GitHub Packages を有効にしてサードパーティのストレージを設定するには、以下を参照してください。

ステップ 4: インスタンスでサポートするパッケージエコシステムを指定する

お使いの GitHub Enterprise Server インスタンス で有効、無効、または読み取り専用に設定するパッケージ エコシステムを選びます。 使用可能なオプションは、Container registry、Docker、RubyGems、npm、Apache Maven、Gradle、または NuGet です。詳しくは、「Enterprise 向けのパッケージエコシステムサポートを設定する」をご覧ください。

ステップ 5: パッケージホスト URL に TLS 証明書があることを確認する (必要に応じて)

お使いの GitHub Enterprise Server インスタンス に対してサブドメイン分離が有効になっている場合、containers.HOSTNAME など、使いたいエコシステムごとにパッケージ ホスト URL を許可する TLS 証明書を作成してアップロードする必要があります。 各パッケージ ホスト URL に https:// が含まれていることを確認します。

手動で証明書を作成するか、Let's Encrypt を使用できます。 既に Let's Encrypt を使用している場合は、GitHub Packages を有効にしてから新しい TLS 証明書をリクエストする必要があります。 パッケージ ホスト URL について詳しくは、「Subdomain Isolationの有効化」をご覧ください。 GitHub Enterprise Server への TLS 証明書のアップロードについて詳しくは、「TLSの設定」をご覧ください。

ステップ 6: 予約名を確認して名前を変更する

サブドメイン分離が無効になっている Docker エコシステムを使う場合は、[Management Console] で Docker エコシステムのサポートを有効にする前に、まず お使いの GitHub Enterprise Server インスタンス で v2 というユーザーまたは Organization の名前を変更する必要があります。 Docker では、v2 アカウント名を使って Docker API とのパスの競合を管理します。この名前は、Docker レジストリのサポートが有効になると使えなくなります。

サイト管理者ダッシュボードの [予約済みログイン] ページに移動すると、内部使用のために予約されたログインの完全な一覧を確認できます。 詳しくは、「Web UI からインスタンスを管理する」をご覧ください。