バージョン管理ツールとしてGitが流行初め、GitHubがスタートしてしばらくしてから、クローズドで自前で設置できるGitHubクローン、GitLabプロジェクトが始まりました。
そんなGitLabにはバージョン3.1くらいの時に個人的に導入してみてからお世話になっています。
ブラウザ上からリポジトリ内のファイル一覧からのコードの閲覧、差分比較などが簡単に行え、プロジェクトやユーザ管理も全てブラウザ上から行えるので大変重宝しています。
GitLabは開発状況も活発で、masterブランチでは毎日のように修正やpull requestによる機能追加などが行われていて、masterのアップデートもなかなか楽しみになってきます。
GitLabはRoR(Ruby on Rails)環境で動作し、インストールについては、基本的に公式マニュアルに書かれているとおりに実行すれば動作するまでには行えます。
とはいうものの、各環境毎にRubyのインストール状況などが異なっていたり、Ruby環境構築に慣れていないとまだまだ若干敷居があり、コマンド一発でインストール！などというにはまだまだ遠い状態です。
そのあたりについては各所でGitLabの紹介、インストール記事などがググればすぐに出てくる程度にはなっているので、そのあたりにお任せしましょう。
いまでは日本語でもだいぶ出てきているので、以前ほど戸惑うこともあまりないと思います。
で、今回ここではアップデートについて。
……と、いうほどアップデート自体にはインストールほどの難しい事はまずないです。
公式マニュアル通りにインストールしていれば、
正直、これだけです。
が、現在使っている環境では、GitLab実行ユーザでrbenvを用いてユーザ単位でRuby実行環境を整えています。
そのため、sudoで実行環境のrubyを引き継いでくれません。この状態で上記を実行すると、OS側にインストールされているRubyを用いて実行されるため、利用するモジュールなどにバージョンba-jon差分などが発生し、途中でrakeが止まってしまったりします。
そこで、この自分の環境に簡単にアップデート出来るコマンドを作ってみました。
上記はRedHat系OS(CentOS)で単体で実行可能なスクリプトとして作成しています。
なお、インストール環境は公式マニュアルに準拠するものとしています。
Gitユーザで上記スクリプトを実行を実行した場合、そのままアップデートを実行します。
sudoでgitユーザになって実行した場合、環境変数を一部gitユーザ用のものに書き換えて実行します。
また、GitLab 5.0異常ではGitLab-Shellという独自のGitShellを採用しており、最新版ではそれらのバージョンと連動することとなっているので、なるべくGitLab-Shellも同時にmasterのものに更新するようにしています。
引数としてブランチ名を与えれば、そのブランチ（例えば、5-2-stableなど）を引っ張ってきてアップデートさせることが出来ます。特に引数がなければ常にmasterを参照するようになります。
あとは別途
で再起動すればOK。
で、これを毎回更新の度にコマンドラインでターミナルからスクリプトを叩けばいいのですが、折角なので同プロジェクトで別途公開されているGitLab CIを使って、ブラウザの画面上からボタン一発で更新できる様にしてみようと思います。
GitLab CIのインストールはここでは割愛します。基本的にはGitLabのインストールとそれほど変わらないし、慣れてればそれほど難しくないです。
（実際わたしはそれまでRoR環境で開発はおろかインストールなどもそれほど経験なかったですが、これらのセットアップ作業を通して、それとなく慣れてきましたｗ）
インストールしたGitLab CIからGitLabプロジェクトを作成し、セットアップします。
GitLab CIから更新するには、リモートリポジトリの内容を一旦プロジェクトパス内に引っ張ってくる必要があるため、実行環境とは別に、別途プロジェクトディレクトリを作成しておきます。
今回はGitLab CIの実行ユーザのホームディレクトリに $HOME/projects/gitlab というディレクトリを作成し、その中にあらかじめGitLabプロジェクトをクローンしておきます。
このパス（$HOME/projects/gitlab）をGitLab CIのプロジェクト編集画面でPathに設定します。
Follow branchesには引っ張ってきたいブランチを指定します。masterの他にstableブランチが公開されているので、必要であれば各バージョンのstableブランチをカンマ区切りで指定します。
Scriptsには下記のスクリプトを記述します。
10行目で先ほどのスクリプトのパスを指定して実行しています。
正直、それより前の部分は前述のスクリプトの内容と作業が重複するため必要ないのですが、実行環境でビルドする前にCI環境内でビルドしておくことで、万が一の時に実行環境で作業される前に確認できるのでいいかなーと思い、この二重ビルドの体勢にしています。
このプロジェクトを保存し、あとはプロジェクト内のmasterなり各バージョンのブランチタブ内のRun buildボタンを押せば、最新版のfetch、merge、ビルド、DBマイグレーション、再起動まで全てが実行されます。
ただし、これらをCI上から実行する前に、もう一つ準備があり、そちらも行っておく必要があります。
今回、GitLab CIはGitLab本体とは別ユーザで実行しています。また、サービスの再起動までをも実行するにあたり、そこに至ってはスーパーユーザー権限が必要となります。
そこで、visudoコマンドなどを用いて、sudoresにGitLab CIユーザにこれらの実行を許可する設定が必要となります。
私の環境では下記の様に設定を行っています。
この設定をGitLab実行ユーザーに対してNOPASSWDで設定します。（さもないとbuild実行中にパスワード入力を求められることとなり、ビルドが実行エラーで停止します。
サービスの再起動にあたっては、serviceコマンドを利用しており、引数でgitlab restartまで指定することで、gitlabの再起動のみしか行えないように制限しています。
これでボタン一発で常に最新版を利用する事も出来るようになります。
…と、ここまで来ましたが、最後に注意点があります。
他のプロジェクトでも当てはまることではありますがGitLabこれまでもいくつか大きく改修してきた事がありました。
一つは、4.1までで、採用していたresqueからsidekiqに変更されたこと。
もう一つは5.0で、当初利用していたgitoliteを切り捨て、独自のGitLab-Shellに置き換えたこと。
最も最近では5.1で、これまで利用していたunicornからpumaに置き換えたこと。
これらは、GitLab本体の更新だけでは対応出来ず、起動スクリプトの変更や、関連プロジェクトの別途更新が必要となります。
そのため自動更新に頼り切らず、更新ログなどから関連する部分についても別途手動で更新していく必要があるので、運用時にはこれらの点にも注意してください。
＜2013年6月6日追記＞また、この記事はGitLabをGitLab CI 2.xでの動作を前提としています。GitLab CI 3.x以降ではこれらは使えない可能性があります。
そんなGitLabにはバージョン3.1くらいの時に個人的に導入してみてからお世話になっています。
ブラウザ上からリポジトリ内のファイル一覧からのコードの閲覧、差分比較などが簡単に行え、プロジェクトやユーザ管理も全てブラウザ上から行えるので大変重宝しています。
GitLabは開発状況も活発で、masterブランチでは毎日のように修正やpull requestによる機能追加などが行われていて、masterのアップデートもなかなか楽しみになってきます。
GitLabはRoR(Ruby on Rails)環境で動作し、インストールについては、基本的に公式マニュアルに書かれているとおりに実行すれば動作するまでには行えます。
とはいうものの、各環境毎にRubyのインストール状況などが異なっていたり、Ruby環境構築に慣れていないとまだまだ若干敷居があり、コマンド一発でインストール！などというにはまだまだ遠い状態です。
そのあたりについては各所でGitLabの紹介、インストール記事などがググればすぐに出てくる程度にはなっているので、そのあたりにお任せしましょう。
いまでは日本語でもだいぶ出てきているので、以前ほど戸惑うこともあまりないと思います。
で、今回ここではアップデートについて。
……と、いうほどアップデート自体にはインストールほどの難しい事はまずないです。
公式マニュアル通りにインストールしていれば、
cd /home/git/gitlab
sudo -u git -H git checkout db/schema.rb
sudo -u git -H git pull
sudo -u git -H bundle install --without development test postgres
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
sudo /etc/init.d/gitlab restart
正直、これだけです。
が、現在使っている環境では、GitLab実行ユーザでrbenvを用いてユーザ単位でRuby実行環境を整えています。
そのため、sudoで実行環境のrubyを引き継いでくれません。この状態で上記を実行すると、OS側にインストールされているRubyを用いて実行されるため、利用するモジュールなどにバージョンba-jon差分などが発生し、途中でrakeが止まってしまったりします。
そこで、この自分の環境に簡単にアップデート出来るコマンドを作ってみました。
上記はRedHat系OS(CentOS)で単体で実行可能なスクリプトとして作成しています。
なお、インストール環境は公式マニュアルに準拠するものとしています。
Gitユーザで上記スクリプトを実行を実行した場合、そのままアップデートを実行します。
sudoでgitユーザになって実行した場合、環境変数を一部gitユーザ用のものに書き換えて実行します。
また、GitLab 5.0異常ではGitLab-Shellという独自のGitShellを採用しており、最新版ではそれらのバージョンと連動することとなっているので、なるべくGitLab-Shellも同時にmasterのものに更新するようにしています。
引数としてブランチ名を与えれば、そのブランチ（例えば、5-2-stableなど）を引っ張ってきてアップデートさせることが出来ます。特に引数がなければ常にmasterを参照するようになります。
あとは別途
sudo /etc/init.d/gitlab restart
で再起動すればOK。
で、これを毎回更新の度にコマンドラインでターミナルからスクリプトを叩けばいいのですが、折角なので同プロジェクトで別途公開されているGitLab CIを使って、ブラウザの画面上からボタン一発で更新できる様にしてみようと思います。
GitLab CIのインストールはここでは割愛します。基本的にはGitLabのインストールとそれほど変わらないし、慣れてればそれほど難しくないです。
（実際わたしはそれまでRoR環境で開発はおろかインストールなどもそれほど経験なかったですが、これらのセットアップ作業を通して、それとなく慣れてきましたｗ）
インストールしたGitLab CIからGitLabプロジェクトを作成し、セットアップします。
 |
| GitLab CI プロジェクト設定画面 |
GitLab CIから更新するには、リモートリポジトリの内容を一旦プロジェクトパス内に引っ張ってくる必要があるため、実行環境とは別に、別途プロジェクトディレクトリを作成しておきます。
今回はGitLab CIの実行ユーザのホームディレクトリに $HOME/projects/gitlab というディレクトリを作成し、その中にあらかじめGitLabプロジェクトをクローンしておきます。
mkdir $HOME/projects/gitlab
cd $HOME/projects/gitlab
git clone git://github.com/gitlabhq/gitlabhq.git .
このパス（$HOME/projects/gitlab）をGitLab CIのプロジェクト編集画面でPathに設定します。
Follow branchesには引っ張ってきたいブランチを指定します。masterの他にstableブランチが公開されているので、必要であれば各バージョンのstableブランチをカンマ区切りで指定します。
Scriptsには下記のスクリプトを記述します。
10行目で先ほどのスクリプトのパスを指定して実行しています。
正直、それより前の部分は前述のスクリプトの内容と作業が重複するため必要ないのですが、実行環境でビルドする前にCI環境内でビルドしておくことで、万が一の時に実行環境で作業される前に確認できるのでいいかなーと思い、この二重ビルドの体勢にしています。
このプロジェクトを保存し、あとはプロジェクト内のmasterなり各バージョンのブランチタブ内のRun buildボタンを押せば、最新版のfetch、merge、ビルド、DBマイグレーション、再起動まで全てが実行されます。
ただし、これらをCI上から実行する前に、もう一つ準備があり、そちらも行っておく必要があります。
今回、GitLab CIはGitLab本体とは別ユーザで実行しています。また、サービスの再起動までをも実行するにあたり、そこに至ってはスーパーユーザー権限が必要となります。
そこで、visudoコマンドなどを用いて、sudoresにGitLab CIユーザにこれらの実行を許可する設定が必要となります。
私の環境では下記の様に設定を行っています。
## Git fetch and merge
Cmnd_Alias GIT_MERGE = /usr/bin/git checkout *, /usr/bin/git fetch *, /usr/bin/git merge *, /usr/bin/git pull *, /usr/bin/git diff, /usr/bin/git log *, /usr/bin/git rev-parse *
## Ruby build
Cmnd_Alias GIT_RUBY_BUILD = /home/git/.rbenv/shims/ruby *, /home/git/.rbenv/bundle install *, /home/git/.rbenv/bundle exec *, /home/git/.rbenv/gem *, /home/git/.rbenv/rake *
この設定をGitLab実行ユーザーに対してNOPASSWDで設定します。（さもないとbuild実行中にパスワード入力を求められることとなり、ビルドが実行エラーで停止します。
gitlab ALL=(ALL) NOPASSWD: GIT_MERGE,GIT_RUBY_BUILD,/home/git/bin/gitlab_update,/sbin/service gitlab restart
サービスの再起動にあたっては、serviceコマンドを利用しており、引数でgitlab restartまで指定することで、gitlabの再起動のみしか行えないように制限しています。
これでボタン一発で常に最新版を利用する事も出来るようになります。
…と、ここまで来ましたが、最後に注意点があります。
他のプロジェクトでも当てはまることではありますがGitLabこれまでもいくつか大きく改修してきた事がありました。
一つは、4.1までで、採用していたresqueからsidekiqに変更されたこと。
もう一つは5.0で、当初利用していたgitoliteを切り捨て、独自のGitLab-Shellに置き換えたこと。
最も最近では5.1で、これまで利用していたunicornからpumaに置き換えたこと。
これらは、GitLab本体の更新だけでは対応出来ず、起動スクリプトの変更や、関連プロジェクトの別途更新が必要となります。
そのため自動更新に頼り切らず、更新ログなどから関連する部分についても別途手動で更新していく必要があるので、運用時にはこれらの点にも注意してください。
＜2013年6月6日追記＞また、この記事はGitLabをGitLab CI 2.xでの動作を前提としています。GitLab CI 3.x以降ではこれらは使えない可能性があります。
