如何通过控制台应用中心管理应用环境_函数计算(FC)-阿里云帮助中心

应用创建成功后，您可以查看应用对应的环境信息。本文介绍如何通过函数计算控制台应用中心管理应用环境，包括创建环境、查看环境、删除环境以及使用环境隔离服务。

背景信息

环境提供基础设施的管理能力。通过环境，您可以：

将服务部署在完全隔离的基础设施中（例如不同地域、不同VPC间服务隔离），实现生产服务的高可用或者低延迟。
为环境关联不同的流水线触发规则（例如，开发分支提交动作触发测试环境CI，主干分支合并触发生产环境发布），实现科学的安全生产流程。

使用说明

环境不会自动分配域名，但环境可以托管一些云资源，例如SLS、VPC或NAS等，这些资源在不同环境中互相隔离。如果需要不同环境使用不同的域名，需要在仓库的s.yaml中指定customDomains字段。
环境托管资源时需要访问云服务的权限。您可以对AliyunFCServerlessDevsRole角色授予相关云服务的权限策略。
服务可以部署到不同的环境中，但是否使用环境提供的配置由用户自己决定。

查看环境

登录函数计算控制台，在左侧导航栏，单击应用，然后在应用页面，单击目标应用左侧的 xiala 图标查看应用的环境列表。

单击环境名称，您可以查看某个环境的详细信息，包括基本信息、代码源配置以及部署历史、对应的资源等。另外，还可以对环境关联的代码进行云端开发以及流水线配置。

环境回滚

重要

环境回滚存在一定风险。当用户误操作导致环境问题时，通过环境回滚功能可以回滚到正确的时间节点，但是此处提供的回滚，仅为当前应用的业务代码回滚。对于上下游的业务等，无法进行回滚，例如，当前应用使用了数据库，如果数据库因为其他错误操作导致无法连接，此时回滚应用的业务代码，可能无法解决数据库的故障。

您可以在应用详情页面的环境详情页签，在部署历史区域，单击回滚进行环境回滚。

env-rollback

环境回滚是指按照对应的部署历史快照，进行业务逻辑与对应配置的重新部署。业务逻辑与对应配置是指对应代码仓库中，指定commit中的代码与资源配置，例如s.yaml。

资源管理

Serverless应用中心不提供资源管理功能，但是支持查看资源关联的信息。

可以通过资源关联信息，进入到对应资源的管理页面进行资源管理等操作。函数计算不推荐此操作，推荐所有的资源管理通过代码仓库中的资源描述文件s.yaml进行管理。在资源管理页面直接对资源进行操作，而未同步更改代码仓库的资源描述文件，可能会导致资源被覆盖。例如，某环境对应分支下代码仓库中的资源描述文件中，描述了某函数对应的内存大小为1024 MB，此时开发者直接修改该函数配置，将其内存修改为2048 MB，而没有更新代码仓库中的资源描述文件，此时触发环境流水线部署，会导致该函数的内存由2048 MB变回1024 MB。

云端开发

Serverless应用中心提供了云端开发能力。您可以在应用详情页面的云端开发页签，单击初始化仓库初始化代码。

初始化之后，可以在WebIDE中查看代码，并进行基础的开发和调试等操作。完成之后可以通过Terminal或者Git插件将代码推送到代码仓库，也可以点击左上角的保存代码到仓库快速进行代码的Add、Commit和Push操作。

cloud-develop

流水线管理

具体信息，请参见管理流水线。

创建环境

应用中心为开发者提供多环境管理能力。开发者可以在应用详情页面单击创建环境，然后根据界面提示即可快速完成环境创建。 create-environment

创建环境涉及的配置项说明如下。

配置项	说明
环境名称	环境的命名，用于对环境进行区分。一个环境类型可以对应多个环境名称。
环境类型	用于对环境进行分类和筛选。目前提供测试环境、预发环境以及生产环境。
环境的基础信息	包括环境的描述、地域、角色名称等。在新建环境页面对环境进行配置的选项（例如地域、日志功能、网络配置以及存储配置等），优先级高于代码仓库中或者应用模板中资源描述文件`s.yaml`的配置。例如，代码仓库中存在`s.yaml`，配置地域为华东1（杭州），而在创建环境时配置地域为华北2（北京），则最终的资源部署地域为华北2（北京）。
流水线配置	在Serverless应用中心，默认每个环境对应一条流水线，您可以针对不同环境对流水线进行配置。

Serverless应用中心，提供的多环境能力更多是与代码仓库的代码分支进行关联。推荐的最佳实践为一个环境对应一条流水线，一条流水线对应一个分支。例如，可以在代码仓库创建dev分支对应开发环境，test分支对应测试环境，以及main/master分支对应生产环境。通过向不同的分支提交代码，触发流水线，确保环境的正常更新。从开发分支到测试分支，再到主干分支，可以通过代码仓库提供的PR/MR功能，实现代码的流转与环境的流转。

实际使用过程中，会存在使用一份代码部署多个应用，给不同用户使用的情况，此时可以通过一个代码分支触发多条流水线，以实现代码更新后，多个环境同步生效。

删除环境

登录函数计算控制台，在左侧导航栏，单击应用，然后在应用页面，单击目标环境右侧操作列的删除，根据界面提示，可以删除不再使用的环境。

警告

删除环境可能涉及资源的删除。因此删除环境时，需要确定要删除的资源名称与资源类型。如果不需要删除资源，需要取消勾选资源左侧的复选框。

delete-environment

使用环境隔离服务

Serverless应用中心采用GitOps方式进行DevOps的最佳实践，即通过Git仓库来管理应用基础设施以及CI/CD流程。Git仓库是应用状态的唯一真实来源，具体方式是使用符合规范的YAML文件，通过在YAML文件中设置相关配置实现使用环境隔离服务。关于YAML规范，请参见YAML规范。

在很多场景下，企业内部会区分开发和运维角色。两者有着明确的职责划分，基础设施一般由运维角色管理并且授权给研发使用。如果所有基础设施都维护到Git仓库中，需要运维人员通过提交代码的方式来变更基础设施，在一些场景下不太符合运维人员的使用习惯。因此，应用中心当前提供以下三种部署方式。

方式一：
不同环境维护不同的YAML文件，在环境中配置流水线，使用指定的YAML文件来部署。
Serverless Devs支持YAML的继承能力来减少YAML重复配置成本。具体操作，请参见YAML继承。

方式二：

不同环境使用同一个YAML文件，环境的差异化配置在流水线环境变量中，通过在YAML文件中引用环境变量来隔离。示例如下。

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)}

方式三：

不同环境使用同一个YAML文件，直接使用所在环境的资源信息来配置指定服务，示例如下。

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

不同的部署方式适用的场景不同。

方式一：
适用于研发和运维属于同一个团队，均有维护YAML文件权限的场景。此方式非常敏捷。
方式二：
适用于基础设施变更不频繁且环境个数不多的场景。由运维角色提前规划好资源并且配置到流水线环境变量中，YAML文件中只需要声明引用环境变量。此方式关注点完全分离，但是基础设施较多时不便于扩展。
方式三：
适用于现代化Serverless应用的研发方式，例如，CI自动触发不同环境拉起云上资源，测试完成后删除环境资源；使用环境来一键开服；生产环境研发及运维职责分离，对研发隔离生产资源访问权限等。