GitLab Runnerを「自前」で極める：CI/CDのボトルネックを排除し、開発速度を限界まで引き上げる戦略
共有のGitLab SaaS Runnerで「Pending」の文字を見て絶望したことはないか？あるいは、ビルド時間が長すぎてフィードバックループが回らず、チームの士気が下がっているのを感じたことはないか？
もしそうなら、今すぐ自前のGitLab Runner（Docker版）を構築すべきだ。これは単なる「設定」ではなく、開発者の時間を奪う摩擦を物理的に排除する、DevOpsの最重要投資である。
本稿では、ただ構築するだけでなく、現場のテックリードが知っておくべき「真の運用」の極意を伝授する。
—
1. なぜ「自前Runner」がDevOpsの勝負を分けるのか
共有Runnerは便利だが、本質的に「ブラックボックス」だ。
- レイテンシ: 共有リソースの奪い合いによる起動遅延。
- スペック制限: コンテナのリソース制限が厳しく、ビルドが落ちる。
- キャッシュ効率: 独自キャッシュ戦略が組めない。
自前Runner（特にDocker executor）を構築すれば、「ビルド環境の完全な制御権」と「キャッシュの局所化」が手に入る。これがエンジニアの体験（DX）を劇的に向上させる。
—
2. 実践：爆速・高安定なDocker Runnerの構築
まずは、単に動かすだけでなく、運用に耐えうる構成で立ち上げる。
`docker-compose.yml` による堅牢な構築
Runnerの死活監視と再起動ポリシーをOSレベルで管理させるために、Docker Composeを使うのが定石だ。
version: ‘3.8’
services:
gitlab-runner:
image: gitlab/gitlab-runner:latest
container_name: gitlab-runner
restart: always # 障害時自動復旧
volumes:
- ./config:/etc/gitlab-runner # 設定永続化
- /var/run/docker.sock:/var/run/docker.sock # ホストのDockerを操作
environment:
- REGISTER_NON_INTERACTIVE=true
登録のハック：`config.toml` の最適化
登録後、`config.toml` を以下の設定でチューニングする。ここが「遅いビルド」と「爆速ビルド」の分かれ目だ。
[runners.docker]
image = “alpine:latest”
# ネットワークをhostにすると速い場合があるが、セキュリティと要相談
network_mode = “bridge”
# キャッシュ用ボリュームをホストにマウントして共有
volumes = [“/cache”, “/opt/docker-cache:/cache:rw”]
# メモリ使用量を明示的に制限し、コンテナの暴走を防ぐ
memory = “2048m”
# 重要：不要なログを出さない、プル戦略を最適化
pull_policy = “if-not-present”
—
3. 現場で差がつく「神」テクニックと習慣
① CI/CDパイプラインの「YAML」構成ベストプラクティス
`include` を使い倒せ。`.gitlab-ci.yml` を肥大化させるのは罪だ。ジョブの共通化は別ファイルへ追い出し、プロジェクト固有のロジックのみを記述する。
プロジェクトのパイプラインはこうあるべき
include:
- project: ‘devops/ci-templates’
file: ‘/java-build.yml’ # 共通ビルドロジックを別リポジトリで管理
variables:
DOCKER_DRIVER: overlay2 # パフォーマンス向上のためのドライバ指定
② チーム開発で絶対に入れるべき設定
- GitLab Workflow Extension (VS Code): これを入れずにGitLabを触るな。エディタ内でパイプラインのステータス確認、ジョブの再実行、マージリクエストの作成が完結する。
- キャッシュ戦略の徹底: `cache:key` を `CI_COMMIT_REF_SLUG` だけでなく、`package-lock.json` のハッシュ値と紐付けろ。不要な依存関係のインストールを省くことが、CI爆速化の最大の鍵だ。
③ 知る人ぞ知るキーボードショートカット
- `Shift + ?`: GitLabの全キーボードショートカットを表示。
- `g + m`: マージリクエスト一覧へ即座にジャンプ。
- `a`: MR画面で「承認(Approve)」ボタンを押さずにショートカットで処理。
—
4. 運用上の絶対的なルール：セキュリティとリソース管理
自前Runnerを立てるということは、「セキュリティの責任を自ら負う」ということだ。
1. DIND（Docker in Docker）の回避: `docker.sock` のマウントは便利だが、権限管理には細心の注意を払うこと。必要であれば `Kaniko` や `Buildah` のような「Dockerデーモンを必要としないビルドツール」への移行を検討せよ。
2. タグ（Tag）による隔離: 汎用Runnerと、本番デプロイ専用のセキュアなRunnerは必ずタグで分けろ。`tags: [prod-runner]` のように指定し、環境ごとの権限を分離する。
3. 定期的な掃除: `/opt/docker-cache` などにマウントしたキャッシュは、放っておくと肥大化しホストのディスクを圧迫する。`docker system prune` を cron で回す運用を自動化パイプラインに組み込むこと。
—
最後に：テックリードからの提言
GitLab Runnerを自前で運用することは、単なるインフラ作業ではない。「エンジニアがコードを書くことに集中できる時間を、自分たちの手で作り出す」という意思表示だ。
パイプラインが1分短縮されれば、チーム全体で毎日何時間もの生産性が回復する。その積み重ねこそが、競合を置き去りにするエンジニアリング組織の強みとなる。
さあ、今すぐRunnerを立てろ。そして、チームのパイプラインを「最高速」へと導け。