一种基于Docker的项目自动化部署方法、设备及存储设备与流程

本发明涉及自动化部署领域，尤其涉及一种基于docker的项目自动化部署方法、设备及存储设备。

背景技术：

一个项目的开发者的工作大概流程是，编写代码，提交代码到github，然后编译，打包，测试，部署，发布。这其中很多重复的工作，影响开发人员的情绪，应当让开发者在做项目的时候只重视代码阶段，后面的内容不用去理会，只要编写代码，提交代码，然后就能打开页面看到效果，那是最好的。

然后现在大部分企业的项目部署还停留的手工生成发布包，手工替换文件进行部署的阶段，这样做无疑缺乏管理且容易出错，而因为构建一个可实际运行且适合企业自身环境的持续发布流程并不简单。特别是针对现在流行的敏捷开发模式导致的高频率发布需求以及多环境(开发环境、测试环境、预发布环境、线上环境等)所带来的环境差异和依赖项管理，这些都给项目应用的部署带来了高强度的工作和新的难度。

技术实现要素：

为了解决上述问题，本发明提供了一种基于docker的项目自动化部署方法、设备及存储设备，一种基于docker的项目自动化部署方法，主要包括以下步骤：

s101：存储待测试的软件代码于本地，并提交到托管平台github；github接收到软件代码后，提交发布请求至开源软件项目jenkins；

s102：jenkins接收到github发出的发布请求后，从github中获取最新的软件代码；

s103：jenkins创建一个jenkins容器，并使用docker容器作为jenkins容器的从容器slave：

s104：jenkins容器对获取的软件代码进行压缩，生成软件代码对应的发布包；

s105：docker容器构建发布包对应的docker镜像，并将构建好的docker镜像提交到docker镜像仓库；

s106：docker镜像仓库利用自动化发布脚本将所述docker镜像发布到集成测试环境中进行测试；

s107：项目自动化部署结束。

进一步地，步骤s103中，jenkins容器不存放任何和待测试的软件代码所属项目相关的数据，jenkins容器仅提供jenkins服务而不负责构建镜像，构建镜像工作由docker容器完成。

进一步地，步骤s105中，docker镜像从上往下分为三层：基础镜像层、服务镜像层和应用镜像层，下层镜像层的构建依赖于上层镜像层，越靠上层的镜像越稳定。

进一步地，步骤s106中，自动化发布脚本在本地创建，并由本地虚拟化环境来进行测试，得到测试成功的自动化发布脚本。

一种存储设备，所述存储设备存储指令及数据用于实现一种基于docker的项目自动化部署方法。

一种基于docker的项目自动化部署设备，包括：处理器及所述存储设备；所述处理器加载并执行所述存储设备中的指令及数据用于实现一种基于docker的项目自动化部署方法。

本发明提供的技术方案带来的有益效果是：本发明所提出的技术方案将解决项目开发环境的差异问题，保持多环境的一致性，最终实现项目部署的自动化流程，提高项目开发效率，减轻开发者的工作量，实用性强。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1是本发明实施例中一种基于docker的项目自动化部署方法的流程图；

图2是本发明实施例中自动化发布流程图的示意图；

图3是本发明实施例中docker镜像分层的示意图；

图4是本发明实施例中硬件设备工作的示意图。

具体实施方式

为了对本发明的技术特征、目的和效果有更加清楚的理解，现对照附图详细说明本发明的具体实施方式。

本发明的实施例提供了一种基于docker的项目自动化部署方法、设备及存储设备。

请参考图1，图1是本发明实施例中一种基于docker的项目自动化部署方法的流程图，具体包括如下步骤：

s101：存储待测试的软件代码于本地，并提交到托管平台github；github接收到软件代码后，提交发布请求至开源软件项目jenkins；

s102：jenkins接收到github发出的发布请求后，从github中获取最新的软件代码；

s103：jenkins创建一个jenkins容器，并使用docker容器作为jenkins容器的从容器slave：

s104：jenkins容器对获取的软件代码进行压缩，生成软件代码对应的发布包；

s105：docker容器构建发布包对应的docker镜像，并将构建好的docker镜像提交到docker镜像仓库；

s106：docker镜像仓库利用自动化发布脚本将所述docker镜像发布到集成测试环境中进行测试；

s107：项目自动化部署结束。

步骤s103中，jenkins容器不存放任何和待测试的软件代码所属项目相关的数据，jenkins容器仅提供jenkins服务而不负责构建镜像，构建镜像工作由docker容器完成。

步骤s105中，docker镜像从上往下分为三层：基础镜像层、服务镜像层和应用镜像层，下层镜像层的构建依赖于上层镜像层，越靠上层的镜像越稳定。

步骤s106中，自动化发布脚本在本地创建，并由本地虚拟化环境来进行测试，得到测试成功的自动化发布脚本。

请参考图2，图2是本发明实施例中自动化发布流程图的示意图，以下将针对此流程图对本发明的关键步骤做进一步的详细说明。

1.创建jenkins(一个开源软件项目，提供各种插件集成)容器

本发明把jenkins做为docker容器单独使用，这样就省去了每次安装jenkins本身及其依赖的过程，真正做到了拿来就可以使用。

jenkins容器使创建一个全新的持续集成(ci)变的非常简单，只需一行命令就可完成：

dockerrun-d-p9090:8080——namejenkinsjenkins:1.576

该命令启动jenkins容器并将容器内部8080端口重定向到主机9090端口，此时访问：主机ip:9090，就可以得到一个正在运行的jenkins服务了。

为了降低升级和维护的成本，可将构建jenkins容器的所有操作写入dockerfile并用版本工具管理，如若需要升级jenkins，只要重新build一次dockerfile，每次build时标注一个新的tag。

另外，使用dockervolume功能将外部目录挂载到jenkins_home目录(jenkins会将安装的插件等文件存放在这个目录)，这样保证了升级jenkins容器后已安装的插件都还存在。例如：将主机/usr/local/jenkins/home目录挂载到容器内部/var/lib/jenkins：

2.使用docker(一个开源的应用容器引擎)容器作为jenkins容器的slave

在使用jenkins容器时，本发明有一个原则：不在容器内部存放任何和项目相关的数据。因为运行中的容器不一定是稳定的，而docker本身也可能有bug，如果把项目数据存放在容器中，一旦出了问题，就有丢掉所有数据的风险。因此，本发明中，。jenkins容器仅负责提供jenkins服务而不负责构建，而是把构建工作代理给其他docker容器做。

例如，为了构建java项目，需要创建一个包含jdk及其构建工具的容器。依然使用dockerfile构建该容器，有了包含构建java项目的slave容器后，依然要遵循容器中不能存放项目相关数据的原则。此时，又需要借助volume。这样，在jenkinsslave中配置的job、workspace以及下载的源码都会被放置到主机目录/usr/local/jenkins/workspace下，最终达成了不在容器中放置任何项目数据的目标。

至此，本发明就成功的将一个docker容器配置成了jenkins的slave。相比直接将jenkins安装到主机上的方式，jenkins容器的解决方案带来了明显的好处：

(1)重用更加简单，只需一行命令就可获得ci的服务；

(2)升级和维护容易，只需要重新构建jenkins容器即可；

(3)灵活配置slave的能力，并可根据企业内部需要预先定制具有不同能力的slave，比如：可以创建出具有构建rubyonrails能力的slave，可以创建出具有构建nodejs能力的slave。当jenkisn需要具备某种能力的slave时，只需要dockerrun将该容器启动，并配置为slave，jenkins就立刻拥有了构建该应用的能力。

3.创建docker镜像

很多企业内部都存在一套叫做标准化的规范，在这套规范中定义了开发中所使用的语言、工具的版本信息等等，这样做可以统一开发环境并降低运维团队负担。本发明根据项目的标准化规范，创建了一系列容器并把它们按照不同的职能进行了分组，如图3所示。图3中，本发明把docker镜像分为三层：基础镜像层、服务镜像层以及应用镜像层，下层镜像的构建依赖上层镜像，越靠上层的镜像越稳定越不容易变。

(1)基础镜像层

负责配置最基本的、所有镜像都需要的软件及服务，例如前面提到的openssh-server。

(2)服务镜像层

负责构建符合企业标准化规范的镜像，这一层很像saas。

(3)应用镜像层

和应用程序直接相关，ci的产出物。

分层后，由于上层镜像已经提供了应用所需要的全部软件和服务，因此可以显著加快应用层镜像构建的速度。曾经有人担心如果在ci中构建镜像会不会太慢？经过这样的分层就可以解决这个问题。

4.更好的组织自动化发布脚本

为了更好的组织自动化发布脚本，版本化控制是必须的。本发明在项目中单独创建了一个目录：deploy，在这个目录下存放所有与发布相关的文件，包括：用于自动化发布的脚本(shell)，用于构建镜像的dockerfile，与环境相关的配置文件等等，其目录结构是：

├──readme.md

├──artifacts#war/jar，数据库迁移脚本等

├──bin#shell脚本，用于自动化构建镜像和部署

├──images#所有镜像的dockerfile

├──regions#环境相关的配置信息，我们只包含本地环境及测试环境

└──roles#角色化部署脚本，会本bin中脚本调用

这样，当需要向某一台机器上安装java和jboss镜像时，只需要这样一条命令：

bin/install.shimages-p10.1.2.15javajboss

而在部署的过程中，我们采用了角色化部署的方式，在roles目录下，它是这样的：

├──nginx

│└──deploy.sh

├──opencms

│└──deploy.sh

├──service-backend

│└──deploy.sh

├──service-web

│└──deploy.sh

└──utils.sh

这里本发明定义了四种角色：nginx，opencms，service-backend以及service-web。每个角色下都有自己的发布脚本。例如：当需要发布service-web时，可以执行命令：

bin/deploy.sh-etest-p10.1.2.15service-web

该脚本会加载由-e指定的test环境的配置信息，并将service-web部署至ip地址为10.1.2.15的机器上，而最终，bin/deploy.sh会调用每个角色下的deploy.sh脚本。角色化后，使部署变的更为清晰明了，而每个角色单独的deploy脚本更有利于划分责任避免和其他角色的干扰。

5.构建本地虚拟化环境验证脚本

脚本的编写过程很耗时，需要把脚本放在相应的环境中反复执行来验证是否工作正常。为了方便验证脚本的有效性，本发明构建了一个本地虚拟化环境，有了它，就可以在自己的机器上反复测试而不受网络和环境的影响。

由于部署脚本通常采用ssh当方式连接，所以，完全可以把这两台虚拟机看做是网络中两台机器，调用部署脚本验证是否正确。

6.构建企业内部的dockerregistry

为了更好的管理分层镜像，本发明使用dockerregistry。dockerregistry是一个镜像仓库，它允许你向registry中提交(push)镜像同时又可以从中下载(pull)。构建本地的registry非常简单，执行下面的命令：

dockerrun-p5000:5000registry

当搭建好registry后，就可以向它push镜像了。这种自动化部署流程，给整个流程带来了极大的灵活性和扩展性。

请参见图4，图4是本发明实施例的硬件设备工作示意图，所述硬件设备具体包括：一种基于docker的项目自动化部署设备401、处理器402及存储设备403。

一种基于docker的项目自动化部署设备401：所述一种基于docker的项目自动化部署设备401实现所述一种基于docker的项目自动化部署方法。

处理器402：所述处理器402加载并执行所述存储设备403中的指令及数据用于实现所述一种基于docker的项目自动化部署方法。

存储设备403：所述存储设备403存储指令及数据；所述存储设备403用于实现所述一种基于docker的项目自动化部署方法。

本发明的有益效果是：本发明所提出的技术方案将解决项目开发环境的差异问题，保持多环境的一致性，最终实现项目部署的自动化流程，提高项目开发效率，减轻开发者的工作量，实用性强。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。