スキップしてメイン コンテンツに移動

GitLabをらくらくアップデートする

バージョン管理ツールとしてGitが流行初め、GitHubがスタートしてしばらくしてから、クローズドで自前で設置できるGitHubクローン、GitLabプロジェクトが始まりました。
そんな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環境で開発はおろかインストールなどもそれほど経験なかったですが、これらのセットアップ作業を通して、それとなく慣れてきましたw)

インストールした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以降ではこれらは使えない可能性があります。

コメント

このブログの人気の投稿

さくらのクラウドでマストドンのインスタンスをサブドメインで作る

タイトルに「の」と「で」が多すぎますが気にせずいきますこんばんは。

さくらのクラウドで、いま話題のMastodon(マストドン)のインスタンスを作成してみました。
Mastodonは普通にソースを展開して自分で普通にセットアップする方法や、Docker-composeを用いた方法などがありますが、さくらのクラウドでは、スタートアップスクリプトを用いて、管理画面から必要な項目を入力、スクリプトを選択するだけで簡単に立ち上げることができるようになっています。

さくらのクラウドのMastodonスタートアップスクリプト 実は少し前にこの方法で立ち上げたりもしていたのですが、本当に簡単でサクサクできてもの自体は30分程度で完了します。
管理者ユーザーを作成するには、通常のユーザー登録と同じ手順で画面からユーザーを作成後、一度コンソールからログインして、mastodonユーザーで下記のコマンドを実行する必要があります。

# su - mastodon % cd ~/live % bundle install % RAILS_ENV=production bundle exec rails mastodon:confirm_email USER_EMAIL=登録時のメールアドレス % RAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=作成したユーザーID mastodon:confirm_email でメール受信確認をスキップして承認済みに、mastodon:make_admin で指定したユーザーを管理者に設定します。

これでインスタンス管理者として様々な操作をGUI上から行えます。

同類の記事は恐らく既にたくさんあるので、詳しい作り方に関してはそちらを参考にしてください。

気になるところが 上記のさくらのクラウドニュース内で記載されているMastodonスタートアップスクリプトでの構築方法に関する記事内で、一つ気になるところがありました。
それが
※サブドメイン(例:mstdn.example.com)には対応していません。 という記述部分です。

つまり、このスタートアップスクリプトを利用した場合、サービス専用のドメインを用意する必要があります。
既存のドメインをなるべく利用したい場合には向…

ブログを移転しました(WordpressからBloggerへ)

現在のこのブログを作ってから、長年自前サーバ(VPS)上で動かしていたWordpressで公開し続けてきました。
Wordpressは自由度もあり、カスタマイズ性もあり、また自前での場合はドメインもサーバ設定カスタマイズすら自由で、自分の行いたいようにいじることができました。

しかし、サーバ側のスペックや他の開発サービスとの兼ね合いなどもあり、人が滅多に来ないブログとは言えブログ自体の重さを感じておりました。
そのため、ここ最近はブログ用に別途VPSを借りて高速Wordpressとして売り出されているKUSANAGIを利用して公開したりもしていましたが、所詮趣味ブログであり、特に収益を上げるために書いたり(所為アフィリエイト)と言うことをしているわけでもなく、記事も頻繁に書くほどではなかったので、コスパの問題も出てきました。

そこで以前から計画していたBloggerへの移行を行い、ようやく公開作業が完了出来ました。使いやすさなどを考えると、はてなブログなどを利用するのが恐らく賢明だと思いますが、あれこれしようとすると有料プランで運用する必要があり、どうするかな、というところで悩みました。(VPSに比べれば月額は明らかに安いですが)

Bloggerは日本ではあまりユーザーが多くないように思えますが、ブログホストサービスとしての歴史は長く、またGoogleに買収されてからも安定して稼働しているので、こちらに移行しようと考えました。

Wordpressからの移行はそれほど大変ではないようで、それなりに大変でもありました。

記事やコメントの移行については簡単で、Wordpressの管理画面から「設定」→「エクスポート」で出力されるXMLを保存し、http://wp2blogger.info/ などのサイトへアップロードすることで、Blogger用XMLフォーマットに変換してくれるので、それをBloggerに取り込めば大体終了です。

問題は記事内で使用している画像です。外部サイトから読み込んでいる場合であればそのままでも行けるかも知れないですが、独自にアップロードしていた画像はすべてBloggerへアップロードし直す必要がありました。
またアップロード後も、元のファイル名でのURLにはならず、それぞれGoogleドライブ内で割り当てられているファイル名に変換されるので、一…

PHPで相対パスから絶対URL(URI)を作成する

HTMLページをパースしてURLを取り出す処理を書いていたのですが、ページ内のリンクなどが全部絶対URLで記述されていれば非常に楽なのですが、現実としてそうでもなく、ページによっては相対パスで書かれていたりして、正規表現で偏にリンクからURLを抜き出すだけではうまくできませんでした。

そこで少しググってみたら

PHPで相対パスから絶対URL(URI)を作成する|PHPプログラムメモ|プログラムメモ

という記事を発見!おぉ、これは便利!
と思って使わせてもらおうと思ったのですが、いくつかテストしてみて、相対パス処理で不備があるなーと思ったところがあったのでちょっと改良させてもらいました。

37~38行目は正直いらない気がしたのですが、 PHP 5.3 のCLIでWindows上でテストした際に、なぜか \/ (アルファベットのVではなく、\ と / ) で出力されたのが気になったので、無駄かもしれないけどあえて記述。
あと $parse の初期化もここまでする必要ないけど、念のためNotice対策を…w

相対パスから絶対URLする関数

< ?php
/**
* 相対パスから絶対URLを返します
*
* @param string $base ベースURL(絶対URL)
* @param string $relational_path 相対パス
* @return string 相対パスの絶対URL
* @link http://blog.anoncom.net/2010/01/08/295.html
* @link http://logic.stepserver.jp/data/archives/501.html
*/
function createUri( $base = '', $relational_path = '' ) {

$parse = array (
'scheme' => null,
'user' => null,
'pass' => null,
'host' => null,
'port' => null,
'path' => null,
'query' => …