Add Terraform wings to Serverless Devs to achieve enterprise-level multi-environment deployment (Part 1)

Author: Feng Chong

foreword

With the popularization of modern applications and the deepening of enterprise cloud adoption, more and more cloud resource usage will be involved in the project. In the process of cloud migration of enterprises, there are often a platform team and an infrastructure (Infra) team: the platform team focuses on the business, abstracts according to business scenarios, and shields the infrastructure for R&D personnel; the infrastructure team focuses on security and cost, and provides the platform for the platform The team planned different sub-accounts, permission policies, and network configurations. The inevitable result of this layered management leads to completely different life cycles of applications and infrastructure, so infrastructure administrators, platform administrators, and R&D personnel focus on different cloud resource perspectives. for example:

• Infrastructure administrators manage the cloud accounts of the entire enterprise, plan the network configuration of the enterprise, and set different sub-accounts and access policies for each platform team;
• The platform administrator holds a sub-account, and divides regions, security, and traffic policies according to disaster recovery and high availability scenarios; plans log, storage, database specifications, backup configuration, quota, etc. according to business scenarios; plans CI/CD pipelines according to R&D process requirements ;
• In the process of using the platform, developers only need to pay attention to program-related content such as code, data, and configuration:
• • When you need to access the database, ask the platform for a data connection string;
  • When log collection is required, the collection path is submitted to the platform, and the platform operation log service completes the log collection configuration and mounting;
  • When persistent storage is required, submit the local mount path to the platform, and the platform operation storage service completes the file directory mount;
  • Publish code to automatically trigger the execution of the CI/CD pipeline;

Therefore, with the difference of responsibility boundaries, the platform team faces greater challenges. It not only needs to digest the business for R&D personnel, but also explain the use of cloud products to the infrastructure team, which undoubtedly increases a lot of communication costs and reduces business iterations. efficiency. If an automated pipeline can be established to allow different teams to complete their own boundaries by themselves, it is bound to greatly improve productivity. This requires several important concepts to connect Dev and Ops:

• Service: The description of the code and program, only the information related to the program, such as function configuration, log collection path
• • For functional applications, a service generally describes a function
  • For containerized applications, a service generally describes a Workload
• Environment: Services run in different environments. The environment is the carrier of service operation, describing the configuration of infrastructure (such as network, cluster, storage), and the operation and maintenance configuration (such as elastic scaling, resource specifications) when the application is running.
• Pipeline: A description of CI/CD that completes the build from code to service and deploys the service to all environments
• Application: a collection of resources for a set of services, environments, and pipelines

To achieve efficient self-service operations, it is rationalized to template the above concepts and use the following workflow to complete:

• Platform administrators encapsulate network, log service, storage, database and other infrastructure resources into environment templates according to the requirements of test/production isolation; apply Alibaba Cloud Function Computing (FC) functions and Serverless Application Engine (SAE) to these R&D concerns encapsulate the business resources into service templates; encapsulate the basic process of CI/CD into pipeline templates;
• Infrastructure administrators review the template, and assign corresponding sub-accounts to platform administrators after approval;
• The platform administrator holds a sub-account and selects environment templates to create different test, pre-release, and production environments, and then grants access rights to the R&D sub-account, or grants R&D write rights to create environments by themselves;
• The R&D personnel select the service template and the associated environment to create the service, and realize the automatic deployment of the application to the specified environment;
• R&D personnel select the pipeline template, and automatically trigger the execution of CI/CD through active triggering or code submission.

This boundary-based template processing method allows different teams of the enterprise to complete the infrastructure construction by themselves, improving production efficiency while ensuring permission isolation and protecting the infrastructure.

Challenges of Serverless Devs Supporting Multiple Environments

Serverless Devs [1] is a management tool for the whole life cycle of serverless applications. The concept of application and service exists in its model specification, but it lacks the inherent support for the environment. The code + infrastructure is jointly maintained under one s.yaml . There are three main limitations of this mode in multiple environments:

1. To maintain different s.yaml for different environments, the maintenance cost is relatively high. When updating the environment, you need to re-initiate the deployment, and when connecting to the CI/CD service, you need to re-initiate a complete release and online operation. (But under normal circumstances, changes in the environment, such as upgrading and upgrading, and updating permissions, are safe for the program, and do not need to initiate an online launch);
2. It is difficult to achieve a scenario where the infrastructure team, platform team, and R&D team collaborate in layers. For example, the service description of Alibaba Cloud Function Compute provides configuration from the perspective of platform administrators such as logs, network, NAS, and service roles. After receiving feedback from customers, the R&D of these configurations is basically unclear, which undoubtedly reduces R&D efficiency and increases security risks. There are often cases where R&D changes the wrong configuration, resulting in damage to online services;
3. The resource operations of Serverless Devs are mainly implemented by components. However, for the risk of instance reconstruction or failure to provide services (such as changing the database engine, changing the service role of FC, changing VPC) for some resource changes, component developers may not If it is clear, it may be ignored. Even if it is clear, it needs to be solved by Case By Case through a lot of judgment codes, which undoubtedly increases the complexity and cost of component development;\

If the layered templating scheme described in the preface of this article is used, the above problems can be solved smoothly:

1. By encapsulating the environment template, the platform team only needs to expose safe parameters (such as instance specifications) to the R&D personnel. The R&D personnel use the template to create an environment and fill in the necessary parameters to complete the infrastructure construction; it can be completed in a self-service manner by updating the environment. Infrastructure upgrades without re-initiating code release operations;
2. The platform team declares a stricter access policy in the environment template, denies some risky resource operations, and can better control the explosion radius;

So, the next question is: how to define environment templates in Serverless Devs?

When Serverless Devs Meet Terraform

Environment templates are for infrastructure, that is, cloud resources. Serverless Devs is inseparable from the operation of cloud resources. The traditional method is to directly use the cloud product SDK in the components. However, when supporting new resources, the corresponding component code needs to be developed. Therefore, it faces the reduction of development efficiency brought about by resource expansion and the more and more code. The more difficult to maintain problem, the better way is to complete the creation of cloud resources through Infrastructure as Code (IaC).

Serverless Devs used Pulumi in the previous practice to complete the encapsulation of the Pulumi Stack through a single component, but in practice, it is found that using GPLs to define IaC still requires a good abstraction at the model level. Maturity and flexibility are not very good. The most powerful tool in the current IaC ecosystem is Terraform, which has become the de facto standard. Terraform HCL itself is a DSL, which can be well compatible with any ecology, especially the Provider is extremely rich.

If Alibaba Cloud's cloud products are connected to POP, Terraform's Provider can be automatically generated, and its reliability and access convenience are quite high. If the definition of the environment template is done through Terraform IaC, and it can be well connected in the system of Serverless Devs, it can greatly expand the user field. Users can define their own infrastructure by writing Terraform files, and use Serverless Devs to complete all the Concatenation of workflows.

Operation case

Following the component development specification of Serverless Devs, the operation of multiple environments is encapsulated into the env command. By using the s env command, the following workflow can be realized:

1. Define reusable environment templates through Infrastructure as Code (IaC) capabilities
2. Build different test, pre-release, production and other isolated environments based on templates, and automatically complete the construction of infrastructure
3. Deploy the same code of a function to different environments

Below we demonstrate the entire operation process through an actual case. Suppose the business scenario requires:

• Read and write OSS files in functions
• The log file is written to the NAS, and the front end displays it in real time
• Write function logs to SLS for system analysis

As a platform administrator, you need to:

• Create an OSS Bucket. You can specify the bucket name by yourself, but the ACL policy must be private
• Create a NAS mount point. The involved VPC, VSwitch, NAS file system, access group, and mount point are completely specified by the administrator
• Create SLS Project, Logstore, the name R & D can be specified by yourself, but the automatic split and the maximum number of splits are completely specified by the administrator

Platform Admin: Development Environment Template

The environment template uses IaC to define resources. Currently, only Terraform templates are supported. The code directory of the environment template contains two types of files:

• IaC file: The .tf file of Terraform. The core elements of the IaC file are:
• • variable: defines the parameters of the template, the user enters the value of the parameter when creating the environment using the template
  • resource: defines the resource of the template, and the creation of the resource is completed when the environment is deployed
  • output: Define the output of the template. After the environment is deployed successfully, the corresponding output will be revealed, which can be accessed by other services

• policy.json: An array of permissions policies for RAM, which supports custom policies and system policies, and declares the permissions required to create resources using this template. The trusted object is Function Compute. When deploying an environment, Function Compute uses role-playing to access the resources defined in the template.

Write IaC, define variables, resources, and outputs of environment templates. Complete code example:

https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/main.tf

Define permission policies for the above resources, maintain the principle of minimum permissions, and only release necessary write permissions. Since Terraform relies on the read permissions of many resources when creating resources, it is recommended to add these commonly used read permissions:

• AliyunECSReadOnlyAccess
• AliyunVPCReadOnlyAccess
• AliyunNASReadOnlyAccess
• AliyunOSSReadOnlyAccess
• AliyunLogReadOnlyAccess
  
  Complete code example:

https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/policy.json

Platform Admin: Publishing Environment Templates

Publish environment templates via s env apply-template

 s env apply-template --name testing --description 'it is a demo' --code ./infra

The meaning of the parameters is as follows:

After the operation is successful, the varibale, outputs, status, policy, text content, version and other information of the current template will be returned.

R&D: Create an environment using an environment template

The environment needs permissions to operate the corresponding cloud resources, and grant Function Compute the role-playing access to cloud resources. Therefore, it needs to:

1. Create common service roles, trust service selection function computing
2. Grant the required permissions to the environment for this role

Enter the interactive operation through the s env init command, enter the environment name, region, role, environment template and template parameters to complete the deployment of the environment:

Click to view the operation video:

https://developer.aliyun.com/live/249417

After successful execution, the env/fc-env-testing.yaml description file will be created in the local .s directory, which can be viewed and edited.

R&D: deploy functions to a specified environment

The developer writes s.yaml and associates the infrastructure configuration to the specified environment. It can be done in the following ways:

• Use environment.outputs to associate the outputs defined in the environment template
• FC services are often mapped to an environment. Usually, when creating a service, the service name should be accompanied by the suffix of the environment. You can use environment.name to automatically associate the service with the environment.
• When specifying the environment, there is no need to specify the region in the props, the component will automatically ensure that the service is deployed to the region where the environment is located

Deploy the function to the specified environment via s deploy --env.

 s deploy --env fc-env-testing

After executing the command, the component will first determine whether the environment has been deployed. If the environment status is ready, the service will be deployed to the environment; otherwise, the environment will be deployed first, and then the service will be deployed.

Summarize

This paper analyzes the application and infrastructure management challenges encountered by enterprises when they fully migrate to the cloud, and proposes a layered templated approach to organize the workflows of different teams, and define a modern application through environments, services, and pipelines. Environment templates, service templates, and pipeline templates are used to shield the complexity of infrastructure and improve operational security. The core is the need for a pipeline to connect the entire workflow, so that each stage of DevOps can be self-service and completed safely. The author hopes that Serverless Devs can act as this pipeline. The idea of application, components and plug-ins provides developers with a good foundation for building modern applications, and Serverless Devs already have the abstraction of services and service templates. What needs to be extended is the environment and pipeline. Ability.

This article focuses on how to use Serverless Devs to manage multiple environments, analyzes the key challenge is to decouple code and infrastructure, and use IaC to complete the definition of infrastructure, and Terraform is the most suitable introduction in the IaC ecosystem, so I choose to use Terraform HCL is used to define the environment template, and the resource orchestration of the environment is done through the back-end Terraform service. In this way, the complete workflow of "release environment template" -> "deployment environment" -> "deploy application to specified environment" can be completed through Serverless Devs.

Of course, there is still a long way to go to realize the vision of the above-mentioned final state. The main roadmaps planned for the future are:

• Continue to polish the experience and output more out-of-the-box templates
• Solve the problem of accessing the environment when the application is running, such as safely and efficiently accessing the resources of the environment in the function code
• Ability to output pipeline templates, pipelines

This article introduces the use of the multi-environment function of Serverless Devs. In the next article, I will explain some common problems in detail.

Reference link:

Serverless Devs:

https://www.serverless-devs.com/

Pulumi:

https://www.pulumi.com/

Terraform:

https://www.terraform.io/

RAM:

https://www.aliyun.com/product/ram?spm

Alibaba Cloud Function Compute (FC):

https://www.aliyun.com/product/fc

---

This scenario is based on Serverless Application Center + Alibaba Cloud Function Computing + KodBox, an open-source enterprise-level online file management system, so that you can have a resource that can be saved at will, downloaded at unlimited speed, used on multiple terminals, and connected with just a few clicks. An exclusive personal network disk for friends to share resources...

Self-built real network disk: https://developer.aliyun.com/adc/series/activity/serverlessapp

Click here to deploy a personal network disk with Serverless in 1 minute!