Vagrant上でGitlabを試してみる

Linux Git

はじめに

割と前から、Gitlabの存在は知っていましたが、「どうせ業務でも使えんし、個人利用だと完全にオーバースペックだしなー」ということで、触ったことはありませんでした。

現在の業務では、当初からSVNを使っているプロジェクトで、大体3年半くらい継続して開発が行われています。
ただ、その間に何度かブランチのマージミスに起因するリリースミスをやらかしています。私自身もやらかしていて、そういう経緯と歴史から、SVNの管理は次のようになっていました。

  • trunkをそのままリリースする
  • リリース日までに開発するものは、trunkから作成したブランチ上で作業する
  • trunkになんらかの修正があったら、ブランチにすぐ反映する

この管理でしばらくやっていますが、前提として、複数ブランチの開発はしないというものを付けています。前は、SVNでチケット単位でのブランチモデルを使っていましたが、それが原因で盛大なマージミスを何回かやっており、客先からも懸念されていたため、この制限については客先も了承していたので、危ないときもありましたが、とりあえず安定してきていました。

しかし、状況が変わり、

  • 他のプロジェクトとの関連機能が多くなる(他のプロジェクトは完全に別)
  • しかし自分のプロジェクトだけの修正はできれば高い頻度で出したい

という客先からの希望が出てくるようになりました。SVNで複数ブランチを使って作業するのはかなり危険(私の経験では)と判断し、それならば、ということで、GitとGitlabを代わりに利用すればいいんじゃまいか、ということで、試しに私の方で構築することにしました。
Gitlabは私が入れてみたかったから、というのもありますが、コードレビューを効率的に行える環境も求められてきているので、一応そういう動機もあります。

実際にやってみる

やたらと長い前置きになりましたが、とりあえず構築したメモになります。

その前に私の環境と、今回使ったBoxを。

Host : Gentoo Linux (3.11.4)
VirtualBox: 4.3.6
Vagrant : 1.4.3
Box : http://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

Boxはdummyという名前で入っていることを前提にしています。
ちなみにGitlabの公式ページでは、Debian/Ubuntuと書かれていますが、とりあえずここでは実験も兼ねていますので、特に気にせず行きます。

まずは今回のVMを格納するディレクトリを作って、Vagrantの初期化をします。この時点では、vagrantのpluginをインストールしていなかったので、ついでにやっときます。

$ vagrant plugin install vagrant-aws
$ mkdir gitlab_sample
$ cd gitlab_sample
$ vagrant init dummy

作成されたVagrantfileに、AWS接続のための色々な設定を書いてやる必要があります。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "dummy"

  config.vm.provider :aws do |aws, override|
    aws.access_key_id = 'アクセスキー'
    aws.secret_access_key = 'シークレットキー'
    aws.region = 'ap-northeast-1'
    aws.instance_type = 'm1.small
    aws.ami = 'ami-0d13700c'
    aws.security_groups = [セキュリティグループ]
    aws.keypair_name = 'キーペアの名前'
    aws.tags = {
      'Name' => 'gitlab_sample'
    }
    override.ssh.username = 'ec2-user'
    override.ssh.private_key_path = 'キーペアのフルパス'
  end

end

これでsmallインスタンスであがるはずですので、実行してみます。ちなみにmicroインスタンスでいけば無料枠でいけたのですが、試しにやってみたら、後述のgitlabインストール時に、メモリ不足でそもそも起動できませんでした。

$ vagrant up --provier=aws
# なんか失敗しますが、sudo じゃないと作成できない場所に/vagrantを作成しようとしてエラーになっているだけなので気にしなくてOKです。
$ vagrant ssh

さて、ここからがやたらと大変です。CentOSは基本的に一つ前のバージョンとかしかありません。なので、必要なものは随時自分でインストールする必要があります。
調べたところ、CentOS 6.4 用の GitLab 自動インストールスクリプトを書いたという非常にありがたいページがありました。

が、せっかくなので、上も参考にしますが、公式HPで紹介されている方法でやっていきたいと思います。

・・・と思ったのですが、作業が予想以上に膨大になりましたので、https://github.com/derui/gitlab-installer-ec2/に、これらの作業をまとめたスクリプトを作りましたので、こちらを参照してください。
残念ながら、時間の無い状態でやったため、エラーチェックとかも何もありません。また、このインストールスクリプトは、rubyのインストール周りについては、上記のページを盛大に参考にさせていただいています。

このスクリプトで、一応インストールまではできると思いますが、いかんせん実地でやったのをまとめただけですので、色々と問題がある可能性が非常に高いです。参考にされる方は、くれぐれも自己責任でお願いします。

ちなみにインストールには最低でもsmallくらいじゃないと快適にできません。microでも動作するような気はしますが、公式でも「Very slow」と言われていますので、ちょっとお金を出した方が多分早いです。

以降、vagrant sshした中でやっていきます。

$ sudo yum update
ruby1.8.7が入っているため、一旦削除します。
$ sudo yum remove ruby
$ sudo su

# これでいけるようにしました。なお、必ずEC2上で構築できる、というわけではありませんのでご了承下さい
$ curl -O https://raw.github.com/derui/gitlab-installer-ec2/master/install.sh | sudo bash 2>&1 | tee gitlab-installer-ec2.log

さて、ここからは実際に構築する上で、ハマった点などを書いていきます。

redisのインストール

上述のスクリプトの中には、redisのインストールが書かれていなかったため、gitlabのsetupでエラーが出てしまっていました。なので、redisのインストールをこちらを参考にして行いました。
ただyumするだけですが。

apache2へのインストール

業務で実際に利用する環境はapache2が入っているのですが、Gitlabでは公式にはnginxしかサポートしていません。
ですが、当然ながらみながみなnginxであるわけはないので、recipesということで、unofficialな設定などをあつめたサイトへ誘導されていました。

https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache

SSLでの接続設定と、HTTP Onlyでの接続設定と両方がありますが、SSL推奨ということでそちらを使います。
また、SSLでの接続だと、証明書とかが必要になったので、以下のページを参考にオレオレ証明書ではありますが、用意しました。

http://albatrosary.hateblo.jp/entry/2013/04/30/123019

これについては、ぶっちゃけ自前で用意してもらうのがいいような気がしてますので(opensslのオプションがよくわからん)、スクリプトの中ではコメントアウトしています。

やってみて

正直、すでにEBSに格納しているSVNがあるのであれば、新しいサーバーを一つたてて、EBSをアタッチした状態から始めた方が早いなー、と思いました。ApacheとNginxの設定方式がやたら違うので・・・。

ただ、既存の環境がかなりhttpdに依存してしまっているので、どうしようかなー、という感じです。Amazon Linuxの場合、既存のrubyを削除しなければならないということもあり、ちょっと導入にためらうのもどうかな？という気がします。

なんにせよ、方法がある程度確立できればいい、というのが今回の趣旨だったので、それについてはできたと思います。

後、EC2を私用で初めて使ってみましたが、金額が頭に浮かんで心臓に悪いです。AWSこわい。