本申请涉及互联网技术领域，具体涉及一种容器处理的方法。本申请同时涉及一种容器处理的装置。
背景技术：
通过容器技术部署并运行应用，以提供业务服务，是目前互联网及云计算行业中常采用的技术方案，docker容器技术是常用的容器技术。所谓应用包括网站以及其他提供服务的应用程序。提供应用服务的系统中通常会存在几十或成百上千docker容器，有的docker容器需要部署在多台服务器，例如用户认证、会员充值这类要求高可用性的业务应用需要部署到多台服务器。由于实际中往往涉及应用的更新或回退，因此对部署并运行应用的docker容器的编排是容器处理的重要内容。
目前一般使用编排工具dockercompose编排docker容器。
现有技术中，编排工具dockercompose只能编排单机容器，当需要编排多台服务器上的容器时，用户需要预先确定更新或回退的docker容器部署在了哪些服务器，在每台服务器安装dockercompose工具，因此不能以全局的方式批量编排不同服务器的容器，在更新或回退容器过程中存在易出错的问题。
技术实现要素：
本申请提供一种容器处理的方法，以解决更新或回退容器过程中容易出错的问题。
本申请提供一种容器处理的方法，包括：
确定需要更新的至少一个原容器；
根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器；
指示所述运行所述原容器的服务器更新所述原容器。
可选的，所述指示所述运行所述原容器的服务器更新所述原容器，包括：
指示所述运行所述原容器的服务器停止所述原容器；或者，
指示所述运行所述原容器的服务器删除所述原容器；或者，
指示所述运行所述原容器的服务器启动新容器。
可选的，所述指示所述运行所述原容器的服务器启动新容器，包括：
指示所述运行所述原容器的服务器从存储有镜像文件的实体，获取用于更新原容器的目标镜像文件；
指示所述运行所述原容器的服务器使用所述目标镜像文件启动新容器。
可选的，所述容器处理的方法，还包括：
向所述运行所述原容器的服务器发送测试命令；
接收所述运行所述原容器的服务器针对所述测试命令的执行结果；
根据所述命令执行结果，判断所述运行所述原容器的服务器是否成功更新所述原容器；
若判断所述运行所述原容器的服务器未成功更新所述原容器，则停止更新所述原容器。
可选的，所述容器处理的方法，还包括：
若判断所述运行所述原容器的服务器未成功更新所述原容器，则发出报警通知。
可选的，，所述确定需要更新的至少一个原容器，包括：
接收更新容器的指令；
根据所述指令，确定所述需要更新的原容器。
可选的，所述容器处理的方法，还包括：
获取用于获得更新后的容器的程序包；
根据所述程序包，构建用于更新所述原容器的目标镜像文件。
可选的，所述容器处理的方法，还包括：
指示构建镜像文件的实体，获取用于获得更新后的容器的程序包；
指示所述构建镜像文件的实体，根据所述程序包构建用于更新所述原容器的目标镜像文件。
可选的，所述容器处理的方法，还包括：
将所述目标镜像文件推送到能存储镜像文件的实体；或，
指示所述构建镜像文件的实体，将所述目标镜像文件推送到能存储镜像文件的实体。
可选的，所述存储有镜像文件的实体和/或能存储镜像文件的实体，是镜像文件仓库。
可选的，所述容器，是基于docker引擎启动运行的特定应用及特定应用的运行环境。
本申请还提供一种容器处理的装置，包括：
待更新容器确定单元，用于确定需要更新的至少一个原容器；
目标服务器确定单元，用于根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器；
更新单元，用于指示所述运行所述原容器的服务器更新所述原容器。
本申请还提供一种电子设备，包括：
存储器，以及处理器；
所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：
确定需要更新的至少一个原容器；
根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器；
指示所述运行所述原容器的服务器更新所述原容器。
本申请还提供一种存储设备，存储有指令，所述指令能够被处理器加载并执行以下步骤：
确定需要更新的至少一个原容器；
根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器；
指示所述运行所述原容器的服务器更新所述原容器。
与现有技术相比，本申请具有以下优点：
本申请提供的容器处理的方法及装置，通过根据预设的原容器与部署所述原容器的服务器的对应关系，确定需要更新或回退的docker容器部署在了哪些服务器，以全局的方式批量编排这些服务器的容器，对需要更新或回退的docker容器进行相应的更新或回退操作，从而解决了更新或回退容器过程中容易出错的问题。
附图说明
图1是本申请第一实施例提供的容器处理的方法的处理流程图；
图2是本申请第一实施例提供的容器处理的方法的实际部署系统的流程图；
图3是本申请第二实施例提供的容器处理的装置的示意图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。
本申请提供一种容器处理的方法。本申请同时涉及一种容器处理的装置。在下面的实施例中逐一进行详细说明。
本申请第一实施例提供一种容器处理的方法。
以下结合图1至图2对本申请第一实施例提供的容器处理的方法进行说明。
图1所示的容器处理的方法，包括：步骤s101至步骤s103。
步骤s101，确定需要更新的至少一个原容器。
本申请实施例中，所述容器，是基于docker引擎启动运行的特定应用及特定应用的运行环境。所述docker引擎，是运行于操作系统内核上的应用容器引擎。通过容器提供特定应用的业务服务或功能的主机称为docker主机。
将特定应用部署并运行于docker主机上，包括：将特定应用、特定应用的依赖库及运行时的配置参数打包成镜像文件(image或images)；docker主机根据所述镜像文件，通过docker从系统可用计算资源中创建或启动运行实例，从而达到运行所述特定应用以提供业务服务的目的。其中，所述运行实例即为基于docker引擎启动运行的特定应用及特定应用的运行环境的容器，也称为docker容器；所述配置参数是所述docker容器运行时的环境参数，例如，匿名卷、环境变量、用户等。每个docker容器都拥有隔离的用户空间，因此在同一主机系统上可以运行多个docker容器。docker容器不需要对操作系统内核或虚拟硬件打包，因此相比于虚拟机更为轻量化，启动速度很快。
本申请实施例提供的容器处理的方法，可以部署于docker主机，也可以部署于与docker主机通信的远程主机或服务器。当特定应用提供的业务服务需要调整时，例如，新增功能或删除功能或改变流程，则需要通过容器编排来处理提供所述业务服务的容器。所谓容器编排，是指对容器进行的处理操作，包括下述任一操作：使用指定的镜像文件启动容器、停止容器、删除容器。
本申请实施例中，对原容器进行容器编排实现原容器的更新，从而达到调整业务服务的目的。所述原容器为需要更新的容器，更新后的容器称为新容器，新容器提供的业务服务为按照需求调整后的业务服务。
本步骤是确定需要更新的原容器。
提供业务服务的特定应用往往会包括大量容器，有的容器需要部署在多个服务器上，例如用户认证、会员充值这类要求高可用性的业务服务需要部署到多台服务器。本申请实施例中通过下述处理确定需要更新的至少一个原容器：
接收更新容器的指令；
根据所述指令，确定所述需要更新的原容器。
实际部署中，部署了所述容器处理的方法的主机或服务器，可以通过处理界面输入更新容器的指令，也可以是接收与所述部署了所述容器处理的方法的主机或服务器通信的实体发送的更新容器的指令。优选的，所述确定所述需要更新的原容器，包括从所述更新容器的指令中获取需要更新的原容器的名称，以便后续用于确定部署所述原容器的服务器。
步骤s102，根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器。
本步骤是确定需要更新的原容器部署在哪些服务器上，以便更新对应服务器上的所述需要更新的原容器。这些服务器为运行docker容器的docker主机。
所述预设的原容器与部署所述原容器的服务器的对应关系，可以预存在所述部署了所述容器处理的方法的主机或服务器上，也可以是预存在与所述部署了所述容器处理的方法的主机或服务器通信的实体上。
本申请实施例中，自动从数据库中获取预先存储的预设的原容器与部署所述原容器的服务器的对应关系，根据所述对应关系确定所述原容器部署到了哪些服务器上。例如，数据库中预先录入的容器名称和所述容器名称对应的服务器。相应的，从数据库读取预先存储的所述预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器。具体的，根据步骤s102确定的需要更新的原容器的名称，从数据库中查询出部署所述需要更新的原容器的服务器。例如，容器名称为用户认证的容器，部署到服务器a和服务器b。
优选的，本申请实施例中，还包括获取原容器在对应的部署所述原容器的服务器上的部署方式。例如，原容器在对应的部署所述原容器的服务器上的配置文件，包括部署过程、监听端口、启动命令等内容，所述配置文件预存在数据库中，在确定部署所述原容器的服务器时获取到所述配置文件，则用户在所述服务器上编排所述原容器时，不需要手工编排，避免手工操作容易出错和速度慢的问题。
由于所述原容器可能部署于多台服务器，例如考虑到服务的高可用性，用户充值的容器部署于多台服务器，因此，根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器，能够使得用户不需要手工逐个确认需要编排原容器的服务器，避免了手工逐个确定需要编排原容器的服务器可能出现遗漏的风险以及速度慢的问题。
另外，自动获取预设的原容器与部署所述原容器的服务器的对应关系，使得用户编排容器时，不需要手工查询所述原容器部署到了哪些服务器，避免了手工逐个查询部署了所述原容器的服务器可能导致的遗漏的风险以及速度慢的问题。
步骤s103，指示所述运行所述原容器的服务器更新所述原容器。
本步骤是更新所述原容器，达到调整业务服务的目的。
具体到本申请实施例，所述指示所述运行所述原容器的服务器更新所述原容器，包括：
指示所述运行所述原容器的服务器停止所述原容器；或者，
指示所述运行所述原容器的服务器删除所述原容器；或者，
指示所述运行所述原容器的服务器启动新容器。
例如，对所述运行所述原容器的服务器下发停止所述原容器的命令或删除所述原容器的命令。
本申请实施例中，所述运行所述原容器的服务器由于运行docker容器，也叫docker主机。部署所述容器处理的方法的主机或服务器，指示所述运行所述原容器的服务器进行原容器的停止、删除等操作，不需要在所述运行所述原容器的服务器上安装客户端程序，可以直接处理能与部署所述容器处理的方法的主机或服务器通信的不同区域服务器的所有docker容器。
本申请实施例中，指示所述运行所述原容器的服务器使用指定的目标镜像文件启动新容器，从而按照需求调整原容器提供的业务服务。具体的，所述指示所述运行所述原容器的服务器启动新容器，包括：
指示所述运行所述原容器的服务器从存储有镜像文件的实体，获取用于更新原容器的目标镜像文件；
指示所述运行所述原容器的服务器使用所述目标镜像文件启动新容器。
优选的，所述存储有镜像文件的实体，是镜像文件仓库。
实际使用中，根据指定的目标镜像文件的版本新旧，更新原容器具体分为两种场景：当指定的目标镜像文件是根据更新后的程序构建的新镜像文件时，更新原容器又称为升级容器。当指定的目标镜像文件是历史镜像文件时，更新原容器又称为回退容器。
本申请实施例中，对于回退容器的场景，包括：
在镜像文件仓库中查询原容器对应的最近至少一个历史镜像版本，例如，支持查询15个历史镜像版本；
选择要回退的镜像版本对应的镜像文件；
指示所述运行所述原容器的服务器从所述镜像仓库拉取选中的镜像文件；
指示所述运行所述原容器的服务器使用所述选中的镜像文件启动新容器。
本申请实施例中，对于升级容器的场景，所述的处理容器的方法的一个具体实施方式还包括构建用于更新所述原容器的目标镜像文件。具体的，包括下述处理：
获取用于获得更新后的容器的程序包；
根据所述程序包，构建用于更新所述原容器的目标镜像文件。
所述用于更新所述原容器的目标镜像文件，可以是由部署了所述容器处理的方法的实体构建，还可以是由构建镜像文件的实体构建。当采用由构建镜像文件的实体构建所述目标镜像文件的方式时，所述容器处理的方法，具体包括下述处理：
指示构建镜像文件的实体，获取用于获得更新后的容器的程序包；
指示所述构建镜像文件的实体，根据所述程序包构建用于更新所述原容器的目标镜像文件。
本申请实施例中，将构建好的所述目标镜像文件存储到能存储镜像文件的实体，具体实施方式包括下述两种处理方式中的任意一种：
方式一、将所述目标镜像文件推送到能存储镜像文件的实体；
如果由部署所述容器处理的方法的主机或服务器构建所述目标镜像文件，则采用处理方式一。
方式二、指示所述构建镜像文件的实体，将所述目标镜像文件推送到能存储镜像文件的实体。
如果由构建镜像文件的实体构建所述目标镜像文件，则采用处理方式二。
优选的，所述存储能存储镜像文件的实体，是镜像文件仓库，使用所述镜像文件仓库能方便的管理维护镜像文件。相应的，所述指示所述运行所述原容器的服务器启动新容器，包括：指示所述运行所述原容器的服务器从镜像文件仓库，获取用于更新原容器的目标镜像文件。
本申请实施例中，在使用所述目标镜像文件启动新容器后还要检测虚拟容器是否启动成功。具体包括：
向所述运行所述原容器的服务器发送测试命令；
接收所述运行所述原容器的服务器针对所述测试命令的执行结果；
根据所述命令执行结果，判断所述运行所述原容器的服务器是否成功更新所述原容器；
若判断所述运行所述原容器的服务器未成功更新所述原容器，则停止更新所述原容器。
若判断所述运行所述原容器的服务器未成功更新所述原容器，则发出报警通知。
所述容器处理的方法，可以处理不同区域服务器的所有docker容器，不需要在docker主机上安装客户端程序。
举例如下：图2是本申请实施例的一个具体部署系统的处理流程图。所述容器处理的方法通过dockercon工具201实现，dockercon工具201部署于一个服务器。打包服务器202用于下发更新原容器的命令。数据库203预存了所述原容器与部署所述原容器的服务器对应关系。habor仓库204用于存储所述原容器的新镜像文件以及历史镜像文件。服务器a是第一确定的部署了所述原容器的服务器。
以需要更新名称为chains的原容器的容器升级为例说明原容器的更新流程如下：
dockercon工具201接收打包服务器202下发的更新chains的指令；
dockercon工具201从打包服务器202获取新的chains程序包；
dockercon工具201构建chains新的镜像文件并推送到harbor仓库204；
dockercon工具201去数据库203查询chains程序对应部署的服务器列表，其中包括服务器a；
dockercon工具201指示服务器a停止、删除旧容器，向服务器a发送启动新容器chains命令；
服务器a从镜像仓库拉取chains新镜像文件，启动容器chains；
dockercon工具201检测新chains容器是否启动成功，若启动失败，则停止更新，发出报警通知。
与本申请提供的一种容器处理的方法的实施例相对应，本申请第二实施例提供了一种容器处理的装置。
参照图3，其示出了根据本申请提供的一种容器处理的装置示意图。由于装置实施例基本相似于方法实施例，所以描述得比较简单，相关的部分请参见方法实施例的对应说明即可。下述描述的装置实施例仅仅是示意性的。
图3所示的容器处理的装置，包括：
待更新容器确定单元301，用于确定需要更新的至少一个原容器；
目标服务器确定单元302，用于根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器；
更新单元303，用于指示所述运行所述原容器的服务器更新所述原容器。
可选的，所述更新单元303，具体用于：
指示所述运行所述原容器的服务器停止所述原容器；或者，
指示所述运行所述原容器的服务器删除所述原容器；或者，
指示所述运行所述原容器的服务器启动新容器。
可选的，所述更新单元303，包括新容器启动子单元，用于：
指示所述运行所述原容器的服务器从存储有镜像文件的实体，获取用于更新原容器的目标镜像文件；
指示所述运行所述原容器的服务器使用所述目标镜像文件启动新容器。
可选的，所述容器处理的装置，还包括检测单元，用于：
向所述运行所述原容器的服务器发送测试命令；
接收所述运行所述原容器的服务器针对所述测试命令的执行结果；
根据所述命令执行结果，判断所述运行所述原容器的服务器是否成功更新所述原容器；
若判断所述运行所述原容器的服务器未成功更新所述原容器，则停止更新所述原容器。
可选的，所述检测单元，还包括报警子单元，用于：
若判断所述运行所述原容器的服务器未成功更新所述原容器，则发出报警通知。
检测单元，所述待更新容器确定单元301，具体用于：
接收更新容器的指令；
根据所述指令，确定所述需要更新的原容器。
可选的，所述容器处理的装置，还包括镜像构建单元，用于：
获取用于获得更新后的容器的程序包；
根据所述程序包，构建用于更新所述原容器的目标镜像文件。
可选的，所述容器处理的装置，还包括镜像远端构建单元，用于：
指示构建镜像文件的实体，获取用于获得更新后的容器的程序包；
指示所述构建镜像文件的实体，根据所述程序包构建用于更新所述原容器的目标镜像文件。
可选的，所述容器处理的装置，还包括镜像存储单元，用于：
将所述目标镜像文件推送到能存储镜像文件的实体；或，
指示所述构建镜像文件的实体，将所述目标镜像文件推送到能存储镜像文件的实体。
可选的，所述存储有镜像文件的实体和/或能存储镜像文件的实体，是镜像文件仓库。
可选的，所述容器，是基于docker引擎启动运行的特定应用及特定应用的运行环境。
本申请第三实施例还提供了一种用于实现所述容器处理的方法的电子设备。
本申请第三实施例描述得比较简单，相关的部分请参见上述提供的所述容器处理的方法的实施例的对应说明即可。
本申请第三实施例提供的电子设备，包括：
存储器，以及处理器；
所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令：
确定需要更新的至少一个原容器；
根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器；
指示所述运行所述原容器的服务器更新所述原容器。
可选的，所述处理器还具体用于执行下述计算机可执行指令：
指示所述运行所述原容器的服务器停止所述原容器；或者，
指示所述运行所述原容器的服务器删除所述原容器；或者，
指示所述运行所述原容器的服务器启动新容器。
可选的，所述指示所述运行所述原容器的服务器启动新容器，包括：
指示所述运行所述原容器的服务器从存储有镜像文件的实体，获取用于更新原容器的目标镜像文件；
指示所述运行所述原容器的服务器使用所述目标镜像文件启动新容器。
可选的，所述处理器还用于执行下述计算机可执行指令：
向所述运行所述原容器的服务器发送测试命令；
接收所述运行所述原容器的服务器针对所述测试命令的执行结果；
根据所述命令执行结果，判断所述运行所述原容器的服务器是否成功更新所述原容器；
若判断所述运行所述原容器的服务器未成功更新所述原容器，则停止更新所述原容器。
可选的，所述处理器还用于执行下述计算机可执行指令：
若判断所述运行所述原容器的服务器未成功更新所述原容器，则发出报警通知。
可选的，所述处理器还具体用于执行下述计算机可执行指令：
接收更新容器的指令；
根据所述指令，确定所述需要更新的原容器。
可选的，所述处理器还用于执行下述计算机可执行指令：
获取用于获得更新后的容器的程序包；
根据所述程序包，构建用于更新所述原容器的目标镜像文件。
可选的，所述处理器还用于执行下述计算机可执行指令：
指示构建镜像文件的实体，获取用于获得更新后的容器的程序包；
指示所述构建镜像文件的实体，根据所述程序包构建用于更新所述原容器的目标镜像文件。
可选的，所述处理器还用于执行下述计算机可执行指令：
将所述目标镜像文件推送到能存储镜像文件的实体；或，
指示所述构建镜像文件的实体，将所述目标镜像文件推送到能存储镜像文件的实体。
可选的，所述存储有镜像文件的实体和/或能存储镜像文件的实体，是镜像文件仓库。
可选的，所述容器，是基于docker引擎启动运行的特定应用及特定应用的运行环境。
本申请第四实施例提供了一种存储设备，其描述得比较简单，相关的部分请参见上述提供的所述容器处理的方法的实施例的对应说明即可。
本申请第四实施例提供一种存储设备，存储有指令，所述指令能够被处理器加载并执行以下步骤：
确定需要更新的至少一个原容器；
根据预设的原容器与部署所述原容器的服务器的对应关系，确定至少一个运行所述原容器的服务器；
指示所述运行所述原容器的服务器更新所述原容器。
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请虽然以较佳实施例公开如上，但其并不是用来限定本申请，任何本领域技术人员在不脱离本申请的精神和范围内，都可以做出可能的变动和修改，因此本申请的保护范围应当以本申请权利要求所界定的范围为准。