1. 项目概述这不是“上云”而是“卸载服务器包袱”“Dump Your Servers for AWS Fargate”——这个标题不是一句营销口号而是一线运维和架构师在连续处理第7次凌晨三点的磁盘告警、第3轮容器镜像构建失败、以及第N次为某台EC2实例打补丁却意外中断了核心批处理任务后脱口而出的真实情绪。它直指一个被长期掩盖但日益尖锐的现实你手里的服务器正在从基础设施变成负债。不是技术落后而是维护成本、响应延迟、资源错配和人为风险这四重压力已经让传统服务器托管模式在多数中后台服务场景中失去了经济性与可持续性。我过去三年主导过12个从EC2/自建K8s向Fargate迁移的项目覆盖支付对账、日志聚合、报表生成、API网关后端、数据清洗流水线等典型场景。实测下来真正能“Dump”掉服务器的从来不是Fargate本身而是你能否重新定义“服务”的边界。Fargate不是另一个IaaS层它强制你把“部署单元”从“一台能SSH进去的机器”压缩成“一个能健康检查通过的容器进程”。这意味着你不再需要关心内核版本是否兼容glibc 2.31不用再为swap分区大小争论不休也不用在Prometheus里为每个节点单独配置node_exporter采集规则。所有这些“服务器感”极强的操作都被抽象掉了——但代价是你必须提前想清楚我的应用到底依赖哪些操作系统级能力它重启时状态是否可丢弃它的启动时间能不能压到30秒内它的内存峰值是不是稳定在2GB以下这个标题里的“Dump”是动词不是名词。它不是让你一键清空资产清单而是要求你完成一次认知切换从“管理硬件生命周期”转向“定义服务交付契约”。适合读这篇内容的不是刚学完Docker基础的新手也不是还在用CloudFormation写500行模板的老派SRE而是那些正坐在会议室里被业务方催着“为什么订单导出要卡40秒”、被财务问“为什么上季度云账单涨了67%”、被安全团队盯着“那台Ubuntu 16.04的跳板机什么时候下线”的实战派。如果你的答案还停留在“加CPU”“扩磁盘”“换SSD”那这篇就是为你写的——因为Fargate的真正价值不在它多快而在它逼你把那些靠“加资源”掩盖的设计债一次性翻出来重算。2. 核心设计逻辑为什么Fargate不是“另一个容器平台”而是一套约束型交付协议2.1 本质差异从“租用计算资源”到“购买服务履约能力”很多人第一次接触Fargate会下意识把它当成“ECS的无服务器版”甚至类比成“AWS版的Kubernetes Kubelet自动托管”。这种理解偏差直接导致后续踩坑率飙升。Fargate的本质是一份由AWS强制执行的服务履约协议Service Level Agreement, SLA而这份协议的核心条款全部围绕“不可变性”和“瞬时性”展开。我们来拆解几个关键约束无持久化本地存储Fargate任务启动时挂载的/tmp和/var/log是临时卷任务终止即销毁。你无法像在EC2上那样把Redis的RDB文件存到/data/redis/然后指望下次重启还能读。这不是功能缺失而是协议明确告诉你“你的状态必须外置”。实操中我们强制所有迁移项目在Dockerfile里加入RUN mkdir -p /app/data chmod 777 /app/data并在应用启动脚本里校验/app/data是否可写——这看似多余实则是用代码固化契约意识。无SSH访问权你永远无法ssh -i key.pem ec2-userip进Fargate任务。这不是权限问题而是架构选择。Fargate的任务生命周期以“健康检查通过”为起点“健康检查失败或超时”为终点。中间过程完全黑盒。我们曾有个Java应用因JVM参数-XX:UseG1GC在特定内存规格下触发长时间GC停顿导致健康检查超时被反复重启。排查路径不是登录看jstat而是改用CloudWatch Logs Insights查ContainerStartedAt和HealthCheckFailedAt时间戳差值再结合X-Ray追踪GC事件。这种调试范式倒逼我们把可观测性前置到代码里。CPU/内存规格强绑定Fargate只提供离散档位如0.25vCPU/0.5GB内存、2vCPU/4GB内存。你不能像EC2那样动态调整c5.large的CPU份额。这意味着应用的资源画像必须精确到小数点后一位。我们开发了一套轻量级压测工具在CI阶段自动运行3轮wrk -t2 -c100 -d30s http://localhost:8080/health采集docker stats输出的MemUsage和CPUPerc峰值取95分位数后向上取整到最近Fargate档位。这套流程让资源预估误差从早期的±40%降到现在的±8%。提示Fargate的“无状态”不是技术限制而是商业契约。AWS通过移除SSH、禁用本地存储、锁定资源配置把运维责任从用户侧彻底转移到自己侧。你付出的不是更高价格而是更早暴露设计缺陷的机会。2.2 迁移决策树什么该迁什么不该碰什么得先动刀不是所有跑在服务器上的东西都适合“Dump”。我们内部用一张三维度决策矩阵评估迁移优先级维度高适配✅ 优先迁中风险⚠️ 需改造低适配❌ 暂缓状态依赖纯计算型ETL、转码、OCR、HTTP API无本地Session依赖本地缓存如Caffeine、需快速冷启动的WebSocket网关数据库PostgreSQL/MySQL、有状态消息队列RabbitMQ、需要共享内存的实时音视频服务启动特性启动时间15秒、无复杂初始化如加载10GB模型启动含数据库连接池预热、需下载远程配置中心配置启动需挂载加密HSM设备、依赖BIOS级硬件指令如SGX运维模式日志/指标已接入CloudWatch、错误可重试、无定时任务硬依赖服务器时间使用Cron表达式调度、需固定IP做白名单、依赖/proc/sys/net内核参数调优需物理隔离金融合规、需定制内核模块如eBPF监控探针举个真实案例某电商的“优惠券发放服务”原部署在3台t3.xlarge EC2上用Redis Cluster做库存扣减。表面看符合“无状态”但实际存在两个隐藏陷阱一是优惠券发放请求含幂等性校验校验结果缓存在本地ConcurrentHashMap里二是为防超发代码里写了Thread.sleep(10)做微秒级限流。迁移前我们做了两件事第一把本地缓存替换为DynamoDB AcceleratorDAX集群用GetItem替代containsKey()第二把sleep换成基于CloudWatch Events的异步重试队列。改造后QPS从1200提升到3800而Fargate成本比原EC2集群低41%。注意所谓“不适合迁移”往往不是技术不可行而是改造成本超过收益阈值。我们设定的硬性红线是单服务改造工时80人日或预期年节省成本当前年运维成本的30%则暂缓。2.3 架构重构原则用Fargate倒逼微服务治理升级Fargate本身不解决微服务问题但它像一面高精度显微镜把你在单体架构里惯用的“快捷方式”照得纤毫毕现。我们总结出三条重构铁律第一律健康检查即服务契约Fargate的HEALTH_CHECK不是可选项而是任务存活的唯一判据。我们强制所有服务将/health端点升级为“全链路健康探针”它不仅要检查自身HTTP端口可达还要同步验证下游依赖如调用订单服务的/health?deeptrue并返回JSON结构体包含各依赖的status、latency_ms、error_rate_5m。当某个依赖超时/health返回503 Service Unavailable而非200 OKFargate会立即停止调度新流量。这倒逼团队建立跨服务SLA协商机制——比如订单服务承诺/health?deeptrue响应时间200ms否则上游必须降级。第二律日志即唯一真相源没有SSH就没有tail -f /var/log/app.log。我们规定所有Fargate任务必须将日志输出到stdout/stderr且格式为JSON含timestamp、level、service_name、trace_id、span_id。CloudWatch Logs自动采集后通过订阅过滤器推送到OpenSearch。曾有个Python服务因logging.basicConfig(levellogging.INFO)未设置format导致日志全是纯文本无法被结构化查询。我们为此开发了CI检查插件在docker build阶段扫描requirements.txt中的logging配置未达标则阻断发布。第三律配置即不可变环境变量Fargate不支持挂载ConfigMap或Secrets Manager自动轮转。我们采用“启动时注入”模式任务启动时容器入口脚本先调用aws ssm get-parameter --name /prod/app/db_password --with-decryption获取密钥再写入临时文件并chmod 400最后启动主进程。为防密钥泄露我们给SSM Parameter Store设置了精细的IAM策略仅允许特定ECS Task Role读取且所有调用记录进入CloudTrail。这套方案比K8s的Secrets更透明审计线索更完整。3. 实操落地从服务器镜像到Fargate任务的七步炼金术3.1 步骤一镜像瘦身——砍掉所有“可能有用”的二进制服务器时代我们习惯在基础镜像里预装vim、curl、jq、net-tools美其名曰“方便调试”。Fargate时代这是赤裸裸的浪费。我们用dive工具分析某Node.js服务镜像发现/usr/bin/vim.tiny占12MB/usr/bin/curl占2.3MB而整个应用代码才8MB。更致命的是这些二进制会增加CVE扫描风险面。我们的瘦身流程基座选择放弃node:18-alpine改用public.ecr.aws/lambda/nodejs:18AWS官方Lambda运行时镜像。它已预装Lambda Runtime Interface ClientRIC与Fargate底层Runtime无缝兼容且体积比Alpine小37%。多阶段构建在Dockerfile中严格分离构建与运行环境# 构建阶段 FROM public.ecr.aws/lambda/nodejs:18 AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction COPY . . RUN npm run build # 运行阶段 FROM public.ecr.aws/lambda/nodejs:18 WORKDIR /app COPY --frombuilder /app/dist ./dist COPY --frombuilder /app/node_modules ./node_modules CMD [dist/index.js]关键点npm ci --onlyproduction确保只安装生产依赖COPY --frombuilder避免将node_modules/.bin里的webpack等构建工具带入运行镜像。最终验证用docker history image检查每层大小要求单层5MB必须说明理由用trivy image --severity CRITICAL image扫描高危漏洞修复率必须100%。实测效果某React SSR服务镜像从1.2GB压至87MB冷启动时间从42秒降至11秒且每月安全告警减少92%。3.2 步骤二网络拓扑重绘——告别“同VPC即互通”的懒人思维服务器时代只要EC2在同一个VPC就默认能ping通、telnet通。Fargate打破这个幻觉。它强制你面对三个网络事实安全组Security Group作用于ENI而非实例Fargate任务启动时AWS为其创建弹性网络接口ENI安全组规则绑定到ENI。这意味着你不能再用“开放整个VPC CIDR到3306端口”这种粗放策略而必须精确到目标RDS实例的ENI ID或安全组ID。私有子网需NAT网关或VPC EndpointFargate任务若需访问S3、Secrets Manager等AWS服务必须走VPC Endpoint推荐或NAT网关。我们曾因忘记为S3配置Gateway VPC Endpoint导致任务启动时拉取配置失败健康检查超时被反复重启。跨AZ通信成本显性化Fargate任务默认随机调度到可用区若你的RDS主库在us-east-1a而Fargate任务常被调度到us-east-1b则每次数据库连接都产生跨AZ流量费$0.01/GB。我们通过placementConstraints强制任务与RDS同AZplacementConstraints: [ { type: memberOf, expression: attribute:ecs.availability-zone us-east-1a } ]我们绘制了新的网络拓扑图用不同颜色标注绿色VPC Endpoint直连、蓝色NAT网关出口、红色跨AZ流量。这张图成为所有迁移项目的必审材料。3.3 步骤三资源规格精算——用压测数据代替拍脑袋Fargate的CPU/内存档位是离散的选错档位代价巨大。我们开发了一套自动化精算流程阶段1基准压测使用k6在CI环境中模拟真实流量k6 run -u 50 -d 300s \ --vus 100 \ --thresholds http_req_duration{expected_response:true}#95200 \ script.jsscript.js模拟用户登录→查询订单→导出PDF的完整链路--thresholds强制95%请求耗时200ms否则测试失败。阶段2资源捕获在压测同时用aws ecs describe-tasksAPI每5秒采集任务指标aws ecs describe-tasks \ --cluster my-cluster \ --tasks $TASK_ID \ --query tasks[0].containers[0].memoryReservation \ --output text提取memoryReservation实际内存占用和cpuReservationCPU使用率的99分位数。阶段3档位匹配将采集数据输入匹配算法内存取memoryReservation_99p * 1.3预留30%缓冲向上取整到最近Fargate档位如1.8GB→2GBCPU取cpuReservation_99p * 1.5应对突发匹配最接近档位如65%→1vCPU我们曾有个Python Flask服务压测显示内存峰值1.4GB按此算法应选2GB档位。但上线后发现偶发OOM追查发现是psycopg2连接池在高并发下内存泄漏。最终解决方案是在requirements.txt中强制psycopg2-binary2.9.7已修复该问题并将档位升至3GB。这印证了我们的信条压测数据是起点不是终点档位选择是工程判断不是数学计算。3.4 步骤四任务定义Task Definition编写——YAML里的黄金法则Fargate的任务定义Task Definition是声明式契约写错一行就可能导致任务无法启动。我们提炼出五条黄金法则法则1容器定义必须显式声明essential: trueFargate任务中至少一个容器必须标记为essential: true。如果所有容器都设为false任务会立即退出。我们曾有个日志收集边车容器sidecar误设为essential: true而主应用容器因健康检查失败被杀导致整个任务因“essential容器退出”而终止。正确做法主应用容器essential: true边车容器essential: false。法则2健康检查路径必须带/前缀且小写Fargate的健康检查URL必须是绝对路径如HTTP:8080/health。写成HTTP:8080health或HTTP:8080/HEALTH会导致健康检查永远失败。我们用CI脚本校验healthCheck字段正则^HTTP:[0-9]\/[a-z0-9\-_\/]$。法则3环境变量加密必须用secrets而非environment敏感信息如数据库密码必须通过secrets字段注入而非environment。secrets会从Secrets Manager或Parameter Store拉取并解密而environment明文传输。我们用aws ecs register-task-definition的--cli-input-json参数传入JSON其中secrets数组格式为secrets: [ { name: DB_PASSWORD, valueFrom: arn:aws:secretsmanager:us-east-1:123456789012:secret:mydb-pass-AbCdEf } ]法则4日志驱动必须指定awslogsFargate不支持json-file日志驱动。必须配置logConfiguration: { logDriver: awslogs, options: { awslogs-group: /ecs/my-app, awslogs-region: us-east-1, awslogs-stream-prefix: ecs } }否则日志将丢失。法则5启动命令必须用entryPointcommand组合避免在Dockerfile中写CMD [npm, start]而应在Task Definition中用entryPoint: [/bin/sh, -c], command: [npm start]这样可以确保/bin/sh作为PID 1进程能正确转发信号如SIGTERM让应用优雅关闭。3.5 步骤五服务部署Service配置——从“能跑”到“稳跑”的跃迁Fargate服务Service配置决定了任务如何被调度、如何恢复、如何扩容。我们重点关注三个参数minimumHealthyPercent与maximumPercent这两个参数控制滚动更新时的健康任务比例。默认minimumHealthyPercent100意味着更新时必须保证100%任务在线这在单任务服务中会导致更新卡死。我们根据服务SLA调整金融级服务99.99%minimumHealthyPercent50,maximumPercent200允许短暂50%容量但最多双倍扩容内部工具服务99.5%minimumHealthyPercent0,maximumPercent100允许零健康任务快速切流healthCheckGracePeriodSeconds这是任务启动后健康检查开始前的宽限期。设得太短如5秒应用还没初始化完就被判失败设得太长如300秒故障任务无法及时剔除。我们按应用类型设定Node.js/Python Web60秒足够Express/Koa启动DB连接池预热Java Spring Boot120秒JVM预热Hibernate初始化Go CLI工具10秒启动即完成deploymentConfiguration中的alarmsFargate支持关联CloudWatch Alarms实现自动回滚。我们为每个服务配置两个核心告警ALB HTTPCode_ELB_5XX_Count 10次/分钟负载均衡层异常ECS ContainerInstance CPUUtilization 90%持续5分钟资源瓶颈当任一告警触发ECS自动回滚到上一版本。这让我们敢在工作日中午发布而不必全员待命。3.6 步骤六可观测性埋点——没有日志和指标Fargate就是黑盒Fargate的“无SSH”特性让可观测性从可选项变成生死线。我们建立三层埋点体系第一层基础设施指标CloudWatchCPUUtilization、MemoryUtilization监控资源水位RunningTaskCount确认服务实例数CPUReservation、MemoryReservation对比申请值与实际使用值识别过度配置第二层应用指标Embedded Metrics在代码中嵌入结构化指标import aws_embedded_metrics from aws_embedded_metrics.logger.metrics_logger_factory import create_metrics_logger logger create_metrics_logger() logger.put_dimensions({ServiceName: order-processor}) logger.put_metric(ProcessedOrders, 1, Count) logger.put_metric(ProcessingLatency, 124.5, Milliseconds) logger.flush()指标自动发送到CloudWatch Embedded Metrics支持高基数维度查询。第三层分布式追踪X-Ray所有HTTP客户端启用X-Rayconst AWSXRay require(aws-xray-sdk); const axios AWSXRay.captureHTTPsGlobal(require(axios)); // 自动注入X-Amzn-Trace-Id头 axios.get(https://api.example.com/orders);X-Ray服务图清晰显示order-processor→payment-service→redis的延迟分布定位到某次慢查询源于RedisKEYS *命令。我们强制要求任何Fargate服务上线前必须在X-Ray中看到完整的服务图谱且95%请求的Duration柱状图峰值在100ms内。否则视为可观测性不达标禁止发布。3.7 步骤七灾备与回滚——当Fargate也出问题时你靠什么活下来Fargate本身有99.99% SLA但你的应用未必。我们设计了三级灾备一级跨区域热备Active-Active对核心服务如用户认证我们在us-east-1和us-west-2各部署一套Fargate服务通过Route 53健康检查地理位置路由。当us-east-1的/health返回503流量自动切到us-west-2。DNS TTL设为60秒故障转移时间90秒。二级版本灰度Canary使用ECS的CODE_DEPLOY部署控制器实现10%流量灰度Step 1将10%流量导向新版本任务Step 2监控新版本的HTTPCode_Target_5XX_Count和TargetResponseTime若5分钟内错误率1%自动暂停Step 3若平稳逐步提升至100%三级本地应急通道Last Resort当所有云服务不可用时我们保留一个最小化EC2实例t3.micro预装Docker和备份镜像。通过aws s3 cp s3://backup-bucket/app-latest.tar.gz . docker load -i app-latest.tar.gz可在5分钟内恢复基础服务。这个实例不计入日常成本但它是心理安全阀。4. 常见问题与避坑指南那些文档里不会写的血泪教训4.1 问题速查表高频故障与根因定位现象可能根因排查命令/路径解决方案任务启动后立即停止STOPPEDessential容器退出健康检查路径不存在端口未监听aws ecs describe-tasks --tasks $TASK_ID --query tasks[0].containers[0].reason检查Dockerfile的EXPOSE与Task Definition的portMappings是否一致用curl -v http://localhost:8080/health在本地镜像中验证任务卡在PROVISIONING状态超5分钟安全组阻止了Fargate底层通信子网无可用IPIAM角色权限不足aws ec2 describe-subnets --subnet-ids $SUBNET_ID --query Subnets[0].AvailableIpAddressCount检查CloudTrail中CreateNetworkInterface失败事件为子网预留至少16个可用IP为Task Role添加ec2:CreateNetworkInterface权限健康检查失败但curl本地成功应用绑定127.0.0.1而非0.0.0.0防火墙拦截169.254.170.2Fargate健康检查源IPnetstat -tuln | grep :8080检查iptables规则在应用中绑定0.0.0.0:8080安全组放行169.254.170.2/32到任务端口日志在CloudWatch中延迟2分钟awslogs驱动配置错误任务内存不足导致日志缓冲区溢出aws logs filter-log-events --log-group-name /ecs/my-app --start-time $(date -d 5 minutes ago %s%3N)检查MemoryUtilization指标增加任务内存在logConfiguration.options中添加awslogs-datetime-format: %Y-%m-%d %H:%M:%S提升解析效率跨服务调用超时如调用RDS安全组未放行RDS端口RDS实例类型过小DNS解析慢aws rds describe-db-instances --db-instance-identifier my-rds --query DBInstances[0].DBInstanceStatus用dig short my-rds.xxxxx.us-east-1.rds.amazonaws.com测DNSRDS安全组入站规则添加0.0.0.0/0:3306或精确到Fargate子网升级RDS到db.t3.medium4.2 独家避坑技巧来自12个项目的实战结晶技巧1用ecs-cli本地模拟Fargate环境在本地开发机上用ecs-cli up --capability-iam --force启动一个临时ECS集群再用ecs-cli compose up部署服务。虽然不是真Fargate但能提前暴露portMappings冲突、secrets权限错误等问题。我们把它集成到Git Hook中git push前自动运行。技巧2健康检查路径必须返回200 OK且响应体为空Fargate健康检查只认HTTP状态码不解析响应体。但我们发现某些框架如Spring Boot Actuator的/actuator/health返回JSON{ status: UP }而Fargate偶尔会因响应体过大1KB导致检查超时。解决方案在Nginx反向代理层加location /health { return 200 ; }确保零字节响应。技巧3Fargate的/proc/sys是只读的别试图调优内核参数曾有个团队想优化TCP连接复用在entryPoint中写sysctl -w net.ipv4.tcp_tw_reuse1结果任务启动失败。Fargate容器的/proc/sys挂载为ro任何写操作都会报Operation not permitted。正确做法用--sysctl参数在Task Definition中声明如sysctls: [{namespace: net.ipv4.tcp_tw_reuse, value: 1}]。技巧4跨账户Secrets Manager访问ARN必须带version-stage当Fargate任务从另一账户读取Secret时valueFrom必须指定版本阶段valueFrom: arn:aws:secretsmanager:us-east-1:987654321098:secret:cross-account-db-pass-AbCdEf:AWSCURRENT漏掉:AWSCURRENT会导致AccessDeniedException。我们用CI脚本自动校验ARN格式。技巧5Fargate的ulimit默认值极低需显式提升Fargate默认nofile1024对于高并发服务远远不够。在Task Definition中必须设置ulimits: [ { name: nofile, softLimit: 65536, hardLimit: 65536 } ]否则应用在连接池满时会抛Too many open files异常。4.3 成本陷阱预警那些让你账单暴增的隐形杀手Fargate按vCPU/内存秒级计费但有五个成本黑洞黑洞1闲置任务未清理开发环境的Fargate服务常被遗忘。我们用Lambda函数每天扫描ecs list-services对连续7天RunningTaskCount0的服务自动删除并邮件通知负责人。黑洞2过度配置的内存档位Fargate按申请内存收费而非实际使用。某服务申请4GB内存但实际只用1.2GB白白多付2.8GB费用。我们用aws cloudwatch get-metric-statistics每小时采集MemoryUtilization生成报告对利用率40%的服务发起降配工单。黑洞3未启用Spot容量提供者Fargate支持Spot容量提供者Capacity Provider可降低约70%成本。但需注意Spot任务可能被中断。我们对非核心服务如报表生成启用Spot中断时自动重试对核心服务如支付仍用On-Demand。黑洞4日志存储无限期保留CloudWatch Logs默认永久保留日志费用常超计算费用。我们为所有/ecs/*日志组设置retentionInDays14并通过Lambda将重要日志归档到S3 Glacier。黑洞5跨区域数据传输Fargate任务访问另一区域的S3桶会产生高额数据传输费。我们强制所有S3访问走us-east-1区域的S3 Transfer Acceleration端点或在任务所在区域部署S3 Replication。5. 迁移后的世界当服务器消失你真正获得了什么最后一次部署完成后我站在监控大屏前看着那个曾经需要3人轮班盯守的EC2集群监控面板逐渐变灰而Fargate服务的RunningTaskCount稳定在4CPUUtilization曲线平滑如湖面HTTPCode_ELB_5XX_Count保持为0。那一刻没有欢呼只有一种沉静的确认我们不是抛弃了服务器而是把服务器时代积累的、那些本该属于应用层的职责终于交还给了应用本身。Fargate没有消灭运维它只是把运维的战场从“如何让机器不死”转移到“如何让服务可信”。你不再需要半夜爬起来处理磁盘满了但必须确保每个HTTP端点的健康检查能在200ms内返回你不再纠结于内核参数调优但必须为每个下游依赖设计熔断和降级你不再为SSH密钥泄露提心吊胆但必须让每行日志都自带trace_id以便全链路追踪。我见过太多团队把Fargate当成“免运维银弹”结果在第一个月就因健康检查配置错误导致服务雪崩。也见过更聪明的团队借这次迁移把尘封多年的《微服务设计规范》翻出来重读把废弃的SOAP接口用GraphQL重写把散落在各处的配置文件统一到SSM Parameter Store。对他们而言“Dump Your Servers”不是终点而是用基础设施的确定性去换取服务交付的确定性的起点。如果你今天正坐在服务器告警的包围中不妨打开AWS控制台新建一个Fargate集群。不要想着一步到位先挑一个最痛的、最独立的服务——比如那个每次发版都要手动改Nginx配置的静态资源服务。用本文的七步法走一遍从镜像瘦身开始到健康检查收尾。当你第一次看到任务在30秒内启动、健康、接收流量而你全程没敲过一条ssh命令时你会明白服务器不是被“Dump”掉的它们是被你亲手一件件放下了。