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

AWS で GitHub Enterprise Server をインストールする

GitHub Enterprise Server をAmazon Web Services (AWS) にインストールするには、Amazon Elastic Compute Cloud (EC2) インスタンスを起動し、個別の Amazon Elastic Block Store (EBS) データボリュームを作成してアタッチする必要があります。

この記事の内容

前提条件

本ガイドは、読者が以下のAWSの概念に馴染んでいることを前提としています。

アーキテクチャの概要を示す図については、GitHub Enterprise Server のデプロイに関する AWS のアーキテクチャの図を参照してください。

このガイドでは、AWS で お使いの GitHub Enterprise Server インスタンス を設定する際に最小権限の原則を推奨しています。 詳細については、AWS の ID とアクセス管理 (IAM) に関するドキュメントを参照してください。

ハードウェアに関する考慮事項

最小推奨要件

お使いの GitHub Enterprise Server インスタンスのユーザー ライセンス数に応じた様々なハードウェア構成をおすすめします。 最小推奨要件以上のリソースを提供すれば、インスタンスのパフォーマンスとスケーラビリティは向上します。

ユーザー ライセンスx86-64 vCPUsメモリルート ストレージアタッチされた (データ) ストレージ
トライアル、デモ、あるいは10人の軽量ユーザ432 GB200 GB150 GB
10-3000848 GB200 GB300 GB
3000-50001264 GB200 GB500 GB
5000-80001696 GB200 GB750 GB
8000-10000+20160 GB200 GB1000 GB

インスタンスのユーザーに対して GitHub Actions または GitHub Advanced Security を有効にする予定の場合は、さらに多くのリソースが必要です。

  • GitHub Actions - CPU とメモリを 25% 増やします
  • GitHub Advanced Security - CPU とメモリを 15% 増やします

これらの調整は、各ユーザー層の基本要件に適用する必要があります。

これらの要件について詳しくは、「GitHub Enterprise Server の GitHub Actions を使い始める」をご覧ください。

インスタンスのユーザーに対して Container registry を有効にする予定の場合は、さらに多くのリソースが必要です。 これらの要件について詳しくは、「Enterprise 向けの GitHub Packages を使い始める」をご覧ください。

既存インスタンスのリソース調整の詳細については、「ストレージ容量の増加」と「CPUあるいはメモリリソースの増加」を参照してください。

ストレージ

GitHub Enterprise Serverには、高い秒あたりの入出力操作（IOPS）と低いレイテンシを持つ高性能なSSDをおすすめします。 ワークロードはI/O集中的です。 ベアメタルのハイパーバイザを使用するなら、直接アタッチされたディスクか、ストレージエリアネットワーク（SAN）からのディスクを利用することをおすすめします。

インスタンスには、ルートディスクとは別の永続化用のデータディスクが必要です。 詳しくは、「システムの概要」を参照してください。

Warning

ルート ストレージとは、インスタンスのルート ディスクの合計サイズを指します。 インスタンスが起動すると、ルート ファイルシステムで 100 GB は、ルート ファイルシステムで使用できます。 残りの 100 GB はアップグレード用に予約されています。 詳しくは、「システムの概要」を参照してください。

GitHub Actions を構成するには、外部 BLOB ストレージを指定する必要があります。 詳しくは、「GitHub Enterprise Server の GitHub Actions を使い始める」を参照してください。

ルート ファイルシステム上の使用可能な領域は、ディスクの合計サイズの 50% です。 新しいインスタンスを構築するか、既存のインスタンスを利用して、インスタンスのルートディスクのサイズを変更できます。 詳細については、「システムの概要」および「ストレージ容量の増加」を参照してください。

CPU とメモリ

GitHub Enterprise Serverが必要とするCPU及びメモリリソースは、ユーザ、自動化、インテグレーションのアクティビティのレベルによります。

お使いの GitHub Enterprise Server インスタンス用にプロビジョニングしたすべての VM では、x86-64 CPU アーキテクチャを使う必要があります。 AArch64 や arm64 など、他のアーキテクチャはサポートされていません。

GitHub Enterprise Server インスタンスのユーザーに対して GitHub Actions を有効にする予定の場合は、インスタンスに追加の CPU とメモリ リソースをプロビジョニングする必要がある場合があります。 詳しくは、「GitHub Enterprise Server の GitHub Actions を使い始める」を参照してください。

CPU リソースを増やす場合、GitHub は、インスタンスにプロビジョニングする各 vCPU ごとに少なくとも6.5GBのメモリを追加する（最大16vCPUまで）ことをおすすめします。 16以上のvCPUを使う場合は、各vCPUごとに6.5GBのメモリを追加する必要はありませんが、インスタンスが十分なメモリを持っているかをモニターするべきです。

警告: GitHub Enterprise Server 上のアクティビティを外部システムに通知する Webhook イベントを構成することをおすすめします。 変更の自動チェックまたは ポーリング は、インスタンスのパフォーマンスとスケーラビリティに悪影響を与えます。 詳しくは、「webhook について」を参照してください。

GitHub Enterprise Server の容量とパフォーマンスの監視について詳しくは、「インスタンスを監視する」をご覧ください。

インスタンスのCPUあるいはメモリリソースは増やすことができます。 詳しくは、「CPUあるいはメモリリソースの増加」を参照してください。

インスタンスタイプの決定

AWS で お使いの GitHub Enterprise Server インスタンス を起動するには、Organization のニーズに最適なマシン タイプを決定する必要があります。 GitHub Enterprise Server の最小推奨要件を確認するには、「最小推奨要件」を参照してください。

インスタンスをサイズ変更すれば、いつでも CPU やメモリをスケールアップできます。 インスタンスで使用できるリソースを変更するには、ユーザーのダウンタイムが必要であるため、GitHub では、スケーリングを考慮してリソースを過剰プロビジョニングすることをおすすめします。

GitHubは、GitHub Enterprise Serverにメモリ最適化されたインスタンスをおすすめします。 詳細については、Amazon EC2 Web サイトの「Amazon EC2 Instance Types (Amazon EC2 インスタンス タイプ)」を参照してください。

GitHub Enterprise Server AMI を選択する

GitHub Enterprise Server には、GitHub Enterprise Server ポータルまたは AWS CLI を使用することで、Amazon Machine Image (AMI) を選択できます。

GitHub Enterprise Server用のAMIは、AWS GovCloud (US東部およびUS西部) 地域で利用できます。 これにより、特定の規制要件を満たす米国のお客様は、連邦準拠のクラウド環境で GitHub Enterprise Server を実行できます。 AWS の連邦および他の標準への準拠の詳細については、AWS の GovCloud (米国) ページと AWS のコンプライアンス ページを参照してください。

GitHub Enterprise Server を使用して AMI を選択する

  1. 新しいインスタンスに使用するイメージに移動します。

    • [リリース ノート]に移動します。
    • 右側のサイドバーで、ダウンロードするバージョンをクリックします。
    • [GitHub Enterprise Server X.X.X のダウンロード] をクリックします。

  2. [クラウドの GitHub] の下にある [プラットフォームの選択] ドロップダウン メニューを選択し、 [アマゾン ウェブ サービス] をクリックします。

  3. [AWS のリージョンの選択] ドロップダウン メニューを選択し、希望するリージョンをクリックします。

  4. 表示されたAMI IDをメモしておいてください。

AWS CLIを使ったAMIの選択

  1. AWS CLI を使用して、GitHub の AWS オーナー ID (GovCloud の場合は 025577942450、他のリージョンの場合は 895557238572) によって公開されている GitHub Enterprise Server のイメージのリストを取得します。 詳細については、AWS のドキュメントの「describe-images」を参照してください。

    aws ec2 describe-images \
--owners OWNER_ID \
--query 'sort_by(Images,&Name)[*].{Name:Name,ImageID:ImageId}' \
--output=text

  2. 最新の GitHub Enterprise Server イメージ用の AMI ID をメモしておきます。

セキュリティ グループの作成

AMI を初めてセットアップする場合は、セキュリティグループを作成し、下記の表にある各ポートに関する新しいセキュリティグループのルールを追加する必要があります。 詳細については、セキュリティ グループの使用に関する AWS のガイドを参照してください。

  1. AWS CLI を使用して、新しいセキュリティグループを作成します。 詳細については、AWS のドキュメントの「create-security-group」を参照してください。

    aws ec2 create-security-group --group-name SECURITY_GROUP_NAME --description "SECURITY GROUP DESCRIPTION"

  2. 新しく作成したセキュリティ グループのセキュリティ グループ ID (sg-xxxxxxxx) を書き留めておきます。

  3. 下記の表にある各ポートに関するセキュリティグループのルールを作成します。 管理とユーザーのために公開する必要があるネットワーク サービスに基づいて、開くネットワーク ポートを選ぶことをお勧めします。 詳細については、「ネットワーク ポート」と、AWS のドキュメントの「authorize-security-group-ingress」を参照してください。

    aws ec2 authorize-security-group-ingress --group-id SECURITY_GROUP_ID --protocol PROTOCOL --port PORT_NUMBER --cidr SOURCE IP RANGE

    次の表に、各ポートの使用目的を示します

    Portサービス説明
    22SSHGit over SSHのアクセス。 パブリック／プライベートリポジトリのクローン、フェッチ、プッシュ操作がサポートされています。
    25SMTP暗号化（STARTTLS）付きのSMTPサポート。
    80HTTPWebアプリケーションへのアクセス。 SSL が有効になっている場合、すべての要求は HTTPS ポートにリダイレクトされます。
    122SSHインスタンスのシェルへのアクセス。 既定の SSH ポート (22) は、アプリケーションの git+ssh ネットワーク トラフィック専用です。
    161/UDPSNMPネットワークモニタリングプロトコルの処理に必要。
    443HTTPSWebアプリケーション及びGit over HTTPSのアクセス。
    1194/UDPVPNHigh Availability設定でのセキュアなレプリケーションネットワークトンネル。 WireGuard を使用して暗号化されます。
    8080HTTPプレーンテキストの Webベースの [Management Console]。 SSL を手動で無効にしない限り必要ありません。
    8443HTTPSセキュアな Webベースの [Management Console]。 基本的なインストールと設定に必要です。
    9418GitシンプルなGitプロトコルのポートです。 パブリックリポジトリのクローンとフェッチのみができます。 暗号化されていないネットワーク通信。 インスタンスでプライベートモードを有効化した場合、このポートをオープンする必要があるのは、匿名Git読み取りアクセスも有効化している場合のみです。 詳しくは、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

GitHub Enterprise Server インスタンスを作成する

インスタンスを作成するには、GitHub Enterprise Server AMI を使用して EC2 インスタンスを起動し、インスタンスデータ用の追加のストレージボリュームをアタッチする必要があります。 詳細については、「ハードウェアに関する考慮事項」を参照してください。

Note

データ ディスクを暗号化してセキュリティを強化し、インスタンスに書き込むデータを確実に保護することができます。 暗号化ディスクを使用すると、パフォーマンスにわずかな影響が生じます。 ボリュームを暗号化する場合は、インスタンスを初めて起動する前にそれを行うことを強くお勧めします。 詳細については、EBS 暗号化に関する Amazon のガイドを参照してください。

Warning

インスタンスを構成した後で暗号化を有効にする場合は、データを暗号化されたボリュームに移行する必要があり、ユーザーに若干のダウンタイムが発生します。

EC2 インスタンスの起動

AWS CLI で、AMI および作成したセキュリティグループを使用して EC2 インスタンスを起動します。 インスタンスデータ用にストレージボリュームとして使うための新しいブロックデバイスをアタッチし、サイズをユーザライセンス数に基づいて設定してください。 詳細については、AWS のドキュメントの「run-instances」を参照してください。

aws ec2 run-instances \
  --security-group-ids SECURITY_GROUP_ID \
  --instance-type INSTANCE_TYPE \
  --image-id AMI_ID \
  --block-device-mappings '[{"DeviceName":"/dev/xvdf","Ebs":{"VolumeSize":SIZE,"VolumeType":"TYPE"}}]' \
  --region REGION \
  --ebs-optimized

Elastic IP を割り当ててとインスタンスに関連付ける

これが本番インスタンスである場合は、GitHub Enterprise Server の設定に進む前に、Elastic IP (EIP) を割り当ててそれをインスタンスに関連付けることを強くおすすめします。 そうしなければ、インスタンスのパブリック IP アドレスはインスタンスの再起動後に保持されません。 詳細については、Amazon のドキュメントのエラスティック IP アドレスの割り当ておよび実行中のインスタンスへのエラスティック IP アドレスの関連付けに関するページを参照してください。

稼働状態の High Availability 設定では、プライマリインスタンスとレプリカインスタンスの両方に別々の EIP を割り当ててください。 詳しくは、「高可用性の構成」を参照してください。

GitHub Enterprise Server インスタンスを設定する

インスタンスを構成するには、ライセンス ファイルのアップロード、ルート[Management Console] パスワードの設定、インスタンスの設定の構成、インスタンスの再起動を行う必要があります。

警告: 攻撃者が新しいインスタンスを侵害できないようにするには、自分だけが知っている ルート [Management Console] パスワードを設定して、最初のユーザーをできるだけ早く作成してください。

  1. 仮想マシンのパブリックDNS名をコピーして、Webブラウザに貼り付けてください。
  2. プロンプトでライセンスファイルをアップロードし、管理コンソールのパスワードを設定してください。 詳しくは、「GitHub Enterpriseのライセンス管理」を参照してください。
  3. [Management Console] で、目的の設定を構成して保存します。 詳しくは、「GitHub Enterprise を設定する」をご覧ください。
  4. インスタンスは自動的に再起動します。
  5. [Visit your instance](インスタンスにアクセスする) をクリックします。

参考資料