Jenkinsのスレーブノードを追加してみた

先日の記事(Hello, Jenkins. GitLab＋Jenkins＋perl(Mojolicious)でCIをしてみた)では
GitLab(Gitolite)を使っている環境に、Jenkinsをインストールして、
CIのためのシステム構築を行いましたが...
さらに他のマシンをスレーブとして追加することで、ビルドの負荷分散ができます。

今回は新しいVPSにもJenkinsをインストールして、スレーブにしてみました。
この記事では、スレーブを構築＆設定する手順を、書いておきます。(自分用メモとしてｗ)

• スレーブ側では、Jenkinsサービスを起動しておく必要はありません。
• ビルドを行う度に、マスターのJenkinsがSSHを介してスレーブのシェルに接続し、スレーブ上のJenkinsの"スレーブエージェント"を実行する仕組みです。(sshを介して通信するので、特に両者間でVPNを張る必要もありません。)
  参照: Distributed builds - 日本語 - Jenkins Wiki
• 今回、CIを行う対象のプロジェクトは、マスター上のGitLab(Gitolite)にリポジトリがあるものとします。(先日の記事の続きなので。)

尚、今回は鍵を2つ作成することになります。

• [マスター側で作成する鍵] カギA　 - 手順3で作成
• マスターのJenkinsが、スレーブに接続するため の鍵。
• 作成されたカギの公開鍵は、スレーブのauthorized_keysに登録します。
• [スレーブ側で作成する鍵] カギB 　- 手順5で作成
• スレーブのJenkinsが、Gitリポジトリに接続するため の鍵。
• 作成されたカギの公開鍵は、GitlabもしくはGitoliteに登録します。

(※ もっと良い手順がありましたら、ご教授お願いします！)

---

1. [スレーブ]　Jenkinsをインストール。
   (先日の記事 "Hello, Jenkins. GitLab＋Jenkins＋perl(Mojolicious)でCIをしてみた" を参照のこと。jenkinsサービスを開始する必要はありません。)
2. [スレーブ]　JREをインストール。
3. [マスター]　カギAを .sshディレクトリ(/var/lib/jenkins/.ssh/)に作成。

   $ sudo -u jenkins ssh-keygen
   > /var/lib/jenkins/.ssh/id_rsa_con_slave

(マスター側の.sshディレクトリには既に、マスター自身のJenkinsが Gitリポジトリに接続するための鍵があるわけですので、今回は別の名前にします。)
4. [スレーブ]　カギAの公開鍵(id_rsa_con_slave.pub)の中身を、スレーブ上のJenkinsユーザのauthorized_keys (/var/lib/jenkins/.ssh/authorized_keys) に記述。

   $ sudo -u jenkins vi /var/lib/jenkins/.ssh/authorized_keys
   ssh-rsa ~~~~ jenkins@xxx

   ※ 但し、jenkinsユーザは、/etc/passwd上 で /bin/falseに設定されているので、/bin/bashに変更する。
   もしくは、他のユーザを作成する。(セキュリティ的には後者のほうが安全...か？)

5. $ sudo -u root vi /etc/passwd
   ~~~~
   jenkins:x:xxx:yyy:Jenkins Continuous Build server:/var/lib/jenkins:/bin/bash

6. [スレーブ]　カギBを .sshディレクトリ(/var/lib/jenkins/.ssh/)に作成。

   $ sudo -u jenkins ssh-keygen
   > /var/lib/jenkins/.ssh/id_rsa

7. [スレーブ]　カギBをGitリポジトリへの接続に使えるよう、.ssh/configに記述。(先日の記事でのマスター側と同様。)

   $ sudo -u jenkins vi /var/lib/jenkins/.ssh/config
   Host example.com
       User gitolite
       Port xx
       Hostname example.com
       IdentityFile /var/lib/jenkins/.ssh/id_rsa

8. [クライアント]　カギBの公開鍵(id_rsa.pub)の中身を、GitLab(もしくはGitolite)のJenkinsユーザのSSH鍵に登録。
   (GitLabを使っているならば、先日の記事と同様に、Webブラウザからjenkinsアカウントでログインして、SSH Keys画面から鍵の追加を行います。)
   
9. [スレーブ]　known_hostsにGitリポジトリサーバの情報を登録するために、一旦、手動でgit cloneをします。

   $ cd /var/lib/jenkins/
   $ sudo -u jenkins git clone ssh://gitolite@example.com:xx/hoge.git
   > Are you sure you want to continue connecting (yes/no)? yes
   $ sudo -u jenkins rm hoge/ -R

   (cloneしてくるリポジトリは、jenkinsアカウントでgit cloneできるものなら何でもOK。cloneされたディレクトリは、すぐに削除して構いません。)
   
10. [クライアント]　マスターのJenkinsのノード管理画面で、ノードを追加する。



• "ノード名":　適当
• "同時ビルド数":　適当 (スレーブのコア数にするのが妥当)。
• "リモートFSルート": 　"/var/lib/jenkins/"
• "起動方法": 　"SSH経由でLinuxマシンのスレーブエージェントを起動"
• "ホスト":　スレーブのホスト名 or IPアドレス
• "ユーザ名":　"jenkins"
• "ポート"　スレーブのSSHデーモンのポート
• "秘密鍵": 　カギAの秘密鍵 ("/var/lib/jenkins/.ssh/id_rsa_con_slave")
11. [スレーブ]　各プロジェクトのビルド環境を構築する。
    とりあえず手順9まで終えて、ビルドを実行してみると、まだ失敗することがわかると思います。
    ですので、例えば perlのプロジェクトをCIするのであれば、cpanmのインストールなり、perlのモジュールインストールなりを行います。先日の記事の後半どおり、マスター側と同様。

といった感じです。

スレーブ側では、JenkinsのWeb画面での設定も、ジョブ作成も必要ありません。
その都度、マスターのJenkinsがスレーブへ自動的に転送してくれます。

尚、さらに2台目、3台目のスレーブ...と追加していく場合には、
この記事の手順3は不要ですね。

Hello, Jenkins. GitLab＋Jenkins＋perl(Mojolicious)でCIをしてみた

こたつ最高(>ω<)♪ こたつで丸くなっております、Masanoriです（笑）

公開しているプロジェクトではTravis-CIを使わせていただいていたりするのですが
今回は、自前のGitLabで管理しているプロジェクトにもCIを...ということで...

Jenkinsをインストールして、GitLab上のGitリポジトリ、
および nginx(リバースプロキシとして...)と組み合わせる話(※自分用メモ)です。
また、Jenkinsを用いて、perl(Mojolicious)のプロジェクトをテストします。
(加えて、CPANモジュールの一時的な自動インストールも行えるようにします。[追記: 2013/02/11])

※尚...Gitlabには、Gitlab CIというシンプルなソフトウェアが提供されており、通常はそちらを使うと良いと思います。今回は Jenkinsを使うこととしました。
Jenknsをちゃんと使ってみたかった！という動機がｗ

• サーバはいつも通りのCentOSです。JDKなどもセットアップ済みです。
• nginxをリバースプロキシとして、Jenkinsを /jenkins 下で動作させます。
  (毎度お断りしておきますが、以下にある設定内容は実際の運用サーバとは異なります。)
• プロジェクトはすでにGitLabで作成済みで運用中、nginxも運用中です。

以下、
madroom project: Gitoliteに触れずにGitLabのhookからJenkins側でビルドする
を参考にさせていただきました。感謝！ m(_ _)m♪
(Gitoliteを弄らない方法になっています。)

---

まずはJenkinsのウェブサイトからRPMをダウンロードしてインストール。
(LTS版もあるみたいですが、最新のJenkins-1.500を選択。)

$ wget http://pkg.jenkins-ci.org/redhat/jenkins-1.500-1.1.noarch.rpm
$ sudo rpm -ivh jenkins-1.500-1.1.noarch.rpm

これでJenkinsのインストールは完了です。とても楽ちんでありがたいですね。

次にJenkinsからGitリポジトリへアクセスできるよう鍵を作ります。
(今回はサーバ上でなくクライアント上で作って転送したほうが、GitLabでの登録がうまく行くそうです。)

$ ssh-keygen
Enter file in which to save the key (~~~): id_rsa_jenkins
Enter passphrase (empty for no passphrase): (空)
Enter same passphrase again: (空)

作成した鍵は、/var/lib/jenkins/.ssh/ 下に置いておきます。

さらに /var/lib/jenkins/.ssh/config を記述します。

$ sudo vi /var/lib/jenkins/.ssh/config
Host example.com
    User gitolite
    Port xx
    Hostname example.com
    IdentityFile /var/lib/jenkins/.ssh/id_rsa_jenkins

またknown_hostsも手動で記述しておきますｗ

$ sudo vi /var/lib/jenkins/.ssh/known_hosts
[example.com]:xx,[xxx.xx.xxx.xxx]:xx ssh-rsa ~~~~

次にJenkinsの設定ファイル(/etc/sysconfig/jenkins)を開いて
ポート設定およびディレクトリパスを変更します。

$ sudo vi /etc/sysconfig/jenkins
~~~~
# JENKINS_PORT="8080"
JENKINS_PORT="8888"
~~~~
#JENKINS_ARGS=""
JENKINS_ARGS="--prefix=/jenkins"

さらにnginxの設定ファイルにリバースプロキシのための設定を追加しておきます。

$ sudo vi /etc/nginx/nginx.conf
http {
    ~~~~
    upstream Jenkins.backend {
        server 127.0.0.1:8888;
    }
　~~~~
    server {
        ~~~~
        location ~ ^/jenkins.* {
                proxy_pass      http://Jenkins.backend
                break;
        }
        ~~~~
    }
}

次に、Gitlabにブラウザからアクセスし、Jenkinsのユーザアカウントを作成します。
またCIを行うプロジェクトの"Reporter"権限をそのアカウントに対し設定します。

さらに、プロジェクトのWebHooks画面で JenkinsのURL (http://example.com/jenkins/git/notifyCommit?url=gitolite@example.com:xxx/yyy.git)
を登録しておきます。

また、作成したアカウントでGitlabにログインして、
さきほど作成した公開鍵を登録します。

次に...Jenkinsを起動します。

$ sudo service jenkins start

これでブラウザからアクセスできるようになっているはずです。 http://example.com/jenkins

早速、"新規ジョブ作成"へ進....
...といいたいところですが、その前に...Git Pluginのインストールです。
これがWebのUIで取得〜適用まで可能になってるんですね〜...素晴らしいです！ (ちょっと違うところでは、TracとかRedmineもそうなってきてますが、手軽でありがたいことですｗ
 以下スクリーンショット付きですｗ)

まず、"Jenkinsの管理"をクリック。

"プラグインの管理"をクリック。

"利用可能"タブをクリックして...

"Git Plugin"にチェックを入れ、"再起動せずにインストール"をクリック。
(※"Git Server Plugin"などありますが、またこれとは別です。
 "Git Plugin"だけ、フィルタをかけてもうまくヒットしないときがありました。 "高度な設定タブで、設定をいじったり、何回か更新処理を実行した後に正しく表示されました。)

(それにしても...他にも色々おもしろそうなプラグインがｗｋｔｋ)

"インストール完了後、ジョブがなければ〜再起動"にチェックを入れて待ちます。

インストールが終われば、ダッシュボードから再度、"Jenkins"の管理をクリックし、 "システムの設定"をクリックします。

"Git plugin" セクションの"Global Config user.name Value"と、
 "Global Config user.email Value"を入力し、"保存"をクリック。

次に、再度ダッシュボードに戻り、"新規ジョブ作成"をクリック。

ジョブ名を入力し"フリースタイル・プロジェクトのビルド"を選択。
"OK"をクリック。

"Git"にチェックを入れ "Repositories"の
"Repository URL"に ssh://~なURLを入力して・・・

さらに、"ビルド・トリガ"セクションの "SCMをポーリング"にチェックを入れ "保存"をクリックします。

また最後であれですが..Jenkinsで認証を設定しておきましょう。(※最初にやるべきか（汗;
"Jenkinsの管理"→"グローバルセキュリティの設定"から、設定できます。

 [追記:2013/02/11]

"アクセス制御"セクションの "行列による権限設定"を選択して、表を編集することで、非ログインユーザーによる閲覧をブロックすることが可能です。
(※尚、"ログイン済みユーザーに許可"のほうを選択してしまうと、非ログインユーザでも閲覧はできますので注意。)
尚、このグローバルセキュリティの設定ですが、設定ミスによりアクセスできなくなった場合は、
一時的に無効化しましょう (→ Jenkins パスワードのリセット方法 - エンジニアきまぐれTips (感謝♪))

さらにもし必要ならば、別途、nginx側などで閲覧認証をつけてください。

これでプロジェクトを取り込む設定は、ひとまず完了です。

あとは、GitLab上でTest Hookを実行するか、リポジトリにプッシュすれば
Jenkins側で、ひとまずビルドが走ります.........

---

さて、これではまだ、テストケースを実行して評価することができません。

今回CIを実施したいプロジェクトは、
perlのMojoliciousというWAFで開発しているWebアプリケーションなのですが、
これをJenkinsでテストできるよう設定したいと思います。

Tatsuya Blog » PerlのテストコードをJenkinsで動かすのページを
参考にさせていただきました。感謝です m(_ _)m♪

• 但し、今回の記事では、テスト実行の際、一時的にCPANモジュールを自動インストールできるようにしておきます。
  インストールされるモジュールは、Makefile.PLに定義します。
• テストスクリプト(t/*.t)とMakefile.PLについては、作成済みです。
  Makefile.PLは、以前の記事: Travis CIでPerl(Mojolicious)アプリケーションを自動テストを参照。
  また、Mojoliciousでのテストスクリプトの書き方は、Test::Mojoなどを参考に。

まず cpanmを Jenkins用に、
Jenkinsのホームディレクトリ(/var/lib/jenkins)下へインストールします。

$ sudo -u jenkins mkdir /var/lib/jenkins/bin
$ cd /var/lib/jenkins/bin
$ sudo -u jenkins curl -LOk https://raw.github.com/miyagawa/cpanminus/master/cpanm
$ sudo chmod +x ./cpanm

次に、cpanmで、TAP::Formatter::JUnit をインストールします。

$ sudo cpanm TAP::Formatter::JUnit

次に、Jenkins上のプロジェクトの設定画面を開きます。

ここでは、"ビルド"セクションで、"シェルの実行"を選び、
"シェルスクリプト"欄に次のコマンドを記述します。

/var/lib/jenkins/bin/cpanm -l dlibs --installdeps .
prove -Idlibs/lib/perl5 -b --formatter=TAP::Formatter::JUnit -lvr t > test_results.xml

(最初にcpanmを使って、dlibsフォルダ下にモジュールを自動ダウンロードしています。
尚、proveコマンドについては、詳細なログが不要であれば-v オプションを取り除くといいです。
オプションについて詳しくは...prove についてのおさらいを参照するとよいでしょう。(感謝♪))

さらに、"テスト後の処理"セクションで、"JUnitテスト結果の集計"を選び、
 "テスト結果XML"欄に次のファイル名を入力します。

test_results.xml

"保存"ボタンをクリックして設定完了です。

あとはプッシュすれば、ビルドが自動的に行われ、テスト結果が生成されます。
また手動でもビルド実行が可能です。

無事通過(PASS)したテスト。Jenkinsでは青色のマークが表示されます。

通知設定などはまた別途行ってください。
それにしても...Jenkinsおじさん、ステキですｗｗｗ

[2013/02/18 追記]
今回の続きとして...Jenkinsへスレーブを追加してみました。
→Masanoriのプログラミング日誌＋＋: Jenkinsのスレーブノードを追加してみた

【解決】GitLabでGit HTTPが使えない問題 (※サブディレクトリ環境)

昨日に引き続き、GitLabの話です。
GitLab 2.7から"Git HTTP"(Git Smart-HTTP)が実装されていたのですが、
いつもはSSH経由で利用しているため、これまでは使っていませんでした。
(※ Git HTTP = HTTP経由でGitLabを通してリポジトリにアクセスする機能)

さて...今日はこのGit HTTP機能をいざ使ってみようと...

GitLab3.0の画面。[SSH]ボタンと並んだ [HTTPS]ボタンをクリックすると
Git HTTPによるURLが表示される。
（URLは、プロジェクトの通常のURLに".git"を付加したものとなる）

表示されたURLをブラウザから開いてみる...と...
何回やっても認証画面がｗｗｗ

正しいメールアドレス＋パスワードを入力しているのに
401エラーが出るという・・・(汗;)ｗ

ところで。GitLabでは、サブディレクトリ下での運用を本来サポートしていません。
ですので、私はリバースプロキシ(nginx)を通して少々無理やり運用しています。
(それについては、記事:Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置)を参照)

今回は恐らく、そのための問題なのだろう...と仮定して調べてみました。
(他の可能性としては、gitlab.ymlの設定ミスもありますが、今回は問題ありませんでした。)

→ 結果...その通り！やはりサブディレクトリ下で運用していることが問題なようですorz

とりあえず...手探りで試行錯誤してみましたので、
対策方法を以下に残しておきます。

[注意] GitLabのサブディレクトリでの運用が本来サポート外であるうえに、
私はいまのところ Ruby/Unicornに全く詳しくありませんｗｗ
そのため保障はできませんが、参考にまで。
...もっと良い方法があればアドバイスお願いします m(_ _)m )

---

/gitlab/lib/gitlab/backend/grack_auth.rb : 17行目付近〜

@env['PATH_INFO'] = @request.path
@env['SCRIPT_NAME'] = ""

# Find project by PATH_INFO from env
#if m = /^\/([\w-]+).git/.match(@request.path_info).to_a　#コメントアウト
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
    if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
        @env['PATH_INFO'] = "/#{m2.last}"
    end
    return false unless project
end

変更点としてはこれくらいです。

---

以下に、何を行ったかの解説＆メモを書いておきます。

まずGitLabでは、Grackというモジュールを用いることで
このGit HTTPを実現しているようです。
GitLabのルーター(/gitlab/config/routes.rb)はユーザからアクセスを受けると、
Git HTTPのためのアクセスをここで受け取ります。

Grackの認証(Basic認証)には、GitLab上のアカウント情報が用いられます。
実際にその処理を行なっているのは/gitlab/backend/grack_auth.rb ですね。

上のgrack_auth.rbでコメントアウトした行とその次行の
# if m = /^\/([\w-]+).git/.match(@request.path_info).to_a
    self.project = Project.find_by_path(m.last)
はリクエストされたパス(@request.path_info)からプロジェクト名を抜き出しています。
本来、パスが"/hoge.git/aaaa"だとしたら、
hogeという部分が正規表現で抜き出され、self.projectに代入されるわけです。

ただ当然これでは、パスがサブディレクトリを含んでいると正しく抜き出せないですね。

ですので...コメントアウトした行の代わりにこのように追加しました:
if m = /^(\/([\w-]+))*?\.git/.match(@request.path_info).to_a

これにより、サブディレクトリであっても正しくプロジェクト名が抜き出せます。

さて...この修正だけで、事態(？)には光が見えてきます（笑）ｗ
プロジェクト名が正しく抜き出せなかったために、
プロジェクトを探せず、401エラーになっていたようです。

これでとりあえず、401エラーが改善し、認証は正常に通るようになります。

が...。

ここでまだ、git cloneしてもうまく行かないはず・・・。

Grackの認証が済むと...
プロジェクト名やパスを環境変数(@env)で渡して次の処理を
/gitlab/vendor/bundle/ruby/*.*.*/bundler/gems/grack-*/lib/grack/*.rb

が行うわけですが・・・。

ここでリポジトリ上のファイルを読み込む時・・・
サブディレクトリのせいでパスを正常に扱えず、ファイルが見つからないのですｗ
なのでエラーとなります。

この対策のために、前のステップでパスを直しておくことにしました。
先ほどとおなじくgrack_auth.rbでやってしまいましょうｗ

以上の理由から、先ほどの行の後に2行追加しました:

        if m2 = /\/([\w-]+*?.git\/.*)/.match(@request.path).to_a
                @env['PATH_INFO'] = "/#{m2.last}"

正規表現マッチもあれな書き方ですが、未だ詳しくないので許してください(><;)

これににより、環境変数に入れるパスからサブディレクトリ部分が削られます。
つまり、本来、GitLabが意図しているパスになるわけです(>ω<)♪

これで一応、解決です。

試しに...クライアントから
$ git clone https://example.com/git/hoge.git
を実行してみてください。正しくcloneできるはずです。

今回は以上となります。

今回もこのヒントを得るためにGitHubやコミュニティを参考にさせていただきました。
ありがとうございました m(_ _)m♪

• Home · SaitoWu/grack Wiki - grackについて。Saitoさんはgitlabのメンテナさんの一人です。
• Smart HTTP not working? · Issue #1810 · gitlabhq/gitlabhq
• Can't clone repos via http on linux · Issue #1101 · gitlabhq/gitlabhq
• Cloning over http fails if gitlab is not on / · Issue #1228 · gitlabhq/gitlabhq
• http clone doesnt work (latest master) · Issue #1039 · gitlabhq/gitlabhq
• in master branch grack_auth.rb doesn't exist · Issue #1476 · gitlabhq/gitlabhq
• Is it possible to host GitLab in a subdirectory of www root, like http://www.mydomain.com/gitlab ? - Google Group
• git http(s) access not working - Google Group
• その他...

---

p.s.

そもそもサブディレクトリじゃなくルートでGitLabを運用したらいいのに...
と思われる方もいらっしゃるかもしれません・・・。

私は学生個人でサーバを運用しています。
そしてこういったものに、HTTPSは必須だと考えております。
ところで、ルートディでGitLabを運用するには、当然、サブドメインなり別サーバ/IPアドレスなりの方法を取らなければなりませんが、
それをするとなると、サーバ証明書もGitLab用に別途用意することになります・・・。
サブドメインでも使える証明書は高価ですし・・・。
そこまでの余裕は無いのです(´・ω・｀)...。

尚、GitLabはサブディレクトリへの対応を実装することは今のところないそうです。

GitLab 2.8→3.0にバージョンアップ

前回の記事(Gitlab 2.7 → 2.8にバージョンアップ)から約2ヶ月...
9月末にGitLab 2.9が公開されていたんですが...
つい先月(10月)末に、GitLab 3.0が公開されたようです。
http://blog.gitlabhq.com/gitlab-3-dot-0-released/

とりあえず変更点を...(適当に翻訳しましたｗ)

2.9での変更点は以下の通り (公式ブログより抄訳)

• 400コミット以上の素晴らしいコード
• コメントの表示順を変更 (Wallを除く)
• omniauthのサポート (twitter, google…)
• Bunch of stuff の修正 (訳注: たくさんのモノ/諸々 とでも訳しておきますかｗ)
• 多くのコードのリファクタリング
• Gitolite v3への対応
• 絵文字機能
• LDAPとOAuth設定を一つに集約 -> config/gitlab.yml
• ProfileとAdmin画面に新機能
• 多くのAPIを追加

そして 3.0での変更点は以下の通り (こちらも公式ブログより抄訳)

• 300コミット以上の素晴らしいコード
• ウェブエディタ機能
• より多くのAPIを追加
• ファイルブラウザの改善
• SSH鍵の追加と削除についての致命的な不具合修正
• (非公式な) Postgreサポート
• プロジェクトグループ機能
• ファイルとコミットについてのパフォーマンスがかなーり改善
• コードのリファクタリングとクリーンアップ など...

うーん。これは楽しみ！！

ということで、3.0へのバージョンアップを行いたいと思います(>ω<)

私の場合、2.9→3.0ではなく2.8→3.0のバージョンアップとなるため・・・
こちらのドキュメントを参考にしたいと思います:
https://github.com/gitlabhq/gitlabhq/wiki/From-2.6-to-3.0
(そうじゃなくてすでに2.9をお使いの方はこちらを参照)

毎度のことですが、更新はgit pullして取得できて楽ですね。

今回はそれに加えて、hooks(post-receive)の上書きと、
gitlab.ymlの再設定が必要になりました。
必要に応じて、バージョンアップ前にバックアップをとっておくといいかもしれません。

(さらに私の環境では、サブディレクトリで動作させる等々しているので殆ど前回同様に再設定が必要でした。)

---

GitLab 3.0にバージョンアップ完了

それにしてもGitLab、友人と一緒の開発に使っていますが...使いやすいですね。

(元々のアイデアであるGitHubもそうですけれど)
他のプロジェクト管理システムよりも色んなモノを削って、またGitに特化している分、
使いやすさがあるんだろうな〜と思います。

GitLab 2.9から追加された Issueでの+1 機能。
コメントを書く時、"+1"という文字を入れておくと、カウントしてくれます。
こういう機能も他のプロジェクト管理システムだとプラグインで使えたりしますが、
標準で実装されるのはちょっと嬉しいですねｗ
(尚、軽めにぼかし入れてますが、開発中のモノです。見えてもいいんですけど一応軽くｗ )

Trac,Redmine,etc...を使っていると、
欲を言えば、GitLabはモノ足りないかなーと思うことが無いこともないんですけど、
それでも...必要十分以上の機能は揃っているわけです。
毎日のように使うツールですから、”シンプル”であることは大切だと思います。
開発メンバーが増えたときの慣れやすさを考えてもそうですしね。

Gitlab 2.7 → 2.8にバージョンアップ

友人との開発プロジェクトにGitLabを実際に利用させていただいています。
GitHubに使い勝手が近いこと、また、RedmineやTracほど大規模でないため
とても手軽で、メンバーの学習コスト的にも敷居が低く、最適だと思っています。
(前回の記事: Gitlabの導入 (Unicorn+nginxでサブディレクトリへ配置))

さて今回は、8月末にGitLab 2.8が公開されたため、
現在のGitLab 2.7からバージョンアップをすることとしました。
GITLAB 2.8 released - GITLAB Blog

Gitlab Flavored Markdownなどなど...便利になりますね。
(プレビュー機能が使えて、その場で確認もできるようになりました。)
また、詳細まで追ってはいませんが、Security fixもあるそうですから
アップデートしておいたほうが良いと思います。

アップデート手順のドキュメントが公開されており、基本的にはこのとおりです。
https://github.com/gitlabhq/gitlabhq/wiki/From-2.7-to-2.8
(推奨OSではなく、CentOS 6.2上で動作させていますが、特にこのとおりで問題ありません。))

GitLabのディレクトリでGitを使ってgit pullしてきて、
bundleコマンドをいくらか実行するだけなので、楽ちんですね♪

---

以下は、どちらかといえば私のサーバ環境固有の問題なのですが... (一応メモですｗ)

1. Gitoliteのユーザアカウントに対してホームフォルダを作っていないためそのままでは動作しませんでした。(詳しくは前回の記事を参照)
→ egrepコマンドで"/home/git/"ディレクトリのパスが決め打ちされている箇所を探して書き換えることで対処できました。

2. nginx+Unicornでサブディレクトリ下でGitlabを動作させるために
コードをほんの一部書き換えているのですが、git pullする際に
マージするか、一旦上書きしてしまって再設定する必要がありました。

3. Gitlab2.8以降のGitlab Markdownによってリンクタグ生成処理が変更されており、
Markdown記述内のリンクには、サブディレクトリが含まれませんでした。
(<a href="http://example.com/gitlab/hoge/issues/1">〜〜</a> になってほしいところが<a href="http://example.com/hoge/issues/1">〜〜</a> になるという。)

→こちらは追加の変更で対処できました： (下線の箇所にサブディレクトリパスを記述)

/lib/gitlab/markdown.rb: 147行:

link_to("##{identifier}", 'gitlab/'+ project_issue_path(@project, issue), html_options.merge(title: "Issue: #{issue.title}", class: "gfm gfm-issue #{html_options[:class]}")) 

同じ感じで...153行、159行、165行目にもパスを追加していきます。

以上です。

GitLabのサブディレクトリの件、もし不具合なのであれば、
GitHubで報告したいのですが、以前からサブディレクトリ対応については
ドキュメントでも触れられていませんし・・・仕様なのかなと。
もし宜しければ、どなたかお願いしますm(_ _)m

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 ディレクトリへのデプロイ