デプロイの前に必ず確認すべきこと

■CI/CD パイプライン構成時の考慮要素

1. 管理担当 (役割分担と責任範囲)

• 業務分担に基づき、ソースビルド・コンテナビルド・デプロイの担当を分離するか検討する。
• 管理責任を明確にするため、ビルドとデプロイの主体を統合するか、あるいは専用ツールで分離するかを決定する。

2. 運用ポリシー (利便性と障害影響度)

• 管理の利便性と障害時の影響範囲（爆発半径）を考慮し、デプロイ環境の一重化または二重化を選択する。
• 開発・本番環境を分離することで、障害時の影響を最小限に抑える構成を検討する。

3. 製品選定 (環境と互換性)

• ネットワーク環境: オンライン(SaaS)かオフライン(オンプレミス)かに応じたツール選定を行う。
• セキュリティと保守: データの保護体制および保守ベンダーの有無、リファレンスの豊富さを確認する。
• コンテナ最適化: Dockerの代替ツール(Buildah, Skopeo等)や、Kubernetesネイティブなツール(ArgoCD, Tekton等)の導入を検討する。

---

■Kubernetes デプロイ戦略の比較と考慮要素

1. Recreate (再作成)

• 概要: v1 が起動中の状態で v2 をデプロイする場合、既存のポッドを削除してから作成するため、**ダウンタイム（停止時間）**が発生する。v2 の生成後にサービスと接続されることで、トラフィックの受信が再開される。
• デプロイ手順:
  1. サービス中断の告知
  2. Deployment の replicas を 0 に変更
  3. DB スキーマ変更などの作業実施
  4. Deployment のタグ変更および replicas を元の数（例: 2）に修正
• ユースケース: データベースのスキーマ変更など、新旧バージョンが同時に存在してはならないデータ整合性が重要な場合。
• 特徴: Kubernetes 標準機能による自動デプロイ（停止・ロールバック）が可能だが、詳細なトラフィック制御は不可。
• ツール: kubectl, Helm, Kustomize

2. RollingUpdate (ローリングアップデート)

• 概要: v1 がサービスを提供している状態で v2 を順次デプロイするため、v1 と v2 が同時に呼び出される期間を経て v2 へと切り替わる。
• デプロイ手順: Deployment のイメージタグをアップデート（デフォルト戦略）。
• ユースケース: 無停止デプロイが必要な一般的なウェブアプリケーション。
• 特徴: サービスの中断がない。自動デプロイ（停止・ロールバック）が可能だが、詳細なトラフィック制御は不可。
• ツール: kubectl, Helm, Kustomize

3. Blue/Green (ブルーグリーン)

• 概要: Kubernetes の標準機能ではないため、K8s の仕組みを利用して独自に構築する必要がある。既存の v1（Blue）構成がある状態で、サービスを除いた v2（Green）構成を別途作成し、サービスの Selector を v1 から v2 へ書き換えることで一気に切り替える。
• デプロイ手順:
  1. v2 の Deployment を作成
  2. Service の Selector を変更
  3. v1 の Deployment を削除
• ユースケース: 本番環境でのみテスト可能な場合や、瞬時の切り戻しが求められる場合。
• 特徴: 手動デプロイ時の切り戻し（ロールバック）が高速。スクリプトによる自動化が可能。v2 への一斉切り替え時に過度な負荷が発生するリスクがある。
• ツール: Jenkins Script, kubectl, ArgoCD

4. Canary (カナリア)

• 概要: v1 の構成がある状態で、同一構成の v2 を作成する。イングレスコントローラーと各サービスに対して Ingress リソースを定義することで、トラフィック量を段階的に調節する。
• デプロイ手順:
  1. v2 の Deployment / Ingress / Service を作成
  2. v1 と v2 の Ingress 重み付け（Weight）を変更
  3. v1 の Deployment / Ingress / Service を削除
• ユースケース: 特定のヘッダー値（Source IP、ユーザー情報、言語設定等）に基づいて、特定の条件に合致するユーザーのみ v2 へ誘導する場合。
• 特徴: コールドスタートの防止、新旧バージョンの比較、A/B テストが可能。
• ツール: ArgoCD, nginx-ingress, Istio

---

■ 段階的に構築するデプロイパイプライン

Level 1: Jenkins 基本構成

• 概要: 最も直感的かつシンプルな形態で構築されるパイプラインである。
• 特徴: 複雑なスクリプトなしで、GUI 上のジョブ設定のみでビルドおよびデプロイの流れを構築できる。
  • 初期導入の難易度が低く, 小規模なプロジェクトに適している。

Level 2: Jenkins Pipeline (Pipeline as Code)

• 概要: 1 回の実行でコンテナビルドからデプロイまでを自動化する。
• 特徴: Jenkinsfile (スクリプト): パイプラインをコードとして管理（Pipeline as Code）でき、バージョン管理が可能になる。
  • ステージビュー: 各工程（Build, Test, Deploy 等）を視覚的に把握できるダッシュボードが提供される。

Level 3: Kustomize / Helm による高度なデプロイ

• 概要: Level 2 の構成をベースに、デプロイコマンドを kubectl から Kustomize や Helm に変更する。
• 特徴: 環境別（Dev/Stg/Prod）のマニフェスト管理が容易になる。
  • パラメータのテンプレート化により、再利用性と保守性が向上する。

Level 4: ArgoCD によるデプロイの分離 (GitOps)

• 概要: CI (Jenkins) と CD (ArgoCD) の役割を完全に分離し、GitOps パターンを導入する。
• 特徴: 役割の分離: Jenkins はビルドとイメージプッシュ（CI）のみを担当し、デプロイ（CD）は ArgoCD が担当する。
  • 同期 (Sync): Git リポジトリ（マニフェスト）の状態と、実際の Kubernetes クラスターの状態を常に一致させる。
  • 自己修復 (Self-healing): クラスター内の設定が手動で書き換えられても、ArgoCD が検知して自動で Git の状態に復旧させる。
  • 視覚的な管理: クラスターのリソース構成やデプロイ状態を専用の GUI で詳細にモニタリングできる。