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

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

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

为什么要做DevOps\u0026amp;如何做DevOps

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

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

把我们的流程梳理清楚，这些流程包括代码提交、发布测试，静态扫描等等。另外我们也需要把团队的关系梳理清楚，软件开发过程中有开发，有测试，有运维，还有一些管理者，需要哪些步骤，需要哪些人审核，在哪些步骤需要通知哪些人，都要梳理清楚。\\t
通过工具化把上面所梳理的流程实现自动化的过程。如何去选择合适的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方面的设计和考量。