Fleet on AWS ECS 部署指南从架构依赖到 Terraform 任务定义的完整实现解析【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet本文以仓库中的 Deploy Fleet on AWS ECS 指南为主体讲解在 Amazon ECS 上部署 Fleet 服务器的完整思路Aurora MySQL 与 ElastiCache Redis 两类基础设施依赖、ECS 服务加负载均衡的核心拓扑以及用独立 ECS 任务执行fleet prepare --no-prompttrue db完成数据库迁移的工程实践。文中所有关键结论均结合仓库内的 ECS Terraform 实现、AWS 参考架构文档 与 fleet prepare 源码 逐条印证读者读完后能掌握一套可直接落地的 ECS 部署方案与生产加固要点。需要先说明适用前提原文档标注该指南已进入Archived归档状态——虽然仍可使用但近期未再更新当前受支持的部署方式请参见官方 Deploy Fleet 文档。因此本文的定位是参考架构与实现原理讲解其中的 ECS/Fargate 拓扑、迁移任务模式和连接池配置策略在当前仓库的 Terraform 基础设施代码中仍被沿用但具体命令与参数请以仓库当前版本的 Fleet 服务器配置文档 为准。一、基础设施依赖MySQL、Redis 与 Fleet 服务原文档把 AWS 上的 Fleet 部署拆成三个部分这也是 ECS 部署方案的全部骨架MySQL—— 原文推荐在 AWS 上运行AuroraMySQL Engine作为 Fleet 的主数据库Redis—— 原文推荐运行ElastiCacheRedis Engine用于分布式查询结果的摄入、排队与数据缓存Fleet server—— 运行在 ECS 上由ECS 服务ECS service与负载均衡器load balancer两个主要组件构成。这一拆分与仓库 参考架构文档 中的描述一致Fleet 的fleet二进制本身内建 TLS Web 服务器、Web 界面、REST API 和 osquery API 端点不需要外部 Web 服务器因此一个容器加一个负载均衡即可承载整个后端。MySQLAurora MySQL 的关键约束结合仓库内代码可以补充若干实操层面的约束版本要求参考架构文档 明确 Fleet 至少需要 MySQL 8.0.44且仅支持单写single-writer数据库拓扑——一个可写主库加只读副本不支持多写或组复制。Aurora 集群天然满足该拓扑。连接池总量必须规划Fleet 通过FLEET_MYSQL_MAX_OPEN_CONNS控制每个服务实例的 MySQL 最大打开连接数。仓库 变量定义 中对mysql_max_open_conns的注释给出了一个很有价值的容量模型单个 Aurora 实例实际承受的连接数约为fleet_containers * mysql_max_open_conns在主从切换或无只读副本时可能瞬时达到 2 倍只读流量回落到写端点。该变量还带了 Terraform 校验值必须大于 0因为database/sql中 0 表示不限制会耗尽 Aurora 的max_connections。RedisElastiCache 及集群模式配置Fleet 用 Redis 做缓存与查询结果队列。在 ECS 任务定义中见下文 ecs.tf 的实现需要同时设置FLEET_REDIS_ADDRESS指向 ElastiCache 副本组replication group的主端点端口 6379FLEET_REDIS_CLUSTER_FOLLOW_REDIRECTIONStrue当使用 ElastiCache 集群模式Cluster Mode时客户端需跟随 shard 重定向FLEET_REDIS_MAX_IDLE_CONNS/FLEET_REDIS_MAX_OPEN_CONNSRedis 连接池上限仓库实现中均取 100。二、ECS 服务与任务定义Fleet 服务在 AWS 上的落地形态原文指出在 ECS 上运行 Fleet 由 ECS 服务与负载均衡器两个主要组件构成。仓库 infrastructure/loadtesting/terraform/ecs.tf 中保存了一份完整的 Fargate 部署实现可以作为理解该拓扑的最佳样本。集群与服务ecs.tf 第 10-36 行 定义了核心服务集群启用containerInsights可直接在 CloudWatch 中获得容器级指标服务launch_type FARGATEdesired_count由变量fleet_containers控制滚动更新策略为deployment_minimum_healthy_percent 100、deployment_maximum_percent 200即先扩容再缩容的蓝绿式滚动保证更新期间容量不降health_check_grace_period_seconds 30服务同时挂接两个负载均衡目标组aws_lb_target_group.internal私网接入与aws_lb_target_group.main公网接入容器名fleet、容器端口8080——这是fleet serve的默认监听端口网络配置使用 VPC 私有子网加专用安全组。容器定义与配置注入任务定义ecs.tf 第 47-222 行展示了 Fleet 容器化的全部配置注入方式分为三类1) 环境变量非机密配置环境变量作用FLEET_MYSQL_USERNAME/FLEET_MYSQL_DATABASE/FLEET_MYSQL_ADDRESS指向 Aurora 集群写端点:3306FLEET_MYSQL_READ_REPLICA_USERNAME/_DATABASE/_ADDRESS/_MAX_OPEN_CONNS指向 Aurora 只读副本reader endpoint用于分流读流量FLEET_REDIS_ADDRESSElastiCache 主端点:6379FLEET_LOGGING_JSONtrue以 JSON 输出日志便于 CloudWatch 解析FLEET_S3_SOFTWARE_INSTALLERS_BUCKET软件包installers存放的 S3 桶FLEET_OSQUERY_STATUS_LOG_PLUGINfilesystem等日志插件指向 filesystem文件设为/dev/null本例不落地写文件由 awslogs 统一收日志2) Secrets Manager 注入的机密容器secrets块把四个机密从 AWS Secrets Manager 直接注入环境变量密码不落任务定义FLEET_MYSQL_PASSWORD/FLEET_MYSQL_READ_REPLICA_PASSWORD复用同一个数据库密码机密FLEET_LICENSE_KEY许可证密钥FLEET_SERVER_PRIVATE_KEY——仓库实现里甚至展示了完整的生成链路用random_password32 位、含特殊字符生成随机值再写入aws_secretsmanager_secret_version见 ecs.tf 第 338-355 行。3) 运行时资源约束任务cpu 1024、memory 4096Fargate CPU 单位 / MiBulimits把nofile打开文件数上限调到 9999——Fleet 要维持大量设备并发连接这是容器化部署中容易被忽略的一项portMappings暴露 8080/tcp网络模式awsvpc日志统一走awslogs驱动写入 CloudWatch Logs 日志组lifecycle { create_before_destroy true }确保任务定义更新时先建后删与服务的滚动更新策略配合避免部署间隙。此外任务中还编入了一个prometheus-exporter边车容器essential false通过PROMETHEUS_SCRAPE_URLhttp://localhost:8080/metrics抓取 Fleet 暴露的 Prometheus 格式指标并转发到 CloudWatch——这与 参考架构文档 中Fleet 暴露 Prometheus 兼容指标、Fleet 自带 /healthz 健康检查端点的监控体系相衔接负载均衡器可用/healthz做健康检查该端点在服务器可运行且 MySQL、Redis 连接健康时返回 HTTP 200否则返回 500。三、数据库迁移用独立 ECS 任务运行fleet prepare原文档中最具操作价值的部分是Fleet migrations在 ECS 中迁移可以通过运行专用的 ECS 任务来执行该任务运行fleet prepare --no-prompttrue db命令。也可以把 prepare 命令打进同一个任务定义中但对于生产环境不推荐这样做。命令本身源码层面的印证fleet prepare是 Fleet 二进制的子命令负责执行数据库迁移。cmd/fleet/prepare.go 第 120 行 中注册了该参数dbCmd.PersistentFlags().BoolVar(noPrompt, no-prompt, false, disable prompting before migrations (for use in scripts))--no-prompt的用途正是关闭迁移前的交互确认使命令可以在脚本/CI 环境中无人值守运行——这解释了为什么 ECS 任务、以及 docker-compose 部署 中的fleet prepare db --no-prompt都要显式带上它。迁移任务定义的实现细节ecs.tf 第 225-297 行 定义了一个独立的任务定义migration容器名fleet-prepare-db要点如下镜像与 Fleet 主容器相同复用同一个 Fleet 镜像但资源规格更小cpu 1024、memory 2048——迁移是一次性任务不需要 4GB 内存容器command [fleet, prepare, --no-prompttrue, db]运行完即退出只需注入FLEET_MYSQL_PASSWORD一个机密加 MySQL/Redis 连接环境变量不需要许可证、私钥等服务端机密日志流前缀fleet-migration便于在 CloudWatch 中单独检索迁移输出。为什么打进同一个任务定义不推荐用于生产原文虽未展开但从这套架构可以推断出原因Fleet 服务端在容器启动时会持续运行而迁移要求对数据库做独占性变更迁移期间需要短暂停机见 升级文档 中关于迁移期间短暂不可用的说明。若让每个服务副本启动时都去跑迁移多个副本会竞争执行迁移且版本滚动更新时先迁移与先启动的时序难以控制独立任务则把迁移变成 CI/CD 流水线中一个显式的、先于服务部署执行的步骤仓库中 DigitalOcean 参考方案同样采用PRE_DEPLOYjob 运行fleet prepare --no-prompttrue db的同一模式见 Reference-Architectures.md 第 514-528 行。四、容量规划与自动扩缩按主机规模选择规格参考架构文档 给出了 AWS/Fargate 部署的官方规格断点原文的ECS 服务 负载均衡拓扑正是在这个规模模型下工作的。摘录其中几档支持规模Fleet 实例CPU 单位内存FLEET_MYSQL_MAX_OPEN_CONNS≤ 5000 台主机6 个 Fargate 任务10244GB10≤ 10000 台主机8 个 Fargate 任务10244GB10≤ 25000 台主机10 个 Fargate 任务10244GB20≤ 50000 台主机15 个 Fargate 任务10244GB20≤ 150000 台主机40 个 Fargate 任务10244GB20对应的依赖规格Redis 7.x 起步 3 节点cache.t4g.small随规模升到cache.r6g.xlargeMySQL 为 Aurora MySQL 88.0.mysql_aurora.3.08.2从 2 节点db.t4g.medium起步升到 3 节点db.r6g.4xlarge。水平扩展的原理也很直接见参考架构Horizontal scaling一节Fleet 服务器是无状态的只要把更多fleet serve进程连到同一组 MySQL 和 Redis再在前面放负载均衡器即可所有 API 都按这种多实例拓扑设计。基于 CloudWatch 的目标追踪扩缩ecs.tf 第 299-336 行 配置了 Application Auto Scaling扩缩对象为ecs:service:DesiredCountmin_capacity与max_capacity均等于fleet_containers本例为固定副本数可按需调宽上下限两条TargetTrackingScaling策略内存利用率目标80%ECSServiceAverageMemoryUtilization、CPU 利用率目标90%ECSServiceAverageCPUUtilization。五、生产加固来自仓库 dogfood 模块的额外实践仓库 infrastructure/dogfood/terraform/aws-tf-module 是 Fleet 团队自用的 AWS Terraform 模块它在原文三要素之外补充了若干生产级做法引用官方 Terraform 模块free.tf 中的基础设施来自fleetdm/fleet-terraform仓库的byo-vpc模块tf-mod-byo-vpc-v1.31.0版本该模块即原文所指参考架构在 fleet-terraform 仓库的落地实现RDS TLS 强制加密Aurora 集群参数require_secure_transport ON数据库备份保留 30 天Fleet 侧通过FLEET_MYSQL_TLS_CA等变量加载 RDS CA 证书。由于容器内无法直接调用 AWS CLI 拉证书模块用一个rds-tls-ca-retriever边车容器alpine 镜像在启动时把 CA 证书写入共享卷Fleet 主容器再从该卷读取——这是原文未涉及、但在 AWS 上启用 MySQL TLS 时几乎必然遇到的工程细节连接生命周期管理设置了FLEET_MYSQL_CONN_MAX_LIFETIME 14400与FLEET_MYSQL_READ_REPLICA_CONN_MAX_LIFETIME 14400避免长连接在数据库维护窗口后成为僵尸连接。六、关键路径索引主题仓库路径本文主体原文档articles/deploy-fleet-on-aws-ecs.mdECS 服务/任务定义/迁移任务/自动扩缩infrastructure/loadtesting/terraform/ecs.tfmysql_max_open_conns变量与容量注释infrastructure/loadtesting/terraform/variables.tfAWS 生产模块BYO-VPC、RDS TLS、Redis 7.1infrastructure/dogfood/terraform/aws-tf-module/free.tfAWS 规格断点与 S3/Terraform IAM 说明docs/Deploy/Reference-Architectures.mdfleet prepare db与--no-prompt参数cmd/fleet/prepare.go迁移期间的升级与停机说明docs/Deploy/Upgrading-Fleet.md小结在 AWS 上用 ECS 部署 Fleet 的完整链路是——Aurora MySQL 8 作为单写主库可加只读副本分流、ElastiCache Redis 承载队列与缓存、Fargate 任务运行fleet serve并经 Application Load Balancer 的 8080 端口对外服务、机密统一走 Secrets Manager、数据库迁移用独立的fleet prepare --no-prompttrue db任务在部署流水线中先于服务启动执行。原文档虽然已归档但这套两组件服务 三类依赖 独立迁移任务的架构在当前仓库的基础设施代码中依然是 AWS 部署的参考范式。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Fleet on AWS ECS 部署指南：从架构依赖到 Terraform 任务定义的完整实现解析
Fleet on AWS ECS 部署指南从架构依赖到 Terraform 任务定义的完整实现解析【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet本文以仓库中的 Deploy Fleet on AWS ECS 指南为主体讲解在 Amazon ECS 上部署 Fleet 服务器的完整思路Aurora MySQL 与 ElastiCache Redis 两类基础设施依赖、ECS 服务加负载均衡的核心拓扑以及用独立 ECS 任务执行fleet prepare --no-prompttrue db完成数据库迁移的工程实践。文中所有关键结论均结合仓库内的 ECS Terraform 实现、AWS 参考架构文档 与 fleet prepare 源码 逐条印证读者读完后能掌握一套可直接落地的 ECS 部署方案与生产加固要点。需要先说明适用前提原文档标注该指南已进入Archived归档状态——虽然仍可使用但近期未再更新当前受支持的部署方式请参见官方 Deploy Fleet 文档。因此本文的定位是参考架构与实现原理讲解其中的 ECS/Fargate 拓扑、迁移任务模式和连接池配置策略在当前仓库的 Terraform 基础设施代码中仍被沿用但具体命令与参数请以仓库当前版本的 Fleet 服务器配置文档 为准。一、基础设施依赖MySQL、Redis 与 Fleet 服务原文档把 AWS 上的 Fleet 部署拆成三个部分这也是 ECS 部署方案的全部骨架MySQL—— 原文推荐在 AWS 上运行AuroraMySQL Engine作为 Fleet 的主数据库Redis—— 原文推荐运行ElastiCacheRedis Engine用于分布式查询结果的摄入、排队与数据缓存Fleet server—— 运行在 ECS 上由ECS 服务ECS service与负载均衡器load balancer两个主要组件构成。这一拆分与仓库 参考架构文档 中的描述一致Fleet 的fleet二进制本身内建 TLS Web 服务器、Web 界面、REST API 和 osquery API 端点不需要外部 Web 服务器因此一个容器加一个负载均衡即可承载整个后端。MySQLAurora MySQL 的关键约束结合仓库内代码可以补充若干实操层面的约束版本要求参考架构文档 明确 Fleet 至少需要 MySQL 8.0.44且仅支持单写single-writer数据库拓扑——一个可写主库加只读副本不支持多写或组复制。Aurora 集群天然满足该拓扑。连接池总量必须规划Fleet 通过FLEET_MYSQL_MAX_OPEN_CONNS控制每个服务实例的 MySQL 最大打开连接数。仓库 变量定义 中对mysql_max_open_conns的注释给出了一个很有价值的容量模型单个 Aurora 实例实际承受的连接数约为fleet_containers * mysql_max_open_conns在主从切换或无只读副本时可能瞬时达到 2 倍只读流量回落到写端点。该变量还带了 Terraform 校验值必须大于 0因为database/sql中 0 表示不限制会耗尽 Aurora 的max_connections。RedisElastiCache 及集群模式配置Fleet 用 Redis 做缓存与查询结果队列。在 ECS 任务定义中见下文 ecs.tf 的实现需要同时设置FLEET_REDIS_ADDRESS指向 ElastiCache 副本组replication group的主端点端口 6379FLEET_REDIS_CLUSTER_FOLLOW_REDIRECTIONStrue当使用 ElastiCache 集群模式Cluster Mode时客户端需跟随 shard 重定向FLEET_REDIS_MAX_IDLE_CONNS/FLEET_REDIS_MAX_OPEN_CONNSRedis 连接池上限仓库实现中均取 100。二、ECS 服务与任务定义Fleet 服务在 AWS 上的落地形态原文指出在 ECS 上运行 Fleet 由 ECS 服务与负载均衡器两个主要组件构成。仓库 infrastructure/loadtesting/terraform/ecs.tf 中保存了一份完整的 Fargate 部署实现可以作为理解该拓扑的最佳样本。集群与服务ecs.tf 第 10-36 行 定义了核心服务集群启用containerInsights可直接在 CloudWatch 中获得容器级指标服务launch_type FARGATEdesired_count由变量fleet_containers控制滚动更新策略为deployment_minimum_healthy_percent 100、deployment_maximum_percent 200即先扩容再缩容的蓝绿式滚动保证更新期间容量不降health_check_grace_period_seconds 30服务同时挂接两个负载均衡目标组aws_lb_target_group.internal私网接入与aws_lb_target_group.main公网接入容器名fleet、容器端口8080——这是fleet serve的默认监听端口网络配置使用 VPC 私有子网加专用安全组。容器定义与配置注入任务定义ecs.tf 第 47-222 行展示了 Fleet 容器化的全部配置注入方式分为三类1) 环境变量非机密配置环境变量作用FLEET_MYSQL_USERNAME/FLEET_MYSQL_DATABASE/FLEET_MYSQL_ADDRESS指向 Aurora 集群写端点:3306FLEET_MYSQL_READ_REPLICA_USERNAME/_DATABASE/_ADDRESS/_MAX_OPEN_CONNS指向 Aurora 只读副本reader endpoint用于分流读流量FLEET_REDIS_ADDRESSElastiCache 主端点:6379FLEET_LOGGING_JSONtrue以 JSON 输出日志便于 CloudWatch 解析FLEET_S3_SOFTWARE_INSTALLERS_BUCKET软件包installers存放的 S3 桶FLEET_OSQUERY_STATUS_LOG_PLUGINfilesystem等日志插件指向 filesystem文件设为/dev/null本例不落地写文件由 awslogs 统一收日志2) Secrets Manager 注入的机密容器secrets块把四个机密从 AWS Secrets Manager 直接注入环境变量密码不落任务定义FLEET_MYSQL_PASSWORD/FLEET_MYSQL_READ_REPLICA_PASSWORD复用同一个数据库密码机密FLEET_LICENSE_KEY许可证密钥FLEET_SERVER_PRIVATE_KEY——仓库实现里甚至展示了完整的生成链路用random_password32 位、含特殊字符生成随机值再写入aws_secretsmanager_secret_version见 ecs.tf 第 338-355 行。3) 运行时资源约束任务cpu 1024、memory 4096Fargate CPU 单位 / MiBulimits把nofile打开文件数上限调到 9999——Fleet 要维持大量设备并发连接这是容器化部署中容易被忽略的一项portMappings暴露 8080/tcp网络模式awsvpc日志统一走awslogs驱动写入 CloudWatch Logs 日志组lifecycle { create_before_destroy true }确保任务定义更新时先建后删与服务的滚动更新策略配合避免部署间隙。此外任务中还编入了一个prometheus-exporter边车容器essential false通过PROMETHEUS_SCRAPE_URLhttp://localhost:8080/metrics抓取 Fleet 暴露的 Prometheus 格式指标并转发到 CloudWatch——这与 参考架构文档 中Fleet 暴露 Prometheus 兼容指标、Fleet 自带 /healthz 健康检查端点的监控体系相衔接负载均衡器可用/healthz做健康检查该端点在服务器可运行且 MySQL、Redis 连接健康时返回 HTTP 200否则返回 500。三、数据库迁移用独立 ECS 任务运行fleet prepare原文档中最具操作价值的部分是Fleet migrations在 ECS 中迁移可以通过运行专用的 ECS 任务来执行该任务运行fleet prepare --no-prompttrue db命令。也可以把 prepare 命令打进同一个任务定义中但对于生产环境不推荐这样做。命令本身源码层面的印证fleet prepare是 Fleet 二进制的子命令负责执行数据库迁移。cmd/fleet/prepare.go 第 120 行 中注册了该参数dbCmd.PersistentFlags().BoolVar(noPrompt, no-prompt, false, disable prompting before migrations (for use in scripts))--no-prompt的用途正是关闭迁移前的交互确认使命令可以在脚本/CI 环境中无人值守运行——这解释了为什么 ECS 任务、以及 docker-compose 部署 中的fleet prepare db --no-prompt都要显式带上它。迁移任务定义的实现细节ecs.tf 第 225-297 行 定义了一个独立的任务定义migration容器名fleet-prepare-db要点如下镜像与 Fleet 主容器相同复用同一个 Fleet 镜像但资源规格更小cpu 1024、memory 2048——迁移是一次性任务不需要 4GB 内存容器command [fleet, prepare, --no-prompttrue, db]运行完即退出只需注入FLEET_MYSQL_PASSWORD一个机密加 MySQL/Redis 连接环境变量不需要许可证、私钥等服务端机密日志流前缀fleet-migration便于在 CloudWatch 中单独检索迁移输出。为什么打进同一个任务定义不推荐用于生产原文虽未展开但从这套架构可以推断出原因Fleet 服务端在容器启动时会持续运行而迁移要求对数据库做独占性变更迁移期间需要短暂停机见 升级文档 中关于迁移期间短暂不可用的说明。若让每个服务副本启动时都去跑迁移多个副本会竞争执行迁移且版本滚动更新时先迁移与先启动的时序难以控制独立任务则把迁移变成 CI/CD 流水线中一个显式的、先于服务部署执行的步骤仓库中 DigitalOcean 参考方案同样采用PRE_DEPLOYjob 运行fleet prepare --no-prompttrue db的同一模式见 Reference-Architectures.md 第 514-528 行。四、容量规划与自动扩缩按主机规模选择规格参考架构文档 给出了 AWS/Fargate 部署的官方规格断点原文的ECS 服务 负载均衡拓扑正是在这个规模模型下工作的。摘录其中几档支持规模Fleet 实例CPU 单位内存FLEET_MYSQL_MAX_OPEN_CONNS≤ 5000 台主机6 个 Fargate 任务10244GB10≤ 10000 台主机8 个 Fargate 任务10244GB10≤ 25000 台主机10 个 Fargate 任务10244GB20≤ 50000 台主机15 个 Fargate 任务10244GB20≤ 150000 台主机40 个 Fargate 任务10244GB20对应的依赖规格Redis 7.x 起步 3 节点cache.t4g.small随规模升到cache.r6g.xlargeMySQL 为 Aurora MySQL 88.0.mysql_aurora.3.08.2从 2 节点db.t4g.medium起步升到 3 节点db.r6g.4xlarge。水平扩展的原理也很直接见参考架构Horizontal scaling一节Fleet 服务器是无状态的只要把更多fleet serve进程连到同一组 MySQL 和 Redis再在前面放负载均衡器即可所有 API 都按这种多实例拓扑设计。基于 CloudWatch 的目标追踪扩缩ecs.tf 第 299-336 行 配置了 Application Auto Scaling扩缩对象为ecs:service:DesiredCountmin_capacity与max_capacity均等于fleet_containers本例为固定副本数可按需调宽上下限两条TargetTrackingScaling策略内存利用率目标80%ECSServiceAverageMemoryUtilization、CPU 利用率目标90%ECSServiceAverageCPUUtilization。五、生产加固来自仓库 dogfood 模块的额外实践仓库 infrastructure/dogfood/terraform/aws-tf-module 是 Fleet 团队自用的 AWS Terraform 模块它在原文三要素之外补充了若干生产级做法引用官方 Terraform 模块free.tf 中的基础设施来自fleetdm/fleet-terraform仓库的byo-vpc模块tf-mod-byo-vpc-v1.31.0版本该模块即原文所指参考架构在 fleet-terraform 仓库的落地实现RDS TLS 强制加密Aurora 集群参数require_secure_transport ON数据库备份保留 30 天Fleet 侧通过FLEET_MYSQL_TLS_CA等变量加载 RDS CA 证书。由于容器内无法直接调用 AWS CLI 拉证书模块用一个rds-tls-ca-retriever边车容器alpine 镜像在启动时把 CA 证书写入共享卷Fleet 主容器再从该卷读取——这是原文未涉及、但在 AWS 上启用 MySQL TLS 时几乎必然遇到的工程细节连接生命周期管理设置了FLEET_MYSQL_CONN_MAX_LIFETIME 14400与FLEET_MYSQL_READ_REPLICA_CONN_MAX_LIFETIME 14400避免长连接在数据库维护窗口后成为僵尸连接。六、关键路径索引主题仓库路径本文主体原文档articles/deploy-fleet-on-aws-ecs.mdECS 服务/任务定义/迁移任务/自动扩缩infrastructure/loadtesting/terraform/ecs.tfmysql_max_open_conns变量与容量注释infrastructure/loadtesting/terraform/variables.tfAWS 生产模块BYO-VPC、RDS TLS、Redis 7.1infrastructure/dogfood/terraform/aws-tf-module/free.tfAWS 规格断点与 S3/Terraform IAM 说明docs/Deploy/Reference-Architectures.mdfleet prepare db与--no-prompt参数cmd/fleet/prepare.go迁移期间的升级与停机说明docs/Deploy/Upgrading-Fleet.md小结在 AWS 上用 ECS 部署 Fleet 的完整链路是——Aurora MySQL 8 作为单写主库可加只读副本分流、ElastiCache Redis 承载队列与缓存、Fargate 任务运行fleet serve并经 Application Load Balancer 的 8080 端口对外服务、机密统一走 Secrets Manager、数据库迁移用独立的fleet prepare --no-prompttrue db任务在部署流水线中先于服务启动执行。原文档虽然已归档但这套两组件服务 三类依赖 独立迁移任务的架构在当前仓库的基础设施代码中依然是 AWS 部署的参考范式。【免费下载链接】fleetOpen device management项目地址: https://gitcode.com/GitHub_Trending/fl/fleet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考