Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置)

Gitlab 2.7をCentOS 6.2でインストールしてみることにしました。
nginx＋Rails＋Unicornで動作させます。

• もはや言い訳のようになっていますが、試行錯誤の結果の自分用メモです (汗;)
  試行錯誤の結果、適当にやってみているところ、
  また、環境依存の箇所もありますのでご了承おねがいします m(_ _;)m
• 従いまして、もし参考にしていただける場合は、お手数をお掛けしますが、
  一度このページの末尾まで全て目を通されることをおすすめします。
• Gitlabのドキュメントでは、socketファイルを用いてnginxとUnicornを通信させていますが、この記事では、ポートを指定させて動作させます。
• 本記事では、GitLabをサブディレクトリに配置して動作させます。
• GitとGitoliteは以前に導入済みです：
  http://masanoriprog.blogspot.jp/2012/06/gitgitolite.html

作業の前にvisudoを実行し、secure_pathに/usr/local/binを追加しておきます。
(参照: http://blog.bungu-do.jp/archives/3525)

$ su
# visudo 

~~~~
Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/local/bin/:/usr/bin
~~~~

さて..まずはGitlabのためのユーザアカウントを作成します。
また、作成したアカウントをgitoliteのグループに所属させます。

# useradd gitlab
# usermod -G gitolite gitlab

次に、Gitのリポジトリディレクトリのパーミッションを変更しておきます。
(gitoliteグループに対して読み書き実行の許可をあたえます。)

# chmod -R g+rwx /pathto/repositories/

次に、GitlabアカウントがGitoliteに接続するためのSSH鍵生成と設定を行います。
とりあえず、gitlabユーザになるために一旦suします。

# su gitlab
$ ssh-keygen -t rsa -P "" -f ~/.ssh/gitadmin 

$ vi ~/.ssh/config

Host    localhost
HostName        localhost
User    gitolite
IdentityFile    ~/.ssh/gitadmin 

$ chmod 0600 ~/.ssh/config
$ git config --global user.name "gitadmin"
$ git config --global user.email "gitadmin@example.com"

$ exit

この作成したgitlabアカウントと鍵で
Gitolite上のgitolite-adminへアクセスできるよう設定しておきます。
(いつも管理してるクライアントPCからやると楽です。)
※ Gitlabのドキュメントでは、サーバ上でgitoliteをgit cloneして最初に鍵ファイルを設定して登録しています・・・
が...今回は、運用中のシステムのセキュリティの設定上面倒なこともあり、このようにしています。
本来であればドキュメント通りが正しいですのでそちらの方法で行なってください。

CLIENT $ git clone gitolite@example.com:gitolite-admin

CLIENT $ cd gitolite-admin/
CLIENT $ touch keydir/gitlab.pub
CLIENT $ vi keydir/gitlab.pub 

ssh-rsa ~~~~ gitlab@~~ #gitadmin.pubの中身をコピペ

CLIENT $ vi conf/gitolite.conf 

repo    gitolite-admin
        RW+     =   gitolite gitlab #gitlabを追加しておく

CLIENT $ git add .
CLIENT $ git commit
CLIENT $ git push

次に、Gitlabをgitlabアカウントのルートディレクトリへgit cloneしてきます。

# cd /home/gitlab/
# sudo -H -u gitlab git clone -b stable git://github.com/gitlabhq/gitlabhq.git gitlab
# cd gitlab/
# sudo -u gitlab mkdir tmp 

# sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml

GitlabでSQLiteを使うための設定を適用しておきます。

# sudo -u gitlab cp config/database.yml.sqlite config/database.yml

必要なものをインストールしていきます。

# easy_install pygments
# gem install bundler
# bundle

・・・とここでエラー(´・ω・｀)

~~~~ ~~~~

Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.
        /usr/local/bin/ruby extconf.rb
checking for main() in -licui18n... no
which: no brew in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/masanori/bin)
checking for main() in -licui18n... no

***************************************************************************************
*********** icu required (brew install icu4c or apt-get install libicu-dev) ***********
***************************************************************************************
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.
Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/local/bin/ruby
--with-icu-dir
--without-icu-dir
--with-icu-include
--without-icu-include=${icu-dir}/include
--with-icu-lib
--without-icu-lib=${icu-dir}/lib
--with-icui18nlib
--without-icui18nlib
--with-icui18nlib
--without-icui18nlib

Gem files will remain installed in /usr/local/lib/ruby/gems/1.9.1/gems/charlock_holmes-0.6.8 for inspection.
Results logged to /usr/local/lib/ruby/gems/1.9.1/gems/charlock_holmes-0.6.8/ext/charlock_holmes/gem_make.out
An error occured while installing charlock_holmes (0.6.8), and Bundler cannot continue.
Make sure that `gem install charlock_holmes -v '0.6.8'` succeeds before bundling.

libicuが無いっぽいのでインストール。

# wget http://mirror.centos.org/centos/6/os/x86_64/Packages/libicu-4.2.1-9.1.el6_2.x86_64.rpm
# rpm -ivh libicu-4.2.1-9.1.el6_2.x86_64.rpm
# wget http://mirror.centos.org/centos/6/os/x86_64/Packages/libicu-devel-4.2.1-9.1.el6_2.x86_64.rpm
# rpm -ivh libicu-devel-4.2.1-9.1.el6_2.x86_64.rpm
# rm ./libicu-devel-*

もう一回、bundleを実行...

# bundle 

~~~ 

Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
Post-install message from httparty:
When you HTTParty, you must party hard!

うまくいった。続いて...Gemのインストール。

# sudo -u gitlab -H bundle install --without development test --deployment

DBのセットアップ。

# sudo -u gitlab bundle exec rake gitlab:app:setup RAILS_ENV=production

構成のテストを行います。

# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production

rake aborted!
Connection refused - Unable to connect to Redis on 127.0.0.1:6379
Tasks: TOP => gitlab:app:status => environment
(See full trace by running task with --trace)

(´・ω・｀)・・・まずRedis入ってなかったorz

# yum install redis
~~~
Installed:
  redis.x86_64 0:2.4.10-1.el6                                                
Complete!

# service redis start

はい。 もう一丁、テスト実行。

# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production 

Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/home/git/repositories/............missing
rake aborted!
unexpected return
Tasks: TOP => gitlab:app:status
(See full trace by running task with --trace)

(´・ω・｀)まあそりゃーな。無いもんな。

実はうちの環境では、/home/git/repositories/下にリポジトリを置いていないのです・・・
ということでGitlabの設定変更。

# vi config/gitlab.yml
~~~
git_host:
  admin_uri: git@localhost:gitolite-admin
  base_path: /pathto/repositories/  # host: localhost
  git_user: git
~~~

再度、テスト実行。

# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production 

Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/var/lib/gitolite/repositories/............exists
/var/lib/gitolite/repositories/ is writable?............YES
ssh: connect to host localhost port 22: Connection refusedfatal: The remote end hung up unexpectedly
Can clone gitolite-admin?............YES
UMASK for .gitolite.rc is 0007? ............NOrake aborted!
unexpected return
Tasks: TOP => gitlab:app:status
(See full trace by running task with --trace)

まず、うちの環境ではSSHのポートを22番から変更しているため
接続できていないということ・・・。
なので再度、Gitlabの設定(gitlab.yml)を変更しておきます。

# vi config/gitlab.yml
~~~~
git_host:
  admin_uri: gitolite@localhost:gitolite-admin
  base_path: /pathto/repositories/
  host: example.com #ホスト名もちゃんと設定しておく。
  git_user: git
  upload_pack: true
  receive_pack: true
  port: 22 #コメントアウトを外してポート番号を変更。
~~~~

同時に、GitlabユーザのSSH設定のほうも変更しておきます。

# vi /home/gitlab/.ssh/config 

Host    localhost
HostName        localhost
User    gitolite
IdentityFile    ~/.ssh/gitadmin
Port    22

また、.gitolite.rc内のUMASKを書き換えろとのこと。やってなかったので・・・

うちの環境では、/var/lib/gitolite/下にありますのでそれを書き換えます。

# cp /var/lib/gitolite/.gitolite.rc  /var/lib/gitolite/.gitolite.rc.backup
# vi /var/lib/gitolite/.gitolite.rc
$REPO_UMASK = 0007; #0077の箇所を0007にしておく 

これで...もう一度、テスト実行。

# sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production

bundle exec rake gitlab:app:status RAILS_ENV=production
Starting diagnostic
config/database.yml............exists
config/gitlab.yml............exists
/var/lib/gitolite/repositories/............exists
/var/lib/gitolite/repositories/ is writable?............YES
remote: Counting objects: 31, done.
remote: Compressing objects: 100% (24/24), done.
remote: Total 31 (delta 7), reused 0 (delta 0)
Receiving objects: 100% (31/31), 3.10 KiB, done.
Resolving deltas: 100% (7/7), done.
Can clone gitolite-admin?............YES
UMASK for .gitolite.rc is 0007? ............YES

OKですね〜。

データベースに初期データを登録します。

# sudo -u gitlab bundle exec rake db:setup RAILS_ENV=production
# sudo -u gitlab bundle exec rake db:seed_fu RAILS_ENV=production

このとき、初期ユーザ名とパスワードが表示されるのでメモを。

さて、デーモン起動させてみましょう。

#  sudo -u gitlab bundle exec rails s -e production -d

=> Booting Thin
=> Rails 3.2.5 application starting in production on http://0.0.0.0:3000

お。OKっぽいですねｗ 続いて...Resqueプロセスを起動させてみます。 

# ./resque.sh

では今後は、Unicornで。

# sudo -u gitlab cp config/unicorn.rb.orig config/unicorn.rb 

# sudo -u gitlab bundle exec unicorn_rails -c config/unicorn.rb -E production -D

次にGitlabをサブディレクトリ下で動作させるために
設定ファイル(config.ru)を変更します。
(config.ruを開いて、run ~~ の一行を次のように囲みます。)

# vi config.ru 

require ::File.expand_path('../config/environment',  __FILE__)
map ActionController::Base.config.relative_url_root || "/" do
        run Gitlab::Application
end

また、バックエンドとなるUnicornをサービスさせるポートを定義するために
Unicornのスクリプトファイル(unicorn.rb)を変更します。

# vi config/unicorn.rb 

~~~~
#listen "#{app_dir}/tmp/sockets/gitlab.socket" #コメントアウトする
listen 8081 #Unicornをサービスさせるポート番号を指定
~~~~

さらに、すでに稼働させているnginxの設定ファイル(nginx.conf)に

Gitlabのためのリバースプロキシ設定を追加しておきます。

$ su

# vi /etc/nginx/nginx.conf

upstream gitlab {

    server 127.0.0.0:8081; #Unicornのポート番号を指定

}

~~~~

server {

    ~~~~

    location ~ ^/gitlab/(.*) { #Gitlabを配置するディレクトリを指定

        proxy_redirect off;

        proxy_pass http://gitlab;

        break;

    }

}

nginxの実行アカウントをgitlabグループに所属させておきましょう。

# usermod -G gitlab nginx

そして、nginxを再起動。

# service nginx restart

さらにgitlabをServiceにするために
/etc/init.d/gitlab を作成しておきましょう。
(Source: https://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.md)

# vi /etc/init.d/gitlab 

#! /bin/bash
### BEGIN INIT INFO
# Provides:          gitlab
# Required-Start:    $local_fs $remote_fs $network $syslog redis-server
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: GitLab git repository management
# Description:       GitLab git repository management
### END INIT INFO
DAEMON_OPTS="-c /home/gitlab/gitlab/config/unicorn.rb -E production -D --path /gitlab" #Gitlabを配置するディレクトリを指定
NAME=unicorn
DESC="Gitlab service"
PID=/home/gitlab/gitlab/tmp/pids/unicorn.pid
RESQUE_PID=/home/gitlab/gitlab/tmp/pids/resque_worker.pid
case "$1" in
  start)
        CD_TO_APP_DIR="cd /home/gitlab/gitlab"
        START_DAEMON_PROCESS="bundle exec unicorn_rails $DAEMON_OPTS"
        START_RESQUE_PROCESS="./resque.sh"
        echo -n "Starting $DESC: "
        if [ `whoami` = root ]; then
          sudo -u gitlab sh -l -c "$CD_TO_APP_DIR > /dev/null 2>&1 && $START_DAEMON_PROCESS && $START_RESQUE_PROCESS"
        else
          $CD_TO_APP_DIR > /dev/null 2>&1 && $START_DAEMON_PROCESS && $START_RESQUE_PROCESS
        fi
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        kill -QUIT `cat $PID`
        kill -QUIT `cat $RESQUE_PID`
        echo "$NAME."
        ;;
  restart)
        echo -n "Restarting $DESC: "
        kill -USR2 `cat $PID`
        kill -USR2 `cat $RESQUE_PID`
        echo "$NAME."
        ;;
  reload)
        echo -n "Reloading $DESC configuration: "
        kill -HUP `cat $PID`
        kill -HUP `cat $RESQUE_PID`
        echo "$NAME."
        ;;
  *)
        echo "Usage: $NAME {start|stop|restart|reload}" >&2
        exit 1
        ;;
esac
exit 0

スクリプトのパーミッションを変更。

# chmod +x /etc/init.d/gitlab

自動起動を有効にしておきます。

# chkconfig --add gitlab
# chkconfig gitlab on

あとはサービスを実行するだけ。

# service gitlab start

これで・・・

http://example.com/gitlab/ にアクセスすると・・・

うまく行ったようです♪

追記: このままではpublic/uploads/下にアップロードするファイルに
アクセスすることができませんでした。

ということで・・・nginxの設定ファイル(nginx.conf)に修正を...。

# vi /etc/nginx/nginx.conf 

~~~~
        location ~ ^/gitlab/uploads/(.*) {
                #静的ファイル
                rewrite ^/gitlab/uploads/(.*) /$1;
                root    /home/gitlab/gitlab/public/uploads/;
                index   index.html;
                ssi     off;
                break;
        }
        location ~ ^/gitlab/(.*) {
                proxy_pass      http://gitlab;
                break;
        }
~~~~

さらに、/home/gitlab/ のパーミッションに

# chmod g+x /home/gitlab/

しておく。以上です。

これで静的ファイルはnginxから直接レスポンスされるようになります。
たぶんこんな感じでOKなはずです。たぶん（汗；←

---

参考にさせていただいたページ (感謝♪):

• gitlabhq/doc/installation.md at stable · gitlabhq/gitlabhq
• CentOS6にGitLabをインストールする方法 | Ryuzee.com
• CentOS 6.2 に GitLab をインストールする - akishin999の日記
• 新さくらVPSへの引越し vol.3 GitLab + Unicorn + Nginxの導入 - yokojiの日記
• kennyjのブログ(仮): rails3でのsub ディレクトリへのデプロイ