一种跨平台部署的方法和系统与流程

文档序号:30955348发布日期:2022-07-30 09:38阅读:385来源:国知局
一种跨平台部署的方法和系统与流程
一种跨平台部署的方法和系统
1.本技术是分案申请,原申请的申请号是201710864390.0,原申请日是2017年09月22日,原申请的全部内容通过引用结合在本技术中。
技术领域
2.本技术涉及虚拟化技术,尤其涉及一种在虚拟化资源平台上跨平台部署应用的方法和系统。


背景技术:

3.虚拟化可以实现将物理的it资源转化为虚拟的it资源,从而实现资源的灵活配置。得益于虚拟化技术,软硬件功能可以解耦,从而让传统网络中专用硬件的功能可以运行在通用硬件设备上,从而降低部署专用硬件的成本。在虚拟化网络中,发起虚拟化请求的一方称为业务请求方,提供虚拟化业务部署能力的一方称为虚拟化业务的提供方。一个网络业务在进行虚拟化部署时,一般业务请求方首先需要向业务提供方提交该业务的描述,称为业务的部署模板,该部署模板中需要描述该业务构成的每个节点信息,比如资源需求等,还包括节点之间的连接关系。
4.常用的部署模板描述语言如oasis tosca组织定义的tosca。如图1所示,一个采用tosca定义的部署模板包含一个应用部署描述文件servicetemplate,其中包含了整个业务中所有节点的信息(node template),和节点之间的关系(relationship template)。
5.一个tosca service template使用topologytemplate来描绘一个应用拓扑。拓扑中每个节点都是一个nodetemplate,其类型由nodetype定义(nodetemplate的type属性描述了该nodetemplate对应的nodetype),一个nodetemplate可以表示一个vnf(虚拟化的网络功能,virtualized network function)的描述,即vnfd(vnf descriptio)。拓扑中的每条边都是一个relationshiptemplate,relationshiptemplate是relationshiptype的一个实例,定义了该边的起点(用sourceelement定义)和终点(用targetelement定义),relationshiptemplate在nfv(network functions virtualization,网络功能虚拟化)中可以定义两个vnf之间的连接关系。一个relationship type根据定义规定了两个node之间的连接关系,比如一个定义为“dependson”的relationship type,当其用在a和b两个node之间且a作为sourceelement,b作为targetelement时,在部署时,需要先部署node b,然后才能部署node a。
6.目前tosca中定义了使用yaml语言进行模板描述的规范,下面是一个采用tosca规范中的yaml语言描述的关于wordpress业务(一种网站业务)部署的service template(模板描述)。
7.8.[0009][0010]
[0011]
其中“inputs”元素定义的参数表示其取值需要在部署时确认并输入,这些参数对于不同的部署需求可能不同,比如ip地址,部署时为用户创建的用户名等。
[0012]“node_templates”元素下面即描述的该业务包含的node,比如该service template中包含有“wordpress”,“apache”,”web_server”,“webpress_db”,“mysql”,“db_server”这些node。
[0013]
以“wordpress”为例,其中“type:tosca.nodes.webapplication.wordpress”即表示该node的node type为“tosca.nodes.webapplication.wordpress”该type需要在部署该service template之前做定义。“properties”中定义了该node的参数,比如“admin_user”,“admin_password”,“db_host”。其中“admin_user”的赋值为“get_input:wp_admin_username”,“get_input”是yaml版本中定义的一种操作,说明其取值需要在部署时输入获得,该例中get_input对应的参数是wp_admin_username说明需要获取部署时“wp_admin_username”的输入值,并赋给“admin_user”。“db_host”的赋值为“get_property:[db_server,db_name]”,其中“get_property”是yaml版本中定义的另一种操作,该操作用来从其他node中定义的“properties”中取值,即在该例中从node“db_server”定义的“db_name”中取值,即为“sql_database1”,并赋给“db_host”。该node中还定义了“requirements”,可以用来指明该node对其他node的连接关系,比如这里“requirements”下有两个参数,“host:apache”和“database_endpoint:wordpress_db”,分别表示该node同“apache”之间的关系是“hostedon”,同“wordpress_db”之间的关系是“connectsto”。
[0014]
如图2所示,为一个支持tosca模板的应用部署处理流程:
[0015]
1、业务请求方进行应用部署模板设计,本例中即是一个采用tosca语言设计的部署模板,比如上面所举的tosca模板实例;
[0016]
2、业务请求方将部署模板发送到tosca控制平台进行上线保存;
[0017]
3、业务请求方发送一个部署请求,其中携带有已经上线的部署模板的标识,在该例中即为步骤2中上线的部署模板;可能的情况是在部署请求中还带有模板中所述inputs的参数的赋值;
[0018]
[0019][0020]
还有一种可能情况是部署请求中不包含inputs参数的赋值,该情况下,在步骤4中,控制器根据模板中inputs定义的参数向请求方请求赋值,在步骤5中,控制器收到请求方返回的inputs参数的赋值;
[0021]
6、当获取到赋值后都需要将所述赋值根据get_input的指示赋值到模板中合适的地方,比如wordpress_db的参数都需要从inputs中获取到赋值:
[0022][0023]
7、根据模板中的描述向虚拟资源管理平台申请所需的资源;
[0024]
8、资源申请成功;
[0025]
9、应用部署成功。
[0026]
目前用于部署模板描述的还有dmtf定义的ovf语言,该语言主要用于vmware平台,采用ovf语言进行业务部署主要分为两个部分:第一部分是业务设计,即部署包的生成;第二部分是部署阶段,下面分别进行说明。
[0027]
第一部分,业务设计:
[0028]
1、用户首先要在本地自行启动所需的虚拟机,并将所需软件安装到该虚拟机上,完成以后关闭该虚拟机并导出该虚拟机的镜像;
[0029]
2、然后采用支持ovf的工具创建采用ovf格式描述的部署模板,其中包含上述虚拟机之间的连接关系等信息;
[0030]
3、最后在工具上生成该应用的部署包,其中包含第一步导出的镜像和在第二步中生成的部署模板,还包含其他需要的认证等文件。
[0031]
在第二部分,部署阶段
[0032]
主要步骤如图3所示,如下:
[0033]
1、业务请求方向vmware控制器平台发送业务设计阶段完成的ovf部署包;
[0034]
2、vmware平台对ovf部署包进行解析,解析中部署应用所需的配置选项,向业务请求方请求所需配置选项的赋值;
[0035]
3、业务请求方反馈所需配置选项的值;
[0036]
4、vmware控制器平台利用收到的配置选项的赋值生成ovf环境文件;
[0037]
5、通过ovf部署包创建虚拟机;
[0038]
6、使用生成的ovf环境文件对创建的虚拟机进行配置,完成应用的部署。
[0039]
tosca是目前广泛使用的应用部署模板,主要应用于openstack(本文中亦可称之为tosca平台)平台上,但不能将tosca建模的业务部署到vmware平台上,同时通过ovf模板建模的业务也不能部署在tosca平台上。因此,现有技术中都只能适用于单一的部署平台,无法满足跨平台的应用部署。


技术实现要素:

[0040]
有鉴于此,本发明提供了一种能够适配跨平台的应用部署的方法和系统。
[0041]
本发明实施例提供的一种跨平台的应用部署的方法以及生成应用部署模板的方法,以tosca模板为基础,并能够兼容其他平台的应用部署的需求,使得通过该解决方案,实现同时支持tosca平台和非tosca平台的跨平台应用部署。
[0042]
具体的,在客户端侧,首先确定好应用部署的目标平台,所述目标平台包括tosca平台之外的其他类型的平台,例如ovf平台,然后生成在目标平台部署应用所需要的应用部署信息,例如ovf平台对应的就是ovf部署包,然后将部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息添加到符合tosca模板格式的统一的部署模板中,将该部署模板上线至上层服务器,在需要部署应用时,向上层服务器发送应用部署请求。
[0043]
在上层服务器侧,接收到客户端发送的应用部署请求后,可以根据该部署请求确定应用部署所需的部署模板,例如利用部署请求中携带的部署模板标识等标识信息,该标识信息可以在之前的部署模板上线的过程中保存在服务器中;获得到部署模板后,就可以根据部署模板中的目标平台信息,将所述应用部署信息发送到目标平台。
[0044]
目标平台收到应用部署信息后,可以确定出需要哪些配置参数以完成应用的部署,并向上层服务器发送获取部署应用所需的配置参数的请求,上层服务器收到该请求后,可以从之前的配置信息中或者从请求部署的客户端侧来获取应用部署所需要的配置参数值,并将获取的配置参数值发送给目标平台,目标平台就可以根据所述应用部署信息以及部署应用所需的配置参数值来部署应用。
[0045]
以上过程就实现了通过一个符合tosca模板格式的部署模板,来部署一个非tosca平台上的应用,同时可以利用现有的tosca平台部署的一般流程,通过该部署模板在tosca平台上部署应用,从而实现了通过一个统一的部署模板,就可以实现跨平台的应用部署。
[0046]
本发明实施例进一步给出了目标平台为ovf平台时的具体实现,其中目标平台的信息可以添加在tosca模板的inputs参数中;应用部署信息为ovf部署包或者ovf部署包的地址,应用部署信息可以添加在tosca模板中的部署节点的部署制品(artifacts)中。所述应用部署信息可以以文件地址的形式置于部署制品中,所述文件地址为ovf部署包的存放地址。进一步的,在应用部署模板中,还可以添加一个传输指示,所述传输指示用于指示将所述应用部署信息发送至所述目标平台。对于其他类型的平台也同样可以参考本发明实施例给出的实现方案参照实现。
[0047]
相应的,本发明实施例提供了一种跨平台部署应用的系统,该系统包括上层服务器以及目标平台,用以实现上述的功能。
[0048]
本发明实施例还提供了一种可以支持跨平台应用部署的客户端以及服务器,以实
现上述功能。
[0049]
通过本发明实施例提供的方案,可以有效解决应用的跨平台部署,通过采用统一的部署模板,通过一个上层的服务器来实现对多个资源平台的支持,从而灵活的实现跨平台的部署。
附图说明
[0050]
图1为tocsa定义的部署模板的示意图;
[0051]
图2为一个支持tosca模板的应用部署的处理流程图;
[0052]
图3为一个支持ovf语言的应用部署的处理流程图;
[0053]
图4为本发明实施例提供的跨平台应用部署的系统架构图;
[0054]
图5为本发明实施例提供的跨平台应用部署的流程图;
[0055]
图6为一个通用计算机架构示意图。
具体实施方式
[0056]
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行描述。
[0057]
为了解决现有技术的问题,本发明实施例提供了一种统一的部署模板,可以兼容tosca平台以及其他平台的应用部署需求,从而实现由一套部署模板,实现跨平台的应用部署。对应于新的部署模板,本发明实施例还提供一个上层服务器,能够识别和解析新的部署模板,并根据部署模板中的内容,确定该应用要部署的目标平台,将应用部署信息发送到对应的资源平台上。
[0058]
在以下实施例描述中,将以兼容tosca平台和ovf平台的跨平台模板设计和应用部署为例进行说明,对于其他平台的模板设计,只要遵循本发明实施例给出的原则进行设计即可实现。
[0059]
图4出示了一个跨平台应用部署的系统架构,包括请求客户端101,上层服务器201,以及两个或两个以上的资源平台,每个资源平台可以由对应的控制器以及虚拟资源管理平台组成,图中即出示了tosca控制器301及其对应的虚拟资源管理平台(open stack)302,以及vmware控制器401及其对应的虚拟资源管理平台(vmware)402。请求客户端101与上层服务器201之间使用一套跨平台的统一的应用部署模板,上层服务器201根据应用部署模板中的信息,确定将应用部署信息发送至相应的目标平台上,实现资源的部署。目标平台通过和上层服务器的交互,获取应用部署所需要的必要的配置参数值。需要说明的是,上层服务器的命名只是相对于其他平台的控制器而言,处于一个上层的统一控制的位置,“上层”本身并不对该服务器的位置或功能构成其他特别的限制,仅用于理解和行文的方便。
[0060]
下面进一步展开具体说明实现的细节。如下是本发明实施例提供的以tosca语言为基础,兼容ovf部署实现的一个应用部署模板的实例:
[0061]
[0062][0063]
该模板实例以tosca模板为基础,并通过适当的改造以兼容ovf格式的应用部署。其中topology_template表示的是该应用的整体拓扑模板,下面对应的内容有inputs和node_templates,inputs用来描述部署该应用时所需要的输入参数,node_templates描述该应用所包含的所有节点。
[0064]
在该例中inputs中定义了一个app1_input的参数,该参数中包含的下列内容:
[0065]
type:external
[0066]
source:ovf
[0067]
transfer:get_artifact(app1)
[0068]
type:external,用来表示所述app1_input参数的输入类型为外部,即来自外部平台的输入。
[0069]
source:ovf,用来表示具体的外部平台是ovf。可以理解的是,通过source信息就
可以识别出目标平台为外部的平台,type类型的配置项为可选项。
[0070]
transfer:get_artifact(app1),用来表示需要传输到ovf平台的文件是get_artifact(app1),即app1所包含的artifact(制品),对应于node_templates中app1节点中定义的artifact,文件地址为local/vdu1.ova,即用于指示将所述应用部署信息发送至所述目标平台,这个文件地址中存储的即为ovf部署包。ovf部署包的生成过程参加背景技术中的描述。需要说明的是,服务器也可以通过默认配置的方式,将指定位置的文件(例如app1所包含的artifact文件)发送给目标平台,而不一定要根据这个transfer指示,因此该指示为可选信息。另外,transfer指示的存储位置也不限于在inputs中,例如也可以存放在要传输的部署制品artifacts下面,或者其他合适的位置,该指示的名称和表征方式也不够成限定,只要达到用于指示传输的目的即可。
[0071]
在node_templates中定义了应用包含的所有节点,本实施例简单列出了两个节点app1和app2,其中app1节点的artifacts即是部署所需要的制品信息,比如在本实例中即为ovf的部署包,在该实施例中所述镜像的type类型为ovf。将现有技术2中的ovf部署包作为artifact添加在tosca模板中。具体的,是通过文件地址的形式,将ovf部署包存放的地址信息放在file字段对应的文件地址中。当然,如果能够携带足够大的数据,也可以直接携带ovf部署包。
[0072]
implementation定义部署这个artifact所需要的执行步骤,该实例中为get_output(app1_input),表示需要从app1_input中获取output输出,对应于inputs中的app1_input从外部获取的赋值。
[0073]
app2就是采用标准tosca模板定义的节点,该节点通过tosca(openstack)平台就可以直接部署。
[0074]
通过以上的模板,扩展了原有tosca模板,使得其可以兼容其他平台的应用部署需求,可以实现同时在tosca平台和ovf平台上部署应用,实现了跨平台的部署。
[0075]
为支持统一的部署模板,请求客户端需要具备创建该模板的能力。在具体实现上,请求客户端首先需要确定应用部署的目标平台,生成在目标平台部署应用所需要的应用部署信息,然后创建符合tosca模板格式的部署模板,在所述部署模板中包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息。以ovf平台为例,上述部署模板已经说明了目标平台信息以及应用部署信息该如何添加在部署模板中。
[0076]
下面结合附图,从实现流程的角度,对跨平台的部署实现进行具体说明。
[0077]
如图5所示,应用部署的具体流程如下:
[0078]
1、请求客户端按照之前的说明,进行应用部署模板的设计,创建应用部署模板;
[0079]
2、将设计好的应用部署模板发送给上层服务器进行上线保存,其他部署需要的文件也可以一起发送给上层服务器,所谓上线即为在上层服务器中存储好该应用部署模板,以便后续可以直接使用该应用部署模板,可以通过分配一个标识来标记这个应用部署模板,方便后续在模板部署时通过标识快速查找对应的应用部署模板;
[0080]
3、发送应用部署请求,可以在部署请求中携带已经上线的应用部署模板的标识,以便上层服务器根据该应用部署模板的标识,获取已经上线的应用部署模板;
[0081]
4、上层服务器解析应用部署模板,根据应用部署模板中待部署应用的inputs参数,确定要部署的目标平台,在本实施例中即为ovf平台
[0082][0083]
根据transfer的指示,或者根据默认的配置,将app1的部署制品(artifact)中的文件发送给目标平台,即vmware平台(或称ovf平台),即对应的artifact即是app1在node_templates中定义的位置在local/vdu1.ova的文件,为一个ovf部署包。
[0084]
5、vmware平台根据收到的ovf部署包,参照现有技术对ovf部署包进行解析,确定部署应用需要的配置参数,向上层服务器发送请求获取配置参数值的请求。
[0085]
6、上层服务器收到获取配置参数值的请求后,获取相应的配置参数值,请求客户端可以将部署应用所需要的配置参数值提前(如在步骤3的过程中)发给上层服务器保存,这样上层服务器根据本地之前保存的配置参数值向vmware平台发送配置参数值,如果本地没有保存,上层服务器可以向请求客户端发送请求,以从请求客户端侧获取部署应用所需要的配置参数值。部署模板中其他inputs中定义的参数,可以在这个过程中,一起返回给请求客户端以请求赋值,也可以如现有技术中的介绍,在步骤3中发送应用部署请求的时候,携带inputs中定义的参数值。
[0086]
7、上层服务器将配置参数的值发送给vmware平台,具体的,上层服务器可以根据部署模板中的implementation定义的部署这个artifact所需要的执行步骤,从外部获取部署app1所需要的配置参数(又可称为环境参数,或者环境变量等)的赋值。
[0087]
8、可选的,上层服务器判断所述部署模板中是否指明资源描述信息的来源,如果是来自对应的外部环境,则请求由对应的vmware平台申请资源,即app1的描述中包含
[0088]
本判断为可选,因为在步骤4中,已经通过inputs参数中的值,能够确定该应用要部署的是非tosca的目标平台了。
[0089]
9、vmware平台使用收到的配置参数赋值生成环境文件,并按照现有技术中的方法对ovf应用进行部署。
[0090]
对app2部署于tosca平台的方式,是现有技术,本实施例不再复述。
[0091]
综上,通过流程说明,介绍了如何实现跨平台的应用部署。通过上述过程可知,该跨平台应用的部署,不需要对目标平台进行改动。vmware平台只需要按照现有技术的方案就可以实现应用的部署,上层服务器相当于一个ovf请求端的代理,实现了原ovf请求端的各种功能。这样的实现方案,避免了对现有的各个资源平台的改造,有利于方案的部署实施。
[0092]
请求客户端,是可以用于请求部署应用的任意类型的客户端,例如一般的计算机,智能终端,平板电脑等任意类型的设备。应理解,上述实施例中所述的流程图,可以通过计算机程序指令和/或硬件操作来实现,如图6所示,出示了一个通用的计算机结构。这些存储
在存储器中的计算机程序指令可以被提供给通用计算机、专用计算机的处理器或者其他可编程数据处理装置,从而通过计算机的处理器或者其他可编程数据处理装置执行的所述指令生成用于实现在所述流程图中请求客户端101以及上层服务器201的功能。
[0093]
这些计算机程序指令还可以存储在可引导计算机或其他可编程数据处理装置以特定方式运行的计算机可用或计算机可读存储器中,从而存储在计算机可用或计算机可读存储器中的指令产生这样的制品,所述制品包括实现在所述流程图/或框图的一个或多个框中所指明的功能的指令。
[0094]
所述计算机程序指令还可以被加载到计算机或者其他可编程数据处理装置上,以使在所述计算机或其他可编程数据处理装置上进行一系列操作步骤来产生计算机实现的过程,从而在所述计算机或其他可编程数据处理装置上执行的所述指令提供用于实现在所述流程图和/或框图的一个或多个框中所指明的功能的步骤。
[0095]
在以上介绍的多个示例性的设计中,本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现,这些功能可以存储于电脑可读的媒介上,或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如,这样的电脑可读媒体可以包括但不限于ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁性存储装置,或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外,任何连接都可以被适当地定义为电脑可读媒介,例如,如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电脑、双绞线、数字用户线(dsl)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、dvd、软盘和蓝光光盘,磁盘通常以磁性复制数据,而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。
[0096]
本发明实施例还提供了一种请求客户端,其包括目标平台确定单元,应用部署信息生成单元,部署模板创建单元。目标平台确定单元,用于确定应用部署的目标平台,所述目标平台为tosca平台之外的其他类型的平台;应用部署信息生成单元,用于生成在目标平台部署应用所需要的应用部署信息;部署模板创建单元,用于创建符合tosca模板格式的部署模板,在所述部署模板中包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息。所述部署模板创建单元进一步用于将应用部署信息添加在tosca模板中部署节点的部署制品(artifacts)中。上述单元的具体实现均可参见上述流程实例中的介绍说明,不再复述。上述单元的具体功能可以以软件的形式存储在计算机代码上,通过处理器调用相应代码执行相应的功能。
[0097]
本发明实施例还提供了一种支持跨平台应用部署的服务器,该服务器包括:
[0098]
接收单元,用于接收应用部署请求,根据应用部署请求确定应用部署所需的部署模板,所述部署模板符合tosca的模板格式,在所述部署模板中还包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息,所述目标平台为tosca平台之外的其他类型的平台;
[0099]
发送单元,用于根据所述部署模板中的目标平台信息,将所述应用部署信息发送
到目标平台;
[0100]
获取单元,用于获取目标平台部署应用所需的配置参数值,并通过发放单元发送至目标平台。
[0101]
结合在部署模板实例中的介绍以及在应用部署流程的说明,本领域技术人员能够明确了解上述各单元在具体应用部署中的各实现细节的处理,在此就不展开复述。上述单元的具体功能也可以以软件的形式存储在计算机代码上,通过处理器调用相应代码执行相应的功能。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1