Gitlab CI 3行まとめ

Gitlab CIはGitLabで使える。CircleCIみたいなもん。最初にちょっとセットアップすれば、Jenkinsより簡単・便利。カバレッジとか成功時にデプロイとか出来る。
GitLab RunnerというCIで使うコンテナを動かすサーバーの構築が必要になるが、必要な作業は大体これだけ。あとはアプリケーション側で設定する。
GitLab使ってたら使っていいと思う（特にアンチJenkins）

GitLab CIについて

Ruby + Go, Dockerを使っている
8.2位からGitLabの機能に統合された。
.gitlab-ci.ymlにcircle.ymlっぽいDSLを書いていく
Push/MergeRequestをきっかけにCIが勝手に走る。
後述する、GitLab Runnerの構築が必要になる。

GitLab CIで Railsプロジェクトをテストするまで

GitLab Runnerの構築

GitLab RunnerはCircle CIやTravis CIでいうところのコンテナを動かすサーバみたいなもん。 GitLabと連携して使う。

今回は、GitLabとは別のVPSサーバにRunnerを構築するという構造を想定している。

ほとんど手順に書いてあるまんま作業した。 gitlab.com

気をつけないといけないのはGitLabとGitLab Mulit Runnerの紐付け位なので、ここの解説だけしておく。

sudo gitlab-ci-multi-runner register

# Runnerを使用したいGitLabのURL + /ci を入力する。
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/ci ) 
https://gitlab.example.com/ci

# https://gitlab.example.com/admin/runners にRunnerに対して入力するTokenが存在するのでそれを入力
Please enter the gitlab-ci token for this runner 
xxx

# Runnerの説明を入力する。
Please enter the gitlab-ci description for this runner 
my-runner

INFO[0034] fcf5c619 Registering runner... succeeded
Please enter the executor: shell, docker, docker-ssh, ssh? # 実行方式を選択する
docker

# デフォルトで使用するDocker Imageを入力する
Please enter the Docker image (eg. ruby:2.1):
ruby:2.1

これでGitLab Runnerの設定は完了。 GitLabのAdminAreaにさっき構築したRunnerが表示されてればOK。今回は説明は割愛するけど、リポジトリ専用で使用するRunnerを作成したりということも可能。

これは別のサーバにRunnerを構築するときの手順だけど、GitLabが入っているサーバにRunnerを構築することも可能だと思う。

並列実行とかについてはよくわからない。

GitLab CI Multi Runnerの設定は /etc/gitlab-runner/config.toml にはいってるので、なにか変更したいときは覗いてみよう。

Railsアプリケーション側の設定

構成としては自分が身近に使っている Rails(4.2.4) + mysql (5.6)+ rspec(3.4)という感じでとりあえずテストできるようにするところまでをまとめた。 GitLab CIに関わる設定・実装以外は割愛しています。

正直、mysqlに接続できないところで一番はまってたので、多分これ見てやればハマらないかと。

CI用に config/database.ci.ymlを作成しておく。

default: &default
  adapter: sqlite3
  pool: 5
  timeout: 5000

development:
  <<: *default
  database: db/development.sqlite3

# (確かこの辺はDocker Imageに依存している設定。)
test: &test
  adapter: mysql2
  encoding: utf8
  pool: 5
  username: root
  password: sample_repo
  host: mysql
  port: 3306
  database: sample_repo

production:
  <<: *default
  database: db/production.sqlite3

.gitlab-ci.ymlを以下の内容で作成。

image: ruby:2.2

services: (ここに使用するミドルウェアのDocker Image等を書いていく)
  - mysql:5.6

variables: (ここでDocker ImageのMysql Root Passwordを設定するようなイメージ)
  MYSQL_ROOT_PASSWORD: sample_repo

before_script:
  - cp config/database.ci.yml config/database.yml
  - bundle install --jobs $(nproc) --path=/cache/bundler

test:
  script:
    - bundle exec rake db:setup RAILS_ENV=test
    - bundle exec rspec
  tags:
    - ruby
    - mysql

あとは、コミットして、Pushすればよい。既に連携されているので、実況状況や結果もすぐに眺めることが出来る。

あとは、カバレッジなんかも計測できる。これはリポジトリの設定画面かなんかで設定するものだった気がするけど。

commit messageに [ci-skip]って入れとくとCIが走らないようにもなっている。

bundle installのところでおまじないチックなコマンド書いてるけど、これはbundle installの結果をcacheさせるため。 Gemfile.lockが更新されているときはちゃんとアップデートしてくれる。

あとのやりたいことはドキュメント見ればなんとなくわかるので、こちらを参照して欲しい。 GitLab Documentation

herokuのデプロイ例なんかも載っているし、EngineYardでもCapistranoでも問題ないと思う。

Jenkinsと比べた時によいところ

良かったところは、Jenkinsを使ってDockerを使ってクリーンな環境でテストがやりたい時にちょっと面倒だったのが、これだとパッケージインストールするのと少しの設定だけであっさり出来てしまうこと。

CIとGitLabとの連携も、GithubとCircleCIのそれよりは面倒だけど、Jenkinsより圧倒的にラク。介護する人は必要かもしれないけど、Jenkinsより管理コストは低い気がする。

総括

正直なところ、おすすめできるかどうかは微妙。使ってて壊れたり、ハマったりっていうのは今のところ無いけど、壊れない保証はない。0.7.xでまだまだ開発中だし。僕はこれを結構気に入ってて~~(選択の余地なくて)~~、人柱になってますが。

不安定な可能性があることが問題ないと思えて、GitLabを使ってて、CIに凝った設定とかしてなければマジでオススメ。管理しなきゃいけない項目もそんなに無いし。

知見はそこまで無いけど、Docker知ってる人がいれば大体大丈夫だと思う。正直なところ、なにかコンテナ関連でハマるとすれば、凝ったテストとかをやりだそうとした時だと思う。

GitLab CIを触って暫くたったので雑な感想

2016-02-17 17:00:00 +0900