前提条件
- GitHub Enterpriseのライセンスファイルを持っていなければなりません。 詳しくは、「GitHub Enterprise Server の試用版を設定する」と「GitHub Enterprise のライセンスについて」をご覧く� さい。
- EC2 インスタンスを起動してEBS ボリュー� を作成できる AWS アカウントを所有している必要があります。 詳細については、アマゾン ウェブ サービスの Web サイトを参照してく� さい。
- の起動に必要なほとんどのアクションは、AWS 管理コンソールを使って実行することもできます。 とはいえ、初期のセットアップのためにAWSコマンドラインインターフェース(CLI)をインストールすることをおすすめします。 AWS CLIの使用例は以下にあります。 詳細については、Amazon の AWS 管理コンソールの操作および AWS コマンド ライン インターフェイスの概要に関するガイドを参照してく� さい。
注: 現時点では、GitHub Enterprise Server では Amazon IDMSv2 メタデータ API の使用はサポートされていません。
本ガイドは、読者が以下のAWSの概念に馴染んでいることを前提としています。
- EC2 インスタンスの起動
- EBS ボリュー� の管理
- セキュリティ グループの使用 (インスタンスへのネットワーク アクセスを管理する� �合)
- エラスティック IP アドレス (EIP) (運用環境では強くお勧めします)
- EC2 と仮想プライベート クラウド (仮想プライベート クラウドでの起動を計画している� �合)
- AWS の価� � (コストを計算して管理する� �合)
アーキテクチャの概要については、GitHub Enterprise Server のデプロイに関する AWS のアーキテクチャの図を参照してく� さい。
このガイドでは、AWS で を設定する際に最小権限の原則を推奨しています。 詳細については、AWS の ID とアクセス管理 (IAM) に関するドキュメントを参照してく� さい。
ハードウェアに関する考慮事� �
最小要件
のユーザライセンス数に応じた様々なハードウェア構成をおすすめします。 最小要件以上のリソースを提供すれば、インスタンスのパフォーマンスとスケーラビリティは向上します。
ユーザー ライセンス | vCPU 数 | メモリ | ルート ストレージ | アタッチされた (データ) ストレージ |
---|---|---|---|---|
トライアル、デモ、あるいは10人の軽量ユーザ | 4 | 32 GB | 200 GB | 150 GB |
10-3000 | 8 | 48 GB | 200 GB | 300 GB |
3000-5000 | 12 | 64 GB | 200 GB | 500 GB |
5000-8000 | 16 | 96 GB | 200 GB | 750 GB |
8000-10000+ | 20 | 160 GB | 200 GB | 1000 GB |
インスタンスのユーザーに対して GitHub Actions を有効にする予定の� �合は、さらに多くのリソースが必要です。
vCPU 数 | メモリ | 最大コンカレンシー |
---|---|---|
8 | 64 GB | 300 ジョブ |
16 | 128 GB | 700 ジョブ |
32 | 160 GB | 1,300 ジョブ |
64 | 256 GB | 2,000 ジョブ |
96 | 384 GB | 4,000 ジョブ |
これらの要件の詳細については、「GitHub Enterprise Server の GitHub Actions の概要」を参照してく� さい。
既存のインスタンスのリソースの調整の詳細については、「ストレージ容量の増� 」および「CPU またはメモリ リソースの増� 」を参照してく� さい。
ストレージ
GitHub Enterprise Serverには、高い秒あたりの入出力操作(IOPS)と低いレイテンシを持つ高性能なSSDをおすすめします。 ワークロードはI/O集中的です。 ベアメタルのハイパーバイザを使用するなら、直接アタッチされたディスクか、ストレージエリアネットワーク(SAN)からのディスクを利用することをおすすめします。
インスタンスには、ルートディスクとは別の永続化用のデータディスクが必要です。 詳細については、「システ� の概要」をご覧く� さい。
GitHub Actions を構成するには、外部 BLOB ストレージを指定する必要があります。 詳細については、「GitHub Enterprise Server の GitHub Actions の概要」を参照してく� さい。
ルート ファイルシステ� 上の使用可能な� �域は、ディスクの合計サイズの 50% です。 新しいインスタンスを構築するか、既存のインスタンスを利用して、インスタンスのルートディスクのサイズを変更できます。 詳細については、「システ� の概要」および「ストレージ容量の増� 」を参照してく� さい。
CPU とメモリ
GitHub Enterprise Serverが必要とするCPU及びメモリリソースは、ユーザ、自動化、インテグレーションのアクティビティのレベルによります。
GitHub Enterprise Server インスタンスのユーザーに対して GitHub Actions を有効にする予定の� �合は、インスタンスに追� の CPU とメモリ リソースをプロビジョニングする必要がある� �合があります。 詳細については、「GitHub Enterprise Server の GitHub Actions の概要」を参照してく� さい。
CPUリソースを増やす� �合、インスタンスにプロビジョニングする各vCPUごとに少なくとも6.5GBのメモリを追� する(最大16vCPUまで)ことをおすすめします。 16以上のvCPUを使う� �合は、各vCPUごとに6.5GBのメモリを追� する必要はありませんが、インスタンスが十分なメモリを持っているかをモニターするべきです。
警告: GitHub Enterprise Server 上のアクティビティを外部システ� に通知する Webhook イベントを構成することをおすすめします。 変更の自動チェックまたは ポーリング は、インスタンスのパフォーマンスとスケーラビリティに悪影響を与えます。 詳細については、「Webhook について」を参照してく� さい。
GitHub Enterprise Server の容量とパフォーマンスの監視の詳細については、「アプライアンスを監視する」を参照してく� さい。
インスタンスのCPUあるいはメモリリソースは増やすことができます。 詳細については、「CPU またはメモリ リソースの増� 」を参照してく� さい。
インスタンスタイプの決定
AWS で を起動する前に、Organization のニーズに最適なマシンタイプを決定する必要があります。 GitHub Enterprise Server の最小要件を確認するには、「最小要件」を参照してく� さい。
注: インスタンスをサイズ変更すれば、いつでも CPU やメモリをスケールアップできます。 しかし、CPUあるいはメモリのリサイズにはユーザにとってのダウンタイ� が生じるので、スケールのためのリソースを前もってオーバープロビジョニングしておくことをおすすめします。
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 を選択する
-
新しいインスタンスに使用するイメージに移動します。
- [リリース ノート]に移動します。
- 右側のサイドバーで、ダウンロードするバージョンをクリックします。
- [GitHub Enterprise Server X.X.X のダウンロード] をクリックします。
-
[クラウドの GitHub] の下にある [プラットフォー� の選択] ドロップダウン メニューを選択し、 [アマゾン ウェブ サービス] をクリックします。
-
[AWS のリージョンの選択] ドロップダウン メニューを選択し、希望するリージョンをクリックします。
-
表示されたAMI IDをメモしておいてく� さい。
AWS CLIを使ったAMIの選択
- 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
- 最新の GitHub Enterprise Server イメージ用の AMI ID をメモしておきます。
セキュリティ グループの作成
AMI を初めてセットアップする� �合は、セキュリティグループを作成し、下記の表にある各ポートに関する新しいセキュリティグループのルールを追� する必要があります。 詳細については、セキュリティ グループの使用に関する AWS のガイドを参照してく� さい。
-
AWS CLI を使用して、新しいセキュリティグループを作成します。 詳細については、AWS のドキュメントの "create-security-group" を参照してく� さい。
$ aws ec2 create-security-group --group-name SECURITY_GROUP_NAME --description "SECURITY GROUP DESCRIPTION"
-
新しく作成したセキュリティ グループのセキュリティ グループ ID (
sg-xxxxxxxx
) を書き留めておきます。 -
下記の表にある各ポートに関するセキュリティグループのルールを作成します。 詳細については、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 サービス 説明 22 SSH Git over SSHのアクセス。 パブリック/プライベートリポジトリのクローン、フェッチ、プッシュ操作がサポートされています。 25 SMTP 暗号化(STARTTLS)付きのSMTPサポート。 80 HTTP Webアプリケーションへのアクセス。 SSL が有効になっている� �合、すべての要求は HTTPS ポートにリダイレクトされます。 122 SSH インスタンスのシェルへのアクセス。 既定の SSH ポート (22) は、アプリケーションの git+ssh ネットワーク トラフィック専用です。 161/UDP SNMP ネットワークモニタリングプロトコルの処理に必要。 443 HTTPS Webアプリケーション及びGit over HTTPSのアクセス。 1194/UDP VPN High Availability設定でのセキュアなレプリケーションネットワークトンネル。 8080 HTTP プレーンテキストの Webベースの [Management Console]。 SSL を手動で無効にしない限り必要ありません。 8443 HTTPS セキュアな Webベースの [Management Console]。 基本的なインストールと設定に必要です。 9418 Git シンプルなGitプロトコルのポートです。 パブリックリポジトリのクローンとフェッチのみができます。 暗号化されていないネットワーク通信。 インスタンスでプライベートモードを有効化した� �合、このポートをオープンする必要があるのは、匿名Git読み取りアクセスも有効化している� �合のみです。 詳細については、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してく� さい。
GitHub Enterprise Server インスタンスを作成する
インスタンスを作成するには、GitHub Enterprise Server AMI を使用して EC2 インスタンスを起動し、インスタンスデータ用の追� のストレージボリュー� をアタッチする必要があります。 詳細については、「ハードウェアに関する考慮事� �」を参照してく� さい。
注: データ ディスクを暗号化してセキュリティを強化し、インスタンスに書き込むデータを確実に保護することができます。 暗号化ディスクを使用すると、パフォーマンスにわずかな影響が生じます。 ボリュー� を暗号化する� �合は、インスタンスを初めて起動する 前に それを行うことを強くお勧めします。 詳細については、EBS 暗号化に関する Amazon のガイドを参照してく� さい。
警告: インスタンスを構成した後で暗号化を有効にする� �合は、データを暗号化されたボリュー� に移行する必要があり、ユーザーに若干のダウンタイ� が発生します。
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 の構成に関するページを参照してく� さい。
GitHub Enterprise Server インスタンスを設定する
- 仮想マシンのパブリックDNS名をコピーして、Webブラウザに貼り付けてく� さい。 2. プロンプトでライセンスファイルをアップロードし、管理コンソールのパスワードを設定してく� さい。 詳細については、「GitHub Enterprise のライセンスの管理」を参照してく� さい。 3. [Management Console] で、目的の設定を構成して保存します。 詳細については、GitHub Enterprise Server アプライアンスの構成に関するページを参照してく� さい。
- インスタンスは自動的に再起動します。 1. [Visit your instance](インスタンスにアクセスする) をクリックします。