読者です 読者をやめる 読者になる 読者になる

そんな今日この頃でして、、、

コード書いたり映画みたり。努力は苦手だから「楽しいこと」を探していきたい。

GitLab CIをDockerで導入してみた

業務じゃ運用っぽいことやってるくせにCI(継続的インテグレーション)まわりを全然カバーできてないのはそろそろ恥ずかしいので、 自宅サーバで色々動かして勉強してみようという試み。

(以前に軽くJenkinsはさわったことあるけど、スペックとかの問題でまともには運用できてなかったんだよな・・・)

今回導入してみたのはGitLab CI

会社でも自宅でもプライベートリポジトリとして利用しているGitLabなのだが、 都合が良いことに8系からはCI機能が統合されたらしい。

GitLabのCI機能を使うためにはあとはRunnerというビルド等を行う側を用意さえすればよいのだが、 こちらも幸いなことに本体同様にDockerイメージがある。

blue1st.hateblo.jp

そんなわけで、先日のGitLab本体に加えてGitLab CIもDockerで動かしてみることにした。

準備

Dockerイメージの取得

本体側でもお世話になってるsameersbn氏のイメージを使う。

github.com

普通にdocker pullで拾ってきておく。

docker pull sameersbn/gitlab-ci-multi-runner:1.0.0-1

似たような名前のdocker-gitlab-ciというイメージもあるが、 こちらは統合前までのものなので注意。

Tokenの確認

RunnerとGitLabとを接続するために、 GitLabの管理者メニューのRunnerのページのTokenを確認する。

f:id:blue1st:20160228231711j:plain

f:id:blue1st:20160228231720j:plain

URLでいうとhttp://[ドメイン]/admin/runnersにある。

Runnerの起動・接続

docker-composeを記述

やっぱり一々オプションを手書きするのは面倒なのでDocker Composeを記述する。

blue1st.hateblo.jp

Githubの記述を参考にしつつ、自分の環境にあわせてドメインやらTokenやらを記載する。

# Ci Runner
GitlabCIMultiRunner:
  image: sameersbn/gitlab-ci-multi-runner:1.0.0-1
  volumes:
    - /srv/docker/gitlab-runner:/home/gitlab_ci_multi_runner/data
    - /etc/localtime:/etc/localtime:ro
  environment:
    - CI_SERVER_URL=http://[GitLabが動いているドメイン]/ci
    - RUNNER_TOKEN=[さっきのToken]
    - RUNNER_DESCRIPTION=[Runnerの名称]
    - RUNNER_EXECUTOR=shell
  restart: always

単体で動かしても良いのだが、どうせ同じサーバ上で動かすということで、今回はGitLab本体のdocker-compose.ymlに追記する形で記述。

kill&up -dで立ち上げ直しておく。

追加の確認

正常に接続されれば、先ほどと同じRunnersページに表示が追加される。

f:id:blue1st:20160228232006j:plain

プロジェクトの設定

対象とするプロジェクトの追加

さっき追加したRunnerのページのEditボタンから設定ページに入る。

f:id:blue1st:20160228232019j:plain

左下に対象とするプロジェクトを選択する箇所があるので、Enableボタンを押して追加していく。

f:id:blue1st:20160228232035j:plain

URLではhttp://[ドメイン]/admin/runners/[RunnerのID]

プロジェクトで使用するRunnerの追加

最後に個別のプロジェクト側のページに移り、設定を行っていく。

プロジェクトのトップから設定ページに入る。

f:id:blue1st:20160228232049j:plain

Runnerページを開き、Disable Shared Runnerボタンを押してEnable Shared Runnerに切り替えておく。

f:id:blue1st:20160228232059j:plain

(この設定もしかすると先にRunnerの方がSpecificになってるからいらないかもしれないんだけど、 RunnerがどこでSharedとSpecificが変更できるのかよくわからないんだよな・・・特に設定変えてないはずなんだけど変わっちゃっててちょっと困惑)

URL的にはhttp://[ドメイン]/[オーナー]/[プロジェクト]/runners

トリガーの設定

同じくプロジェクトの設定ページからTriggersページを開く。

そしてAdd Triggerで新たにトークンを発行する。

f:id:blue1st:20160228232222j:plain

追加すると.gitlab-ci.ymlなんかの記載例が出てくる。

f:id:blue1st:20160228232233j:plain

URLではhttp://[ドメイン]/[オーナー]/[プロジェクト]/triggers


あとは先程の.gitlab-cli.ymlをプロジェクトのディレクトリに追加すれば、 CI機能が動作することを確認できる。

ここより先の部分についてはまだ学習中ということで、今回はここまで。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

  • 作者: David Farley,Jez Humble,和智右桂,高木正弘
  • 出版社/メーカー: KADOKAWA/アスキー・メディアワークス
  • 発売日: 2012/03/14
  • メディア: 大型本
  • 購入: 24人 クリック: 567回
  • この商品を含むブログ (53件) を見る

継続的インテグレーション入門

継続的インテグレーション入門

  • 作者: ポール・M・デュバル,スティーブ・M・マティアス,アンドリュー・グローバー,大塚庸史,丸山大輔,岡本裕二,亀村圭助
  • 出版社/メーカー: 日経BP社
  • 発売日: 2009/08/06
  • メディア: 単行本
  • 購入: 18人 クリック: 388回
  • この商品を含むブログ (37件) を見る