关于后端:DevOps自动化我用模板为编排提效100倍

模板是什么？

看一个 go template 示例

echo "部署 {{.svc}} 服务"

这个模板生成的 shell 执行后可打印 部署 ** 任意 ** 服务，如：

echo "部署 user"
echo "部署 order"

模板用于形容不变的流程，模板参数示意可变动的局部，模板参数最终由输出值代替。

模板的分类

模板一共分三种：聚合模板、编排模板、执行模板 组成，实质是雷同的文本在不同的阶段采纳不同模板渲染规定。

聚合模板

聚合本地模板文件到一个编排内，性能相似 helm。

左右分隔符别离为 %{ 和}%，尽量和支流分隔符辨别开。

下图为 聚合 argo workflow templates、执行模板、配置模板 到一份编排示例：

模块定义模板

用来定义代码、kube、测试等 模块 的属性（含平安规定）、执行脚本、脚本配置模板。

模块的次要定义内容如下图：

以下为模块定义的一些示例

模板的左右分隔符别离为 !{ 和}!。

1. 代码 code.common 定义示例如下：

   code:
     common:
    labels:
      role: website,iot # role：代码仓库所属角色
      package: true # 示意公共库
    config: ""    # 示意不须要构建镜像
    settings:
      repo: http://xxxxxx/common.git
      mvn:
        api: # 只上传 jar 包 不打包和构建镜像
          dir: ""
      sonar:  
        exclusions: 'src/main/java/xxx/protobuf/**'  # sonar 扫描排除 pb 代码

2. 像 默认属性、平安规定、执行脚本、配置文件 在整个模块都是类似的，因而 优先定义在独立的全局配置。

code:  # 模块名
  __global__:  # 模块的全局配置
    workflow:
      templates: |
        %{readText "code/argo.templates.yaml" | indent 36}%
    security:
      pom:
        - name: "fastjson 反序列化破绽"
          env: ".*"
          action: "Info"
          content: "com\\.alibaba:fastjson:jar:1\\.2\\.(([1-7][0-9]?)|(8[0-2])):compile"
          message: "低版本 fastjson 存在反序列化安全漏洞，请降级到最新版本 1.2.83 及以上版本！"
    execTmpl: |
        %{readText "code/argo.yaml" | indent 34}%
    config:
      - |
        %{readText "code/run.Dockerfile" | indent 34}%
    default:
      type: git
      template: public/java:latest
        !{- if contains (or $.engine.metadata.annotations.codes "")"common" }!
      depends:
      - common
        !{- end}!

3. 定义中 不同环境的雷同属性的值不一样。

   feishu-workflow: &wf
     type: feishu
     settings:
    webhooks:
   #        - https://open.feishu.cn/open-apis/bot/v2/hook/aaaaaa # 测试群音讯
      !{- if inStr $.sys.env "dev" "debug" "pts"}!
      - https://open.feishu.cn/open-apis/bot/v2/hook/bbbbbbb # 开发环境
      !{- end}!
      !{- if inStr $.sys.env "sit" "alpha" "beta"}!
      - https://open.feishu.cn/open-apis/bot/v2/hook/cccccc # 测试环境
      !{- end}!
   

执行模板

此模板的 指标是生成最终的编排 ，次要包含 编排、执行脚本配置模板 ，左右分隔符别离为@{ 和}@。

上面以 CI、CD、 发版前后查看 为例作阐明。

编排示例如下：

@{- $check := or (contains .sys.env "uat-") (contains .sys.env "prod-") }@
metadata:
  annotations:
    platform: "linux/amd64"
spec:
  global:  # 全局配置，定义 workflow、k8s 环境等信息
    workflow:
      templates:
        %{readText "global.templates.yaml" | indent 14}%
    kube:
      %{readText "global.kube.yaml" | indent 12}%
  stages:
    - name: "ci"  # 阶段名
      desc: "性能包含下载代码、编译、制作镜像"
      modules:  # 定义用到的模块，由代码和参数填充内容；同时仅渲染该渲染的、解决大模板问题
        code: []

    @{- $cdDeps := "ci"}@
    @{- if $check}@
    @{- $cdDeps = concat $cdDeps ",precheck"}@
    @{- end}@

    - name: "cd"
      desc: "性能包含 k8s、nacos"
      depends: [@{- $cdDeps -}@ ] # 按条件生成依赖阶段
      modules:
        kube: []

    @{- if $check}@  # 按条件生成执行的阶段
    - name: "precheck"
      desc: "变更前巡检"
      modules:
        log: []
    - name: "check"
      desc: "变更后巡检"
      depends: ["cd"]
      modules:
        log: []
    @{- end}@

code 形容 CI 过程，包含下载代码、编译、构建镜像等性能，所有性能有脚本和配置实现(Dockerfile)。

脚本模板示例：

@{/* 下载代码 */}@
@{- $repoName := repoName .settings.repo}@
@{- $branch := or .settings.tag .settings.branch (render $env.code.branch .) }@
- name: git
  template: git
  arguments:
    parameters:
      - name: stage
        value: @{$.sys.stage}@
      - name: repo
        value: @{.settings.repo}@
      - name: branch
        value: @{$branch}@
      - name: repoName
        value: @{$repoName}@
@{/* 编译 */}@
- name: "mvn-@{$type}@"
  template: mvn
  depends: [@{ $depends}@]
  arguments:
    parameters:
      - name: cmd
        value: |
          mvn clean package -U -P @{$env.mvn.profile}@ -Dmaven.test.skip=true

@{/* 构建镜像 */}@
- name: docker
  template: docker
  depends: [mvn-@{$type}@]
  arguments:
    parameters:
      - name: stage
        value: @{$.sys.stage}@
      - name: name
        value: @{$parent.name}@
      - name: image
        value: @{$parent.settings._image}@
      - name: repoName
        value: @{$repoName}@

#要害命令如下：依赖 Dockerfile
#executor --cache=true --cache-dir=/cache --context=dir:///workspace --custom-platform=@{or .sys.annotations.platform "linux/amd64"}@ \
#--dockerfile=/workdir/{{inputs.parameters.name}}.Dockerfile \
#--destination={{inputs.parameters.image}} \
#--push-retry=5

执行脚本对应的 配置模板（Dockerfile）示例：

@{- $platform := "" -}@
@{- if and .sys.annotations.platform (not (contains .sys.annotations.platform "amd64")) -}@
@{- $platform = "-arm64" -}@
@{- end -}@

FROM openjdk:8.0.4@{- $platform}@

WORKDIR /
ARG JAR_FILE=app.jar
COPY ${JAR_FILE} app.jar

ENV TZ=Asia/Shanghai
#设置变量 JAVA_OPTS
ENV JAVA_OPTS=""
CMD @{$cmdPrefx}@ /sbin/tini -- java \
-Duser.language=zh -Duser.country=CN -Duser.timezone=Asia/Shanghai \
-Djava.security.egd=file:///dev/urandom \
-Dsun.net.client.defaultConnectTimeout=5000 -Dsun.net.client.defaultReadTimeout=60000 \
-Dspring.jmx.enabled=false -Dspring.backgroundpreinitializer.ignore=true \
-Djava.util.concurrent.ForkJoinPool.common.parallelism=10 \
-cp "/app:/app/lib/*" \
$JAVA_OPTS -jar /app.jar

模板的利用

平台与我的项目 / 部门 的根本流程如下图

阐明：不同色彩：示意不同我的项目 / 部门的整条链路都要差别解决，即 各模板的定义、构造和实现都存在差别。

结语

基于模板治理编排，使编排极易保护和扩大，相比仓库治理编排效率进步 100 倍不止。

TODO：行将补充残缺模板利用案例

请 <font style=”color:red;font-weight:bold”> 同学 </font> 关注下😉，我专一云原生 DevOps 落地，将按段公布上述能力的落地计划。

本文由 mdnice 多平台公布