Valerio Uberti

多くのチームが Terraform で AWS をプロビジョニングした後も続けています: Helm チャート、名前空間、アドオン、さらには EKS 内のアプリケーションマニフェストまで。

これは効率的に見えます。実際には、インフラストラクチャとプラットフォームの境界を曖昧にする最も速い方法です。

より良いモデルは最初は不便です:

  • アプリケーションリポジトリはソースコードとビルド用;
  • 運用リポジトリは Terraform と GitOps マニフェスト用;
  • Terraform は AWS と EKS の境界に限定;
  • ArgoCD はクラスター内のすべてを担当。

本当の問題はライフサイクルのミスマッチです。VPC、IAM ロール、ノードグループはゆっくりと変化します。Kubernetes マニフェスト、プラットフォームアドオン、イメージタグは頻繁に変化します。両方のレイヤーを Terraform に通すと、インフラストラクチャプロビジョニングがリリースエンジンになってしまいます。

そこで問題が発生します:

  • アプリケーションのデプロイがインフラストラクチャリスクを引き継ぐ;
  • ロールバックが本来あるべきより重くなる;
  • Terraform と ArgoCD が同じクラスター状態をめぐって競合する可能性がある;
  • CI パイプラインが本来持つべきでないクラスター認証情報を必要とする。

リポジトリ構造、Terraform の例、ArgoCD のマニフェスト、正確なデプロイフローを含む完全な分析をこちらに書きました:

👉 完全な記事を読む