如何使用 Pulumi 构建云平台 Apps 项目

背景

Iac 领域，terraform 应用比较广，之前公司主要也是使用 kubevela 来进行整个平台组件的架构部署。
在使用过程中，kubevela 本身的弊端也显而易见。

1. kubevela 本身不支持模板，为了支持不同的测试、预发布、生产环境的配置，或者其他需要动态化配置，则需要在 kubevela 之上再封装一层模板解析过程代码，增加了整体维护复杂性。
2. 在一些全局功能中，比如日志收集 sidecar 注入或者 Prometheus 数据接入等通用功能，依赖平台对 kubevela 的扩展能力，即 workload type 和 traits 的自定义支持，从而增加了对底层平台开发人员的依赖，影响 app 开发集成效率。

基于这两点考虑，我们调研了 Pulumi 对此类问题的解决方案。

1. Pulumi 使用 golang 等通用编程语言来管理整个 app 的部署生命周期，并且使用 stack 来管理不同的测试、预发布、生产环境的配置，增加了整个架构部署平台的代码复用能力。
2. Pulumi 在构建整个架构代码时，每个 app 都是独立的 pulumi project，用户直接使用 Pulumi api 来操作，并不需要依赖底层架构开发人员的支持，减少了沟通成本，增加了 app 开发部署效率。

目标

基于目前公司的业务，我们对底层基础架构平台有两点基本要求，后续所有问题解决方案参考该基本要求来确认边界。

1. app 的增加集成要方便开发人员测试，开发人员可以使用 pulumi 相关原生命令来测试整个 app 的创建、更新、删除等等流程管理，而不需要其他外部资源支持。
2. 对于整体基础架构的发布，要方便平台发布人员操作使用，平台发布人员不需要对基础架构代码进行任何修改，完成一键发布、更新等操作，对于每次发布，需要生成相关的发布 preview ，方便和开发人员来确认发布计划是否存在偏差。
3. 所有 app 的管理统一集中管理，方便运维开发人员进行整体平台创建。

Pulumi 项目结构规划

确认了目标之后，我们确定 pulumi-apps 的项目结构需要围绕这两个目标来构建。
由于Pulumi stack机制的限制，如果两个project都公用相同的stack名称时，操作一个project会删除掉另外一个project，主要原因还是pulumi后台stack管理的BUG，官方有相关讨论，暂时还未修复，参见Issues：
https://github.com/pulumi/pulumi/issues/8402
在基于此情况下，我们在automation中管理各个apps的安装，删除和与发布操作时，每个app都使用其app名称+dev/prod/test后缀来命名每个app project对应的stack名称，整个automation使用Pulumi automation API实现，参见文档：
https://www.pulumi.com/docs/guides/automation-api/getting-started-automation-api/
整体结构如下所示：

|____automation
|        |______main.go
|        |______go.mod
|        |______go.sum
|        |______Pulumi.Yaml
|        |______utils
|____apps
      |______minio.app
      |         |______main.go
      |         |______go.mod
      |         |______go.sum
      |         |______Pulumi.Yaml
      |         |______Pulumi.minio.app.dev.Yaml
      |_______volcano.app
      |         |______main.go
      |         |______go.mod
      |         |______go.sum
      |         |______Pulumi.Yaml
      |         |______Pulumi.volcano.app.dev.Yaml
      |________x.app
      |________y.app

该结构有以下几个特点：
1、automation目录是给平台升级维护人员使用，可以管理所有apps。
2、apps目录主要是给app开发人员使用，开发人员添加一个新的app，只需要使用pulumi new命令来操作生成即可，并且，不限制pulumi app project的开发语言，开发人员可以根据自己喜好来选择app开发语言。

后续更新

1、后续会在automation目录下提炼出整个系统的全局变量维护和底层服务(promethues/logging)统一接入维护。
2、会利用automation不同的stack来维护整体对应不同集群配置。
3、automation功能会识别pulumi up/destroy/preview等命令，来达到pulumi原生命令的统一支持。
4、可以再封装一层使用户不关注 pulumi api。