Ubuntu 应用在 AWS 上的部署与排错
到了 AWS 以后，排障思路不变：域名 → 入口 → 端口 → 进程 → 日志，只是每一层有了 AWS 专属的服务名和检查命令。
AWS 排障链路
graph TD
A[Route 53 解析] --> B[ALB 入口]
B --> C[Security Group 规则]
C --> D[EC2 Nginx]
D --> E[应用进程]
E --> F[CloudWatch 日志]
常见故障对照表
| 现象 | 最可能原因 | 排查命令 |
|---|---|---|
| 域名无法解析 | Route 53 NS 未更新 / TTL 未到期 | dig myapp.com NS |
| ALB 返回 503 | 目标组健康检查失败 | 控制台 → 目标组 → 查看健康状态 |
| ALB 返回 502 | Nginx 到应用端口不通 | curl -v http://127.0.0.1:3000/health |
| SSH 连不上 | Security Group 未开放 22 端口 | aws ec2 describe-security-groups --group-ids sg-xxxx |
| 服务正常但响应慢 | CPU / 内存撑满 | CloudWatch → EC2 指标 |
部署一次完整流程（示例）
# 1. 在 EC2 上拉取最新代码
cd /opt/myapp
git pull origin main
# 2. 安装依赖并构建
npm ci && npm run build
# 3. 重启应用服务
sudo systemctl restart myapp
# 4. 确认应用进程正常
systemctl status myapp
curl -f http://127.0.0.1:3000/health
# 5. 查看 CloudWatch 日志（需安装 CloudWatch Agent）
aws logs tail /myapp/app --follow
排查 ALB 健康检查失败
ALB 健康检查失败是 AWS 环境最常见问题，排查顺序：
# Step 1：确认应用在 EC2 内部是否正常响应
curl -v http://127.0.0.1:3000/health
# 期望：HTTP 200
# Step 2：确认 Security Group 允许 ALB 访问应用端口
# ALB 与 EC2 在同一 VPC，Security Group 入站应允许来自 ALB SG 的流量
# Step 3：确认 Nginx 转发配置正确
nginx -t
grep proxy_pass /etc/nginx/sites-enabled/myapp
常见误区
- Security Group 修改后以为立即生效于已有连接：新规则对现有 TCP 连接不会立即断开，但新建连接会按新规则过滤
- 以为 EC2 Public IP 不变：默认 Public IP 在实例停止后会释放。生产环境应使用 Elastic IP 绑定固定地址
- ALB 健康检查路径未设置：默认检查
/，如果应用在/返回非 2xx 就会被标记为不健康，应配置专门的/health路径
本节执行清单
- [ ] 走一遍完整部署流程，记录每步操作和期望输出
- [ ] 确认 ALB 目标组健康状态为 healthy
- [ ] 用
aws logs tail确认 CloudWatch 日志在更新 - [ ] 模拟一次 502 故障（临时停止应用），用排障表逐层定位
下一章：GCP 版本实战——用同一逻辑映射到 GCP。