こんにちは！日々の開発、本当にお疲れ様です。
「GitLabの共有Runner、なんだかいつもビルド待ちが発生していらいらする……」「うちのプロジェクト特有のビルドツールやキャッシュをサクサク動かしたい！」そんな風に思ったことはありませんか？
今回は、あなたの自前サーバー（オンプレミスやクラウドの仮想マシン）に、Docker版の「GitLab Runner」を爆速で構築する方法を徹底解説します。
これをマスターすれば、ビルド待ちのストレスから解放されるだけでなく、あなた専用のパワフルなCI/CD環境が手に入り、毎日の開発が劇的に楽になりますよ。さあ、一緒にモダンで快適な自動化の世界へ足を踏み入れましょう！
—
なぜ「自前（プライベート）Runner」が必要なのか？
GitLabには、最初から利用できる「共有Runner（Shared Runner）」が用意されています。これらは手軽で便利なのですが、チームや他のユーザーとリソースを共有するため、ピーク時には「ビルドがキュー（待機列）に入ったまま全然始まらない……」というボトルネックが発生しがちです。
ここで、自前サーバーに専用のRunner（Specific Runner / 自前Runner）を構築するメリットを見てみましょう。
1. 爆速のビルド開始: 待機列なし。トリガーした瞬間からビルドが走り始めます。
2. 環境の完全コントロール: 必要な言語のランタイムや、社内ニッチなツール、特殊なライブラリを自由自在にインプットできます。
3. セキュリティとコストの最適化: 機密情報を扱うビルドをクローズドな環境で完結させたり、クラウドの共有Runnerの利用時間制限を気にせず使えます。
Docker版を使うことで、OSを汚さず、クリーンで再現性の高いビルド環境を瞬時に作ることができます。それでは、具体的な手順を見ていきましょう！
—
ステップ1：GitLab Runnerのインストール（Docker版）
今回の主役はDockerです。ホストOS（サーバー）にDockerがすでにインストールされている前提で進めます。
まずは、Runnerの設定やデータを永続化するためのDockerボリュームを作成し、公式のGitLab 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
ここがポイント！
`-v /var/run/docker.sock:/var/run/docker.sock` という設定が非常に重要です。これは「コンテナの中から、ホスト側のDockerエンジンを操作できるようにする」ための魔法の呪文です。これによって、「Dockerの中でさらにDockerコンテナを立ち上げてビルドする（Docker-in-Docker）」という、非常にクリーンでモダンなCI/CDパイプラインが実現できます。
—
ステップ2：GitLabとRunnerを紐付ける（登録作業）
コンテナが立ち上がったら、次はあなたのGitLabプロジェクトとこのRunnerをペアリング（登録）します。
1. 登録トークンの取得
GitLabのプロジェクト画面を開き、左メニューから [設定 (Settings)] > [CI/CD] を展開します。
その中の [Runners] セクションを開き、[新しいプロジェクトRunnerを作成 (New project runner)] ボタンをクリックします。
（タグやプラットフォームを設定して進めると、「登録トークン（Registration Token / glrt-…）」が表示されます。これをコピーしておいてください）
2. コンテナ内から登録コマンドを実行
先ほど立てたDockerコンテナの中にログインして、登録作業を行います。以下のコマンドを実行してください。
docker exec -it gitlab-runner gitlab-runner register
コマンドを実行すると、対話形式でいくつか質問されます。以下のように入力していきましょう。
1. GitLabのURLを入力 (例: GitLab Self-managedの場合はそのURL、GitLab.comなら https://gitlab.com)
Please enter the gitlab-ci coordinator URL:
https://gitlab.com
2. 先ほどコピーした登録トークンを入力
Please enter the gitlab-ci token for this runner:
glrt-xxxxxxxxxxxxxxxxxxxx
3. このRunnerの説明 (なんでもOKです)
Please enter the gitlab-ci description for this runner:
[hostname]: my-lightning-fast-runner
4. タグを入力 (パイプライン側でこのRunnerを指定するためのキーワード。例: docker, production)
Please enter the gitlab-ci tags for this runner (comma separated):
docker-runner
5. オプションのメンテナンスノート
Please enter the gitlab-ci optional maintenance note:
My local docker runner for fast CI
6. 【最重要】エグゼキューター（実行環境）の選択
Docker版の恩恵を最大限受けるために “docker” を入力します！
Please enter the executor:
docker
7. デフォルトで使用するDockerイメージ (何もないときのフォールバック)
Please enter the default Docker image (e.g. ruby:3.0):
ubuntu:22.04
「Runner registered successfully.」と表示されたら、ペアリング大成功です！GitLabの画面に戻ると、緑色のマークが点灯し、無事にRunnerが認識されていることが確認できます。
—
ステップ3：セキュリティ設定の注意点（超重要）
自前サーバーでDocker Runnerを動かす場合、セキュリティ面で絶対に押さえておかなければならない注意点が1つあります。
先ほど設定した `-v /var/run/docker.sock:/var/run/docker.sock` ですが、これは「ホストOSのDockerデーモンへのフルアクセス権をコンテナに与える」ことを意味します。もし悪意のあるコードがCI/CDパイプラインに混入した場合、ホストサーバー自体が乗っ取られるリスクがあります。
安全な運用を守るためのベストプラクティス:
- 公開リポジトリでは慎重に: 誰でもマージリクエストを送れるオープンなプロジェクトでこの構成にする場合は、誰がパイプラインを実行できるか（権限管理）を厳しく制限してください。
- 専用の仮想マシン（VM）を切り出す: 本番環境のサーバーや、他の重要なサービスが動いているホスト上で直接Runnerを動かすのは避け、CI専用の使い捨て可能な軽量VM（AWS EC2やGoogle Compute Engineなど）の上でコンテナを動かすのがプロの鉄則です。
—
ステップ4：精度高い「HelloWorld」で動作確認！
さあ、いよいよ自前Runnerが正しく動くかテストしてみましょう。
プロジェクトのルートディレクトリに `.gitlab-ci.yml` というファイルを作成し、以下のコードを書き込んでコミット＆プッシュしてください。
.gitlab-ci.yml
使用するステージの定義
stages:
- test
ジョブの定義
hello_world_job:
stage: test
# 先ほど登録時に指定したタグを設定し、この自前Runnerで実行させる
tags:
- docker-runner
# 軽量なAlpine Linuxのイメージを指定
image: alpine:latest
script:
- echo “==========================================”
- echo “🎉 おめでとうございます！自前Runnerが動いています！”
- echo “==========================================”
- uname -a
- apk update && apk add curl
- echo “インターネット接続もバッチリです。”
動作確認の流れ
1. 上記のファイルをGitLabにプッシュします。
2. プロジェクトの [ビルド (Build)] > [パイプライン (Pipelines)] を覗いてみてください。
3. 共有Runnerの順番待ちを一切挟むことなく、一瞬でジョブが「Running」になり、数秒で「Passed」に変わるはずです！
4. ジョブのログを開いて、お馴染みのメッセージと `uname -a` の結果が表示されていれば、爆速CI環境の完成です。
—
おわりに
お疲れ様でした！これで、あなた専用のパワフルかつクリーンなDocker版GitLab Runnerの構築が完了しました。
自前Runnerを手に入れたことで、重たいテストコンテナのキャッシュ戦略、複雑なビルドフロー、社内ニッチなツールとの連携など、CI/CDの可能性は無限大に広がります。
「毎日の作業が劇的に楽になる」その感覚を、ぜひチームのメンバーとも共有して、さらに開発スピードを加速させていってくださいね。それでは、良きCI/CDライフを！