Concourse on Kubernetes 検証メモ — Helm 導入と本番運用で考えること

本記事の位置づけ

Concourse CI アーキテクチャ で紹介した構成を、 Kubernetes クラスタ上にデプロイする 検証メモです。 2018 年当時の構築手順を軸にしつつ、現時点 (2024+) の推奨構成も併記します。

なぜ Kubernetes 上で動かすのか

Concourse の構成要素 (ATC / TSA / Worker / PostgreSQL) をそれぞれ VM で立てて管理するのは煩雑。 Kubernetes に乗せると以下のメリットがあります:

• コンポーネントの宣言的管理 — ATC・Worker・PostgreSQL をマニフェストで一括定義- Worker のオートスケール — HPA / Karpenter と組み合わせてビルド負荷に応じた拡張- GitOps との統合 — Argo CD / Flux で Concourse 自体もコード管理- 他サービスとの共存 — K8s クラスタ上で CI 以外のワークロードと一緒に運用 一方で、Kubernetes 上の Worker で Docker-in-Docker (DinD) が必要 という設計上の難しさが残ります。

Helm での最小デプロイ

Concourse 公式の Helm Chart (concourse/concourse-chart) が最も素直です。

helm repo add concourse https://concourse-charts.storage.googleapis.com/
helm install my-ci concourse/concourse \
  --namespace ci --create-namespace \
  --set concourse.web.externalUrl=https://ci.example.com \
  --set secrets.localUsers=admin:secret_password

デフォルトの構成:

要素	Kubernetes リソース	備考
ATC + TSA (Web)	Deployment (replicas: 1)	Ingress 配下で HTTPS
Worker	StatefulSet (replicas: 2)	永続 Volume で Baggageclaim キャッシュ保持
PostgreSQL	StatefulSet or 外部 RDS 推奨	Chart 同梱は検証用

本番では PostgreSQL を外出し (Amazon RDS / Cloud SQL) にするのが基本。

Worker ノードの設計

StatefulSet でキャッシュ永続化

Worker は Baggageclaim Volume (Git リポジトリ、依存キャッシュ) を抱えるので、 Deployment より StatefulSet が有利 (Pod 再起動時に PVC が付いて来る)。

Docker-in-Docker (DinD) の扱い

Concourse タスクは Docker コンテナを更に起動するため、 Worker Pod 内で dockerd を動かす (DinD) か、 ホストの Docker ソケットをマウント するか、 あるいは runc 系の軽量ランタイム (crun, kata-containers) を使うかの選択:

• DinD: 特権 (privileged) が必要、セキュリティリスク
• Docker ソケットマウント: Pod がホスト Docker を触れる (更にリスキー)
• containerd 直接: Concourse 側対応が限定的

実際の本番運用では DinD を privileged で割り切る 選択が多く、 その代わり Worker Pod を他ワークロードから隔離 (node selector / taint で専用ノードプール) するのが定石。

Worker をオートスケール

パイプライン実行数で CPU 使用率が上下するので、HPA を効かせる:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: concourse-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: StatefulSet
    name: my-ci-worker
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

注意: Worker をスケールインするとき、実行中のビルドが中断されないよう graceful shutdown 設定が要る (concourse.worker.lifecycleHook.preStop)。

本番運用の留意点

1. Ingress + TLS

ATC Web UI と fly CLI 用の TSA (SSH) の両方を外から見えるように:

• ATC: Ingress + cert-manager で TLS
• TSA: LoadBalancer Service (SSH の 2222 ポートを曝露)

2. 認証連携

Chart デフォルトはローカルユーザーだけ。本番は GitHub / GitLab / OIDC 連携を:

concourse:
  web:
    auth:
      github:
        clientId: ...
        clientSecret: ...
        org: your-org

3. Credential Manager (Vault)

秘密情報は Vault 連携 で ((…)) プレースホルダから解決:

concourse:
  web:
    credentialManager:
      vault:
        url: https://vault.example.com
        clientToken: ...

4. 監視

• ATC / Worker のメトリクス → Prometheus (concourse.web.prometheus.enabled)
• ビルドログ → Loki / CloudWatch Logs に転送
• Vault アクセスログ監査

5. バックアップ

PostgreSQL のバックアップだけ 死守すれば、残りは Helm で再構築可能。

2024 年の現実解

正直なところ、2024 年時点で新規に CI/CD を Kubernetes 上に構築するなら、 Concourse より以下の方が実装例・周辺エコシステムとも充実しています:

選択肢	向く用途
GitHub Actions (+ self-hosted runners)	GitHub ユーザーなら第一候補
Argo Workflows	Kubernetes ネイティブ DAG、Argo CD と統合
Tekton	ベンダーロックインを嫌う Enterprise、OpenShift Pipelines
GitLab CI/CD	GitLab ユーザーなら全て完結
Buildkite / CircleCI	SaaS で済ませたい場合

既存の Concourse 資産がある、あるいは 「全てを YAML で宣言したい」 というポリシーを徹底したい なら Concourse on K8s は今も合理的ですが、後発勢の成熟も考慮してください。

---

まとめ: Concourse on Kubernetes は Helm で手早く立ち上がりますが、 DinD の権限設計、Worker のキャッシュ永続化、PostgreSQL の HA、認証連携 が本番投入の鍵。 新規プロジェクトであれば GitHub Actions や Argo Workflows の方が手早く済む可能性が高いので、 既存資産との兼ね合い で判断するのが現実的です。