ラベル git の投稿を表示しています。 すべての投稿を表示
ラベル git の投稿を表示しています。 すべての投稿を表示

2013/02/18

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

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

今回は新しいVPSにもJenkinsをインストールして、スレーブにしてみました。
この記事では、スレーブを構築&設定する手順を、書いておきます。(自分用メモとしてw)
  • スレーブ側では、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
  4. (マスター側の.sshディレクトリには既に、マスター自身のJenkinsが Gitリポジトリに接続するための鍵があるわけですので、今回は別の名前にします。)
  5. [スレーブ] カギ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に変更する。
    もしくは、他のユーザを作成する。(セキュリティ的には後者のほうが安全...か?)
  6. $ sudo -u root vi /etc/passwd
    ~~~~
    jenkins:x:xxx:yyy:Jenkins Continuous Build server:/var/lib/jenkins:/bin/bash
  7. [スレーブ] カギBを .sshディレクトリ(/var/lib/jenkins/.ssh/)に作成。
    $ sudo -u jenkins ssh-keygen
    > /var/lib/jenkins/.ssh/id_rsa
  8. [スレーブ] カギ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
  9. [クライアント] カギBの公開鍵(id_rsa.pub)の中身を、GitLab(もしくはGitolite)のJenkinsユーザのSSH鍵に登録。
    (GitLabを使っているならば、先日の記事と同様に、Webブラウザからjenkinsアカウントでログインして、SSH Keys画面から鍵の追加を行います。)
  10. [スレーブ] 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されたディレクトリは、すぐに削除して構いません。)
  11. [クライアント] マスターのJenkinsのノード管理画面で、ノードを追加する。

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

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

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

2012/11/04

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/

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

2.9での変更点は以下の通り (公式ブログより抄訳)
  • 400コミット以上の素晴らしいコード
  • コメントの表示順を変更 (Wallを除く)
  • omniauthのサポート (twitter, google…)
  • Bunch of stuff の修正 (訳注: たくさんのモノ/諸々 とでも訳しておきますかw)
  • 多くのコードのリファクタリング
  • 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"という文字を入れておくと、カウントしてくれます。
こういう機能も他のプロジェクト管理システムだとプラグインで使えたりしますが、
標準で実装されるのはちょっと嬉しいですねw
(尚、軽めにぼかし入れてますが、開発中のモノです。見えてもいいんですけど一応軽くw )
Trac,Redmine,etc...を使っていると、
欲を言えば、GitLabはモノ足りないかなーと思うことが無いこともないんですけど、
それでも...必要十分以上の機能は揃っているわけです。
毎日のように使うツールですから、”シンプル”であることは大切だと思います。
開発メンバーが増えたときの慣れやすさを考えてもそうですしね。




2012/09/12

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コマンドをいくらか実行するだけなので、楽ちんですね♪



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

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

2012/08/06

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っぽいですねw 続いて...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なはずです。たぶん(汗;←

2012/06/24

Git+Gitoliteを使い始める

実は今までまともにGitを使ったことが無い(git cloneくらいしかないw)ので
この機会に実際にGitを使い初めて学んでみることにしました。
慣れてきたらSVNから徐々に移行していきたいつもりです。

尚、この記事は私のメモが目的であり、
申し訳ありませんがあまり役に立たないかもしれません。ご了承ください(汗;)
参考になる情報をお探しの方は、この記事の最後にある参考ページを。

さて、まずは...手始めにサーバ上でGitをインストールします。
server: $ sudo yum install git
さらに、リポジトリとユーザ管理を容易にしてくれる gitoliteをインストール。
server: $ sudo yum install gitolite
このとき、インストールと同時に、gitoliteというユーザがサーバ上に追加されます。

さて..gitoliteはユーザを認証鍵で識別するため、そのための鍵を作る必要があります。
(参照:この仕組みについては、gitoliteはどうやってユーザを判別しているか - SELECT * FROM life;が参考になりました。)
ですので、クライアントとなるPCで・・・
まず、gitolite用にいつもとは別の鍵を作成します。
client: $ ssh-keygen -t rsa 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hoge/.ssh/id_rsa): ~/.ssh/gitoliteEnter passphrase (empty for no passphrase): #空でEnter
Enter same passphrase again: #空でEnter
Your identification has been saved in /home/hoge/.ssh/gitolite.
Your public key has been saved in /home/hoge/.ssh/gitolite.pub.
The key fingerprint is:
〜〜〜〜
The key's randomart image is:
〜〜〜〜
これで、"gitolite"と"gitolite.pub"というファイルが、~/.ssh/下に生成されます。

さらにこの鍵を使うために、~/.ssh/configへ記述をしておきます。
client: $ vi ~/.ssh/config 
HOST git.example        USER            gitolite
        HOSTNAME        example.com        PORT            22        IDENTITYFILE    ~/.ssh/gitolite
こんな感じで。git.exampleは識別名なので何でも構いません。(あとで利用)
HOSTNAMEとPORTは、それぞれサーバのアドレスとSSHポート番号を指定します。

あとは、gitolite.pubをサーバの/tmp/あたりに転送します。(SCPか何かで適当に。)
client: $ scp ~/.ssh/gitolite.pub hoge@example.com:/tmp/gitolite.pub
今度はサーバ側で、アップロードしたファイルのパーミッションを変更。
server: # chmod a+r /tmp/gitolite.pub
さらに、gitoliteとしてログインしなおし...gitoliteの設定を行ないます。
server: $ su - gitolite 
server: $ gl-setup /tmp/gitolite.pub
The default settings in the rc file (/var/lib/gitolite/.gitolite.rc) are fine for most
people but if you wish to make any changes, you can do so now.
hit enter... #Enterキーで続行。#続けて.gitolite.rcがエディタで開きますが、気にせずそのまま閉じます。creating gitolite-admin...
Initialized empty Git repository in /var/lib/gitolite/repositories/gitolite-admin.git/
creating testing...
Initialized empty Git repository in /var/lib/gitolite/repositories/testing.git/
[master (root-commit) 〜] gl-setup /tmp/gitolite.pub 2 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/gitolite.pub 
server : $ exit
このとき、サーバ上に、"testing"というサンプルのリポジトリと、
"gitolite-admin"というリポジトリが自動生成されます。

このgitolite-admin リポジトリは、Gitolite管理用リポジトリとなります。
なぜかというと・・・・ここに対して設定ファイルをコミットしていくことで
Gitoliteの設定変更(Gitリポジトリの生成といった管理操作も!)ができるという仕組みなのです。面白いですね!!

さて今度はクライアント側から、この"gitolite-admin"リポジトリをgit cloneしてみます。
適当なディレクトリへcloneします。これでcloneされたローカルリポジトリが生成されるわけですね。
(アドレスは実際のサーバアドレスは指定しません。
git.exampleとしているように、先程設定した識別名を指定します。)
client: $ cd ~
client: $ git clone ssh://git.example/gitolite-admin
git cloneが成功しました。
試しに新しいリポジトリでも作ってみます...(ここではrepo1というリポジトリを作ってみる。)
cloneされたディレクトリ下にある conf/gitlite.conf をエディタで開き、記述を追加します。
client: $ cd gitolite-admin/
client: $ vi conf/gitolite.conf  
repo    gitolite-admin
        RW+     =   gitolite
repo    testing
        RW+     =   @all
#以下...追加
repo    repo1
        RW+     =   @all
そして...ローカルリポジトリへのコミット
client: $ git add .
client: $ git commit 
エディタが起動して、コミットログを編集する画面になるので、以下のように先頭の#を削除して終了。
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
 On branch master
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
        modified:   conf/gitolite.conf 
ローカルリポジトリへのコミットが実行されます。 
[master 21e408a]  On branch master  Changes to be committed:    (use "git reset HEAD <file>..." to unstage)
 1 files changed, 2 insertions(+), 0 deletions(-)
最後にローカルリポジトリをサーバへプッシュします。
client: $ git push
サーバ側で作業することなくこれだけでリポジトリが追加されます。
なんだこれは便利www

あとは他のユーザをgitoliteに追加するとか、
RedmineにGitリポジトリを設定するとかあるのですが、それはまた (^^)/♪



参考にさせていただいたサイト(感謝♪!):

2012/02/22

nginxをEPELから導入して最新版上書き&モジュール導入

nginxをEPELから導入したいと思います。
最新版は1.0.12ですが、EPELには最新版がありません。
また、nginxのモジュールの組み込みにはビルドしなおす必要があります。

だったら完全にソースから...となるのですが、それはそれでinit.dの準備などなど面倒です。
そのため、EPELからnginx-0.8.55-1を取得して...これを基に、
nginx-1.0.12と、モジュール ngx_cache_purge-1.5 を適用します。

今回は...
http://sakuratan.biz/archives/4582 と
http://sakura.off-soft.net/centos/apache-nginx-1-reverse-proxy-install.html

を参考にさせていだきます。感謝♪
(参考というか大半写しですね...自分用のメモを兼ねているのでお許しを m(_ _)m
以下の内容を参考にされる方は、そのまえに上記のサイトをじっくりお読みください。

前準備にパッケージをインストール。
$ sudo yum --enablerepo=epel install make automake gcc gcc-c++ rpm-build spawn-fcgi pcre-devel zlib-devel openssl-devel libxslt-devel GeoIP-devel gd-devel

次にEPELからnginxのSource RPMをダウンロード。
nginxの最新版は1.0.12なわけですが、ここにあるのは0.8.55-1。
http://dl.fedoraproject.org/pub/epel/5/SRPMS/repoview/nginx.html
$ wget http://dl.fedoraproject.org/pub/epel/5/SRPMS/nginx-0.8.55-1.el5.src.rpm
インストール。
$ sudo rpm -ivh nginx-0.8.55-1.el5.src.rpm
警告: グループ mockbuild は存在しません - root を使用します

とりあえず、このエラーは無視で構わないそうです。

次は、このインストールしたnginxに対して
最新版のnginxとモジュールで上書きをします。


まずはインストールしたソースディレクトリへ移動して...
$ su
# cd /usr/src/redhat/SOURCES
nginxの最新版(1.0.12)のパッケージをダウンロード。
# wget http://nginx.org/download/nginx-1.0.12.tar.gz
次に、ngx_cache_purge モジュールの最新版(1.5)のパッケージをダウンロード。
# wget http://labs.frickle.com/files/ngx_cache_purge-1.5.tar.gz
さらに、SPECファイルを編集します。
SPECディレクトリへ移動して、nginx.specをエディタで開きます。

# cd /usr/src/redhat/SPECS
# cp nginx.spec nginx.spec.org
# vi nginx.spec
11行目付近:バージョン番号を変更。
Version:        1.0.12

42行目付近:モジュールのパッケージファイル名を追加。
Source10:   ngx_cache_purge-1.5.tar.gz

51行目付近:パッチのための記述をコメントアウト。
#Patch0:     nginx-auto-cc-gcc.patch

60行目付近:同様にコメントアウト。
#%patch0 -p0

61行目付近:ビルド前処理としてモジュールパッケージを展開する記述を追加。
%setup -T -D -a 10

69行目付近:文字コードを設定する記述を追加しておきます。
export LANG='ja_JP.UTF-8'

106行目付近:モジュールを追加しているため、ここの記述も書き換え。
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --add-module=%{_builddir}/nginx-%{version}/ngx_cache_purge-1.5
make %{?_smp_mflags}

110行目付近:モジュールのドキュメントファイルの名前を変更する記述を追加。
mv ngx_cache_purge-1.5/CHANGES ngx_cache_purge-1.5/CHANGES.ngx_cache_purge
mv ngx_cache_purge-1.5/README.md ngx_cache_purge-1.5/README.ngx_cache_purge

168行目付近:モジュールのドキュメントファイルをnginxに追加。
%doc ngx_cache_purge-1.5/CHANGES.ngx_cache_purge ngx_cache_purge-1.5/README.ngx_cache_purge

これで上書きします。

あとは・・・ビルド。
# rpmbuild -bb nginx.spec
〜〜〜
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-1.0.12-1.x86_64.rpm
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-debuginfo-1.0.12-1.x86_64.rpm
実行中(%clean): /bin/sh -e /var/tmp/rpm-tmp.56019
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd nginx-1.0.12
+ rm -rf /var/tmp/nginx-1.0.12-1-root-root
+ exit 0

ビルドが終わったようです。
あとは、今できあがったパッケージをインストールします。
# cd ../RPMS/x86_64/
# rpm -Uvh nginx-1.0.12-1.x86_64.rpm

これで完了ですね。