Docker镜像安全扫描

在Docker镜像的存储完成之后，我们还是提供了一个Docker镜像的静态扫描。它通过对比Docker镜像包里所包含的软件列表版本和漏洞数据库里面漏洞对应的软件版本，得出一个差异，通过这个差异计算出当前Docker镜像里面可能会存在的漏洞风险。

Scanner服务是扫描的中心服务，我们借鉴了CoreOS的Claire来实现的，它会周期性地和几大发行版的漏洞数据库进行同步。Docker镜像上传完成之后，就会提交到扫描中心，逐个分析它的每个Layer，把每个Layer取出来，看里面的软件版本。当漏洞被发现的时候，Scanner发起一个通知，最终通知到前端的Registry服务，用户可以通过webhook拿到这个消息。因为扫描只能获得已知的漏洞，针对一些0day漏洞是没有办法的，当新漏洞被曝光出来之后，可能各大发行商会跟进，然后更新他们的漏洞数据库，已经完成扫描的Docker镜像就需要再去做对比，这个时候就需要我们开发人员比较小心，留意是否有影响到自己的漏洞。

前面基于Docker仓库关于镜像存储方面的分享，也是TencentHub镜像仓库里面最复杂的部分，关于artifact和heml chart这样的文件存储，我们就不做过多的实现，因为它的实现都类似。

workflow引擎设计与实现

如何设计一个通用的DevOps型解决方案？

我们为什么要去做一个TencentHub的DevOps引擎呢？因为我们发现很多客户在上云的时候，平时遇到非常多重复性的操作工作，例如在腾讯云UI上面做很多事情，没办法自动化或者腾讯云的API还不够好用等等各种问题。其实DevOps的自动化要求是很高的，我们不能加入大量的人工去操作，基于这个考虑，同时还要照顾到中长尾客户的一些需求，我们最终决定要做一个DevOps的工具，去帮用户来建立自己的DevOps流程。

这里是我们考虑如何去做这个事情。

第一点，要实现DevOps这样一个工具，首先要把DevOps任务编排起来，所以我们需要做到一个能尽量覆盖到尽多客户DevOps需求的编排逻辑。

第二，DevOps任务是千差万别的，我们没办法去开发完所有的插件，去适配每个客户自己的需求，他们的部署策略，他们的单元测试、编译等等。所以我们需要把这些任务交给客户自己去完成，需要设计一个插件机制，就是Component，后面会介绍。第三点，用户的DevOps流程运行在TencentHub里面，我们需要真正去执行它，但我们不想去发一个执行任务的集群，我们只需要只需要做很简单的任务调度，然后交给成熟的集群管理组件完成。所以我们最终还是选择kubernetes来做这个事情，也就是TKE，它为我们省去了很多运维工作，还有TKE的监控都可以复用。

DevOps任务编排 Workflow/Stage/Job

按业界通用的方法，workflow设计成三级结构，每个workflow包含多个stage，每个stage里面会有很多job，job会有并行和串行的执行方式。stage有一个类型叫pause。为什么会这样一个类型呢？比如金融客户的发布有很严格的审批流程，并不是说我修完代码，提交到git server，代码的提交，触发workflow的执行，然后去线上部署，直接一股脑跑通了。这是不行的，在DevOps流程当中，在合适的时候是需要人工介入的，需要团队中不同角色来决定流程是否继续，因此我们设计可以暂停的stage，就是为了来适应这样的场景。

具体的设计思想是，用户可以去开发一个自己的DevOps Task任务逻辑(component)，我们会把stage接下来继续执行的调用接口或者取消接口通过环境变量传到component里面去，在component插件里面，开发者可以通过邮件或者其他形式，把你需要审批的流程发给上级审批部门去察看，他如果通过之后，通过客户自己的系统，点击这个URL，回调到TencentHub里面来，TencentHub就会根据你当前回调的URL是取消任务还是继续执行任务，来决定这条workflow是继续向下走还是终止。

Component的设计我们后面再详细介绍。

Workflow 生命周期

workflow的设计生命周期需要简单介绍一下。首先，workflow可以被触发执行，这里有三种方式。一种是把某一条workflow和代码关联起来，当提交代码的时候，可以触发这条workflow的执行。第二种是也可以和TencentHub的镜像存储关联起来，比如说我们可能不需要代码去触发，我们想通过push一个镜像，因为我们的代码可能是在内部比较重要的地方去存储，不会用到公有的github、gitlab，或者不想暴露git仓库出来，就可以通过push一个镜像去触发。第三种是可以通过调API直接触发某一条workflow。

workflow被触发执行，就会在系统中把它置成一个pending状态。因为每个客户有配额限制，我们的scheduler会去检查这个用户的配置是否足够，例如他如果有些比较长的workflow执行，我们会一直将它放在一个调度的状态，当检查通过之后，就会被投入到TKE当中去执行。但是它也不一定马上会运行起来，因为TKE的资源也有可能会比较紧张，我们这里提供的是公有云服务，所有人都会访问，所以资源可能会临时不够用，也会处于pending。我们会有一个状态的检测服务，不停的轮巡job的状态，如果发现部分它已经脱离了pending，进入了其它状态类型值，我们就会把它标定为running状态。如果一个stage被标记为是一个可暂停的stage，这个stage里所有的job被执行完之后，我们会把它标记为已被暂停的状态，这时候它需要等待外界的反馈，来决定这条workflow继续如何走: 如果外界反馈说它要取消，workflow就会进入到整个流程的结束。

Job feature

首先，每个job都考虑成为一个类似于函数一样，去处理输入，在内部做一些自己的业务逻辑，最后通过我们定义的标准输出，去输出一些它处理完的信息。

第二，job可以从workflow全局环境变量中去读取信息，做一些逻辑。这些环境变量不能修改，因为如果我们提出一个全局可修改的变量存储，它会导致整个component的调试或者开发会非常麻烦。

第三，每个component肯定需要和外界打交道，我们workflow里面会去提供cache和artifact指令，让用户可以非常方便地把container里面构建出或者运行的一些结果保存到我们提供的外部存储里面。

第四，workflow没有办法去循环执行，只是一个DAG构成的关系图，然后一条一条向前执行。这是我们设计workflow的一些考虑，没有去违背这些，才去做接下来的开发。

Job Storage – Artifacts & Cache

Cache，是用来在不同的job之间共享和传递一些数据，它可以是文件夹，也可以是文件。Artifacts是构建出的一些结果，可以保存在TencentHub仓库里面，在仓库里面有界面，也有API，可以进行查看或者拉取下来。Cache没有去跨多个workflow实例。Cache的具体实现工程是对指定的文件/文件目录进行压缩，上传到TencentHub的对象存储里面。当下面有一个Job依赖它的时候，又会在Component内部把它下载下来。整个实现就是在两个hook中进行完成，两个hook一个是Prestart，一个Poststop，后面会介绍我们如何去实现hook机制。

为什么使用容器去做DevOps？

我们选择了用容器来做DevOps，为什么我们要选择用容器来做这样的插件机制呢？也是考虑了很久，讨论了很久，核心是基于下面四个考虑。

第一，我们面对的所有用户是公共服务，隔离性是我们要考虑的第一件事情，用容器可以非常方便的帮我们实现不同用户的任务隔离，有些用户可能对自己任务的安全性要求非常好，我们后期会考虑和CIS做结合，直接用Clear Container来提供更高的隔离性。
第二，复用，在不同的部门之外，它们的技术栈可能会有相似的，后台有一些公共的DevOps任务需要去使用，通过容器Docker镜像可以非常方便的去共享这样的逻辑。
第三，Docker标准非常固定，也已经非常成熟，通过我们前面对job特性的规范把它确定下来，它可以在本地直接去调试自己的Component，而不需要要建到一个workflow里面去做这个事情。我们知道，如果我们用jenkins去搭一个复杂的workflow，编写、调试脚本是比较麻烦的一件事情。
最后，我们考虑到需要平滑过渡客户已有的DevOps流程，因为每个公司会积累很多已有的不管是否标准的DevOps任务，如果让完全重新开发，代价是很高的。当我们用容器封装的时候，只需要在Component封装一个原来的任务，无论是用shell脚本，或者还是用Go写的，只要提供一个环境，用容器封装起来，就可以快速的把之前的逻辑挪过来。当然，这些迁移都不是完全透明的，需要去做开发，用容器封装之后，我们相信这个工作量不会特别大。所以我们最终选择了使用容器来作为DevOps的核心插件机制。

Component像一个函数实现一样，会有Input和Output，每个Component可以从另一个Component的Output去添加需要使用的一些输出值，workflow会把它变成Component执行的容器的环境变量，注入到当前Component里面。在Component容器进程里面可以使用这些环境变量做一些逻辑，比如说克隆指定版本的代码，或者发布上一个环节构建出的版本。Component的输出直接放到标准输出里面，我们规定了每一行只要符合下面红色地方标明的数据格式，我们就把它作为Component的输出。选择这样不够优美，但是非常实用的方式去实现，是考虑到如果使用外部的存储比如redis对input/output 作为存储，会对用户编写Component造成很大的影响：需要在Component里面还要去调用外部存储，保存输出需要存储一个Key，在下一个阶段使用时又要用key到存储里去取出来。虽然可能用一个第三方的存储会带来更丰富的数据结构方面的优势，但是我们认为对客户开发Component侵入性太大，所以我们直接用环境变量和标准输出来做这个事情。

workflow引擎

workflow是在我们的TKE去执行的，选择用DevOps做workflow引擎的执行集群，是基于这些特性去考虑的。

首先，Kubernetes的可靠性，TKE非常可靠，我们不用去担心它的运维方面的事情。
第二，workflow跑的很多任务可能会占用不同的资源，有可能一个固定的集群资源大小是不够的，结合TKE的自动扩缩容，我们就非常方便的去在上层workflow变得很多时，自动为客户提供构建的能力，不用我们人工又去介入。
第三，它的资源分配更灵活，并不是每个客户自己的workflow都是很小的资源占用，有些可能会做一些压力测试之类，会占用更大的资源。如果我们自己去实现一个workflow执行程序，就要考虑这些调度问题，所以我们最终选择用kubernetes去做这个事情。

前面到使用Component作为插件的时候，使用到 Prestart和Poststop这两个hook，在设计的时候，我们调研过是否能复用kubernetes pod 的Poststop。发现是不行的，Poststop是在pod的生命没结束之前由外面的controller去结束一个pod的时候执行（这才会有机会在容器之内去运行指定的hook程序）。但如果像workflow这种Task是一次性执行然后自行退出的，kubernetes没有办法在进程正常前调用调用Poststop里面指定的程序 – kubernetes不知道什么时候Task会退出。

所以我们最终实现了自己的方式： workflow把Component在kubernetes里面运行变成pod前，把它的CMD替换成另一个程序CommandWrapper，这个程序采用静态链接，保证可以在Linux上运行。CommandWrapper会在组件component任务被执行之前，会完成Cache和Artifact相应的逻辑，然后component会在子进程中运行，子进程退出后， CommandWrapper会继续处理Cache和Artifact的上传逻辑，最后，CommandWrapper程序会以子进程所退出状态码进行退出，如果是返回码是0，workflow引擎就把它标记为是成功运行，然后会调度下一个job的运行。这就是我们去设计的Hook机制。

这里简单介绍如果workflow引擎如何获取Task的Log。开发人员常常需要查看每个运行的workflow job的Log。可能workflow里面会有Bug，或者想看它当前进行到什么地步。Log的获取没有使用Docker driver，因为这在kubernetes里面目前还没有实现，即时kubernetes支持了docker的log driver，通过单独的通道去收集Log也会带来很大的复杂性，所以workflow引擎直接调用了kubernetes的API去获取它的Log，因为kubernetes API的Log只要在调用没退出之前，会一直把pod运行的Log从集群里面读出来，返回给调用方。Workflow引擎把整个Log存起来，放到COS里面，或者最后把它通过websocket去写到前端，让用户可以去实时查看。当然，后者我们还没有实现，开发人员太少，但是我们预留了，可以这样去做。

今天没有给大家分享怎么去搭建自己DevOps流程的例子，因为我相信这是千差万别的，在不同的公司，不同的组织里面，流程都不相同，我们没有办法枚举出来。而是站在公共服务的提供商角度，考虑怎么给用户最大的便利去建立这样一套工具。所以我今天的分享主要是关于DevOps的设计和一些实现细节，希望对大家会有一些帮助。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/Fcp2Z7afM5DHnTov31w6TA

创作场景

TencentHub 技术架构与 DevOps 实践揭秘（下）