容器服务管理方法和装置
技术领域
本发明涉及存储领域,尤其涉及一种容器服务管理方法和装置。
背景技术
在使用单机进行存储,尤其是支持服务的存储时,由于单个物理磁盘的存储空间有限,因此在容器服务需要频繁升级时将占据新的存储空间,会遇到存储空间不足的问题。虽然分布式存储方案可以引入多台物理机作为后端存储,但在已经使用单机针对一个或少量用户提供云存储的情况下,分布式存储系统的引入,会增加整个服务的部署复杂度和维护成本,并带来额外的系统开销。
为此,需要一种更为简便可行的容器服务管理方案。
发明内容
为了解决如上至少一个问题,本发明提出了一种容器服务管理方案,该方案能够通过物理存储目录的映射挂载来实现针对用户透明的存储扩容,尤其适用于容器镜像仓库服务的单机扩容。
根据本发明的第一个方面,提出了一种容器服务的管理方法,包括:基于容器服务对应的第一存储空间,确定第二存储空间,所述第二存储空间包括N个物理磁盘;创建所述N个物理磁盘的挂载点目录与所述第一存储空间的文件目录的映射关系;根据所述映射关系,将所述N个物理磁盘的挂载点目录挂载到所述第一存储空间对应的文件目录。
根据本发明的第二个方面,提出了一种容器服务管理装置,包括:存储空间确定单元,用于基于容器服务对应的第一存储空间,确定第二存储空间,所述第二存储空间包括N个物理磁盘;映射关系创建单元,用于创建所述N个物理磁盘的挂载点目录与所述第一存储空间的文件目录的映射关系;以及挂载单元,用于根据所述映射关系,将所述N个物理磁盘的挂载点目录挂载到所述第一存储空间对应的文件目录。
根据本发明的第三个方面,提出了一种计算设备,包括:处理器;以及存储器,其上存储有可执行代码,当所述可执行代码被所述处理器执行时,使所述处理器执行如上第一方面所述的容器管理服务方法。
根据本发明的第四个方面,提出了一种非暂时性机器可读存储介质,其上存储有可执行代码,当所述可执行代码被电子设备的处理器执行时,使所述处理器执行如上第一方面所述的容器管理服务方法。
通过本发明的扩容方案,可以直接利用已有磁盘进行挂载映射来实现针对用户透明的存储扩容。上述存储扩容尤其适用于容器镜像仓库的单机扩容,可以在不改动服务部署和使用方式的前提下,解决单机存储容量的瓶颈问题。
附图说明
通过结合附图对本公开示例性实施方式进行更详细的描述,本公开的上述以及其它目的、特征和优势将变得更加明显,其中,在本公开示例性实施方式中,相同的参考标号通常代表相同部件。
图1示出了Docker平台的基本构成例。
图2示出了根据本发明一个实施例的容器管理服务方法的流程图。
图3示出了绑定挂载的一个例子。
图4示出了一个典型的镜像结构。
图5示出了一个镜像内部分层的层结构例。
图6示出了根据本发明一个实施例的容器服务管理装置的组成示意图。
图7示出了根据本发明一个实施例可用于实现上述容器服务管理方法的计算设备的结构示意图。
图8示出了专业云的已有存储方案。
图9示出了根据本发明的专业云优化存储例。
具体实施方式
下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式,然而应该理解,可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
在使用单机进行存储,尤其是支持服务的存储时,由于每个物理磁盘的存储空间有限,因此在服务需要频繁升级以占据新的存储空间时,会遇到存储空间不足的问题。
在支持容器镜像仓库服务时,默认使用本地磁盘作为后端存储服务,同时支持多种分布式存储后端。例如,现有容器镜像仓库服务采用本地2TB磁盘作为后端存储,而相近版本的镜像差异在几百G的量级,则本地磁盘只能支持10次以下的升级。由此可见,单机单磁盘的限制会严重影响现有容器镜像仓库服务的升级次数。
虽然分布式存储方案可以通过引入多台物理机作为后端存储来进行扩容,但在已经使用单机针对一个或少量用户提供云存储的情况下,分布式存储系统的引入,会增加整个服务的部署复杂度和维护成本,并带来额外的系统开销。
为此,本发明提出了一种容器管理服务方案,该方案能够通过针对逻辑目录的物理存储目录的挂载来实现针对用户透明的存储扩容,尤其适用于具有默认数据块存储目录命名规则的容器镜像仓库服务。
由于本发明的容器管理服务方案尤其适用于针对Docker Registry服务的单机存储扩容,因此为了方便对本发明的理解,在此首先对Docker及Docker Registry服务进行简要的介绍。应该理解的是,本发明的原理也适用于Docker Registry服务之外的其他容器管理扩容场景。
Docker是一种面向应用开发和运维人员的开发、部署和运行的容器平台,相对于Virtual Machine更加轻量,底层使用Linux Namespace(UTS、IPC、PID、Network、Mount、User)和cgroups(Control Groups)技术对应用进程进行虚拟化隔离和资源管控,并拥有灵活性、轻量、可扩展性、可伸缩性等特点。Docker容器实例从镜像加载,镜像包含应用所需的所有可执行文件、配置文件、运行时依赖库、环境变量等,这个镜像可以被加载在任何Docker引擎(Engine)机器上。越来越多的开发者和公司都将自己产品的打包成Docker镜像进行发布和销售。
Docker平台基本上由三部分组成。图1示出了Docker平台的基本构成例。如图所示,Docker平台包括客户端(Client)、Docker主机(Host)和Docker镜像仓库(registry)。用户可以使用Docker提供的工具(CLI以及API等)来构建客户端,上传镜像并发布命令来创建和启动容器。Docker主机则用于从Docker registry上下载镜像并启动容器。Dockerregistry也可称为Docker镜像仓库,用于保存镜像,并提供镜像上传和下载
在Docker平台中,提供存储、分发和管理镜像的服务为Docker Registry镜像仓库服务。Docker Registry镜像仓库,是一种集中式存储、应用无状态、节点可扩展的HTTP公共服务。提供了镜像管理、存储、上传下载、AAA认证鉴权、WebHook通知、日志等功能。
用户通过dockerbuild命令从Docker文件和“上下文”构建Docker映像,通过docker push命令把打包好的镜像(Images)发布到Docker Registry镜像仓库服务中,其他的用户通过docker pull从镜像仓库中获取镜像,并由Docker Engine启动Docker实例。
Docker Daemon是Docker架构中运行在后台的守护进程,可以接受Docker Client的请求,并进行,然后根据请求类型,创建出指定的实例并运行。容器(Container)是镜像(Image)运行时的实体。Docker容器实例从镜像加载。本发明的容器服务管理方案,尤其适用于提供针对Docker registry服务的管理,例如,用于运行该服务的存储扩容。
图2示出了根据本发明一个实施例的容器服务的管理方法的示意性流程图。该方法适用于在用于提供容器服务(例如,上述Docker Registry服务)的物理机器上进行。在不同的实施例中,涉及的可以是多台机器,但尤其适用于针对单个物理机器进行,例如,针对大数据系统中承载各个单机存储引擎的物理计算机。
在此,“单机存储”是相对于“分布式存储”的概念,指代在单机内部提供一个存储介质的界面,例如,在一台物理机器(的一块物理磁盘)上存储一个镜像及其后续升级。对于数据量比较大的系统而言,就需要对数据做拆分并放不到不同的机器上,单机存储引擎会是其基本组成组件。
在步骤S210,基于容器服务对应的第一存储空间,确定第二存储空间,所述第二存储空间包括N个物理磁盘。在此,N大于等于1。在某些实施例中,第一存储空间和第二存储空间可以位于不同的物理机器上,甚至第二存储空间所包括的N个物理磁盘也可以位于不同的物理机器上(此时,N≥2)。在一个优选实施例中,上述第一和第二存储空间可以位于同一目标设备上,第二存储空间所包括的N个物理磁盘可以看作是单机存储的扩容操作。在某些实施例中,第一存储空间内可以包括已有磁盘,例如一个已有磁盘,第二存储空间所包括的N个磁盘则可以是新添加的磁盘,例如手动添加的磁盘。在添加多个新磁盘的情况下,还可以包括为新磁盘排序的操作。应该理解的是,本发明中“第一”和“第二”旨在用于对同类中的不同对象加以区分,而非暗示两者之间存在任何前后和主次关系。
在步骤S220,创建所述N个物理磁盘的挂载点目录与所述第一存储空间的文件目录的映射关系。在步骤S230,根据所述映射关系,将所述N个物理磁盘的挂载点目录挂载到所述第一存储空间对应的文件目录。
在实际的挂载操作中,可以利用“逻辑目录”来实现针对用户透明的存储扩容。在此,“逻辑目录”是一个存储抽象概念,内核使用它作为一个固定大小的、随机访问的和成块的线性序列。磁盘设备驱动将这些块映射到底层的物理存储设备。
在一个实施例中,可以在步骤S210之前,甚至在添加所述N个物理磁盘之前,可以首先在已有磁盘中为多个目录创建逻辑目录,以方便后续扩容时的挂载。例如,可以将已有磁盘作为逻辑磁盘,并在逻辑磁盘预创建包括所述多个目录的逻辑目录。在其他实施例中,还可以将物理单机磁盘做成LVM或搭建RAID,以便将多块物理磁盘合为一块逻辑盘,但由于这种方式需要重新格式化磁盘,对运行已有服务的系统无法实施。
在不同的实施例中,逻辑目录可以与存储数据的物理目录相同或不同。于是,在本发明的一个实施例中,可以使用原始的存储目录直接作为逻辑目录,并在挂载后进行物理转存。此时,所述文件目录作为原始的物理存储目录可以包括多个目录,这多个目录各自可以存储有文件,例如存储有数据块(例如,下述的blob)。并且,所述管理方法可以包括:将所述文件目录设为逻辑目录;以及将所述逻辑目录内的数据块转存至所述挂载点目录。
在本发明的另一个实施例中,存储数据块的原始目录可以与逻辑目录不同。此时,原始的存储有数据块的目录可以存储在第一存储空间内,也可以存储在第一和第二存储空间内的其他存储空间。并且,管理方法可以包括:创建所述文件目录作为存储有数据块的多个目录的逻辑目录;以及根据所述多个目录与所述逻辑目录的对应关系,将所述多个目录内的数据块转存至所述挂载点目录。
在此,“转存”指代将至少部分目录转移存储至新添加的磁盘,例如,可以直接将至少部分目录物理移动或是复制到新添加的磁盘。留在已有磁盘中的对应内容则可在后续的操作中被盖写。
“挂载”或者“绑定挂载”则允许用户将一个目录或者文件,挂载到一个指定的目录上,并且之后在这个挂载点上的操作,只发生在被挂载的目录或者文件上,而原来挂载点的内容会被隐藏起来不受影响。图3示出了绑定挂载的一个例子。如图所示,可以将原本各自属于节点1(inode_1)和节点2(inode_2)上的/home和/test目录通过挂载命令(例如,图示的mount-bind/home/test)将/home和/test目录挂载至节点1(inode_1),并且可以通过挂载目录确定目录的层级关系,例如图示的将/test目录挂载至/home的下层。在挂载之后,用户针对/home和/test目录的操作将只发生在包括挂载点的节点1(inode_1)中。
由此,通过物理磁盘的添加、目录的转存和挂载,方便高效地实现存储扩容。
具体地,为了进行转存,可以获取所述多个目录的目录相关信息,并且获取所述N个物理磁盘的磁盘相关信息。随后,可以基于所述目录相关信息以及所述N个物理磁盘的磁盘相关信息,确定所述挂载点目录和所述文件目录的映射关系。具体地,可以计算所述挂载点目录与逻辑目录的映射关系后,可以根据所述映射关系,在所述N个磁盘中创建挂载点。于是,可以通过映射关系的计算,实现目录的合理分布。
如前所述,第一存储空间可以对应于已有磁盘。已有磁盘可以是单机中已安装的一个本地物理磁盘,或是多个本地物理磁盘。已有磁盘中优选包括存储了数据块的所述多个目录,这多个目录优选是同层目录,例如,位于同一个上级目录下的多个目录。在其他实施例中,多个目录也可以是非同级目录,甚至可以位于不同的上级目录或是不同的层级,只要这些目录彼此互斥。优选地,所述多个目录是被顺序编号的同层目录,并且所述多个目录中的每个目录中存储一个或多个数据块。
在N个物理磁盘(例如,新添加的磁盘)包括多个磁盘的情况下,映射关系的计算可以至少基于新磁盘的个数和编号加以计算。例如,在已有磁盘为一块,新添加了一块容量相同的磁盘的情况下,可以将多个目录中的一半目录转存至新磁盘。而倘若有磁盘为一块,新添加了三块容量相同的磁盘的情况下,可以将多个目录中的四分之三目录转存至新磁盘,即,每个磁盘都包括原有多个目录中的四分之一个。
在容器服务实现为DockerRegistry服务时,所述数据块可以是容器仓库中的层。于是方法还会涉及到存储扩容期间的服务关闭和启动,例如,可以在添加新磁盘之前停止物理机器(例如,单机)上的DockerRegistry服务;以及在挂载至逻辑目录之后,启动所述单机上的DockerRegistry服务。
Docker是一个容器管理框架,它负责创建和管理容器实例,一个容器实例从Docker镜像加载,镜像是一种压缩文件,包含了一个应用所需的所有内容。一个镜像可以依赖另一个镜像,并是一种单继承关系。图4示出了一个典型的镜像结构。最初始的镜像叫做基础镜像(Base Image),可以继承基础镜像制作新镜像,新镜像也可以被其他的镜像再继承,这个新镜像被称作父镜像(Parent Image),继承父镜像的新镜像被称作子镜像(ChildImage)。如图所示,alpine是基础镜像,提供了一个轻量的、安全的Linux运行环境,基础App1和基础App2都基于并共享这个基础镜像alpine,基础App1和BasicApp2可作为一个单独的镜像发布,同时也各自是进阶(Advanced)App1/2/3的父镜像。具体地,在子镜像中发展出基于基础App1的进阶App1以及基于基础App2的进阶App2和进阶App3。基础App 1/2在进阶App 1/2/3下载的时候,会检测并下载所有依赖的父镜像和基础镜像,而往往在registry存储节点里,只会存储一份父镜像实例和基础镜像,并被其他镜像所共享,高效节省存储空间。
一个镜像内部被切分称多个层(Layer),每一个层包含整个镜像的部分文件。当Docker容器实例从镜像加载后,实例将看到所有层共同合并的文件集合,实例不需要关心各个层的层级关系。镜像里面所有层的属性为只读,当前容器实例进行写操作的时候,从旧的层中进行Copy On Write(写时复制)操作,用于复制旧文件,产生新文件,并产生一层可写的新层。这种Copy On Write做法能最大化节省空间和效率,层级见也能充分复用。
图5示出了一个镜像内部分层的层结构例。
进阶App1内部文件分为4个层存储,每一个层为一个压缩类型文件,并通过文件sha256值标识,如图所示,四个层各自以其sha256值命名。所有层的文件组成了最终镜像的内容,在容器从镜像启动后,容器实例看到所有层的文件内容。如其中一层的存储如下:
$file
/var/lib/registry/docker/registry/v2/blobs/sha256/40/4001a1209541c37465e524db0b9bb20744ceb319e8303ebec3259fc8317e2dec/data
data:gzip compressed data
$sha256sum
/var/lib/registry/docker/registry/v2/blobs/sha256/40/4001a1209541c37465e524db0b9bb20744ceb319e8303ebec3259fc8317e2dec/data
4001a1209541c37465e524db0b9bb20744ceb319e8303ebec3259fc8317e2dec
在本发明中,所述多个目录的每个目录中存储一个或多个数据块。该数据块可以是如上所述的DockerRegistry中的层。在docker register服务的应用场景中,所述多个目录可以是reigistryblob的目录。在此,blob(binarylargeobject,二进制大对象)是数据块管理系统中的一个概念,指代将二进制数据存储为一个单一个体的集合(即,数据块)。为此,可以按照registry blob存储目录命名规则,计算出16*16的所有的目录组成方式,定义:blobDirs=[00,01,02…10,11,12…f0,f1,f2…fd,fe,ff],blobNum值为blobDirs组合数,其值为16*16。于是,该方法还可以包括:按照数据块文件名的起始编号,将所述数据块存储到相应编号的挂载点目录中。图中容器所涉及的四个层,各自具有以其sha256值标识的文件名。如图5所示,这四个层按照虚线框中所标识的,可知其属于数据块目录blobDir=[40],[63],[b2],[97],并且在之前或随后产生的以40、63、b2和97开头的层都应被存储至相应的目录。
如前所述,在本发明的容器服务管理方法在单机上实现时,第一和第二存储空间可以位于同一目标设备内。此时,第一存储空间包括目标设备上执行容器仓库服务的物理磁盘,所述方法还包括:在所述目标设备上的所述第二存储空间内执行所述容器仓库服务。进一步地,可以在确定所述第二存储空间之前,停止所述目标设备上的容器仓库服务,并且在将所述N个物理磁盘的挂载点目录挂载到所述第一存储空间对应的文件目录之后,启动所述目标设备上的容器仓库服务。
在更广泛的应用场景中,第一和第二存储空间可以限于同一目标设备内。此时,该方法还可以包括:在确定所述第二存储空间之前,停止所述第一存储空间对应的容器仓库服务;在将所述N个物理磁盘的挂载点目录挂载到所述第一存储空间对应的文件目录之后,启动所述第一存储空间对应的容器仓库服务。
本发明还可以实现为一种容器服务管理系统,该系统包括主节点和多个单机节点。每个单机节点与主节点相连(例如,直接或间接相连),所述主节点向所述多个单机节点发送指令(例如,直接或经由其他转发节点间接发送),以使得每个单机节点执行如上的容器服务管理方法。
图6示出了根据本发明一个实施例的容器服务管理装置的组成示意图。如图所示,容器服务管理装置600可以包括存储空间确定610、映射关系创建单元620和挂载单元630。应该理解的是,该存储装置600可以在物理单机,例如上述单机存储系统中的每个物理单机上实现,也可以在涉及多个物理设备时在作为控制节点的设备上实现。
存储空间确定单元610用于基于容器服务对应的第一存储空间,确定第二存储空间,所述第二存储空间包括N个物理磁盘。映射关系创建单元620用于创建所述N个物理磁盘的挂载点目录与所述第一存储空间的文件目录的映射关系。挂载单元630用于根据所述映射关系,将所述N个物理磁盘的挂载点目录挂载到所述第一存储空间对应的文件目录。
在一个实施例中,所述文件目录是原始数据块存储目录,并且其本身可以用作逻辑目录。此时,所述文件目录可以包括多个目录,所述多个目录存储有数据块。装置600还可以包括:逻辑目录创建单元,用于将所述文件目录设为逻辑目录;以及转存单元,用于将所述逻辑目录内的数据块转存至所述挂载点目录。
作为替换,所述文件目录是原始数据块存储目录之外的其他目录,并且可以用作逻辑目录。此时,装置600还可以包括:逻辑目录创建单元,用于创建所述文件目录作为存储有数据块的多个目录的逻辑目录;以及转存单元,根据所述多个目录与所述逻辑目录的对应关系,将所述多个目录内的数据块转存至所述挂载点目录。
进一步地,装置600还可以包括:信息获取单元,用于获取所述多个目录的目录相关信息以及所述N个物理磁盘的磁盘相关信息;以及映射关系确定单元,基于所述目录相关信息以及所述N个物理磁盘的磁盘相关信息,确定所述挂载点目录和所述文件目录的映射关系。
优选地,所述多个目录可以是被顺序编号的同层目录,并且所述多个目录中的每个目录中存储一个或多个数据块。所述数据块可以是容器仓库中的层。
在单机实现方案中,所述第一存储空间包括目标设备上执行容器仓库服务的物理磁盘,所述装置还包括:仓库服务执行单元,用于在所述目标设备上的所述第二存储空间内执行所述容器仓库服务。优选地,装置600还可以包括:服务开关单元,用于:在确定所述第二存储空间之前,停止所述目标设备上的容器仓库服务;以及在所述挂载单元完成将所述逻辑目录内的数据块转存至所述挂载点目录之后,启动所述目标设备上的容器仓库服务。
在非单机实现中,装置600还可以包括:服务开关单元,用于:在确定所述第二存储空间之前,停止所述第一存储空间对应的容器仓库服务;以及在所述挂载单元完成将所述逻辑目录内的数据块转存至所述挂载点目录之后,启动所述第一存储空间对应的容器仓库服务。
图7示出了根据本发明一个实施例可用于实现上述容器服务管理方法的计算设备的结构示意图。
参见图7,计算设备700包括存储器710和处理器720。
处理器720可以是一个多核的处理器,也可以包含多个处理器。在一些实施例中,处理器1020可以包含一个通用的主处理器以及一个或多个特殊的协处理器,例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中,处理器1020可以使用定制的电路实现,例如特定用途集成电路(ASIC,Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA,Field Programmable Gate Arrays)。
存储器710可以包括各种类型的存储单元,例如系统内存、只读存储器(ROM),和永久存储装置。其中,ROM可以存储处理器720或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中,永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中,永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备,例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外,存储器710可以包括任意计算机可读存储媒介的组合,包括各种类型的半导体存储芯片(DRAM,SRAM,SDRAM,闪存,可编程只读存储器),磁盘和/或光盘也可以采用。在一些实施方式中,存储器710可以包括可读和/或写的可移除的存储设备,例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM,双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。
存储器710上存储有可执行代码,当可执行代码被处理器720处理时,可以使处理器720执行上文述及的容器服务管理方法。
[应用例]
图8示出了专业云的已有存储方案。如图所示,256个blobDirs=[00,01,02…10,11,12…f0,f1,f2…fd,fe,ff]全都存储在单机存储设备的一个已有的物理磁盘(disk)里。
图9示出了根据本发明的专业云优化存储例。具体操作如下:
1.首先停止Docker Registry服务;
2.随后,按照指定规则获取物理磁盘数量N,并定义为:{disk1,disk2…diski…diskN},其中diski表示第i块磁盘。比如根据磁盘容量大于1.5TB的规则获取有效磁盘。在图9中示例中,N=8,例如,可以在图8原有存储的基础上,添加了7块新磁盘,由此得到8块本地磁盘;也可以直接添加8块新磁盘;
3.接下来,可以按照registry blob存储目录命名规则,计算出16*16的所有的目录组成方式,定义:blobDirs=[00,01,02…10,11,12…f0,f1,f2…fd,fe,ff],blobNum值为blobDirs组合数,其值为16*16;
4.将图8已有存储方案的Docker Registry磁盘,作为逻辑磁盘,并在逻辑磁盘预创建所有blobDirs目录。由此使得逻辑磁盘对Docker Registry服务的部署和使用完全透明,不需要有额外改造。对Docker Registry服务的区别是,之前将容器镜像存储在真实的物理磁盘,现在是存储到逻辑磁盘,再通过逻辑磁盘存储到其他多块物理磁盘;
5.随后,计算第i块磁盘中挂载点目录与逻辑磁盘映射关系,计算公式为:
blobDirs{(i-1)+N*0,(i-1)+N*1,(i-1)+N*2,(i-1)+N*3…(i-1)+N*(blobNum/N-1)},图2中假设N=8,可以得到如图9所示的映射关系,通过上面映射关系,可以将磁盘负载随机分散到多块磁盘;
6.按照第4步计算的出来的映射关系,在对应的物理磁盘创建对应的挂载点目录;
7.将原始挂载磁盘blobDirs目录中内容移动到新的物理磁盘对应的目录中;
8.使用mount--bind系统挂载工具,将物理磁盘的挂载点目录挂载到逻辑磁盘对应的目录上,挂载后的存储结构如图9所示;
9.最后,启动DockerRegistry服务,完成用户透明的存储扩容。
上文中已经参考附图详细描述了根据本发明的容器服务管理方案。通过本发明的容器服务管理方案,可以直接经由简单的新磁盘添加,在对已有应用的部署和使用不加改动或极小改动的情况下,实现存储扩容,例如针对Docker Registry服务的扩容存储。由此,使得原本只能应对例如2~7次升级的服务提升至例如添加磁盘块数使得为N=8时的30~77次。
此外,根据本发明的方法还可以实现为一种计算机程序或计算机程序产品,该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。
或者,本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质),其上存储有可执行代码(或计算机程序、或计算机指令代码),当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时,使所述处理器执行根据本发明的上述方法的各个步骤。
本领域技术人员还将明白的是,结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。
附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
以上已经描述了本发明的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。
- 上一篇:石墨接头机器人自动装卡簧、装栓机
- 下一篇:容器管理方法、装置及计算设备