サーバまるごと移行する話です。
社のサーバでGitLabを運用しているのですが、GitLabとGitLab CI以外にもSlackのロガーやwiki等のサービスが走りまくっており常にスワップが発生する状態でした。加えてGitLab CIの機能の少なさ、障害が発生した時にGitLab Omnibusではどこに問題があるのかわかりづらい(ログが追いづらい)などの問題があったため
- サーバを新調
- GitLabをインストール
- GitLab CIを廃止してJenkinsに移行
という作業を行いました。幸いなことにGitLab CIは使いづらいためあまり使われておらず、CIについては単純に新たにJenkinsを導入するだけで済みました。
基本的には以下の2つのページを参考にすると移行することができます。
http://blog.innobase.co.jp/entry/2014/09/15/174228blog.innobase.co.jp
手順としては
- 移行元のGitLabを最新版にする
- 移行先にGitLabの最新版をインストールする
- 移行元で全データをバックアップする
- 移行先にバックアップを移動してリストアする
になります。バックアップファイルがどこに出現するか、リストア時にどこに置くかなどは自分で調べてください。リストア時に置く場所はその環境(Omnibus or manual install)でバックアップファイルが作成される場所です。
この作業中に少し躓いたのでメモしておきます。
rbenvを使わない方が良い
移行にあたってItamaeで1コマンドでデプロイされるようにしました(かなり雑に書いたので整理する余裕ができるまで公開はしないつもりです)。最初はrbenvを使ってRubyをインストールしていましたが、いろんなところで躓く上にsudoersを書き換えるなどして環境変数を引き継ぐ必要が発生するなどお世辞にも綺麗とはいえないデプロイになるためrbenvを諦めました。そもそもGitLabのためにRubyを入れるので、今後バージョンを上げたいなどの欲求があれば今回と同様にサーバをまるごと移行した上でRubyのバージョンを挙げてしまえば問題ないと考えています。
各レポジトリにhooksへのsymlinkが含まれていてこれが壊れていることがある
この問題はOmnibus→manual installまたはmanual install→Omnibusで発生するものです。各リポジトリにpush時のhookスクリプトを格納するディレクトリへのsymlinkがあります。この実態はgitlab-shell/hooksであり、そのパスはOmnibusの場合とmanual installの場合で異なります。バックアップをとったリポジトリ内には移行元の環境のsymlinkが含まれているため、移行先によってこのsymlinkを作り直す必要があります。手動でやってもスクリプトを作っても問題ないと思います。今回はリポジトリの数が少なかったため手動でsymlinkを貼り直しました。
壊れているかどうかを確認するのは簡単で、sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=productionを実行したときにErrno::ENOENT: No such file or directory @ realpath_rec - /opt/gitlabというようなエラーを吐いていたら壊れています。
以上2点が主な躓いた点です。rbenvに関してはもはや常識といえるのかもしれませんが、結構扱いに慣れていたつもりでも面倒だったので少々残念でした。
今回のサーバ移行でGitLabがかなり快適になったので今後の開発にも力が入りそうです。
