1 分•作者: lionello•大约 2 个月前
Hi HN，
这是三个 FOSS Pulumi 提供程序（defang-aws、defang-gcp、defang-azure），它们接受类似 Docker Compose 的项目，并将其作为真正的基础设施配置到相应的云中：VPC、子网、负载均衡器、无服务器容器（ECS Fargate、Cloud Run、Container App）、构建、托管 PostgreSQL、Redis、LLM 以及公共/私有 DNS。
一次开发，随处部署：所有这三个提供程序都公开了相同的 Compose 形状的接口。它们包含相同的 Pulumi 资源：Project、Build、Service、Postgres、Redis、LLM。Compose services 映射中的每个服务都将作为这些资源之一进行配置。在云之间切换应该像更改导入一样简单，不需要其他操作。Project 资源为服务发现设置私有 DNS，因此 Compose 服务可以使用其 Compose 服务名称进行连接。
这些提供程序已从头开始用 Go 重写，并基于我们过去 2 年一直在使用的（内部）TypeScript Pulumi 代码。我们尚未完全达到同等水平，但我们鼓励大家使用它们并分享您的反馈。
Pulumi 工具为 TypeScript、Python、Go 和 C# 生成 SDK。该存储库提供了所有云中所有这些语言的示例，例如：
```
const app = new defang_aws.Project("demo", {
services: {
web: {
image: "nginx:latest",
ports: [{ target: 80, mode: "ingress", appProtocol: "http" }],
},
},
});
export const endpoints = app.endpoints;
```
一些说明：
- Compose 接口是有主见的。我们检查服务需求并将其映射到具体的云资源。例如，在 GCP 上，没有公开端口的服务将在 Compote Engine 上运行，而不是 Cloud Run。
- 可移植性在 Compose 级别。每个云的行为都不同：IAM、原生容器等。API 相同，但实现方式不同。
- Project 资源拥有共享基础设施（VPC、构建管道、DNS、LB）。独立的 Service、Postgres、Redis 资源会跳过这一步，因此 Service 需要一个构建好的镜像。
- 许可方式是双重的：提供程序引擎是 AGPL-3.0，因为我们希望分支能够回馈社区。生成的 SDK 是 Apache-2.0，因此在您自己的 Pulumi 代码中没有 copyleft。
- 我们正在等待 Pulumi 开发人员合并我们的注册表 PR，因此注册表仍然反映旧的 v1 提供程序文档。
- 支持运行时“config”，即参数，使用 ConfigProvider 接口，该接口也支持插值。
仓库：[https://github.com/DefangLabs/pulumi-defang](https://github.com/DefangLabs/pulumi-defang)
很乐意深入探讨 Compose 翻译的工作原理、API 在云之间差异的原因（以及原因）、为什么选择 Pulumi 而不是 CDK/Terraform，或者特定于云的权衡（AWS 使用 ECS+ALB，GCP 使用 Cloud Run 并可选地回退到 CE，Azure 使用 Container Apps）。
- Lio