Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GL_TsukasainGitLab合同会社

GitLab Runner運用の新時代：GRITで実現するインフラストラクチャ管理の効率化

Last updated at Posted at 2025-11-23

GitLab Runner運用の新時代：GRITで実現するインフラストラクチャ管理の効率化

(トップページはこちら) - (GitLab Runnerを始める)

「Runnerが10台を超えたあたりから、設定ファイルの管理が破綻し始めた」「オートスケーリングの設定を間違えて、クラウドコストが跳ね上がった」「チームごとに異なるRunner設定が乱立して、統一できない」

GitLab Runnerを本格的に運用すると、こうした課題に直面します。GitLab Runner Infrastructure Toolkit(GRIT)は、これらの問題に対する実践的な解決策です。

1. GRITの正体

GRITは、GitLab Runnerのデプロイと管理のためのTerraformモジュール集です。GitLab.comで月間数百万ジョブを処理している実績をもとに、運用のベストプラクティスをコード化しています。

1.1 何ができるのか

  • 単一のShell Runnerから、数百台規模のオートスケーリング環境まで対応
  • AWS、GCP、Azureなど主要クラウドプロバイダーをサポート
  • モジュールを組み合わせることで、VPC、IAM、オートスケーリングを一貫して構成
  • バージョン管理により、「GRIT 1.5.0を使っています」と言えば設定が特定できる

1.2 現在の状態

開発状況は実験段階(Experimental)ですが、GitLab社内での本番利用がベータ段階に入っており、急速に成熟しています。

2. 5分で理解する実装例

2.1 最小構成：Shell Runner

まず、最もシンプルな例から見ていきます。

module "shell_runner" {
  source = "grit/modules/aws/runner"
  
  runner_name = "production-shell-runner"
  gitlab_url  = "https://gitlab.com"
  executor    = "shell"
}

たったこれだけで、EC2インスタンス上にShell Runnerが構築されます。

2.2 本番構成：Docker Autoscaler

実際の本番環境では、以下のような構成になります。

# VPC設定
module "vpc" {
  source = "grit/modules/aws/vpc"
  
  vpc_cidr           = "10.0.0.0/16"
  availability_zones = ["ap-northeast-1a", "ap-northeast-1c"]
}

# IAM設定
module "iam" {
  source = "grit/modules/aws/iam"
  
  runner_name = "docker-autoscaler-runner"
}

# Fleeting設定（オートスケーリング）
module "fleeting" {
  source = "grit/modules/aws/fleeting"
  
  instance_type = "t3.medium"
  max_instances = 10
}

# Runner設定
module "runner" {
  source = "grit/modules/aws/runner"
  
  runner_name = "docker-autoscaler-runner"
  gitlab_url  = "https://gitlab.com"
  executor    = "docker-autoscaler"
  
  # 他のモジュールの出力を直接接続
  vpc      = module.vpc
  iam      = module.iam
  fleeting = module.fleeting
}

2.3 Perfect Fitの威力

注目すべきは、module.vpcの出力がmodule.runnerのvpcパラメータにそのまま渡せる点です。これがGRITの「Perfect Fit」設計です。データ変換や構造の調整が不要で、モジュール間の接続がシームレスに行えます。

3. オートスケーリングの仕組み

GRITを効果的に使うには、GitLab Runnerのオートスケーリングアーキテクチャを理解する必要があります。

3.1 Runner Managerとは

Runner Managerは、ジョブを実行する「実Runner」を動的に作成・管理する特別なRunnerです。

3.2 重要な設定パラメータ

concurrent = 10  # 全Runnerで同時実行できるジョブ総数

[[runners]]
  name = "docker-autoscaler-runner"
  url = "https://gitlab.com"
  token = "..."
  executor = "docker-autoscaler"
  limit = 5  # このRunnerが作成できる実Runnerの最大数

理解のポイント

  • concurrent: システム全体のキャパシティ
  • limit: 個別Runnerのキャパシティ
  • オートスケーリングの場合、limitは「作成する実Runnerの数」を意味する

3.3 冗長化の必須パターン

本番環境では、最低2つのRunner Managerを同じタグで構成します。

これにより、1台のRunner Managerが停止してもジョブ実行が継続されます。

4. Docker Executorの実践

4.1 ジョブ実行の4ステップ

Docker Executorは、ジョブを以下のステップで実行します。

4.2 ネットワーク分離の推奨設定

ジョブごとに独立したネットワークを作成することで、セキュリティと安定性が向上します。

[[runners]]
  executor = "docker"
  environment = ["FF_NETWORK_PER_BUILD=1"]
  [runners.docker]
    image = "alpine:latest"

効果

  • ジョブ間で環境変数が漏洩しない
  • サービスコンテナの名前解決が確実に動作
  • ネットワークの競合が発生しない

4.3 イメージプルポリシーの選択

運用方針に応じて、適切なプルポリシーを選択します。

[[runners]]
  executor = "docker"
  [runners.docker]
    # 推奨：フォールバック付き
    pull_policy = ["always", "if-not-present"]
    
    # セキュリティ：許可するポリシーを制限
    allowed_pull_policies = ["always", "if-not-present"]

選択基準

ポリシー 用途 注意点
always 本番環境・共有Runner レジストリ障害時にジョブが失敗
if-not-present 開発環境・専用Runner セキュリティリスクあり
never エアギャップ環境 事前のイメージ配置が必須

5. 大規模運用の最適化

5.1 Long Pollingの必要性

Runner数が増えると、定期的なポーリングがGitLabサーバーの負荷になります。

問題の例

  • 100台のRunnerが10秒ごとにポーリング → 毎秒10リクエスト
  • ジョブキュー時間の増加
  • GitLabサーバーのCPU使用率上昇

5.2 Long Pollingの動作

Long Pollingを有効にすると、Runnerのリクエストは新しいジョブが発生するまで保持されます。

5.3 設定方法

5.3.1 Linux package(Omnibus)

# /etc/gitlab/gitlab.rb
gitlab_workhorse['api_ci_long_polling_duration'] = "50s"

設定後、再構成を実行します。

sudo gitlab-ctl reconfigure

5.3.2 Helm chart(Kubernetes)

gitlab:
  webservice:
    workhorse:
      extraArgs: "-apiCiLongPollingDuration 50s"

効果

  • ジョブキュー時間の短縮（即座に通知）
  • GitLabサーバーの負荷削減（ポーリング頻度の低下）
  • ネットワーク帯域の節約

6. 監視とメトリクス

6.1 必須メトリクス3選

GRITで構築した環境を運用する際、最低限監視すべきメトリクスは以下の3つです。

6.1.1 ジョブ実行数

gitlab_runner_jobs_total

用途: 使用傾向の把握、キャパシティプランニング

6.1.2 ジョブキュー時間

gitlab_runner_job_queue_duration_seconds

用途: Runner不足の検出、SLO監視

6.1.3 Runnerキャパシティ

gitlab_runner_jobs / gitlab_runner_limit

用途: スケールアウトのタイミング判断

6.2 メトリクスの公開設定

# config.toml
listen_address = ":9252"

この設定により、http://runner-host:9252/metricsでPrometheusメトリクスが公開されます。

6.3 Grafanaダッシュボードの構成

最小限のダッシュボードとして、以下の3つのパネルを作成します。

  1. ジョブ実行数の推移: 週次で確認し、増加傾向を把握
  2. ジョブキュー時間の分布: P50、P95、P99を監視
  3. Runnerキャパシティの使用率: 80%を超えたらスケールアウトを検討

6.4 Runner Fleet Dashboard

GitLab 16.6以降では、管理画面から直接Runner環境の健全性を確認できます。

主要機能

  • オンライン/オフラインRunnerの数
  • Runnerインフラストラクチャ起因のCIエラー
  • 最も負荷の高いRunnerの同時実行ジョブ数
  • コンピュートミニッツの使用量（ClickHouse連携時）
  • ジョブキュー時間の詳細分析（ClickHouse連携時）

7. 運用開始前のチェックリスト

7.1 要件定義

GRITを導入する前に、以下を明確にします。

  • オンボード予定のチーム数
  • 使用する言語・フレームワーク（Go、Java、Node.jsなど）
  • 1日あたりの予想ジョブ数
  • コンテナで実行できない特殊要件の有無
  • 必要なコンピュートキャパシティ

7.2 最小構成の決定

推奨開始構成

  • Runner Manager: 2台（冗長化）
  • 各Managerのlimit: 5（合計10の実Runnerを作成可能）
  • インスタンスタイプ: t3.medium（2vCPU、4GB RAM）
  • 監視: Prometheus + Grafana

7.3 セキュリティ設定

本番環境では、使用可能なイメージを制限します。

[[runners]]
  executor = "docker"
  [runners.docker]
    # プライベートレジストリのみ許可
    allowed_images = ["registry.example.com/*:*"]
    allowed_services = ["registry.example.com/*:*"]

8. GRITがもたらす価値

8.1 設定の標準化

課題: チームごとに異なるRunner設定が乱立

解決: GRITのバージョンを指定することで、設定を統一

# チームA
module "runner_team_a" {
  source = "grit/modules/aws/runner@v1.5.0"
  # ...
}

# チームB
module "runner_team_b" {
  source = "grit/modules/aws/runner@v1.5.0"
  # ...
}

8.2 トラブルシューティングの効率化

課題: 「Runner設定のどこが問題か分からない」

解決: 「GRIT 1.5.0を使っています」と言えば、サポートが設定を特定できる

8.3 ベストプラクティスの自動適用

課題: オートスケーリングの設定ミスでコストが跳ね上がる

解決: GitLab.comで実証済みの設定がモジュールに組み込まれている

8.4 GitLab.comとの知見共有

GRITは、GitLab.comで月間数百万ジョブを処理している実績をもとに開発されています。

具体例

  • Docker Machine Executor: 7台のRunner Manager
  • インスタンスタイプ: GCP n1-standard-1
  • 処理規模: 月間数百万ジョブ

この構成がGRITのモジュールに反映されています。

9. バージョン管理戦略

9.1 セマンティックバージョニング

GRITはvX.Y.Z形式でバージョン管理されています。

  • X（メジャー）: 破壊的変更
  • Y（マイナー）: 後方互換性のある新機能
  • Z（パッチ）: バグ修正

9.2 プレリリースの活用

mainブランチへのマージごとにプレリリースタグが自動生成されます。

例: 最新リリースがv1.0.0で、10個の新しいコミットがある場合

v1.1.0-pre.10

これにより、最新の開発版を試すことができます。

9.3 AMIのライフサイクル

AWS環境では、GRITが提供するAMIは最大2年間サポートされます。

削除される条件

  • タグ付きリリースに含まれず、かつ最新リリース前に作成された
  • 作成から2年以上経過

対策: 定期的にGRITをアップグレードする

10. 次のステップ

10.1 今すぐ試す

  1. 最新リリースをダウンロード
  2. シンプルなShell Runnerから開始
  3. 監視を設定
  4. 段階的にDocker Autoscalerに移行

10.2 本番導入の流れ

10.3 コミュニティへの参加

GRITは現在実験段階ですが、以下の方法で開発に参加できます。

  • GitLabのIssueで機能要望やバグ報告
  • Slackでの議論
  • マージリクエストの提出

10.4 学習リソース

  • デモ動画: GRITの概要と基本的な使い方
  • サンプルコード: examples/ディレクトリに実装例
  • ドキュメント: 各モジュールのREADME.mdに詳細な説明

11. まとめ

GitLab Runner Infrastructure Toolkit(GRIT)は、Runner運用の複雑さを解決するTerraformモジュール集です。

GRITの本質

  • GitLab.comで実証済みのベストプラクティスをコード化
  • モジュールの組み合わせで、シンプルから複雑まで対応
  • バージョン管理により、設定の標準化とトラブルシューティングを効率化

導入の効果

  • 設定ファイルの乱立を防ぎ、統一された構成を実現
  • オートスケーリングの設定ミスによるコスト増を回避
  • 監視とメトリクスにより、適切なタイミングでスケールアウト

今後の展望

現在は実験段階ですが、GitLab社内での本番利用を通じて急速に成熟しています。GA（一般提供）に向けて、後方互換性を維持しながら機能が拡充されていきます。

Runner運用の課題に直面しているなら、GRITは検討する価値のあるツールです。まずは小規模な検証環境から始めて、段階的に本番環境に適用していくことをお勧めします。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?