全部产品
存储与CDN 数据库 安全 应用服务 数加·人工智能 数加·大数据基础服务 互联网中间件 视频服务 开发者工具 解决方案 物联网
云效

使用传入参数改变构建行为

更新时间:2017-09-25 10:01:32

尽管一个应用仅对应一个<应用名称>.release文件,但根据构建时上下文中传入的参数的不同,可以改变构建的行为,输出不同的构建结果。典型的,为不同的运行环境(比如测试环境和线上环境),打出不同内容,甚至不同类型的包。下面详细讲解基于同一份构建配置文件,根据上下文参数改变构建行为的方法。

原理:包标签及其他环境变量

在流水线上配置构建任务时,点击打开高级配置,会看到“包标签”这个配置:

包标签

包标签的默认值是default,但可以调整这个配置。构建打包得到的包,用于不同用途时,可以在上面打上相应的标签。比如部署到日常测试环境的包和部署到预发环境的包、生产环境的包,分别用testingstagingproduction来区分。流水线上的部署组件,就可以根据需要,配置取得特定标签对应的包。比如,取得testing对应的包,用来部署日常测试环境。

那么,构建组件是如何根据包标签名的不同,打出不同的包呢?在构建时,系统会把包标签的值通过环境变量的方式,传到构建的上下文中。具体来说,该环境变量的key是PACKAGE_LABEL,值就是包标签的名字。于是,构建过程就可以据此进行调整,以产生适合这个构建目的的包。调整方法详见下文描述。

除了包标签PACKAGE_LABEL这个环境变量,构建时系统还将把其他一些环境变量传入构建上下文。其中的一些,是系统自带的,详见构建传入环境变量完整列表。此外,用户还可以自定义若干key-value对:流水线上配置构建组件时的高级配置部分,在包标签设置的下方,有“+添加参数”按钮,点击可添加key-value对儿。

key-value对儿

构建过程可以根据以上这些环境变量进行调整。详见下文。

方法1:以PACKAGE_LABEL的值作为配置键的前缀

<应用名称>.release中的键(比如docker.file),可以用PACKAGE_LABEL的值作为前缀(比如testing.docker.file)。构建时,如果找到以当时PACKAGE_LABEL的值(比如testing)作为前缀的键(比如testing.docker.file),就将以它的值(比如Dockerfile),作为键(比如docker.file)的值。

PACKAGE_LABELtesting时候,RDC会寻找所有不带前缀的键值,并与带testing前缀的键值,进行合并。带前缀的键值拥有更高的优先级。也就是说下面的例子中,docker.file最终的值是Dockerfile_test

  1. docker.file=Dockerfile
  2. testing.docker.file=Dockerfile_test

这个方法,不仅可以让特定键在为不同环境构建时,获得不同的值,甚至可以仅在特定环境获得值。比如,如果仅日常环境使用阿里云容器服务,需要进行镜像构建,但在生产环境希望使用ECS部署,不需要进行镜像构建。那么对于这个场景,可以使用下面的写法。

  1. code.language=java
  2. baseline.jdk=jdk-1.7.0_51
  3. build.tools.maven=maven2.2.1
  4. # 使用`PACKAGE_LABEL`的前缀(testing, staging, production)的键值,只会在相应环境的构建中生效
  5. testing.docker.file=Dockerfile
  6. testing.docker.repo=registry.cn-hangzhou.aliyuncs.com/mynamespace/container-app
  7. testing.docker.tag=${TIMESTAMP}

方法2:键值因为环境变量的值而改变

可以在键值中使用环境变量,例如:

  1. docker.tag=${PACKAGE_LABEL}

还可以是组合,例如:

  1. docker.tag=${PACKAGE_LABEL}_${TIMESTAMP}

再举个例子,使用PACKAGE_LABEL作为maven构建的profile。在release文件中配置build.command=mvn clean install -P$PACKAGE_LABEL。并且在您的pom文件中设置对应的profile,在其中定义不同环境的不同行为。

方法3:构建过程中引用环境变量

比如,设置build.command=sh build.sh,然后在build.sh中使用环境变量的值来进行判断,并执行不同的操作。

一个具体的例子:我想在不同包的构建中,使用不同的数据库配置。假设程序运行时从application.properties中读取数据库配置,则可以在代码库中放置三个配置文件:application.properties.testingapplication.properties.stagingapplication.properties.production,在自定义流水线中也定义了的三个的PACKAGE_LABEL的值是testingstagingproduction。然后在build.sh中包含这么一行,将属于相应环境的配置文件覆盖到程序读取的文件,也就是application.properteis

  1. cp application.properties.$PACKAGE_LABEL application.properteis

注意:上面只是一个例子,具体的配置文件的路径以你的项目的实际情况为准。

非自定义流水线时的情况

前面讲的在流水线上配置构建组件时配置PACKAGE_LABEL的值,指的是用户可自定义的流水线。目前有些情况下,系统仍然在使用不能这样自定义的流水线。典型的,当使用分支模式时,每个环境(典型的:日常测试环境、预发环境、正式环境),都对应一条不能用户灵活配置的流水线。此时,PACKAGE_LABEL的值被分别设置为testingstagingproduction。(也就是旧版本RDC中的ENV_TYPE的值)

此外,当不是自定义流水线时,用户也无法传入更多的自定义环境变量。

本文导读目录