はじめに
「CI/CDって言葉は知ってるけど、全体の流れがいまいちピンとこない」——そんな方に向けて、1枚の図でパイプラインの全体像を整理しました。
本記事では下図をベースに、ソースコードの変更がKubernetes上のコンテナとして動き出すまでの流れを簡潔に解説します。
登場する3つの領域
図に登場する主要な領域は以下の3つです。
| 領域 | 役割 |
|---|---|
| ソースコードリポジトリ | アプリのコードとDockerfileを管理 |
| マニフェストリポジトリ | Kubernetesのデプロイ定義（YAML）を管理 |
| Kubernetes | 実際にコンテナが稼働するクラスタ |
ソースコードとマニフェストを 別リポジトリで管理する 構成は、GitOpsの基本パターンです。アプリの変更とインフラの変更を独立してレビュー・追跡できるメリットがあります。
CI（継続的インテグレーション）の流れ
CIサーバがソースコードリポジトリの変更を検知すると、以下が自動で実行されます。
-
Dockerfileを参照してdocker buildを実行 - ビルドされたイメージを
docker pushでイメージレジストリに格納 - マニフェストリポジトリ内の
deployment.yamlに記載されたイメージタグ（:image）を更新
ポイントは CIの成果物がコンテナイメージである こと。ビルド・テスト・イメージ化までを一貫して自動化することで、「手元では動くのに……」を防ぎます。
CD（継続的デリバリー/デプロイ）の流れ
CDサーバがマニフェストリポジトリの変更を検知すると、Kubernetesへの反映が始まります。
-
deployment.yaml/service.yaml/route.yamlをkubectl applyでクラスタに適用 - Kubernetesが新しいイメージでコンテナを起動
マニフェストリポジトリの内容 ＝ クラスタのあるべき姿、という考え方が GitOps の核心です。Argo CDやFlux CDなどのツールがこの役割を担います。
まとめ
| フェーズ | トリガー | やること |
|---|---|---|
| CI | ソースコード変更 | ビルド → イメージPush → タグ更新 |
| CD | マニフェスト変更 | kubectl apply → コンテナ起動 |
この図を頭に入れておくと、Jenkins / GitHub Actions / GitLab CI / Argo CD といった個別ツールの役割がどこに位置付けられるか理解しやすくなります。
まずは 「コードの変更がコンテナになるまで」 の流れを掴むところから始めてみてください。