gitlab-runnerをspecificからsharedに設定変更する。

1. はじめに

• 「GitLab CI環境でsphinx文書をビルドしてGitLab Pagesにデプロイする」にてrunnerを登録したのですが、このプロジェクトからMkDocsプロジェクトにforkしようと思うと、プロジェクト間で共有できるrunnerがほしいと思いました。
• そのため、specific-runnerで登録したrunnerをshared-runnerで登録し直しを実施します。

2. 参考ページ

• GitLab on DockerのGitLab-Runnerの設定手順
  • 変更手順は、ほぼこのページの記載通り。私のこのページは作業履歴状態。
• GitLab CIにて、kanikoでDockerイメージの更新をする
  • 現状の設定状況。ここから改造していきます。

3. 設定しなおし

3.1. specific runnerの登録解除

• 「Settings」→「CI/CD」からRunnersの項目を広げて表示します。
• 「Remove runner」を押下すると消えます。

3.2. runner設定の退避

• gitlab-runnerコンテナの設定ファイル(/etc/gitlab-runner/config.toml)をどこか別のところに移動します。
  • この退避は、再利用が目的ではなく、gitlab-runner register後に手動で追加した設定を確認するために退避しています。
• 私の環境では、gitlab-runnerをコンテナで作成しているため、以下のような流れで実施しました。
  • gitlab-runnerコンテナを停止&削除します。
  • ホスト側で、コンテナマウントディレクトリ内にあるconfig.tomlを別のディレクトリにmvします。
  • その後、gitlab-runnerコンテナを生成&起動します。

3.3. specific-runnerの登録

※root権限持ちのユーザでGitLabにログインすること

• 「Admin area」→「Runners」を開き、runnerのtokenを確認する。

• gitlab-runner内にて、以下ようにregisterを実行します。

$ gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=24 revision=7a6612da version=13.12.0
Running in system-mode.                            

Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlab-ce.com:8443/          # ユーザ入力 
Enter the registration token:
7FZPrpiXsHfxvzCswjsN                 # ユーザ入力
Enter a description for the runner:
[runner]: executor: docker           # ユーザ入力
Enter tags for the runner (comma-separated):
docker,shared                        # ユーザ入力
Registering runner... succeeded                     runner=7FZPrpiX
Enter an executor: docker-ssh, shell, ssh, custom, docker, docker+machine, docker-ssh+machine, kubernetes, parallels, virtualbox:
docker                               # ユーザ入力
Enter the default Docker image (for example, ruby:2.6):
centos:7.6.1810                      # ユーザ入力(テキトーに入力した)
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded! 

• 再度「Admin area」→「Runners」を開くと、runnerが登録されていることがわかります。

tag登録するとき

• tag登録するときは、executorの情報をtagの一つに設定すると後から見たときにわかりやすいです。
  • gitlab-runnerはGitLabからではどのexecutorで動作するかがわからないためです。
  • 私は、discriptionにもexecutorの情報を記載します。

3.4. specific-runnerのconfig修正

※ GitLab CI環境でsphinx文書をビルドしてGitLab Pagesにデプロイするで設定したネットワーク設定等を追加していきます。

• gitlab-runnerコンテナを停止&削除して、コンテナマウントディレクトリ内にあるconfig.tomlを開き、以下の項目を追加します。
• 追加後、gitlab-runnerコンテナを生成&起動します。

concurrent = 1
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "executor: docker"
  url = "https://gitlab-ce.com:8443/"
  dns = "192.168.10.253"             # 追加（各自の環境に合わせてください）
  token = "p8d2ABh2xkMUJuburyVB"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "centos:7.6.1810"
    privileged = false
    network_mode = "devops_mynet"    # 追加（各自の環境に合わせてください）
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0

3.5. プロジェクトの.gitlab-ci.ymlの修正

• tag指定を変更する。
  • ここでは、「sphinx」から「shared」に変更しました。

stages:
  - build
  - deploy

docker-build:
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  stage: build
  tags:
    - shared     # 変更
  only:
    changes:
      - Dockerfile
    refs:
      - master
  script:
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"auth\":\"$REGISTRY_TOKEN_AUTH\"}}}" > /kaniko/.docker/config.json
    - cat $REGISTRY_CERT >> /kaniko/ssl/certs/ca-certificates.crt
    - TAG=`echo "$CI_COMMIT_SHA" | cut -b -8`
    - /kaniko/executor --context ./ --dockerfile ./Dockerfile --destination $CI_REGISTRY_IMAGE/sphinx-rtd-container:$TAG --destination $CI_REGISTRY_IMAGE/sphinx-rtd-container:latest

pages:
  image: gitlab-ce.com:25000/developer/study-page/sphinx-rtd-container:latest
  stage: deploy
  tags:
    - shared     # 変更
  script:
    - make html
    - mv build/html/* public/
  artifacts:
    paths:
      - public
  only:
    refs:
      - master

おわりに

• shared runnerは、なんだかんだ使い回しができて楽です。
  • ただし、一つのrunnerを使い回しすぎると、job待ちが発生するので、stage別や用途別、runnerデプロイサーバの特性別に各種runnerを用意するといよいと思っています。
• 後の記事にて、sphinxプロジェクトからMkDocsプロジェクトにforkさせるときに役立つと信じています。