房多多一站式自动化发布系统

随着容器技术的发展以及微服务架构的推进，应用的迭代越发频繁，传统的应用部署流程无法有效应对房多多整个研发团队每日大量的构建以及发布需求。研发团队迫切希望代码构建、容器镜像打包、应用部署等一系列CI/CD流程能够统一起来并自动化执行，提升应用的迭代速度。因此，运维团队在不断优化完善原有的自动化发布工具后推出集项目管理、机器管理、CI/CD于一体的自动化发布系统，规范了工作流程的同时极大提高了研发团队的工作效率。

发布系统生态组成

房多多发布系统生态大致可划分为三大部分：

发布系统核心服务架构

发布系统项目采用常见的前后端分离架构，前后端数据通过JSON进行交互。

发布系统前端项目：采用轻量级的Vue框架，充分利用了其组件化的特性整合各页面模块，同时加入Vue-router插件实现页面的无跳转切换，为用户提供便捷的项目管理、构建版本管理、测试用例、部署回滚等功能。

发布系统后端项目：基于Python开发，包含Web Server和Worker两个组件。

由于研发人员每天大量的构建与发布操作均需要耗费相对较长的时间，因此发布系统后端引入了基于Python的Celery分布式任务调度模块，使用Redis作为消息服务，而Web Server和Worker分别作为Provider和Consumer。

• 后端的Web Server负责接收来自于发布系统前端的请求，该Web Server使用Flask Web框架，同时配合高性能WSGI HTTP服务器Gunicorn来应对高并发的场景。当后端Web Server接收到来自前端的请求并解析后，将异步任务下发到Redis中；
• 后端的Worker负责监视任务队列，执行分配到的任务，并将执行过程反馈到前端页面，此过程后端Web Server未被阻塞，可不断接收来自发布系统前端的请求。

发布系统后端相关组件均部署在容器集群内部，不管是Web Server、Worker还是消息队列，都可以进行横向扩展，满足研发团队大量并发的构建/发布需求。

Teamcode/Jenkins

房多多团队所使用的Teamcode代码仓库基于开源软件Gerrit，负责源代码的存储以及版本控制，同时提供代码审核，从而为CI服务器Jenkins提供合格的“原材料”，而“原材料”在Jenkins中经过一系列的“加工”后得到的产物将存放到特定的“仓库”中。

持续构建作为发布系统生态中最基础的一环，如何让发布系统核心组件，Teamcode代码仓库、CI服务器Jenkins协同工作至关重要：

• 发布系统与Teamcode间的联动依赖独立组件Teamcode-trigger，该组件会启动守护进程持续监听Teamcode仓库的提交事件，当侦听到代码仓库有新的提交后，会调用发布系统后端Web Server提供的webhook，从而向后端Worker下达构建请求；
• 后端Worker则通过Python的Jenkins库与Jenkins服务器进行通讯，后端接收到构建请求后，会将用户在发布系统前端创建项目时填写的信息作为参数向Jenkins发起调用，完成流水线的创建与执行，经过编译构建后的产物将存放到容器镜像仓库或者其他临时仓库中，从而完成持续构建的过程；
• 为实现不同用户的构建需求，运维团队在构建流程中引入了Jenkins Pipeline，在此基础上预设不同的DSL模板，让用户可在发布系统前端自行选择合适的模板，同时也支持对选择后的模板进行自定义修改，最终生成的流水线配置会保存到发布系统数据库中，供后端调用Jenkins时使用。为了兼容使用“参数化构建模板”的服务，发布系统 则通过独立组件Build-service向该部分没有配置DSL模板的服务提供默认的构建模板。

目标机器/集群

得益于房多多容器化的推进，房多多绝大部分服务均已容器化，因此目标集群主要指容器集群，而容器集群滚动更新的机制，也能让持续部署的过程变得更加平滑。

发布系统与容器集群的通讯主要通过“中介”来进行，而服务部署所需的容器镜像则来源于Jenkins构建的产物，这种松耦合的方式让发布系统能更加灵活地对接不同的集群，而目前对接的容器集群有Docker Swarm以及Kubernetes：

• Swarm集群使用开源软件Portainer进行管理，并向发布系统提供Restful API接口，发布系统则利用该“中介”完成服务的部署、更新、删除等操作；
• Kubernetes集群与发布系统对接的中介，则是房多多运维团队通过对Kubernetes核心代码中的Client-go包进行二次开发后得到的RESTful服务。Client-go作为官方编程式交互客户端库，在Kubernetes系统中做了大量的优化，在其基础上封装的应用与Kubernetes API Server进行交互能极大提高性能，Kubernetes控制平面中的核心组件均通过Client-go包与API Server进行通讯。Client-go包内部实现了进程内缓存以及队列，能将Kubernetes内部对象缓存起来直接对外提供服务，大大减轻API Server的压力。运维团队在Client-go基础上开发的应用，需通过JWT的方式进行访问，支持Kubernetes API对象的部署，更新，删除，容器日志查看等操作，而部署所需的Yaml配置文件则可通过Consul获取，也支持通过Websocket的方式对外提供容器终端连接的功能；

Client-go封装后的RESTful服务以容器的方式部署，无状态，可横向扩展

在实际的使用过程中，用户无须关心背后的容器集群Swarm还是Kubernetes，用户只需在代码完成构建后通过发布系统前端执行发布操作，将服务部署到实际的容器环境当中，即可在发布系统前端对正常运行的容器进行维护或根据异常容器的日志输出进行故障排查。

发布系统功能特性

用户可在发布系统上创建项目，并将项目绑定到某个Git仓库。

用户最初只允许访问自己创建的项目，用户可在发布系统申请项目权限。

新项目最初无目标机器的部署权限，用户需在发布系统申请所需机器。

发布系统记录用户构建过的版本，用户可回滚到任意版本。

用户在完成应用的部署后可根据需求选择合适的测试用例进行服务的可用性测试。

用户可在直接发布系统维护已启动的服务，包括查看日志、终端操作以及健康检查配置等。

发布系统目前支持后端RESTful以及Dubbo服务的灰度发布。发布系统通过调整服务网格的流量比例来达到RESTful服务的灰度发布需求，而Dubbo服务的灰度则由后端服务实现，发布系统在发布Dubbo灰度服务时向应用注入灰度标志。

发布系统实际工作流程

期望效果：

• 开发人员将代码提交至代码仓库的动作能自动触发编译构建；
• 开发人员能够跟踪代码构建的过程；
• 构建后的产物统一存放到“仓库”中；
• 开发人员可以选择将应用部署到不同环境不同机器上；
• 部署过程无须运维人员或其他人员介入，且能实时反馈部署过程；
• 部署完成后开发人员可在页面上对应用进行维护；

为完成上述需求，发布系统进行了以下几项自动化流程：

• 步骤1：开发人员在发布系统前端根据需求创建好项目后， 发布系统后端会根据项目信息创建代码仓库，开发人员还可以自身需求选择合适的构建模板， 而后相关信息都会被记录到数据库中；
• 步骤2：teamcode trigger负责监听代码仓库的变动，当监听到开发人员将代码提交至对应代码仓库后，会向发布系统后端发送构建指令，触发Jenkins的构建；
• 步骤3：Jenkins会根据构建模板创建不同的任务，并执行对应的构建流程；
• 步骤4：在构建过程中，发布系统后端不断检查构建进度，并将最终的构建结果反馈到前端页面；
• 步骤5：当构建完成后， 开发人员可以通过发布系统前端在其权限范围内进行服务的部署，同时可以在发布系统前端查看部署进度；
• 步骤6：当服务完成部署后， 开发人员可以通过发布系统前端查看服务的运行状态、日志以及进入容器终端等操作；

完整流程如下图所示：

目前房多多的发布系统已能为研发和运维带来极大的便利，但随着技术的不断演进以及新工具层出不穷，发布系统还可以带来更多的可能性，未来的CI/CD流程将更加人性化、智能化，运维团队会保持发布系统的持续优化，下一步将会结合更多的云原生技术，为整个研发团队提供更合理、更方便快捷的自动化CI/CD系统。

原文链接：https://mp.weixin.qq.com/s/R0DghGCuYmpyGRp-SrIVcw