4. AWS环境准备
做 Cromwell 跨云部署,说实话,最让人头疼的不是 Cromwell 本身,而是底层网络和权限。网络不通、权限不足,这两类问题我踩过的坑比代码报错还多。本章我会带你一步步搭好 AWS 的网络基座和权限模型——说白了,就是给 Cromwell 造一条结实又安全的跑道。
核心知识点:VPC 网络隔离、子网拆分、安全组规则放行、IAM 角色与策略的最小权限原则。
4.1 VPC 与子网:给 Cromwell 划出一块安全区域
AWS 的 VPC 就是一个虚拟数据中心。你可以在里面自由划分网段,内部通信完全隔离。我个人习惯把 Cromwell 的 VPC 固定在一个可用区里,这样能减少跨 AZ 的数据传输费用。
创建 VPC 时,CIDR 块我建议用 10.0.0.0/16,预留够空间。子网至少需要两个:公有子网(Public Subnet)放堡垒机或 NAT 网关,私有子网(Private Subnet)放 Cromwell 的计算节点和数据盘。
# 创建 VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=cromwell-vpc}]'
# 创建公有子网
aws ec2 create-subnet --vpc-id vpc-xxxxx --cidr-block 10.0.1.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=cromwell-public-subnet}]'
# 创建私有子网
aws ec2 create-subnet --vpc-id vpc-xxxxx --cidr-block 10.0.2.0/24 --availability-zone us-east-1a --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=cromwell-private-subnet}]'
4.2 子网选择:公有还是私有?
很多人在子网选择上犹豫。我直接给结论吧:凡是 Cromwell 的计算节点、数据库、缓存,全部丢私有子网。只有一种情况可以放公有子网——你希望 Jenkins 或跳板机直接通过公网 SSH 上去调试。
| 用途 | 推荐子网类型 | 说明 |
|---|---|---|
| Cromwell Server | 私有子网 | 通过 ALB 暴露,不直接开公网 IP |
| 计算节点(Batch / EC2) | 私有子网 | 通过 NAT 出公网 |
| 数据库(RDS / MySQL) | 私有子网 | 严格不暴露公网 |
| 堡垒机 / 跳板机 | 公有子网 | 配安全组限制来源 IP |
4.3 安全组:别图省事,每条规则都要精打细算
安全组是 AWS 的虚拟防火墙。我常跟团队说一句话:安全组规则写得多不重要,写得对才重要。Cromwell 部署场景里,安全组至少要分三个:
- Cromwell Server 安全组:放行 8080 端口给跳板机或 ALB。
- 数据库安全组:只允许 Cromwell Server 安全组访问 3306 端口。
- 计算节点安全组:允许 Server 安全组发起任务,并且能访问数据库。
# 创建 Cromwell Server 安全组
aws ec2 create-security-group --group-name cromwell-server-sg --description "Security group for Cromwell server" --vpc-id vpc-xxxxx
# 添加入站规则:只允许跳板机访问 8080
aws ec2 authorize-security-group-ingress --group-id sg-xxxxx --protocol tcp --port 8080 --cidr 203.0.113.0/24
# 创建数据库安全组,入站只允许 Cromwell Server 安全组
aws ec2 create-security-group --group-name cromwell-db-sg --description "Security group for Cromwll database" --vpc-id vpc-xxxxx
aws ec2 authorize-security-group-ingress --group-id sg-yyyyy --protocol tcp --port 3306 --source-group sg-xxxxx
4.4 IAM 角色与策略:最小权限的动态钥匙
IAM 是 Cromwell 和 AWS 服务通信的凭证。你不应该用 Access Key 硬编码在代码里,而是用 IAM Role 挂载到 EC2 或 ECS 上。这样既安全又方便轮换密钥。
Cromwell 后端需要操作 Batch、EC2、S3、CloudWatch。我需要准备一个策略,涵盖这些操作,但尽量限定资源范围。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"batch:SubmitJob",
"batch:DescribeJobs",
"batch:TerminateJob",
"batch:ListJobs",
"batch:DescribeJobDefinitions",
"batch:RegisterJobDefinition",
"batch:DeregisterJobDefinition",
"ec2:DescribeInstances",
"ec2:DescribeInstanceTypes",
"ec2:RunInstances",
"ec2:TerminateInstances",
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
4.5 整体架构概览
弄完上面几步,整个网络和权限骨架就搭好了。下面这张 SVG 图能帮你一眼看清各组件的关系。
记住这个逻辑:VPC 划网络分段,子网做隔离,安全组控制细粒度流量,IAM 解决动态授权。这四个要素配齐,Cromwell 的基础网络就算真正准备好了。接下来你才能放心部署 Server 和后端计算环境——如果连这一步都省了,后面全是坑。