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に変更した例です。

/etc/gitlab-runner/config.toml

concurrent = 3

cacheを使う

.gitlab-ci.ymlのcacheで指定ディレクトリ/ファイルをパイプラインやjob間で共有することができます。

例として、下記の定義ではnode_modulesをjob1からjob2に渡しています。

.gitlab-ci.yml

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に下記のように設定を追加します。

/etc/gitlab-runner/config.toml

[[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の設定・構成を見直してみるのもよいかと思います。

GitLab CIのjobの実行時間改善Tips