一种基于dockercompose的持续集成方法及装置与流程

本发明实施例涉及软件技术开发领域，尤其涉及一种基于docker compose的持续集成方法及装置。

背景技术：

持续集成(Continuous integration，CI)是一种软件开发实践，是软件开发过程中的一个重要组成部分。在持续集成中，团队开发人员要经常集成他们的工作成果，以尽早发现集成错误，保证开发产品的质量。

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上。现有技术中，基于docker的持续集成方法一般依次为在代码库中提交代码、编译打包代码、构建镜像、将构建的镜像上传至镜像库、从镜像库中下载镜像及运行镜像。

然而，上述持续集成方法中，在持续集成的过程中，每次编译打包代码后，均重新构建镜像，并上传至镜像库，过程复杂，集成效率较低。

技术实现要素：

本发明提供一种基于docker compose的持续集成方法及装置，以提高持续集成效率。

第一方面，本发明实施例提供了一种基于docker compose的持续集成方法，该方法包括：

在集成文件夹中建立用于配置镜像的docker compose.yml文件；

将可执行程序保存在所述集成文件夹，并在所述docker compose.yml文件中以磁盘挂载的方式挂载；

将待集成的可执行程序的更新程序保存至所述集成文件夹。

第二方面，本发明实施例还提供了一种基于docker compose的持续集成装置，包括：

文件建立模块，用于在集成文件夹中建立用于配置镜像的docker compose.yml文件；

可执行程序保存模块，用于将可执行程序保存在所述集成文件夹，并在所述docker compose.yml文件中以磁盘挂载的方式挂载；

更新程序保存模块，用于将待集成的可执行程序的更新程序保存至所述集成文件夹。

本发明实施例在集成文件夹中建立用于配置镜像的docker compose.yml文件；将可执行程序保存在所述集成文件夹，并在docker compose.yml文件中以磁盘挂载的方式挂载，然后将待集成的更新程序保存至集成文件夹。本发明实施例在持续集成过程中，优选使用基础的官方镜像或已经构建的镜像，使得在持续集成过程中无需每次更新代码时均更新镜像，并在docker compose.yml文件中以磁盘挂载的方式挂载待集成的程序，通过磁盘挂载实现程序的共享，在持续集成过程中，只需更该挂载至容器的宿主机目录中的程序，无需每次集成将待集成的程序放至各容器里，可以方便快速完成构建和部署，提高集成效率。

附图说明

图1是本发明实施例一中的一种基于docker compose的持续集成方法的流程示意图；

图2是本发明实施例二中的一种基于docker compose的持续集成方法的流程示意图；

图3是本发明实施例三中的一种基于docker compose的持续集成方法的流程示意图；

图4是本发明实施例四中的一种基于docker compose的持续集成装置的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图1为本发明实施例一提供的一种基于docker compose的持续集成方法的流程示意图，本实施例可适用于任何需持续集成情况，该方法可以由基于docker compose的持续集成装置来执行，其中该装置可由软件和/或硬件实现。该方法具体包括如下步骤：

步骤110、在集成文件夹中建立用于配置镜像的docker compose.yml文件。

其中，docker compose.yml文件为docker compose的配置文件，在docker compose.yml文件中可定义每个服务，并指定每个服务所依赖的镜像以及各镜像运行后生成的容器之间的依赖关系等，通过docker compose.yml文件，docker compose完成管理和配置各容器，以形成完整的应用服务。

优选的，在本实施例提供的基于docker compose的持续集成方法中，每个服务所依赖的镜像优选使用官方镜像仓库中的官方镜像，例如Docker Hub中的官方镜像，若官方镜像仓库中没有docker compose.yml文件中定义的服务所要依赖的镜像，可在本次进行集成之前，构建所依赖的镜像，并将其上传至镜像仓库中，以便本次集成及后续持续集成过程中使用。这里需要说明的是，本实施例提供的基于docker compose的持续集成方法中，优选的使用官方镜像，只有在docker compose.yml文件中所要定义的服务依赖的镜像在官方镜像中没有时，才会构建镜像，并且下次集成过程中该服务所依赖的镜像可直接在docker compose.yml中通过image指定已经构建的镜像，即在持续集成过程中，下一次集成所需的镜像可完全依赖官方镜像或已经构建的镜像，而不在持续集成过程中，每次集成都构建新的镜像，可大大简化持续集成的过程，提高集成效率。

步骤120、将可执行程序保存在集成文件夹，并在docker compose.yml文件中以磁盘挂载的方式挂载。

优选的，可使用git仓库作为代码仓库，开发人员在git仓库中提交待集成的程序，jenkins获取提交的程序，将可执行程序保存在集成文件夹中，jenkins自动根据部署脚本进行构建和部署，完成持续集成。

优选的，在docker compose.yml文件中通过volumes将宿主机中的目录挂载到容器的内部，即通过在docker compose.yml文件中使用volumes指定挂载到容器的宿主机目录，从而在集成过程中，将可执行程序放至指定的宿主机目录中，容器启动后，可执行程序便可在容器中进行运行。这样在每次集成过程中，只需将待集成的可执行程序放至docker compose.yml文件中volumes指定的宿主机的目录中，即对volumes指定的宿主机的目录中的可执行程序进行更新，而不是每次集成都构建新的镜像，生成新的容器并将待集成的可执行程序放至各容器中，节约系统资源。本实施例提供的方法所有服务基本依赖于基础的官方镜像或已构建的镜像，并通过磁盘挂载的方式挂载待集成的可执行程序，简化了持续集成过程，提高集成效率。

步骤130、将待集成的可执行程序的更新程序保存至集成文件夹。

优选的，若本次待集成的可执行程序的更新程序所依赖的环境可不进行改变，则无需对docker compose.yml文件进行更改，开发人员只需在代码仓库中提交待集成的更新的程序，则jenkins获取提交的更新的程序，将待集成的可执行程序的更新程序保存至集成文件夹，自动根据部署脚本进行构建和部署，完成持续集成。

优选的，若本次待集成的可执行程序的更新程序所依赖的环境有所改变，则在提交更新程序之前，可构建新的镜像，然后在代码仓库中提交待集成的更新的程序。

上述方案中，可选的是，将待集成的可执行程序的更新程序保存至集成文件夹之前，还包括：

确认达到预设的集成周期的分界时刻。

示例性的，确认预设的集成周期的分界时刻可为自动定时触发，当达到预设的时间时，jenkins自动获取提交的更新的程序进行构建和部署，示例性的，预设的时间为每天凌晨2点或预设时间为一定的时间间隔，如每间隔1个小时，jenkins自动获取提交的更新的程序，若有更新程序提交，则jenkins自动进行构建和部署。

示例性的，还可通过手动触发来确认预设的集成周期的分界时刻，当在git仓库中提交更新的程序后，开发人员可通过jenkins中的手动触发按钮来实现构建和部署，完成本次集成。还可通过钩子(hook)将jenkins与git仓库连接来确认预设的集成周期的分界时刻，只要git仓库中有新的程序提交，jenkins便会自动获取提交的更新的程序进行构建和部署。

上述方案中，可选的是，将待集成的可执行程序的更新程序保存至集成文件夹之后，还包括：将集成文件夹打包为一个压缩包。

优选的，当待集成的可执行程序的更新程序保存至集成文件夹之后，自动将集成文件夹打包为一个压缩包，无需手动进行打包，提高持续集成的效率。

上述方案中，可选的是，若集成文件夹打包失败，发送失败邮件。

示例性的，若jenkins获取提交的更新的程序失败、待集成的可执行程序的更新程序未能成功放至集成文件夹中或集成过程中出现的其他错误均会导致集成文件夹打包失败。

优选的，如果集成文件夹打包失败，会自动发送打包失败邮件至指定的邮箱，以及时发现持续集成过程中的错误，对发现的错误进行及时的修改，保证集成的效率和开发产品的质量。

本实施例在集成文件夹中建立用于配置镜像的docker compose.yml文件；将可执行程序保存在所述集成文件夹，并在docker compose.yml文件中以磁盘挂载的方式挂载，然后将待集成的更新程序保存至集成文件夹。本实施例在持续集成过程中，优选使用基础的官方镜像或已经构建的镜像，使得在持续集成过程中无需每次更新代码时均更新镜像，并在docker compose.yml文件中以磁盘挂载的方式挂载待集成的程序，通过磁盘挂载实现程序的共享，在持续集成过程中，只需更改挂载至容器的宿主机目录中的程序，无需每次集成将待集成的程序放至各容器里，可以方便快速完成构建和部署，提高持续集成效率。

实施例二

图2为本发明实施例二提供的一种基于docker compose的持续集成方法的流程示意图。本实施例为在实施例一的基础上进行优化，如图2所示，在实施例一的方案中，可选的是，步骤130、将待集成的可执行程序的更新程序保存至集成文件夹具体可以通过下述方式来实施：步骤230、将更新程序的源代码通过jenkins编译后得到的二进制程序保存至集成文件夹。

相应的，本实施例提供的方法包括：

步骤210、在集成文件夹中建立用于配置镜像的docker compose.yml文件。

步骤220、将可执行程序保存在集成文件夹，并在docker compose.yml文件中以磁盘挂载的方式挂载。

步骤230、将更新程序的源代码通过jenkins编译后得到的二进制程序保存至集成文件夹。

示例性的，若开发人员提交的更新程序是以编译型语言进行编写的，如C++语言或C语言等，jenkins在获取提交的更新的程序之后，对提交的更新程序的源代码进行编译，得到编译后的二进制程序，由于编译后得到的二进制程序不易被破解，因此，可自动直接将编译后得到的二进制程序保存至集成文件夹中，提高集成的效率。

本实施例提供的方法中，jenkins在获取提交的更新的程序之后，对提交的更新程序的源代码进行编译，自动直接将编译后得到的二进制程序保存到集成文件中，提高集成的效率。

实施例三

图3为本发明实施例三提供的一种基于docker compose的持续集成方法的流程示意图。本实施例为在实施例一的基础上进行优化，如图3所示，在实施例一的方案中，可选的是，步骤130、将待集成的可执行程序的更新程序保存至集成文件夹具体可以通过下述方式来实施：步骤330、将以源代码的方式运行的更新程序的源代码通过jenkins混淆后保存至集成文件夹。

相应的，本实施例提供的方法包括：

步骤310、在集成文件夹中建立用于配置镜像的docker compose.yml文件。

步骤320、将可执行程序保存在集成文件夹，并在docker compose.yml文件中以磁盘挂载的方式挂载。

步骤330、将以源代码的方式运行的更新程序的源代码通过jenkins混淆后保存至集成文件夹。

示例性的，若开发人员提交的更新程序是以源代码的方式运行的语言进行编写的，如解释型语言C#、java、javascript等，在jenkins获取提交的更新程序之后，通过混淆工具将获取的提交的更新程序混淆之后，再保存至集成文件夹中，以使开发的程序不易被破解，保证开发产品的安全性。

本实施例提供的方法中，jenkins在获取提交的更新的程序之后，对提交的更新程序的源代码进行混淆后保存到集成文件中，以使开发的程序不易被破解，保证开发产品的安全性。

下面通过一个较佳实施例来对本发明进行阐述。

在持续集成过程中，首次持续集成时，首先在集成文件夹中建立并编写docker compose.yml文件，在docker compose.yml文件中定义每个服务，并指定每个服务所依赖的镜像以及各镜像运行后生成的容器之间的依赖关系等，并通过volumes将宿主机中的目录挂载到容器的内部，优选的，所有服务使用官方镜像仓库中的官方镜像，若官方镜像仓库中没有docker compose.yml文件中定义的服务所要依赖的镜像，则首先构建所需要的镜像，并上传至镜像仓库中，以供本次集成及后续集成使用，本发明中优选的使用基础的官方镜像或已构建的镜像，不需每次集成均构建新的镜像，提高集成效率，并通过volumes将宿主机中的目录挂载到容器的内部，通过volumes实现代码的共享，则在下次集成中更新所指定挂载的宿主机的目录中的程序，而并不是将所集成的程序都放至各容器中，可节约系统资源。其次，编写dockerfile文件来规范运行环境并编写构建所要执行的部署脚本，然后在jenkins新建一个项目，并进行设置，如代码仓库的地址、构建触发器及构建时所要执行的部署脚本等，完成设置后，便可在代码仓库中提交待集成的代码。优选的，在jenkins构建触发器中设置每一个小时进行构建，则jenkins每隔一个小时从代码仓库中拉取一次代码，若代码仓库中有新的程序提交，则jenkins获取提交的程序，若提交的程序为以编译型语言进行编写的，如C++语言或C语言等，jenkins在获取提交的更新程序之后，对提交的更新程序的源代码进行编译，得到编译后的二进制程序，若提交的程序为以源代码的方式运行的语言进行编写的，如解释型语言C#、java、javascript等，在jenkins获取提交的更新程序之后，通过混淆工具将获取的提交的更新程序混淆，然后将得到的编译后的二进制程序或混淆后的提交的更新程序保存至集成文件夹中，jenkins自动根据设置的构建时所要执行的部署脚本进行构建和部署，然后自动定时将集成文件夹打包为一个压缩包得到本次集成的新版本安装包，若由于获取提交代码失败或编译失败等原因导致集成文件夹打包失败，则发送失败邮件至指定邮箱，以及时发现持续集成过程中的错误，对发现的错误进行及时的修改，保证集成的效率和开发产品的质量。当再次进行集成时，开发人员只需在代码仓库中提交更新的程序，jenkins便会自动进行构建和部署得到新版本安装包，快速完成构建和部署。

实施例四

图4为本发明实施例四提供的一种基于docker compose的持续集成装置的结构示意图，上述装置用于实现上述实施例提供的一种基于docker compose的持续集成方法，该装置包括：

文件建立模块410，用于在集成文件夹中建立用于配置镜像的docker compose.yml文件。

可执行程序保存模块420，用于将可执行程序保存在所述集成文件夹，并在所述docker compose.yml文件中以磁盘挂载的方式挂载。

更新程序保存模块430，用于将待集成的可执行程序的更新程序保存至所述集成文件夹。

上述方案中，可选的是，所述更新程序保存模块430具体用于：

将所述更新程序的源代码通过jenkins编译后得到的二进制程序保存至所述集成文件夹，或

将以源代码的方式运行的所述更新程序的源代码通过jenkins混淆后保存至所述集成文件夹。

上述方案中，可选的是，还包括：

集成打包模块，用于将所述集成文件夹打包为一个压缩包。

上述方案中，可选的是，还包括：

邮件发送模块，用于若所述集成文件夹打包失败，发送失败邮件。

上述方案中，可选的是，还包括：

周期确认模块，用于确认达到预设的集成周期的分界时刻。

上述装置可执行本发明任意实施例所提供的方法，具备执行上述方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本发明实施例一至三所提供的任意方法。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。