CN107577475A - 一种数据中心集群系统的软件包管理方法及系统 - Google Patents

Abstract

本发明提供一种数据中心集群系统的软件包管理方法及系统，数据中心集群系统包括中心服务器以及若干个服务器节点，方法包括：接收服务器节点发送的对软件进行操作和/或运行的命令，命令包括软件的名称和版本；在所述中心服务器中创建至少一个目标容器映像，至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的所有依赖项；为服务器节点设置环境变量并挂载所述目标容器映像，以供所述服务器节点操作和/或运行软件。本发明通过利用容器的自包含、自组织、安全隔离特性，针对数据中心集群的软件同构性特点，实现带外的在线式软件包管理机制，解决了数据中心集群系统中多软件多版本、共享和隔离、安全可信、在线更新等控制管理问题。

Description

一种数据中心集群系统的软件包管理方法及系统

技术领域

本发明涉及计算机技术领域，更具体地，涉及一种数据中心集群系统的软件包管理方法及系统。

背景技术

目前各自Linux系统的发行版都有各自的软件包管理系统，这些软件包管理系统能够方便用户进行软件管理，例如deb、yum/rpm、zypper/yast/rpm，这些管理系统基于berkeley db(简称BDB)数据库实现软件包信息的存储，需在每个服务器节点上维护一个数据库(Berkeley DB)，由于安装流程、维护人员、维护方法、维护工具等多种方面的原因，很难保证数千乃至数万个数据库副本的完全一致，这导致在使用过程中，应用程序的运行在不同节点上可能发生行为不一致的情况。

数据中心集群系统中往往同时运行成千上万的服务器节点，不同服务器节点根据角色、功能、分组、用户帐号、应用背景等方面的不同，往往要求有不同的软件包视图；有些场景下会需要相同软件的不同版本共存，并在不同情况下按需激活使用；也会要求某些相同的软件版本，但其链接的底层库中间件有所不同；并且数据中心集群系统还需要维护各个软件的版本信息、安装部署等，因此需要尽可能在在各个节点上保持严格的一致性。但现有的单节点软件包管理系统已经无法满足上述需求。

发明内容

本发明提供一种克服上述问题或者至少部分地解决上述问题的数据中心集群系统的软件包管理方法及系统。

根据本发明的一个方面，提供一种数据中心集群系统的软件包管理方法，所述数据中心集群系统包括中心服务器以及与所述中心服务器连接的若干个服务器节点，所述软件包管理方法包括：

接收所述服务器节点发送的对软件进行操作和/或运行的命令，所述命令包括软件的名称和版本；

在所述中心服务器中创建至少一个目标容器映像，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的依赖项；

为所述服务器节点设置环境变量并挂载所述目标容器映像，以供所述服务器节点操作和/或运行所述软件。

优选地，所述数据中心集群系统的软件包管理方法，还包括：

当软件具有待更新的版本时，复制封装该软件的容器映像，获得容器映像的副本；

对所述容器映像的副本中的软件进行更新，获得更新后的容器映像；

当接收到服务器节点发送的对所述软件进行操作的命令时，为所述服务器节点设置环境变量并挂载所述更新后的容器映像，以供所述服务器节点操作和/或运行更新后的软件。

优选地，所述在所述中心服务器中创建至少一个目标容器映像的步骤包括：

在所述中心服务器中创建一定数量的容器映像，每个所述容器映像包含逻辑上相关的一组软件以及所述一组软件的依赖项；

搜索并计算各软件的依赖项，根据依赖项所属容器映像的不同，建立容器映像之间的引用关系，并根据所述引用关系获得容器映像的引用图；

遍历所述引用图，获得表示所述命令中的软件及依赖项的关联关系的树状图，根据所述树状图创建至少一个目标容器映像；

其中，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的所有依赖项。

优选地，所述获得更新后的容器映像的步骤，之后还包括：

根据所述树状图，对具有引用关系的容器映像以及所述更新后的容器映像的内外环境进行二进制同步，并对所述更新后的容器映像的内外环境的目录结构进行转换和映射。

优选地，所述数据中心集群系统的软件包管理方法还包括：

遍历所述引用图，获得更新的容器映像，对所述更新的容器映像进行备份。

优选地，所述数据中心集群系统的软件包管理方法还包括

接收对所述中心服务器进行测试验证的测试程序；

分别创建封装不同的测试程序和相同软件的不同测试版本的多个容器映像，作为测试容器映像；

在进行测试验证时，根据测试验证的项目，挂载对应的测试容器映像。

优选地，所述数据中心集群系统的软件包管理方法还包括：

当存在新的测试验证且已有的容器映像不能满足测试验证要求时，根据测试验证的项目，分拆已有的容器映像以组合成新的测试容器映像。

优选地，当所述数据中心集群系统存在多个中心服务器时，在所述多个中心服务器之间创建加密的数据通道，以使得容器映像在所述多个中心服务器上共享。

根据本发明的另一个方面，还提供一种数据中心集群系统的软件包管理系统，所述数据中心集群系统包括中心服务器以及与所述中心服务器连接的若干个服务器节点，所述软件包管理系统包括：

接收命令模块，用于接收所述服务器节点发送的对软件进行操作和/或运行的命令，所述命令包括软件的名称和版本；

容器映像创建模块，用于在所述中心服务器中创建至少一个目标容器映像，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的所有依赖项；

挂载模块，用于为所述服务器节点设置环境变量并挂载所述目标容器映像，以供所述服务器节点操作所述软件。

优选地，所述数据中心集群系统的软件包管理系统还包括：

复制模块，用于当软件具有待更新的版本时，复制封装该软件的容器映像，获得容器映像的副本；

更新模块，用于对所述容器映像的副本中的软件进行更新，获得更新后的容器映像；

其中，所述挂载模块还用于当接收到服务器节点发送的对所述软件进行操作的命令时，为所述服务器节点设置环境变量并挂载所述更新后的容器映像，以供所述服务器节点操作更新后的软件。

本申请提出的一种数据中心集群系统的软件包管理方法及系统，通过利用容器的自包含、自组织、安全隔离特性，针对数据中心集群的软件同构性特点，实现带外的在线式软件包管理机制，重点解决了数据中心集群系统中多软件多版本、共享和隔离、安全可信、在线更新、测试与验证、高可靠性、高可用性等一系列控制管理问题。

附图说明

图1为根据本发明实施例的软件包管理方法的流程示意图；

图2为根据本发明实施例的待更新的软件包的目录结构示意图；

图3为根据本发明实施例的引用图的结构示意图；

图4为根据本发明实施例的数据中心集群系统进行性能测试的示意图；

图5为根据本发明实施例的数据中心集群系统的用户空间隔离示意图；

图6为根据本发明实施例的跨服务器的软件包共享的拓扑结构图。

具体实施方式

下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。

针对现有技术存在的上述问题，本发明实施例提供了一种数据中心集群系统的软件包管理方法，本实施例及后续实施例所提供的方法，适用于使用基于Linux内核的类Unix操作系统的数据中心集群系统，数据中心集群系统包括至少一个中心服务器以及多个服务器节点，仅在中心服务器上维护Berkeley DB数据库，以共享的方式为所有服务器节点提供全局的软件包安装环境，通过单点维护来确保各个节点上看到的安装视图都能保持严格一致。参见图1，该软件包管理方法包括：

101、接收所述服务器节点发送的对软件进行操作和/或运行的命令，所述命令包括软件的名称和版本；

102、在所述中心服务器中创建至少一个目标容器映像，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的依赖项；

103、为所述服务器节点设置环境变量并挂载所述目标容器映像，以供所述服务器节点操作和/或运行该软件。

对于步骤101来说，服务器节点发送的命令一般来说包括安装软件、卸载软件或者更新软件等等，其中，此处所指的软件可以是中心服务器已有的软件，也可以是中心服务器尚未安装的新软件。可以理解的是，所有的软件都具有软件名称和软件版本号，一个规范的软件版本号能够直观显示软件的发布日期、软件的类型(例如是试用版还是正式版)等信息。

对于步骤102来说，Linux系统中很多软件是协同工作的，例如，软件A运行是需要使用软件B和动态库C和工具D，一般称软件A依赖于软件B和动态库C和工具D，软件B和动态库C和工具D也称之为软件A的依赖项。

容器(Docker)可以理解为接口集合，其位于中心服务器之内，由中心服务器负责加载和维护，一个容器只能存在于一个服务器之内，但一个服务器可以建立和维护多个容器。容器一般遵守可配置的原则，即容器的使用者可以通过对容器参数的配置，来达到自己的使用需求，而不需要修改容器的代码。容器通过映像文件进行分发，并通过映像仓库解决了分发问题，只要下载这个镜像，在任何装有相应环境的机器上，通过docker run就能运行起来。

在一个可选实施例中，目标容器映像的个数可以是一个也可以是多个，如果在该目标容器映像中封装有软件和该软件的所有依赖项(假设只封装一个软件)，那么目标容器映像的个数仅为1个，若根据需要将软件和软件的依赖项分别封装于不同的容器映像时，目标容器映像的个数也就不止一个。

对于步骤103来说，环境变量一般是指在操作系统中用来指定操作系统运行环境的一些参数，如：临时文件夹位置和系统文件夹位置等。环境变量是在操作系统中一个具有特定名字的对象，它包含了一个或者多个软件所将使用到的信息。

在linux操作系统中，挂载是指将一个设备(通常是存储设备)挂接到一个已存在的目录上。如果要访问存储设备中的文件，必须将文件所在的分区挂载到一个已存在的目录上，然后通过访问这个目录来访问存储设备。

需要说明的是，本发明实施例通过获取服务器节点的命令，构建封装该软件及依赖项的目标容器映像，在脱离中心服务器的具体运行环境(out of box)的前提下，通过共享方式为所有节点准备一个全局的软件包安装环境，通过单点维护(即维护中心服务器)来确保各个节点上看到的安装视图都能保持严格一致，由于目标容器映像是共享的，在服务器节点的环境里通过一个通用的mount操作，即可实现接入，无须经过额外的步骤和操作便可无缝连接到执行任务的服务器节点环境中。

进一步地，通过容器的抽象(抽象是指对一个可执行程序所完成功能的一个汇总，有些库和中间件，如果在各个领域的应用程序中都要用到，可以抽出来放在一个容器里，但逻辑上它可以属于不同的应用领域的应用程序)也可实现以公共库和中间件的共享。容器之间的依赖关系(由于软件存在互相调用的依赖关系，当软件分别打包在不同的容器中，软件所属的容器之间就会自然产生依赖)由自动计算得出，对于某些中间件、库文件都可以根据实际需要在容器之间重复副本或者直接连接到宿主环境(即容器的运行环境)的目录中。

大规模数据中心提供的是无间断服务，而复杂的软件系统往往需要持续的改进和更新，这些更新动作要求不可影响在线运行的业务。单机版的包管理系统对软件的更新要求业务暂停；而传统数据中心更新软件的方式是采取批量离线-更新-再上线的循环，这样的做法都需要人工跟踪记录整个过程，复杂且容易出错。

在上述实施例的基础上，本发明的软件包管理方法还包括：当软件具有待更新的版本时，复制封装该软件的容器映像，获得容器映像的副本；对所述容器映像的副本中的软件进行更新，获得更新后的容器映像；当接收到服务器节点发送的对所述软件进行操作的命令时，为所述服务器节点设置环境变量并挂载所述更新后的容器映像，以供所述服务器节点操作更新后的软件。

需要说明的是，因为容器映像是通过共享方式输出给服务器节点使用的，更新容器映像时可以让共享的正在使用中的容器保持不变，而重新创建一个更新的容器，当把新容器映像输出给服务器节点时，新的容器映像和旧的容器映像就可以同时工作，挂载新容器的服务器节点就自动执行新的功能，而仍挂载旧的容器的服务器节点则还可以不中断服务继续执行，直到服务器节点任务完成后，再进行新旧容器映像的切换。

本实施例提供的更新软件的方法是以逻辑上离线的方式完成更新，即以复制容器映像的方式获得容器映像的副本，对容器映像的副本进行更新，使得软件更新不需要先停止软件运行，更新任何文件都不会影响在运行的运算实例。

图2示出了本发明实施例的待更新的软件包的目录结构示意图，如图所示，cesm软件的更新前的版本(即旧版本)为4.4.6，该旧版本的cesm软件的运行依赖于mpi、esm、pop和atm这几个软件，在本实施例中mpi、esm、pop和atm软件统一封装与一个虚拟机映像中，但也可以根据需要和运行环境的变化，将这几个软件封装与其他虚拟机映像中，本发明不做进一步的限定，同时，mpi、esm、pop和atm软件的运行又进一步依赖于netcnf库，当需要更新netcnf库时，使用者不希望停止正在运行的基于netcdf-4.4.6的程序，而希望在新服务器节点或者新启动的程序能够使用新版本的netcdf库。如果对运行中的程序更新其所依赖的库，会导致出现混乱，但是通过本实施例提供的软件包更新方法，将cesm软件的容器映像复制一个副本，然后对副本进行更新，更新后的容器映像通过配置文件注册到服务器节点的用户环境中，当用户再次登录数据中心集群系统进行运算时，自动帮助用户切换到更新了版本的netcdf映像上。这种更新方法不会影响旧版本，更不会影响到运行中的旧版本程序。

在上述各实施例的基础上，步骤102中在所述中心服务器中创建至少一个目标容器映像的步骤，进一步包括：

在所述中心服务器中创建一定数量的容器映像，每个所述容器映像包含逻辑上相关的一组软件以及所述一组软件的部分依赖项；

搜索并计算各软件的依赖项，根据依赖项所属容器映像的不同，建立容器映像之间的引用关系，并根据所述引用关系获得容器映像的引用图；

遍历所述引用图，获得表示所述命令中的软件及依赖项的关联关系的树状图，根据所述树状图创建至少一个目标容器映像；

其中，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的依赖项。

需要说明的是，中心服务器首先会创建一定数量的容器映像，容器映像实际运行于数据中心的、由应用场景或管理人员决定的、逻辑上相关的一组应用程序及其依赖的库和工具等，本领域技术人员可以理解的是，应用程序与其所依赖的库和工具是否封装在同一个容器映像中，由应用场景或管理人员决定。

在Linux环境下，操作ldd命令可以搜索出应用程序所需要的依赖项，进而获得一个确定的依赖集合，在确定依赖关系后，依照依赖项所属的映像的不同，将映像之间建立关联关系，并根据所述引用关系获得容器映像的引用图。

引用图的定义为：ref_graph＝{<V,E>|V is docker iamge,E是docker映像之间的引用关系}，其中，映像为图的节点，边表示图之间的关联引用关系，例如映像X中的一个应用程序依赖于映像Y中的库，则存在一条由X指向Y的边。图3示出了引用图的结构示意图，如图3所示，Wrf表示一个天气预报软件，cesm表示一个气候模拟软件，这两个软件的运行依赖于公共数学库和基础数学库等，同时它们也依赖动态链接库，如netcdf，petsc等，netcdf是一种文件读写软件，它定义一种特殊的文件格式用于科学计算，Petsc是一种解方程的软件包，它提供基本的解方程工具，wrf/cesm等软件要运行则需借助这个软件包提供的解方程的功能，而vasp/abinit/petot都是材料/凝聚态物理领域里面用于做第一原理计算的软件，他们的运行也需要借助基础数学库提供的功能。relion，blast/clustalw等软件是生物领域用于计算结构和基因组的的软件，他们的运行也依赖公共数学库以及一些通用的算法，mpi是并行计算通信用的库，它有各种不同版本，mpich，mvapich，openmpi，intelmpi都是mpi的一种实现，他们又各有自己的不同版本。执行环境的运行需要python、java、ruby以及R语言的支持。

由图3可以看出，软件的运行需要依赖各种不同级别的库、工具、其他软件和环境，而且这种依赖是可以分类和分层次的，通过ldd命令可以找到这些软件的依赖(或者称为引用/调用)，构造出这个依赖(引用)图。而这种依赖(引用/调用)是互相交叉的，引用与被引用的关系也可能互易。

在获得引用图后，通过sub_graph命令可以获得引用图的子图，子图用来展示应用程序及其所有依赖，在本实施例中，sub_graph命令用于依据引用关系，遍历引用图的节点和边，获得表示命令中的软件及依赖项的关联关系的树状图。根据树状图创建至少一个目标容器映像，所述至少一个目标容器映像封装至少一个版本的所述软件和/或所包含的软件的依赖项。

由上述实施例可知，容器的作用在于固化软件安装的目录结构，固化每个软件的依赖关系，从而实现全局的一致性。图3示出了一个实施例维护全局一致的软件示意图，图3中同一个软件：第一原理计算具有两个不同的版本，其中一个是vasp-4.6版本，另一个为vasp-5.2版本，其中vasp-4.6版本的软件在CentOS-6.5上运行，而vasp-5.2版本在CentOS-7.3上运行，CentOS(英文全称：Community Enterprise Operating System，中文名称：社区企业操作系统)是Linux发行版之一。当需要服务器节点运行这两个不同版本的软件时，不必在意具体应用的是哪个版本，而是通过统一的命令：(/apps/vasp/bin/vasp)来运行它。此时就可以通过stage-in操作把本来属于不同版本的vasp/5.2和vasp/4.6在打包容器映像时，自动映射成统一的/apps/vasp/bin/vasp，这样在CentOS-7.3和CentOS-6.5里统一用一个命令运行软件，如此就实现了多版本多软件的全局一致性维护。

需要说明的是，stage-in操作即迁入操作，对应的还包括state-out迁出操作，迁入和迁出操作用来根据依赖关系树(即树状图)，在映像之间和映像内外环境之间进行二进制同步，并负责对其间的目录结构进行转换和映射。本领域技术人员可以理解的是，在映像之间和映像内外环境之间进行二进制同步是指映像外的目录结构转换成映像内的目录结构以及映像内的目录结构转换成映像外的目录结构，由于软件运行时对其所依赖的库的寻找是按照确定的目录结构搜索的，如果打包成映像，目录结构就要从逻辑上遵循这个预先确定的结构才能工作，保证了软件的运行。

由于数据中心可能会有大量非可信用户的登录，存在二进制文件被篡改或植入恶意代码的可能性。在一个海量应用软件安装池内扫描恶意代码是一个耗时的工作，特别是在应用程序持续集成和更新的生产型环境，这个工作会更加复杂。本发明实施例通过容器映像提供一个访问权限受控的沙箱，装载应用程序二进制代码，即解决了上述问题。

通过遍历引用图即可实现整个应用软件环境的增量备份。在上述各实施例的基础上，本实施例的软件包管理方法还包括：遍历所述引用图，获得更新的容器映像，对所述更新的容器映像进行备份。具体地，通过遍历引用图即可实现整个应用软件环境的增量备份，备份与恢复可在容器内实施也可以在容器所依赖的宿主环境中执行。备份时将容器切换为只读模式，而恢复时则可通过创建新的容器映像副本来规避对运行中容器实例的干扰。

在软件包更新后，必须经过正确性和性能的验证方可转入在线运行。当在线性能测试需要用不同版本的软件来验证同一个测试指标时，虽然这两个测试的软件版本不一样，但它们可能都依赖相同的底层库。如果在一个测试正在执行期间，想启动另外一个。传统的办法是再开启一个目录安装这个新版本的软件，然后执行测试，但是这样操作会导致新版本的软件所工作的目录结构就与先前一个版本的目录结构不一致，一旦测试通过，它们就不能平顺地、一致地迁移到生产环境里。

在上述各实施例的基础上，本实施例的软件包管理方法还包括：接收对所述中心服务器进行测试验证的测试程序，创建多个容器映像，以封装不同的测试程序和相同软件的不同测试版本；在进行测试验证时，根据测试需要挂载对应的容器映像。

需要说明的是，本发明实施例提供的将容器封装完成后再输出挂载的方式可以通过目录结构映射，就可以实现不同版本的软件包结构完全一致。做到新版本测试的运行不影响旧版本的运行，且二者能够同时在不同的服务器节点集合上运行。

在上述实施例的基础上，当存在新的测试验证且已有的容器映像不能满足测试验证要求时，根据测试验证的项目，分拆已有的容器映像以组合成新的测试容器映像，或创建新的测试容器映像。需要说明的是，通过state out迁出操作实现分拆已有的容器映像，将分拆后获得的软件、库以及工具，根据测试验证的项目，通过stage in迁入操作组合成新的测试容器映像。

图4示出了本发明实施例的数据中心集群系统进行性能测试的示意图，图4中SCStore表示由容器组成的集合(运行在中心服务器上)，类似于苹果公司的APPStore，computer node set x和computer node set y表示两个服务器节点，通过mount操作在两个服务器节点上分别挂载A集群性能测试工具和B集群性能测试工具，由图中可以看出，两个集群性能测试工具所依赖的库的版本不同(其中A工具依赖V4.1版本的intel，而B工具依赖V2.3a的mvapich)，图4的目的在于表示通过本发明实施例的容器打包后再输出挂载的方式，通过目录结构映射，就可以实现不同版本的软件包结构完全一致。做到新版本测试的运行不影响旧版本的运行，且二者能够同时在不同的服务器节点集合上运行。

由于容器能够提供隔离，用户工作所使用的软件被打包到容器映像中后，通过共享的方式，挂载到用户的服务器节点上，每个用户就只能看到和使用这个容器里提供的信息，而看不到其他用户容器里的软件和程序。图5示出了本发明实施例的数据中心集群系统的用户空间隔离示意图，如图所示，UserA使用第一原理计算软件，而UserB所属使用生物信息软件，而两个用户所用的软件基本没有交集(但二者的应用软件所调用和依赖的库可能有交集)，如果不希望UserA看到生物信息的程序，也不希望UserB看到第一原理的计算程序，通过把不同应用领域的程序打包到不同映像的方式，实现隔离。基于服务器节点在连接至中心服务器发送的命令，本软件包管理方法可以实现自动帮助用户挂载他们所需的、打包了应用软件的容器映像。

在上述各实施例的基础上，当所述数据中心集群系统存在多个中心服务器时，在所述多个中心服务器之间创建加密的数据通道，以使得容器映像在所述多个中心服务器上共享。参见图6，图6示出了本发明实施例的跨服务器的软件包共享的拓扑结构图，数据中心A具有三种不同型号的处理器，分别为intel X5670、intelE7-4830、Nvida k40，登录服务器用于与服务器节点建立连接，服务器节点上的用户通过输入登录消息至登录服务器，如果登录成功，则可以访问中心服务器，在图中以appserver表示，并行文件系统能够支持并行应用，在并行文件系统环境下，所有客户端可以在同一时间并发读写同一个文件。并发读，大部分文件系统都能够实现。相应地，数据中心B具有4个处理器(vn000000～vn040959、intelE5、intelE7和Nvidia k40)、中心服务器(swapp)和并行文件系统。在建立连接时，通过在两个登录服务器之间架设vpn隧道，使得两个登录服务器可以交换数据信息，在appserver和swapp之间架设加密的ssh隧道，就可以实现容器的共享。

本发明还提供一种数据中心集群系统的软件包管理系统，数据中心集群系统包括中心服务器以及与中心服务器连接的若干个服务器节点，软件包管理系统包括：

接收命令模块，用于接收服务器节点发送的对软件进行操作和/或运行的命令，命令包括软件的名称和版本；

容器映像创建模块，用于在中心服务器中创建至少一个目标容器映像，至少一个目标容器映像封装至少一个版本的软件和所包含的软件的所有依赖项；

挂载模块，用于为服务器节点设置环境变量并挂载目标容器映像，以供服务器节点操作和/或运行软件。

在上述实施例的基础上，软件包管理系统还包括：

复制模块，用于当软件具有待更新的版本时，复制封装该软件的容器映像，获得容器映像的副本；

更新模块，用于对容器映像的副本中的软件进行更新，获得更新后的容器映像；

其中，挂载模块还用于当接收到服务器节点发送的对软件进行操作的命令时，为服务器节点设置环境变量并挂载更新后的容器映像，以供服务器节点操作和/或运行更新后的软件。

最后，本申请的方法仅为较佳的实施方案，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据中心集群系统的软件包管理方法，所述数据中心集群系统包括中心服务器以及与所述中心服务器连接的若干个服务器节点，其特征在于，所述软件包管理方法包括：

接收所述服务器节点发送的对软件进行操作和/或运行的命令，所述命令包括软件的名称和版本；

在所述中心服务器中创建至少一个目标容器映像，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的所有依赖项；

为所述服务器节点设置环境变量并挂载所述目标容器映像，以供所述服务器节点操作和/或运行所述软件。

2.如权利要求1所述的数据中心集群系统的软件包管理方法，其特征在于，还包括：

当软件具有待更新的版本时，复制封装该软件的容器映像，获得容器映像的副本；

对所述容器映像的副本中的软件进行更新，获得更新后的容器映像；

当接收到服务器节点发送的对所述软件进行操作和/或运行的命令时，为所述服务器节点设置环境变量并挂载所述更新后的容器映像，以供所述服务器节点操作和/或运行更新后的软件。

3.如权利要求2所述的数据中心集群系统的软件包管理方法，其特征在于，所述在所述中心服务器中创建至少一个目标容器映像的步骤包括：

在所述中心服务器中创建一定数量的容器映像，每个所述容器映像包含逻辑上相关的一组软件以及所述一组软件的依赖项；

搜索并计算各软件的依赖项，根据依赖项所属容器映像的不同，建立容器映像之间的引用关系，并根据所述引用关系获得容器映像的引用图；

遍历所述引用图，获得表示所述命令中的软件及依赖项的关联关系的树状图，根据所述树状图创建至少一个目标容器映像；

其中，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的所有依赖项。

4.如权利要求3所述的数据中心集群系统的软件包管理方法，其特征在于，所述获得更新后的容器映像的步骤，之后还包括：

根据所述树状图，对具有引用关系的容器映像以及所述更新后的容器映像的内外环境进行二进制同步，并对所述更新后的容器映像的内外环境的目录结构进行转换和映射。

5.如权利要求3所述的数据中心集群系统的软件包管理方法，其特征在于，还包括：

遍历所述引用图，获得更新的容器映像，对所述更新的容器映像进行备份。

6.如权利要求2所述的数据中心集群系统的软件包管理方法，其特征在于，还包括

接收对所述中心服务器进行测试验证的测试程序；

分别创建封装不同的测试程序和相同软件的不同测试版本的多个容器映像，作为测试容器映像；

在进行测试验证时，根据测试验证的项目，挂载对应的测试容器映像。

7.如权利要求6所述的数据中心集群系统的软件包管理方法，其特征在于，还包括：

当存在新的测试验证且已有的容器映像不能满足测试验证要求时，根据测试验证的项目，分拆已有的容器映像以组合成新的测试容器映像。

8.如权利要求1-7任意一项所述的数据中心集群系统的软件包管理方法，其特征在于，当所述数据中心集群系统存在多个中心服务器时，在所述多个中心服务器之间创建加密的数据通道，以使得容器映像在所述多个中心服务器上共享。

9.一种数据中心集群系统的软件包管理系统，所述数据中心集群系统包括中心服务器以及与所述中心服务器连接的若干个服务器节点，其特征在于，所述软件包管理系统包括：

接收命令模块，用于接收所述服务器节点发送的对软件进行操作和/或运行的命令，所述命令包括软件的名称和版本；

容器映像创建模块，用于在所述中心服务器中创建至少一个目标容器映像，所述至少一个目标容器映像封装至少一个版本的所述软件和所包含的软件的所有依赖项；

挂载模块，用于为所述服务器节点设置环境变量并挂载所述目标容器映像，以供所述服务器节点操作所述软件。

10.如权利要求9所述的数据中心集群系统的软件包管理系统，其特征在于，还包括：

复制模块，用于当软件具有待更新的版本时，复制封装该软件的容器映像，获得容器映像的副本；

更新模块，用于对所述容器映像的副本中的软件进行更新，获得更新后的容器映像；

其中，所述挂载模块还用于当接收到服务器节点发送的对所述软件进行操作的命令时，为所述服务器节点设置环境变量并挂载所述更新后的容器映像，以供所述服务器节点操作更新后的软件。