Skip to content

DeployServer

Jump to bottom
StruggleYang edited this page Jan 2, 2019 · 37 revisions

1.概述

本文档是Dapeng自动化部署平台的设计文档, 旨在提供一套平台,标准化以及简化系统上线发布的流程, 减轻运维的工作压力.

2.平台架构

系统分为两个部分:

  1. deploy-server

deploy-server将服务运行所需要的所有配置项入库, 负责生成运行所需的配置文件(一般为yml), 并指示agent进行系统的发布/回滚等.

  1. deploy-agent(以下简称agent).

agent部署在服务节点上, 并接收deploy-server的指令并根据指令做具体的操作.

3.配置管理

配置管理员通过平台修改配置项:

配置管理

配置项包括:

  • 环境集信息(对应数据模型为t_set): 用于区分不同的环境, 例如:测试环境, 演示环境, 生产环境等
  • 节点信息(对应数据模型为t_host): 描述某环境下的某个节点信息, 一般是指宿主机. 例如:测试环境下的sandbox1, 生产环境的app-5等
  • 服务信息(对应数据模型为t_service): 描述服务信息, 例如服务名,镜像名等
  • 配置项(对应数据模型为t_environment): 描述具体的配置项信息
  • 部署信息(对应数据模型为t_deploy_unit): 描述服务的部署信息
  • 部署历史信息(对应数据模型为t_deploy_journal): 描述服务的历史部署信息

其中, 配置项可出现在t_set, t_host以及t_service中, 优先级为t_set<t_host<t_service. 但通常建议只把配置项配置到t_set级别上, 以实现最大程度的信息共享 通过环境集/节点/服务/配置项的组合, 我们可以生成部署信息.

3.1 环境集管理

包括新建/修改/禁用/查找等功能. 选定环境集后, 可直接管理该环境集的配置项信息.

3.2 节点信息管理

包括新建/修改/禁用/查找等功能. 选定节点后, 可直接管理该节点的配置项信息.

3.3 服务信息管理

包括新建/修改/禁用/查找等功能. 选定服务后, 可直接管理该服务的配置项信息.

4.部署管理

通过部署管理模块, 实现服务的发布/回滚/启停/摘除等功能. 同时, 我们还需要根据注册中心的实时数据, 跟数据库的设定数据做比较, 不一致的话需要告警(健康度: 小于2个节点的服务, 背景黄色, 没有节点的服务, 灰色. ) 有2个维度去展现该功能模块:

4.1 节点维度

从t_deploy_unit中根据host分组(选定某环境集后), 展示所有主机的服务信息.(初始情况下列表为空) 包括:新建部署(如果点击某节点, 那么就是基于该节点的部署)/升级服务/回滚服务/重启服务/停止服务等功能.

4.2 服务维度

从t_deploy_unit中根据service分组(选定某环境集后), 展示所有服务的信息. 包括:新建部署(如果点击某服务, 那么就是基于该服务的部署)/升级服务/回滚服务/重启服务/停止服务等功能.

5.数据模型

DataModel

CREATE TABLE IF NOT EXISTS `config_server_db`.`t_set` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(45) NOT NULL COMMENT '环境集名称, 例如sandbox1, demo, onlineDemo, ',
  `env` VARCHAR(8192) NULL COMMENT '环境变量',
  `created_at` DATETIME NOT NULL,
  `updated_at` TIMESTAMP(0) NOT NULL DEFAULT 'CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP(0)',
  `remark` VARCHAR(255) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8mb4
COMMENT = '环境集信息表';


-- -----------------------------------------------------
-- Table `config_server_db`.`t_host`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `config_server_db`.`t_host` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(45) NOT NULL COMMENT '节点(宿主机)名称, 例如app-5',
  `set_id` INT NOT NULL,
  `ip` INT NOT NULL COMMENT '该节点IP信息',
  `labels` VARCHAR(45) NULL COMMENT '逗号分隔的标签,用于分类',
  `extra` SMALLINT(2) NOT NULL DEFAULT 0 COMMENT '是否外部机器. 内部机器用于部署, 外部机器用于配置extra_host',
  `env` VARCHAR(4096) NULL COMMENT '尽量不要再host上配置, 以免扩容时麻烦',
  `created_at` DATETIME NOT NULL,
  `updated_at` TIMESTAMP(0) NULL DEFAULT 'CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP(0)',
  `remark` VARCHAR(255) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8mb4
COMMENT = '节点信息表';


-- -----------------------------------------------------
-- Table `config_server_db`.`t_service`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `config_server_db`.`t_service` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(45) NOT NULL COMMENT '服务名称',
  `image` VARCHAR(128) NOT NULL COMMENT '镜像',
  `labels` VARCHAR(255) NULL COMMENT '逗号分隔的标签,用于分类',
  `env` VARCHAR(4096) NULL,
  `volumes` VARCHAR(1024) NULL,
  `ports` VARCHAR(1024) NULL,
  `compose_labels` VARCHAR(4096) NULL COMMENT 'labels node of source-compose',
  `docker_extras` VARCHAR(1024) NULL COMMENT '例如restart, cmd等',
  `created_at` DATETIME NOT NULL,
  `updated_at` TIMESTAMP(0) NOT NULL DEFAULT 'CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP(0)',
  `remark` VARCHAR(255) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8mb4
COMMENT = '服务信息表\nenv优先级: service<set<host<deploy_unit';


-- -----------------------------------------------------
-- Table `config_server_db`.`t_deploy_unit`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `config_server_db`.`t_deploy_unit` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `set_id` INT NOT NULL,
  `host_id` INT NOT NULL,
  `service_id` INT NULL,
  `git_tag` VARCHAR(45) NOT NULL COMMENT '部署的tag号',
  `image_tag` VARCHAR(45) NULL COMMENT '镜像tag',
  `created_at` DATETIME NOT NULL,
  `updated_at` TIMESTAMP(0) NULL DEFAULT 'CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP(0)',
  `env` VARCHAR(1024) NULL,
  `ports` VARCHAR(45) NULL,
  `volumes` VARCHAR(45) NULL,
  `docker_extras` VARCHAR(1024) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8mb4
COMMENT = '部署单元';


-- -----------------------------------------------------
-- Table `config_server_db`.`t_operation_journal`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `config_server_db`.`t_operation_journal` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `set_id` INT NOT NULL,
  `host_id` INT NOT NULL,
  `service_id` INT NULL,
  `git_tag` VARCHAR(45) NOT NULL COMMENT '部署的tag号',
  `image_tag` VARCHAR(45) NULL COMMENT '镜像tag',
  `yml` TEXT NULL,
  `diff` VARCHAR(4096) NULL COMMENT 'yml diff',
  `op_flag` SMALLINT(2) NOT NULL COMMENT '操作列表,1:升级(update);2:重启(restart);3:停止(stop);4:降级(rollback)',
  `created_at` DATETIME NOT NULL,
  `created_by` VARCHAR(45) NOT NULL COMMENT '操作人',
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8mb4
COMMENT = '部署流水表';


-- -----------------------------------------------------
-- Table `config_server_db`.`t_deploy_unit_status`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `config_server_db`.`t_deploy_unit_status` (
  `id` INT NOT NULL,
  `current_timestamp` VARCHAR(45) NULL,
  `current_yml` VARCHAR(45) NULL,
  `expired` VARCHAR(45) NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8mb4;

版本规划

dapeng-config-server

V1.0 【8月】

  • 服务管理
    • 服务信息(服务名，服务镜像，ENV，VOLUMES，PORTS，composeLabels，dockerExtras)
    • 针对服务基本信息增删改查
  • 环境集管理
    • 环境集信息(环境集名称，当前环境集下的ENV，环境集中针对服务的特有配置)
    • 针对环境集基本信息增删改查
  • 节点管理
    • 节点信息(节点名称，IP地址，所属环境集，是否外部机器，ENV)
    • 针对节点基本信息增删改查
  • 部署单元管理
    • 部署单元信息(发布TAG，所属环境集，所属主机，所属服务，镜像tag，ENV，VOLUMES，PORTS，dockerExtras)
    • 针对部署单元基本信息进行增删改查
  • 上线部署
    • 提供两个视图:服务视图、主机视图(视图数据都来自部署单元，不论哪个视图都具体到某个服务运行在某个节点上)
    • 服务视图显示所有的服务，并在每个服务下展示运行在哪些节点之上
    • 主机视图显示所有的节点，并在每个节点下展示节点上运行的服务
    • 视图展示信息
      • 当前主机运行的服务tag
      • 配置在web中的更新时间
      • 主机上的配置更新时间
      • 服务在主机上的运行状态
      • 服务是否需要更新的状态
    • 预览操作，查看当前的配置合成(docker-compose)的yaml文件内容，并提供与当前主机上的配置diff
    • 提供当前配置下载功能，方便线下查看编辑
    • 升级操作，将合成的yaml文件内容下发至agent并生成yaml文件，执行升级操作
    • 停止操作，停止选定节点的选定服务，不改变配置内容
    • 重启操作，重启选定节点的选定服务，不改变配置内容
    • 针对节点上服务的操作(升级，停止，重启)，提供控制台展示实时日志
  • 部署记录
    • 记录平台管理员每一次操作(升级、停止、重启)
    • 升级操作可以查看发布的yaml文件内容，并提供回滚功能

V2.0 【9月】

  • 升级后可查看容器实时启动日志(docker logs xxx)
  • 提供配置复制功能，可一键复制已有的环境集，服务，减少书写
  • ansi color code terminal
  • 服务启动配置文件入库，由数据库录入内容生成文件
  • 改变现有的服务文件挂载形式，将数据库配置内容生成文件并更新文件(目标是节点上只需要一个agent程序包)
  • 提供配置导入导出
  • 服务数据导出导入
  • 部署单元批量修改tag号
  • 可在部署单元修改容器名
  • 敏感信息(mysql账号密码)加密
  • agent状态列表，可查看agent的运行状态
  • 不共享用户terminal
  • agent-server通讯鉴权
  • 部署视图，加一个：待更新服务视图。
  • 增加审计功能，对每个修改，新增操作记录日志。

V3.0 【10月】

  • 批量升级/重启
  • 查看运行容器ENV
  • ci支持
  • 可进入容器进行操作
  • ssh终端支持(xterm.js)
  • 界面重构
  • k-v型变量支持表单/文本录入
  • 集成sso,功能权限划分

CI构建功能

  • 服务构建分支管理
  • 服务依赖管理
  • 服务构建任务管理
  • 构建服务器管理
  • 一个构建任务，提供当前服务的依赖服务视图，可视化构建依赖树(可批量修改依赖服务分支)
  • 可自定义依赖的服务构建方式(format: gitUrl@@serviceName;shellScript?)：
    • 默认不填写，按照源码文件决定构建方式(如:mvn,sbt,npm) 如***member.git@@member;
    • 指定构建脚本在project.build-depends后添加脚本 如***member.git@@member;sh build.sh
    • 指定构建指令：如***member.git@@member;sbt clean api/compile api/package
  • 新增构建服务器一键生成所有服务的构建任务(默认master分支)
  • 服务构建视图
  • 代码diff审查
  • 可查看指定区间git log
  • 提供构建后的操作脚本选项
服务构建事件格式
1. purchase: source:  branch : purchaseBuildCmd
2. stock:    source:  branch : stockBuildCmd 
3. order:    source:  branch : orderBuildCmd


agentClient: (purxx; stock; orderl)
if (!dir exists) {
  git clone source
}
cd serviceName
git pull
git checkout xxx
purchaseCmd -> sbt api/compile

stock is same with purchase

cd order
git pull
git checkout xxx
orderBuildCmd

附一：文件挂载下发方案

解决容器文件/文件夹挂载，做一个纯净的部署中心

一.如何存储文件和内容，关联服务和主机？

1.将文件与部署单元进行关联，部署单元描述了服务与节点的关系，一个文件可与多个部署单元进行关联

2.文件表包含如下信息：

  • fileName（容器内文件名）
  • fileExtName （容器外文件名）
  • fileContext （文件内容）
  • fileTag（文件内容MD5(16位),描述了宿主机上的文件名）
  • remark (备注 )
  • 通过中间表与部署单元进行关联

3.每当文件内容fileContext变更，fileTag 也会相应变更，将fileName与fileTag作为与之关联的部署单元对应的服务的VOLUMES映射(fileExtName-fileTag:fileName)，如：

./config/fluent-bit-a0b923820dcc509a.conf:/opt/fluent-bit/etc/fluent-bit.conf

（agent端存放文件夹+fileExtName+fileTag+文件后缀，从fileExtName中获得）

4.服务最终的VOLUMES映射都由此关联关系来维护并生成挂载映射

二.如何展示 1.新增文件管理侧边菜单
2.展示文件列表基本信息
3.筛选维度，从未绑定的文件，环境集，服务，节点(可通过部署单元反查服务，环境，节点信息)

文件名 | 宿主机文件名 | 预览内容 | fileTag | 备注 | 操作 ---|---|---|---|---|---|--- /opt/fluent-bit/etc/fluent-bit.conf | fluent-bit.conf | 预览 | 5b1939ca338e310a| fluent-bit配置 | 详情，修改，查看/关联部署单元

三.如何下发文件内容

1.文件内容fileContext变更，对应的fileTag也会相应变更，同时一个服务可能存在多个配置文件，判定一个服务在部署时是否需要更新配置文件，不能按照单个文件的 更新时间戳进行判定。下面列出三种对比更新方案 ：

_.1:因为在初次进入部署页面时会获取yaml时间戳，因此服务对应的多个文件内容一旦变更，时间戳也会相应的变更。将服务对应的各个文件时间戳与返回的时间戳进行对比，可得到需要更新的文件列表。在发出正式的升级更新指令前，会将配置文件先发送至agent进行创建和更新到指定的目录。

_.2第二种方案是，文件fileContext一旦更新，对应的fileTag也会更新，但此时，agent上是不存在此文件的。则将服务的全部配置文件fileTag发送到agent进行询问，返回不存在的文件列表，则是需要更新的文件，在发出正式的升级更新指令前，会将配置文件先发送至agent进行创建和更新到指定的目录。

_.3 第三种是不对比更新状态，统一将关联的最新文件时间加入到服务yml文件的时间戳对比列表中，每次更新服务都会将与之关联的文件和内容一并下发到agent。

Clone this wiki locally