GitLab6.4をCentOS5.5にインストールした
インストール用のchefクックブックが公式から出てたりいろんな環境でインストールした例があったりして楽に構築できると思ってたらそんなことはなかった。多分CentOS5系に入れたからなんだろうと思うけど。全部まとめる気力もログも残っていないが、ハマリポイントだけまとめておく。
参考にした資料
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md
基本はこれを参考にしてインストール
https://github.com/gitlabhq/gitlab-public-wiki/wiki/Unofficial-Installation-Guides
CentOS5.x系とかOSXとかGentooとかの環境でのインストールガイド一覧(非公式)
この中ではhttp://www.digitalsanctuary.com/tech-blog/general/installing-gitlab-on-redhat-enterprise-5-rhel-5.htmlを参考にした
icuのインストール
GitLab6.4はrubyというかrailsでできているけども、そのなかでcharlock_holmesというgemを使っている。で、そのgemが利用しているlibicuがCentOS5系にあるものだと古すぎて使えない。なのでicuをソースからインストールして、さらにgitlabをcloneしてきてbundle installすると、同時にcharlock_holmesもビルドされるのでそのビルドオプションとしてicuのインストール場所を明示的に指定してあげないといけない。
mysqlのバージョン
CentOS5系のyumでインストール出来るmysqlは5.1。 そのままmysql5.1をインストールして進むと、railsのmigrationでコケる。というのはテーブルをmigrationが作ってくれる際にインデックスのキープレフィックスの最大値にひっかかってしまうのだ。これを回避するためのinnodb_large_prefixというオプションがあるのだけど、これが使えるのがmysql5.5.14以降とのことなので、結局現時点での最新のmysql(5.6.15)をいれてなんとかした。
nginxのバージョン
どうにか入ったと思って色々動かしていたら、今度はhttp経由でのcloneが出来なかった。 これまたCentOS5系のyumで入るnginxのバージョンじゃアカンというやつだった。 https://github.com/gitlabhq/gitlabhq/issues/5774 ので、これも最新安定版の1.4.4のrpmを入れて対処した。
あげてみればたったこれだけだが、実感としてもっと時間かかってた気がする。1番目のicu周りが上手く行かなくてrailsのvendorディレクトリごと消し飛ばしたせいでvendor/assetsが参照できなくなってassets:precompileがうまくいかないとか変な所で時間使ってた覚えがある。