CN108196915A - 基于应用容器引擎的代码处理方法、设备及存储介质 - Google Patents

Abstract

本发明提供一种基于应用容器引擎(Docker)的代码处理方法、设备及计算机存储介质，该方法包括：接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；根据所述通知消息从代码托管仓库中提取所述用户代码；以及对所述用户代码进行Docker镜像构建。

Description

基于应用容器引擎的代码处理方法、设备及存储介质

技术领域

本发明涉及持续集成/持续部署(Continuous Integration/ContinuousIntegration，CI/CD)技术，尤其涉及一种基于应用容器引擎(Docker)的代码处理方法、设备及计算机存储介质。

背景技术

为保证产品的质量及稳定性，持续集成/持续部署(CI/CD)作为互联网产品开发/发布的主流标准，在微服务架构下如何为部署在Docker容器中的服务进行高效的CI/CD也就显得愈发的重要。

当前实现CI/CD主要采用如下两种方式：

方式一，通过Travis CI等工具进行代码的构建并推送至二进制包管理仓库，然后手工将可运行包部署至Docker容器内部；

方式二，通过Jenkins等工具服务进行代码的构建与镜像推送，并通过编写Jenkins file等自动化脚本来进行服务的部署运行。

由此可见，当前实现CI/CD所采用的方式存在如下明显的缺陷：一方面，方式一需要用户手工拷贝构建完的二进制包到容器中并部署，这样不仅非常的耗时耗力，在代码迭代更新速度较快时，甚至可能出现部署速度跟不上代码更新速度的情况。在构建需求量很大的时候，构建服务的可扩展性依赖于Travis CI等工具自身的扩展性。另一方面，方式二只适合在CI/CD的数量不大的私有云环境中，并不太适用于作为公有云服务对外提供服务，用户体验差。

发明内容

为了至少解决现有技术中存在的以上问题之一，本发明实施例提供一种基于Docker的代码处理方法、设备及计算机存储介质。

根据本公开的第一方面，提供一种基于Docker的代码处理方法，该方法包括：接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；根据所述通知消息从代码托管仓库中提取所述用户代码；以及对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，该方法进一步包括：通过调用表述性状态转移设计标准的应用程序接口(Restful API)的方式来对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，对所述用户代码进行Docker镜像构建包括：检测是否已构建有对应于所述用户代码的Dockerfile；若已构建，则确定所述用户代码属于更新代码；根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，对所述用户代码进行Docker镜像构建包括：检测是否已构建有对应于所述用户代码的Dockerfile；若未构建，则确定所述用户代码属于新建代码；基于构建内容进行Dockerfile的构建；以及根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，所述方法还包括：检测所述用户代码的类型是否满足所述构建的Dockerfile对应的代码类型；若满足，则对所述用户代码进行编译；若编译成功，则进一步根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，所述方法还包括：保存构建的Docker镜像。

根据本公开的一个实施方式，所述方法还包括：根据所述用户代码提交的时间戳生成对应的版本号；或者，根据用户自定义的数字序列生成对应的版本号。

根据本公开的一个实施方式，该方法进一步包括：采用服务发送事件(ServerSent Event，SSE)将所述用户代码进行Docker镜像构建的过程进行日志输出。

根据本公开的一个实施方式，所述方法还包括：通过调用Restful API的方式来将所构建的Docker镜像部署至对应的Docker容器。

根据本公开的一个实施方式，该方法进一步包括：检测Docker容器中是否部署有所构建的Docker镜像的其他版本；若Docker容器中部署有所构建的Docker镜像的其他版本，则将所述Docker镜像部署至对应的Docker容器。

根据本公开的一个实施方式，将所述Docker镜像部署至对应的Docker容器包括：检测是否开启持续部署功能；若开启，则在检测到Docker容器中部署有所构建的Docker镜像的其他版本时，将所述Docker镜像部署至对应的Docker容器。

根据本公开的一个实施方式，所述Docker镜像为多个；将所述Docker镜像部署至对应的Docker容器，包括：采用滚动更新的方式将所述多个Docker镜像部署至对应的多个Docker容器。

根据本公开的一个实施方式，所述方法还包括：基于集群编排策略对所述多个Docker容器进行服务编排。

根据本公开的一个实施方式，该方法进一步包括：采用SSE将所述Docker镜像部署至对应的Docker容器的过程进行日志输出。

根据本公开的第二方面，提供一种基于Docker的代码处理设备，该设备包括：接收装置，用于接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；生成装置，用于响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；提取装置，用于根据所述通知消息从代码托管仓库中提取所述用户代码；以及构建装置，用于对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，所述构建装置还用于，通过调用Restful API的方式来对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，所述构建装置包括：第一检测子装置，用于检测是否已构建有对应于所述用户代码的Dockerfile；确定子装置，用于若已构建，则确定所述用户代码属于更新代码；以及构建子装置，用于根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，所述构建装置包括：第一检测子装置，用于检测是否已构建有对应于所述用户代码的Dockerfile；确定子装置，用于若未构建，则确定所述用户代码属于新建代码；以及构建子装置，用于基于构建内容进行Dockerfile的构建；还用于根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，所述构建装置还包括：所述第一检测子装置，用于检测所述用户代码的类型是否满足所述构建的Dockerfile对应的代码类型；编译子装置，用于若满足，则对所述用户代码进行编译；若编译成功，则进一步通过构建子装置根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本公开的一个实施方式，所述设备还包括：存储装置，用于保存构建的Docker镜像。

根据本公开的一个实施方式，所述存储装置还用于，根据所述用户代码提交的时间戳生成对应的版本号并保存；或者，所述存储装置还用于，根据用户自定义的数字序列生成对应的版本号并保存。

根据本公开的一个实施方式，所述设备还包括：第一日志输出装置，用于采用SSE将所述用户代码进行Docker镜像构建的过程进行日志输出。

根据本公开的一个实施方式，所述设备还包括：部署装置，用于通过调用RestfulAPI的方式来将所构建的Docker镜像部署至对应的Docker容器。

根据本公开的一个实施方式，所述设备还包括：检测装置，用于检测Docker容器中是否部署有所构建的Docker镜像的其他版本；所述部署装置，还用于若Docker容器中部署有所构建的Docker镜像的其他版本，则将所述Docker镜像部署至对应的Docker容器。

根据本公开的一个实施方式，所述部署装置包括：第二检测子装置，用于检测是否开启持续部署功能；部署子装置，用于若开启，则在检测到Docker容器中部署有所构建的Docker镜像的其他版本时，将所述Docker镜像部署至对应的Docker容器。

根据本公开的一个实施方式，所述Docker镜像为多个；所述部署装置还用于，采用滚动更新的方式将所述多个Docker镜像部署至对应的多个Docker容器。

根据本公开的一个实施方式，所述设备还包括：集群服务装置，用于基于集群编排策略对所述多个Docker容器进行服务编排。

根据本公开的一个实施方式，所述设备还包括：第二日志输出装置，用于采用SSE将所述Docker镜像部署至对应的Docker容器的过程进行日志输出。

根据本公开的第三方面，提供一种基于Docker的代码处理设备，包括：一个或者多个处理器；存储器；存储在所述存储器中的程序，当被所述一个或者多个处理器执行时，所述程序使所述处理器执行如上述第一方面中任意一项所述的方法。

根据本公开的第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有程序，当所述程序被处理器执行时，使得所述处理器执行如上述第一方面中任意一项所述的方法。

本公开的实施方式能够实现以下技术效果中的至少一种。

首先，Controller作为整个基于Docker进行CI/CD服务的控制中心，能够在发生有已提交用户代码的事件的情况下，通过与Hook服务之间的协作实时获取用户代码并调度具体的CI/CD服务，从而提供吞吐量大、响应快、稳定性高的调度中心服务。

其次，本发明实施例通过调用Restful API的方式来提供CI/CD服务，使得CI/CD服务可以在需要时随时新起服务，且在不需要时随时停掉部分服务，即使得CI/CD服务实现为无状态服务(也即不用保持状态)，得以保证在大规模构建需求下，CI/CD服务的弹性伸缩能力。而且，本发明实施例所述基于Docker的代码处理方法所提供的CI/CD服务不仅对公有云服务使用，而且在构建需求量不大的私有云平台也同样适用。

再次，本发明实施例通过SSE技术来解决CI/CD服务构建实时日志的输出。该SSE方式能够在不引入其他依赖(如中间件Redis)，保证CI/CD服务的弹性伸缩能力的前提下，实现构建部署实时日志的输出；而且该SSE方式支持客户端的重连，在较差的网络环境中，依然能够保证构建实时日志的输出。这样，用户可以查看构建部署的实时日志，方便查看构建部署的进度和结果，从而增强用户友好性，有效提升用户体验。

需要理解的是，本公开的教导并不需要实现上面所述的全部有益效果，而是特定的技术方案可以实现特定的技术效果，并且本公开的其他实施方式还能够实现上面未提到的有益效果。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：

在附图中，相同或对应的标号表示相同或对应的部分。

图1示出了相关技术中通过Jenkins进行CI/CD服务的系统架构图；

图2示出了本发明实施例基于Docker进行CI/CD服务的系统架构图；

图3示出了本发明实施例基于Docker的代码处理方法的实现流程示意图；

图4示出了本发明一应用示例在CI服务的实现中采用SSE所输出的构建日志的展示效果图；

图5示出了本发明一应用示例中CI可配置自动关联界面图；

图6示出了本发明一应用示例中CI自动化构建界面图；

图7示意性地示出了根据本发明实施方式的基于Docker的代码处理设备的示意图；

图8示出了根据本发明实施方式的基于Docker的代码处理设备的示意图；

图9示出了根据本发明实施方式的基于Docker的代码处理的计算机可读存储介质的示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

下面结合附图对本发明的具体实施方式进行详细描述。

对本发明进行进一步详细说明之前，首先对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

1)持续集成(CI)，在用户代码持续更新后，能够及时将开发代码集成至主干分支并构建打包成可运行的软件包。

2)持续部署(CD)，在持续集成完成后，能够及时将持续集成所构建好包发布至各个环境运行。

3)Docker，开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中。

4)Docker镜像，容器的运行状态的保存，通过Docker镜像可以做到快速部署两个相同的服务，通过Docker file描述镜像构建的过程及容器运行时环境。

5)服务端推送事件(SSE)，该技术能够不断的向客户端推送事件，并且支持客户端重连，保证在网络环境不理想的情况下依然能够保证较为实时的事件推送。

6)Restful API，是给表述性状态转移(Representational State Transfer，REST)设计标准的应用程序编程接口(Application Programming Interface，API)。

7)钩子(Hook)，实际上是一个处理消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口前，钩子程序就先捕获该消息，亦即钩子函数先得到控制权。这时钩子函数既可以加工处理(改变)该消息，也可以不作处理而继续传递该消息，还可以强制结束消息的传递。

8)GitHub，其作为一个分布式的版本控制系统，可以托管各种git库，并提供一个Web界面。

9)无状态(Stateless)，作为REST架构风格最重要的架构约束之一，该约束对应通信只能由客户端单方面发起，表现为请求—响应的形式。

图1示出了相关技术中通过Jenkins进行CI/CD服务的系统架构图。

如图1所示，相关技术中通过Jenkins进行CI/CD服务的具体实现流程如下：a.开发者向代码托管仓库GitHub提交代码；b.GitHub通过调用webhook通知Jenkins有更新；c.Jenkins从GitHub下拉最新代码、Dockerfile及其他文档；d.Jenkins在从节点(Slaver节点)构建Docker镜像；e.Jenkins在Slave节点实例化Docker镜像，并且执行测试代码；f.如果测试通过，Jenkins推送Docker镜像到仓库。由此可见，上述通用的CI/CD方案存在如下缺陷：一是因为该方案的构建日志无法做到实时输出，导致用户无法查看构建过程，对用户使用不友好；二是持续部署的过程，需要用户编写自动化部署脚本，有一定的学习成本，用户体验差。

图2示出了本发明实施例基于Docker进行CI/CD服务的系统架构图。

为了解决相关技术中通用的CI/CD方案所存在的问题，本发明实施例提供一种基于Docker进行CI/CD服务的系统，如图2所示，该系统包括如下服务模块：用于提供调度中心服务的控制中心(Controller)，用于托管用户代码的代码托管仓库(GitHub)，用于提供Hook服务的钩子(Hook)，用于提供持续构建服务的CI服务模块，用于提供持续部署服务的CD服务模块，用于提供应用镜像保存服务的仓库(Registry)，以及用于提供集群服务的k8s模块。当然，本发明基于Docker进行CI/CD服务的系统的架构并不局限于如图2所示的服务模块，服务模块之间的任意组合，任意减少其中的部分服务模块，或额外增加新的服务模块所形成的系统均属于本发明保护范围。

图3示出了本发明实施例基于Docker的代码处理方法的实现流程示意图。

如图3所示，该方法包括如下操作：操作301，接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；操作302，响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；操作303，根据所述通知消息从代码托管仓库中提取所述用户代码；以及操作304，对所述用户代码进行Docker镜像构建。

下面结合图2的系统架构对本发明实施例基于Docker的代码处理方法的实现流程进行详细描述。

在操作301，通过Hook服务接收GitHub的Hook回调请求(Hook callback)，该Hook回调请求用于表征所述代码托管仓库中存在已提交用户代码的事件，即有用户(User)向GitHub推送了用户代码；其中，所述用户代码可能是用户在原始代码基础上进行更新后的更新代码，也可能是用户为了开发新功能所编写的新建代码。

在操作302～304，Hook服务响应所述Hook callback，生成用于指示已提交用户代码的事件的通知消息，如MQ消息；进一步地，Hook服务发送所述MQ消息至Controller，以使Controller通过消費所述MQ消息的方式从GitHub中提取所述用户代码，并进一步调度具体的CI/CD服务。其中，Controller通过消费MQ消息进行CI/CD服务调度时，MQ消息中包含有相关参数信息。举例来说，在调度CI服务时，MQ消息中包括有需要传入用户最新推送的用户代码与用户相关身份信息等参数信息；因此，Controller服务可以根据该参数信息调用CI服务的接口进行CI服务。

如此，Controller作为整个基于Docker进行CI/CD服务的控制中心，能够在发生有已提交用户代码的事件的情况下，通过与Hook服务之间的协作实时获取用户代码并调度具体的CI/CD服务，从而提供吞吐量大、响应快、稳定性高的调度中心服务。

根据本发明一实施方式，在操作304，可以通过调用Restful API的方式来对所述用户代码进行Docker镜像构建。具体地，在调用Restful API进行CI服务时，Controller首先通过消费MQ的方式向提供CI服务的API参数中传入相关参数信息，如传入用户设置的镜像版本，用户的代码仓库相关授权信息等。这样，CI服务模块可以通过调用API参数中用户的代码仓库相关授权信息去拉取用户代码，并进一步对所述用户代码进行Docker镜像构建。

根据本发明一实施方式，在操作304之后，所述方法还可以包括：操作305，通过调用Restful API的方式来将所构建的Docker镜像部署至对应的Docker容器。

如此，本发明实施例通过调用Restful API的方式来提供CI/CD服务，使得CI/CD服务可以在需要时随时新起服务，且在不需要时随时停掉部分服务，即使得CI/CD服务实现为无状态服务(也即不用保持状态)，得以保证在大规模构建需求下，CI/CD服务的弹性伸缩能力。当然，通过调用Restful API的方式所提供的CI/CD服务本身无外部依赖，需要的话，可以在海外部署提供服务。而且，本发明实施例所述基于Docker的代码处理方法所提供的CI/CD服务不仅对公有云服务使用，而且在构建需求量不大的私有云平台也同样适用。

根据本发明一实施方式，在操作304或操作305，均可以采用SSE进行日志输出。具体地，在操作304的实现中，可以将所述用户代码进行Docker镜像构建的过程进行日志输出；相应的，在操作305的实现中，可以采用SSE将所述Docker镜像部署至对应的Docker容器的过程进行日志输出。

图4示出了本发明一应用示例在CI服务的实现中采用SSE所输出的构建日志的展示效果图。

如图4所示，在CI服务的实现中，采用SSE进行日志输出的方式对用户代码进行Docker镜像构建的过程记录如下：2017-09-15 10:17:40开始执行任务：解析参数；2017-09-15 10:17:40开始代码拉取，地址：https://github.com/piaohai/hello-nce.git,分支:master；2017-09-15 10:17:43拉取代码成功；2017-09-15 10:17:43开始执行任务：处理Dockerfile；2017-09-15 10:17:43开始基于模板中的Dockerfile构建，repoUrl:hub.c.163.com/piaohai/helloci:20170915101738877,dockerfile；Done。通过上述日志输出，从而记录得到构建日志-20170915101738877。

本发明在CI/CD服务中对于日志的实时推送，采用了较为优选的SSE方式。该SSE方式与现有技术中同样可以不依赖中间件Redis的websocket和long polling相比：websocket需要服务端专门支持websocket，对应用本身侵入较大；long polling需要阻塞客户端的请求，知道所有数据准备好才返回；而SSE可以认为是一个http版本的websocket，对应用本身无侵入，也可以做到服务端实时推送。

如此，本发明实施例通过SSE技术来解决CI/CD服务构建实时日志的输出。该SSE方式能够在不引入其他依赖(如中间件Redis)，保证CI/CD服务的弹性伸缩能力的前提下，实现构建部署实时日志的输出；而且该SSE方式支持客户端的重连，在较差的网络环境中，依然能够保证构建实时日志的输出。这样，用户可以查看构建部署的实时日志，方便查看构建部署的进度和结果，从而增强用户友好性，有效提升用户体验。

根据本发明一实施方式，在操作304，对所述用户代码进行Docker镜像构建包括：检测是否已构建有对应于所述用户代码的Dockerfile；若已构建有对应于所述用户代码的Dockerfile，则确定所述用户代码属于更新代码，进一步根据构建的Dockerfile对所述用户代码进行Docker镜像构建；若未构建有对应于所述用户代码的Dockerfile，则确定所述用户代码属于新建代码，进一步基于构建内容进行Dockerfile的构建；以及根据构建的Dockerfile对所述用户代码进行Docker镜像构建。这样，在CI服务的实现过程中，用户可以自己根据构建内容的不同，编写Dockerfile进行Docker镜像的构建。进一步地，在用户首次构建之后的每次构建，CI服务会自动根据用户的Dockerfile进行镜像构建。

图5示出了本发明一应用示例中CI可配置自动关联界面图。

在一示例中，如图5所示，在代码构建过程中，首先可以在代码仓库piaohai/helloci中，基于GitHub的源码管理来检测是否为已构建有对应于当前用户代码的Dockerfile文件的方式来判断所述用户代码是否属于更新代码，即在GitHub中检测有piaohai这一用户的Dockerfile文件，如nenoz及其更新时间为2013-12-28 16:18，则可确定当前用户代码并非用户piaohai的次构建，故CI服务可以自动根据用户piaohai已构建的Dockerfile文件对当前用户代码进行Dockerfile镜像构建。

根据本发明一实施方式，在操作304，所述方法还包括：检测所述用户代码的类型是否满足所述构建的Dockerfile对应的代码类型；若满足，则对所述用户代码进行编译；若编译成功，则进一步根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

在一应用示例中，如图5所示，在代码构建过程中，如果代码需要编译，则在确定所述用户代码的类型满足所构建的Dockerfile文件对应的代码类型的情况下，可参考帮助文档对所述用户代码进行编译。

根据本发明一实施方式，在操作304，所述方法还包括：保存构建的Docker镜像。具体地，在生成Docker镜像之后，可以通过Registry实现根据用户的权限进行自动的应用镜像保存，同时根据提交的时间戳或用户自定义的数字自动生成版本号。

根据本发明一实施方式，在操作304，所述方法还包括：根据所述用户代码提交的时间戳生成对应的版本号；或者，根据用户自定义的数字序列生成对应的版本号。

图6示出了本发明一应用示例中CI自动化构建界面图。

在一应用示例，如图6所示，在代码构建过程中，用户可以在CI自动化构建界面图中将版本命名规则预先进行预先选定，如仅更新时间或代码分支缩写+更新时间的方式；其中，代码分支缩写通常为用户自定义的数字。这样，在后续Docker镜像构建时会自动根据提交的时间戳或用户自定义的数字自动生成版本号。另外，在图6所述的CI自动化构建界面图中，用户还可以预先选定Dockerfile文件的构建方式，如自定义或自动生成，即使用默认Dockerfile；其中，在自定义选项下可以填写Dockerfile文件的编写方法。

需要补充说明的是，dockerfile的编写没有编写的界面，用户可以自己用文本编辑器编写好，然后通过界面上传。用户可以根据构建内容的不同而编写不同的dockerfile，即用户需要根据自己的应用的编写语言，应用的依赖等不同，来进行不同的准备。

根据本发明一实施方式，在操作305，该方法进一步包括：检测Docker容器中是否部署有所构建的Docker镜像的其他版本；若Docker容器中部署有所构建的Docker镜像的其他版本，则将所述Docker镜像部署至对应的Docker容器。

根据本发明一实施方式，操作305将所述Docker镜像部署至对应的Docker容器包括：检测是否开启持续部署功能；若开启，则在检测到Docker容器中部署有所构建的Docker镜像的其他版本时，将所述Docker镜像部署至对应的Docker容器。

如此，用户在CI服务模块通过操作304实现CI服务完成Docker镜像构建之后，CD服务模块能够自行检测该镜像仓库镜像是否有部署在容器并根据用户的自定义开关(是否开启持续部署，若开启，则在持续构建完成后会自动将构建结果部署至对应环境)自动将持续构建后的镜像以rolling update的方式部署至用户容器内部。这样，既节省了用户自己编写自动化部署脚本所带来成本，又避免了因为自动化脚本可能带来的CI/CD流水线的中断，最终为用户提供了一键式的CI/CD服务。

根据本发明一实施方式，所述Docker镜像为多个；将所述Docker镜像部署至对应的Docker容器，包括：采用滚动更新的方式将所述多个Docker镜像部署至对应的多个Docker容器。

根据本发明一实施方式，在操作305，所述方法还包括：基于集群编排策略对所述多个Docker容器进行服务编排。

具体地，参考图2，在CD服务的实现过程中，可以通过k8s集群服务来基于一定的集群编排策略采用滚动更新(rolling update)的方式镜已构建好的多个Docker镜像部署至对应的多个Docker容器。这样，通过k8s集群服务的大规模集群自动化编排能力，能够实现多应用的灰度与服务发现等编排能力，从而保证服务发现的效率。

示例性设备

在介绍了本发明示例性实施方式的基于Docker的代码处理方法之后，接下来，介绍根据本发明的另一示例性实施方式的基于Docker的代码处理设备。

图7示意性地示出了根据本发明实施方式的基于Docker的代码处理设备的示意图。

如图7所示，本发明实施例基于Docker的代码处理设备700可以包括：接收装置701，用于接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；生成装置702，用于响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；提取装置703，用于根据所述通知消息从代码托管仓库中提取所述用户代码；以及构建装置704，用于对所述用户代码进行Docker镜像构建。

根据本发明一实施方式，所述构建装置704还用于，通过调用Restful API的方式来对所述用户代码进行Docker镜像构建。

根据本发明一实施方式，如图7所示，所述构建装置704包括：第一检测子装置7041，用于检测是否已构建有对应于所述用户代码的Dockerfile；确定子装置7042，用于若已构建，则确定所述用户代码属于更新代码；以及构建子装置7043，用于根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本发明一实施方式，如图7所示，所述构建装置704包括：第一检测子装置7041，用于检测是否已构建有对应于所述用户代码的Dockerfile；确定子装置7042，用于若未构建，则确定所述用户代码属于新建代码；以及构建子装置7043，用于基于构建内容进行Dockerfile的构建；还用于根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本发明一实施方式，如图7所示，所述构建装置704还包括：所述第一检测子装置7041，用于检测所述用户代码的类型是否满足所述构建的Dockerfile对应的代码类型；编译子装置7044，用于若满足，则对所述用户代码进行编译；若编译成功，则进一步通过构建子装置根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

根据本发明一实施方式，如图7所示，所述设备700还包括：存储装置705，用于保存构建的Docker镜像。

根据本发明一实施方式，所述存储装置705还用于，根据所述用户代码提交的时间戳生成对应的版本号并保存；或者，所述存储装置705还用于，根据用户自定义的数字序列生成对应的版本号并保存。

根据本发明一实施方式，如图7所示，所述设备700还包括：第一日志输出装置706，用于采用SSE将所述用户代码进行Docker镜像构建的过程进行日志输出。

根据本发明一实施方式，如图7所示，所述设备700还包括：部署装置707，用于通过调用Restful API的方式来将所构建的Docker镜像部署至对应的Docker容器。

根据本发明一实施方式，如图7所示，所述设备700还包括：检测装置708，用于检测Docker容器中是否部署有所构建的Docker镜像的其他版本；所述部署装置707，还用于若Docker容器中部署有所构建的Docker镜像的其他版本，则将所述Docker镜像部署至对应的Docker容器。

根据本发明一实施方式，如图7所示，所述部署装置707包括：第二检测子装置7071，用于检测是否开启持续部署功能；部署子装置7072，用于若开启，则在检测到Docker容器中部署有所构建的Docker镜像的其他版本时，将所述Docker镜像部署至对应的Docker容器。

根据本发明一实施方式，所述Docker镜像为多个；所述部署装置707还用于，采用滚动更新的方式将所述多个Docker镜像部署至对应的多个Docker容器。

根据本发明一实施方式，如图7所示，所述设备700还包括：集群服务装置709，用于基于集群编排策略对所述多个Docker容器进行服务编排。

根据本发明一实施方式，如图7所示，所述设备700还包括：第二日志输出装置710，用于采用SSE将所述Docker镜像部署至对应的Docker容器的过程进行日志输出。

根据本申请实施例的所述基于Docker的代码处理设备700中的各个装置及其子装置的具体配置和操作已经在上面参考图1到图6描述的基于Docker的代码处理方法中详细介绍，并因此，将省略其重复描述。

在介绍了本发明示例性实施方式的方法和设备之后，接下来，介绍根据本发明的另一示例性实施方式的基于Docker的代码处理设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，本发明的基于Docker的代码处理设备可以至少包括一个或多个处理器、以及至少一个存储器。其中，所述存储器存储有程序，当所述程序被所述处理器执行时，使得所述处理器执行本说明书中描述各个步骤，例如，所述处理器可以执行如图3中所示的操作301，接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；操作302，响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；操作303，根据所述通知消息从代码托管仓库中提取所述用户代码；以及操作304，对所述用户代码进行Docker镜像构建。

图8示出了根据本发明实施方式的基于Docker的代码处理设备的示意图。

下面参照图8来描述根据本发明的这种实施方式的基于Docker的代码处理设备。图8显示的设备800仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图8所示，设备800以通用计算设备的形式表现，包括但不限于：上述至少一个处理器810、上述至少一个存储器820、连接不同系统组件(包括存储器820和处理器810)的总线860。

总线860包括地址总线，控制总线和数据总线。

存储器820可以包括易失性存储器，例如随机存取存储器(RAM)821和/或高速缓存存储器822，还可以进一步包括只读存储器(ROM)823。

存储器820还可以包括一组(至少一个)程序模块824，这样的程序模块824包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

设备800还可以与一个或多个外部设备80(例如键盘、指向设备、蓝牙设备等)通信。这种通信可以通过输入/输出(I/O)接口840进行，并在显示单元830上进行显示。并且，设备900还可以通过网络适配器850与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器850通过总线860与设备800中的其它模块通信。应当明白，尽管图中未示出，但可以结合设备800使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

示例性程序产品

在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序代码在被处理器执行时，所述程序代码用于使所述处理器执行上面描述的方法的各个步骤，例如，所述处理器可以执行如图3中所示的操作301，接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；操作302，响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；操作303，根据所述通知消息从代码托管仓库中提取所述用户代码；以及操作304，对所述用户代码进行Docker镜像构建。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

图9示出了根据本发明实施方式的基于Docker的代码处理的计算机可读存储介质的示意图。

如图9所示，描述了根据本发明的实施方式的程序产品900，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端或服务器上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

应当注意，尽管在上文详细描述中提及了用于评测OCR系统的性能的若干装置及子装置，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多装置的特征和功能可以在一个装置中具体化。反之，上文描述的一个装置的特征和功能可以进一步划分为由多个装置来具体化。

虽然已经参考若干具体实施方式描述了本发明的精神和原理，但是应该理解，本发明并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本发明旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (10)

1.一种基于应用容器引擎Docker的代码处理方法，该方法包括：

接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；

响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；

根据所述通知消息从代码托管仓库中提取所述用户代码；以及

对所述用户代码进行Docker镜像构建。

2.根据权利要求1所述的方法，其中，该方法进一步包括：

通过调用表述性状态转移设计标准的应用程序接口Restful API的方式来对所述用户代码进行Docker镜像构建。

3.根据权利要求1所述的方法，其中，对所述用户代码进行Docker镜像构建包括：

检测是否已构建有对应于所述用户代码的Dockerfile；

若已构建，则

确定所述用户代码属于更新代码；

根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

4.根据权利要求1所述的方法，其中，对所述用户代码进行Docker镜像构建包括：

检测是否已构建有对应于所述用户代码的Dockerfile；

若未构建，则

确定所述用户代码属于新建代码；

基于构建内容进行Dockerfile的构建；以及

根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

5.根据权利要求3或4所述的方法，其中，所述方法还包括：

检测所述用户代码的类型是否满足所述构建的Dockerfile对应的代码类型；

若满足，则对所述用户代码进行编译；

若编译成功，则进一步根据构建的Dockerfile对所述用户代码进行Docker镜像构建。

6.根据权利要求3或4所述的方法，其中，所述方法还包括：

保存构建的Docker镜像。

7.根据权利要求6所述的方法，其中，所述方法还包括：

根据所述用户代码提交的时间戳生成对应的版本号；或者，

根据用户自定义的数字序列生成对应的版本号。

8.一种基于应用容器引擎Docker的代码处理设备，该设备包括：

接收装置，用于接收针对代码托管仓库的回调请求，所述回调请求用于表征所述代码托管仓库中有已提交用户代码的事件；

生成装置，用于响应于所述回调请求，生成用于指示已提交用户代码的事件的通知消息；

提取装置，用于根据所述通知消息从代码托管仓库中提取所述用户代码；以及

构建装置，用于对所述用户代码进行Docker镜像构建。

9.一种基于应用容器引擎Docker的代码处理设备，包括：

一个或者多个处理器；

存储器；

存储在所述存储器中的程序，当被所述一个或者多个处理器执行时，所述程序使所述处理器执行如权利要求1-7中任意一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有程序，当所述程序被处理器执行时，使得所述处理器执行如权利要求1-7中任意一项所述的方法。