CN110262809B - 基于持续集成和虚拟化容器的校园应用发布方法及系统 - Google Patents

Abstract

本公开公开了基于持续集成和虚拟化容器的校园应用发布方法及系统，包括：接收用户发布的校园应用代码，将校园应用代码存储到代码仓库；将用户发布的校园应用代码，转化为XML文件，并将XML文件发送给持续集成Jenkins；持续集成Jenkins接收到XML文件后，对XML文件进行解析，根据解析结果配合Docker虚拟化容器完成相应的操作，完成校园应用的发布；接收用户对校园应用的访问指令，根据访问指令从校园数据库中调取相应的数据，反馈给用户。

Description

基于持续集成和虚拟化容器的校园应用发布方法及系统

技术领域

本公开涉及智慧校园技术领域，特别是涉及基于持续集成和虚拟化容器的校园应用发布方法及系统。

背景技术

本部分的陈述仅仅是提到了与本公开相关的背景技术，并不必然构成现有技术。

在实现本公开的过程中，发明人发现现有技术中存在以下技术问题：

高校在推进信息化建设过程中，产生了许多信息化的产物，例如校园网、一卡通、图书馆系统、教务系统等。为了加快高校的信息化建设，各高校开始建设智慧校园，将信息化逐步推进为智慧化建设，智慧校园建立的目的是使学生和教职工在各方面受益，管理校园可用资源并通过主动服务的形势提高用户体验，智慧校园的服务范围从智慧教室到教室内的教学过程，再到整个校园。在建设中，高校建立数据中心，整合高校中已存在系统的所有数据，对这些数据获取、过滤、清洗，进而将高校中所有的数据统一管理。高校在智慧化建设过程中，除了数据中心之外，还产生了许多其他系统，这些系统在高校的环境中满足越来越多的需求，但是现阶段的高校智慧化建设仍处于起步阶段，校园中各个系统之间产生许多信息孤岛和数据冗余，难以统一和合作，不能够满足实现教学和教育信息全面现代化的需求，距离真正意义的智慧校园还有很大的差距。

智慧校园是一个在数字校园基础上发展而来。目前绝大部分高校都处在数字校园阶段，校园各种系统都是为了学生或者教职工在某些方面满足某些需求而产生的，每个系统都有一个明确的目标，后期会围绕这个目标来增添功能，一旦一个新的需求与这个目标相差甚远的时候，系统将不会添加这个功能，而是另外开发一个新的系统来满足这个需求，这种模式会使某个系统越来越庞大，难以维护，另外也会开辟越多的系统，使整个高校信息化系统错综复杂，不利于高校的智慧化建设。

现有技术亟需解决的技术问题之一是，如何让校园应用发布更加简单，让没有应用发布经验的学生群体或教师群体也可以实现校园应用的测试发布。

发明内容

为了解决现有技术的不足，本公开提供了基于持续集成和虚拟化容器的校园应用发布方法及系统；

第一方面，本公开提供了基于持续集成和虚拟化容器的校园应用发布方法；

基于持续集成和虚拟化容器的校园应用发布方法，包括：

接收用户发布的校园应用代码，将校园应用代码存储到代码仓库；

将用户发布的校园应用代码，转化为XML文件，并将XML文件发送给持续集成Jenkins；

持续集成Jenkins接收到XML文件后，对XML文件进行解析，根据解析结果配合Docker虚拟化容器完成相应的操作，完成校园应用的发布；

接收用户对校园应用的访问指令，根据访问指令从校园数据库中调取相应的数据，反馈给用户。

第二方面，本公开还提供了基于持续集成和虚拟化容器的校园应用发布系统；

基于持续集成和虚拟化容器的校园应用发布系统，包括：

第一接收模块，其被配置为接收用户发布的校园应用代码，将校园应用代码存储到代码仓库；

XML文件转化模块，其被配置为将用户发布的校园应用代码，转化为XML文件，并将XML文件发送给持续集成Jenkins；

XML文件解析模块，其被配置为持续集成Jenkins接收到XML文件后，对XML文件进行解析，根据解析结果配合Docker虚拟化容器完成相应的操作，完成校园应用的发布；

第二接收模块，其被配置为接收用户对校园应用的访问指令，根据访问指令从校园数据库中调取相应的数据，反馈给用户。

与现有技术相比，本公开的有益效果是：

无需繁琐的对每一个应用手动进行操作，例如应用代码的获取、应用运行环境的构建、应用的构建、应用的编译、应用的测试、应用的部署等过程，实现完全自动化。让校园应用发布更加简单，让没有应用发布经验的学生群体或教师群体也可以实现校园应用的测试发布。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。

图1为系统整体架构图；

图2为系统整体流程图。

具体实施方式

应该指出，以下详细说明都是示例性的，旨在对本申请提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本申请所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

敏捷开发是应用于软件开发和交付的一种迭代以及快速响应的理念，如何在不断变化的需求中快速适应和保证软件质量显得尤为重要，持续集成正是解决这一问题的软件开发实践，并且持续集成已经成为现代化软件开发的最佳实践。为了减少人工的重复性工作，降低维护工作的难度，提高工作的效率，采用持续集成的方案。智慧校园开放系统收到用户的应用配置后，通过Jenkins进行持续集成。Jenkins是一款强大的开源的持续集成工具，可以更高效的完成持续集成整个步骤，减少开发的工作，并且能够在企业中高效的进行软件开发，通过自动化的流程来节省开发人员的工作时间。当开发人员将自己的应用发布到智慧校园开放系统后，应用的部署将自动进行，开发人员不用关注应用的运维方式，把更多的关注点放到代码开发上。Jenkins将自动的执行持续集成方案，同样，当用户开发的应用需要更新时，可以重新触发持续集成方案，Jenkins也将按同样的方式部署应用，充分体现持续集成的灵活性。作为开发者可以随时在智慧校园开放系统上查看应用的各种情况，方便及时地处理出现的问题。

Docker提供了一种轻量级的应用虚拟化功能，拥有很高的资源隔离和安全保障，在操作系统虚拟化、跨系统可移植性、模块复用化、版本控制、DevOps理念等方面得到大量的实践。在智慧校园开放系统上，用户的应用架构采用微服务的形式，能够实现一种基于隐私保护的划分机制，将不同的组分分割，而Docker创建的容器是进程级别的隔离，使得应用之间互不干涉。对于Docker本身来说，它首先是跨系统的，简单易用，其次Docker解决了环境的问题，不管是Java应用、Python应用还是Node.JS应用，它只需要从Docker仓库拉取相应的镜像，配置相应的依赖就可运行。跟虚拟机相比，Docker镜像和依赖的体积往往小很多，Docker直接运行在硬件系统而不像虚拟机一样运行在中间层系统环境，它的运行效率得到很大的提高。

实施例一，本公开提供了基于持续集成和虚拟化容器的校园应用发布方法；

基于持续集成和虚拟化容器的校园应用发布方法，包括：

S1：接收用户发布的校园应用代码，将校园应用代码存储到代码仓库；

S2：将用户发布的校园应用代码，转化为XML文件，并将XML文件发送给持续集成Jenkins；

S3：持续集成Jenkins接收到XML文件后，对XML文件进行解析，根据解析结果配合Docker虚拟化容器完成相应的操作，完成校园应用的发布；

S4：接收用户对校园应用的访问指令，根据访问指令从校园数据库中调取相应的数据，反馈给用户。

作为一个或多个实施例，所述用户发布的校园应用代码，包括以下内容的一种或多种：应用名称、应用图标、代码仓库地址、应用类型、版本和当前应用对应的校园数据库的接口；

不同的接口对应不同的数据权限，例如：用户A访问第一接口得到用户A的数据，而用户B访问第二接口得到用户B的数据。

作为一个或多个实施例，所述用户发布的校园应用代码，包括四种形式：MySQL应用、Java应用、Python应用以及Node.js应用。

进一步地，MySQL应用，包括：应用名称、应用描述、MySQL版本、MySQL Root密码和初始化SQL语句。

进一步地，Java应用，包括：应用名称、应用图标、应用描述、代码仓库地址、jdk版本和maven版本。

进一步地，Python应用，包括：应用名称、应用图标、应用描述、代码仓库地址和Python版本。

进一步地，Node.js应用，包括：应用名称、应用图标、应用描述、代码仓库地址和Node版本。

作为一个或多个实施例，所述将用户发布的校园应用代码，转化为XML文件，包括：将MySQL应用转化为XML文件、将Java应用转化为XML文件、将Python应用转化为XML文件和将Node.js应用转化为XML文件。

进一步地，所述将MySQL应用转化为XML文件具体步骤包括：

S201：将初始化SQL语句分割成：数据库名称、创建数据库语句和其他语句；根据MySQL版本，构建相应的Docker镜像；

S202：使用Docker镜像，构建第一Docker容器，并且根据MySQL Root密码初始化MySQL服务；

S203：检测宿主机可用端口，记录宿主机可用端口，将宿主机可用端口映射到第一Docker容器的3306端口，建立端口映射的目的是当访问数据库地址的时候，统一访问宿主机的端口，宿主机的端口将自动寻址到第一Docker容器中的3306端口，3306为第一Docker容器内启动MySQL服务的默认密码；

S204：采用SideCar模式，建立第二Docker容器，跟第一个容器建立方式相似，使用Docker的link建立第一Docker容器与第二Docker容器之间的通信，第一Docker容器看作是MySQL的服务端，第二Docker容器看作MySQL服务的客户端，使用mysqladmin ping轮询第一Docker容器的MySQL服务，当检测第一Docker容器的MySQL服务没有正常启动时，休眠设定时间，直到第一Docker容器的MySQL服务正常启动然后执行步骤205，或者超过最大休眠时间，结束；

S205：MySQL服务正常启动后，使用mysql命令和创建数据库语句创建一个数据库；使用mysql命令和其他语句执行最后的操作；其他语句，包括建表，插入数据。

进一步地，所述将Java应用转化为XML文件具体步骤包括：

S211：根据代码仓库地址，依赖Jenkins Git插件功能，使用git命令，将代码仓库地址中的代码，全部下载到服务端应用文件夹，每个应用拥有独自的文件目录；

S212：根据Java应用的jdk版本和maven版本，构建相应的Docker镜像；

S213：使用Docker镜像，构建第三Docker容器，并且将第三Docker容器内文件目录映射到宿主机文件目录，将容器的/root/.m2文件夹映射宿主机的/root/.m2文件夹；

S214：检测宿主机可用端口，记录宿主机可用端口并且将宿主机可用端口映射到第三Docker容器的8080端口，建立端口映射的目的是当访问应用地址的时候，统一访问宿主机可用端口，宿主机可用端口将自动寻址到容器中的8080端口；

S215：将应用文件夹映射到第三Docker容器，因为S211已经将代码仓库的代码下载下来，此时在第三Docker容器中访问到代码文件；

S216：使用mvn build命令，用Maven编译用户的应用，下载的依赖文件存储在/root/.m2中；

S217：使用mvn test命令，用Maven执行应用中的单元测试，测试成功进入S218；

S218：使用mvn package命令，将应用打包，打包后的文件命名规则是[NAME]-[VERSION].jar；

S219：使用Maven和插件help:evaluate，寻找打包的文件路径，将应用的NAME和VERSION存储为临时变量；使用java–jar命令，运行应用。

进一步地，所述将Python应用转化为XML文件具体步骤包括：

S221：根据Python应用的代码仓库地址，依赖Jenkins Git插件功能，使用git命令，将代码仓库地址中的代码，全部下载到服务端应用文件夹，每个应用拥有独自的文件目录；

S222：根据Python应用的版本，构建相应的Docker镜像；使用Docker镜像，构建第四Docker容器；

S223：服务端检测宿主机可用端口，记录并且将宿主机可用端口映射到第四Docker容器的8080端口，建立端口映射的目的是当访问应用地址的时候，统一访问宿主机的端口，宿主机可用端口将自动寻址到第四Docker容器中的8080端口；

S224：将应用文件夹映射到容器，在第四Docker容器容器中访问到代码文件；

S225：使用pip install命令，用pip下载依赖文件，构建用户的应用；

S226：使用python命令，执行main.py文件，运行应用。

进一步地，所述将Node.js应用转化为XML文件具体步骤包括：

S231：根据Node.js应用的代码仓库地址，依赖Jenkins Git插件功能，使用git命令，将代码仓库地址中的代码，全部下载到服务端应用文件夹，每个应用拥有独自的文件目录；

S232：根据node版本，构建相应的Docker镜像；使用Docker镜像，构建第五Docker容器；

S233：检测宿主机可用端口，记录并且将宿主机可用端口映射到第五Docker容器的3000端口，建立端口映射的目的是当访问应用地址的时候，统一访问宿主机的可用端口，宿主机可用端口将自动寻址到第五Docker容器中的3000端口；

S234：将应用文件夹映射到容器，在第五Docker容器中访问到代码文件；

S235：使用npm install命令，用npm下载依赖文件，构建用户的应用；

S236：使用npm run build命令，用npm编译用户的应用；

S237：使用npm start命令，运行应用。

作为一个或多个实施例，根据解析结果配合Docker虚拟化容器完成相应的操作，具体步骤包括：

S31：Docker守护进程时刻监听Docker的Unix域套接字文件，通过对Unix域套接字文件的修改反向控制Docker；

在启动Jenkins容器的时候，使用Docker的目录挂载，挂载Docker的/var/run/docker.sock文件，使Jenkins有权访问Unix域套接字文件，建立与Docker的通信；

S32：Jenkins容器有权限控制Docker，控制Docker开启一个虚拟化容器并能管理虚拟化容器，控制在虚拟化容器中进行应用构建、应用编译、应用测试或应用部署操作。

图1为系统整体架构图，整个系统分为四个部分：核心系统、持续集成部分、应用部分、数据中心系统。这四部分运行在Docker环境中。用户通过移动端和PC的浏览器直接访问核心系统，这里包含用户所有的操作。核心系统通过以Jenkins Client为主的连接方式与持续集成相连，完成核心系统需要处理的持续集成工作(应用发布后的代码获取、环境构建、应用构建、应用编译、应用测试和应用部署)以及持续集成部分需要返回的各种信息(Jenkins的启动状态、Jenkins中应用的列表及应用的配置信息，应用的运行日志)。持续集成部分通过docker.sock文件连接Docker应用容器引擎所支持的应用部分，完成应用所有生命周期中的工作。应用部分中的应用为系统用户发布的应用，这些应用能够使用数据中心的数据，应用通过访问数据中心所开放的一系列接口拿到相应的数据。

持续集成部分主要使用Jenkins持续集成工具，该部分与核心系统和应用部分相连接。与核心系统通过以jenkins-client为主的连接方式连接，除此之外还有另外两种方式，模拟Jenkins的HTTP请求和jenkins原生的Jenkins API，通过这三种方式使核心端控制Jenkins进行一系列操作。

应用部分将最终运行着用户发布的应用。本系统需要保证应用与应用之间互不干涉，一个应用若是出现了各种问题，不能影响其他应用和整个系统的运行。为了让每个应用相互独立，本系统将每个应用运行在一个Docker容器中，因为Docker容器是线程级别的隔离，保证了应用之间的相互独立。应用部分会与持续集成部分相连，应用的集成的整个过程实际上也是在这个容器中进行。

图2为系统整体流程图。主要涵盖系统在发布应用与使用应用的整个流程。

系统提供各种基于智慧校园的数据接口，包含智慧校园数据中心等系统的数据，通过HTTP GET或者HTTP POST的形式获取开放的数据。用户发布的应用最终是其他用户来使用，应用不得不区分和识别当前使用该应用的用户以及获取到该用户的一些信息，这些信息都是通过数据中心系统以接口的形式获取到，用户开发应用时，将需要的接口信息嵌入到自己的应用中，从而实现相应的功能。

系统会提供所有支持的数据接口，除此之外还有系统所支持应用的代码开发规范，例如编程语言的类型和版本，使用的开发框架。代码开发规范的原则是在尽可能实现绝大多数功能的前提下，选择高效的开发框架，并且提供几种不同编程语言开发的应用示例。根据这个规范开发的应用能够发布到系统上。代码开发规范指导用户在发布应用时候的编码要求，包括应用使用的编程语言和Web框架以及相应的版本，通过代码开发规范指导用户从开发应用到应用发布的整个过程，保证应用开发的可行性。应用开发完毕之后需要将应用上传到个人的Github仓库。

服务端与Jenkins通信，Jenkins的操作通常是登录Jenkins的Web端经行操作，而系统需要服务端来操作Jenkins，完全实现自动化。

服务端与Jenkins通信采用三种通信方式：

(1)使用Jenkins-Client服务端插件，高效、稳定，但支持的请求类型有限。

(2)模拟Jenkins请求，Jenkins的操作通常是登录Jenkins的Web端经行操作的本质是HTTP请求，模拟Jenkins的HTTP操作完成相应的功能。

(3)Jenkins API，Jenkins原生的接口，本质也是HTTP请求，支持请求类型有限。

三种方式相结合，使服务端和Jenkins建立连接，优先使用的是第一种方式。

在移动端访问应用，本质是访问应用的地址，地址为服务端的HOST+应用端口。服务器核心端通过检测宿主机端口使用情况，来分配给应用不同的端口。使用Docker端口映射，映射容器内的端口。

用户发现处理发布的应用可能出现的问题；

应用可能需要更新，也可能由于其他问题启动失败。

解决方案：利用Jenkins与服务端的连接，支持查看应用持续集成的日志信息(Jenkins日志)，提供重新触发持续集成(本质是重新发布应用)。

智慧校园开放系统结合当前高校智慧校园建设，现有的校园系统可以满足校园用户的基本需求，但是仍有其他的特殊需求没有满足，这些需求或许很细微，现有的校园系统可以做到但是总不能满足所有校园用户全部的需求，它可以逐步添加用户需求的功能，但不断满足各种需求会牺牲大量的资源，集成难度大，耦合度大。

实施例二，本公开还提供了基于持续集成和虚拟化容器的校园应用发布系统；

基于持续集成和虚拟化容器的校园应用发布系统，包括：

第一接收模块，其被配置为接收用户发布的校园应用代码，将校园应用代码存储到代码仓库；

XML文件转化模块，其被配置为将用户发布的校园应用代码，转化为XML文件，并将XML文件发送给持续集成Jenkins；

XML文件解析模块，其被配置为持续集成Jenkins接收到XML文件后，对XML文件进行解析，根据解析结果配合Docker虚拟化容器完成相应的操作，完成校园应用的发布；

第二接收模块，其被配置为接收用户对校园应用的访问指令，根据访问指令从校园数据库中调取相应的数据，反馈给用户。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (9)

1.基于持续集成和虚拟化容器的校园应用发布方法，其特征是，包括：

接收用户发布的校园应用代码，将校园应用代码存储到代码仓库；

将用户发布的校园应用代码，转化为XML文件，并将XML文件发送给持续集成Jenkins；

所述用户发布的校园应用代码，包括四种形式：MySQL应用、Java应用、Python应用以及Node.js应用；

所述Node.js应用，包括：应用名称、应用图标、应用描述、代码仓库地址和Node版本；

所述将用户发布的校园应用代码，转化为XML文件，包括：将Node.js应用转化为XML文件；

所述将Node.js应用转化为XML文件具体步骤包括：

S231：根据Node.js应用的代码仓库地址，依赖Jenkins Git插件功能，使用git命令，将代码仓库地址中的代码，全部下载到服务端应用文件夹，每个应用拥有独自的文件目录；

S232：根据node版本，构建相应的Docker镜像；使用Docker镜像，构建第五Docker容器；

S233：检测宿主机可用端口，记录并且将宿主机可用端口映射到第五Docker容器的3000端口，建立端口映射的目的是当访问应用地址的时候，统一访问宿主机的可用端口，宿主机可用端口将自动寻址到第五Docker容器中的3000端口；

S234：将应用文件夹映射到容器，在第五Docker容器中访问到代码文件；

S235：使用npminstall命令，用npm下载依赖文件，构建用户的应用；

S236：使用npm run build命令，用npm编译用户的应用；

S237：使用npm start命令，运行应用；

持续集成Jenkins接收到XML文件后，对XML文件进行解析，根据解析结果配合Docker虚拟化容器完成相应的操作，完成校园应用的发布；

接收用户对校园应用的访问指令，根据访问指令从校园数据库中调取相应的数据，反馈给用户。

2.如权利要求1所述的方法，其特征是，所述用户发布的校园应用代码，包括以下内容的一种或多种：应用名称、应用图标、代码仓库地址、应用类型、版本和当前应用对应的校园数据库的接口。

3.如权利要求1所述的方法，其特征是，所述MySQL应用，包括：应用名称、应用描述、MySQL版本、MySQL Root密码和初始化SQL语句；

所述Java应用，包括：应用名称、应用图标、应用描述、代码仓库地址、jdk版本和maven版本；

所述Python应用，包括：应用名称、应用图标、应用描述、代码仓库地址和Python版本。

4.如权利要求3所述的方法，其特征是，所述将用户发布的校园应用代码，转化为XML文件，还包括：将MySQL应用转化为XML文件、将Java应用转化为XML文件和将Python应用转化为XML文件。

5.如权利要求4所述的方法，其特征是，所述将MySQL应用转化为XML文件具体步骤包括：

S201：将初始化SQL语句分割成：数据库名称、创建数据库语句和其他语句；根据MySQL版本，构建相应的Docker镜像；

S202：使用Docker镜像，构建第一Docker容器，并且根据MySQL Root密码初始化MySQL服务；

S203：检测宿主机可用端口，记录宿主机可用端口，将宿主机可用端口映射到第一Docker容器的3306端口，建立端口映射的目的是当访问数据库地址的时候，统一访问宿主机的端口，宿主机的端口将自动寻址到第一Docker容器中的3306端口，3306为第一Docker容器内启动MySQL服务的默认密码；

S204：采用SideCar模式，建立第二Docker容器，跟第一个容器建立方式相似，使用Docker的link建立第一Docker容器与第二Docker容器之间的通信，第一Docker容器看作是MySQL的服务端，第二Docker容器看作MySQL服务的客户端，使用mysqladmin ping轮询第一Docker容器的MySQL服务，当检测第一Docker容器的MySQL服务没有正常启动时，休眠设定时间，直到第一Docker容器的MySQL服务正常启动然后执行步骤205，或者超过最大休眠时间，结束；

S205：MySQL服务正常启动后，使用mysql命令和创建数据库语句创建一个数据库；使用mysql命令和其他语句执行最后的操作；其他语句，包括建表，插入数据。

6.如权利要求4所述的方法，其特征是，所述将Java应用转化为XML文件具体步骤包括：

S211：根据代码仓库地址，依赖Jenkins Git插件功能，使用git命令，将代码仓库地址中的代码，全部下载到服务端应用文件夹，每个应用拥有独自的文件目录；

S212：根据Java应用的jdk版本和maven版本，构建相应的Docker镜像；

S213：使用Docker镜像，构建第三Docker容器，并且将第三Docker容器内文件目录映射到宿主机文件目录，将容器的/root/.m2文件夹映射宿主机的/root/.m2文件夹；

S214：检测宿主机可用端口，记录宿主机可用端口并且将宿主机可用端口映射到第三Docker容器的8080端口，建立端口映射的目的是当访问应用地址的时候，统一访问宿主机可用端口，宿主机可用端口将自动寻址到容器中的8080端口；

S215：将应用文件夹映射到第三Docker容器，因为S211已经将代码仓库的代码下载下来，此时在第三Docker容器中访问到代码文件；

S216：使用mvn build命令，用Maven编译用户的应用，下载的依赖文件存储在/root/.m2中；

S217：使用mvn test命令，用Maven执行应用中的单元测试，测试成功进入S218；

S218：使用mvn package命令，将应用打包，打包后的文件命名规则是[NAME]-[VERSION].jar；

S219：使用Maven和插件help:evaluate，寻找打包的文件路径，将应用的NAME和VERSION存储为临时变量；使用java–jar命令，运行应用。

7.如权利要求4所述的方法，其特征是，所述将Python应用转化为XML文件具体步骤包括：

S221：根据Python应用的代码仓库地址，依赖Jenkins Git插件功能，使用git命令，将代码仓库地址中的代码，全部下载到服务端应用文件夹，每个应用拥有独自的文件目录；

S222：根据Python应用的版本，构建相应的Docker镜像；使用Docker镜像，构建第四Docker容器；

S223：服务端检测宿主机可用端口，记录并且将宿主机可用端口映射到第四Docker容器的8080端口，建立端口映射的目的是当访问应用地址的时候，统一访问宿主机的端口，宿主机可用端口将自动寻址到第四Docker容器中的8080端口；

S224：将应用文件夹映射到容器，在第四Docker容器容器中访问到代码文件；

S225：使用pip install命令，用pip下载依赖文件，构建用户的应用；

S226：使用python命令，执行main.py文件，运行应用。

8.如权利要求1所述的方法，其特征是，根据解析结果配合Docker虚拟化容器完成相应的操作，具体步骤包括：

S31：Docker守护进程时刻监听Docker的Unix域套接字文件，通过对Unix域套接字文件的修改反向控制Docker；

在启动Jenkins容器的时候，使用Docker的目录挂载，挂载Docker的/var/run/docker.sock文件，使Jenkins有权访问Unix域套接字文件，建立与Docker的通信；

S32：Jenkins容器有权限控制Docker，控制Docker开启一个虚拟化容器并能管理虚拟化容器，控制在虚拟化容器中进行应用构建、应用编译、应用测试或应用部署操作。

9.基于持续集成和虚拟化容器的校园应用发布系统，其特征是，包括：

第一接收模块，其被配置为接收用户发布的校园应用代码，将校园应用代码存储到代码仓库；

XML文件转化模块，其被配置为将用户发布的校园应用代码，转化为XML文件，并将XML文件发送给持续集成Jenkins；

所述用户发布的校园应用代码，包括四种形式：MySQL应用、Java应用、Python应用以及Node.js应用；

所述Node.js应用，包括：应用名称、应用图标、应用描述、代码仓库地址和Node版本；

所述将用户发布的校园应用代码，转化为XML文件，包括：将Node.js应用转化为XML文件；

所述将Node.js应用转化为XML文件具体步骤包括：

S231：根据Node.js应用的代码仓库地址，依赖Jenkins Git插件功能，使用git命令，将代码仓库地址中的代码，全部下载到服务端应用文件夹，每个应用拥有独自的文件目录；

S232：根据node版本，构建相应的Docker镜像；使用Docker镜像，构建第五Docker容器；

S233：检测宿主机可用端口，记录并且将宿主机可用端口映射到第五Docker容器的3000端口，建立端口映射的目的是当访问应用地址的时候，统一访问宿主机的可用端口，宿主机可用端口将自动寻址到第五Docker容器中的3000端口；

S234：将应用文件夹映射到容器，在第五Docker容器中访问到代码文件；

S235：使用npminstall命令，用npm下载依赖文件，构建用户的应用；

S236：使用npm run build命令，用npm编译用户的应用；

S237：使用npm start命令，运行应用；

XML文件解析模块，其被配置为持续集成Jenkins接收到XML文件后，对XML文件进行解析，根据解析结果配合Docker虚拟化容器完成相应的操作，完成校园应用的发布；

第二接收模块，其被配置为接收用户对校园应用的访问指令，根据访问指令从校园数据库中调取相应的数据，反馈给用户。

Images