GitLab Advent Calendar 2018 3日目の記事です。
はじめに
GitLab CIを運用するにあたり、ジョブの実行時間を早くする為に実施した設定の見直し等をまとめます。
環境
GitLab (CE) : 11.2.3
GitLab Runner : 11.2.0
Tips
並列実行数を増やす
Runnerが同時に処理することのできるジョブの数を増加させます。
GitLab Runnerサーバの/etc/gitlab-runner/config.toml
ファイル内の先頭にあるconcurrent
を変更することで設定できます。
デフォルトでは1になっていますが、サーバのスペックと相談して適宜増やしましょう。
下記はジョブの並列処理数を3に変更した例です。
concurrent = 3
cacheを使う
.gitlab-ci.ymlのcache
で指定ディレクトリ/ファイルをパイプラインやjob間で共有することができます。
例として、下記の定義ではnode_modulesをjob1からjob2に渡しています。
image: node
job1:
script:
- npm install
cache:
paths:
- node_modules/
job2:
script:
- npm run hoge-script
cache:
paths:
- node_modules/
policy: pull
cacheの共有範囲は、cache:key
で指定が可能です。
branch毎のcache
cache:
key: "$CI_COMMIT_REF_SLUG"
paths:
- node_modules/
job毎のcache
cache:
key: "$CI_JOB_NAME"
paths:
- node_modules/
cache:key に使える変数はPredefined variablesのみです。
なお、キャッシュを削除したい場合はjobの中に削除する処理を仕込むか、PipelinesページでClear Runner cachesボタンを押下する。(実際にはcacheの実体が削除されるのではなく、cache:keyの接尾辞をインクリメントする。)
runnerのif-not-present policyを使う
RunnerのexecutorがDocker
の場合にjobはDockerコンテナ上で実行されますが、その際に利用するDockerイメージは都度プルされます。
イメージのサイズが大きい場合、プルの時間がjobの実行時間を占める割合が大きくなり得ます。
job実行時のDockerイメージのプルの挙動を定義するのがpull_policy
です。
- always
- 常にイメージをプルします。デフォルト。
- if-not-present
- Runnerサーバ上にイメージが存在するか確認し、存在しない場合のみプルします。
- never
- 常にイメージをプルしません。
pull_policyはRunnerの登録時のオプション--docker-pull-policy
で指定できます。
gitlab-runnner register --docker-pull-policy "if-not-present" [other options...]
登録済みのRunnerのpull_policyを変更する場合は/etc/gitlab-runner/config.toml
の該当Runnerに下記のように設定を追加します。
[[runners]]
name = "123abc456"
url = "http://localhost:9000/ci"
token = "your token"
executor = "docker"
[runners.docker]
tls_verify = false
image = "docker:latest"
privileged = true
disable_cache = false
volumes = ["/cache"]
shm_size = 0
pull_policy = "if-not-present" # 追加
[runners.cache]
Docker in Dockerを使わない
Docker in Dockerでdocker-composeを利用したジョブの実行などやりがちですが、dindの場合はDockerイメージは上述のif-not-present policyの恩恵を授かれません。
docker-composeではなく、実行するメインのイメージ以外はservicesに列挙することで、if-not-present policyにより各イメージのプルも省略できます。
もちろん、Dockerイメージのビルドなどジョブの中でdockerコマンドが必要なものは適宜dindを使うべきです。
最後に
まだまだ速度改善できる手法はたくさんあるかと思いますが、まずはお手頃に設定できるところからの紹介でした。
マシンパワーで全て解決する前に、一度CIの設定・構成を見直してみるのもよいかと思います。