こんにちは！研究開発チーム 荒川（@Morikuma_Works）です。

本日よりリクルートライフスタイルのエンジニアブログを開設いたしました。
記事第一弾として、先日リリースされました、GitHub Enterprise 2.0の使用感とセットアップ時にハマった事例とともに、そもそもなぜ弊社がGitHub Enterpriseを使い始めるに至ったか、運用してみてどうだったか、に関して紹介できればと思います。

GitHub Enterpriseとは

GitHub Enterpriseとは、GitHub.comを自分の環境で運用できるオンプレミス版のGitHub.comのようなサービスです。弊社ではGitHub.comは使わずに、GitHub Enterpriseを用いてソースコードの管理、コードレビュー（Pull Request開発）などを行っております。

以前までは、VMware ESXiやVirtualBoxへデプロイできるVMイメージが供給され、それらハイパーバイザー上でGitHub Enterpriseを社内向けにホスティングしておりましたが、今回のGitHub Enterprise 2.0へのバージョンアップにより、Amazon Web Serrvice上でホスティングすることが可能になりました。

導入のきっかけ

弊社では元々Subversionでソースコード管理をしていました。しかし、ブランチ運用のコスト、マージのコスト、スムーズなコードレビュー環境がない、などのソースコード管理にまつわる負が多数ありました。そこで考えたのが、Gitによるソースコード管理と、それをホスティングするサービスの導入でした。

導入するサービスを検討するにあたって、

• エンジニアが使い慣れているUIであること
• Gitホスティングシステムが安定していること
• Pull Request機能を有すること
• チケット管理システムであるJIRAとの最低限の連携が行えること

上記4点に着目し、いろいろな候補はあったのですが最終的にGitHub Enterpriseを選定しました。

これまでの運用方法

弊社のGitHub Enterpriseをホスティングしていた自作の社内サーバは下記のようなスペックです。

なお、このサーバではGitHub Enterpriseのみをホスティングしていました。 この自作したサーバで1年間運用したところ、

• 400ユーザ程度であればCPU、メモリともにオーバースペック
• HDDを積んでいるが表示速度は良好
• HDDは2TBだが実際には50GB程度しか使用していない

ということがわかりました。

1年間の運用のなかで、1度のみシステムが予期せずダウンしました。原因はVMware上でのスナップショットの肥大化によって、空き容量がなくなり、HDDへアクセスができなくなっていたことが原因でした。
スナップショットを撮り続けるのはバッドノウハウであり、現在では便利なBackup Utilsが存在するため、こちらを使用するように変更しました。

1度のみシステムが予期せずダウンしたとはいえ、堅調に運用を続けていましたが下記のような問題の芽がありました。

• ハードウェア障害が起きてしまった際の対応速度が見えない
• サービスの可用性のさらなる向上
• VMware ESXi、ハードウェア自体のメンテナンス
• ビルの電気設備法定点検による停電の際にシステムも止まってしまう

そこで、Amazon Web Serviceなどで運用できないかと考えていたところ、GitHub Inc.からGitHub Enterprise 2.0のクローズドβテストのお話をいただき参加させていただきました。

2.0新機能

こちらに2.0新機能のまとめがあります。待ち望んでいた機能を3点だけご紹介します。

High availability

Amazon Web Service上でGitHub Enterpriseをホスティングする利点の一つとして、可用性があります。社内でハードウェアの面倒をみずとも高い水準の可用性を比較的コストが掛からずに獲得できるため、とても助かります。
それだけではなく、Warm Active Standby用のSlaveのGitHub Enterpriseインスタンスを作成すると、コマンド1つでMasterインスタンスからSlaveインスタンスにデータのレプリケーションが実行できるようになっています。GitHub Enterpriseが落ちてしまった場合、Airレジ、ホットペッパーグルメ、ホットペッパービューティー、ギャザリーなどのサービス開発の一部が止まってしまい業務影響は深刻なため、とても助かる機能の1つです。

Split Diff

GitHub.comではすでに導入されていますが、差分を表示する際に並べて表示されるようになります。

PSD rendering

こちらもGitHub.comではすでに導入されている機能です。PSDファイルの差分が見れるようになりました。弊社ではデザイナも含めたリソース管理を実現させているため、この機能はデザイナと企画にとって便利な機能になりそうです。

その他にも

その他にも、SAMLのサポート、Inbound email、Pull Request Revertボタンなど便利な機能が続々とリリースされたようです。

セットアップの勘所

詳細なセットアップ方法が記述されており、特殊な作業も必要ないため、Amazon Web Serviceを使用したことがあればとても簡単にインストールできます。しかしいくつか勘所があったので共有します。

EBSのマウント先

Amazon Web Service上のGitHub Enterpriseはrootディスクではなく、追加でEBSをブロックデバイスとしてマウントさせる必要があります。Web Consoleを使用している場合、マウント先が明記されていないため迷うかもしれませんが、例で表示されているjsonを見るとマウント先が記述されています。

EIPを割り当ててからアクセスする

EC2インスタンスが起動し終わったら、アクセスする前にEIPの割り当てを行いましょう。public IPを用いてアクセスするとEIPを割り当てるためにはインスタンスを再起動する必要があります。

セットアップ後最初のアクセスは管理用ポートを用いたページにリダイレクトする

Amazon Web Service上でのセットアップが終了し、最初にアクセスしようとすると、管理用ポートを用いた管理ページにリダイレクトされます。もしアクセス元がwell-knownではないポートを用いた通信が許可されていない場合白紙のページが表示されてしまうため注意が必要です。

まとめ

弊社では、プリリリース版を含めてすでに1ヶ月程度、テスト運用を続けています。特に今回の正式リリース版とほぼ同等のプリリリース版を導入してからシステムが不安定になったことは今のところ1度もありませんでした。

今回は弊社がGitHub Enterpriseを導入したきっかけ、1年間の運用に関して、GitHub Enteprise 2.0の新機能とインストール時の勘所に関して説明いたしました。
次回は弊社ではGitHub Enterpriseを用いてどのようなフローで開発が行われているかを紹介できればと思います。

みなさんもGitHub Enterprise 2.0を使ってみましょう！