Concourse CI アーキテクチャ解剖 — ATC / TSA / Worker はどう連携するか

Concourse の設計思想

Concourse (concourse-ci.org) は YAML 駆動のパイプライン実行基盤 です。 他の CI/CD と一線を画す設計:

• Pipeline as Code: YAML でパイプラインを完全記述、fly CLI で反映- ステートレス: サーバー側に状態を持たず、Resource (Git / S3 / Docker Registry など) の状態変化で駆動- Docker 単位のジョブ実行: 各タスクは Docker コンテナで実行、再現性が高い- Worker の水平スケール: パイプラインが増えたら Worker ノードを追加するだけどういう問題を解くか: Jenkins のように Groovy や UI 操作で設定が霧散せず、全てがコードになる、環境依存のない CI/CD 基盤。> 2024 時点の立ち位置: Concourse は VMware (Pivotal) 傘下で開発が継続されていますが、> Argo Workflows / Tekton / GitHub Actions / GitLab CI に市場を奪われ、新規採用は減っています。

既存の Concourse 運用環境を理解する目的で本稿を読むのが現実的な位置づけです。

コンポーネント一覧

ATC (Air Traffic Controller)

• HTTP サーバー: 既定 8080- Web UI 提供- fly CLI からの API 受付 (パイプラインの set / unpause / trigger)- Worker ノードのスケジューリング- 「Concourse の脳」 に相当### TSA (Trusted Service Announcer)

• SSH サーバー: 既定 2222- Worker ノードを ATC に 安全に登録 するための認証口- Worker は TSA にリバース SSH トンネルを張り、ATC からのジョブ指示を受ける- 30 秒毎に Worker の生存確認- 「ATC と Worker の間の信頼境界」### PostgreSQL

• パイプライン定義 / ビルドログ / Resource の状態履歴を保存

• Concourse の 唯一の永続化層

• ATC を複数台で運用する場合もバックエンドは PostgreSQL 共有

Worker ノード

Worker はジョブ実行の実体。内部に以下のサブコンポーネントを持つ:

Garden (旧名 Garden-Runc)

• HTTP サーバー: 既定 7777- Docker コンテナのライフサイクル管理 (作成・実行・破棄)- 内部的には runc を使用- ATC が指示したタスクを実行#### Baggageclaim
• HTTP サーバー: 既定 7788- タスク間で共有する Volume 管理 (Git リポジトリのクローン、依存キャッシュ等)- COW (Copy-on-Write) ボリュームでパイプライン高速化#### Beacon- Worker 側で動く常駐プロセス
• TSA にリバース SSH トンネルを張り続けて、ATC から到達可能にする
• Worker を NAT 配下に置いても ATC から指示できる

リクエストフロー: パイプラインが動くまで

開発者
   ↓  fly set-pipeline / fly trigger-job
ATC (API)
   ↓  PostgreSQL に状態保存
ATC (Scheduler)  — Resource の変化を検知
   ↓  TSA 経由で Worker に指示
Worker
   ├─ Baggageclaim: Volume 取得・準備
   └─ Garden: Docker コンテナを起動 → タスク実行 → 結果を Volume に書き出し
   ↓  結果を ATC に報告
ATC  — ログを PostgreSQL に保存、UI に表示

Vault との連携

Concourse 自体は秘密情報 (API キー、SSH 鍵) の保管に向かないため、 Vault / AWS Secrets Manager / CredHub と連携する設計:

jobs:
  - name: deploy
    plan:
      - get: src
      - task: deploy
        params:
          API_KEY: ((prod/api_key))   # Vault から解決

((...)) は Credential Manager のプレースホルダ。 ATC に認証情報を注入する設定を一度してしまえば、パイプライン YAML には 秘匿情報が一切出てこない 。

Concourse の強みと弱点

強み

• 完全な Pipeline as Code: UI 操作でパイプライン変更不可、YAML が真実- 再現性: 全ジョブがコンテナ実行- シンプルな抽象: Pipeline = Job + Resource のみ (覚える概念が少ない)- 並列実行 + Worker スケール### 弱点- 学習曲線: Resource の概念に慣れが要る (Git Pull も Resource、通知も Resource)- UI が他ツールに比べ質素- コミュニティの規模: Jenkins / GitHub Actions に比べ小さい- プラグイン (Resource Type) が限定的- 依存: PostgreSQL を含む運用セットが重い (小規模プロジェクトには過剰)## 近年の代替選択肢| ツール | 特徴 | Concourse と比べたとき || --- | --- | --- || GitHub Actions | GitHub ネイティブ、YAML 駆動 | 導入コストほぼゼロ、OSS/コンテナビルドは全部これで | | GitLab CI/CD | GitLab 統合 | Concourse と同じ YAML 駆動、UI 良好 | | Argo Workflows | Kubernetes ネイティブ、DAG 定義 | K8s 中心に寄せるなら強力 | | Tekton | Kubernetes CRD ベース | クラウドネイティブ標準化志向 | | Dagger | Pipeline を Go/Python/TS で書ける | 「YAML 疲れ」 からの開放を謳う新興 | | Jenkins | 歴史と資産 | プラグインは豊富だが、設定が霧散しがち |

新規採用で Concourse を選ぶ理由はもはや限定的 。 しかし既存の Concourse 運用環境を触る機会はまだあり、そのための理解として本稿の価値があります。

落とし穴

1. PostgreSQL のバックアップを忘れる

パイプライン定義 + ビルド履歴 + Credential ハッシュがここに集約されているので、 失ったらクラスタ再構築 。必ず定期バックアップ。

2. Worker の ephemeral 設定をせずに汚染

Worker ノード上のキャッシュ (Baggageclaim Volume) は蓄積するので、 ディスク溢れ対策として ephemeral: true で揮発化 or 定期入れ替えを。

3. パイプライン YAML を手で set-pipeline する

パイプライン YAML そのものも Git 管理し、 反映を自動化するパイプライン (いわゆる 「pipeline-of-pipelines」) を組むのが本流。

4. ATC を 1 台で運用

ATC の障害でパイプライン全停止。本番は ATC 2 台 + PostgreSQL HA が最低構成。

---

まとめ: Concourse は 「YAML と Docker で CI/CD を純化する」 というビジョンの実装。 2024 年時点では 新規採用は GitHub Actions / Argo Workflows が主流ですが、 既存の Concourse 運用コードを触るときは本稿のコンポーネント図を手元に持っておくとデバッグが速くなります。