75 lines
5.3 KiB
Markdown
75 lines
5.3 KiB
Markdown
---
|
||
title: "Learning Sessions ECS Deployment using IAC - 20230808"
|
||
type: source
|
||
tags:
|
||
- AWS
|
||
- ECS
|
||
- IaC
|
||
- Terraform
|
||
- CTP
|
||
date: 2023-08-08
|
||
---
|
||
|
||
## Source File
|
||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md]]
|
||
|
||
## Summary（用中文描述）
|
||
- 核心主题：通过基础设施即代码（IaC）使用 Terraform 模块部署 Amazon ECS 容器服务，涵盖 ECS 业务背景、技术架构、CTP/SRE 团队开发的 Terraform 模块详解及最佳实践。
|
||
- 问题域：企业如何在 AWS 云中通过 Terraform IaC 模块标准化、可重复地部署和管理 ECS 容器集群，实现动态扩缩和自动化运维。
|
||
- 方法/机制：
|
||
- **业务背景**：企业面临不可预测性和敏捷性挑战，动态扩缩能力是关键，ECS 作为 AWS 原生容器编排服务集成 AWS 生态。
|
||
- **ECS 模块架构**：基于 Gruntwork 模块构建，支持 Docker 容器创建、EC2 实例或 Fargate 部署目标；提供自动扩缩容（Auto Scaling）、自动恢复（Auto Healing）和金丝雀部署（Canary Deployment）能力。
|
||
- **Listener 模式**：实现集中式 ECS 管理，避免各产品团队直接下载 Gruntwork 模块本地使用。
|
||
- **前置条件**：VPC、ELB 安全组、EFS 卷挂载；配置通过 YAML/JSON 传递；集成 CloudWatch、Splunk、Grafana、Prometheus。
|
||
- 结论/价值：CTP/SRE ECS Terraform 模块提供企业级容器编排方案，通过 IaC 实现标准化部署，通过 Listener 模式实现集中管控，通过 ELB + Target Group 实现金丝雀部署和灰度发布。
|
||
|
||
## Key Claims（用中文描述）
|
||
- 企业必须在不可预测性和敏捷性挑战中生存，代码（Code）是应对之道，基础设施即代码使企业能够在挑战中锻造（forged by code）。
|
||
- 动态扩缩容（Dynamic Scaling）是应对不可预测负载模式的关键技术能力，技术必须不断演进。
|
||
- ECS 是 AWS 原生专有技术，相比 EKS 或原生 Kubernetes 具有集成优势，但同时也面临云厂商锁定的挑战。
|
||
- CTP/SRE 团队基于 Gruntwork 模块构建了企业级 ECS Terraform 模块，支持 Docker 容器化部署。
|
||
- Listener 模式实现集中式 ECS 管理，防止各产品团队重复下载和使用 Gruntwork 模块。
|
||
- ECS 模块支持自动扩缩容（Auto Scaling）、自动恢复（Auto Healing）和金丝雀部署（Canary Deployment）。
|
||
- 监控集成支持 AWS CloudWatch、Splunk、Grafana 和 Prometheus。
|
||
|
||
## Key Quotes
|
||
> "Businesses have to thrive in the middle of all these challenges and it is forged by code." — ECS IaC 部署的核心驱动力：业务敏捷性
|
||
|
||
> "We have implemented the listener approach because we have seen many of the products are you know they are downloading the quotes from the grant work and using locally." — Listener 模式实施原因：避免本地重复使用 Gruntwork 模块
|
||
|
||
> "ECS (Elastic Container Services) is an AWS proprietary technology that integrates with AWS services, offering advantages and challenges compared to EKS or native Kubernetes." — ECS vs EKS 权衡
|
||
|
||
## Key Concepts
|
||
- [[ECS]]：AWS 托管容器编排服务，支持 Docker 容器在 EC2 或 Fargate 上的运行和管理。
|
||
- [[Infrastructure-as-Code]]：通过声明式代码管理 ECS 基础设施，实现标准化、可重复的部署。
|
||
- [[Terraform]]：HashiCorp 出品的 IaC 工具，用于定义和部署 ECS 集群模块。
|
||
- [[Gruntwork]]：提供生产级 Terraform 模块的基础设施库，CTP ECS 模块基于 Gruntwork 构建。
|
||
- [[Auto-Scaling]]：ECS 自动扩缩容能力，根据负载动态调整容器实例数量。
|
||
- [[Canary-Deployment]]：金丝雀部署策略，通过 Target Group 权重逐步将流量导向新版本。
|
||
- [[Listener]]：集中式 ECS 管理模式，实现统一入口和流量分发控制。
|
||
- [[ELB]]（Elastic Load Balancing）：弹性负载均衡，与 ECS 集成实现流量分发和高可用。
|
||
|
||
## Key Entities
|
||
- [[AWS]]：Amazon Web Services，提供 ECS 容器编排服务和相关 AWS 生态集成。
|
||
- [[Gruntwork]]：提供生产级 Terraform 模块的基础设施库，CTP ECS 模块的构建基础。
|
||
- [[JP]]：CTP 技术专家，负责讲解 ECS 的业务和技术背景。
|
||
- [[Raja-M]]：CTP/SRE 技术专家，负责详解 CTP/SRE 团队开发的 ECS Terraform 模块。
|
||
- [[SRE]]（Site Reliability Engineering）：SRE 团队，负责 ECS 模块的设计、开发和维护。
|
||
|
||
## Connections
|
||
- [[ECS]] ← deployed_by ← [[Terraform]]
|
||
- [[ECS]] ← built_on ← [[Gruntwork]]
|
||
- [[ECS]] ← managed_by ← [[Listener]]
|
||
- [[ECS]] ← scales_with ← [[Auto-Scaling]]
|
||
- [[ECS]] ← deploys_with ← [[Canary-Deployment]]
|
||
- [[ECS]] ← monitored_by ← CloudWatch / Splunk / Grafana / Prometheus
|
||
- [[ECS]] ← load_balanced_by ← [[ELB]]
|
||
- [[Gruntwork]] ← extended_by ← [[Terraform-IaC]]（CTP ECS 模块）
|
||
|
||
## Contradictions
|
||
- ECS vs EKS：
|
||
- 冲突点：选择 ECS 还是 EKS 作为容器编排平台。
|
||
- 当前观点（本 session）：ECS 是 AWS 专有技术，与 AWS 服务深度集成，具有原生优势，适合 AWS 优先策略。
|
||
- 对方观点（其他来源）：EKS 提供 Kubernetes 标准生态，跨云可移植性更强，适合多云策略。
|
||
- 说明：两者各有适用场景，ECS 适合 AWS 深度集成场景，EKS 适合需要 Kubernetes 一致性的多云环境。
|