Skip to content

新发布脚本方案

新发布脚本方案

修改日志

-----------2018-8-23 17：10-------------
1. 不在灰度期间发布一个项目到所有机器，只在预全量阶段把其他机器的项目启动起来，让灰度用户轮询的在上面验证流量。
2. 灰度和bug单独放到一台机器上面，方便维护和查找问题
3. 微服务灰度方案，改成按照先匹配group，再匹配版本的方式

-----------2018-8-27 17：50-------------
1. 沿用上面的1、2条
2. 微服务灰度方案，按照接口新增版本的方式来升级版本，灰度统一走group

脚本发布阶段

  1. gray 单机测试发布灰度（再单独用来发布灰度的机器上面发布）
  2. gray 单机测试重新发布灰度
  3. prepare 预全量（测完了，准备灰度真实用户，在其他机器上面启动项目，轮询切换灰度group到机器上面验证,1天待定）
  4. prepare 预全量（重新发布）
  5. release 全量（1天后在所有机器上面切量）
  6. complete 切模板

微服务发布策略

微服务灰度采用安装group来灰度的策略，默认是版本兼容的，当微服务的接口版本不兼容了，就需要另开一个接口（带版本的），灰度测试就是station和微服务的nginx配置相同的group来灰度测试，全量先全微服务，在全station
需要先做的工作：
    rmiclient修改 参数可以传入版本
注意：开发不兼容版本的，需要人工处理一下接口上的版本

微服务不同版本的规则

当前：/order/create
新增不兼容的接口：/order/create/v1

实现目标

1. bshop, 统一group灰度, 否则不能和微服务一起灰度，只能升级版本
2. 微服务灰度，eg：order, merchandise
3. 多模板支持
4. nginx实现 固定流量到单独机器
5. 实现全量其他机器的功能。
6. 记录脚本运行中日志
7. 取消灰度功能

bshop, 统一group灰度

目前存在的问题是，一个cms_key对应多个group，这些数据如果实在不能修改，那可以在bshop代码里面设置group的时候检查，如果这个cms_key存在多个group_id，那么就把这些group_id设置成特定的值，如-999，然后脚本里面灰度bshop的时候判断这些group不能灰度，就可以了。

从目前老灰度转移到新灰度

只需要在work3上配置一个新的nginx，配置灰度信息，添加一个机器启动项目用来测试，测试完，修改负载均衡指向这个nginx，用新的发布脚本跑灰度就可以了。微服务nginx配置不用动。

存储设计

gmdeploy_info mongo

id
publish_id          str             eg:发布id，关联微服务和station等项目的关系id
publish_topic       str             eg:station,manage，order等
back_branch         list            灰度后台分支
gray_group          list            各项目灰度的group
status              int             -1:delete, 1:verify, 5:gray, 10:release, 15:complete 
front_template      list            前端模板
running_info        list            运行机器端口
create_user         str             创建人
desc                str             简单描述，默认提取git log里最新一条的备注，也可人工填写
create_time
modify_time

灰度发布

gmdeploy gray 
-u  M   wrd 
-g  O   123 
-id O   gmdeploy_id_12345678    # 所发项目统一id

灰度思路：
    在单独灰度机器上面 新增灰度，方便维护和查找问题
    灰度分支在灰度中填写
发布逻辑（做到可重复发布）
  • 获取文件锁
  • 检查所有 参数、输入信息是否正确
  • -id，获取上次填写的信息，打开编辑
  • 填写灰度信息、描述、前端模板信息
  • 检查填写信息
  • 根据配置，循环一下操作
    • 跳转到单独部署机器
    • 检查是否已存在灰度分支项目
    • 不存在，创建项目
    • 是station ，根据输入的模板信息修改软连接
    • 启动服务，需设计微服务接口和station等检查接口，根据项目对应检查
    • 启动成功，否则 解锁退出
    • 返回对应的nginx，修改nginx配置
    • nginx重启
    • 信息存数据库
  • 后续多个nginx服务，需要同步配置到另外一台
  • 保存相关信息到数据库
  • 发钉钉
  • 检测项目是否全部都发布完成，是就解锁，否则提示命令

预全量（做到可重复发布）

gmdeploy prepare
-u  M   wrd 
-g  O   123 
-id M   gmdeploy_id_12345678    # 所发项目统一id
预全量逻辑
  • 获取预全量锁
  • 检查所有 参数、输入信息是否正确
  • -id，获取上次填写的信息，打开编辑
  • 判断代码是否是最新的，是否打成一个节点等
  • 填写是否修改配置，否则按照前面灰度的配置运行
  • 填写灰度信息、描述、前端模板信息
  • 检查填写信息
  • 获取所有机器组，循环下面操作
    • 获取所需部署的项目，循环下面操作
      • 跳转到对应的项目机器
      • 部署项目，启动，测试接口
      • 修改nginx，配置灰度的group轮询走到所有灰度机器组
      • 添加完成一台机器的记录到数据库
  • 不解除锁，等下面的全量命令后解锁。
  • 保存信息到数据库
  • 同步nginx信息到其他nginx上面
  • 发钉钉

全量其他机器

gmdeploy release 
-u  M   wrd 
-id M   gmdeploy_id_12345678    # 所发项目统一id
全量其他机器逻辑
  • 检查所有 参数、输入信息是否正确
  • 检查项目是否在预全量阶段
  • 到nginx分发机器，修改nginx配置，配置预全量的信息成master分支
  • 同步nginx信息到其他nginx上面
  • 解锁
  • 发钉钉，解锁退出

切模板

基本逻辑不变

取消灰度

gmdeploy cancel 
-p  M   station或者微服务等 
-b  M   fix_s 
-u  M   wrd
  • 获取文件锁
  • 检查所有 参数、输入信息是否正确
  • 判断是正在灰度的项目，还是预全量的灰度，循环以下操作
  • 跳转到查出来的机器上面，stop掉项目
  • 跳转到nginx转发机器。修改配置
  • 重启nginx
  • 解锁

添加detail命令

list，命令只用来展示简单的版本信息
detail展示详细信息
总结
以下是事情完成顺序：
    1.  bshop统一group灰度                  预计开发：8月29号完成
    2.  rmiclient能传入版本号，修改微服务url    预计开发：8月29号完成
    3.  开始编写脚本          预计开发：8月30号到9月14号 （12天）