🐧

Docker 版 GitLab Runner で CI/CD:Linux 使い（略）Advent Calendar 2024

2024/12/23に公開

Docker

はじめに

これは「Linux 使いになりたい人のための Advent Calendar 2024」の記事です。

筆者は、Web エンジニアを志望する人には、セルフホスト Git サービスを稼働させて利用することをオススメしています。もし Git を使ったことがないなら、Git を学ぶときに、セルフホスト Git サービスを稼働させることも視野に含めながら学習するのが効率的だと考えています。

Docker 版 GitLab Runner で CI/CD

前回まで、3回に渡ってcfssl で自己認証局、サーバー証明書を用意し、それらを使って GitLab コンテナー、Mailpit コンテナーの HTTPS 対応をしました。これで、ようやく GitLab Runner で CI/CD が実行できる準備が済みました。

今回は、GitLab Runner を GitLab へ登録して CI/CD ができるようにしてみましょう。GitLab Runner では CI/CD 実行用に Shell 環境と Docker 環境を用意することができます。

ここでは Shell 環境と Docker 環境の GitLab Runner を用意してみます。専用サーバーを用意するのは大変なので、Docker 版 GitLab Runner を使います。また、用意するものは試用を目的とし、単純な CI/CD 用の処理が動くところまで紹介します。

Shell 環境の GitLab RUnner

Shell 環境で CI/CD を動かすには、開発ツールを一式インストールした GitLab Runner マシンを用意します。Docker 環境でない分、わかりやすいですが、環境のリセットなどがしにくくなります。

Shell 環境の GitLab Runner を Ubuntu Server で用意した場合は、CI/CD 用の処理を準備するには同じ Ubuntu 環境が必要です。最近は Docker があるので、それで開発ができるので、それようの Docker イメージを作って対応することでしょう。

ここで、CI/CD 用の処理をするための Docker イメージがあるなら、それを GitLab Runner で動かせたら楽そうだと思うはずです。たとえば新しい開発ツールを CI/CD に導入することになったら、Shell 環境の GitLab Runner だと、そのマシンに追加インストールが必要になります。手元では、新しい開発ツールをインストール済みの Docker イメージを用意することになるので、それをそのまま使えたら、この手間はかかりません。

ということで、慣れてくると Docker 環境の GitLab Runner が欲しいと思うようになるはずです。

Docker 環境の GitLab RUnner

Docker 環境の GitLab Runner の場合は、ローカルでも動作確認できる Docker イメージを使って CI/CD の実装ができるため、環境を一度構築できたら、使い勝手の良いものとなります。ただし、Shell 環境とはちがった Docker コンテナーを利用することによる制約も出てきます。Docker に慣れていないと、Shell 環境よりも使いにくいと感じるかもしれません。

とくに、セルフホスト Git サービス環境だと、自分で好きに GitLab Runner 用のサーバーを管理できるので、Docker の制約事項で悩む時間がもったいないと感じるときもあるでしょう。このあたりは、自分のスキルや、身につけたい技術に合わせて選択すれば良いはずです。

なお、Docker 環境で CI/CD を動かすには、Docker Engine をインストールした GitLab Runner マシンを用意します。Docker 環境ではコンテナー内で CI/CD 用のジョブを実行するので、クリーンな環境での CI/CD がしやすくなります。同じ Docker イメージを使えば、ローカルでも同じ処理を実行できるので、CI/CD 処理の準備がしやすくなります。

ちなみに、Docker 環境の GitLab Runner を Docker 版 GitLab Runner で動かすことについては、実際に使おうとすると、それなりに Docker について詳しくないとはまることが多いはずです。本格的に使う場合は専用サーバーに通常の GitLab Runner と Docker Engine をインストールした方が良いです。リソール管理なども Docker 版の方がハードルが高いはずです。

ディレクトリー構成

今回用意するファイルのディレクトリー構成は次のようになります。

/workspace/
├── cfssl/server/server.pem ... cfssl で作成したもの
├── gitlab-ce-https-gitlab-runner/ ... Shell 環境
│  ├── compose.yaml
│  ├── backup/
│  └── sample/
│     └── gitlab-runner-shell/
│          └── config.toml
└── gitlab-ce-https-gitlab-runner2/ ... Docker 環境
    ├── compose.yaml
    ├── backup/
    └── sample/
        └── gitlab-runner-docker/
            └── config.toml

なお、これ以降、/workspace は ${WORKSPACE_DIR} と表記します。

また、cfssl と GitLab は最初に紹介済みの記事で用意したものを使います。まだ読んでいない場合は、そちらも目を通して必要な環境について把握をしておいてください。

Shell 環境用 GitLab Runner

それでは、Shell 環境用 GitLab Runner を用意しましょう。

gitlab/gitlab-runner イメージ

GitLab Runner の Docker イメージは Docker Hub の次の URL で公開されています。

https://hub.docker.com/r/gitlab/gitlab-runner

これを使う config.yaml として、次のものを用意します。

name: gitlab-ce-https-gitlab-runner

services:
  gitlab-runner:
    # Ubuntu ベースのイメージ
    image: gitlab/gitlab-runner:latest
    # Alpine ベースの方がサイズが小さい
    # image: gitlab/gitlab-runner:alpine
    container_name: 'gitlab-runner'
    hostname: 'gitlab-runner.local.internal'
    restart: always
    networks:
      gitlab-ce-https-net:
    volumes:
      - type: volume
        source: gitlab-runner-config
        target: /etc/gitlab-runner
    environment:
      TZ: 'Asia/Tokyo'

networks:
  gitlab-ce-https-net:
    name: gitlab-ce-https-net
    external: true

volumes:
  gitlab-runner-config:
    name: gitlab-ce-https-gitlab-runner-config

イメージのベースは Ubuntu と Alpine の選択肢があります。

Ubuntu に慣れているなら、Shell 環境のものは Ubuntu にしておいた方が使いやすいでしょう。ローカルの開発環境の構築方法については Ubuntu の方が資料が多くあり、その知見が流用できます。

Alpine の場合は、Alpine での環境構築についての知見が必要となります。

用意ができたら起動します。

cd ${WORKSPACE_DIR}/gitlab-ce-https-gitlab-runner
docker compose up -d

自己認証局による HTTPS への対応

ここで、GitLab で cfssl による自己認証局で署名したサーバー証明書を使う場合は、GitLab Runner コンテナー側に crt ファイルを用意しておく必要があります。

次のようにして cfssl/server/server.pem を /etc/gitlab-runner/certs/gitlab-ce-https.local.internal.crt へコピーします。

cd ${WORKSPACE_DIR}/gitlab-ce-https-gitlab-runner
docker compose -p gitlab-ce-https-gitlab-runner exec gitlab-runner sh -c '\
    if [ ! -e /etc/gitlab-runner/certs/ ]; then mkdir /etc/gitlab-runner/certs/; fi\
'
docker compose -p gitlab-ce-https-gitlab-runner cp \
    ../cfssl/server/server.pem \
    gitlab-runner:/etc/gitlab-runner/certs/gitlab-ce-https.local.internal.crt

GitLab Runner の登録

それから、GitLab で新しい GitLab Runner のインスタンスを作成します。次の URL へアクセスすると作成ができます。

https://gitlab-ce-https.local.internal:8443/admin/runners/new

このページに、新しい GitLab Runner を GitLab へ登録するためのシェルコマンドが表示されます。内容は次のようになっていて、--token で指定されているトークンの値によって GitLab Runner の登録時に認証されます。新しい GitLab Runner を登録する度に、この値は変わります。

gitlab-runner register \
  --url https://gitlab-ce-https.local.internal:8443 \
  --token glrt-t1_abcdefghijklmnopqr12

このシェルコマンドをコピーし、Docker Compose プロジェクトの gitlab-ce-https-gitlab-runner で用意した gitlab-runner コンテナーで実行します。このとき、対話モードになるので、必要に応じて値を指定して Enter で確定します。

値を指定しない場合は [] 内のデフォルト値が使われます。ここでは、Enter an executor: に shell を指定する以外はデフォルト値のままで良いです。

実行例は次のようになります。

root@gitlab-runner:/# gitlab-runner register \
  --url https://gitlab-ce-https.local.internal:8443 \
  --token glrt-t1_abcdefghijklmnopqr12
Runtime platform                                    arch=amd64 os=linux pid=42 revision=374d34fd version=17.6.0
Running in system-mode.                            
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
[https://gitlab-ce-https.local.internal:8443]: 
Verifying runner... is valid                        runner=t1_qbT1WR
Enter a name for the runner. This is stored only in the local config.toml file:
[gitlab-runner.local.internal]: 
Enter an executor: docker, kubernetes, docker-autoscaler, instance, custom, shell, ssh, parallels, virtualbox, docker-windows, docker+machine:
shell  ← ここで `shell` を入力
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
 
Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

これで、gitlab-runner:/etc/gitlab-runner/config.toml に設定ファイルが生成されます。作成される config.toml の内容は次のようになっています。

concurrent = 1
check_interval = 0
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "gitlab-runner.local.internal"
  url = "https://gitlab-ce-https.local.internal:8443"
  id = 3
  token = "glrt-t1_abcdefghijklmnopqr12"
  token_obtained_at = 2024-12-17T09:50:16Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "shell"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]

他には gitlab-runner:/etc/gitlab-runner/.runner_system_id も作成されます。これらが、この GitLab Runner を動作させるのに必要なファイルとなるので、バックアップしておくと良いでしょう。

docker compose -p gitlab-ce-https-gitlab-runner \
    cp gitlab-runner:/etc/gitlab-runner/config.toml ./backup/
docker compose -p gitlab-ce-https-gitlab-runner \
    cp gitlab-runner:/etc/gitlab-runner/.runner_system_id backup/

GiLab に登録された GitLab Runner は https://gitlab-ce-https.local.internal:8443/admin/runners で確認できます。ここに gitlab-runner.local.internal の GitLab Runner が追加されていることを確認しておきましょう。

サンプルリポジトリで CI/CD

ここでは user001/sample001 リポジトリを作成後、次の URL を開いてテンプレートから次の .gitlab-ci.yml を作成。

https://gitlab-ce-https.local.internal:8443/user001/sample001/-/ci/editor?branch_name=main

内容は次（不要なコメントは省略）。

stages:          # List of stages for jobs, and their order of execution
  - build
  - test
  - deploy

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

unit-test-job:   # This job runs in the test stage.
  stage: test    # It only starts when the job in the build stage completes successfully.
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 60
    - echo "Code coverage is 90%"

lint-test-job:   # This job also runs in the test stage.
  stage: test    # It can run at the same time as unit-test-job (in parallel).
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 10
    - echo "No lint issues found."

deploy-job:      # This job runs in the deploy stage.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  environment: production
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."

実行する処理については、ジョブ単位に指定します。ここでは次の4つのジョブが用意されています。

build-job
unit-test-job
lint-test-job
deploy-job

また、各ジョブには script: の指定が含まれています。ここで実行するコマンドを指定します。コマンド行はリスト（-）で指定します。ここでは echo コマンドで文字列を出力しているだけなので、説明は特に必要ないでしょう。

これを保存してコミットすると、GitLab Runner により、指定したジョブがパイプラインとして実行されます。「ビルド」-「パイプライン」の画面から、これらのジョブの結果などを確認することができます。エラーがおきると、赤色のバツマーク、成功すると緑色のチェックマークとなります。

Docker 環境用 GitLab Runner

それでは、次に Docker 環境用 GitLab Runner を用意してみましょう。

これを使うには、Docker 環境用 GitLab Runner を稼働させるマシンで、Docker Engine とソケットファイルの /var/run/docker.sock 経由で通信可能となっている必要があります。

Ubuntu Desktop マシンで Docker Engine をインストールしてある場合は、そのまま使えます。Windows + Docker Desktop の環境で PowerShell や Git Bash だと使えません。

Windows + Docker Desktop の環境で WSL Ubuntu 経由なら動くはずですが、それについては動作確認をしていません。ネットワーク関連の設定について正しく対応すれば、動くはずです。

docker executor 用コンテナーの compose.yaml

docker executor 用コンテナーの gitlab-ce-https-gitlab-runner2/compose.yaml は次のようになります。

name: gitlab-ce-https-gitlab-runner2

services:
  gitlab-runner2:
    # Ubuntu ベースのイメージ
    image: gitlab/gitlab-runner:latest
    container_name: 'gitlab-runner2'
    hostname: 'gitlab-runner2.local.internal'
    restart: always
    networks:
      gitlab-ce-https-net:
    volumes:
      - type: bind
        source: /var/run/docker.sock
        target: /var/run/docker.sock
      - type: volume
        source: gitlab-runner-config
        target: /etc/gitlab-runner
    environment:
      TZ: 'Asia/Tokyo'

networks:
  gitlab-ce-https-net:
    name: gitlab-ce-https-net
    external: true

volumes:
  gitlab-runner-config:
    name: gitlab-ce-https-gitlab-runner2-config

注目が必要なのは Docker Engine と通信するためのソケットファイルである /var/run/docker.sock をバインドマウントしている点です。これをバインドマウントすることで、GitLab Runner が動作するコンテナーと Docker ホストが通信して、コンテナーの利用ができるようになります。

用意ができたら起動します。

cd ${WORKSPACE_DIR}/gitlab-ce-https-gitlab-runner
docker compose up -d

自己認証局による HTTPS への対応（docker executor）

docker executor 用コンテナーでも、自己認証局による HTTPS 対応した GitLab へ警告なしでアクセスするために、crt ファイルを用意する必要があります。

cd ${WORKSPACE_DIR}/gitlab-ce-https-gitlab-runner2
docker compose -p gitlab-ce-https-gitlab-runner2 exec gitlab-runner2 sh -c '\
    if [ ! -e /etc/gitlab-runner/certs/ ]; then mkdir /etc/gitlab-runner/certs/; fi\
'
docker compose -p gitlab-ce-https-gitlab-runner2 cp \
    ../cfssl/server/server.pem \
    gitlab-runner2:/etc/gitlab-runner/certs/gitlab-ce-https.local.internal.crt

GitLab Runner の登録（docker executor）

それから、次の URL へアクセスして、GitLab で新しい GitLab Runner のインスタンス作成用のシェルコマンドを入手します。

https://gitlab-ce-https.local.internal:8443/admin/runners/new

今回は、docker compose exec コマンドを使って新しい GitLab Runner を登録してみましょう。このコマンドを使うと、コンテナーにアタッチすると同時にコマンド実行できます。

具体的には次のようにします。

docker compose -p gitlab-ce-https-gitlab-runner2 exec gitlab-runner2 \
    gitlab-runner register  --url https://gitlab-ce-https.local.internal:8443 \
    --token glrt-t1_abcdefghijklmnopqr13

対話モードでは、Enter an executor: に docker、Enter the default Docker image に ubuntu:24.04 を指定する以外はデフォルト値のままで良いです。

実行例は次のようになります。

root@gitlab-runner2:/# gitlab-runner register \
  --url https://gitlab-ce-https.local.internal:8443 \
  --token glrt-t1_abcdefghijklmnopqr13
Runtime platform                                    arch=amd64 os=linux pid=49 revision=374d34fd version=17.6.0
Running in system-mode.                            
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
[https://gitlab-ce-https.local.internal:8443]: 
Verifying runner... is valid                        runner=t1_ZFufT-
Enter a name for the runner. This is stored only in the local config.toml file:
[gitlab-runner2.local.internal]: 
Enter an executor: instance, shell, docker, docker-windows, kubernetes, docker+machine, docker-autoscaler, custom, ssh, parallels, virtualbox:
docker  ← ここで `docker` を指定
Enter the default Docker image (for example, ruby:2.7):
ubuntu:24.04  ← ここで `ubuntu:24.04` を指定
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
 
Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

これで、gitlab-runner:/etc/gitlab-runner/config.toml に設定ファイルが生成されます。

GitLab Runner の設定変更

ここでは、作成される config.toml について、いくつか設定変更をします。まずは次のようにしてバックアップします。

cd ${WORKSPACE_DIR}/gitlab-ce-https-gitlab-runner2
DP=gitlab-ce-https-gitlab-runner2
CN=gitlab-runner2
if [ ! -e ./backup ]; then mkdir backup; fi
docker compose -p ${DP} cp ${CN}:/etc/gitlab-runner/config.toml ./backup/
docker compose -p ${DP} cp ${CN}:/etc/gitlab-runner/.runner_system_id backup/

docker executor の場合は、次の設定を変更します。

allowed_pull_policies の設定追加
extra_hosts の設定追加

allowed_pull_policies の設定は、Docker イメージの pull は時間がかかるので、Docker Engine がインストールされたマシンでキャッシュされたものを有効利用するために指定します。こうしておくことで、CI/CD のジョブで常に最新のものを使う必要がある場合は、always を指定、キャッシュで良いものは if-not-present を指定とすることで、キャッシュで良いジョブの実行時間を短縮できます。

extra_hosts の設定は、Docker 版 GitLab Runner コンテナーが起動するコンテナーが GitLab へアクセスするにあたって名前解決をするときに必要なものです。

[[runners]]
（略）
  [runners.docker]
（略）
    volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/builds:/builds", "/cache"]
    privileged = true
    allowed_pull_policies = ["always", "if-not-present"]
    extra_hosts = ["gitlab-ce-https.local.internal:172.17.0.1"]

extra_hosts で指定する IP は、Docker 版 GitLab Runner コンテナーが起動するコンテナーから到達可能な IP アドレスとなっている必要があります。また、ポート番号 8443 はアクセス可能となっている必要があります。このあたりは、ファイアウォールの設定が関係してきます。どのように IP アドレスとポートを開放するかは、使用しているマシンによって変わります。

IP アドレスについては、コンテナーから見える Docker ホストの IP アドレスで良いので、Docker ネットワークのもので良いです。Ubuntu なら ip a コマンドの結果を grep docker でフィルタリングすることでわかります。この例だと 172.17.0.1 となります。

$ ip a | grep docker
8: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

これでうまくいかない場合はマシンが使っている IP アドレスを使います。Ubuntu では、ip a コマンドで IP アドレスを確認できます。手元だと次のようにして抽出できました。この例だと 192.168.0.100 となります。

$ ip a | grep inet | grep -v inet6 | grep -v "br-" | grep -v docker | grep -v virbr | grep -v "127.0.0.1"
    inet 192.168.0.100/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp0s20f3

ちなみに gitlab-runner2 のコンテナーについて IP アドレスを確認したい場合は docker inspect コマンドでわかります。

$ docker inspect gitlab-runner2 | grep IPAddress | grep -v null | grep -v \"\"
                    "IPAddress": "172.18.0.4"

全体は次のようになります。

concurrent = 1
check_interval = 0
connection_max_age = "15m0s"
shutdown_timeout = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "gitlab-runner2.local.internal"
  url = "https://gitlab-ce-https.local.internal:8443"
  id = 1
  token = "glrt-t1_abcdefghijklmnopqr12"
  token_obtained_at = 2024-12-17T07:17:39Z
  token_expires_at = 0001-01-01T00:00:00Z
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    # GitLab Runner が起動する Docker コンテナー用オプションの指定
    tls_verify = false
    image = "ubuntu:24.04"
    privileged = false
    # docker in docker を使うなら privileged = true とする。
    # ただし true とすると セキュリティ上のリスクが上がる。
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    # 次のように Docker ホストのディレクトリーをバインドマウントすることも可能。
    # volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/builds:/builds", "/cache"]
    shm_size = 0
    network_mtu = 0
    allowed_pull_policies = ["always", "if-not-present"]
    # DNS に登録していない GitLab は IP アドレスの指定が必要
    extra_hosts = ["gitlab-ce-https.local.internal:172.17.0.1"]

GitLab Runner 設定変更を反映

設定ファイルを用意したら、コンテナーのファイルを更新します。

cd ${WORKSPACE_DIR}/gitlab-ce-https-gitlab-runner2
DP=gitlab-ce-https-gitlab-runner2
CN=gitlab-runner2
docker compose -p ${DP} cp ./backup/config.toml ${CN}:/etc/gitlab-runner/

それから、設定ファイルの強制リロードをするために kill コマンドへ -SIGHUP オプションをつけて実行します。このコマンドを実行するときは GitLab Runner のプロセス ID が必要なので、pgrep gitlab-runner で取得しています。

DP=gitlab-ce-https-gitlab-runner2
CN=gitlab-runner2
docker compose -p ${DP} exec ${CN} bash -c 'kill -SIGHUP $(pgrep gitlab-runner)'

設定ファイルの強制リロードがされたことを確認するにはログを見ます。kill コマンド実行時に Configuration loaded というメッセージが出力されるので、これがあれば設定反映がされていることになります。

DP=gitlab-ce-https-gitlab-runner2
CN=gitlab-runner2
docker compose -p ${DP} logs -t ${CN}

このコマンドの実行例は次のようになります。

$ DP=gitlab-ce-https-gitlab-runner2
$ CN=gitlab-runner2
$ docker compose -p ${DP} logs -t ${CN}
（略）
gitlab-runner  | 2024-12-17T08:10:09.377828181Z Configuration loaded  builds=0 max_builds=1

GiLab に登録された GitLab Runner は https://gitlab-ce-https.local.internal:8443/admin/runners で確認できます。ここに gitlab-runner2.local.internal の GitLab Runner が追加されていることを確認しておきましょう。

サンプルリポジトリで CI/CD（docker executor）

すでに作成してある user001/sample001 リポジトリで docker executor 版の GitLab Runner を使ってみましょう。簡単なのは .gitlab-ci.yml を次の内容に更新します。

variables:
  DOCKER_DRIVER: overlay2
  DOCKER_TLS_CERTDIR: ""
  FF_USE_FASTZIP: "true"

stages:          # List of stages for jobs, and their order of execution
  - build
  - test
  - deploy

build-job:       # This job runs in the build stage, which runs first.
  stage: build
  tags: [docker]
  image:
    name: 'ubuntu:24.04'
    pull_policy: "if-not-present"
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

unit-test-job:   # This job runs in the test stage.
  stage: test    # It only starts when the job in the build stage completes successfully.
  tags: [docker]
  image:
    name: 'ubuntu:24.04'
    pull_policy: "if-not-present"
  script:
    - echo "Running unit tests... This will take about 60 seconds."
    - sleep 60
    - echo "Code coverage is 90%"

lint-test-job:   # This job also runs in the test stage.
  stage: test    # It can run at the same time as unit-test-job (in parallel).
  tags: [docker]
  image:
    name: 'ubuntu:24.04'
    pull_policy: "if-not-present"
  script:
    - echo "Linting code... This will take about 10 seconds."
    - sleep 10
    - echo "No lint issues found."

deploy-job:      # This job runs in the deploy stage.
  stage: deploy  # It only runs when *both* jobs in the test stage complete successfully.
  tags: [docker]
  image:
    name: 'ubuntu:24.04'
    pull_policy: "if-not-present"
  environment: production
  script:
    - echo "Deploying application..."
    - echo "Application successfully deployed."

ここでは tags: [docker] をつけることで、実行時に docker のタグがついている gitlab-runner2.local.internal の GitLab Runner が使われるようになります。

実行に使う Docker は image: の name: 'ubuntu:24.04' で指定したもので、キャッシュされたものが利用されるように pull_policy: "if-not-present" としてあります。

このイメージは Docker ホストでキャッシュされているものが使えるので、カスタム Docker イメージが必要な場合、自分は Docker イメージビルド用のジョブを用意して、GitLab Runner のマシンが使う Docker ホストでビルドして用意できるようにしています。これができない場合は、ローカルに Docker レジストリ用サーバーを用意するなど、少しハードルが高い作業が必要になります。

セルフホスト Git サービスの場合は、GitLab 経由での Docker イメージのビルドがわからなくても、GitLab Runner のマシンが使っている Docker ホストで Docker イメージをビルドしておけば、GitLab の CI/CD で使えるようになります。

こうしておいた方が、Docker レジストリ用サービスに対しても余計な負荷をかけませんし、ネットワーク負荷の視点からも良いので、指定するようにしています。

ファイルを編集してコミットすると、Docker 版の GitLab Runner が実行されます。

おわりに

これで GitLab Runner による CI/CD の実行ができるようになったので、開発時に自動化できるものをどんどん自動化できる環境が用意できるようになりました。本格的に稼働させるには GitLab と GitLab Runner のための専用マシンが必要ですが、個人でお試しで使う分には、Docker で必要な時だけ動かして利用という環境で十分でしょう。

個人開発以外だと、CI/CD 関連の開発作業をするときに、こういう環境がローカルにあると、リモートにあるリソースを使わなくても動作確認を含めた作業ができるので、全体的に効率よくなります。CI/CD 関連の開発作業を担当する人は、それほど多くはいないはずですが、この機能は開発作業の効率化に対して、それなりにインパクトのあるプロセスを担当する部分となります。実際に担当するときは、重要な役割を担うことになるので、できるだけ効率良く動作するような設計と実装としたいところです。そのためにも、ローカルで試行錯誤できる環境があるというのは重要になります。

ところで、GitBucket + CI 用プラグインの手軽さと比較すると、手間が多かったと感じるはずです。実際のところとしては、GitLab + GitLab Runner が大変というより、HTTPS 環境での GitLab + GitLab Runner が大変なので、HTTP で用意するなら、ここまで大変ではありません。なお、GitBucket でも Jenkins のような CI/CD 用のシステムと HTTPS で連携させようとした場合は、同じように HTTPS 対応をすることになり、結構な手間がかかります。

CI/CD まわりは、HTTPS 対応のハードルの高さがあって、個人環境で用意しようとまでは、なかなか思わないというところがあります。ただ、開発をするにあたって CI/CD 環境を用意するのは当たり前だという状況が覆ることはないと筆者は考えています。

となると、将来的には CI/CD 環境構築のハードルが下がっていって、手軽に用意できるようになるはずです。そういった流れはあるはずなので、今回の一連の記事で個人環境で CI/CD ができるようにしておくのは価値があると筆者は考えています。同じように価値があると考えている人に、これらの記事が役に立てば幸いです。

参考資料

Dockerエクゼキュータ | GitLab