オープンソースのGitLabで社内GitHubを構築しよう

BPSでは、社内のソースコード管理にgitを採用しています。
中央リポジトリには、GitHubのオープンソースクローン、GitLabを利用しています。

GitHubのPrivate Repositoryは便利ですが、ちょっとした細かい案件にリポジトリを作って行くと、価格が馬鹿になりません。
また、日本からだと少し遅いですね。
Github Enterpriseは高かったので、面白そうだしGitLabを導入したところ、使い勝手も良く安定運用できています。

GitLabとは

gitoliteのフロントエンドです。似たようなものに、gitosisがあります。
gitoliteは、UNIXユーザを作らずにSSH鍵によってユーザを識別し、プロジェクト毎のアクセス権を与えられるgitリポジトリの管理システムです。

中央リポジトリサーバに、ユーザ毎のアカウントを作ると、以下のような問題があります。

  • 煩雑:単純に大量のユーザを作るのは手間です。
  • セキュリティ:リポジトリアクセスさせたいだけなのに、シェルを渡すのは過剰です。
  • 権限管理:リポジトリの数だけgroupを作って参加を管理するのは、かなり面倒です。また、read only accessを制御するのが困難です。

gitoliteでは、すべてのユーザは共通ユーザ(git)としてログインします。
ログイン時のSSH鍵で、できる操作(アクセスできるリポジトリ)が制御されます。実際に、/home/git/.ssh/authorized_keysに、鍵毎のcommandが指定されています。

gitoliteは以下のような設定ファイル(これ自身をgitで管理)で権限を編集し、設定ファイルの更新hookでauthorized_keysを更新しています。

repo    gitolite-admin
          RW+     =   admin
repo    testing
          RW+     =   @all

GitLabは、これをWeb管理画面から管理できるようにし、GitHubのようなリポジトリブラウザ・Issue・Wikiなどを搭載したものです。

GitHubとの違い

機能的には、本家GitHubには色々劣っていたりします。
なので、お金があるなら、GitHub Enterpriseを使った方が良いと思います。自分で構築したい人向けです。

リポジトリ名はglobal
これはポリシーの問題ですが、GitLabではリポジトリ名は全体で共有されます。
babatakao/practiceとpeter/practiceを両方作ることはできません。
人数やプロジェクトが増えてきたら、prefixな命名規則を作らないと破綻します。

forkはない
同様に、forkもありません。
Pull Requestに相当するMerge Requestは存在しますが、1つのリポジトリのブランチで実施します。
babatakao:masterからpeter:masterにforkといった運用はわかりやすいのですが、これができないことになります。

public repositoryが存在しない
社内向け用途が想定されているため、public repositoryは存在しません。
そのため、deployやtest用にも、必ずdeploy keyを登録する必要があります。
全プロジェクト共通のreadonly accountを設定する機能も現状ないので(gitoliteを直接いじる裏技は可能)、多少手順は煩雑になります。

その他、巨大ファイルがあると弱かったりします。

それ以外は特に気になることもなく、運用できています。
特に、リポジトリブラウザは、本家にひけを取りません。
一番よく使う機能の1つなので、非常に便利です。やはり、リモートブランチの中身を見やすく見られるのは大事ですね。
コミットへのコメント機能もあるので、継続的なコードレビューもやりやすくなっています。

構築

本当は構築をメインに書こうと思ったのですが、非常に簡単で書くことがないので、リンクだけにしておきます。
https://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.md
なお、GitLabは特に関係ないのですが、サーバは必ず64bitマシンにしておきましょう。32bitだと、gitプロセスが十分なメモリを確保できず、OutOfMemoryを吐くことがあります。巨大なファイルがpushされてしまったときなどに。

運用

更新が頻繁なので、まめにバックアップ・バージョンアップできる準備をしておきましょう。
また、pull requestへの反応も良いので、気になる部分はどんどん送ると良いと思います。

Railsのアプリケーションとしても、かなり参考になります。
最新のRailsに随時対応し、Resqueなどの流行りのライブラリを取り入れています。
機能が分かりやすいので、チュートリアルを終えた人が実践的なソースコードに触れるのにも向いています。

しばらく使ってみて

現在、以下のような規模で運用しています。

BPSのGitLab

リポジトリは大小あり、ユーザ数1人・ファイル数10個程度のものから、ユーザ数20人近くのものまで。git-svnで移行したリポジトリも相当数混じっています。
サーバは仮想マシン1台(メモリ2GB)、Ubuntu 12.04 LTS。毎日10~15人くらいはpush/pullしているはずです。

この状態で、特に大きなパフォーマンス上の問題は出ていません。
プロジェクト数が増えてから、新規リポジトリの追加・メンバーの追加はやや重くなりました。これは、gitolite-adminのgitolite.confをパース・上書きしてgitoliteに反映する処理に時間がかかっていると思われます。
リポジトリのpush/pullは、さすが社内ネットワーク経由なので、爆速です。

感謝・感謝です。良いpull request遅れるように頑張ります。

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

baba

ゆとりプログラマー。

高校時代から趣味でプログラミングを初め、そのままコードを書き続けて現在に至る。慶應義塾大学環境情報学部(SFC)卒業。BPS設立初期に在学中から参加している最古参メンバーの一人。Ruby on Rails、PHP、Androidアプリ、Windows/Macアプリ、超縦書の開発などを気まぐれにやる。軽度の資格マニアで、情報処理技術者試験(15区分 + 情報処理安全確保支援士試験)、技術士(情報工学部門)、CITP、Ruby Programmer Goldなどを保有。

babaの書いた記事

BPSアドベントカレンダー

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ