配置云提供者：AWS、Azure、GCP配置入门

说到混合云迁移，就得先打通云提供者的入口。说白了，Cromwell 只是个调度引擎，真正干活儿的计算资源还要靠各家云平台。

我个人习惯先把三家云厂商的认证方式理清楚——虽然概念类似，但细节总是不同。我踩过的坑大多都在这里：配错了认证、选错了 region、忘了开某个 API 权限……都是血泪史。

这一节我们直奔主题：AWS、Azure、GCP 的 Cromwell 后端配置。每个平台都会给出完整的 backend 配置示例、认证方式、必要的 IAM 准备，外加我的避坑经验。

AWS 后端配置

AWS 是我最早接触的云平台。你需要在 Cromwell 配置里指定 aws 后端，并绑定 S3 作为存储。

准备工作：

• 一个 IAM 用户或角色，拥有 s3:*（至少对目标桶的读写）、batch:*、ecs:*、logs:* 权限。
• 创建一个 S3 桶（比如 my-cromwell-bucket）。
• 创建一个 AWS Batch 计算环境 + 作业队列。

Cromwell 配置（backendProviders 部分）：

backend {
  default = "AWS"
  providers {
    AWS {
      actor-factory = "cromwell.backend.impl.sfs.config.ConfigBackendLifecycleActorFactory"
      config {
        root = "s3://my-cromwell-bucket/workflow"
        filesystems {
          s3 {
            auth = "default-aws"
          }
        }
        runtime-attributes = """
        String? docker = "ubuntu:20.04"
        String? queue_arn = "arn:aws:batch:us-east-1:123456789012:job-queue/my-queue"
        Int? cpu = 2
        Int? memory_mb = 4096
        """
      }
    }
  }
}

嗯，这里要注意 queue_arn 一定要填正确。我曾经填错了 ARN 格式，Batch 任务一直挂起，查了半天才知道少了个 :。

认证方式：Cromwell 默认使用 AWS SDK 的凭据链（环境变量 AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY，或者 IAM 角色）。我建议用环境变量，清晰可控。

Azure 后端配置

Azure 的配置核心是 Blob 存储 + Azure Batch。Cromwell 需要知道存储账号、容器，以及 Batch 账号的链接。

你需要先创建好：

• 一个 Azure 存储账号，里面建一个 Blob 容器（比如 cromwell-workflows）。
• 一个 Azure Batch 账号，再创建一个 Batch 池。
• 服务主体（Service Principal）用于认证，或者用托管标识（MSI）。

Cromwell 配置：

backend {
  default = "Azure"
  providers {
    Azure {
      actor-factory = "cromwell.backend.impl.sfs.config.ConfigBackendLifecycleActorFactory"
      config {
        root = "az://my-account.blob.core.windows.net/cromwell-workflows/workflow"
        filesystems {
          azure {
            auth = "azure-oauth"
            storageAccountName = "my-account"
            storageAccountKey = "..."   # 也可以从环境变量读取
          }
        }
        runtime-attributes = """
        String? docker = "ubuntu:20.04"
        String? batchAccount = "mybatchaccount"
        String? batchPoolId = "cromwell-pool"
        Int? cpu = 2
        Int? memory_mb = 4096
        """
      }
    }
  }
}

认证部分我踩过一个大坑：以前我直接把存储账号密钥写死在配置文件里，结果不小心提交到了 Git……

后来改成用环境变量 AZURE_STORAGE_ACCOUNT_KEY 读取，安全多了。Azure 的 OAuth 也支持，但需要额外配 token 刷新。

GCP 后端配置

GCP 相对比较清爽。你需要把 Cromwell 指向 GCS 桶，并启用 Cloud Life Sciences API（旧称 Genomics API）。

准备工作：

• 在 GCP 项目中启用 Cloud Life Sciences API 和 Cloud Storage API。
• 创建一个 GCS 桶（比如 gs://my-cromwell-bucket）。
• 创建一个服务账号，下载 JSON 密钥，授予 Storage 对象管理员 + Life Sciences 调用者权限。

Cromwell 配置：

backend {
  default = "GCP"
  providers {
    GCP {
      actor-factory = "cromwell.backend.google.pipelines.v2alpha2.PipelinesApiLifecycleActorFactory"
      config {
        project = "my-gcp-project"
        root = "gs://my-cromwell-bucket/workflow"
        genomics {
          computeServiceAccount = "my-service-account@my-gcp-project.iam.gserviceaccount.com"
          location = "us-central1"
        }
        filesystems {
          gcs {
            auth = "gcp-json-key"
          }
        }
      }
    }
  }
}

认证 JSON 密钥可以放在环境变量 GOOGLE_APPLICATION_CREDENTIALS 指向的路径里。我习惯把密钥文件放在 /etc/cromwell/credentials.json，然后在 Cromwell 配置中引用。

三种云配置对比

维度	AWS	Azure	GCP
存储后端	S3 桶	Blob 容器	GCS 桶
计算后端	AWS Batch / ECS	Azure Batch	Cloud Life Sciences (Pipelines API)
认证方式	IAM 角色 / 访问密钥	服务主体 / 存储账号密钥	服务账号 JSON 密钥 / 默认凭据
默认 region	us-east-1	westeurope	us-central1
Cromwell actor-factory	ConfigBackendLifecycleActorFactory	ConfigBackendLifecycleActorFactory	PipelinesApiLifecycleActorFactory
URI 格式示例	s3://bucket/path	az://account.blob.core.windows.net/container/path	gs://bucket/path

配置文件中的通用建议

不管用哪家云，有几个原则我建议你记住：

• 把认证信息抽离到环境变量中，不要写在 Cromwell 的 .conf 文件里。
• 使用不同的 backend 名字区分环境（比如 AWS-Prod、Azure-Dev）。
• 测试时先用小任务跑通，确认日志和输出位置正确。

有个小细节：Cromwell 的 root 路径不要带斜杠结尾，否则容易拼出双斜杠路径。我曾经在 GCS 上遇到过路径 gs://bucket//workflow/ 导致权限拒绝的问题。