作者介绍
谷自强,洋码头高级运维开发工程师
负责洋码头的发布系统、CMDB、监控告警系统的开发和维护
本文约2400字,可参阅下面的大纲阅读。
项目需求
设计思路
技术选型
系统架构
功能特点
总结
项目需求
结合洋码头的业务特点和现状,我们的自动化发布系统需要满足以下需求:
支持各种语言代码发布(IIS、Java、Nodejs、Python、Windows Service)等
同时支持Windows和Linux系统
支持单台发布、一键发布、灰度发布、扩容发布、回滚发布等多种发布要求
支持多机房和云端部署
流程可定制且便于修改
支持RBAC权限管理
支持发布版本历史记录回溯
设计思路
整体采用微服务架构的思想,避免高度耦合,也便于以后扩展
每个应用只需要维护自身的业务逻辑
每个应用提供标准的、符合RESTful规范的API接口
统一使用JSON数据格式进行传输
尽量选用能够跨平台支持的运维工具
技术选型
| Python
采用Python作为主要的开发语言,因为Python简单易用强大,开发周期短(短,平,快),跨平台,而且几乎所有Linux系统都内置Python解释器,第三方模块多如牛毛; 更重要的是洋码头已有很多运维脚本和工具是用Python写的,平台可以很容易也很方便地对其进行整合。
| Django
Python的web框架非常多,常用的有Django、Flask、Tornado、Pylons、Webpy、Bottle、Sanic等等,这里我们为了能快速开发,省心省力而选用了Django,结合第三方神器django-rest-framework能够轻松的自动生成符合RESTful规范的API。
| SaltStack
运维自动化工具也有很多,如Ansible、Bcfg2、Puppet、SaltStack等等,为了能够支持Windows系统,我们选用SaltStack作为我们的底层工具。
| Celery
任务调度利器Celery是Python开发的分布式任务调度模块,通过它可以轻松的实现任务的异步处理。因为发布是一个非常耗时的过程,只需要将任务丢给Celery,然后该干嘛干嘛去,最后任务执行完成后告知用户执行结果即可。
系统架构
发布系统架构图
| Jira
Jira系统用于控制发布流程。我们利用Jira Workflow定制了工作流并通过用户Group和Role进行权限控制。开发提交发布任务申请、开发leader审批、测试通过SIT测试...,开发、测试可以在Jira上完成从SIT到PROD发布的整个流程,且所有操作均有据可查。
| WebUI
WebUI允许用户创建发布任务,并提供比Jira系统更加详细的数据展示,便于开发、测试、运维进行一站式监控、跟踪及问题处理。
| CMDB
CMDB为发布系统提供数据支撑,如应用的基本信息,部署环境信息等等都从CMDB中获取。
| 配置管理中心
配置管理中心负责保存各个应用的配置信息,如数据库用户名和密码等敏感信息,在发布时,负责将配置打包并上传到FTP服务器中。
| FTP
FTP用于存放产物包和配置包。发布系统通过调用Saltstack脚本从FTP中获取对应的产物包进行发布。
| Dispatch
Dispatch负责将任务下发,以及对salt-key和服务器IP地址做映射管理,当有发布任务时,调用Saltstack执行发布脚本。
| 发布系统
发布系统用于把产物包发布到Stage和PROD环境。下面描述其核心运作逻辑:
洋码头目前有4套部署环境: SIT、UAT、Stage、PROD。SIT和UAT环境由测试人员通过Jenkins部署,我们的发布系统负责Stage环境和PROD环境部署。UAT环境测试通过后,测试人员通过Jenkins将UAT的产物打成zip包上传到FTP中,发布系统驱动配置管理中心将配置文件也打成zip包上传到FTP中;发布系统在Stage发布时从FTP中下载产物包和配置包,并在Stage发布成功后再将产物包和配置包合并打包成一个zip包上传到FTP中供PROD发布。
为了支持各种语言代码发布(IIS、Java、Nodejs、Python、Windows Service等),我们分别对每种应用类型编写Salt模块或脚本。 发布系统通过任务类型来区分调用哪个模块执行脚本,例如发布IIS应用调用PowerShell脚本执行,发布Java、Python、Nodejs、Static等应用调用与之对应的Salt自定义模块执行。
采用通用化的启动脚本以减轻维护成本。若有需要,也可以按照一定要求自定义启动脚本。发布时会优先到指定路径下寻找自定义的启动脚本,否则将采用通用启动脚本运行。
应用发布新版本后会在本地保留历史版本的产物包,用于支持版本快速回滚,而不用再从FTP下载产物包。
功能特点
发布系统具有如下功能特点。
简单的任务创建过程
开发人员或者运维人员创建任务时只需要填写任务类型(环境)、应用名称、版本号即可,服务端收到创建任务请求后,到CMDB中查询这个应用的一些基本信息,便能知道该应用在什么环境下有哪些机器,应用的启动的端口,应用的类型(Nodejs还是Java或者IIS等),根据这些信息创建发布任务。
WebUI创建任务界面
Jira界面
可视化的任务执行过程
通过自动化发布系统的WebUI界面,我们可以很清楚的看到发布任务执行状态、进度、耗时、日志等信息。同时为了提高用户体验,我们在发布的时候会对应用进行点火和健康检测,确认应用发布上线后正常可用。
Stage发布可视化状态截图
PROD发布可视化状态截图
支持一键发布&灰度发布双模式
所谓的一键发布是指将所有机器并行的进行部署,能提高发布速度,但如果发布失败可能会导致整个应用业务不可用;而灰度发布能保证发布时不影响到业务,但发布速度相对一键发布要慢一些。开发同学可以根据自己的需要选择合适的发布方式。
支持快速扩容和回滚
支持快速扩容发布,发布系统能自动从CMDB资源池中根据应用的类型挑选合适的机器,进行扩容发布。
当发布出现异常时,能够直接从本地获取上一版本或者指定版本进行版本回滚。
支持多机房和云端部署
我们将云主机当成普通的虚拟机,并自动同步到CMDB中,系统环境保持和IDC机房的机器一样,网络也与IDC机房互联互通,发布系统便能在多个机房和云端进行部署。
严格的权限控制
在运维管理中,对权限的控制显得尤为重要,在发布代码时,对应用进行权限隔离,只有与该应用相关的人员或者同属于一个项目组的人员才能进行发布,否则无权进行发布操作。
通过django-guardian插件,能够很轻松的实现对象级的权限管控,具体可到官网查看使用方式
清晰的发布版本历史记录回溯
每次发布成功后,将发布版本记录在CMDB中,并提供查询入口,这样可以清楚的查看该应用在哪些机房部署过哪些版本、当前的版本号等信息。
支持容器化部署
随着容器技术的成熟,我们部署了一套Kubernetes集群,发布系统可以通过调用k8s-api接口实现Docker化的部署。具体实现方式如下: 对于需要上Docker的应用,首先将代码包打成镜像push到Harbor仓库,然后在CMDB中做好标记。在发布时,发布系统会根据CMDB中应用的标记来决定采用VM的方式部署还是Docker部署,或者VM和Docker一起部署。
总结
到目前为止,这套发布平台已经平稳运行了两年多,周发布量近1000次,而且最重要的是现在基本不需要运维人员进行发布操作,解放了运维的双手,减轻了运维的工作压力,大大提高了运维的工作效率。
全文完
近期分享预告:
洋码头搜索应用架构
洋码头推荐系统架构
洋码头数据仓库建设实践
每周我们都会推送一篇由洋码头一线工程师写的技术分享。关注【洋码头技术】,第一时间获取我们最新的技术分享推送吧。
领取专属 10元无门槛券
私享最新 技术干货