This video focuses on creating cloud resources, one of the most typical scenarios in cloud O&M. The video introduces how to use automation to create or manage cloud resources efficiently and securely. The video contains a specific example.
You can refer to the following transcript:
Hello, welcome back to Auto Talk, the Alibaba Cloud Open Platform Automation Series. I am Bozong, a research and development engineer for Alibaba Cloud Open Platform. In this episode, I will introduce how enterprises can achieve automated resource provisioning based on Cloud Management Platform (CMP) and GitLab. Enterprises use three methods for resource provisioning. The first and most common method involves business staff directly logging on to the cloud console to manually create resources. The second method involves business staff creating cloud resources through scripts. The third method involves business staff logging on to the cloud management platform of the enterprise to apply for and create cloud resources.
In the process of applying for enterprise cloud resources, several issues exist. These issues fall into three main categories. In terms of risk, during the creation of cloud resources, such as ECS instances, enterprises may introduce untested images, leading to unknown risks. Enterprises might also use unauthorized cloud services, which causes applications to have dependencies that are not approved by the enterprise. This introduces additional unknown risks.
Regarding efficiency, as of September 2022, ECS provides 495 x86 instance types. By June 2023, the number of x86 instance types increases to 594. The abundance of choices in the console makes it difficult for enterprise users to select the correct instance type. Additionally, if the enterprise adopts a method where operations personnel help business personnel create resources, the workload of the delivery team is increased, which hinders rapid business development. From a cost perspective, developers may choose cloud services and specifications arbitrarily, leading to cost overruns. Furthermore, due to the lack of a standardized cost management mechanism for enterprise resources, the resources created by the enterprise cannot be categorized into resource groups or tagged, making it difficult for the enterprise to effectively control resource costs.
The solution presented in this video addresses the previously mentioned challenges in enterprise resource provisioning. First, business teams can obtain compliant cloud resources, which accelerates resource delivery and improves overall team efficiency. Second, O&M teams define cloud resource types and specifications using Terraform templates and provide these templates to business teams. Business teams create cloud resources by using Terraform, ensuring the security and compliance of the cloud resources. Third, the solution uses the pipeline merging feature of GitLab to streamline the resource provisioning process, enabling a unified review of cloud resource requests from an enterprise perspective. Many enterprises require a multi-cloud strategy. Our solution, which leverages GitLab and Terraform, meets the needs of enterprises for automated resource provisioning. I will describe two typical scenarios.
For business teams, new applications going to the cloud require a certain level of agility. In the solution, business teams first select the required resource templates, deploy resources through these templates, and then deploy the applications on the cloud resources. For enterprises, compliance requirements take precedence. Therefore, enterprises need to set compliance baselines to ensure continuous compliance of cloud resources. In this solution, the enterprise management defines the Terraform templates and provides these templates to the business teams for application. Business teams deploy resources through the templates and proceed with application deployment. For enterprises, the resource provisioning process follows the diagram shown here.
When a new application goes to the cloud, the business team applies for a cloud account. The operations team reviews and delivers the cloud account through the cloud management platform. After the operations team delivers the business cloud account, the business team applies for application resources by using this cloud account. The operations team reviews and delivers the application resources through the cloud management platform. The current solution focuses on how the business team applies for application resources in the delivered cloud account and how the operations team delivers the application resources.
Before I show you an example, an introduction to the overall architecture of the solution is necessary. First, the business team needs to apply for resources through the cloud management platform. After the application, the management team conducts the first review. After the review is passed, the cloud management platform creates a change branch in GitLab and automatically generates the Terraform code for the cloud resources applied for by the business personnel. The platform submits this code to the change branch and creates a merge request to merge the change branch into the main branch. After creating the merge request, the operations personnel conduct a second review. After the second review, the GitLab pipeline runs the Terraform apply command to create the cloud resources.
Below, I demonstrate the actual steps for cloud resource application. First, the business personnel apply for resources through the cloud management platform. Here, the business personnel can specify the resource name. The resource name is the name of the application.
Next, the business personnel can enter the name of the OSS bucket. The business personnel can also provide the reason for the application. Example: New application being launched.
Applying for the OSS bucket required by the application. In the form, the business personnel can select the region and environment for the OSS bucket. The environment is used to deploy the application, and three options are available: Daily, Pre-release, and Production.
In the resource application ticket list of the cloud management platform, we can see the resource ticket submitted by the user. The status shows Approval in Progress, which means the system waits for the management personnel to approve the ticket. Here, we click Pass to approve the resource ticket.
The status of the resource ticket now changes to Change Initiated. Switching to the GitLab pipeline page, we can see that the CMP creates a Merge Request corresponding to the resource application ticket.
The CMP system creates a change branch when the user submits the ticket. The system commits the resource form and the corresponding resource description code to the change branch. The GitLab pipeline then automatically executes the Terraform apply operation. The status of the resource ticket changes to Pre-check in Progress. After the pre-check, the status changes to Pending Execution, indicating that the GitLab pipeline has completed the Terraform apply operation. One can download the Terraform plan log here to preview the resources that the resource change ticket will create. After confirming the details, the management personnel can click Execute in the CMP to create the cloud resources.
On the GitLab page, one can see that the CMP triggers the GitLab pipeline by calling the GitLab API and performs the Terraform apply operation. Returning to the CMP, the ticket status changes to Executed. The business personnel can download the results of the Terraform apply operation, completing the delivery of the cloud resources.
In the Alibaba Cloud console, one can see that the CMP has created an OSS bucket named application-coffee-1 through the GitLab pipeline, delivering the required cloud resources for the application. Additionally, entering the GitLab repository, one can see that the resource change branch has been merged into the main branch. In the main branch, under the previously specified cn-hangzhou production environment folder, one can see the Terraform code corresponding to the resource change ticket, which has been merged into the main branch.
This concludes this episode. If you have any questions or ideas about cloud automation, scan the QR code below to join the DingTalk group and communicate with us. We look forward to seeing you in the next episode.