一种应用部署方法及装置
技术领域
本申请涉及云计算技术领域,尤其涉及一种应用部署方法及装置。
背景技术
Docker是一个开源的应用容器引擎,允许开发者打包应用到容器中,适合大规模分布式应用和大数据处理应用场景。
图1示出了现有技术中Docker管理环境的架构示意图,如图所示,包括:控制节点、容器库、配置/服务发现存储系统以及多台容器节点。其中,
(1)控制节点实现了对外的调用接口和集群内资源调度功能;
(2)容器库实现了容器的注册和发布功能,在部署容器时可直接从容器库中将相关的容器移动待部署的机器上;
(3)配置/服务发现存储系统用于共享配置并实现服务发现功能;
(4)容器节点用于实际运行Docker容器。
具体的,在每台容器节点上运行了本地容器管理模块、代理模块,其中,
(1)本地容器管理模块用于与控制节点通信,并根据控制节点的指令在本地创建容器组,容器组可以包含一个或多个容器;
(2)代理模块用于解决同一宿主机相同服务端口冲突的问题,还具备service转发服务端口来对外提供服务的能力。
目前,Docker管理环境中的这些组件通常部署在一个数据中心内部的多台物理网络互通的物理服务器或多台虚拟机上。由于管理环境部署于同一个局域网内,各物理服务器或虚拟机之间没有安全隔离机制,不同用户的应用通过容器进行隔离,因此,用户的应用存在被其他用户攻击的风险。
现有技术不足在于:
不同用户的应用通过容器隔离,导致用户的应用存在一定的安全风险。
发明内容
本申请实施例提出了一种应用部署方法及装置,以解决现有技术中不同用户的应用通过容器隔离,导致用户的应用存在一定的安全风险的技术问题。
本申请实施例提供了一种应用部署方法,可以包括如下步骤:
管理虚拟私有云VPC的控制节点接收用户的应用发布请求,所述应用发布请求中包括所述用户标识ID;
根据所述用户ID确定所述用户的用户VPC;
通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,所述应用部署消息中包括所述用户定义的应用参数;
所述本地容器管理模块根据所述用户定义的应用参数在所述虚拟机中创建容器,所述容器用于部署所述应用。
本申请实施例提供了一种应用部署装置,可以包括:
第一接收模块,用于所述管理虚拟私有云VPC的控制节点接收用户的应用发布请求,所述应用发布请求中包括所述用户标识ID;
用户VPC确定模块,用于根据所述用户ID确定所述用户的用户VPC;
第一消息发送模块,用于通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,所述应用部署消息中包括所述用户定义的应用参数;
应用部署模块,用于所述本地容器管理模块根据所述用户定义的应用参数在所述虚拟机中创建容器,所述容器用于部署所述应用。
有益效果如下:
本申请实施例所提供的应用部署方法及装置,在管理VPC的控制节点接收用户的应用发布请求后,确定所述用户的用户VPC,通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,所述本地容器管理模块根据所述用户定义的应用参数在所述虚拟机中创建容器,所述容器用于部署所述应用;由于本申请实施例通过管理VPC统一管理用户VPC的应用部署,在接收到用户的应用发布请求后通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,确保不同用户VPC之间无法通信,用户与用户之间通过VPC实现安全隔离,该用户所要发布的应用部署于该用户的用户VPC上,从而实现每个用户的应用不会被其他用户攻击的目的,提高了用户应用的安全性。
附图说明
下面将参照附图描述本申请的具体实施例,其中:
图1示出了现有技术中Docker管理环境部署的架构示意图;
图2示出了现有技术中以Kubernetes为例的Docker管理环境示意图;
图3示出了本申请实施例中应用部署方法实施的流程示意图;
图4示出了本申请实施例中Docker运行环境的示意图一;
图5示出了本申请实施例中Docker运行环境示意图二;
图6示出了本申请实施例中以Kubernetes为例的架构示意图;
图7示出了本申请实施例中应用部署装置的结构示意图。
具体实施方式
为了使本申请的技术方案及优点更加清楚明白,以下结合附图对本申请的示例性实施例进行进一步详细的说明,显然,所描述的实施例仅是本申请的一部分实施例,而不是所有实施例的穷举。并且在不冲突的情况下,本说明中的实施例及实施例中的特征可以互相结合。
发明人在发明过程中注意到:
目前kubernetes为常用的Docker容器集群管理系统,它为容器化的应用提供了资源调度、部署运行、服务发现、扩容缩容等功能。
图2示出了现有技术中以kubernetes为例的Docker管理环境示意图,如图所示,Docker管理环境可以包括控制节点kubernetes master、容器库Docker registry、高可用的键值存储系统ETCD(一个分布式强一致性的key/value存储)和多台容器节点kubernetesnode。
在kubernetes中,kubernetes master实现了API服务器server、副本控制器replication controllers、调度器scheduler等功能模块,其中:
API server作为kubernetes系统的入口,封装了核心对象的增加、删除、修改、查询操作,以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST(表述性状态转移,Representational State Transfer)对象将持久化到ETCD。
Replication Controller实现复制多个容器组POD副本,往往一个应用需要多个POD来支撑,并且可以保证其复制的副本数,即使副本所调度分配的主宿机出现异常,通过Replication Controller可以保证在其它主宿机启用同等数量的POD。
scheduler负责集群的资源调度,为新建的POD分配机器。
在容器节点上运行了本地容器管理模块kubelet、代理模块proxy,其中:
本地容器管理模块用于与控制节点(Master)通信,并根据控制节点的指令在本地创建容器组可以包含一个容器或多个相关的容器;在kubernetes中,通常以容器组(POD)为单位来进行调度;
代理模块(Proxy)用于解决同一主宿机的相同服务端口冲突的问题,还提供了Service转发服务端口对外提供服务的能力。
这些组件可以部署在一个数据中心内部的多台物理网络互通的物理服务区或虚拟机上。具体的,可以将其中某些组件部署在相同的物理机或虚拟机上,例如,将控制节点和容器库放在相同的物理机或虚拟机上,配置/服务发现存储系统在3个或3个以上的物理机或虚拟机上独立集群部署。
综上可以看出,现有Docker运行环境大多是部署在同一局域网内的物理机或虚拟机上,彼此之间可以直接通信,不同的用户的应用可以通过容器container隔离。但这种方式可能存在用户的应用被其他用户攻击的风险,不能防止来自容器的入侵,安全性较低,对于资源隔离要求高、安全性要求高的多租户场景并不适用。
为了解决上述问题,本申请实施例提出将容器container与虚拟私有云(VPC,Virtual Private Cloud)结合起来,通过VPC的机制弥补容器所固有的安全缺陷,也即,将不同用户的应用放在不同VPC的虚拟机上,同一用户的不同应用使用container隔离,以提高安全性。
本申请实施例提出的container与VPC结合的结构,即基于VPC部署用户的Docker,每个用户的容器部署在单独的VPC中保障不同用户的容器被严格的隔离起来。
要实现这样的目的,最直接的方法可以是在每个VPC中独立部署一套完整的Docker环境,即每个VPC中部署一套控制节点、容器库、配置/服务发现存储系统以及多台容器节点。
但发明人注意到,由于控制节点、容器库、配置/服务发现存储系统需要占用独立的虚拟机,多套VPC分别部署完整的Docker环境浪费较多的资源;同时,一些企业用户为了实现企业内部不同部门的隔离,可能需要同时配置多个VPC,每个VPC内均部署完整的Docker环境会导致资源浪费、成本较高。
因此,发明人想到,要实现不同用户的应用放在不同VPC的虚拟机上,同一用户的不同应用使用container进行隔离,且进一步降低资源的浪费,则需要考虑以下两方面:
(1)为了确保安全性,Docker的管理调度节点不能放在某个用户的VPC中,需要一个独立的管理VPC来存放管理调度节点,并打通管理VPC与用户VPC的网络连接,同时还要确保不同用户VPC之间的网络隔离;
(2)由于用户申请是动态的,因此,用户VPC也是被动态创建出来的,需要一个调度方法来有效的管理用户VPC中的资源,以得到Docker管理调度节点的统一管理。
基于此,本申请实施例提出了一种应用部署方法及装置,下面进行详细说明。
图3示出了本申请实施例中应用部署方法实施的流程示意图,如图所示,所述应用部署方法可以包括如下步骤:
步骤301、管理VPC的控制节点接收用户的应用发布请求,所述应用发布请求中包括所述用户标识ID;
步骤302、所述控制节点根据所述用户ID确定所述用户的用户VPC;
步骤303、所述控制节点通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,所述应用部署消息中包括所述用户定义的应用参数;
步骤304、所述本地容器管理模块根据所述用户定义的应用参数在所述虚拟机中创建容器,所述容器用于部署所述应用。
虚拟私有云(VPC)是一个公共云计算资源的动态配置池,可以通过加密协议和网络访问控制等实现网络间的安全隔离。本申请实施例中Docker运行环境包括管理VPC和用户VPC,通过用户VPC将各个用户实现隔离,以提高不同用户之间的安全性,将现有技术中的管理调度节点单独放在一个管理VPC中,以便统一管理所有用户VPC的资源。
具体实施中,每个VPC中均可以包括一个虚拟路由装置和多个虚拟机(VM,VirtualMachine)。其中,虚拟路由装置可以为虚拟路由器vRouter或者vGateway等路由设备。
本申请实施例中管理VPC可以包括两个虚拟机,一个虚拟机用于部署控制节点、用户VPC管理模块和容器库,另一个虚拟机用于部署配置服务发现存储系统等;或者,管理VPC可以包括四个虚拟机,将各个组件分别部署于所述管理VPC内不同的虚拟机上,使得所有的操作都可以在独立的虚拟系统中运行,互相不会产生任何影响;本申请实施例还可以将配置服务发现存储系统集群部署于三个或三个以上的物理机或虚拟机上。
用户VPC中可以包括多个虚拟机,每个虚拟机中又可以包括多个容器container,用户可以将该用户的不同应用分别放在不同的container中,单独存放以便于管理。
本申请实施例将现有技术中的管理调度节点和用户节点分别放在管理VPC和用户VPC中实现隔离,管理VPC统一管理用户VPC,具体实施中,可以预先在每个VPC的虚拟路由装置上进行路由设置和安全策略设置等,通过每个VPC中的虚拟路由装置将管理VPC和用户的用户VPC一对一的建立互通关系,确保网络通信的安全性。
本申请实施例中,如果某个用户想要发布应用,管理VPC的控制节点接收到该用户发布应用的请求后,所述管理VPC的控制节点通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,用户VPC虚拟机上的本地容器管理模块创建容器来部署该应用;也可以创建容器组,容器组中包括多个容器,每个容器部署不同的应用。
在具体实施中,容器组可以为POD。其中,POD是Kubernetes最基本的部署调度单元,可以包含多个container,逻辑上可以表示某个应用的一个实例。例如,一个web站点应用可以由前端、后端和数据库构建而成,这三个组件可以运行在各自的container中,那么,本申请实施例可以创建包含三个container的POD。
本申请实施例中当用户发布应用时,管理VPC中的控制节点可以统一管理POD、container、虚拟机等资源,实现管理VPC对用户VPC的统一管理、调度。
由于本申请实施例通过管理VPC统一管理用户VPC的应用部署以及资源调度等,在接收到用户的应用发布请求后通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,确保不同用户VPC之间无法通信,用户与用户之间通过VPC实现安全隔离,该用户所要发布的应用部署于该用户的用户VPC上,从而实现每个用户的应用不会被其他用户攻击的目的,提高了用户应用的安全性。
实施中,在所述管理虚拟私有云VPC的控制节点接收用户的应用发布请求之前,进一步包括:
接收用户创建请求;
管理VPC中的用户VPC管理模块为所述用户创建用户VPC,并建立所述用户VPC与所述管理VPC的安全隧道。
本申请实施例中,在接收用户的应用发布请求之前可以进一步包括,接收创建用户的请求,例如,当有新用户想要发布应用时,在应用发布请求之前,首先可以为该用户创建该用户的用户VPC,并建立所述用户的用户VPC与管理VPC之间的安全隧道。
具体实施中,管理VPC中的用户VPC管理模块可以通过调用IaaS(基础设施即服务,Infrastructure as a Service)云平台API(应用程序编程接口,ApplicationProgramming Interface)申请并创建一个用户VPC和该用户VPC的虚拟路由装置,设置该用户VPC的虚拟路由装置与管理VPC的虚拟路由装置之间的路由和安全策略;存储该用户的标识ID和用户VPC的ID之间的对应关系。
本申请实施例中为每个用户创建其自身的用户VPC,以部署用户自己的应用,并建立用户VPC与管理VPC之间的安全隧道,由管理VPC统一管理用户VPC,从而提高管理效率、提高安全性。
实施中,所述用户VPC可以为多个,所述管理VPC与所述用户VPC之间的存在安全隧道具体可以为,所述管理VPC的虚拟路由装置分别与各用户VPC的虚拟路由装置之间存在路由,各用户VPC之间不存在路由。
本申请实施例中的用户VPC可以为多个,当有N个用户时,用户VPC也可以相应的存在N个,不同用户的应用存放在不同用户VPC的虚拟机上,即,用户i的应用可以存放在用户VPCi上,所述管理VPC的虚拟路由装置分别与各用户VPC的虚拟路由装置之间存在路由,各用户VPC之间不存在路由,从而确保各个用户之间安全隔离,避免某个用户被其他用户攻击的情况。
具体实施中,可以通过在管理VPC的虚拟路由装置上设置安全路由策略,使得不同用户VPC之间不存在路由,也可以将管理VPC的虚拟路由装置设置为不具备路由转发功能,防止不用用户VPC通过管理VPC转发实现通信,进一步提高用户应用的安全性。
本申请实施例中,管理VPC与多个用户VPC之间均可以互通,即,管理VPC与用户VPC可以是一对多的关系,多个用户VPC之间不存在互通关系,每个用户VPC可以与管理VPC互通,即,某个用户VPC与管理VPC是一对一的关系。采用这样的路由方式,可以确保多个用户被管理VPC统一管理,且多个用户之间实现安全隔离。
实施中,当所述管理VPC的控制节点接收用户的应用发布请求为首次时,在所述根据所述用户ID确定所述用户的用户VPC之后,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息之前,所述方法可以进一步包括:
所述管理VPC的用户VPC管理模块在所述用户VPC中创建虚拟机,所述虚拟机中部署有本地容器管理模块;
所述管理VPC的用户VPC管理模块建立所述本地容器管理模块与所述管理VPC的控制节点之间的通信。
具体实施中,在新用户完成注册后,即,为新用户创建该用户的用户VPC之后,如果用户第一次发起应用发布请求,本申请实施例中所述用户VPC管理模块可以在该用户的用户VPC中创建部署有本地容器管理模块的虚拟机,并建立所述用户VPC的虚拟机中的本地容器管理模块与所述管理VPC的控制节点之间的通信,以便所述管理VPC可以统一管理所述用户VPC的虚拟机。
实施中,所述向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,具体可以为:
所述管理VPC的控制节点根据所述用户VPC中虚拟机的资源使用情况确定所述用户VPC中用于部署所述应用的虚拟机ID;
所述管理VPC的控制节点根据所述虚拟机ID向所述虚拟机的本地容器管理模块发送应用部署消息。
具体实施中,所述管理VPC的控制节点可以监控、记录所述用户VPC中各个虚拟机的资源使用情况,例如,可以包括:CPU、内存、硬盘、网络等信息;然后,所述控制节点可以根据所述用户VPC中虚拟机的资源使用情况,来判断当前所述用户VPC的虚拟机是否可以满足所述应用的部署需求:
如果当前所述用户VPC的虚拟机不能满足所述应用的部署需求,则可以通知所述管理VPC的用户VPC管理模块来创建新的虚拟机,新的虚拟机可以满足所述应用的部署需求,以达到部署所述应用的目的;
如果当前所述用户VPC的虚拟机可以满足所述应用的部署需求,那么,控制节点可以进一步根据负载均衡等策略来选择用于部署所述应用的虚拟机,确定所述虚拟机ID;最后,根据所述虚拟机ID向该虚拟机上的本地容器管理模块发送应用部署消息。
所述虚拟机上的本地容器管理模块收到所述消息后,根据消息中的用户定义的应用参数,从所述管理VPC的容器库中下载相应的容器模板到本地,并创建容器组或容器,完成所述应用的部署。
本申请实施例为了进一步提高资源利用率和管理效率,控制节点在发送应用部署消息时可以首先根据所述用户VPC中虚拟机的资源使用情况来确定部署本次待部署应用的虚拟机,进而将该应用部署到该虚拟机中,确保所述用户VPC的资源合理利用。
实施中,所述方法可以进一步包括:
接收用户的应用释放请求,所述应用释放请求中包括应用ID;
所述管理VPC的控制节点根据所述应用ID确定所述应用所在的虚拟机,向所述应用所在的虚拟机上的本地容器管理模块发送容器释放消息,所述容器释放消息中包括容器ID;
所述虚拟机的本地容器管理模块根据所述容器ID释放所述容器。
具体实施中,在用户提出应用释放请求时,所述管理VPC的控制节点接收到所述应用释放请求后,可以根据应用ID查询应用信息表,确定该应用所在的虚拟机;如果该应用为部署于虚拟机中容器组内的容器上,所述管理VPC的控制节点还可以根据应用ID确定该应用所在的虚拟机的同时,确定该应用所在的容器组信息。所述控制节点向相应的虚拟机的本地容器管理模块发送释放容器的消息;所述虚拟机的本地容器管理模块根据接收的消息释放相应的容器组或容器。
在具体实施时,所述虚拟机的容器管理模块释放所述应用所在的容器后,所述管理VPC的控制节点可以更新应用信息表,将该应用及其容器、容器组、所在虚拟机等信息的记录删除;所述管理VPC的控制节点还可以统计所述用户VPC的各个虚拟机的资源使用信息,以备后续重新分配资源等操作。
本申请实施例提供了用户释放应用时的方法流程,可以在用户提出释放应用的请求时,通过管理VPC的控制节点向该应用所在的虚拟机发送释放消息,并由该虚拟机的本地容器管理模块释放该应用所在的容器,实现释放应用的目的,进而释放出更多的资源。
实施中,所述方法可以进一步包括:
所述控制节点根据所述用户VPC的资源使用情况确定需要释放的用户VPC ID;所述管理VPC的用户VPC管理模块根据所述用户VPC ID释放所述需要释放的用户VPC;或者,
所述控制节点根据所述用户VPC中虚拟机的资源使用情况确定所述用户VPC中需要释放的虚拟机ID;所述管理VPC的用户VPC管理模块根据所述虚拟机ID释放所述需要释放的虚拟机。
具体实施中,当所述管理VPC的控制节点发现某个用户的所有应用都已经被释放并且不再使用资源时,所述控制节点可以通过所述管理VPC的用户VPC管理模块主动释放该用户对应的用户VPC,并更新用户与用户VPC的映射表,将该用户的用户信息及用户VPC信息的记录删除。
具体实施中,当所述管理VPC的控制节点发现某个或者某些虚拟机资源空闲或者没有应用部署时,所述控制节点可以通过所述管理VPC的用户VPC管理模块主动释放相应虚拟机。所述控制节点可以更新虚拟机VPC映射表(即虚拟机与用户VPC的对应关系表)和虚拟机资源监控信息表,删除相应的虚拟机信息。
本申请实施例不仅可以在用户提出应用释放请求时进行应用的释放,还可以根据用户VPC或用户VPC中虚拟机的资源使用情况,主动释放所述用户VPC或所述用户VPC中的虚拟机,通过管理VPC统一管理用户VPC,实现资源的动态调度。
图4示出了本申请实施例中Docker运行环境示意图一,如图所示,所述Docker运行环境中可以包括一个管理VPC和多个用户VPC(VPC1、VPC2、…、VPCn)。
图5示出了本申请实施例中Docker运行环境示意图二,所述示意图二为所述示意图一的详细表示,如图所示,每个VPC中包含一个虚拟路由装置以及多个虚拟机。
其中,管理VPC中可以包括四个虚拟机,分别用于部署用户VPC管理模块、控制节点、容器库和配置服务发现存储系统;用户VPC中可以包括多个虚拟机,每个虚拟机中可以包括本地容器管理模块、代理模块和多个容器(组)。
所述管理VPC的虚拟路由装置与所述用户VPC的虚拟路由装置之间存在安全隧道,用来实现管理VPC与用户VPC之间的通信,用户VPC之间没有安全隧道,无法实现互相访问。
为了便于本申请的理解,下面以Kubernetes作为容器编排技术为例进行说明。
图6示出了本申请实施例中以Kubernetes为例的架构示意图,如图所示,本申请实施例从不同阶段进行详细描述如下:
1、系统的原始状态
创建一个管理VPC(VPC0)以及VPC0的虚拟路由器vRouter0,在VPC0中创建两个虚拟机VM1、VM2,在VM1部署用户VPC管理模块、Kubermetes Master、Docker registry,在VM2中部署ETCD。
具体实施时,ETCD也可以集群部署在3个或3个以上的物理机或虚拟机上。
2、创建用户
本申请实施例假设有两个用户,分别为用户A(假设ID=User1)和用户B(假设ID=User2)。
管理VPC(VPC0)的用户VPC管理模块为用户User1申请、创建一个VPC1,并创建VPC1的虚拟路由器vRouter1;
管理VPC(VPC0)的用户VPC管理模块为用户User2申请、创建一个VPC2,并创建VPC2的虚拟路由器vRouter2。
所述用户VPC管理模块可以设置VPC0的vRouter0与VPC1的vRouter1之间的路由及安全策略,保证vRouter0与vRouter1之间互通,以及VPC0的vRouter0与VPC2的vRouter2之间的路由及安全策略,保证vRouter0与vRouter2之间互通,使得管理VPC(VPC0)中的虚拟机可以访问用户VPC(VPC1、VPC2…等)中的虚拟机,但vRouter0不能将vRouter1的路由转发到其他用户VPC的vRouter上(例如,VPC2的vRouter2),同理,vRouter0也不能将其他用户VPC的vRouter(例如,VPC2的vRouter2)的路由转发到vRouter1上,从而保证不同用户的VPC之间不可访问。
具体实施时,可以将VPC0的vRouter0设置为不具备路由转发功能。
本申请实施例中,vRouter0上的路由表可以设置为如下表所示:
vRouter1上的路由表可以设置为如下表所示:
vRouter2上的路由表可以设置为如下表所示:
通过上述的路由设置之后,用户A和用户B之间实现了安全隔离,用户A、用户B的用户VPC可以分别与管理VPC互通,由管理VPC统一管理、调度。
VPC0上可以保存用户与用户VPC的映射表,用来保存用户信息与用户VPC信息之间的对应关系,具体可以如下表所示:
用户ID |
用户VPC ID |
创建时间 |
… |
User1 |
VPC1 |
|
|
User2 |
VPC2 |
|
|
用户VPC映射表可以记录有用户标识ID信息以及用户VPC ID信息等,具体实施时,每个用户可以有一个或多个用户VPC,此时该用户VPC映射表中对于每个用户可能会生成一条或多条记录。
3、用户发布应用
以用户VPC为VPC1为例,假设用户A想要发布企业移动管理系统应用,在用户A点击发布应用按钮后,Kubermetes Master接收用户A的应用发布请求,所述应用发布请求中可以包括所述用户A的ID(User1),根据所述用户A的ID确定所述用户A的用户VPC为VPC1;
管理VPC(VPC0)的用户VPC管理模块在VPC1中创建虚拟机VM3,所述VM3中可以预先部署有本地容器管理模块kuberlet和代理模块proxy;所述用户VPC管理模块建立所述VPC1的VM3上的kuberlet与Kubermetes Master之间的通信。
VPC0上可以保存容器节点和用户VPC的映射表,用来保存用户VPC信息与所述用户VPC内的容器节点信息之间的对应关系,具体可以如下表所示:
容器节点ID |
用户VPC ID |
创建时间 |
… |
VM3 |
VPC1 |
|
|
VM4 |
VPC1 |
|
|
Kubermetes Master根据所述vRouter0与vRouter1之间的安全隧道,向VM3上的kuberlet发送应用部署消息,所述应用部署消息中可以包括用户定义的应用参数;
VM3中的kuberlet可以根据所述用户定义的应用参数,从所述VPC0中的Dockerregistry下载相应的容器模板,在VM3中创建容器组POD,根据用户的应用定义创建容器。
由于企业移动管理系统通常包括服务器和个人系统,VM3中的kuberlet可以根据所述用户定义的应用参数,在VM3的POD中创建container1和container2。其中,所述container1可以用来部署EMM server(企业移动管理服务器)应用,所述container2可以用来部署OwnCloud(个人私有云)应用。
VPC0上可以保存容器节点资源监控信息表,用来记录各个容器节点的资源使用情况,可以包括CPU、内存、硬盘、网络等信息,具体可以如下表所示:
容器节点ID |
资源使用信息 |
时间戳 |
… |
VM3 |
|
|
|
VM4 |
|
|
|
本申请实施例中Kubermetes Master可以定期更新表内的相关信息。
VPC0上还可以保存应用信息表,用来记录各个应用所部署到的容器信息、容器组信息等,具体可以如下表所示:
应用ID |
用户ID |
创建时间 |
容器组信息 |
所在容器信息 |
… |
EMM Server |
User1 |
|
POD1 |
container1 |
|
OwnCloud |
User1 |
|
POD1 |
container2 |
|
VPC0上还可以保存应用资源使用信息表,用来记录每个应用的负载情况,具体可以如下表所示:
应用ID |
容器/容器组ID |
负载信息 |
时间戳 |
… |
EMM Server |
container1/POD1 |
|
|
|
OwnCloud |
container2/POD1 |
|
|
|
以用户VPC为VPC2为例,假设用户B想要发布一个web站点应用时,在用户B提交发布应用请求后,Kubermetes Master接收用户B的应用发布请求,所述应用发布请求中包括所述用户B的ID(User2),根据所述用户ID确定所述用户B的用户VPC为VPC2;
管理VPC(VPC0)的用户VPC管理模块在所述VPC2上创建虚拟机VM5,所述VM5中可以预先部署有本地容器管理模块kuberlet和代理模块proxy;所述用户VPC管理模块建立所述VPC2的VM5上的kuberlet与Kubermetes Master之间的通信。
Kubermetes Master根据所述vRouter0与vRouter2之间的安全隧道,向VM5上的kuberlet发送应用部署消息,所述应用部署消息中可以包括用户定义的应用参数;由于web站点应用包括web前端、web后端和web数据库,因此,VM4中的kuberlet可以根据所述用户定义的应用参数,从所述VPC0中的Docker registry下载相应的容器模板,在所述VM4中创建一个POD,所述POD里可以根据用户定义的web前端、web后端和web数据库创建三个container(即container1、contamer2、container3),从而将web前端、web后端和web数据库分别存放在该POD中的不同container中。
采用本申请实施例所提供的方案,用户A无法访问、修改用户B的应用,用户B也无法访问、修改用户A的应用,确保两个用户之间安全隔离,降低了安全风险,同时,两个用户的VPC分别与管理VPC互通,实现管理VPC统一管理资源的目的。
当用户B想要释放所述web站点应用时,Kubermetes Master接收用户的应用释放请求,该请求中可以包括待释放应用的ID(假设ID为web站点应用);Kubermetes Master根据应用ID确定该应用所在的虚拟机为VM5,然后向所述VM5上的本地容器管理模块发送容器释放消息,消息中可以包括容器ID(container1、container2和container3);所述VM5的kuberlet释放所述容器,Kubermetes Master更新虚拟机VPC映射表和虚拟机资源监控信息表,删除VM5的相关信息。
经过一段时间,Kubermetes Master发现用户B的所有应用已经被释放且不再使用资源,此时,Kubermetes Master通过VPC0的用户VPC管理模块主动释放用户B的VPC2,将用户B的信息及VPC2的信息记录从用户VPC映射表中删除。
本申请实施例提供了一种基于VPC安全隔离的Docker运行环境及动态创建、部署应用、释放应用等方法,设置管理VPC和用户VPC,通过设置管理VPC与用户VPC之间的路由,保证管理VPC和用户VPC的连通,又保障不同用户VPC之间的隔离。
基于同一发明构思,本申请实施例中还提供了一种应用部署装置,由于这些设备解决问题的原理与一种应用部署方法相似,因此这些设备的实施可以参见方法的实施,重复之处不再赘述。
图7示出了本申请实施例中应用部署装置的结构示意图,如图所示,所述应用部署装置可以包括:
第一接收模块701,用于管理虚拟私有云VPC的控制节点接收用户的应用发布请求,所述应用发布请求中包括所述用户标识ID;
用户VPC确定模块702,用于根据所述用户ID确定所述用户的用户VPC;
第一消息发送模块703,用于通过所述管理VPC与所述用户VPC之间的安全隧道,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息,所述应用部署消息中包括所述用户定义的应用参数;
应用部署模块704,用于所述本地容器管理模块根据所述用户定义的应用参数在所述虚拟机中创建容器,所述容器用于部署所述应用。
实施中,所述装置可以进一步包括:
第二接收模块705,用于在所述管理虚拟私有云VPC的控制节点接收用户的应用发布请求之前,接收用户创建请求;
用户VPC创建模块706,用于管理VPC中的用户VPC管理模块为所述用户创建用户VPC,并建立所述用户VPC与所述管理VPC的安全隧道。
实施中,所述用户VPC可以为多个,所述管理VPC与所述用户VPC之间的存在安全隧道具体为,所述管理VPC的虚拟路由装置分别与各用户VPC的虚拟路由装置之间存在路由,各用户VPC之间不存在路由。
实施中,所述装置可以进一步包括:
虚拟机创建模块707,用于如果所述管理VPC的控制节点接收用户的应用发布请求为首次,在所述根据所述用户ID确定所述用户的用户VPC之后,向所述用户VPC的虚拟机上的本地容器管理模块发送应用部署消息之前,所述管理VPC的用户VPC管理模块在所述用户VPC中创建虚拟机,所述虚拟机中部署有本地容器管理模块;所述管理VPC的用户VPC管理模块建立所述本地容器管理模块与所述管理VPC的控制节点之间的通信。
实施中,所述第一消息发送模块可以具体包括:
应用部署虚拟机确定单元,用于所述管理VPC的控制节点根据所述用户VPC中虚拟机的资源使用情况确定所述用户VPC中的虚拟机ID;
发送单元,用于所述控制节点根据所述虚拟机ID通过所述管理VPC与所述用户VPC之间的安全隧道向所述虚拟机的本地容器管理模块发送应用部署消息。
实施中,所述装置可以进一步包括:
第三接收模块708,用于所述管理VPC的控制节点接收用户的应用释放请求;
第二消息发送模块709,用于所述控制节点确定所述应用所在的虚拟机,向所述应用所在的虚拟机的本地容器管理模块发送容器释放消息,所述容器释放消息中包括容器ID;
容器释放模块710,用于所述虚拟机的本地容器管理模块根据所述容器ID释放所述容器。
实施中,所述装置可以进一步包括:
待释放虚拟机确定模块711,用于所述控制节点根据所述用户VPC或所述用户VPC中虚拟机的资源使用情况确定需要释放的用户VPC ID或虚拟机ID;
虚拟机释放模块712,用于所述管理VPC的用户VPC管理模块根据所述用户VPC ID或虚拟机ID释放所述需要释放的用户VPC或虚拟机。
为了描述的方便,以上所述装置的各部分以功能分为各种模块或单元分别描述。当然,在实施本申请时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。