企业官网建设流程全解析

1. 这不是“配个YAML就完事”的玩具项目，而是一条能跑通真实业务的自动化流水线

你有没有过这样的经历：改完一行代码，手动打包、本地测试、上传服务器、重启服务、再点开网页确认——整个过程耗时8分钟，其中6分钟在等自己手抖输错命令？或者更糟：上线后用户突然反馈“页面白屏”，你翻日志发现是某次合并漏掉了npm install，而那个 commit 的作者此刻正在休假。这不是个别现象，而是大量中小团队在交付节奏加快后遭遇的典型“人工流水线失速”。我带过的7个不同行业的技术团队（从电商SaaS到工业IoT平台），92%的线上故障回溯都指向同一个根因：部署环节存在不可控的人为干预。而今天这个标题里的组合——GitHub Actions + Docker + Cloud——不是三个工具的简单拼接，它是一套经过生产环境千锤百炼的“确定性交付协议”：GitHub Actions 是调度中枢，Docker 是标准化容器，Cloud 是弹性执行沙盒。三者咬合后，任何开发者提交代码的那一刻，系统就自动启动一条预设路径：代码扫描 → 构建镜像 → 单元测试 → 容器健康检查 → 灰度发布 → 全量切换 → 监控告警。全程无需人工介入，失败自动回滚，成功自动归档。它解决的不是“能不能部署”，而是“每次部署的结果是否完全一致”。适合谁？如果你是独立开发者想摆脱凌晨三点手动上线的噩梦，是初创公司CTO需要向投资人证明交付流程可审计，或是传统企业运维工程师正被“这个版本在测试环境好好的，怎么上生产就崩了”这类问题反复折磨——这篇文章就是你接下来两周要反复翻看的操作手册。核心关键词已经嵌入：E2E CI/CD Pipeline、GitHub Actions、Docker、Cloud，它们不是孤立名词，而是构成闭环的齿轮。

2. 整体设计思路：为什么必须是这三块拼图，缺一不可？

2.1 拒绝“伪CI/CD”：从需求倒推架构选型

很多团队踩的第一个坑，是把“有自动化脚本”误认为“有CI/CD”。我见过最典型的反例：某教育平台用 Jenkins 写了段 Shell 脚本，每次构建前先ssh到测试服务器git pull，再npm run build，最后pm2 restart。表面看是自动化，实则埋下三颗雷：第一，构建环境依赖服务器本地 Node 版本，开发机装的是 v18，测试机是 v16，构建产物不兼容；第二，git pull无法保证代码状态纯净，.env文件可能被误提交；第三，pm2 restart是粗暴杀进程，用户请求在切换瞬间丢失。真正的 E2E 流水线必须满足四个刚性条件：环境隔离、状态可追溯、过程可中断、结果可验证。我们来逐条拆解为何只有 GitHub Actions + Docker + Cloud 的组合能同时满足：

• 环境隔离：GitHub Actions 提供托管运行器（ubuntu-latest/macos-latest），每次构建都在全新虚拟机中启动，彻底杜绝本地环境污染。Docker 则将应用及其所有依赖（Node、Python、JDK、甚至字体库）打包进镜像，确保“构建一次，处处运行”。Cloud（这里指 AWS EC2/ECS、GCP Cloud Run 或 Azure Container Instances）作为最终执行层，提供独立网络空间与资源配额，避免多服务争抢 CPU 导致的性能抖动。

• 状态可追溯：GitHub Actions 的 workflow run ID 与 commit hash 强绑定，Docker 镜像 tag 默认采用sha256:abc123...哈希值，Cloud 平台的部署记录自动关联镜像 ID。三者形成“代码→构建→容器→实例”的完整溯源链。当线上出问题时，你只需输入一个 commit ID，就能精准定位到对应镜像、对应云实例、对应日志流，而不是在几十个 Jenkins job 中大海捞针。

• 过程可中断：GitHub Actions 支持if: always()和if: failure()条件分支，Docker 支持--rm参数实现容器即启即毁，Cloud 平台提供 API 驱动的实例销毁能力。这意味着你可以设计“安全阀”逻辑：例如单元测试失败时，自动触发 Slack 通知并终止后续步骤；镜像扫描发现高危漏洞时，强制阻断发布流程；甚至可以设置“灰度流量超阈值自动回滚”的熔断策略。

• 结果可验证：Docker 的HEALTHCHECK指令让容器自带心跳探针，Cloud 平台的负载均衡器可配置 HTTP 健康检查路径（如/healthz），GitHub Actions 的curl -f http://service:3000/healthz命令则能在部署后立即验证服务可达性。三重验证叠加，比单纯“容器启动成功”可靠十倍。

提示：不要试图用单一工具替代这套组合。比如只用 GitHub Actions 不用 Docker，环境一致性无法保障；只用 Docker 不用 Cloud，缺乏弹性伸缩与灾备能力；只用 Cloud 不用 GitHub Actions，则失去代码驱动的自动化触发机制。它们是铁三角，不是可选项。

2.2 为什么放弃 Jenkins/Travis CI？成本与心智负担的硬账

有人会问：“我们已有 Jenkins，为什么还要迁？” 我用两个真实数据回答：第一，某金融客户迁移前后对比，Jenkins Master 节点平均 CPU 使用率从 85% 降至 12%，月度云服务器费用减少 $1,240；第二，运维团队每周花在 Jenkins 插件升级、节点维护、权限配置上的工时，从 18 小时压缩至 2.5 小时。这不是玄学，而是架构差异带来的本质红利。

Jenkins 的核心瓶颈在于“中心化调度”。所有构建任务排队等待 Master 分配 Slave 节点，Slave 节点需长期驻留、定期更新、手动扩容。而 GitHub Actions 是“事件驱动+按需分配”：当你 push 代码，GitHub 后台瞬间拉起一台干净 Ubuntu 虚拟机，执行完自动销毁。没有 Master 单点故障，没有 Slave 资源闲置，没有插件版本冲突。更关键的是心智模型简化——Jenkins 需要你理解 Workspace、Pipeline Script、Shared Library、Credentials Binding 等抽象概念；GitHub Actions 只需你写 YAML，语法直白如“当某事件发生，执行这些步骤”。

至于 Travis CI，其免费额度已大幅缩减，且对私有仓库支持薄弱。而 GitHub Actions 天然集成 GitHub，私有仓库免费额度充足（2,000 分钟/月），且支持自托管 runner（可复用现有物理机）。我们团队曾用一台旧 Mac Mini 作为自托管 runner，专门跑 iOS 构建任务，既规避了 Apple 证书管理难题，又节省了 $29/月的 GitHub-hosted macOS runner 费用。

2.3 Docker 镜像分层设计：不是“Dockerfile 写完就跑”，而是构建可复用的资产

很多人以为 Docker 就是写个FROM node:18然后COPY . .，这是对镜像分层机制的严重误读。Docker 镜像由多层只读文件系统叠加而成，每一层对应 Dockerfile 中的一条指令。高效的设计必须遵循“变化越少的层越靠下，变化越频繁的层越靠上”原则。以一个 React 前端项目为例，错误写法是：

FROM node:18 WORKDIR /app COPY package.json . RUN npm install # ❌ 每次代码变更都会重新执行此步，浪费时间 COPY . . CMD ["npm", "start"]

正确写法应拆分为三层：

# 第一层：基础环境（极低频变更） FROM node:18-alpine AS builder WORKDIR /app # 第二层：依赖安装（仅当 package.json 变更时重建） COPY package*.json ./ RUN npm ci --only=production # ✅ 使用 ci 替代 install，确保依赖树完全一致 # 第三层：应用代码（高频变更） COPY . . RUN npm run build # 最终镜像（精简运行时） FROM nginx:alpine COPY --from=builder /app/build /usr/share/nginx/html EXPOSE 80

这样设计后，当仅修改src/App.js时，Docker 只需重建第三层，前两层直接复用缓存，构建时间从 3分28秒降至 18秒。而npm ci比npm install更可靠，它会严格校验package-lock.json，杜绝“本地能跑，CI 上报错”的经典悲剧。

注意：永远不要在生产镜像中保留node_modules的开发依赖（devDependencies）。我们曾因webpack被误打入生产镜像，导致镜像体积暴涨 420MB，推送耗时从 47秒飙升至 6分12秒。解决方案是在多阶段构建中，用--only=production显式过滤。

3. 核心细节解析：从零搭建一条可落地的 E2E 流水线

3.1 GitHub Actions 工作流骨架：不是模板复制，而是按需裁剪

GitHub Actions 的核心是.github/workflows/ci-cd.yml文件。别被网上那些“一键生成”的复杂模板吓住，一个真正可用的 E2E 流水线，只需抓住五个关键节点：触发（Trigger）、环境（Environment）、构建（Build）、测试（Test）、部署（Deploy）。下面是我在线上项目中稳定运行 14 个月的最小可行骨架（已去除所有冗余注释）：

name: E2E CI/CD Pipeline # 1. 触发：定义什么事件启动流水线 on: push: branches: [main] # 主干推送即构建 paths: ['src/**', 'package.json', 'Dockerfile'] # 仅当相关文件变更时触发，避免无关提交浪费资源 pull_request: branches: [main] paths: ['src/**', 'package.json', 'Dockerfile'] # 2. 环境：定义全局变量与密钥 env: NODE_VERSION: 18.17.0 DOCKER_IMAGE_NAME: ghcr.io/your-org/your-app CLOUD_DEPLOY_TARGET: production # 可设为 staging/test # 3. 构建：在干净环境中编译代码 jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # 拉取代码 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} - name: Install dependencies run: npm ci - name: Build app run: npm run build - name: Cache build artifacts uses: actions/cache@v4 with: path: dist/ key: ${{ runner.os }}-build-${{ hashFiles('**/package-lock.json') }} # 4. 测试：并行执行多维度验证 test: needs: build runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: ${{ env.NODE_VERSION }} - name: Restore build cache uses: actions/cache@v4 with: path: dist/ key: ${{ runner.os }}-build-${{ hashFiles('**/package-lock.json') }} - name: Unit tests run: npm test -- --coverage - name: Lint code run: npm run lint - name: Security scan (trivy) uses: aquasecurity/trivy-action@master with: scan-type: 'fs' ignore-unfixed: true format: 'sarif' output: 'trivy-results.sarif' env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - name: Upload SARIF file uses: github/codeql-action/upload-sarif@v2 with: sarif_file: 'trivy-results.sarif' # 5. 部署：仅当测试全通过才执行 deploy: needs: test runs-on: ubuntu-latest if: github.event_name == 'push' && github.head_ref == 'main' # 仅 main 分支推送触发 steps: - uses: actions/checkout@v4 - name: Login to GitHub Container Registry uses: docker/login-action@v3 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Build and push Docker image uses: docker/build-push-action@v5 with: context: . push: true tags: | ${{ env.DOCKER_IMAGE_NAME }}:latest ${{ env.DOCKER_IMAGE_NAME }}:${{ github.sha }} - name: Deploy to Cloud uses: ./.github/actions/deploy-to-cloud # 自定义 action，封装云平台部署逻辑 with: image-tag: ${{ github.sha }} target-env: ${{ env.CLOUD_DEPLOY_TARGET }} env: CLOUD_API_KEY: ${{ secrets.CLOUD_API_KEY }} CLOUD_API_SECRET: ${{ secrets.CLOUD_API_SECRET }}

这个骨架的关键设计点在于：

• 精准触发：paths过滤避免非代码文件（如 README.md 修改）触发构建，每月节省约 300 分钟构建时间；
• 环境隔离：testjob 显式needs: build，确保测试基于最新构建产物，而非本地缓存；
• 安全左移：trivy-action在构建后立即扫描dist/目录，发现漏洞即阻断流程，而非等上线后被扫描器通报；
• 部署守门：if条件双重校验（事件类型 + 分支名），杜绝 PR 合并前误部署。

实操心得：永远不要在deployjob 中写run: curl -X POST https://api.cloud.com/deploy这类裸命令。必须封装成自定义 Action（见.github/actions/deploy-to-cloud），原因有三：第一，密钥管理更安全（Secrets 可在 action 内部加密传递）；第二，错误处理更优雅（action 可内置重试、超时、回滚逻辑）；第三，团队协作更清晰（新人只需调用uses: ./...，无需理解云平台 API 细节）。

3.2 Docker 镜像优化实战：从 1.2GB 到 87MB 的瘦身之路

镜像体积直接影响部署速度与安全性。我们曾接手一个遗留 Node.js 服务，原始镜像 1.2GB，推送至私有 Registry 耗时 8分32秒，且包含 217 个已知 CVE 漏洞。通过四步重构，将其压缩至 87MB，推送时间降至 11秒，漏洞清零。以下是具体操作：

第一步：基础镜像降级
原FROM node:18使用 Debian 基础镜像（约 1GB），改为FROM node:18-alpine（约 120MB）。Alpine Linux 采用 musl libc 替代 glibc，体积锐减。但需注意：某些依赖（如 Puppeteer）需额外安装libglib-2.0-0等包，可在 Dockerfile 中补全：

FROM node:18-alpine RUN apk add --no-cache \ ttf-dejavu \ libglib-2.0-0 \ nss-tools

第二步：多阶段构建剥离构建依赖
原镜像将npm install与npm run build全部打包进生产镜像，导致node_modules中混入webpack、jest等开发工具。重构后采用标准多阶段：

# 构建阶段 FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build # 生产阶段 FROM nginx:alpine COPY --from=builder /app/dist /usr/share/nginx/html # 移除默认 nginx 配置，注入自定义 COPY nginx.conf /etc/nginx/nginx.conf EXPOSE 80

第三步：Dockerfile 指令合并与缓存优化
将多个RUN指令合并为单条，减少镜像层数（每层都是只读文件系统，层数越多，存储与传输开销越大）：

# ❌ 错误：产生 3 层 RUN apt-get update RUN apt-get install -y curl RUN curl -o /tmp/app.tar.gz https://example.com/app.tar.gz # ✅ 正确：合并为 1 层，且利用缓存 RUN apt-get update && \ apt-get install -y curl && \ curl -o /tmp/app.tar.gz https://example.com/app.tar.gz && \ rm -rf /var/lib/apt/lists/*

第四步：启用 BuildKit 加速构建
在 GitHub Actions 中启用 BuildKit（Docker 18.09+ 默认支持），可并行化构建步骤、智能缓存、跳过未使用阶段：

- name: Build and push Docker image uses: docker/build-push-action@v5 with: context: . push: true tags: ${{ env.DOCKER_IMAGE_NAME }}:${{ github.sha }} cache-from: type=registry,ref=${{ env.DOCKER_IMAGE_NAME }}:buildcache cache-to: type=registry,ref=${{ env.DOCKER_IMAGE_NAME }}:buildcache,mode=max env: DOCKER_BUILDKIT: 1 # 关键！启用 BuildKit

最终效果：镜像体积下降 92.7%，CVE 漏洞从 217 个归零，构建时间从 4分18秒降至 52秒。这不是数字游戏，而是直接影响业务连续性的关键指标——当线上服务需要紧急回滚时，87MB 镜像的拉取与启动速度，比 1.2GB 镜像快 17 倍。

3.3 云平台部署策略：不是“扔上去就行”，而是可控的渐进式交付

Cloud 并非黑箱，而是需要精细配置的执行引擎。我们以 AWS ECS（Elastic Container Service）为例，说明如何设计安全、可观测、可回滚的部署策略。核心原则是：永远不要直接更新生产服务，而是通过蓝绿部署（Blue/Green）实现零停机切换。

蓝绿部署工作流：

1. 创建两个完全相同的 ECS 服务：my-app-blue（当前生产）与my-app-green（待上线）；
2. 新镜像构建完成后，部署到my-app-green服务；
3. 自动执行健康检查（HTTP GET/healthz，超时 30 秒，失败 3 次即终止）；
4. 健康检查通过后，将 ALB（Application Load Balancer）监听器规则从blue切换至green；
5. 切换完成后，blue服务保持运行 15 分钟，供快速回滚；
6. 15 分钟后，自动销毁blue服务（或降为 0 实例，保留配置）。

在 GitHub Actions 的deployjob 中，我们通过 AWS CLI 封装此流程：

- name: Deploy to AWS ECS (Blue/Green) run: | # 1. 更新 green 服务任务定义 aws ecs register-task-definition \ --family my-app-green \ --network-mode awsvpc \ --requires-compatibilities "FARGATE" \ --cpu "256" \ --memory "512" \ --execution-role-arn "arn:aws:iam::123456789012:role/ecsTaskExecutionRole" \ --task-role-arn "arn:aws:iam::123456789012:role/ecsTaskRole" \ --container-definitions "[{ \"name\": \"my-app\", \"image\": \"${{ env.DOCKER_IMAGE_NAME }}:${{ github.sha }}\", \"portMappings\":[{\"containerPort\":80,\"hostPort\":80}], \"healthCheck\":{\"command\":[\"CMD-SHELL\",\"curl -f http://localhost:80/healthz || exit 1\"],\"interval\":30,\"timeout\":5,\"retries\":3} }]" \ --region us-east-1 # 2. 更新 green 服务（启动新任务） aws ecs update-service \ --cluster my-app-cluster \ --service my-app-green \ --task-definition my-app-green \ --desired-count 2 \ --region us-east-1 # 3. 等待 green 服务稳定（轮询 ECS 服务状态） aws ecs wait services-stable \ --cluster my-app-cluster \ --services my-app-green \ --region us-east-1 # 4. 切换 ALB 目标组（核心！） aws elbv2 modify-listener \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-app-alb/1234567890123456/abcdef0123456789 \ --default-actions "Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-app-green/abcdef0123456789" \ --region us-east-1 # 5. 清理 blue 服务（15分钟后） (sleep 900 && \ aws ecs update-service \ --cluster my-app-cluster \ --service my-app-blue \ --desired-count 0 \ --region us-east-1) &

这个脚本的关键价值在于：将部署动作转化为幂等操作。即使脚本执行到一半中断，再次运行仍能安全续跑——因为register-task-definition总是创建新版本，update-service总是更新到指定版本，modify-listener总是设置为目标组。没有“中间态”，只有“蓝”或“绿”两种确定状态。

注意事项：ALB 的目标组健康检查必须与容器HEALTHCHECK指令协同。我们曾因 ALB 检查路径设为/（返回 200），而容器HEALTHCHECK设为/healthz（返回 503），导致 ALB 认为服务健康，实际容器已崩溃。解决方案是统一健康检查端点，并在 Nginx 配置中暴露/healthz：

location /healthz { return 200 'OK'; add_header Content-Type text/plain; }

4. 实操全流程：从代码提交到服务上线的 7 分钟实录

4.1 场景设定：一个真实的电商后台管理界面迭代

为具象化整个流程，我们模拟一个典型场景：前端团队需上线一个“订单导出 CSV”功能。该功能涉及三个文件变更：

• src/components/OrderList.jsx：新增导出按钮与点击事件；
• src/api/orders.js：新增exportOrders()API 调用；
• Dockerfile：因新增csv-generator依赖，需更新npm install步骤。

整个过程从开发者执行git push开始，到新功能在生产环境可访问结束，全程 7 分钟 23 秒。以下是分秒级实录与关键节点分析：

T+00:00 —— 开发者推送代码

git add src/components/OrderList.jsx src/api/orders.js Dockerfile git commit -m "feat: add order export CSV button" git push origin main

GitHub 接收到 push 事件，立即触发.github/workflows/ci-cd.yml流水线。此时，GitHub 后台开始拉取ubuntu-latestrunner，耗时 8 秒。

T+00:08 —— Build Job 启动
Runner 启动后，执行actions/checkout@v4拉取代码（2.1 秒），setup-node@v4安装 Node.js（3.4 秒），npm ci安装依赖（28 秒）。关键点：由于Dockerfile变更，npm ci后的npm run build步骤触发，Webpack 编译耗时 41 秒。构建产物dist/被缓存，为后续测试 job 复用。

T+01:22 —— Test Job 启动（并行）
Build Job 完成后，Test Job 立即启动。它首先复用dist/缓存（0.3 秒），然后执行npm test（单元测试，19 秒）、npm run lint（代码规范检查，4.2 秒）、trivy-action（安全扫描，12 秒）。扫描结果显示：csv-generator依赖存在一个中危 CVE（CVE-2023-1234），但ignore-unfixed: true配置允许流程继续（符合团队安全策略）。

T+02:18 —— Deploy Job 启动
Test 全通过，Deploy Job 启动。首先docker/login-action@v3登录 GHCR（1.8 秒），然后docker/build-push-action@v5执行构建。由于Dockerfile变更，Base Image 层缓存失效，但npm ci层与COPY . .层仍可复用，构建总耗时 52 秒。镜像推送至 GHCR 耗时 11 秒（87MB 镜像优势显现）。

T+03:21 —— 云平台部署启动
Deploy Job 执行自定义deploy-to-cloudaction，调用 AWS CLI。register-task-definition创建新任务定义（0.9 秒），update-service启动my-app-green服务（2.3 秒）。ECS 启动 2 个 Fargate 任务，每个任务拉取镜像（11 秒）+ 解压（3.2 秒）+ 运行容器（1.5 秒）+HEALTHCHECK通过（30 秒），总计 48 秒。

T+04:29 —— ALB 切换流量
aws elbv2 modify-listener执行，将 ALB 流量从blue目标组切至green目标组（0.4 秒）。切换瞬间，ALB 开始将新请求路由至green服务。此时，blue服务仍在处理存量连接（TCP Keep-Alive），无请求丢失。

T+04:29 —— 自动清理启动
后台sleep 900进程启动，15 分钟后执行update-service --desired-count 0，将blue服务实例数降为 0，释放资源。

T+07:23 —— 开发者验证完成
开发者打开浏览器，访问https://admin.your-ecommerce.com/orders，点击“导出 CSV”按钮，成功下载orders_20231015.csv文件。打开终端执行curl -I https://admin.your-ecommerce.com/healthz，返回HTTP/2 200。整个流程结束。

实操心得：监控不是“出了问题再看”，而是“每一步都埋点”。我们在每个 job 的末尾添加echo "::set-output name=duration::$(($(date +%s)-$START_TIME))"，将各阶段耗时写入输出变量。流水线结束后，自动生成耗时分布图（如 Build 占 22%，Test 占 18%，Deploy 占 60%），持续优化瓶颈环节。过去三个月，Deploy 阶段耗时从 5分12秒降至 2分23秒，核心就是将modify-listener操作从串行改为并行（同时更新多个监听器）。

4.2 关键参数计算：为什么是 2 个 Fargate 实例？为什么内存设为 512MB？

云资源配置不是拍脑袋决定，而是基于真实负载的数学推演。我们以该电商后台为例，说明参数计算逻辑：

QPS 与实例数关系：
后台管理界面日均 PV 12,000，峰值集中在上午 9-11 点（占全天 40%），即峰值小时 PV = 12,000 × 40% ÷ 2 = 2,400。按 3600 秒计算，峰值 QPS = 2,400 ÷ 3600 ≈ 0.67。单个 Node.js 实例在 512MB 内存下，经压测可稳定支撑 12 QPS（使用 Artillery 工具，--duration 300 --rate 12持续 5 分钟，CPU < 70%，内存 < 90%）。因此，理论最小实例数 = 0.67 ÷ 12 ≈ 0.056，向上取整为 1。但为防突发流量与单点故障，采用 2 实例（双活），具备 100% 容灾能力。

内存与 CPU 配比：
Fargate 提供固定配比：256MB/0.25vCPU、512MB/0.5vCPU、1GB/1vCPU。我们的应用是 I/O 密集型（大量 API 调用、数据库查询），而非 CPU 密集型（无复杂计算）。压测显示：当内存为 512MB 时，CPU 使用率峰值 32%，内存使用率峰值 85%；若降为 256MB，内存使用率峰值达 112%（OOM Kill）；若升为 1GB，CPU 使用率仍低于 15%，资源浪费。故选择 512MB/0.5vCPU 是性价比最优解。

健康检查超时设置：
HEALTHCHECK的--timeout 5与 ALB 的Health check timeout（30 秒）需匹配。我们设定容器内curl -f http://localhost:80/healthz超时为 5 秒，ALB 检查间隔为 30 秒，失败阈值为 3 次。这意味着：若容器连续 3 次（90 秒内）无法响应健康检查，ALB 将其从目标组剔除。该设置平衡了故障发现速度（< 90 秒）与误判率（避免网络抖动导致的误剔除）。

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 “Build Success, But Deploy Failed” —— 镜像构建成功却部署失败的三大元凶

这是新手最常遇到的“薛定谔失败”：GitHub Actions 显示绿色对勾，但云平台日志里满屏CannotPullContainerError。根据我们处理的 47 个同类案例，根源集中于以下三点：

元凶一：Registry 权限未同步
现象：docker push成功，但 ECS 报错ECR AccessDeniedException。
原因：GitHub Actions 的docker/login-action使用GITHUB_TOKEN登录 GHCR，而 ECS 任务执行角色（Task Role）需有权限从 ECR（Amazon Elastic Container Registry）拉取镜像。但很多团队误以为“GHCR 和 ECR 是同一个东西”，实际上它们是独立 Registry。
解决方案：在 ECS 任务定义中，将image字段从ghcr.io/your-org/your-app:sha改为123456789012.dkr.ecr.us-east-1.amazonaws.com/your-app:sha，并在 Task Role 中附加AmazonEC2ContainerRegistryReadOnly策略。若坚持用 GHCR，则需在 Task Role 中添加sts:AssumeRole权限，允许 ECS 服务代理访问 GHCR。

元凶二：镜像平台不匹配
现象：docker build本地成功，CI 中报错exec user process caused: exec format error。
原因：本地开发机是 macOS（ARM64），而 GitHub Actions runner 是ubuntu-latest（AMD64），Dockerfile 中FROM node:18-alpine默认拉取 AMD64 镜像。但若你在Dockerfile中显式写了RUN --platform linux/amd64 ...，而构建时未指定平台，会导致二进制不兼容。
解决方案：在docker/build-push-action@v5中强制指定平台：

with: platforms: linux/amd64,linux/arm64 push: true

并确保基础镜像支持多平台（如node:18-alpine官方已支持）。

元凶三：环境变量注入时机错误
现象：容器启动后，process.env.DB_HOST为空，导致连接数据库失败。
原因：Docker 的ENV指令在构建时注入，而云平台（如 ECS）的secrets或environment配置在运行时注入。若你在Dockerfile中写ENV DB_HOST=xxx，它会被运行时环境变量覆盖；但若你依赖ENV值做构建时逻辑（如RUN echo $DB_HOST > config.js），则运行时变量无效。
解决方案：永远不要在构建阶段读取运行时环境变量。将配置外置为config.js文件或使用--env-file参数。在 ECS 任务定义中，通过secrets字段注入 SSM Parameter Store 值：

"secrets": [ { "name": "DB