Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Terraform for Serverless Devs – Implement Enterprise-Level Multi-Environment Deployment (Part 1)

Terraform for Serverless Devs – Implement Enterprise-Level Multi-Environment Deployment (Part 1)

Part 1 of this 2-part series analyzes the application and infrastructure management challenges encountered by enterprises when going to the cloud.

By Fengchong (Senior Technical Expert of Alibaba Cloud Serverless)

Preface

With the popularization of modern applications and the deepening of enterprise cloud migration, more cloud resources are required in business. During enterprise cloud migration, there are usually 2 teams involved, a platform team and an infrastructure team. The Platform Team focuses on the business, based on your business scenario abstraction for R&D personnel shielding infrastructure. The Infrastructure Team pays attention to safety and cost for the Platform Team planning different sub-account permission management, strategy, and network configuration.

The inevitable result of this hierarchical management leads to completely different lifecycles of applications and infrastructure. Therefore, infrastructure administrators, platform administrators, and R&D personnel focus on different perspectives on cloud resources.

For example:

  • The infrastructure administrator manages the cloud accounts of the entire enterprise, plans the network configuration of the enterprise, and sets up different sub-accounts and access control lists for each platform team.
  • The platform administrators hold a sub-account and divide the region, security, and traffic policies based on disaster recovery and high availability scenarios. They plan log, storage, database specifications, backup configurations, and quotas based on business scenarios. They plan the CI/CD pipeline based on R&D process requirements.

  • When using the platform, developers only need to focus on code, data, configuration, and other program-related content.

    • 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. The platform operates the log service to complete the log collection configuration mount.
    • When persistent storage needs to be used, submit the local mount path to the platform. The platform operates the storage service to mount the file directory.
    • Release code to trigger CI/CD pipeline execution automatically

Therefore, as the boundaries of responsibilities vary, the Platform Team faces an even greater challenge. The team should explain the business to the R&D personnel and explain the use of cloud products to the infrastructure team, which undoubtedly increases a lot of communication costs and reduces the iterative efficiency of the business.

If an automated pipeline can be established to allow different teams to complete their boundaries in a self-service manner, productivity will be improved significantly. This requires several important concepts to connect Dev and Ops:

  • Service: It describes the code and program and only describes the information related to the program, such as function configuration and log collection path.

    • For containerized applications, services generally describe a Workload.
    • For functional applications, a service generally describes a function.
  • Environment: Services run in different environments. The environment is the carrier of service operation. It describes the configuration of infrastructure (such as network, cluster, and storage) and the O&M configuration of application run time (such as Auto Scaling and resource specifications).
  • Pipeline: It is the description of CI/CD, completes the construction of code to service, and deploys service to all environments.
  • Application: It is the collection of a set of services, environments, and pipelines.

1

If you want to achieve efficient self-service operations, the rationalization solution is to template the concepts above and use the following workflow to complete them:

  • The platform administrator encapsulates infrastructure resources (such as network, log service, storage, and database) into environment templates according to the requirements of test/production isolation. The administrator encapsulates Alibaba Cloud Function Compute (FC) and Serverless App Engine (SAE) into service templates and encapsulates the basic processes of CI/CD into pipeline templates.
  • The infrastructure administrator reviews the template and assigns the corresponding sub-account to the platform administrator after passing the template.
  • The platform administrator holds a sub-account and selects an environment template to create a different test, pre-release, and production environments and then grants the R&D sub-account access permissions or grants the R&D write permissions to create the environment.
  • The developer selects the service template and the associated environment to create the service and realize the automatic deployment of the application to the specified environment.
  • The developer selects a pipeline template and automatically triggers the execution of CI/CD through active triggering or code submission.

Different teams of the enterprise can complete the construction of infrastructure by themselves through this borderline templated processing method, improving production efficiency while ensuring the isolation of permissions and protecting the infrastructure.

2

Challenges in Supporting Multiple Environments

Serverless Devs [1] is a management tool for the entire lifecycle of Serverless applications. Its model specification contains the concepts of applications and services but currently lacks internal support for the environment. The code and infrastructure are jointly maintained under an s.yaml. The limitations of this mode in multiple environments are mainly three points:

  1. The maintenance costs to maintain different s.yaml for different environments are relatively high. When updating the environment, you need to re-initiate the deployment. When you connect to CI/CD services, you need to re-initiate a complete release and launch operation. (However, under normal circumstances, environmental changes, such as upgrading and updating permissions, are safe for the program and do not need to initiate a launch.)
  2. It is difficult to achieve scenarios where infrastructure teams, platform teams, and R&D teams collaborate in layers. For example, the service description of Alibaba Cloud Function Compute (FC) provides the configuration from the platform administrator perspective, such as log, network, NAS, and service role. After receiving feedback from customers, the research and development of these configurations are unclear, which undoubtedly reduces the research and development efficiency and increases security risks. It often leads to the loss of online services caused by the wrong configuration of research and development.
  3. The resource operations of Serverless Devs are mainly implemented by components. However, some resource changes may cause instance reconstruction or failure to provide services (such as changing the database engine, changing the service role of FC, and changing the VPC). Component developers may not know it or ignore it. Even if it is clear, it needs to solve the problem case by case through many judgment codes. It undoubtedly increases the complexity of component development and usage costs.

If the layered templating scheme described in the preface of this article is adopted, the problems above can be solved successfully.

  1. After encapsulating an environment template, the platform team only needs to expose security parameters (such as instance types) to R&D personnel. R&D personnel use the template to create an environment and fill in the necessary parameters to build the infrastructure. The platform team can upgrade the infrastructure in a self-service manner without re-launching the code release operation by updating the environment.
  2. The platform team declares a stricter access control list in the environment template and rejects certain risky resource operations, which can control the explosion radius better.

How can we define an environment template in Serverless Devs?

When Serverless Devs Meets Terraform

The environment template is aimed at infrastructure or cloud resources. Serverless Devs cannot work without the operation of cloud resources. The traditional method is to directly use cloud product SDKs in components. However, corresponding component codes need to be developed when supporting new resources. Therefore, the development efficiency caused by resource expansion is reduced, and the code is increasingly difficult to maintain. A better way is to use the IaC of infrastructure (i.e. code) to create cloud resources.

Serverless Devs used Pulumi [2] to encapsulate Pulumi Stack through a single component in previous practice. However, in practice, it was found that using GPLs to define IaC still requires good abstraction at the model level. Therefore, it is not very good to extend Pulumi to component developers in terms of ecological maturity and flexibility.

Currently, the most powerful tool of IaC ecology is Terraform [3], which has become the de facto standard. Terraform HCL is a DSL, which can be compatible with any ecosystem, and it has lots of Providers. If Alibaba Cloud products are connected to POP, Terraform providers can be automatically generated, which has high reliability and access convenience.

If you use Terraform IaC to define an environment template and connect it well within the Serverless Devs system, this broadens the user domain immensely. You can write Terraform files to define your infrastructure and use Serverless Devs to connect all workflows.

3

Cases

Follow the component development specifications of Serverless Devs and encapsulate operations in multiple environments into env commands. The following workflows can be implemented using the env command:

  1. Define reusable environment templates through the ability of Infrastructure as Code (IaC).
  2. Based on the template, build different testing, pre-release, production, and other isolated environments, and automatically complete the construction of infrastructure.
  3. Deploy the same code of the function to different environments and demonstrate the whole operation process through a practical case.

Let's assume the business scenario requires:

  1. Read and write OSS files in functions
  2. Log files are written into NAS and displayed in real-time at the frontend.
  3. Write function logs to SLS for system analysis

As a platform administrator, you need to develop:

  • Create an OSS Bucket: The name of the bucket can be specified by R&D. However, 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 an SLS Project and a Logstore: The name R&D can be specified by yourself, but the automatic splitting and the maximum number of splits are completely specified by the administrator.

Platform Administrator: Development Environment Template

Environment templates use IaC to define resources. Currently, only Terraform templates are supported. The code directory of the environment template must contain two types of files.

  • IaC File: It is the .tf file of Terraform. The core elements of the IaC file are:

    • Resource: It defines the template. The resource is created when the environment is deployed.
    • Output: It defines the output of the template. After the environment is successfully deployed, the corresponding output can be accessed by other services.
    • Variable: It defines the parameters of the template. When the user uses this template to create an environment, enter the value of the parameter.

4

  • Policy.json: It is the policy array of RAM [4], which supports custom policies and system policies and declares the permissions required to use this template to create resources. The credit object is the Function Compute [5]. When you deploy an environment, the Function Compute accesses the resources defined in the template in role-playing mode.

Write IaC to define the variable, resource, and output of the environment template

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

5

Define a policy for the preceding resources, maintain the principle of minimum permissions, and only release the necessary write permissions. Terraform depends on the read permissions of many resources when creating resources. Therefore, we recommend adding these common read permissions:

  • AliyunECSReadOnlyAccess
  • AliyunVPCReadOnlyAccess
  • AliyunNASReadOnlyAccess
  • AliyunOSSReadOnlyAccess
  • AliyunLogReadOnlyAccess

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

Platform Administrator: Publish Environment Template

Publish an environment template using the s env apply-template:

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

The following list describes the fields in the format:

Parameter Required Description
Name True Environment Template Name
Description False Environment Template Description
Code False Template Code Directory

After the operation succeeds, the variables, outputs, status, policy, text content, and version of the current template are returned.

R&D: Create an Environment Using an Environment Template

The environment needs permissions to operate the corresponding cloud resources to grant Function Compute access to the cloud resources in role-playing mode. Therefore, you need to:

  1. Create a common service role and select Function Compute for credit service
  2. Grant the permissions required by the environment to the role

Run the s env init command to enter an interactive operation. Enter the environment name, region, role, environment template, and template parameters to deploy the environment:

After the execution, the env/fc-env-testing.yaml description file is created in the . s directory. You can view and edit the file.

6

R&D: Deploy a Function to a Specified Environment

The developer writes s.yaml and associates the infrastructure configuration with the specified environment. You can use the following methods:

  • Use environment.outputs to associate the output defined in the environment template.
  • FC services are often mapped to an environment. Usually, when creating a service, the service name must include the suffix of the environment. You can use the environment.name to automatically associate the service with the environment.
  • When you specify an environment, you do not need to specify a region in props. The component automatically ensures the service is deployed to the region where the environment resides.

7

Use s deploy --env to deploy the function to a specified environment:

s deploy --env fc-env-testing

After the command is executed, the component determines whether the environment has been deployed. If the environment is in the ready state, the service is deployed to the environment. Otherwise, the component deploys the environment before the service is deployed.

Summary

This article analyzes the application and infrastructure management challenges encountered by enterprises when going to the cloud and proposes adopting a hierarchical templating method to organize the workflows of different teams. It defines a modern application through environment, service, and pipeline. Environmental templates, service templates, and pipeline templates are used to shield the complexity of infrastructure and improve operational security. The core is that a pipeline is needed to connect the entire workflow and let the various stages of DevOps be self-service and completed safely.

The author hopes that Serverless Devs can serve as this pipeline. The ideas of its applications, components, and plug-ins provide developers with a good foundation for building modern applications. Serverless Devs already has the abstraction of services and service templates and needs to expand the capabilities of environments and pipelines.

This article focuses on how to use Serverless Devs to manage multiple environments. The key challenge is to decouple code and infrastructure and use IaC to complete the definition of infrastructure. In the IaC ecosystem, Terraform is the most suitable one to be introduced. Therefore, Terraform HCL is used to define environment templates. The Resource Orchestration Service (ROS) of the environment is completed through the Terraform service in the backend. This way, you can use Serverless Devs to complete the complete workflow of publish environment template → deploy environment → deploy an application to the specified environment.

There is still a long way to go to realize the vision above. The main Roadmap for future planning is listed below:

  1. Continue to better the experience and output more templates out of the box
  2. Solve the problem of application run time accessing the environment (such as accessing the resources of the environment safely and efficiently in some way in the function code)
  3. Ability to output pipeline templates and pipelines

This article introduces the use of multi-environment features of Serverless Devs. Part 2 of this 2-part series
will explain some common problems in detail.

References

DevOps Terraform Computing Serverless Function Compute CI/CD Deployment R&D Serverless Devs
0 0 0
Share on

Read previous post:

Detailed Asynchronous Tasks: Task Status and Lifecycle Management

Read next post:

Terraform for Serverless Devs – Implement Enterprise-Level Multi-Environment Deployment (Part 2)

Alibaba Cloud Serverless

97 posts | 7 followers

You may also like

Comments

Alibaba Cloud Serverless

97 posts | 7 followers

Related Products

More Posts by Alibaba Cloud Serverless

See All