GitHub EnterpriseをAWSで使おう – マネジメントコンソール編

GitHub Enterprise on AWS Cloud

#AWS

#GitHub

knakayama

2016.10.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

こんにちは、中山です。

GitHub Enterprise(以下GHE) on AWSシリーズの第2弾です。1回目はAWSへのインストール方法を解説しました。まだ利用したことがない方は一度読んでみていただければと思います。

GitHub EnterpriseをAWSで使おう - インストール編

GHEには管理者用インタフェースが2つ用意されています。WebベースのマネジメントコンソールとCLIツールを利用したSSHアクセスです。今回はGUIで操作するマネジメントコンソールについてご紹介します。

マネジメントコンソールとは

Webベースで操作可能な管理者用ページです。「https://<hostname>/setup」にアクセスすると8443番ポートにリダイレクトされ表示されます。推奨されないですが、HTTPを利用している場合は「http://<hostname>/setup」です。アクセスすると、以下のように管理者用パスワードの入力を求められます。

ghe2-1

パスワードを入力すると設定画面が表示されます。

ghe2-2

以下ではこのマネジメントコンソールで設定可能な項目(「Settings」タブの内容)について解説します。注意点として、現時点(2016年10月26日)の最新バージョンである2.7を前提とします。バージョンが変わった場合は情報が異なる可能性があるので、利用される際には常に最新の情報を参照するようにしてください。

GHEのドキュメントはバージョン毎にURLを変えて作成されています。例えば2.7用ドキュメントのURLは以下のようになります。

https://help.github.com/enterprise/2.7/

そのため参照するドキュメントは自分が利用しているバージョンと合っているかに注意する必要があります。

それでは、それぞれの内容についてご紹介します。各種詳細な情報は以下のドキュメントにまとまっています。ご利用される際はドキュメントも参照してください。

GitHub Enterprise Setup and Configuration Guide

Change password

マネジメントコンソールにログインする際のパスワードを変更する項目です。リンクが記載されているのでそれをクリックすれば以下のようにパスワード変更画面が表示されます。

ghe2-3

SSH access

SSHアクセス時に利用する公開鍵を登録する項目です。「Add new SSH key」に公開鍵をペーストして「Add key」を押下すればadminの ~/.ssh/authorized_keys に反映されます。GHEのSSH用ポートは122番なのでご注意ください。22番はgit+sshで利用されます。

ghe2-4

マネジメントコンソールで設定する項目は基本的に画面上部にある「Save settings」を押下してアプリケーションの再起動をする必要があるのですが、この項目はそういったことをせず即時で反映されます。

Hostname

GHEインスタンスへアクセスする際のホスト名を設定する項目です。基本的にIPアドレスではなくホスト名でアクセスできるようにしましょう。後述しますが特別な理由がない限り「Subdomain Isolation」を有効にしてください。

ghe2-5

今回はDNSにRoute53を利用したawscliでの設定例をご紹介します。Hosted Zoneはすでに取得している前提で進めます。

まずは登録するホスト名を正常に正引きできるように新規でレコードセットを作成します。以下のようなJSONファイルを用意してください。「_YOUR_...」となっている部分は自分の環境に合うよう変更してください。注意点としてインバウンド用のMXレコードは「reply.<hostname>」となります。

{
  "Comment": "Create record sets for GHE",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_YOUR_A_RECORD_",
        "Type": "A",
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "_YOUR_GHE_PUBLIC_IP_"
          }
        ]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "reply._YOUR_A_RECORD_",
        "Type": "MX",
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "_YOUR_PRIORITY_ _YOUR_GHE_PUBLIC_IP_"
          }
        ]
      }
    }
  ]
}

続いてレコードセットを作成します。Hosted Zone Idはご自身のものに変更してください。

$ aws route53 change-resource-record-sets \
  --hosted-zone-id <HOSTED-ZONE-ID> \
  --change-batch file://path/to/json
{
    "ChangeInfo": {
        "Status": "PENDING",
        "Comment": "Create record sets for GHE",
        "SubmittedAt": "2016-10-22T05:19:43.412Z",
        "Id": "/change/**************"
    }
}

しばらく待てばホスト名を正引きできるようになります。作成したレコードをペーストした後、「Test domain settings」を押下すれば正常に正引き可能かチェックすることができます。ホスト名を変更する際は事前にチェックすることをオススメいたします。

ghe2-6

続いてSubdomain Isolationについて解説します。この設定を有効にするとパスベースではなくサブドメインで各種ページにアクセスできるため、同一オリジンポリシーによりクロスサイト・スクリプティングなどの対策として有効に動作します。何らかの理由で無効化する場合は「GitHub Enterprise Pages」も無効化することが推奨されています。詳細はこちらのドキュメントを参照してください。

有効化すると以下のようにサブドメイン形式でアクセスできるようになります。

Original Path	With subdomain isolation
http(s)://hostname/assets/	http(s)://assets.hostname/

2.7で試した限りでは以下の設定でDNSに登録する必要があるようです(この内「gist-assets」と「gist-raw」はマネジメントコンソールには表示されないようですが、上記ドキュメントには登録する必要がある旨、書かれています)。replyはインバウンドのメール用に利用するので、もし利用しないのであれば特に設定は不要です。

レコード	レコードタイプ
<hostname>	A
reply.<hostname>	MX
reply.<hostname>	A
assets.<hostname>	A
raw.<hostname>	A
codeload.<hostname>	A
gist.<hostname>	A
gist-assets.<hostname>	A
gist-raw.<hostname>	A
uploads.<hostname>	A
render.<hostname>	A
pages.<hostname>	A
media.<hostname>	A
avatars.<hostname>	A

一つ一つ登録することも可能ですが、数が多いのでワイルドカード形式(*.<hostname>)でDNSに登録されることをオススメいたします。awscliで登録する場合は以下のようなJSONファイルを用意して先程と同じようにレコードセットを作成すればOKです。

{
  "Comment": "Create record sets for GHE",
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_YOUR_A_RECORD_",
        "Type": "A",
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "_YOUR_GHE_PUBLIC_IP_"
          }
        ]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "reply._YOUR_A_RECORD_",
        "Type": "MX",
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "_YOUR_PRIORITY_ _YOUR_GHE_PUBLIC_IP_"
          }
        ]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "*._YOUR_A_RECORD_",
        "Type": "A",
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "_YOUR_GHE_PUBLIC_IP_"
          }
        ]
      }
    }
  ]
}

上記設定後「Test domain settings」を押下すると以下のように正常に正引きできた旨、表示されます。

ghe2-7

Time

どのNTPサーバと同期するかを設定する項目です。デフォルトではUbuntuで利用されているNTPサーバが指定されています。特定のサーバに変更したいなど理由があれば変更してください。

ghe2-8

Authentication

GHE上のユーザをどのような方法で管理するかを指定する項目です。組織によってはすでにユーザ情報をLDAPなどを利用している場合、既存のユーザ情報と連携できるので利便性が向上すると思われます。ユーザ情報はデフォルトでインスタンス上に保存されます。

ghe2-8

Privacy

セキュリティ関連の設定を行う項目です。少し長いですが全体の設定画面を貼り付けます。

ghe2-9-3

SSL only

特別な理由がない限り必ず有効にしてください。デフォルトではGHEが自動で生成した自己証明書が利用されるので、変更する必要があります。また、こちらのドキュメントに書かれていますが、SSLターミネーションをELBなどのロードバランサで実施することはサポートされていません。インスタンスに直接証明書をアップロードする必要があります。

Subdomain Isolationを有効化している場合は注意点があります。GHEのホスト名に指定したドメインとそのサブドメイン両方とも利用するという性質上、ワイルドカード証明書ではなくSANs(Subject Alternative Names)に対応したマルチドメイン証明書を指定する必要があります。

Private Mode

このモードが有効になっているとGHE上にアカウントを取得していないユーザに対して、パブリックなリポジトリをgitプロトコルでcloneできなくさせます。また、デフォルトの認証が利用されている限り、アカウントを発行されないとログインできません。こちらのFAQに記載されているように、GHEは基本的に閉じた組織内で利用することを想定しているので有効化することが推奨されています。

Enable sign-up

こちらはPrivate Modeとは逆の設定です。GHEにアクセス可能なユーザは新規アカウントを作成したり、gitプロトコルを利用したcloneが可能です。特別な理由がない限り無効化しておきましょう。もし有効化する場合はPrivate Modeを無効化しておく必要があります。

Proxy

GHEから送信されるトラフィック(Webhookやbundleのアップロードなど)がここで指定したプロキシを経由して送信されます。ただし、Excludeに登録したホストに対してはその限りではありません。

GeoJSON

GeoJSONファイルのdiffを取るかどうかのようです。

Pages

GHE用GitHub Pagesの設定項目です。この設定はSubdomain Isolationを無効化している場合は利用しないでください。

ghe2-10

「Public Pages」とはPrivate Modeが有効になっていてもGitHub Pagesをパブリックに公開するかどうかの設定です。デフォルトでは無効化されています。

Email

メールの設定です。ここでSMTPサーバの設定をするとメールを利用した通知が可能になります。メールの受信を有効にする場合は25番ポートの開放とDNSの設定が必要になります。

ghe2-11

こちらについては別エントリにまとめてご紹介したいと思います。

2016年10月27日追記
Amazon SESを利用したEmail Notificationの設定方法をエントリにまとめました。もしよろしければ読んでいただければと思います。

Monitoring

GHEから各種メトリクスを収集するための設定です。

ghe2-12

SNMP

GHEはSNMPでインスタンスのリソースを取得できます。マネジメントコンソールからコミュニティ名を指定できるので、今回適当な文字列を入れて取得できるか試してみました。デフォルト値はpublicです。

ghe2-13

ローカルのPCから値を取得してみましたが、正常に値が取得できるようです。

$ snmpget -v 2c -c test -O e <hostname> system.sysDescr.0
SNMPv2-MIB::sysDescr.0 = STRING: Linux ****************************** 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64

Enable log forwarding

syslog-ngを利用してGHE上のログを外部サーバに転送可能です。TCPとUDPが選択可能ですが、TCPの場合正常にログの転送ができないとGHEが反応なくなるようなのでUDPが推奨されています。

今回は、GHEと同じVPC内にlogstashをインストールしたインスタンスを構築して、正常にログが転送されているかを確認してみました。以下のように「Enable log forwarding」にチェックを入れるとログ転送用インスタンスのホスト名とプロトコルが指定できるので入力します。

ghe2-14-2

「Save settings」を押下するとGHE上でsyslog-ngがログの転送を開始します。UDPを選択した場合は514番ポートが利用されるので、logstashをインストールしたインスタンス上で以下のようにログのフォワードを待ち受けてみると正常に動作しているか確認できます。

$ sudo /opt/logstash/bin/logstash -e 'input { udp { port => 514 } } output { stdout {} }'
Settings: Default pipeline workers: 1
Pipeline main started
2016-10-22T10:53:41.165Z 172.31.28.45 <45>Oct 22 10:52:41 ****************************** syslog-ng[26429]: Syslog connection broken; fd='46', server='AF_INET(172.31.30.78:514)', time_reopen='60'

2016-10-22T10:53:41.166Z 172.31.28.45 <14>Oct 22 10:52:43 ****************************** enterprise_manage_unicorn: [2016-10-22T10:52:42.203424 #4952]  INFO -- : 127.0.0.1 - - [22/Oct/2016 10:52:42] "GET / HTTP/1.0" 302 - 0.0005

2016-10-22T10:53:41.167Z 172.31.28.45 <14>Oct 22 10:52:43 ****************************** enterprise_manage_access: - - [22/Oct/2016:10:52:42 +0000] "GET / HTTP/1.0" 302 44 "-" "-" "-" 0.001 0.001 .

2016-10-22T10:53:41.168Z 172.31.28.45 <14>Oct 22 10:52:45 ****************************** github_production: 10:52:41 +0000 [metrics resque.queued]: {:queue=>"low", :class=>"github-jobs-retry_jobs"} 3930.185883873657ms

2016-10-22T10:53:41.168Z 172.31.28.45 <14>Oct 22 10:52:45 ****************************** github_production: 10:52:44 +0000 [metrics resque.performed]: {:queue=>"low", :class=>"github-jobs-retry_jobs"} 3.72337ms
<snip>

Enable collectd forwarding

GHEのcollectdは5系なので、データ収集用のcollectdは5系以上が必要です。「Enable collectd forwarding」にチェックを入れるとホスト名とフォワードに利用するポート、そして暗号化方式を設定可能です。

ghe2-15

今回はlogstashの時と同様、同じVPC上に構築したcollectdインスタンスでnetworkプラグインを有効にし、ログのフォワーディングを有効化してみました。Amazon Linuxにcollectdをインストール後、以下の内容を /etc/collectd.d/network.conf に記述します。

<Plugin network>
    Listen "0.0.0.0" "25826"
</Plugin>

collectd-rrdtoolパッケージをインストールしてcollectdを再起動すると /var/lib/collectd/rrd 以下に大量のRRDデータが保存されていることが確認できると思います。

まとめ

いかがだったでしょうか。

全部説明していくとかなり長くなってしまいました。設定が必要になった際に適宜参考にしていただければと思います。

本エントリがみなさんの参考になれば幸いです。

GitHub EnterpriseをAWSで使おう – マネジメントコンソール編

はじめに

マネジメントコンソールとは

Change password

SSH access

Hostname

Time

Authentication

Privacy

Pages

Email

Monitoring

まとめ

関連記事

主なカテゴリ

AWS

おすすめ

プロダクト

コンテンツ

お問い合わせ

運営会社