• Dockerエンジンのバージョン互換性
• 一般的なGitLab Runner Dockerイメージの使い方
• Dockerイメージをインストールし、コンテナを起動します。
  • オプション1：ローカルシステムのボリュームマウントを使ってRunnerコンテナを起動します。
  • オプション 2: Dockerボリュームを使用してRunnerコンテナを起動します。
  • ランナーの登録
• 設定の更新
• バージョンアップ
• GitLab Runner のログの読み込み
• 信頼できるSSLサーバ証明書のインストール
• Dockerイメージ
  • GitLab Runner Docker イメージの作成
• SELinux
• GitLab Runnerコンテナイメージはライフサイクルをサポートします。
  • コンテナイメージと公開終了日

GitLab Runnerをコンテナで実行します。

Dockerコンテナ内でGitLab Runnerを実行する方法です。

Dockerエンジンのバージョン互換性

一般的に、Docker EngineのバージョンとGitLab Runnerコンテナイメージのバージョンは一致する必要はありません。GitLab Runnerのイメージは前後で互換性があるべきです。しかし、最新の機能やセキュリティアップデートを確実に利用するためには、常に最新の安定したDocker Engineのバージョンを使うべきです。

一般的なGitLab Runner Dockerイメージの使い方

GitLab Runner Dockerイメージ（UbuntuまたはAlpine Linuxベース）は、GitLab Runnerがホストに直接インストールされている場合のように、標準的なgitlab-runner コマンドのラッパーとして設計されています。

一般的なルールは、通常であればGitLab Runnerのコマンドはすべて：

gitlab-runner <runner command and options...>

で実行できます：

docker run <chosen docker options...> gitlab/gitlab-runner <runner command and options...>

例えば、GitLab Runner コマンドのトップレベルのヘルプ情報を得るには次のように実行します：

docker run --rm -t -i gitlab/gitlab-runner --help

NAME:
   gitlab-runner - a GitLab Runner

USAGE:
   gitlab-runner [global options] command [command options] [arguments...]

VERSION:
   15.11.0 (436955cb)

(...)

要するに、コマンドのgitlab-runner の部分がdocker run [docker options] gitlab/gitlab-runner に置き換えられ、コマンドの残りの部分は登録ドキュメントに記載されている通りになります。唯一の違いは、gitlab-runner コマンドが Docker コンテナの内部で実行されることです。

Dockerイメージをインストールし、コンテナを起動します。

始める前に、Dockerがインストールされていることを確認してください。

Dockerコンテナ内部でgitlab-runner を実行するには、コンテナの再起動時に設定が失われないようにする必要があります。そのためには、以下の2つのオプションがあります。

GitLab Runnerのよくある問題については、FAQセクションを読んでください。

• session_server を使っている場合は、docker run コマンドに-p 8093:8093 を追加して8093 ポートを公開する必要があります。

• オートスケール機能でDocker Machine Executorを使用したい場合は、Docker Machineストレージパスをマウントする必要もあります:/root/.docker/machine ：

  • システムボリュームのマウント用に-v /srv/gitlab-runner/docker-machine-config:/root/.docker/machine を追加してください。
  • Docker名前付きボリューム用に-v docker-machine-config:/root/.docker/machine 。

オプション1：ローカルシステムのボリュームマウントを使ってRunnerコンテナを起動します。

この例では、gitlab-runner コンテナにマウントされる設定ボリュームにローカルシステムを使用します。このボリュームは、設定やその他のリソースに使用されます。

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

オプション 2: Dockerボリュームを使用してRunnerコンテナを起動します。

この例では、設定コンテナを使ってカスタムデータボリュームをマウントします。

1. Dockerボリュームを作成します：

   docker volume create gitlab-runner-config
   

2. 先ほど作成したボリュームを使って GitLab Runner コンテナを起動します：

   docker run -d --name gitlab-runner --restart always \
       -v /var/run/docker.sock:/var/run/docker.sock \
       -v gitlab-runner-config:/etc/gitlab-runner \
       gitlab/gitlab-runner:latest
   

ランナーの登録

最後のステップは、新しい Runner を登録することです。GitLab Runnerコンテナは登録されるまでジョブを受け取りません。

設定の更新

config.toml で設定を変更した場合、変更を適用するために Runner を再起動する必要があるかもしれません。gitlab-runner restart を使用するのではなく、コンテナ全体を再起動するようにしてください：

docker restart gitlab-runner

バージョンアップ

最新バージョン（または特定のタグ）をプルします：

docker pull gitlab/gitlab-runner:latest

既存のコンテナを停止して削除します：

docker stop gitlab-runner && docker rm gitlab-runner

コンテナを元のように起動します：

docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest

GitLab Runner のログの読み込み

GitLab Runnerが（ローカルにインストールされたバイナリであろうとDockerコンテナ内であろうと）フォアグラウンドタスクとして起動されると、ログは標準出力に出力されます。GitLab Runnerがシステムサービスとして（例えばSystemdで）起動された場合、ログはほとんどの場合Syslogや他のシステムロギング機構を通して記録されます。

GitLab RunnerをDockerベースのサービスとして起動した場合、gitlab-runner ... コマンドがコンテナのメインプロセスであるため、docker logs コマンドを使ってログを読み取ることができます。

例えば、以下のコマンドでGitLab Runnerを起動した場合：

docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest

でログを取得します：

docker logs gitlab-runner

ここで、gitlab-runner はコンテナの名前で、最初のコマンドで--name gitlab-runner 。

コンテナ・ログの取り扱いに関する詳細は、Dockerのドキュメント・ページを参照してください。

信頼できるSSLサーバ証明書のインストール

GitLab CIサーバーが自己署名SSL証明書を使用している場合は、GitLab CIサーバー証明書がGitLab Runnerコンテナから信頼されていることを確認してください。

gitlab/gitlab-runner イメージは/etc/gitlab-runner/certs/ca.crt で信頼された SSL 証明書を探すように設定されています。これは-e "CA_CERTIFICATES_PATH=/DIR/CERT" 設定オプションを使って変更することができます。

ca.crt ファイルをデータボリューム（またはコンテナ）のcerts ディレクトリにコピーします。このca.crt ファイルには、GitLab Runnerに信頼させたいすべてのサーバーのルート証明書が含まれているはず ca.crtです。ca.crt GitLab Runnerコンテナは ca.crt起動時にファイルをca.crt インポート ca.crtするので、コンテナがすでに起動している場合は、変更を有効にするために再起動する必要があるかもしれません。

Dockerイメージ

以下のマルチプラットフォームDockerイメージが利用可能です：

• gitlab/gitlab-runner:latest Ubuntuベース。
• gitlab/gitlab-runner:alpine UbuntuはAlpineをベースにしていますが、フットプリントはずっと小さくなっています（圧縮/解凍した場合、Ubuntuは160/350 MB、Alpineは45/130 MB）。

UbuntuとAlpine両方のイメージのビルド手順については、GitLab Runnerのソースを参照してください。

GitLab Runner Docker イメージの作成

GitLab Runner 16.1現在、AlpineベースのGitLab Runner DockerイメージはAlpine 3.18.2を使用しています。ただし、GitLabリポジトリで利用可能になる前に、イメージのOSをアップグレードすることができます。

最新のAlpineバージョンのgitlab-runner Dockerイメージをビルドするには：

1. alpine-upgrade/Dockerfile を作成します。

   ARG GITLAB_RUNNER_IMAGE_TYPE
   ARG GITLAB_RUNNER_IMAGE_TAG
   FROM gitlab/${GITLAB_RUNNER_IMAGE_TYPE}:${GITLAB_RUNNER_IMAGE_TAG}
      
   RUN apk update
   RUN apk upgrade
   

2. アップグレードされたgitlab-runner イメージを作成します。

   GITLAB_RUNNER_IMAGE_TYPE=gitlab-runner GITLAB_RUNNER_IMAGE_TAG=alpine-v16.1.0 docker build -t $GITLAB_RUNNER_IMAGE_TYPE:$GITLAB_RUNNER_IMAGE_TAG --build-arg GITLAB_RUNNER_IMAGE_TYPE=$GITLAB_RUNNER_IMAGE_TYPE --build-arg GITLAB_RUNNER_IMAGE_TAG=$GITLAB_RUNNER_IMAGE_TAG -f alpine-upgrade/Dockerfile alpine-upgrade
      
   

3. アップグレードされたgitlab-runner-helper イメージを作成します。

   GITLAB_RUNNER_IMAGE_TYPE=gitlab-runner-helper GITLAB_RUNNER_IMAGE_TAG=x86_64-v16.1.0 docker build -t $GITLAB_RUNNER_IMAGE_TYPE:$GITLAB_RUNNER_IMAGE_TAG --build-arg GITLAB_RUNNER_IMAGE_TYPE=$GITLAB_RUNNER_IMAGE_TYPE --build-arg GITLAB_RUNNER_IMAGE_TAG=$GITLAB_RUNNER_IMAGE_TAG -f alpine-upgrade/Dockerfile alpine-upgrade
   

SELinux

いくつかのディストリビューション（CentOS、Red Hat、Fedora）は、基本システムのセキュリティを強化するためにデフォルトでSELinuxを使用しています。

このような設定を扱う場合は、特に注意が必要です。

1. Dockerエクゼキュータを使用してコンテナでビルドを実行する場合、/var/run/docker.sock へのアクセスが必要です。しかし、SELinuxが強制モードになっていると、/var/run/docker.sockへのアクセス時にPermission denied エラーが表示されます。このイシューを解決するには、selinux-dockersockをインストールしてください。
2. ホスト上に永続ディレクトリが作成されていることを確認してください:mkdir -p /srv/gitlab-runner/config 。
3. Dockerをボリューム上で:Z ：

docker run -d --name gitlab-runner --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner:Z \
  gitlab/gitlab-runner:latest

GitLab Runnerコンテナイメージはライフサイクルをサポートします。

GitLab Runnerコンテナイメージの作成に使用したベースディストリビューション（Ubuntu、Alpine、Red Hat Universal Base Image）のサポートライフサイクルに沿って説明します。

ベースディストリビューションの公開終了日は、必ずしもGitLabのメジャーリリースサイクルと一致しません。つまり、GitLab Runner コンテナイメージのバージョンの公開はマイナーリリースで終了します。これは、アップストリームディストリビューションが更新しなくなったイメージを公開しないようにするためです。

コンテナイメージと公開終了日