自动化场景-基于CMP+Gitlab实现自动化资源供给

以下是视频转写全文，供参考：

Hello，大家好，欢迎回到阿里云开放平台自动化专栏Auto Talk。我是阿里云开放平台的研发工程师博纵。本期我们带来的是企业如何基于CMP+GitLab实现自动化资源供给。那么当下企业资源供给的方式主要有哪几种呢？第一种也是最常见的方式是由企业业务人员直接登录云控制台，手动创建资源。第二种是由企业业务人员通过脚本创建云资源。第三种是由企业业务人员登录企业自身的云管去申请并创建云资源。

企业云资源的申请流程中，目前面临着哪些问题呢？我们将问题主要归类为三种。在风险方面，企业在创建云资源的过程中，比如创建ECS的过程中，可能会引入未经检测的镜像，带来未知风险。同时企业也有可能使用未经允许的云产品，导致应用有其他的未经企业许可的依赖，进而引入未知风险。

在效率方面我们可以看到右边在2022年9月，我们的X86计算的ECS规格提供了495种。但是到了2023年6月，我们的X86计算的ECS规格数量已经提升到了594种。在我们提供丰富规格的ECS的同时，对于企业用户来说，我们的控制台的选择过多，难以选择正确的版本。同时如果企业采用的方式是由运维人员帮助业务人员创建资源的话，那么会增加交付团队的工作负担，阻碍业务快速发展。第三点，从成本角度来看，开发人员有可能会随意选择云产品和规格，导致成本失控。同时由于企业资源没有标准化的成本管理机制，企业创建的资源无法被成功的归类到资源组或者打上对应的标签。企业就无法有效的控制资源的成本。

我们本次提供的方案是如何解决我们之前提到的企业资源供给面临的问题。首先业务团队自助获取合规云资源，从而加速资源交付，提升团队整体的运作效率。其次，运维团队可以基于Terraform模板对云资源的类型、规格等进行定义，随后交付给业务团队，通过Terraform的方式创建云资源，保证云资源的安全合规。第三点，通过GitLab合并流水线的方式实现资源供给的流程化，实现企业角度云资源供给申请的统一审核。对于很多企业来说，目前都有多云战略的需求。我们的方案是通过GitLab和Terraform实现的，能够较好地满足企业对自动化资源供给的需求，我们抽象出了两个典型场景。

对于业务团队来说，新应用上云需要保持一定的敏捷性。我们在方案中的设计是业务团队首先选择所需的资源模板，之后通过模板部署资源，进而在云资源上部署它的应用。对于企业而言，企业更重视的是合规方面的需求。因此它需要通过设置合规基线，保证企业云资源的持续合规。在我们的方案中，企业管理方会定义它的Terraform模板，随后将模板交付给业务团队，用于业务团队申请。随后通过模板部署资源，然后再部署应用。对于企业来说，它的资源供给流程大概如该图所示。

首先业务团队在新应用上云的时候会，进行业务云账号申请。随后运维团队会在云管平台上对云账号进行审批与交付。当运维团队交付业务云账号后，业务团队会在该云账号下进行应用资源的申请，再由运维团队通过云管平台进行应用资源的审批与交付。我们本次的方案主要关注于业务团队如何在应用云账号交付之后，在应用云账号下进行应用资源的申请，以及运维团队如何进行应用资源的交付。

在我们方案的具体演示前，我需要再介绍一下我们方案的整体架构。首先业务团队需要通过我们方案的所提供的云管平台进行资源的申请。在进行资源申请后，由企业的管理人员进行第一次审批。当第一次审批通过后，云管平台会在企业的GitLab上创建出对应的变更分支，并且自动生成业务人员所申请的云资源对应的Terraform代码，并提交到该变更分支上，并且创建变更分支合并到主干的合并请求。创建合并请求后，会再由企业的运维人员进行二次审批。只有当企业的运维人员进行二次审批后，才会触发GitLab流水线进行Terraform apply的操作，从而创建实际的云资源。

下面我给大家演示一下我们实际的云资源申请的步骤。首先由企业的业务人员通过云管平台申请资源。这里企业业务人员可以填写资源实例名称。资源实例名称可以理解成企业内部的与企业应用相关的概念。

随后我们可以填入具体要创建的OSS bucket的名称。随后 业务人员可以填入他自己的申请原因，例如新应用上线。

申请应用所需的OSS bucket。我们可以在表单中选择我们创建OSS bucket的实际创建的地域和环境。这里的环境也是企业内部应用的概念。我们提供三种选项：日常、预发和线上。

随后我们在企业云管系统的资源申请工单列表，已经可以看到刚才用户所提交的具体资源工单了。这里可以看到我们的状态为审批中，审批中的状态在我们的系统中的含义就是等待具体的企业管理人员依次进行审批。这里我们模拟企业管理人员点击通过进行第一次审批。

可以看到这里我们的资源工单状态已经变成了开始变更。随后我们切换到企业的GitLab流水线这一页，可以看到企业的CMP系统在背后创建出了该资源申请工单对应的Merge Request。

在这里我们可以看到企业内部CMP系统在对应的用户提交工单的同时，创建了对应的变更分支。并在变更分支上提交了本次用户所填写的资源表单和对应的资源描述代码。随后GitLab流水线会自动的执行Terraform apply操作。可以在这里看到资源工单的状态变为了预检中，我们看到资源工单的状态变为了待执行。这意味着GitLab流水线已经执行完了Terraform apply操作。我们可以在这里下载Terraform plan日志，用于企业人员预览资源变更工单将要创建的资源，让企业管理人员在确认无误后，可以在企业CMP中点击执行，进行实际的云资源创建操作。

我们可以在GitLab页面中看到，我们的CMP系统已经实际通过GitLab API调用了触发GitLab流水线，然后进行了Terraform apply操作。回到企业CMP可以看到工单状态已经变成了执行成功。企业业务人员可以在这里下载的资源申请的Terraform apply的结果，最终实现云资源的实际交付。

最终我们登录到阿里云控制台，可以看到企业CMP已经通过GitLab流水线创建了名为application-coffee-1的OSS bucket，实现了应用所需云资源的交付。同时我们进入企业GitLab仓库，可以看到我们的资源变更分支已经被合并进了主干分支。我们进入主干分支下之前用户所指定的cn-hangzhou的生产环境文件夹，可以看到用户所创建的资源变更工单所对应的Terraform代码，已经被合并到了主干分支。

以上就是本期分享的全部内容了。若您有任何疑问或关于云上自动化的想法，欢迎扫描屏幕下方二维码，加入钉群与我们交流，期待下期再见。