文档

管理环境

更新时间:
重要

本文中含有需要您注意的重要提示信息,忽略该信息可能对您的业务造成影响,请务必仔细阅读。

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

背景信息

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

  • 将服务部署在完全隔离的基础设施中(例如不同地域、不同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文件来部署。

    one-pipeline-one-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自动触发不同环境拉起云上资源,测试完成后删除环境资源;使用环境来一键开服;生产环境研发及运维职责分离,对研发隔离生产资源访问权限等。