Zadig 的服务可以是一组 Kubernetes 资源集合（下面简称 K8s YAML）、一个完整的 Helm Chart 或者是主机服务。下面分别介绍这几种类型的服务操作。

K8s YAML 服务

新建服务

进入项目的服务管理页面。

创建服务

系统支持以下三种方式创建 K8s YAML 服务：

  • 手动输入：在创建服务时手动输入服务的 K8s YAML 配置文件，内容存储在 Zadig 系统中。
  • 从代码库同步：服务的 K8s YAML 配置文件在代码仓库中，从代码库中同步服务配置。当代码库中的服务配置有变更时，会通过 Webhook 自动更新 Zadig 平台中的服务配置。
  • 使用模板新建：在 Zadig 平台中创建服务 K8s YAML 模板，创建服务时，在模板的基础上对服务进行重新定义。

手动输入

点击手工输入按钮 -> 填写服务名称 -> 将服务 K8s YAML 填入编辑器 -> 点击保存按钮，即可新建服务。

创建服务

添加服务成功后即可对环境进行更新：点击环境更新，选择要更新的环境，将服务加入到环境中。

更新环境

从代码库同步

前提

需要在系统中集成代码源，可参考：代码源集成。

点击从代码库同步按钮 -> 选择具体的代码库和目录 -> 点击同步，即可从代码库同步新建服务。

从代码库同步创建服务

使用模板新建

前提

需要先在系统模板库里创建 K8s YAML 模板，请参考 K8s YAML 模板管理。

点击使用模板新建按钮 -> 填写服务名称，选择模板，按需对模板中的变量进行赋值 -> 点击新建，即可使用此模板和新的变量赋值新建服务。

使用 K8s YAML 模板

更新服务

下面分别介绍如何更新使用不同方式新建的服务。

更新手动输入的服务

修改服务的 K8s YAML 内容并保存即可。

修改服务

服务修改成功后即可对环境进行更新：点击环境更新，选择要更新的环境对环境中的服务进行更新。

更新环境中的服务

更新从代码库同步的服务

  • 提交服务配置变更到代码仓库。

配置变更

  • 变更合并后，通过 Webhook 的能力自动同步最新配置到 Zadig 系统。也可以在界面上手动同步服务配置，如下图所示。

服务手动配置同步

  • 在 环境中，查看服务配置的变更，点击更新服务钮执行更新操作。

服务版本diff 服务更新

更新使用模板新建的服务

点击使用模板新建的服务 -> 点击预览/编辑，即可预览/编辑该服务的 K8s YAML 配置。

配置变更

删除服务

点击服务右侧的删除按钮即可将服务删除，若需要将服务从环境中移除，点击环境更新并选择要更新的环境即可。

删除环境

服务编排

Zadig 系统支持对多个服务进行编排，重新组合定义多个服务的启动顺序，适用于多个服务的启动顺序有先后依赖关系的场景。

点击服务编排图标，按需对服务启动顺序进行拖拽组合。

K8s 服务编排 K8s 服务编排

共享服务

一个 K8s YAML 服务在某个项目中被设置为共享后，可被添加到使用 K8s YAML 部署的其他项目中去，参与该项目的服务编排。

  • 设置共享服务：点击服务右侧的共享按钮即可设置该服务为共享服务。

设置 K8s YAML 共享服务

  • 使用共享服务：在共享服务列表中，点击服务右侧的+即可将该服务添加到当前项目中，且服务右侧会有共享字段标识。

添加 K8s YAML 共享服务

扩展阅读

  • 使用共享服务只是复用服务的定义，并不是共享服务实例。在不同项目的环境中，相同的共享服务也是独立的服务实例。
  • 使用其他项目中的共享服务时，构建过程会使用该共享服务对应的构建脚本。

变量配置

变量主要分为系统内置变量和自定义变量，均可在服务 YAML 中进行引用。

变量

系统内置变量

包括 $Namespace$、$Product$、$Service$、$EnvName$ ，可直接在 YAML 中进行引用，具体说明如下：

  • $Namespace$：项目创建的环境所在的 K8s 空间名称
  • $Product$：项目名称
  • $Service$：服务名称
  • $EnvName$：创建的环境名称

自定义变量

通过平台新增 Key，可输入默认 Value，通过关键字：{{.key}} 引用

例如：在 K8s YAML 中引用配置的变量

  1. apiVersion: extensions/v1beta1
  2. kind: Ingress
  3. metadata:
  4.   name: $Product$-index  //引用系统内置变量 $Product$，环境创建时被渲染
  5. spec:
  6.   rules:
  7.   - host: {{.portal_host}} //引用自定义变量 portal_host，环境创建时被渲染
  8.     http:
  9.       paths:
  10.       - backend:
  11.           serviceName: $Product$-index
  12.           servicePort: 80
  13.         path: /

变量的使用

创建集成环境时使用

在创建环境时，对项目中所有服务的 YAML 和服务配置文件进行渲染。

创建集成环境变量渲染

环境变量更新时使用

在环境中，对于正常运行中的服务，可以自行更新变量值，基本操作中点击更新环境变量，即可更新对应环境中的环境变量。

更新集成环境变量渲染

策略配置

在策略中设置部署服务的超时时间以及服务交付产物的命名规则。

服务策略配置

说明如下：

  • 服务部署超时设置：将服务部署到环境中的超时时间，默认值为 10 分钟。若超出该阈值服务仍未处于 Running 状态，则视为部署超时。
  • 交付物命名规则设置：自定义该项目中工作流构建产物的命名规则，对当前项目的所有服务都生效，可通过以下变量和常量组合的方式设置。
变量名称描述
TIMESTAMP工作流任务的执行时间戳，形如 20211029113304
TASK_ID工作流任务的 ID
REPO_BRANCH构建过程中指定代码仓库使用的分支信息
REPO_PR构建过程中指定代码仓库使用的 Pull Request 信息
REPO_TAG构建过程中指定代码仓库使用的 Tag 信息
REPO_COMMIT_ID构建过程中指定代码仓库使用的 Commit ID 信息
PROJECT构建所属的 Zadig 项目名称
SERVICE构建编译的服务名称
ENV_NAME构建部署的环境名称
字符常量大小写字母、数字、中划线、下划线及点组合生成的 127 个字符以内的常量

服务 YAML 样例

无状态服务

概念：服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的。可以参考这篇文章服务 - 图22 (opens new window)了解无状态服务的更多细节。

点击查看

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: nginx-deployment
  5. spec:
  6.   selector:
  7.     matchLabels:
  8.       app: nginx
  9.   replicas: 2 # 2 个 Pod 实例
  10.   template:
  11.     metadata:
  12.       labels:
  13.         app: nginx
  14.     spec:
  15.       containers:
  16.       - name: nginx
  17.         image: nginx:1.14.2
  18.         ports:
  19.         - containerPort: 80

有状态服务

概念：服务的实例可以将一部分数据随时进行备份，并且在创建一个新的有状态服务时，可以通过备份恢复这些数据，以达到数据持久化的目的。可以参考这篇文章服务 - 图23 (opens new window)了解有状态服务的更多细节。

点击查看

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: mysql
  5.   labels:
  6.     app: mysql
  7. data:
  8.   master.cnf: |
  9.     # Apply this config only on the master.
  10.     [mysqld]
  11.     log-bin
  12.   slave.cnf: |
  13.     # Apply this config only on slaves.
  14.     [mysqld]
  15.     super-read-only
  16. ---
  17. # Headless service for stable DNS entries of StatefulSet members.
  18. apiVersion: v1
  19. kind: Service
  20. metadata:
  21.   name: mysql
  22.   labels:
  23.     app: mysql
  24. spec:
  25.   ports:
  26.   - name: mysql
  27.     port: 3306
  28.   clusterIP: None
  29.   selector:
  30.     app: mysql
  31. ---
  32. # Client service for connecting to any MySQL instance for reads.
  33. # For writes, you must instead connect to the master: mysql-0.mysql.
  34. apiVersion: v1
  35. kind: Service
  36. metadata:
  37.   name: mysql-read
  38.   labels:
  39.     app: mysql
  40. spec:
  41.   ports:
  42.   - name: mysql
  43.     port: 3306
  44.   selector:
  45.     app: mysql
  46. ---
  47. apiVersion: apps/v1beta1
  48. kind: StatefulSet
  49. metadata:
  50.   name: mysql
  51. spec:
  52.   selector:
  53.     matchLabels:
  54.       app: mysql
  55.   serviceName: mysql
  56.   # 1 master and 2 slave
  57.   replicas: 3
  58.   template:
  59.     metadata:
  60.       labels:
  61.         app: mysql
  62.     spec:
  63.       initContainers:
  64.       - name: init-mysql
  65.         image: mysql:5.7
  66.         command:
  67.         - bash
  68.         - "-c"
  69.         - |
  70.           set -ex
  71.           # Generate mysql server-id from pod ordinal index.
  72.           [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
  73.           ordinal=${BASH_REMATCH[1]}
  74.           echo [mysqld] > /mnt/conf.d/server-id.cnf
  75.           # Add an offset to avoid reserved server-id=0 value.
  76.           echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
  77.           # Copy appropriate conf.d files from config-map to emptyDir.
  78.           if [[ $ordinal -eq 0 ]]; then
  79.             cp /mnt/config-map/master.cnf /mnt/conf.d/
  80.           else
  81.             cp /mnt/config-map/slave.cnf /mnt/conf.d/
  82.           fi
  83.         volumeMounts:
  84.         - name: conf
  85.           mountPath: /mnt/conf.d
  86.         - name: config-map
  87.           mountPath: /mnt/config-map
  88.       - name: clone-mysql
  89.         image: gcr.azk8s.cn/google-samples/xtrabackup:1.0
  90.         command:
  91.         - bash
  92.         - "-c"
  93.         - |
  94.           set -ex
  95.           # Skip the clone if data already exists.
  96.           [[ -d /var/lib/mysql/mysql ]] && exit 0
  97.           # Skip the clone on master (ordinal index 0).
  98.           [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
  99.           ordinal=${BASH_REMATCH[1]}
  100.           [[ $ordinal -eq 0 ]] && exit 0
  101.           # Clone data from previous peer.
  102.           ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
  103.           # Prepare the backup.
  104.           xtrabackup --prepare --target-dir=/var/lib/mysql
  105.         volumeMounts:
  106.         - name: data
  107.           mountPath: /var/lib/mysql
  108.           subPath: mysql
  109.         - name: conf
  110.           mountPath: /etc/mysql/conf.d
  111.       containers:
  112.       - name: mysql
  113.         image: mysql:5.7
  114.         env:
  115.         - name: MYSQL_ALLOW_EMPTY_PASSWORD
  116.           value: "1"
  117.         ports:
  118.         - name: mysql
  119.           containerPort: 3306
  120.         volumeMounts:
  121.         - name: data
  122.           mountPath: /var/lib/mysql
  123.           subPath: mysql
  124.         - name: conf
  125.           mountPath: /etc/mysql/conf.d
  126.         resources:
  127.           requests:
  128.             cpu: 500m
  129.             memory: 1Gi
  130.           limits:
  131.             cpu: 500m
  132.             memory: 1Gi
  133.         livenessProbe:
  134.           exec:
  135.             command: ["mysqladmin", "ping"]
  136.           initialDelaySeconds: 30
  137.           periodSeconds: 10
  138.           timeoutSeconds: 5
  139.         readinessProbe:
  140.           exec:
  141.             # Check we can execute queries over TCP (skip-networking is off).
  142.             command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
  143.           initialDelaySeconds: 5
  144.           periodSeconds: 2
  145.           timeoutSeconds: 1
  146.       - name: xtrabackup
  147.         image: gcr.azk8s.cn/google-samples/xtrabackup:1.0
  148.         ports:
  149.         - name: xtrabackup
  150.           containerPort: 3307
  151.         command:
  152.         - bash
  153.         - "-c"
  154.         - |
  155.           set -ex
  156.           cd /var/lib/mysql
  158.           # Determine binlog position of cloned data, if any.
  159.           if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
  160.             # XtraBackup already generated a partial "CHANGE MASTER TO" query
  161.             # because we're cloning from an existing slave. (Need to remove the tailing semicolon!)
  162.             cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
  163.             # Ignore xtrabackup_binlog_info in this case (it's useless).
  164.             rm -f xtrabackup_slave_info xtrabackup_binlog_info
  165.           elif [[ -f xtrabackup_binlog_info ]]; then
  166.             # We're cloning directly from master. Parse binlog position.
  167.             [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
  168.             rm -f xtrabackup_binlog_info xtrabackup_slave_info
  169.             echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
  170.                   MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
  171.           fi
  173.           # Check if we need to complete a clone by starting replication.
  174.           if [[ -f change_master_to.sql.in ]]; then
  175.             echo "Waiting for mysqld to be ready (accepting connections)"
  176.             until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done
  178.             echo "Initializing replication from clone position"
  179.             mysql -h 127.0.0.1 \
  180.                   -e "$(<change_master_to.sql.in), \
  181.                           MASTER_HOST='mysql-0.mysql', \
  182.                           MASTER_USER='root', \
  183.                           MASTER_PASSWORD='', \
  184.                           MASTER_CONNECT_RETRY=10; \
  185.                         START SLAVE;" || exit 1
  186.             # In case of container restart, attempt this at-most-once.
  187.             mv change_master_to.sql.in change_master_to.sql.orig
  188.           fi
  190.           # Start a server to send backups when requested by peers.
  191.           exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
  192.             "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
  193.         volumeMounts:
  194.         - name: data
  195.           mountPath: /var/lib/mysql
  196.           subPath: mysql
  197.         - name: conf
  198.           mountPath: /etc/mysql/conf.d
  199.         resources:
  200.           requests:
  201.             cpu: 100m
  202.             memory: 100Mi
  203.       volumes:
  204.       - name: conf
  205.         emptyDir: {}
  206.       - name: config-map
  207.         configMap:
  208.           name: mysql
  209.   volumeClaimTemplates:
  210.   - metadata:
  211.       name: data
  212.     spec:
  213.       accessModes: ["ReadWriteOnce"]
  214.       resources:
  215.         requests:
  216.           storage: 10Gi

K8s Helm Chart 服务

Helm服务 - 图24 (opens new window) 是 Kubernetes 应用的包管理工具， Helm Chart 定义、安装和升级复杂的 Kubernetes 应用。

新建服务

支持从代码库同步、从 Chart 仓库同步、使用模板新建三种方式创建 K8s Helm Chart 服务。

从代码库同步

服务的 Helm Chart 配置文件在代码库中，从代码库中同步服务配置，支持 GitHub/GitLab/Gerrit 代码仓库。

点击从代码库同步 -> 填写代码库及服务配置在代码库中的目录 -> 点击加载，即可从代码库同步服务。同步成功后，当代码库中对应目录的文件有变更时，会通过 Webhook 的方式自动更新此处的服务配置。

前提

需要先集成代码源，参考 GitLab/GitHub/Gerrit 集成。

从 Git 仓库导入 Helm Chart

从 Chart 仓库同步

服务的 Helm Chart 配置文件在 Chart 仓库中，从 Chart 仓库中同步服务配置。

前提

需要先集成 Helm Chart 仓库，参考：集成 Helm Chart 仓库。

点击从 Chart 仓库同步，选择 Chart 仓库及 Chart，新建即可。 从 Chart 仓库同步 Helm Chart

使用模板新建

在 Zadig 平台中创建服务 Helm Chart 模板，创建服务时，在模板的基础上对服务进行重新定义。支持一次创建一个服务，也支持基于模板批量创建服务。

前提

需要先在系统模板库里创建 Helm Chart 模板，请参考 Helm Chart 模板管理

创建单个服务
  • 点击使用模板新建 -> 填写服务名称并选择模板 -> 按需对模板中的变量进行覆盖赋值后，导入即可。

从 Git 仓库导入 Helm Chart

  • 在高级设置中，系统还支持用新的 values.yaml 覆盖模板中的内容，包括手动输入和从指定 Git 仓库导入两种途径来覆盖。

从 Git 仓库导入 Helm Chart

批量创建服务
  • 点击使用模板新建 -> 点击批量创建 -> 选择 Helm Chart 模板 -> 选择要导入服务的 values 文件，导入即可。

从 Helm Chart 模板导入服务

  • 一份 values 文件会被定义成一个服务，values 文件名即为服务名。服务批量创建完毕后，点击更新环境即可将服务快速应用于环境中。

预览从 Helm Chart 模板导入服务后效果

服务组件镜像信息自定义

导入 Helm Chart 配置文件后，系统会按照内置规则解析 vaues.yaml 文件中的镜像内容。当默认规则不满足需求时，用户可自定义镜像解析规则。

Helm Chart 服务组件自定义 Helm Chart 服务组件自定义

Zadig 系统会解析镜像名为可被部署和更新的服务组件，系统关于 values.yaml 中服务组件内置的解析规则如下：

  1. values.yaml 中有如下代码段结构，拼接 image.repository:image.tag 作为该组件的镜像版本，服务的部署版本和更新均围绕 image.repository 和 image.tag。该例中即为：ccr.ccs.tencentyun.com/koderover-public/backend:latest。

点击查看

  1. # Helm Chart values.yaml Demo
  2. key1: value1
  3. key2: value2
  4. key3:
  5.   key4: value4
  6.   key5:
  7.     image:
  8.       repository: "ccr.ccs.tencentyun.com/koderover-public/backend"
  9.       tag: "latest"
  10.   key6:
  11.     ...
  12. ...
  1. values.yaml 中的 image 字段的值为镜像信息，服务的部署版本和更新均围绕 image。该例中即为 ccr.ccs.tencentyun.com/koderover-public/backend:latest。

点击查看

  1. # Helm Chart values.yaml Demo
  2. key1: value1
  3. key2: value2
  4. key3:
  5.   key4: value4
  6.   key5:
  7.     image: "ccr.ccs.tencentyun.com/koderover-public/backend:latest"
  8.   key6:
  9.     ...
  10. ...
  1. 用户也可自定义解析规则，提供关于镜像的明确信息。说明如下：
  • 使用 key 的绝对路径来解析组件的镜像信息，下例中，自定义规则中填入 deploy.image.repo/deploy.image.name:deploy.image.tag 即可。

点击查看

  1. key1: value1
  2. key2: value2
  3. ...
  4. deploy:
  5.   image:
  6.     repo: library
  7.     name: ubuntu
  8.     tag: 20.04
  • 使用 key 的相对路径来解析服务组件的镜像信息，下例中，自定义规则中填入 repo/name:tag 即可。

点击查看

  1. key1: value1
  2. key2: value2
  3. ...
  4. deploy:
  5.   image:
  6.     repo: library
  7.     name: ubuntu
  8.     tag: 20.04
  • 支持使用一份解析规则来解析多个服务组件，下例中，自定义规则中填入 repo/name:tag 即可解析出 service1 和 service2 的镜像分别为 library/service1:v1 和 library/service2:v2。

点击查看

  1. key1: value1
  2. key2: value2
  3. ...
  4. deploy:
  5.   service1:
  6.     repo: library
  7.     name: service1
  8.     tag: v1
  9.   service2:
  10.     repo: library
  11.     name: service2
  12.     tag: v2
  • values.yaml 文件中可复用部分 key，下例中，自定义规则中填入 public.repoInfo/name:tag 即可解析出 service1 和 service2 的镜像分别为 library/service1:v1 和 library/service2:v2。

点击查看

  1. key1: value1
  2. key2: value2
  3. ...
  4. public:
  5.   repoInfo: library
  6. deploy:
  7.   service1:
  8.     name: service1
  9.     tag: v1
  10.   service2:
  11.     name: service2
  12.     tag: v2
  • 自定义规则中的 仓库地址/命名空间 和 标签名 非必填，下例中，在自定义规则的镜像名中填入 deploy.image.name 即可

点击查看

  1. deploy:
  2.   image:
  3.     name: library/ubuntu:12.04

更新服务

更新从代码库同步的服务

  • 从代码库导入服务的 Chart 配置后，会自动创建 Webhook。当对应代码库中有变更时，会自动同步服务的 Chart 配置到 Zadig 中。也可以点击服务右侧的同步按钮，点击加载主动同步更新。

更新 Helm Chart 服务

更新从 Chart 仓库同步的服务

  • 点击服务右侧的同步按钮，按需修改 Chart 版本号，点击更新即可。

更新 Helm Chart 服务

更新使用模板新建的服务

  • 点击服务右侧的同步按钮，按需修改 Helm values 文件后点击导入即可。

更新 Helm Chart 服务

删除服务

  • 点击服务右侧的删除按钮即可将服务配置删除。若需要将服务从环境中也删除，点击更新环境并选择要更新的环境即可。

删除服务

策略配置

在策略中设置部署服务的超时时间以及服务交付产物的命名规则。细节可阅读：策略配置。

服务策略配置

Helm Chart 样例

koderover/zadig服务 - 图38 (opens new window) 库中提供了 Helm Chart 样例，点击链接服务 - 图39 (opens new window)查看详情。

托管项目服务

配置托管服务

  • 点击环境下的配置托管。

托管服务

  • 按需选择左侧列表中的服务拖至右侧，点击下一步，新增对该服务的托管管理；或者将右侧已托管服务拖至左侧，取消对该服务的托管。

配置托管

主机服务

在 Zadig 系统上主机服务的配置中包括服务的构建脚本、资源配置、部署配置和探活配置。

新增服务

  • 点击添加服务按钮 -> 输入服务名称 -> 填写基本信息、部署配置及探活配置。

新增服务

基本信息

  • 配置构建脚本，定义服务的构建打包过程。

主机服务的构建脚本相关配置说明，参考构建模块。

部署配置

  • 配置部署脚本，定义服务的部署过程。

部署脚本

说明：

  • 部署方式：
    • 本地直连部署：直接在 Zadig 所在集群中执行部署操作，需确保 Zadig 系统能连通或访问到脚本中的主机地址。
    • 使用 SSH Agent 远程部署：安全登录到目标机器，执行部署操作。
  • 部署脚本和构建脚本共享存储卷，在构建脚本中生成的包在部署脚本中直接获取。
  • 部署脚本可以使用构建脚本中系统内置变量，构建包需使用 $PKG_FILE 获取。

探活配置

配置探活

字段说明：

  • 协议：支持 HTTP、HTTPS 和 TCP。
  • 路径：HTTP/HTTPS 请求的健康检查路径。
  • 端口：支持 1 - 65535 端口。
  • 响应超时：超出设定时间，判断为不健康。
  • 高级设置：
    • 探测间隔：两次探活请求的间隔时间，默认 2s。
    • 健康阈值：从不健康变为健康的连续探测次数。
    • 不健康阈值：从健康变为不健康的连续探测次数。

更新服务

  • 选择需要修改的服务，修改服务配置，点击保存 -> 点击更新环境 -> 在弹框中选择需要更新的环境。

更新服务

删除服务

  • 点击服务右侧的删除按钮将服务删除。删除服务后，若需将服务从环境中也删除，点击更新环境即可。

删除服务