腾讯云 DevOps 技术揭秘：新时代运维重器 Tencent Hub 最佳实践

随着云计算和容器技术的发展以及微服务架构的兴起，服务能够实现细粒度的部署，维护和伸缩。在使开发人员能快速开发的同时，这些技术也给系统和应用的运维带来了更大的挑战。DevOps 理念也应运而生，强调研发和运维的流程及工具的自动化，最大程度地减少人工运维的工作量。

在上周腾讯“云 + 未来”峰会的开发者专场上，来自腾讯云的几位开发者和大家分享了 DevOps，数据库，微服务框架，边缘计算，机器学习等话题的实践，为大家带来了一场技术盛宴。在这里和大家一起分享腾讯云 PaaS 产品总监邹辉带来的 Tencent Hub 最佳实践，一窥腾讯云 DevOps 产品的设计理念和思考。

为什么要做 DevOps& 如何做 DevOps

从技术的角度来看，随着业务的发展，业务的场景越来越多也越来越复杂，系统架构越来越庞大，开发人员越来越多，对系统的稳定性要求也会越来越高。所以这些场景催生了技术架构的变革，由此会带来微服务架构设计理念的产生。微服务架构设计理念能够解决这些问题，但同时也带来了很多问题：微服务导致我们的系统模块越来越多，而这些模块运维管理复杂度也会增加，同时微服务会让我们的开发速度得到增加，开发人员对我们发布的效率会有明显的诉求。所以在运维人员对系统的质量把控，以及开发人员对系统效率的追求上就有了矛盾，这就是 DevOps 需要解决的一些问题，由此催生了我们 DevOps。

所以 DevOps 的实质是：我们需要通过 DevOps 来保证质量，同时，平衡开发的效率。本质上来说 DevOps 就是一个流程化和工具化的过程，通过工具来固化流程，通过流程来保证运维发布和研发质量，同时降低人工进行操作时候的一些误操作引发的故障，也提高了整个研发的效率。所以基于这一点，如何去实现我们的 DevOps，实际上非常清晰，因为 DevOps 就是一个流程规范制定和工具化的自动化过程。所以要做好 DevOps，我觉得关键在于两步：

1. 把我们的流程梳理清楚，这些流程包括代码提交、发布测试，静态扫描等等。另外我们也需要把团队的关系梳理清楚，软件开发过程中有开发，有测试，有运维，还有一些管理者，需要哪些步骤，需要哪些人审核，在哪些步骤需要通知哪些人，都要梳理清楚。
2. 通过工具化把上面所梳理的流程实现自动化的过程。如何去选择合适的 DevOps 工具体系，把流程规范给自动化起来。

接下来就给大家分享腾讯云在DevOps 工具体系这方面的实践。

Tencent Hub

腾讯云 DevOps 推出了一款叫 Tencent Hub 的管理平台，该平台为存储研发流程中的文件和代码以及创建 DevOps 工作流而打造。Tencent Hub 是腾讯云第一款涵盖了 DevOps 整个体系的工具体系，主要分成三部分，覆盖代码的开发阶段，构建阶段，一直到代码的发布阶段。

Tgait 代码仓库

在代码开发阶段，我们可以提供 TAPD 的开发平台，同时我们也推出了一个 Tgait 的代码仓库。基于这个构建组件，我们可以很方便地把整个 DevOps 流程给串起来，同时也提供了一个全面的仓库。在这个仓库里面，我们可以存储任何的代码，DevOps 任何的存储，最终我们也会跟运行环境里面的一些服务打通，来支持各种发布，提供各种各样的查检。腾讯云在 Tencent Hub 整体的体系图如下。

Work Flow

在CD 的环节，我们有一个核心组件叫Work Flow，大家可以把它简单理解为一个工厂的流水线，通过这个流水线，我们可以把DevOps 开发、测试、发布、代码自动测试等所有的环节很简单地串联起来。因为不同的公司研发流程不一样，并且随着业务的发展，流程可能也会不断地变更，所以我们在设计Work Flow 这款组件的时候，一个核心考量就是能否快速地适应多样化的流程体系和流程的变更。

我们在设计Work Flow 的时候，把Work Flow 分成了三块：一个是Engine 的环境，一个是插件层，还有一个是Work Flow 的插件库，主要是管理调度功能，真正实现任务执行是在下面Work Flow 的插件去实现这个功能。

在Work Flow Engine 这一层也是分成多个阶段。我们将一个DevOps 完整阶段拆分成多个不同的阶段，可以串行执行，也可以并行执行。我们可以定义任何DevOps 的流程，同时在执行过程中，可以暂停这个stage，也可以启动这个stage；在完成以后，能根据反馈结果来定义这个流程是该继续走下去还是该终止。当我们把代码构建完成之后发布到自动化测试系统中做测试，发现某个自动化测试用例跑不过，这个时候我们可以设计一个终止的环节，然后把这个系统结果给到开发运维人员，或者测试人员。这时候Work Flow Engine 同时也写好YAML 文件，把完整的流程导入到Engine 里面执行。这就是在Engine 这一侧我们去做的一些设计和思考。

在Work Flow 插件这一层，Engine 可以通过API 调动任务，Engine 层可以执行指定的一个任务，实际上以容器镜像的方式定义和运行这个插件，这也是我们在Work Flow 做的一个比较大的革新。为什么这样说？因为我们发现把容器引入到DevOps 里面去做会带来很多的好处：首先DevOps 流程里面会执行各种各样的任务，如果把这个任务通过容器化固化下来，通过容器镜像可以很方便地传播，这个时候大家看的可能不是跟Engine 相关的插件，而是一个容器镜像。一旦把插件分装到容器里面之后，就可以根据大家的喜好和专业程度去开发容器。这就是我们在Work Flow 插件这一块实现的机制。

另外，如果用户想要自定义自己的插件，完成一些功能，也只需要定义好简单的输入和输出即可。输入值可以从前面任何流程获取，制定本质的输出参数，输出参数也可以反馈回来，供后面的流程使用。用户也可以很简单地去遵守这个输入和输出的规范，开发自己的镜像插件。

另外，我们也针对一些常见的语言库和流程提供一些通用的插件库，比如里面的代码检查、构建，这些镜像可以统统在这一层获取到。这就是我们在Work Flow 这里面的一些设计理念。

Registry

除了 Work Flow 之外，我们还构建了一个 Registry。我们发现在 Work Flow 会产生很多中间产物，比如构建一个 Zaar 程序，或者发布一些配置文件，这些配置文件发布在哪些地方，包括发布机制，它存在的地方或者最终镜像存在的地方，这些环节中产生的中间产物往往会存储到不同的地方，使用不同的协议去获取。基于这一点，我们开发了一个叫 Registry 的通用仓库，可以实现通用存储，使用这个通用存储可以很方便的把 DevOps 里面中间产物给管理起来。

另外 Registry 也提供了多层管理机制，从组织到用户团队到个人，通过权限的方式去统计，也提供各种各样的日记，静态扫描的功能，让用户能够更方便地使用这些 Registry 功能。以上就是 Registry 方面的设计和考量。

最后

除此之外，其实腾讯云还会把内部的一些研发实践，通过服务的方式分装起来给开发者，让开发者不光可以使用 Work Flow，使用既定插件，同时还可以使用腾讯内部一些比较好的经验，更好的去支撑他们的 DevOps，比如自动化运维、代码托管、自动化测试等环节。