作者介绍

符杰超，熊猫直播基础架构部高级运维开发工程师。主要负责熊猫直播运维自动化架构平台建设和开发

前言

        随着熊猫直播的业务发展越来越快,业务需求的迭代和版本更新需求越来越多,对开发和运维面临以下4个痛点:

• 项目需求上线越来越多

• 发布周期比较长，人工操作比较繁琐

• 发布项目效率和风险的问题,比如平滑发布,切换负载均衡

• 发布过程没有详细的审计功能

       由此,团队内部决定在现有的发布过程上实现开发统一的发布系统平台,实现熊猫直播的运维发布流程化、标准化、自动化为一体的统一发布要求。

       下面围绕整个Rancho发布系统做总结梳理,总共分为9个方面:

• 实现的最终目的

• 用户登陆(发布系统的第一道安全墙)

• 用户权限(发布系统的第二道安全墙)

• 项目权限(发布系统的第三道安全墙)

• 代码发布前台

• 代码发布后台

• 发布过程/结果

• 建立标准的wiki文档

• 小结

Rancho 发布系统流程概述架构图

Rancho 发布系统流程图

Rancho发布系统

实现的最终目的

       随着熊猫直播业务的迅猛发展、项目、产品的需求规模和版本迭代频次是无法预估的。传统的运维支持方式已渐渐无法满足这种工程应用现状。但是如果把发布权利交付到开发人员手里控制，运维安全是比较大的隐患。当2者都无法平衡的时候，利用高效的标准化，自动化体系将2个无法逾越的问题优化结合起来，我们结合了上述问题,实现了内部的发布系统，对于发布系统,实现了2个核心目标，如下: 

• 发布项目统一接入
  在新项目接入平台的第一次起，运维只需要把项目添加上，给对应的开发开放相对应的发布权限，项目接入＋权限都是正常状态下，运维需要做的事情就完成了

• 一键自动发布 开发可以根据自己所拥有的项目发布权限，进行任何时间段的发布，同时发布系统会对用户，发布项目，发布操作，结果做到全方位的记录

目的：
       让研发自助运维

用户登陆(发布系统的第一道安全墙)

       对于发布系统的登陆，我们结合了内部开发的一套SSO系统＋Rancho系统并加了一层白名单策略，有以下3个方面考虑:

• 安全性
  平台登陆安全性，SSO采用统一认证＋MD5算法+Hash算法＋静态系统唯一标识

• 连接
  统一的Session/Cookie允许连接，保持会话，过期，删除由SSO管理

• 双权验证
  假如用户在SSO可以正常登陆，但是在Rancho发布平台没有登陆权限，就是禁止登陆。原因很简单，因为全公司每个人都拥有自己的统一登陆账户，防止有人试探登陆/误操作登陆

用户权限(发布系统的第二道安全墙)

      用户权限,我们分为2类角色：

• 管理员
  具有发布系统超级权限，可以对所有项目/用户进行操作

• 普通用户
  只能看到运维授权的项目，发布、发布详情、查看发布历史、查询，但是不可编辑、更新项目 

项目权限(发布系统的第三道安全墙)

        项目权限设计，我们当时也花很多时间去讨论，最终拟定方案，项目不首先对应用户，而是在用户和项目中间建立一个桥梁，我们命名为项目组 

• 原因
  当多个用户同时去拥有一个项目权限的时候，这个时候要全部用户都要增加到这个项目体系中去

• 如果这样做的问题
  增加繁琐，当项目删除改用户权限/或者用户不再拥有该项目权限，还要精确的删除，否则删除错了，后果很严重，逻辑同时还要对用户和项目，做双层处理操作 

• 解决方案
  用户--项目组--项目

• 方案优点

1. 项目组方便了运维管理，如果没有项目组，一个项目对应的权限用户比较多的话、需要管理员分别的去增加/更新编辑比较繁琐 

2. 系统根据项目组有效控制不同用户之间对应项目的权限隔离发

项目组图例

代码发布前台

       前台用于开发人员进行发布所操作的页面,其中功能包含:

• 发布页面

• 发布tag种类选择

• 发布环境/机器列表选择

       当用户进来某个项目的时候，Rancho 发布系统会同时异步获取该项目所有的环境/主机列表，对用户而言无需任何操作处理。

发布页面

       支持机器单选、多选、全选、临时主机添加等：

发布tag种类

发布tag种类选择如下:

• 开发tag(可测试)

• 线上tag(灰度/线上)

• 其他tag(代表开发/线上 tag 未显示你要发布的 tag，发布人员可以根据 tag号输入，如果 git 库里存在，可以正常发布，如果不存在，用户也可以接收到对应的错误结果)

• 线上/开发tag，Rancho 发布系统会自动实时更新git库前10个最新的tag,供用户选择

tag版本选择页面

tag比对图

用户选择的tag和主干，和最后一次发布tag比对如下：

发布环境/机器列表选择

       对于发布环境我们有自己的一套命名扩展规则，有3种类型：

• 类型一
  根据项目功能服务来命名

• 类型二
  根据发布环境来命名 

• 类型三 

• 前2者整合 

       某个项目命名情况：

• 项目功能服务拆分，包含：crontab、sdk、console、front等

• 项目发布环境拆分，包含：online、beta、gray等

      独立情况/整合情况，如下说明：

• beta环境可以独立的命名 

• beta环境有sdk服务，命名为：sdk_beta 

• beta环境有console，命名为：beta_console

PS：环境命名、细化、拆解，开发人员根据项目功能类型进行自定义，
Rancho自动识别和拆解命名体系

      每个发布环境对应发布的机器,其中一个项目页面如下展示

前台首页图

       用户登陆进来看到的所拥有项目的页面，功能有发布、查看、发布历史、需说明(只有管理员才有展示启用/禁用权限)

启用：代表这个项目是正常运行发布
禁用：可以看作删除，但是我们不作为真正删除，临时迁入回收站，如果哪天这个项目需要启用发布了，我们再打开进行该项目发布

前台发布确认清单

       发布前让发布用户再次确认上线的项目，tag，发布环境，是否重启机器(现有的和临时添加的主机)：

发布清单提交请求

    避免脏数据的方法：

• 程序监控对发布队列是否正常服务检测，并且自动做干预

• 程序监控对数据库/缓存正常服务检测，并且自动做干预

• 程序监控对生成的task_ID是否存在，并且自动做干预

• 程序监控对生成的发布指令做严格的判断，是否为不正确指令，并且自动做出干预

代码发布后台

• 后台项目管理的成功/失败，对整个前台发布起到至关重要的

• 后台操作权限为管理员：一般是指定对应的运维人员

• 操作程度:简单、易用，所有处理逻辑都交给Rancho去搞定

后台操作新项目流程页面

新建字段说明

名称：

代表项目的主名称(唯一，如果重复则提示错误详情)，别名代表项目的描述，可以是中文/英文，名称可以重复

git clone url地址:
开发提供，这个地址Rancho在处理的过程中，会对本身项目权限，该项目类型标识进行判断和提取，比如我们有2种功能发布：rigger和ansible，而发布语言有：golang、php、nodejs、python、lua、c++等多种混合语言，排名不分先后

项目组权限:
添加该项目允许哪些项目组成员进行发布

备注:

可写/可不写

      至此，运维管理员需要做的事情已经完成，剩下的点击提交，剩下的事情交给Rancho去处理了。

后台新建页面

Rancho底层基本处理流程

项目失败手动触发 Rancho 处理恢复流程

发布过程/结果

    前期的工作：
           后台新建项目完成，到发布提交申请，最后查看发布过程/结果的验证

   某一个项目单次发布127台主机，用时3分32秒，截图如下:

发布过程的处理流程概述和原理图例展示

发布过程有3种场景：

• 负载均衡四/七层策略

• 无负载均衡策略

• 项目服务是否重启

针对以上3种场景，分别作了不同的处理规则:

• 负载均衡场景
  有白名单策略代表该项目拥有负载均衡策略(至于挂了多少负载均衡节点在发布的时候，Rancho发布系统会自动的计算，并且做相对应的平滑策略切换)

• 无负载均衡策略
  走正常的发布流程

• 项目服务发布是否重启
  (Rancho支持重启项目服务/支持不重启项目服务)需求描述：

1. 项目发布更新，但是不重启服务，看下项目代码发布过程是否成功/失败。(这点对于发布项目业务正常运行不会出现有损情况)
   

2. 项目发布更新,重启服务(项目发布代码完成,自动重启项目服务)

发布速度:无负载均衡策略项目相对于比有LB策略的项目快2ms-30ms,根据项目绑定的LB有关联。

项目发布锁图例展现

       发布锁作用：
               防止同项目同发布环境多任务一起发布，会有覆盖，冲突

项目发布历史统计图例展现

状态分为： 

• 正在发布

• 触发失败

• 发布成功

项目发布手工终止图例展现

发布结果成功图例展现

发布结果失败/终止图例展现

      失败单台，未执行的机器程序自动干预停止发布实例子 

发布过程中，手工可以终止发布功能，说明

• 防止发布过程中有未知的原因或长时间缓慢/卡顿等，发布人员可以根据业务重要评估，进行降级发布过程停止操作，并且系统会把操作用户、时间、项目、降级操作等做详细记录

• 正常发布完成后，终止发布按钮功能会自动消失

下面截图所示

项目回滚策略

       当某个项目发布失败或者异常，想回滚到上个正常版本，可以以对应的tag号来进行重新发布

发布结果日志截图展现

        自动按天生成日志,并且按天做发布日志全量汇总

建立完善的Wiki文档

       Rancho发布系统在熊猫直播循序渐进的优化功能/需求、bug修复等、wiki文档的规范化也要随之建立起来。

       以下是wiki文档建立的图例：

小结

Rancho发布系统已经在线上运行了将近5个月的时间，目前 Rancho系统功能包含了：

• 项目建立

• 用户登陆权限严格的隔离

• 项目锁机制

• 项目前台

• 项目后台

• LB 4/7层和 Nginx upstream 白名单策略

• 平滑摘取/绑定主机

• 支持Rigger发布功能和Ansible发布功能

• 多语言混合并行发布(Golang、PHP、Nodejs、C++、Lua、Python、Shell等，语言排名不分先后)

• 异步实时处理发布任务

• 实时可视化展现发布结果

• 多环境发布

• 跨多机房发布

• 手工/自动干预终止发布

• 避免严重的错误影响到正常业务

• 详细的发布操作记录：
  用户操作、时间、发布环境、发布tag、发布主机成功次数统计、发布主机失败次数统计、发布主机程序自动干预终止次数统计、发布主机手工干预终止次数统计、发布主机正在发布中次数统计等

目前熊猫直播Rancho发布系统解决的痛点：

• 研发自助运维
  熊猫直播产品业务线的发布更新/回滚变更等操作，都由各自的项目线开发人员操作发布/回滚，运维不直接参与整个发布/回滚流程，遇到发布错误/异常，运维才介入和开发一起排查相关问题 

• 发布时间周期长
  目前发布系统异步处理整个发布流程，点击发布提交之后，页面关闭都可以，发布人员想看结果的时候，才登陆系统查看即可 

• 平滑切换负载均衡
  发布系统增加了白名单策略，发布项目上线前，Rancho发布系统会自动判断白名单策略项目，如果该项目存在白名单策略，Rancho发布系统会自动做整个负载均衡下线—上线—绑定上线流程操作

• 发布系统详细的审计功能
  从用户登陆－创建发布清单－点击发布－发布过程-发布结果都做了详细的记录，记录纬度：登陆时间、发布起始时间、发布完成时间、用户、发布环境、发布项目(平滑，服务是否重启，tag，主机数量，主机信息清单)，发布结果(成功、失败、终止)等

目前发布次数/项目总数统计

       2017年2月16日上线到目前，累计发布工单12000次，最多单次工单发布主机100台+，成功96%，失败3%，终止1%，接入发布项目将近100+。

Rancho发布系统未来优化

       Rancho发布系统未来优化的路还有很多，优化方向分为以下3点：

• 接入发布预警平台
  当某个项目出现异常的时候，运维能及时收到短信/邮件的提示

• 定时作业发布
  可以按照用户自定义的发布时间，定时发布代码 

• 发布错误/异常自动修复
  目前Rancho发布系统已经可以收集到全部错误发布类型，但是真正修复还需人工，以后当错误出现了，自动上报到修复库里进行存档，在下一次同样错误出现的时候，Rancho自动修复，并优雅提示用户发布错误修复完成，请重新发布

本文出自 “IMySQL” 博客，请务必保留此出处http://jiechao2012.blog.51cto.com/3251753/1945787

熊猫直播Rancho发布系统构建之路