使用YAML_Anchors让你的配置更优雅

简介

作为一个 YAML 开发工程师，很多人其实不知道 YAML 有个 Anchors 的功能。YAML Anchors 可以让你在一个地方定义一段内容，然后在文件的其他地方引用这段内容。这样可以让配置文件更加简洁，避免重复劳动，便于维护。

操作

当你在定义 GitLab 流水线的时候，比如 Spring Cloud 里面有很多模块需要编译，大部分的参数都是相同的，比如编译 runner 的 tag、stage、触发条件等，有一部分是不一样的，比如你的环境变量，这个时候你就可以使用 YAML Anchors 的功能，如下：

# 定义一个默认的构建配置
default_build: &default_build
  stage: build
  when: manual
  script:
    - bash build.sh
  tags:
    - mvnd

# 使用默认配置并覆盖部分变量
APP1-build:
  <<: *default_build
  variables:
    APP_NAME: APP1

APP2-build:
  <<: *default_build
  variables:
    APP_NAME: APP2

在上述例子中：

&default_build 定义了一个锚点，包含了一组下面所有 job 相同的配置。
<<: *default_build 用来“合并”这组配置到 APP1-build 或 APP2-build 配置中。
如果需要覆盖其中某一项（比如 script 或 stage），只需要单独在该环境配置里写出来即可。

上面配置等同于：

APP1-build:
  stage: build
  when: manual
  script:
    - bash build.sh
  tags:
    - mvnd
  variables:
    APP_NAME: APP1

APP2-build:
  stage: build
  when: manual
  script:
    - bash build.sh
  tags:
    - mvnd
  variables:
    APP_NAME: APP2

相比于配置 2，配置 1 简洁了很多，而且当你需要修改编译 runner 的 tag 的时候，只需要修改一个地方就可以了。

当你 APP1 和 APP2 的 tags 不一样的时候，你可以这么写：

# 定义一个默认的构建配置
default_build: &default_build
  stage: build
  when: manual
  script:
    - bash build.sh
  tags:
    - mvnd

# 使用默认配置并覆盖部分变量
APP1-build:
  <<: *default_build
  variables:
    APP_NAME: APP1

APP2-build:
  <<: *default_build
  variables:
    APP_NAME: APP2
  tags:
    - mvnd
    - node
    - mvn

这样，在 tags 这个 key 下，APP2 使用的是它自己的 tags，而不是共同的 tags。

注意

值得注意的是，并不是所有的解析器都完全支持 Anchor 和 Alias，比如 Docker Compose 推荐使用扩展字段（如 x-xxx），然后在各服务配置中通过 *alias 进行覆盖，而不是直接用合并键。

x-common-env: &common_env
  - DEBUG=true
  - LOG_LEVEL=info

services:
  app1:
    environment: *common_env
    image: myapp:latest
  app2:
    environment:
      - DEBUG=false
      - LOG_LEVEL=debug
      - EXTRA_SETTING=app2
    image: myapp:stable

这样 x-common-env 不会被当作服务启动，仅供引用。

欢迎关注我的博客www.bboy.app

Have Fun

Bboysoul's Blog

使用YAML_Anchors让你的配置更优雅

简介

操作

注意