現在のポートフォリオの課題をAIに生成させてみました。

Docker Compose から Kubernetes へ

― SREとセキュリティを両立させる現実的移行ロードマップ ―

はじめに

Docker Compose は、小規模〜中規模システムにおいて
「速く作れて・分かりやすい」 優れた選択肢です。

しかし、サービスが成長すると次の問題が必ず表面化します。

• 単一障害点が消せない
• 無停止デプロイが難しい
• 障害時の自動復旧が弱い
• セキュリティ設定が属人化する

これらは 設計者のミスではなく、Composeの設計思想の限界です。

本記事では、
SRE（Site Reliability Engineering）とセキュリティの観点から、
Compose → Kubernetes（K8s）への安全な移行ロードマップを解説します。

なぜ Kubernetes が必要になるのか

Compose の本質的な制約

Docker Compose は以下を前提にしています。

• 単一ホスト
• 静的構成
• 手動運用が前提

一方、SREが目指す世界はこうです。

障害は起きる
↓
即座に検知
↓
自動で復旧
↓
影響を最小化

この思想を実装できるのが Kubernetes です。

移行の大原則（セキュリティ視点）

移行時に最も重要なのは 「一気にやらない」 ことです。

原則

1. 先に設計をK8s前提に寄せる
2. 秘密情報をコードから排除する
3. 状態を外に逃がす
4. 自動化できないものはK8sに乗せない

Phase 0：移行前の地ならし（最重要）

目的

Kubernetes に 安全に乗せられる状態を作る。

実施内容

① Compose構成の論理分解

• Web（Django）
• Worker（Celery）
• Scheduler（Celery Beat）
• Reverse Proxy（Nginx）
• DB / Redis

👉 1コンテナ1責務を徹底。

② 環境変数の整理（セキュリティの第一歩）

• .env を用途別に分離
  • アプリ設定
  • DB設定
  • 秘密情報

この時点で「.env直置き」は卒業します。

③ healthcheck の実装

• アプリが「生きているか」
• リクエストを「受けていいか」

👉 これが無いと、K8sは正しく守ってくれません。

Phase 1：Kubernetes 基礎構築

小さく始める

• 検証：k3s
• 本番：kubeadm または managed K8s

必須コンポーネント

• CoreDNS
• metrics-server
• Ingress Controller（nginx）

ここでは セキュリティポリシーは厳しすぎなくてOK。
まずは「壊れずに動く」ことが優先です。

Phase 2：設定と秘密情報の分離（Security Core）

Compose と K8s の対応

セキュリティ観点の重要点

• Secret は Git に置かない
• 環境変数経由でのみ参照
• Pod 再起動で自動反映

👉 「人が覚えなくても安全」な状態を作ります。

Phase 3：アプリケーション移植

Django

• Deployment（replicas ≥ 2）
• readinessProbe / livenessProbe
• stateless 設計

Celery

• Worker：Deployment
• Beat：replicas=1

注意点（超重要）

DB や Redis を 最初から K8s 内に入れない。

理由：

• 障害対応が難しい
• セキュリティ境界が曖昧になる

👉 最初は外部（VM / managed）で十分です。

Phase 4：Ingress とネットワークセキュリティ

通信構成

Internet
 → Cloudflare（WAF / DDoS）
   → Ingress
     → Service
       → Pod

セキュリティ強化ポイント

• TLS終端は Cloudflare or Ingress
• Pod への直接アクセスは禁止
• 内部通信は Service DNS のみ

Phase 5：安全なデプロイ戦略

推奨戦略

• Blue-Green Deploy

Django 特有の注意

• DB Migration は Job で 単発実行
• Pod 起動時に自動実行しない

👉 ここを間違えると 一瞬で全Pod死亡します。

Phase 6：監視と予兆検知

監視スタック

• Prometheus
• Grafana
• Alertmanager

見るべき指標

• Pod Restart 数
• レイテンシ p95
• エラーレート
• HPA スケール履歴

「落ちた」ではなく「落ちそう」を検知するのがSREです。

Phase 7：オートスケールと耐障害性

• HPA（CPU / Queue長）
• Pod 自動再配置
• Node 障害時の自動復旧

この段階で、Compose では不可能だった世界に入ります。

移行時の典型的な失敗（セキュリティ事故）

まとめ

Docker Compose から Kubernetes への移行は
**技術力より「順序」と「割り切り」**が重要です。

• まず安全に動かす
• 自動化できる所だけK8sに任せる
• セキュリティは「人」ではなく「仕組み」で守る

これが、SREとセキュリティを両立する唯一の道です。

感想

docker-composeだけだと厳しいのは理解できるけど・・・k8sサーバー費用高くなるのが、作ってみたいという欲はあるけどVMとVPSのスペックに相談するしか・・