Manage application environments-阿里云帮助中心

After you create an application, you can view its environment information. This topic describes how to manage application environments in the App Center of the Function Compute console, including how to create, view, and delete environments, and use environment isolation.

Background information

Environments provide infrastructure management capabilities that allow you to:

Deploy services in completely isolated infrastructures, such as different regions or VPCs. This helps you achieve high availability or low latency for production services.
Associate different pipeline trigger rules with environments. For example, you can configure a commit to a development branch to trigger continuous integration (CI) for the staging environment, and a merge to the main branch to trigger a release to the production environment. This helps you implement a systematic and secure production process.

Usage notes

By default, no domain name is assigned to an environment. An environment can host Alibaba Cloud resources, such as Log Service, VPC, and Apsara File Storage NAS (NAS) resources. These resources are isolated in different environments. To use different domain names for different environments, you must specify the customDomains field in the s.yaml file of the repository.
An environment requires permissions to access Alibaba Cloud services when it hosts resources. You can grant the required permissions by assigning the necessary Alibaba Cloud service policies to the AliyunFCServerlessDevsRole role.
You can deploy services to different environments, but you can choose whether to use the configurations provided by the environment.

View an environment

Log on to the Function Compute console. In the navigation pane on the left, click Applications. On the Applications page, click the xiala icon to the left of the target application to view its list of environments.

Click an environment name to view its details. The details include basic information, source code configuration, deployment history, and associated resources. You can also perform cloud-based development and configure pipelines for the code associated with the environment.

Roll back an environment

Important

Rolling back an environment involves risks. If an environment issue occurs because of an incorrect operation, you can use the rollback feature to restore the environment to a specific point in time. However, this feature rolls back only the business code of the current application and does not roll back downstream services. For example, if your application uses a database that becomes inaccessible due to an incorrect operation, rolling back the application's business code may not resolve the database fault.

On the Environment Details tab of the application details page, find the Deployment History section and click Roll Back to roll back the environment.

env-rollback

An environment rollback redeploys the business logic and its corresponding configurations based on a deployment history snapshot. The business logic and configurations refer to the code and resource configurations, such as the s.yaml file, in a specific commit of the code repository.

Resource management

The Serverless App Center does not provide resource management features, but it lets you view information about associated resources.

You can use the resource association information to go to the management page of a resource to perform operations. However, Function Compute does not recommend this method. You should manage all resources through the s.yaml resource description file in the code repository. If you directly modify a resource on its management page without synchronizing the changes to the resource description file, the resource may be overwritten. For example, the resource description file in the code repository for a branch specifies that the memory size of a function is 1024 MB. A developer then directly modifies the function's configuration to change its memory to 2048 MB without updating the resource description file. When the environment pipeline is triggered for deployment, the function's memory is changed back from 2048 MB to 1024 MB.

Cloud-based development

The Serverless App Center provides cloud-based development capabilities. On the Cloud-based Development tab of the application details page, click Initialize Repository to initialize the code.

After initialization, you can view the code in the WebIDE and perform basic development and debugging operations. When you are finished, you can use the Terminal or the Git plugin to push the code to the code repository. You can also click Save Code to Repository in the upper-left corner to quickly add, commit, and push the code.

cloud-develop

Pipeline management

For more information, see Manage pipelines.

Create an environment

The App Center provides developers with multi-environment management capabilities. On the application details page, click Create Environment and follow the on-screen instructions to create an environment. create-environment

The following table describes the configuration items for creating an environment.

Configuration item	Description
Environment Name	The name of the environment. It is used to distinguish between environments. An environment type can correspond to multiple environment names.
Environment Type	You can use this to classify and filter environments. The available environments are test, staging, or production.
Basic Information	Includes the environment description, region, and role name. The options that you configure on the Create Environment page, such as region, log feature, network configuration, and storage configuration, have a higher priority than the configurations in the `s.yaml` resource description file in the code repository or application template. For example, the `s.yaml` file in the code repository specifies the region as China (Hangzhou). However, you set the region to China (Beijing) when you create the environment. In this case, the resources are deployed in the China (Beijing) region.
Pipeline Configuration	In the Serverless App Center, each environment corresponds to one pipeline by default. You can configure the pipeline for each environment.

In the Serverless App Center, the multi-environment feature is primarily associated with code branches in a code repository. The best practice is to map each environment to a dedicated pipeline and each pipeline to a specific branch. For example, you can create a dev branch for the development environment, a test branch for the staging environment, and a main/master branch for the production environment. By committing code to different branches, you trigger pipelines that update the corresponding environments. You can use the PR/MR feature of the code repository to manage the flow of code from the development branch to the staging branch and then to the main branch.

In practice, you may need to use one set of code to deploy multiple applications for different users. In this case, you can have one code branch trigger multiple pipelines to ensure that multiple environments are synchronized after a code update.

Delete an environment

Log on to the Function Compute console. In the navigation pane on the left, click Applications. On the Applications page, find the target environment, click Delete in the Actions column, and follow the on-screen instructions.

Warning

Deleting an environment may involve deleting resources. When you delete an environment, confirm the names and types of the resources to be deleted. If you do not want to delete a specific resource, clear the check box next to it.

delete-environment

Use environment isolation

The Serverless App Center uses the GitOps approach as a best practice for DevOps. This approach involves using a Git repository to manage application infrastructure and CI/CD flows, making the Git repository the single source of truth for the application's state. Environment isolation is achieved using a compliant YAML file and setting the relevant configurations in the file. For more information about YAML specifications, see YAML specifications or .

In many scenarios, enterprises distinguish between developer and operations and maintenance (O&M) roles, which have clear responsibilities. The infrastructure is typically managed by O&M engineers and granted to developers for use. If all infrastructure is maintained in a Git repository, O&M engineers must change the infrastructure by committing code. This may not align with the typical workflow of O&M engineers in some scenarios. Therefore, the App Center provides the following three deployment methods.

Method 1:
Maintain different YAML files for different environments. In each environment, configure the pipeline to use the specified YAML file for deployment.
Serverless Devs supports YAML inheritance to reduce the cost of repetitive YAML configurations. For more information, see YAML Inheritance or .
Method 2:
Use the same YAML file for different environments. The different configurations for each environment are stored as pipeline environment variables. You can reference these environment variables in the YAML file to achieve isolation. For more information about how to configure environment variables, see Pipeline environment variables. The following is an example.
```
vars:
  region: ${env(region)}
  service:
    name: demo-service-${env(prefix)}
    internetAccess: true
    logConfig:
      project: ${env(LOG_PROJECT)}
      logstore: fc-console-function-pre
    vpcConfig:
      securityGroupId: ${env(SG_ID)}
      vswitchIds:
        - ${env(VSWITCH_ID)}
      vpcId: ${env(VPC_ID)}
```

Method 3:

Use the same YAML file for different environments. You can directly use the resource information of the environment where the service is located to configure the service. The following is an example.

service:
  logConfig:
    project: ${environment.outputs.slsProject}
    logstore: ${environment.outputs.slsLogStore}
  vpcConfig:
    vpcId: ${environment.outputs.vpcId}
    securityGroupId: ${environment.outputs.securityGroupId}
    vswitchIds:
    - ${environment.outputs.vswitchId}
  nasConfig:
    userId: 10003
    groupId: 10003
    mountPoints:
    - serverAddr: ${environment.outputs.nasMountTargetId}
      nasDir: /fc-deploy-service
      fcDir: /mnt/auto

Different deployment methods are suitable for different scenarios.

Method 1:
This method is suitable for scenarios where developers and O&M engineers are on the same team and both have permissions to maintain YAML files. This method provides high agility.
Method 2:
This method is suitable for scenarios where the infrastructure does not change frequently and the number of environments is small. O&M engineers plan the resources in advance and configure them as pipeline environment variables. The YAML file only needs to declare references to these environment variables. This method completely separates concerns but is not easily scalable when a large amount of infrastructure is involved.
Method 3:
This method is suitable for modern Serverless application development. For example, CI can automatically trigger the creation of cloud resources for different environments and then delete the resources after testing is complete. You can also use environments for one-click service deployment. In a production environment, you can separate the responsibilities of developers and O&M engineers and prevent developers from accessing production resources.