CN109871258A - 基于分布式容器的修改主机配置的方法及装置 - Google Patents

Abstract

本申请提出一种基于分布式容器的修改主机配置的方法，包括以下步骤：指定各个分布式容器的配置文件，所述配置文件至少包括各分布式容器的配置项、相应分布式容器的容器名称；获取各个分布式容器所在主机的URL，并将容器所在主机的URL记录至所述配置文件中；遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；通过容器客户端实例将配置文件拷贝都相应的容器中，覆盖原有的配置文件以对容器的主机配置进行修改。本申请还提出一种基于分布式容器的修改主机配置的装置。本申请的有益效果是：能够获得方便地批量操作不同机器上的主机配置。

Description

基于分布式容器的修改主机配置的方法及装置

技术领域

本发明涉及计算机领域，尤其涉及一种基于分布式容器(Container)的修改主机配置的方法及装置。

背景技术

操作系统虚拟化通过对真实的计算机硬件设备进行模拟，使得多名用户可以分别通过虚拟化后的操作系统共享使用计算机硬件资源，从而可以高效率地利用计算机硬件资源。同时，由于操作系统虚拟化使得各应用程序及其关联性被隔离，从而每位用户如同在个人计算机上操作独立的操作系统。

例如，作为操作系统虚拟化的典型例子，虚拟机通常运行在诸如服务器等底层硬件的主机设备上，并通过虚拟机管理程序分配内存和CPU等计算机硬件资源到多台虚拟机上。因此，可以根据当前各台虚拟机所请求的计算机硬件资源，动态地进行分配。然而，为了给各位用户提供一个完整独立的应用程序运行环境，虚拟机需要同时包含完整的虚拟硬件堆栈(包括虚拟的网络适配器、存储以及CPU等)。这意味着其自身也拥有完整的操作系统，并对计算机硬件资源抽象化而进行隔离，从而需要将部分由主机设备提供的共享资源占据为自身的专用资源而降低主机设备的总体性能。

相反，作为操作系统虚拟化的另一个例子，容器是一种轻量级的操作系统虚拟化技术。各个容器通过共享主机设备上的系统内核以实现自身的轻量化，并利用进程访问控制隔离技术和进程组管理控制技术等方式隔离各自的用户空间，从而使得多套容器能够并行地运行在同一主机设备上。在现有的技术方案中，尤其在分布式环境下，由于容器的隔离性，因此容器一旦建立，其主机配置是不变的。如果由于某种原因需要修改各个容器的主机配置(例如调整服务端的测试环境)，通常的做法就是进入各个容器去修改主机配置文件。具体地，基于分布式容器的服务部署在15台机器上，即15台机器上均有容器正在运行。每台机器的容器运行环境是固定的，即其主机配置是不变的。如果服务在测试阶段需要访问某个URL，为方便验证与调试，需要将该URL指向固定ip，那么就需要增加容器内的主机配置，将该URL指向固定ip。然而，目前并没有可用的便捷工具能够在不间断容器服务的情况下，批量地修改主机配置；而在分布式主机的前提下修改多个机器的多个容器，无疑是相当繁琐的事情，尤其是多台机器可能在空间上分布相当遥远。例如，若进一步要求不暂停容器服务，测试人员只能根据上述要求，分别手动修改不同机器的不同容器内的主机配置文件。另一种在服务端测试中较为常见的场景是，相当比例的服务端其环境变量在镜像打包的时候已经设置完毕；因此，一旦需要在容器服务启动后，再次调整环境主机的设置，则需要再次打包服务端的镜像并重头配置各个分布式容器。上述操作提高了测试的成本，同时带来测试不稳定等风险(例如无法方便地回归测试验证某个版本的bug是否被解决)。

发明内容

本申请的目的是解决现有技术的不足，提供一种基于分布式容器的修改主机配置的方法及装置，能够获得方便地操作不同机器上的主机配置的效果。

为了实现上述目的，本申请采用以下的技术方案。

首先，本申请提出一种基于分布式容器的修改主机配置的方法。该方法包括以下步骤：

S100)指定各个分布式容器的配置文件，所述配置文件至少包括各分布式容器的配置项、相应分布式容器的容器名称；

S200)获取各个分布式容器所在主机的URL，并将容器所在主机的URL记录至所述配置文件中；

S300)遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；

S400)通过容器客户端实例将配置文件拷贝都相应的容器中，覆盖原有的配置文件以对容器的主机配置进行修改。

进一步地，在本申请的上述方法中，各个分布式容器的配置文件的文件路径及文件名称一并记录在所述配置文件内。

再进一步地，在本申请的上述方法中，所述配置文件以redis数据库的方式缓存。

进一步地，在本申请的上述方法中，所述步骤S300还包括以下子步骤：

S301)由Python脚本读取缓存在redis数据库内的所述配置文件；

S302)基于配置文件所记录主机的URL，通过docker-py库远程连接至各个分布式容器所在的主机；

S303)获取已远程连接主机的容器客户端实例。

进一步地，在本申请的上述方法中，所述步骤S400包括以下子步骤：

S401)获取各个分布式容器的配置文件的文件路径；

S402)调用各个容器客户端实例的接口，将指定的文件拷贝到相应容器指定的文件路径。

可替代地，在本申请的上述方法中，所述方法还包括以下后置处理步骤：

自动生成错误日志以记录配置修改失败的容器，所述错误日志至少包括相关主机的URL及失败类型。

进一步地，在本申请的上述方法中，调用各个容器客户端实例的接口执行配置文件所指示的修改时，添加版本信息到配置文件内。

其次，本申请还提出一种基于分布式容器的修改主机配置的装置。该装置可包括以下模块：初始化模块，用于指定各个分布式容器的配置文件，所述配置文件至少包括各分布式容器的配置项、相应分布式容器的容器名称；获取模块，用于获取各个分布式容器所在主机的URL，并将容器所在主机的URL记录至所述配置文件中；遍历模块，用于遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；拷贝模块，用于通过容器客户端实例将配置文件拷贝都相应的容器中，覆盖原有的配置文件以对容器的主机配置进行修改。

进一步地，在本申请的上述装置中，各个分布式容器的配置文件的文件路径及文件名称一并记录在所述配置文件内。

再进一步地，在本申请的上述装置中，所述配置文件以redis数据库的方式缓存。

进一步地，在本申请的上述装置中，所述遍历模块还可以包括以下子模块：读取模块，用于由Python脚本读取缓存在redis数据库内的所述配置文件；连接模块，用于基于配置文件所记录主机的URL，通过docker-py库远程连接至各个分布式容器所在的主机；第一执行模块，用于获取已远程连接主机的容器客户端实例。

进一步地，在本申请的上述装置中，所述拷贝模块还可以包括以下子模块：第二执行模块，用于获取各个分布式容器的配置文件的文件路径；调用模块，用于调用各个容器客户端实例的接口，将指定的文件拷贝到相应容器指定的文件路径。

可替代地，在本申请的上述装置中，所述装置还包括以下后置处理模块：日志模块，用于自动生成错误日志以记录配置修改失败的容器，所述错误日志至少包括相关主机的URL及失败类型。

进一步地，在本申请的上述装置中，调用各个容器客户端实例的接口执行配置文件所指示的修改时，添加版本信息到配置文件内。

最后，本申请还提出一种计算机可读存储介质，其上存储有计算机指令。该指令被处理器执行时实现以下方法的步骤：

S100)指定各个分布式容器的配置文件，所述配置文件至少包括各分布式容器的配置项、相应分布式容器的容器名称；

S200)获取各个分布式容器所在主机的URL，并将容器所在主机的URL记录至所述配置文件中；

S300)遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；

S400)通过容器客户端实例将配置文件拷贝都相应的容器中，覆盖原有的配置文件以对容器的主机配置进行修改。

进一步地，在本申请的上述指令被处理器执行的过程中，各个分布式容器的配置文件的文件路径及文件名称一并记录在所述配置文件内。

再进一步地，在本申请的上述指令被处理器执行的过程中，所述配置文件以redis数据库的方式缓存。

进一步地，在本申请的上述指令被处理器执行的过程中，所述步骤S300还包括以下子步骤：

S301)由Python脚本读取缓存在redis数据库内的所述配置文件；

S302)基于配置文件所记录主机的URL，通过docker-py库远程连接至各个分布式容器所在的主机；

S303)获取已远程连接主机的容器客户端实例。

进一步地，在本申请的上述指令被处理器执行的过程中，所述步骤S400包括以下子步骤：

S401)获取各个分布式容器的配置文件的文件路径；

S402)调用各个容器客户端实例的接口，将指定的文件拷贝到相应容器指定的文件路径。

可替代地，在本申请的上述指令被处理器执行的过程中，所述方法还包括以下后置处理步骤：

自动生成错误日志以记录配置修改失败的容器，所述错误日志至少包括相关主机的URL及失败类型。

进一步地，在本申请的上述指令被处理器执行的过程中，调用各个容器客户端实例的接口执行配置文件所指示的修改时，添加版本信息到配置文件内。

本申请的有益效果为：通过对分布式容器的远程连接和操控，批量地修改分布式容器所在的不同机器上的主机配置，方便地实现了运行环境的临时更改，满足了诸如测试人员做各类灰度测试的各项需求。

附图说明

图1所示为现有的虚拟机和容器结构示意图；

图2所示为本申请所公开的基于分布式容器的修改主机配置的方法流程图；

图3所示为本申请的一个实施例中，远程连接主机的子方法流程图；

图4所示为本申请的一个实施例中，覆盖主机的配置文件的子方法流程图；

图5所示为本申请所公开的基于分布式容器的修改主机配置的模块结构图。

具体实施方式

以下将结合实施例和附图对本申请的构思、具体结构及产生的技术效果进行清楚、完整的描述，以充分地理解本申请的目的、方案和效果。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，如无特殊说明，当某一特征被称为“固定”、“连接”在另一个特征，它可以直接固定、连接在另一个特征上，也可以间接地固定、连接在另一个特征上。此外，本申请中所使用的上、下、左、右等描述仅仅是相对于附图中本申请各组成部分的相互位置关系来说的。在本申请和所附权利要求书中所使用的单数形式的“一种”、“该”和“所述”也旨在包括多数形式，除非上下文清楚地表示其他含义。

此外，除非另有定义，本文所使用的所有的技术和科学术语与本技术领域的技术人员通常理解的含义相同。本文说明书中所使用的术语只是为了描述具体的实施例，而不是为了限制本申请。本文所使用的术语“和/或”包括一个或多个相关的所列项目的任意的组合。

应当理解，尽管在本申请中可能采用术语第一、第二、第三等来描述各种元件，但这些元件不应限于这些术语。这些术语仅用来将同一类型的元件彼此区分开。例如，在不脱离本申请范围的情况下，第一元件也可以被称为第二元件，类似地，第二元件也可以被称为第一元件。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”。

参考图1所示的现有的虚拟机和容器结构示意图。作为虚拟化技术的两个典型例子，虚拟机和容器包含应用程序及运行该应用程序的所必需的组件(例如系统的二进制文件及库)，并分别通过运行在物理计算机上的虚拟机监控器(Hypervisor)和容器引擎(Docker Engine)申请位于系统底层的计算机硬件资源。对于虚拟机和容器，底层的单个计算机硬件资源(例如服务器、存储设备、中央处理器、I/O端口和网络端口等)由于被虚拟化而可以充当多个可被共享的逻辑资源。同时，主机操作系统(Operation System，OS)亦可以为上述虚拟机监控器和容器引擎与底层计算机硬件资源的交互提供进一步优化。例如，主机OS可支持多个空间上相互隔离的用户通过虚拟机或容器共享底层的计算机硬件资源。其中主机OS的一些示例可以是和然而，正如前文所指出，虚拟机由于其自身操作系统需要专门占用更多的资源并包含更多的处理开销，从而降低了主机设备的总体性能。虽然容器通过共享主机OS的内核而实现自身的轻量化，但是由于容器相互之间及容器与主机之间的隔离性，因此难以实现批量增加各分布式容器所在主机配置或者改变容器所在主机指向。

因此，为了充分利用容器的轻量化优势，并实现分布式容器所在主机配置的批量修改，本申请提出了一种基于分布式容器的修改主机配置的方法。参照图2所示的方法流程图，在本申请的一个或多个实施例中，上述基于分布式容器的修改主机配置的方法包括以下步骤：

S100)指定各个分布式容器内待拉取或推送文件的文件路径及文件名称，以及拉取或推送后文件的保存位置；

S200)记录各个分布式容器的自定义名称及所在主机的URL，形成各个分布式容器的配置文件；

S300)遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；

S400)根据各个分布式容器内待拉取或推送文件的文件路径及文件名称，以及拉取或推送后文件的保存位置，通过容器客户端实例进行文件的拷贝。

具体地，各分布式容器的配置项、相应分布式容器的容器名称可采用以下方法记录在所述配置文件内。

[host]

180.25.75.251＝img.pp.pass.kingsoft.com

180.35.73.257＝img2.pp.pass.kingsoft.com

[container]

c780a139_slaver_74＝tcp://10.20.77.94:2375

c780a139_slaver_72＝tcp://10.20.69.251:2375

c780a139_slaver_73＝tcp://10.20.77.96:2375

c780a139_slaver_34＝tcp://10.20.77.99:2375

c780a139_slaver_47＝tcp://10.20.69.251:2375

c780a139_slaver_10＝tcp://10.20.75.122:2375

其中，host配置下的配置项指定运行环境需要增加的主机配置。分布式容器的维护人员可以在这里配置多个可以添加进来的主机配置。进一步地，为了提高配置文件的健壮性，host配置下的配置项甚至可以是相同的配置项，只是此时后面的配置项将覆盖前面的配置项。container配置下的配置项指定了分布式容器的自定义名称及该容器所在机器的URL。上述配置文件可以文本文件的方法存储，从而可以方便快捷地读/写该配置文件。例如分布式容器的维护人员可以动态地定期更新各台机器所分配的URL，或者增加/删除容器。可替代地，在本申请的一个或多个实施例中，上述主机配置的修改也可以直接通过批处理文件以命令行的方式实现。此时，分布式容器的维护人员只需要维护用于执行上述方法的批处理文件内与分布式容器相关的配置参数(例如上述配置项、相应分布式容器的容器名称等等)，然后再直接执行该批处理文件以实现相关主机配置的修改。在本申请的一个或多个实施例中，各个分布式容器的配置文件的文件路径及文件名称一并记录在所述配置文件内。此时，当以批处理文件执行上述主机配置的修改时，批处理文件可以直接读取配置文件内的参数执行相关操作，进一步实现程序和数据的分离。同时由于上述配置修改一旦执行即可生效，无须重启容器服务。

进一步地，在本申请的上述一个或多个实施例中，所述配置文件以redis数据库的方式缓存。尤其是当在多台分布式机器上搭建大量容器时，由于redis是一个高性能的key-value数据库，同时能够支持主从同步(即数据可以从主服务器向任意数量的从服务器上同步，且从服务器可以是关联其他从服务器的主服务器)，因此更为方便快捷地获取全部分布式容器的上述配置参数，并进行管理。

具体地，参照图3所示的子方法流程图，在本申请的上述一个或多个实施例中，所述步骤S300还包括以下子步骤：

S301)由Python脚本读取缓存在redis数据库内的所述配置文件；

S302)基于配置文件所记录主机的URL，通过docker-py库远程连接至各个分布式容器所在的主机；

S303)获取已远程连接主机的容器客户端实例。

例如，分布式容器之间的远程连接可以通过docker-py库中所提供的API接口实现。分布式容器的远程操作(例如配置文件的拷贝和覆盖)也可以通过已远程连接主机的容器客户端实例而方便地执行，从而实现多个分布式容器之间的文件拷贝转移操作。

参照图4所示的子方法流程图，在本申请的一个或多个实施例中，所述步骤S400包括以下子步骤：

S401)获取各个分布式容器的配置文件的文件路径；

S402)调用各个容器客户端实例的接口，将指定的文件拷贝到相应容器指定的文件路径。上述执行步骤可以Python脚本的方式实现，从而实现一键完成相关配置文件的推送。同时，由于上述方法所调用到的get_archive等接口都是原生的，因此相关命令的执行稳定高效，可以方便地执行诸如添加主机配置、新增服务的配置项和硬件相关的限制等修改。

进一步，在本申请的一个或多个实施例中，还可以包括以下后置处理步骤：自动生成错误日志以记录配置修改失败的容器，所述错误日志至少包括相关主机的URL及失败类型。其中，错误类型可以是包括但是不限于诸如分布式容器的各个模块之间版本不切合、机器所配置的URL错误等原因而导致利用上述docker-py库实现分布式容器之间的远程连接可能会导致失败，或者是配置文件的参数设置错误而导致的失败。错误日志还可以是空白的，表示所有分布式容器都已经正确执行上述修改。错误日志可以保存为可读的外部文件，以方便分布式容器的维护人员针对性地对跟踪调整各个分布式容器的配置。另外，在本申请的一个或多个实施例中，为方便对每次主机配置修改进行跟踪管理，可以在调用各个容器客户端实例的接口执行配置文件所指示的修改时，添加版本信息到配置文件内。

本申请还提出一种基于分布式容器的修改主机配置的装置，参照图5所示的模块结构图，在本申请的一个或多个实施例中，上述基于分布式容器的修改主机配置的装置可以包括以下模块：初始化模块，用于指定各个分布式容器的配置文件，所述配置文件至少包括各分布式容器的配置项、相应分布式容器的容器名称；获取模块，用于获取各个分布式容器所在主机的URL，并将容器所在主机的URL记录至所述配置文件中；遍历模块，用于遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；拷贝模块，用于通过容器客户端实例将配置文件拷贝都相应的容器中，覆盖原有的配置文件以对容器的主机配置进行修改。具体地，各分布式容器的配置项、相应分布式容器的容器名称可采用以下方法记录在所述配置文件内。

[host]

180.25.75.251＝img.pp.pass.kingsoft.com

180.35.73.257＝img2.pp.pass.kingsoft.com

[container]

c780a139_slaver_74＝tcp://10.20.77.94:2375

c780a139_slaver_72＝tcp://10.20.69.251:2375

c780a139_slaver_73＝tcp://10.20.77.96:2375

c780a139_slaver_34＝tcp://10.20.77.99:2375

c780a139_slaver_47＝tcp://10.20.69.251:2375

c780a139_slaver_10＝tcp://10.20.75.122:2375

其中，host配置下的配置项指定运行环境需要增加的主机配置。分布式容器的维护人员可以在这里配置多个可以添加进来的主机配置。进一步地，为了提高配置文件的健壮性，host配置下的配置项甚至可以是相同的配置项，只是此时后面的配置项将覆盖前面的配置项。container配置下的配置项指定了分布式容器的自定义名称及该容器所在机器的URL。上述配置文件可以文本文件的方法存储，从而可以方便快捷地读/写该配置文件。例如分布式容器的维护人员可以动态地定期更新各台机器所分配的URL，或者增加/删除容器。可替代地，在本申请的一个或多个实施例中，上述主机配置的修改也可以直接通过批处理文件以命令行的方式实现。此时，分布式容器的维护人员只需要维护用于执行上述方法的批处理文件内与分布式容器相关的配置参数(例如上述配置项、相应分布式容器的容器名称等等)，然后再直接执行该批处理文件以实现相关主机配置的修改。在本申请的一个或多个实施例中，各个分布式容器的配置文件的文件路径及文件名称一并记录在所述配置文件内。此时，当以批处理文件执行上述主机配置的修改时，批处理文件可以直接读取配置文件内的参数执行相关操作，进一步实现程序和数据的分离。同时由于上述配置修改一旦执行即可生效，无须重启容器服务。

进一步地，在本申请的上述一个或多个实施例中，所述配置文件以redis数据库的方式缓存。尤其是当在多台分布式机器上搭建大量容器时，由于redis是一个高性能的key-value数据库，同时能够支持主从同步(即数据可以从主服务器向任意数量的从服务器上同步，且从服务器可以是关联其他从服务器的主服务器)，因此更为方便快捷地获取全部分布式容器的上述配置参数，并进行管理。

具体地，在本申请的上述一个或多个实施例中，所述遍历模块还可以包括以下子模块：读取模块，用于由Python脚本读取缓存在redis数据库内的所述配置文件；连接模块，用于基于配置文件所记录主机的URL，通过docker-py库远程连接至各个分布式容器所在的主机；第一执行模块，用于获取已远程连接主机的容器客户端实例。例如，分布式容器之间的远程连接可以通过docker-py库中所提供的API接口实现。分布式容器的远程操作(例如配置文件的拷贝和覆盖)也可以通过已远程连接主机的容器客户端实例而方便地执行，从而实现多个分布式容器之间的文件拷贝转移操作。

在本申请的一个或多个实施例中，所述拷贝模块还可以包括以下子模块：第二执行模块，用于获取各个分布式容器的配置文件的文件路径；调用模块，用于调用各个容器客户端实例的接口，将指定的文件拷贝到相应容器指定的文件路径。上述执行步骤可以Python脚本的方式实现，从而实现一键完成相关配置文件的推送。同时，由于上述方法所调用到的get_archive等接口都是原生的，因此相关命令的执行稳定高效，可以方便地执行诸如添加主机配置、新增服务的配置项和硬件相关的限制等修改。

进一步，在本申请的一个或多个实施例中，所述装置还包括以下后置处理模块：日志模块，用于自动生成错误日志以记录配置修改失败的容器，所述错误日志至少包括相关主机的URL及失败类型。其中，错误类型可以是包括但是不限于诸如分布式容器的各个模块之间版本不切合、机器所配置的URL错误等原因而导致利用上述docker-py库实现分布式容器之间的远程连接可能会导致失败，或者是配置文件的参数设置错误而导致的失败。错误日志还可以是空白的，表示所有分布式容器都已经正确执行上述修改。错误日志可以保存为可读的外部文件，以方便分布式容器的维护人员针对性地对跟踪调整各个分布式容器的配置。另外，在本申请的一个或多个实施例中，为方便对每次主机配置修改进行跟踪管理，可以在调用各个容器客户端实例的接口执行配置文件所指示的修改时，添加版本信息到配置文件内。

应当认识到，本申请的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性计算机可读存储器中的计算机指令来实现或实施。该方法可以使用标准编程技术-包括配置有计算机程序的非暂时性计算机可读存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作——根据在具体实施例中描述的方法和附图。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。

进一步地，该方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本申请的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文该步骤的指令或程序时，本文所述的申请包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本申请所述的方法和技术编程时，本申请还包括计算机本身。

计算机程序能够应用于输入数据以执行本文所述的功能，从而转换输入数据以生成存储至非易失性存储器的输出数据。输出信息还可以应用于一个或多个输出设备如显示器。在本申请优选的实施例中，转换的数据表示物理和有形的对象，包括显示器上产生的物理和有形对象的特定视觉描绘。

因此，应以说明性意义而不是限制性意义来理解本说明书和附图。然而，将明显的是：在不脱离如权利要求书中阐述的本申请的更宽广精神和范围的情况下，可以对本申请做出各种修改和改变。

其他变型在本申请的精神内。因此，尽管所公开的技术可容许各种修改和替代构造，但在附图中已示出并且在上文中详细描述所示的其某些实施例。然而，应当理解，并不意图将本申请局限于所公开的一种或多种具体形式；相反，其意图涵盖如所附权利要求书中所限定落在本申请的精神和范围内的所有修改、替代构造和等效物。

Claims (9)

1.一种基于分布式容器的修改主机配置的方法，其特征在于，包括以下步骤：

S100)指定各个分布式容器的配置文件，所述配置文件至少包括各分布式容器的配置项、相应分布式容器的容器名称；

S200)获取各个分布式容器所在主机的URL，并将容器所在主机的URL记录至所述配置文件中；

S300)遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；

S400)通过容器客户端实例将配置文件拷贝都相应的容器中，覆盖原有的配置文件以对容器的主机配置进行修改。

2.根据权利要求1所述的方法，其特征在于，各个分布式容器的配置文件的文件路径及文件名称一并记录在所述配置文件内。

3.根据权利要求1或2所述的方法，其特征在于，所述配置文件以redis数据库的方式缓存。

4.根据权利要求3所述的方法，其特征在于，所述步骤S300还包括以下子步骤：

S301)由Python脚本读取缓存在redis数据库内的所述配置文件；

S302)基于配置文件所记录主机的URL，通过docker-py库远程连接至各个分布式容器所在的主机；

S303)获取已远程连接主机的容器客户端实例。

5.根据权利要求4中所述的方法，其特征在于，所述步骤S400包括以下子步骤：

S401)获取各个分布式容器的配置文件的文件路径；

S402)调用各个容器客户端实例的接口，将指定的文件拷贝到相应容器指定的文件路径。

6.根据权利要求4或5所述的方法，其特征在于，所述方法还包括以下后置处理步骤：

自动生成错误日志以记录配置修改失败的容器，所述错误日志至少包括相关主机的URL及失败类型。

7.根据权利要求6所述的方法，其特征在于，调用各个容器客户端实例的接口执行配置文件所指示的修改时，添加版本信息到配置文件内。

8.一种基于分布式容器的修改主机配置的装置，其特征在于，包括以下模块：

初始化模块，用于指定各个分布式容器的配置文件，所述配置文件至少包括各分布式容器的配置项、相应分布式容器的容器名称；

获取模块，用于获取各个分布式容器所在主机的URL，并将容器所在主机的URL记录至所述配置文件中；

遍历模块，用于遍历配置文件上所记录URL对应的主机以远程连接相应的主机，并生成相应的容器客户端实例；

拷贝模块，用于通过容器客户端实例将配置文件拷贝都相应的容器中，覆盖原有的配置文件以对容器的主机配置进行修改。

9.一种计算机可读存储介质，其上存储有计算机指令，其特征在于该指令被处理器执行时实现如权利要求1至7中任一项所述的方法的步骤。