CI/CD・デプロイ

コンテナベースCI こんてなべーすしーあい

DockerCI/CDコンテナJenkinsGitHub Actionsビルド環境

コンテナベースCIについて教えて

簡単に言うとこんな感じ！

テストやビルドを「毎回まっさらな弁当箱（コンテナ）」の中で動かす仕組みだよ！「自分のPCでは動いたのに…」という悲劇をなくして、誰のマシンでも・何度やっても同じ結果が出るCI環境を作れるんだ！

コンテナベースCIとは

コンテナベースCIとは、CI（継続的インテグレーション） のビルド・テスト工程を、コンテナ（DockerなどによるOS以上の隔離された実行環境）の中で走らせる手法です。コードが変更されるたびに自動でテストを実行するCIそのものの仕組みは変わりませんが、その「実行場所」をコンテナに統一することで、環境の差異による不具合を排除します。

従来のCIでは、テスト用サーバー（CIエージェント）に直接ツールをインストールして管理する必要があり、「Aプロジェクトは Node.js 16、Bプロジェクトは Node.js 20」といったバージョン混在問題や、誰かが設定を変えてしまう「環境汚染」が起きがちでした。コンテナベースCIはこの問題を根本から解決します。各ジョブが使い捨てのクリーンな環境で動くため、再現性・信頼性・並列実行のしやすさが大幅に向上します。

現代のCI/CDパイプラインでは、GitHub Actions・GitLab CI・CircleCI・Jenkinsなどほぼすべての主要ツールがコンテナベースでの実行を標準サポートしています。「うちのプロジェクトのCIがコンテナで動いている」という状況は、今や当たり前に近い状態です。

コンテナベースCIの仕組みと構造

従来CI vs コンテナベースCIの比較

比較項目	従来のCI（ベアメタル）	コンテナベースCI
実行環境	CIサーバーに直接インストール	コンテナイメージを都度起動
環境の再現性	×（手動管理、状態が溜まる）	◎（毎回同じイメージから起動）
プロジェクト間の独立性	△（バージョン競合が起きやすい）	◎（コンテナが完全に隔離）
並列実行	△（サーバーリソースを奪い合う）	◎（コンテナ単位でスケール）
セットアップのコード化	△（ドキュメントに頼りがち）	◎（Dockerfileで管理）
環境汚染リスク	高（前のジョブの残骸が残る）	低（コンテナ破棄でリセット）

コンテナベースCIの処理フロー

コードのプッシュ — 開発者がGitリポジトリにコードをプッシュ
CIトリガー — CIツールがイベントを検知してジョブを起動
コンテナイメージのPull — 指定したDockerイメージ（例: node:20-alpine）を取得
コンテナ起動 — まっさらなコンテナを立ち上げる
ジョブ実行 — ビルド・テスト・静的解析などを実行
コンテナ破棄 — ジョブ完了後にコンテナを削除（環境はゼロリセット）
結果通知 — 成功/失敗をSlackやPRコメントで通知

よく使われるコンテナイメージの例

# GitHub Actions の例
jobs:
  test:
    runs-on: ubuntu-latest
    container:
      image: node:20-alpine      # ← このイメージの中でジョブが動く
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

歴史と背景

2013年 — Docker登場。コンテナ技術が一気に身近になる
2014〜2015年 — JenkinsがDockerプラグインを整備。CIとコンテナの組み合わせが普及し始める
2016年 — GitLab CIがコンテナ実行を標準機能として組み込む。.gitlab-ci.yml に image: 一行書くだけで対応
2018年 — CircleCIがコンテナ実行をアーキテクチャの中心に据えたバージョン2.0を刷新
2019年 — GitHub Actionsが正式リリース。コンテナサービス（service containers）にも対応し、DBなどを含む複合環境も定義可能に
2020年代 — KubernetesベースのCI（Tekton・Argoなど）が台頭。コンテナオーケストレーション基盤の上でCIを動かす構成が大規模案件で普及

主要CIツールとコンテナの関係

サービスコンテナ（Service Containers）

コンテナベースCIの強力な機能として、サービスコンテナがあります。テスト中にデータベース（PostgreSQL・MySQL）やキャッシュ（Redis）が必要な場合、本番環境のサーバーを使わず、CIジョブと並走する専用コンテナを立ち上げられます。

# GitHub Actions でのサービスコンテナ例
services:
  postgres:
    image: postgres:16
    env:
      POSTGRES_PASSWORD: testpass
    ports:
      - 5432:5432

テストが終わればデータベースごと消えるため、データが残ってテストが汚染されることもありません。

Docker-in-Docker（DinD）とは

コンテナの中でさらにDockerを動かす「Docker-in-Docker（DinD）」という構成も使われます。CIコンテナ自体がDockerイメージのビルドや別コンテナの起動を行いたい場合に必要になりますが、セキュリティ上の注意点もあるため、最近は/var/run/docker.sock をマウントする方式や、Kaniko（コンテナ不要でDockerイメージをビルドするツール）を使う方式も採用されています。

規格・仕様	内容
OCI Image Specification	Open Container Initiativeによるコンテナイメージフォーマットの標準仕様
OCI Runtime Specification	コンテナランタイムの標準仕様（runc等が準拠）