WO2019056882A1 - 一种跨平台部署的方法和系统 - Google Patents

一种跨平台部署的方法和系统 Download PDF

Info

Publication number
WO2019056882A1
WO2019056882A1 PCT/CN2018/099356 CN2018099356W WO2019056882A1 WO 2019056882 A1 WO2019056882 A1 WO 2019056882A1 CN 2018099356 W CN2018099356 W CN 2018099356W WO 2019056882 A1 WO2019056882 A1 WO 2019056882A1
Authority
WO
WIPO (PCT)
Prior art keywords
deployment
application
platform
template
target platform
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2018/099356
Other languages
English (en)
French (fr)
Inventor
李世涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to EP18857968.4A priority Critical patent/EP3668057B1/en
Publication of WO2019056882A1 publication Critical patent/WO2019056882A1/zh
Priority to US16/814,409 priority patent/US11693642B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/166—Editing, e.g. inserting or deleting
    • G06F40/186—Templates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Definitions

  • the present application relates to virtualization technologies, and in particular, to a method and system for deploying applications across platforms on a virtualized resource platform.
  • Virtualization can realize the flexible configuration of resources by transforming physical IT resources into virtual IT resources. Thanks to virtualization technology, hardware and software functions can be decoupled, allowing the functionality of dedicated hardware in traditional networks to run on general-purpose hardware devices, reducing the cost of deploying dedicated hardware.
  • the party that initiates the virtualization request is called the service requester, and the party that provides the virtualization service deployment capability is called the provider of the virtualization service.
  • the general service requester first needs to submit a description of the service to the service provider, which is called a service deployment template.
  • the deployment template needs to describe each node information of the service, such as resources. Requirements, etc., also include the connection relationship between nodes.
  • a commonly used deployment template description language such as the TOSCA defined by the OASIS TOSCA organization.
  • a deployment template defined by TOSCA includes an application deployment description file ServiceTemplate, which contains information about all nodes in the entire service (node template) and the relationship between nodes (relationship template).
  • a TOSCA service template uses a TopologyTemplate to depict an application topology.
  • Each node in the topology is a NodeTemplate whose type is defined by the NodeType (the type attribute of the NodeTemplate describes the NodeType corresponding to the NodeTemplate), and a NodeTemplate can represent a description of a VNF (Virtualized Network Function). VNFD (VNF Descriptio).
  • Each edge in the topology is a RelationshipTemplate.
  • the RelationshipTemplate is an instance of RelationshipType, which defines the starting point of the edge (defined by SourceElement) and the ending point (defined by TargetElement).
  • the RelationshipTemplate is in NFV (Network Functions Virtualization). The connection between two VNFs can be defined.
  • a Relationship Type specifies the connection relationship between two Nodes according to the definition, such as a Relationship Type defined as "DependsOn”. When it is used between A and B Nodes and A is the SourceElement and B is the TargetElement, When deploying, you need to deploy Node B before you can deploy Node A.
  • the parameters defined by the "inputs" element indicate that their values need to be confirmed and entered during deployment. These parameters may be different for different deployment requirements, such as IP address, user name created during deployment, and so on.
  • the “node_templates” element describes the node contained in the service.
  • the Service Template contains nodes such as " WordPress”, “apache”, “web_server”, “webpress_db”, “mysql”, and "db_server”.
  • the parameter corresponding to get_input is wp_admin_username, indicating that deployment is required.
  • the input value of "wp_admin_username” is assigned to "admin_user”.
  • the assignment value of "db_host” is "get_property:[db_server,db_name]", where "get_property” is another operation defined in the YAML version. This operation is used to take values from the "properties” defined in other nodes. In this example, the value is taken from the "db_name” defined by node “db_server”, which is "sql_database1" and assigned to "db_host”.
  • the node also defines "requirements”, which can be used to indicate the connection relationship of the node to other nodes. For example, there are two parameters under “requirements”, “host:apache” and “database_endpoint: WordPress_db”, respectively, indicating the node. The relationship with “apache” is “HostedOn”, and the relationship with “php_db” is “ConnectsTo”.
  • the application process is deployed for an application that supports TOSCA templates:
  • the service requester performs application deployment template design.
  • it is a deployment template designed with TOSCA language, such as the TOSCA template instance mentioned above;
  • the service requester sends the deployment template to the TOSCA control platform for online storage
  • the service requester sends a deployment request, which carries the identifier of the deployment template that has been online, in this case, the deployment template that goes online in step 2; the possible case is that the deployment request is also included in the template.
  • step 4 the controller requests the requestor to assign a value according to the parameters defined by inputs in the template.
  • step 5 the controller receives the request. The assignment of the inputs parameter returned by the party;
  • the language is mainly used for the VMware platform.
  • the service deployment using the OVF language is mainly divided into two parts: the first part is the business design, that is, the generation of the deployment package; Part of it is the deployment phase, which is explained below.
  • the user first needs to start the required virtual machine locally and install the required software on the virtual machine. After the completion, the virtual machine is shut down and the image of the virtual machine is exported.
  • the deployment package of the application is generated on the tool, which includes the image exported in the first step and the deployment template generated in the second step, and other required authentication files.
  • the service request direction sends the OVF deployment package completed in the service design phase to the VMware controller platform.
  • the VMWare platform parses the OVF deployment package, parses the configuration options required for the application deployment, and requests the service requester for the assignment of the required configuration options.
  • TOSCA is a widely used application deployment template, which is mainly applied to OpenStack (also referred to as TOSCA platform in this paper) platform, but cannot deploy TOSCA modeling services to VMware platforms, and services that are modeled by OVF templates. Nor can it be deployed on the TOSCA platform. Therefore, the prior art can only be applied to a single deployment platform, and cannot meet the cross-platform application deployment.
  • OpenStack also referred to as TOSCA platform in this paper
  • the present invention provides a method and system that can adapt to cross-platform application deployment.
  • the method for deploying a cross-platform application and the method for generating an application deployment template provided by the embodiment of the present invention are based on the TOSCA template and are compatible with the application deployment requirements of other platforms, so that the TOSCA is simultaneously supported by the solution.
  • the target platform for application deployment is first determined, and the target platform includes other types of platforms other than the TOSCA platform, such as an OVF platform, and then generates application deployment information required for deploying the application on the target platform.
  • the OVF platform corresponds to the OVF deployment package, and then the information about the deployment target platform and the application deployment information required for deploying the application on the deployment target platform are added to a unified deployment template conforming to the TOSCA template format, and the deployment template is Go online to the upper server and send an application deployment request to the upper server when the application needs to be deployed.
  • the deployment template required for the application deployment may be determined according to the deployment request, for example, the identification information of the deployment template identifier carried in the deployment request may be used, and the identifier information may be before
  • the deployment template is saved in the server during the process of being online; after obtaining the deployment template, the application deployment information can be sent to the target platform according to the target platform information in the deployment template.
  • the target platform After receiving the application deployment information, the target platform can determine which configuration parameters are needed to complete the deployment of the application, and send a request for obtaining the configuration parameters required for deploying the application to the upper server. After receiving the request, the upper server can obtain the previous request.
  • the configuration parameter value required for the application deployment is obtained from the client side of the requesting deployment, and the obtained configuration parameter value is sent to the target platform, and the target platform can deploy the information according to the application and deploy the application. Configure parameter values to deploy the app.
  • the above process realizes deploying an application on a non-TOSCA platform through a deployment template conforming to the TOSCA template format, and can utilize the general process of the existing TOSCA platform deployment, and deploy the application on the TOSCA platform through the deployment template.
  • a cross-platform application deployment can be achieved through a unified deployment template.
  • the embodiment of the present invention further provides a specific implementation when the target platform is an OVF platform, wherein the information of the target platform can be added in the inputs parameter of the TOSCA template; the application deployment information is the address of the OVF deployment package or the OVF deployment package, and the application deployment information is used. Can be added to the deployment artifacts of the deployment nodes in the TOSCA template.
  • the application deployment information may be placed in a deployed article in the form of a file address, where the file address is a storage address of the OVF deployment package.
  • a transmission indication may be further added, where the transmission indication is used to indicate that the application deployment information is sent to the target platform.
  • an embodiment of the present invention provides a system for deploying an application across platforms, where the system includes an upper layer server and a target platform, to implement the foregoing functions.
  • the embodiment of the invention further provides a client and a server that can support cross-platform application deployment to implement the above functions.
  • the cross-platform deployment of the application can be effectively solved.
  • the support of multiple resource platforms is realized through an upper-layer server, thereby flexibly implementing cross-platform deployment.
  • Figure 1 is a schematic diagram of a deployment template defined by TOCSA
  • FIG. 2 is a process flow diagram of an application deployment supporting a TOSCA template
  • Figure 3 is a process flow diagram of an application deployment supporting the OVF language
  • FIG. 4 is a system architecture diagram of cross-platform application deployment according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of a cross-platform application deployment according to an embodiment of the present invention.
  • Figure 6 is a schematic diagram of a general computer architecture.
  • the embodiment of the present invention provides a unified deployment template, which can be compatible with the application deployment requirements of the TOSCA platform and other platforms, thereby implementing a cross-platform application deployment by a set of deployment templates.
  • the embodiment of the present invention further provides an upper-layer server, which can identify and parse the new deployment template, and determine the target platform to be deployed by the application according to the content in the deployment template, and send the application deployment information to the corresponding On the resource platform.
  • the cross-platform template design and application deployment compatible with the TOSCA platform and the OVF platform will be described as an example.
  • the design can be implemented according to the principles given in the embodiments of the present invention. .
  • Figure 4 shows a system architecture for a cross-platform application deployment, including a requesting client 101, an upper server 201, and two or more resource platforms, each of which may be composed of a corresponding controller and a virtual resource management platform.
  • the TOSCA controller 301 and its corresponding virtual resource management platform (Open Stack) 302, as well as the VMware controller 401 and its corresponding virtual resource management platform (VMware) 402 are shown.
  • the requesting client 101 and the upper layer server 201 use a set of unified application deployment templates across the platform, and the upper server 201 determines to send the application deployment information to the corresponding target platform according to the information in the application deployment template to implement resource deployment. .
  • the target platform obtains the necessary configuration parameter values required for application deployment by interacting with the upper server.
  • the template instance is based on the TOSCA template and is deployed in an OVF format compatible application with appropriate modifications.
  • the topology_template represents the overall topology template of the application.
  • the corresponding content below is inputs and node_templates.
  • the inputs are used to describe the input parameters needed to deploy the application.
  • the node_templates describes all the nodes included in the application.
  • an app1_input parameter is defined in inputs, which contains the following contents:
  • Type:external used to indicate that the input type of the app1_input parameter is external, that is, input from an external platform.
  • Source OVF, used to indicate that the specific external platform is OVF. It can be understood that the source platform can identify the platform on which the target platform is external, and the configuration item of type type is optional.
  • get_artifact(app1) which means that the file to be transferred to the OVF platform is get_artifact(app1), that is, the artifact contained in app1, corresponding to the artifact defined in the app1 node in node_templates
  • the file address is local/vdu1 .OVA, which is used to indicate that the application deployment information is sent to the target platform
  • the OVF deployment package is stored in the file address.
  • the generation process of the OVF deployment package participates in the description in the background art.
  • the server may also send the file of the specified location (for example, the artifact file included in app1) to the target platform by default configuration, without necessarily according to the transfer indication, so the indication is optional information.
  • the storage location indicated by the transfer is not limited to the inputs, for example, it may be stored under the deployed artifacts to be transmitted, or other suitable locations, and the name and representation of the indication are not limited enough, as long as the indication is reached.
  • the purpose of transmission can be.
  • node_templates all the nodes included in the application are defined. In this embodiment, two nodes, app1 and app2, are simply listed.
  • the artifacts of the app1 node are the product information required for deployment.
  • the deployment package is OVF.
  • the type of the image is OVF.
  • the OVF deployment package in prior art 2 is added as an artifact in the TOSCA template. Specifically, the address information stored in the OVF deployment package is placed in the file address corresponding to the file field in the form of a file address. Of course, if you can carry enough data, you can also carry the OVF deployment package directly.
  • the implementation defines the execution steps required to deploy the artifact.
  • the instance is get_output(app1_input), which means that the output output needs to be obtained from app1_input, corresponding to the assignment obtained from the external app1_input in inputs.
  • App2 is a node defined by the standard TOSCA template, which can be deployed directly through the TOSCA (Openstack) platform.
  • the original TOSCA template is extended, so that it can be compatible with the application deployment requirements of other platforms, and the application can be deployed on both the TOSCA platform and the OVF platform, thereby realizing cross-platform deployment.
  • the requesting client needs to have the ability to create the template.
  • the requesting client first needs to determine a target platform for application deployment, generate application deployment information required for deploying the application on the target platform, and then create a deployment template that conforms to the TOSCA template format, and includes a deployment target platform in the deployment template.
  • Information and application deployment information required to deploy the application on the deployment target platform Taking the OVF platform as an example, the above deployment template has explained how the target platform information and application deployment information are added in the deployment template.
  • the requesting client performs the design of the application deployment template according to the previous description, and creates an application deployment template.
  • the application deployment template can be used to mark the application deployment template by assigning an identifier, so as to quickly find the corresponding application deployment template by using the identifier during the template deployment.
  • the application deployment request is sent, and the application deployment template of the application that has been online is carried in the deployment request, so that the upper-layer server obtains the application deployment template that has been online according to the identifier of the application deployment template.
  • the upper-layer server parses the application deployment template, and determines the target platform to be deployed according to the inputs parameter of the application to be deployed in the application deployment template.
  • the OVF platform is used.
  • the file in the deployment artifact of app1 is sent to the target platform, that is, the VMware platform (or OVF platform), that is, the corresponding artifact is the location defined by app1 in node_templates.
  • the target platform that is, the VMware platform (or OVF platform)
  • the corresponding artifact is the location defined by app1 in node_templates.
  • an OVF deployment package In the local/vdu1.OVA file, an OVF deployment package.
  • the VMware platform parses the OVF deployment package according to the received OVF deployment package, determines the configuration parameters required for the deployment application, and sends a request to the upper layer server to obtain the configuration parameter value.
  • the upper server After receiving the request for obtaining the configuration parameter value, the upper server obtains the corresponding configuration parameter value, and the requesting client can send the configuration parameter value required for deploying the application to the upper layer server in advance (for example, in the process of step 3). In this way, the upper server sends the configuration parameter value to the VMware platform according to the locally saved configuration parameter value. If the local server does not save, the upper server can send a request to the requesting client to obtain the configuration parameter value required for deploying the application from the requesting client side.
  • the parameters defined in the other inputs in the deployment template may be returned to the requesting client to request the assignment in the process. Alternatively, when the application deployment request is sent in step 3, the input is carried in the input device as described in the prior art. The defined parameter value.
  • the upper server sends the value of the configuration parameter to the VMware platform. Specifically, the upper server can obtain the configuration parameters required for deploying the app1 from the outside according to the execution steps required by the implementation defined in the deployment template. An assignment called an environment parameter, or an environment variable.
  • the upper server determines whether the source of the resource description information is specified in the deployment template, and if it is from the corresponding external environment, requesting that the resource be requested by the corresponding VMware platform, that is, the description of app1 is included.
  • step 4 This determination is optional because in step 4, it has been determined by the value in the inputs parameter that the application is to deploy a non-TOSCA target platform.
  • the VMWare platform generates an environment file by using the received configuration parameter assignment, and deploys the OVF application according to the method in the prior art.
  • the requesting client is any type of client that can be used to request deployment of an application, such as a general computer, a smart terminal, a tablet, or the like.
  • an application such as a general computer, a smart terminal, a tablet, or the like.
  • FIG. 6 a general computer architecture is shown.
  • the computer program instructions stored in the memory may be provided to a general purpose computer, a processor of a special purpose computer, or other programmable data processing apparatus such that the instructions are executed by a processor or other programmable data processing apparatus of the computer for generating
  • the functions of the client 101 and the upper server 201 are requested in the flowchart.
  • the computer program instructions can also be stored in a computer usable or computer readable memory that can be booted by a computer or other programmable data processing device in a particular manner, such that instructions stored in a computer usable or computer readable memory produce such an article.
  • the article of manufacture includes instructions for implementing the functions indicated in one or more of the blocks of the flowcharts.
  • the computer program instructions can also be loaded onto a computer or other programmable data processing device to cause a series of operational steps on the computer or other programmable data processing device to produce a computer implemented process, thereby
  • the instructions executed on a computer or other programmable data processing apparatus provide steps for implementing the functions indicated in one or more of the flowcharts and/or block diagrams.
  • the above described functions described in the embodiments of the present invention may be implemented in hardware, software, firmware, or any combination of the three. If implemented in software, these functions can be stored on a computer readable medium or transmitted as one or more instructions or code to a computer readable medium.
  • Computer readable media includes computer storage media and communication media that facilitates the transfer of computer programs from one place to another.
  • the storage medium can be any available media that any general purpose or special computer can access.
  • Such computer-readable media can include, but is not limited to, RAM, ROM, EEPROM, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or any other device or data structure that can be used for carrying or storing Other media that can be read by a general purpose or special computer, or a general purpose or special processor.
  • any connection can be appropriately defined as a computer readable medium, for example, if the software is from a website site, server or other remote source through a coaxial cable, fiber optic computer, twisted pair, digital subscriber line (DSL) Or wirelessly transmitted in, for example, infrared, wireless, and microwave, is also included in the defined computer readable medium.
  • DSL digital subscriber line
  • the disks and discs include compact disks, laser disks, optical disks, DVDs, floppy disks, and Blu-ray disks. Disks typically replicate data magnetically, while disks typically optically replicate data with a laser. Combinations of the above may also be included in a computer readable medium.
  • the embodiment of the invention further provides a request client, which includes a target platform determining unit, an application deployment information generating unit, and a deployment template creating unit.
  • a target platform determining unit configured to determine a target platform for application deployment, where the target platform is another type of platform other than the TOSCA platform; and an application deployment information generating unit, configured to generate application deployment information required for deploying the application on the target platform;
  • the deployment template creation unit is configured to create a deployment template that conforms to the TOSCA template format, where the deployment template includes information about the deployment target platform and application deployment information required for deploying the application on the deployment target platform.
  • the deployment template creation unit is further configured to add application deployment information in deployment artifacts of the deployment node in the TOSCA template.
  • the embodiment of the invention further provides a server supporting cross-platform application deployment, the server comprising:
  • a receiving unit configured to receive an application deployment request, and determine a deployment template required for the application deployment according to the application deployment request, where the deployment template conforms to a template format of the TOSCA, and the deployment template further includes information about the deployment target platform and the Deploying application deployment information required for deploying an application on a target platform, the target platform being other types of platforms other than the TOSCA platform;
  • a sending unit configured to send the application deployment information to the target platform according to the target platform information in the deployment template
  • the obtaining unit is configured to obtain a configuration parameter value required for the target platform to deploy the application, and send the value to the target platform through the issuing unit.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)

Abstract

本发明实施例提供的一种跨平台的应用部署方案，以TOSCA模板为基础，并能够兼容其他平台的应用部署的需求，使得通过该解决方案，实现同时支持TOSCA平台和非TOSCA平台的跨平台应用部署。通过在部署模板中加入目标平台信息以及在目标平台部署应用所需要的应用部署信息，上层服务器解析后将应用部署信息发送至目标平台，从而实现了利用一套统一的模板，即可实现TOSCA平台和非TOSCA平台的跨平台应用部署。

Description

一种跨平台部署的方法和系统
本申请要求于2017年9月22日提交中国专利局、申请号为201710864390.0，发明名称为“一种跨平台部署的方法和系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及虚拟化技术，尤其涉及一种在虚拟化资源平台上跨平台部署应用的方法和系统。
背景技术
虚拟化可以实现将物理的IT资源转化为虚拟的IT资源，从而实现资源的灵活配置。得益于虚拟化技术，软硬件功能可以解耦，从而让传统网络中专用硬件的功能可以运行在通用硬件设备上，从而降低部署专用硬件的成本。在虚拟化网络中，发起虚拟化请求的一方称为业务请求方，提供虚拟化业务部署能力的一方称为虚拟化业务的提供方。一个网络业务在进行虚拟化部署时，一般业务请求方首先需要向业务提供方提交该业务的描述，称为业务的部署模板，该部署模板中需要描述该业务构成的每个节点信息，比如资源需求等，还包括节点之间的连接关系。
常用的部署模板描述语言如OASIS TOSCA组织定义的TOSCA。如图1所示，一个采用TOSCA定义的部署模板包含一个应用部署描述文件ServiceTemplate，其中包含了整个业务中所有节点的信息(node template)，和节点之间的关系(relationship template)。
一个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。
目前TOSCA中定义了使用YAML语言进行模板描述的规范，下面是一个采用TOSCA规范中的YAML语言描述的关于wordpress业务(一种网站业务)部署的Service Template(模板描述)。
Figure PCTCN2018099356-appb-000001
Figure PCTCN2018099356-appb-000002
Figure PCTCN2018099356-appb-000003
其中“inputs”元素定义的参数表示其取值需要在部署时确认并输入，这些参数对于不同的部署需求可能不同，比如IP地址，部署时为用户创建的用户名等。
“node_templates”元素下面即描述的该业务包含的node，比如该Service Template中包含有“wordpress”，“apache”,”web_server”,“webpress_db”,“mysql”,“db_server”这些node。
以“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”。
如图2所示，为一个支持TOSCA模板的应用部署处理流程：
1、业务请求方进行应用部署模板设计，本例中即是一个采用TOSCA语言设计的部署模板，比如上面所举的TOSCA模板实例；
2、业务请求方将部署模板发送到TOSCA控制平台进行上线保存；
3、业务请求方发送一个部署请求，其中携带有已经上线的部署模板的标识，在该例中即为步骤2中上线的部署模板；可能的情况是在部署请求中还带有模板中所述inputs的参数的赋值；
Figure PCTCN2018099356-appb-000004
Figure PCTCN2018099356-appb-000005
还有一种可能情况是部署请求中不包含inputs参数的赋值，该情况下，在步骤4中，控制器根据模板中inputs定义的参数向请求方请求赋值，在步骤5中，控制器收到请求方返回的inputs参数的赋值；
6、当获取到赋值后都需要将所述赋值根据get_input的指示赋值到模板中合适的地方，比如wordpress_db的参数都需要从inputs中获取到赋值：
Figure PCTCN2018099356-appb-000006
7、根据模板中的描述向虚拟资源管理平台申请所需的资源；
8、资源申请成功；
9、应用部署成功。
目前用于部署模板描述的还有DMTF定义的OVF语言，该语言主要用于VMware平台，采用OVF语言进行业务部署主要分为两个部分：第一部分是业务设计，即部署包的生成；第二部分是部署阶段，下面分别进行说明。
第一部分，业务设计：
1、用户首先要在本地自行启动所需的虚拟机，并将所需软件安装到该虚拟机上，完成以后关闭该虚拟机并导出该虚拟机的镜像；
2、然后采用支持OVF的工具创建采用OVF格式描述的部署模板，其中包含上述虚拟机之间的连接关系等信息；
3、最后在工具上生成该应用的部署包，其中包含第一步导出的镜像和在第二步中生成的部署模板，还包含其他需要的认证等文件。
在第二部分，部署阶段
主要步骤如图3所示，如下：
1、业务请求方向VMware控制器平台发送业务设计阶段完成的OVF部署包
2、VMWare平台对OVF部署包进行解析，解析中部署应用所需的配置选项，向业务请求方请求所需配置选项的赋值
3、业务请求方反馈所需配置选项的值
4、VMware控制器平台利用收到的配置选项的赋值生成OVF环境文件
5、通过OVF部署包创建虚拟机
6、使用生成的OVF环境文件对创建的虚拟机进行配置，完成应用的部署
TOSCA是目前广泛使用的应用部署模板，主要应用于OpenStack(本文中亦可称之为 TOSCA平台)平台上，但不能将TOSCA建模的业务部署到VMware平台上，同时通过OVF模板建模的业务也不能部署在TOSCA平台上。因此，现有技术中都只能适用于单一的部署平台，无法满足跨平台的应用部署。
发明内容
有鉴于此，本发明提供了一种能够适配跨平台的应用部署的方法和系统。
本发明实施例提供的一种跨平台的应用部署的方法以及生成应用部署模板的方法，以TOSCA模板为基础，并能够兼容其他平台的应用部署的需求，使得通过该解决方案，实现同时支持TOSCA平台和非TOSCA平台的跨平台应用部署。
具体的，在客户端侧，首先确定好应用部署的目标平台，所述目标平台包括TOSCA平台之外的其他类型的平台，例如OVF平台，然后生成在目标平台部署应用所需要的应用部署信息，例如OVF平台对应的就是OVF部署包，然后将部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息添加到符合TOSCA模板格式的统一的部署模板中，将该部署模板上线至上层服务器，在需要部署应用时，向上层服务器发送应用部署请求。
在上层服务器侧，接收到客户端发送的应用部署请求后，可以根据该部署请求确定应用部署所需的部署模板，例如利用部署请求中携带的部署模板标识等标识信息，该标识信息可以在之前的部署模板上线的过程中保存在服务器中；获得到部署模板后，就可以根据部署模板中的目标平台信息，将所述应用部署信息发送到目标平台。
目标平台收到应用部署信息后，可以确定出需要哪些配置参数以完成应用的部署，并向上层服务器发送获取部署应用所需的配置参数的请求，上层服务器收到该请求后，可以从之前的配置信息中或者从请求部署的客户端侧来获取应用部署所需要的配置参数值，并将获取的配置参数值发送给目标平台，目标平台就可以根据所述应用部署信息以及部署应用所需的配置参数值来部署应用。
以上过程就实现了通过一个符合TOSCA模板格式的部署模板，来部署一个非TOSCA平台上的应用，同时可以利用现有的TOSCA平台部署的一般流程，通过该部署模板在TOSCA平台上部署应用，从而实现了通过一个统一的部署模板，就可以实现跨平台的应用部署。
本发明实施例进一步给出了目标平台为OVF平台时的具体实现，其中目标平台的信息可以添加在TOSCA模板的inputs参数中；应用部署信息为OVF部署包或者OVF部署包的地址，应用部署信息可以添加在TOSCA模板中的部署节点的部署制品(artifacts)中。所述应用部署信息可以以文件地址的形式置于部署制品中，所述文件地址为OVF部署包的存放地址。进一步的，在应用部署模板中，还可以添加一个传输指示，所述传输指示用于指示将所述应用部署信息发送至所述目标平台。对于其他类型的平台也同样可以参考本发明实施例给出的实现方案参照实现。
相应的，本发明实施例提供了一种跨平台部署应用的系统，该系统包括上层服务器以及目标平台，用以实现上述的功能。
本发明实施例还提供了一种可以支持跨平台应用部署的客户端以及服务器，以实现上 述功能。
通过本发明实施例提供的方案，可以有效解决应用的跨平台部署，通过采用统一的部署模板，通过一个上层的服务器来实现对多个资源平台的支持，从而灵活的实现跨平台的部署。
附图说明
图1为TOCSA定义的部署模板的示意图；
图2为一个支持TOSCA模板的应用部署的处理流程图；
图3为一个支持OVF语言的应用部署的处理流程图；
图4为本发明实施例提供的跨平台应用部署的系统架构图；
图5为本发明实施例提供的跨平台应用部署的流程图；
图6为一个通用计算机架构示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行描述。
为了解决现有技术的问题，本发明实施例提供了一种统一的部署模板，可以兼容TOSCA平台以及其他平台的应用部署需求，从而实现由一套部署模板，实现跨平台的应用部署。对应于新的部署模板，本发明实施例还提供一个上层服务器，能够识别和解析新的部署模板，并根据部署模板中的内容，确定该应用要部署的目标平台，将应用部署信息发送到对应的资源平台上。
在以下实施例描述中，将以兼容TOSCA平台和OVF平台的跨平台模板设计和应用部署为例进行说明，对于其他平台的模板设计，只要遵循本发明实施例给出的原则进行设计即可实现。
图4出示了一个跨平台应用部署的系统架构，包括请求客户端101，上层服务器201，以及两个或两个以上的资源平台，每个资源平台可以由对应的控制器以及虚拟资源管理平台组成，图中即出示了TOSCA控制器301及其对应的虚拟资源管理平台(Open Stack)302，以及VMware控制器401及其对应的虚拟资源管理平台(VMware)402。请求客户端101与上层服务器201之间使用一套跨平台的统一的应用部署模板，上层服务器201根据应用部署模板中的信息，确定将应用部署信息发送至相应的目标平台上，实现资源的部署。目标平台通过和上层服务器的交互，获取应用部署所需要的必要的配置参数值。需要说明的是，上层服务器的命名只是相对于其他平台的控制器而言，处于一个上层的统一控制的位置，“上层”本身并不对该服务器的位置或功能构成其他特别的限制，仅用于理解和行文的方便。
下面进一步展开具体说明实现的细节。如下是本发明实施例提供的以TOSCA语言为基础，兼容OVF部署实现的一个应用部署模板的实例：
Figure PCTCN2018099356-appb-000007
Figure PCTCN2018099356-appb-000008
该模板实例以TOSCA模板为基础，并通过适当的改造以兼容OVF格式的应用部署。其中topology_template表示的是该应用的整体拓扑模板，下面对应的内容有inputs和node_templates，inputs用来描述部署该应用时所需要的输入参数，node_templates描述该应用所包含的所有节点。
在该例中inputs中定义了一个app1_input的参数,该参数中包含的下列内容：
type:external
source:OVF
   transfer:get_artifact(app1)
type:external，用来表示所述app1_input参数的输入类型为外部，即来自外部平台的输入。
source:OVF，用来表示具体的外部平台是OVF。可以理解的是，通过source信息就可以识别出目标平台为外部的平台，type类型的配置项为可选项。
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下面，或者其他合适的位置，该指示的名称和表征方式也不够成限定，只要达到用于指示传输的目的即可。
在node_templates中定义了应用包含的所有节点，本实施例简单列出了两个节点app1和app2，其中app1节点的artifacts即是部署所需要的制品信息，比如在本实例中即为OVF的部署包，在该实施例中所述镜像的type类型为OVF。将现有技术2中的OVF部署包作为artifact添加在TOSCA模板中。具体的，是通过文件地址的形式，将OVF部署包存放的地址信息放在file字段对应的文件地址中。当然，如果能够携带足够大的数据，也可以直接携带OVF部署包。
implementation定义部署这个artifact所需要的执行步骤，该实例中为get_output(app1_input)，表示需要从app1_input中获取output输出，对应于inputs中的app1_input从外部获取的赋值。
app2就是采用标准TOSCA模板定义的节点，该节点通过TOSCA(Openstack)平台就可以直接部署。
通过以上的模板，扩展了原有TOSCA模板，使得其可以兼容其他平台的应用部署需求，可以实现同时在TOSCA平台和OVF平台上部署应用，实现了跨平台的部署。
为支持统一的部署模板，请求客户端需要具备创建该模板的能力。在具体实现上，请求客户端首先需要确定应用部署的目标平台，生成在目标平台部署应用所需要的应用部署信息，然后创建符合TOSCA模板格式的部署模板，在所述部署模板中包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息。以OVF平台为例，上述部署模板已经说明了目标平台信息以及应用部署信息该如何添加在部署模板中。
下面结合附图，从实现流程的角度，对跨平台的部署实现进行具体说明。
如图5所示，应用部署的具体流程如下：
1、请求客户端按照之前的说明，进行应用部署模板的设计，创建应用部署模板；
2、将设计好的应用部署模板发送给上层服务器进行上线保存，其他部署需要的文件也可以一起发送给上层服务器，所谓上线即为在上层服务器中存储好该应用部署模板，以便后续可以直接使用该应用部署模板，可以通过分配一个标识来标记这个应用部署模板，方便后续在模板部署时通过标识快速查找对应的应用部署模板；
3、发送应用部署请求，可以在部署请求中携带已经上线的应用部署模板的标识，以便上层服务器根据该应用部署模板的标识，获取已经上线的应用部署模板；
4、上层服务器解析应用部署模板，根据应用部署模板中待部署应用的inputs参数，确定要部署的目标平台，在本实施例中即为OVF平台
Figure PCTCN2018099356-appb-000009
Figure PCTCN2018099356-appb-000010
根据transfer的指示，或者根据默认的配置，将app1的部署制品(artifact)中的文件发送给目标平台，即VMware平台(或称OVF平台)，即对应的artifact即是app1在node_templates中定义的位置在local/vdu1.OVA的文件，为一个OVF部署包。
5、VMware平台根据收到的OVF部署包，参照现有技术对OVF部署包进行解析，确定部署应用需要的配置参数，向上层服务器发送请求获取配置参数值的请求。
6、上层服务器收到获取配置参数值的请求后，获取相应的配置参数值，请求客户端可以将部署应用所需要的配置参数值提前(如在步骤3的过程中)发给上层服务器保存，这样上层服务器根据本地之前保存的配置参数值向VMware平台发送配置参数值，如果本地没有保存，上层服务器可以向请求客户端发送请求，以从请求客户端侧获取部署应用所需要的配置参数值。部署模板中其他inputs中定义的参数，可以在这个过程中，一起返回给请求客户端以请求赋值，也可以如现有技术中的介绍，在步骤3中发送应用部署请求的时候，携带inputs中定义的参数值。
7、上层服务器将配置参数的值发送给VMware平台，具体的，上层服务器可以根据部署模板中的implementation定义的部署这个artifact所需要的执行步骤，从外部获取部署app1所需要的配置参数(又可称为环境参数，或者环境变量等)的赋值。
8、可选的，上层服务器判断所述部署模板中是否指明资源描述信息的来源，如果是来自对应的外部环境，则请求由对应的VMware平台申请资源，即app1的描述中包含
Figure PCTCN2018099356-appb-000011
本判断为可选，因为在步骤4中，已经通过inputs参数中的值，能够确定该应用要部署的是非TOSCA的目标平台了。
9、VMWare平台使用收到的配置参数赋值生成环境文件，并按照现有技术中的方法对OVF应用进行部署。
对app2部署于TOSCA平台的方式，是现有技术，本实施例不再复述。
综上，通过流程说明，介绍了如何实现跨平台的应用部署。通过上述过程可知，该跨平台应用的部署，不需要对目标平台进行改动。VMware平台只需要按照现有技术的方案就可以实现应用的部署，上层服务器相当于一个OVF请求端的代理，实现了原OVF请求端的各种功能。这样的实现方案，避免了对现有的各个资源平台的改造，有利于方案的部署实施。
请求客户端，是可以用于请求部署应用的任意类型的客户端，例如一般的计算机，智能终端，平板电脑等任意类型的设备。应理解，上述实施例中所述的流程图，可以通过计算机程序指令和/或硬件操作来实现，如图6所示，出示了一个通用的计算机结构。这些存储在存储器中的计算机程序指令可以被提供给通用计算机、专用计算机的处理器或者其他可编程数据处理装置，从而通过计算机的处理器或者其他可编程数据处理装置执行的所述指令生成用于实现在所述流程图中请求客户端101以及上层服务器201的功能。
这些计算机程序指令还可以存储在可引导计算机或其他可编程数据处理装置以特定方式运行的计算机可用或计算机可读存储器中，从而存储在计算机可用或计算机可读存储器中的指令产生这样的制品，所述制品包括实现在所述流程图/或框图的一个或多个框中所指明 的功能的指令。
所述计算机程序指令还可以被加载到计算机或者其他可编程数据处理装置上，以使在所述计算机或其他可编程数据处理装置上进行一系列操作步骤来产生计算机实现的过程，从而在所述计算机或其他可编程数据处理装置上执行的所述指令提供用于实现在所述流程图和/或框图的一个或多个框中所指明的功能的步骤。
在以上介绍的多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储于电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电脑、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。
本发明实施例还提供了一种请求客户端，其包括目标平台确定单元，应用部署信息生成单元，部署模板创建单元。目标平台确定单元，用于确定应用部署的目标平台，所述目标平台为TOSCA平台之外的其他类型的平台；应用部署信息生成单元，用于生成在目标平台部署应用所需要的应用部署信息；部署模板创建单元，用于创建符合TOSCA模板格式的部署模板，在所述部署模板中包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息。所述部署模板创建单元进一步用于将应用部署信息添加在TOSCA模板中部署节点的部署制品(artifacts)中。上述单元的具体实现均可参见上述流程实例中的介绍说明，不再复述。上述单元的具体功能可以以软件的形式存储在计算机代码上，通过处理器调用相应代码执行相应的功能。
本发明实施例还提供了一种支持跨平台应用部署的服务器，该服务器包括：
接收单元，用于接收应用部署请求，根据应用部署请求确定应用部署所需的部署模板，所述部署模板符合TOSCA的模板格式，在所述部署模板中还包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息，所述目标平台为TOSCA平台之外的其他类型的平台；
发送单元，用于根据所述部署模板中的目标平台信息，将所述应用部署信息发送到目标平台；
获取单元，用于获取目标平台部署应用所需的配置参数值，并通过发放单元发送至目标平台。
结合在部署模板实例中的介绍以及在应用部署流程的说明，本领域技术人员能够明确了解上述各单元在具体应用部署中的各实现细节的处理，在此就不展开复述。上述单元的具体功能也可以以软件的形式存储在计算机代码上，通过处理器调用相应代码执行相应的功能。

Claims (14)

  1. 一种跨平台应用部署的方法，其特征在于，
    接收应用部署请求；
    根据应用部署请求确定应用部署所需的应用部署模板，所述应用部署模板符合TOSCA的模板格式，在所述应用部署模板中还包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息，所述目标平台为TOSCA平台之外的其他类型的平台；
    根据所述应用部署模板中的目标平台信息，将所述应用部署信息发送到目标平台；
    获取目标平台部署应用所需的配置参数值，并发送至目标平台，以便目标平台根据所述应用部署信息以及部署应用所需的配置参数值部署应用。
  2. 一种生成应用部署模板的方法，以支持跨平台的应用部署，该方法包括：
    确定应用部署的目标平台，所述目标平台为TOSCA平台之外的其他类型的平台；
    生成在目标平台部署应用所需要的应用部署信息；
    创建符合TOSCA模板格式的应用部署模板，在所述应用部署模板中包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息。
  3. 根据权利要求1或2所述的方法，其特征在于，所述目标平台为OVF平台。
  4. 根据权利要求1或2所述的方法，其特征在于，所述目标平台的信息添加在TOSCA模板中的inputs参数中。
  5. 根据权利要求3所述的方法，其特征在于，所述应用部署信息为OVF部署包或者OVF部署包的地址。
  6. 根据权利要求5所述的方法，其特征在于，所述应用部署信息添加在TOSCA模板中部署节点的部署制品(artifacts)中。
  7. 根据权利要求6所述的方法，其特征在于，所述应用部署信息以文件地址的形式置于部署制品中，所述文件地址为OVF部署包的存放地址。
  8. 根据权利要求1或2所述的方法，其特征在于，所述应用部署模板中进一步包括传输指示，所述传输指示用于指示将所述应用部署信息发送至所述目标平台。
  9. 根据权利要求1所述的方法，其特征在于，所述获取目标平台部署应用所需的配置参数值具体包括：
    根据从目标平台收到的部署应用所需要的参数信息，从业务请求方获取应用部署所需要的参数值。
  10. 一种跨平台部署应用的系统，其特征在于，该系统包括上层服务器以及目标平台，上层服务器用于接收应用部署请求，根据应用部署请求确定应用部署所需的部署模板，所述部署模板符合TOSCA的模板格式，在所述部署模板中还包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息，根据所述部署模板中的目标平台信息，将所述应用部署信息发送到目标平台；
    所述目标平台为TOSCA平台之外的其他类型的平台，用于在收到上层服务器发送的应用部署信息后，确定部署应用所需要的配置参数，向上层服务器发送获取部署应用所需的配置参数的请求；
    上层服务器还用于在收到目标平台发送的获取部署应用所需的配置参数的请求后，获取目标平台部署应用所需的配置参数值，并发放至目标平台；
    所述目标平台还用于根据所述应用部署信息以及部署应用所需的配置参数值部署应用。
  11. 根据权利要求10所述的系统，其特征在于，所述目标平台为OVF平台。
  12. 一种可以支持跨平台应用部署的客户端，其特征在于，该客户端包括：
    目标平台确定单元，用于确定应用部署的目标平台，所述目标平台为TOSCA平台之外的其他类型的平台；
    应用部署信息生成单元，用于生成在目标平台部署应用所需要的应用部署信息；
    部署模板创建单元，用于创建符合TOSCA模板格式的部署模板，在所述部署模板中包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息。
  13. 根据权利要求12所述的客户端，其特征在于，所述部署模板创建单元进一步用于将应用部署信息添加在TOSCA模板中部署节点的部署制品(artifacts)中。
  14. 一种可以支持跨平台应用部署的服务器，其特征在于，该服务器包括：
    接收单元，用于接收应用部署请求，根据应用部署请求确定应用部署所需的部署模板，所述部署模板符合TOSCA的模板格式，在所述部署模板中还包括部署目标平台的信息以及在所述部署目标平台上部署应用所需要的应用部署信息，所述目标平台为TOSCA平台之外的其他类型的平台；
    发送单元，用于根据所述部署模板中的目标平台信息，将所述应用部署信息发送到目标平台；
    获取单元，用于获取目标平台部署应用所需的配置参数值，并通过发放单元发送至目标平台。
PCT/CN2018/099356 2017-09-22 2018-08-08 一种跨平台部署的方法和系统 Ceased WO2019056882A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18857968.4A EP3668057B1 (en) 2017-09-22 2018-08-08 Method and system for cross-platform deployment
US16/814,409 US11693642B2 (en) 2017-09-22 2020-03-10 Method and system for cross-platform deployment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710864390.0 2017-09-22
CN201710864390.0A CN109547509B (zh) 2017-09-22 2017-09-22 一种跨平台部署的方法和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/814,409 Continuation US11693642B2 (en) 2017-09-22 2020-03-10 Method and system for cross-platform deployment

Publications (1)

Publication Number Publication Date
WO2019056882A1 true WO2019056882A1 (zh) 2019-03-28

Family

ID=65810072

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/099356 Ceased WO2019056882A1 (zh) 2017-09-22 2018-08-08 一种跨平台部署的方法和系统

Country Status (4)

Country Link
US (1) US11693642B2 (zh)
EP (1) EP3668057B1 (zh)
CN (2) CN114827241A (zh)
WO (1) WO2019056882A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020259081A1 (zh) * 2019-06-25 2020-12-30 深圳前海微众银行股份有限公司 任务调度方法、装置、设备及计算机可读存储介质

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11019178B1 (en) * 2019-01-07 2021-05-25 West Corporation Deployment router based on channel traffic
CN110362318B (zh) * 2019-07-12 2025-05-27 北京百度网讯科技有限公司 应用部署方法、装置、设备和存储介质
CN110633079B (zh) * 2019-08-30 2023-06-16 微梦创科网络科技（中国）有限公司 一种基于yaml语言的业务开发方法及系统
CN116391182A (zh) * 2020-09-16 2023-07-04 云蓝有限责任公司 实现跨云应用模板的系统及方法
CN113961199A (zh) * 2020-12-18 2022-01-21 深圳平安智汇企业信息管理有限公司 一种模型部署系统、方法、装置及存储介质
CN112910956B (zh) * 2021-01-15 2023-05-02 北京金山云网络技术有限公司 一种资源创建方法、装置及电子设备
CN113407178B (zh) * 2021-06-01 2022-06-17 上海安畅网络科技股份有限公司 一种跨平台的DevOps引擎模板方法和系统
CN113839992B (zh) * 2021-08-31 2023-09-19 青岛海尔科技有限公司 设备控制方法及装置
US11805002B2 (en) 2021-11-19 2023-10-31 Hewlett Packard Enterprise Development Lp Retrieving and provisioning entities based on inheritance
US11868749B2 (en) * 2022-01-14 2024-01-09 Discover Financial Services Configurable deployment of data science models
CN116911406B (zh) * 2023-07-05 2024-02-02 上海数禾信息科技有限公司 风控模型部署方法、装置、计算机设备和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103970908A (zh) * 2014-05-28 2014-08-06 浪潮电子信息产业股份有限公司 一种虚拟机模板ivf存储方法
CN105159760A (zh) * 2014-05-27 2015-12-16 中国电信股份有限公司 云资源迁移方法和统一的跨平台云资源迁移能力开放接口
CN106796508A (zh) * 2014-04-30 2017-05-31 皮沃塔尔软件公司 在云平台上的快速部署
CN106936715A (zh) * 2015-12-31 2017-07-07 新华三技术有限公司 虚拟机报文控制方法及装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9134964B2 (en) * 2011-04-06 2015-09-15 Media Direct, Inc. Systems and methods for a specialized application development and deployment platform
CN103092670A (zh) * 2011-11-02 2013-05-08 佳都新太科技股份有限公司 一种云计算环境下跨平台的虚拟计算资源管理方法
US20150169373A1 (en) * 2012-12-17 2015-06-18 Unisys Corporation System and method for managing computing resources
CN103905508B (zh) * 2012-12-28 2017-07-28 华为技术有限公司 云平台应用部署方法及装置
CN105051687B (zh) * 2013-05-31 2018-01-09 华为技术有限公司 应用部署方法和设备
CN104601622B (zh) * 2013-10-31 2018-04-17 国际商业机器公司 一种部署集群的方法和系统
US9342299B2 (en) * 2014-02-25 2016-05-17 Red Hat, Inc. Deployment optimization for activation of scaled applications in a multi-tenant platform-as-a-service (PaaS) system
US9792140B2 (en) * 2015-03-04 2017-10-17 International Business Machines Corporation Maintenance of a software discovery catalog in a virtual machine environment
EP3281168A4 (en) * 2015-07-31 2018-03-14 Hewlett-Packard Enterprise Development LP Discovering and publishing api information
IN2015CH04027A (zh) * 2015-08-03 2015-08-14 Wipro Ltd
CN105260225B (zh) * 2015-09-01 2018-07-06 南威软件股份有限公司 一种虚拟桌面系统及其整合方法
US10089135B2 (en) * 2016-08-09 2018-10-02 International Business Machines Corporation Expediting the provisioning of virtual machines based on cached repeated portions of a template

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106796508A (zh) * 2014-04-30 2017-05-31 皮沃塔尔软件公司 在云平台上的快速部署
CN105159760A (zh) * 2014-05-27 2015-12-16 中国电信股份有限公司 云资源迁移方法和统一的跨平台云资源迁移能力开放接口
CN103970908A (zh) * 2014-05-28 2014-08-06 浪潮电子信息产业股份有限公司 一种虚拟机模板ivf存储方法
CN106936715A (zh) * 2015-12-31 2017-07-07 新华三技术有限公司 虚拟机报文控制方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3668057A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020259081A1 (zh) * 2019-06-25 2020-12-30 深圳前海微众银行股份有限公司 任务调度方法、装置、设备及计算机可读存储介质

Also Published As

Publication number Publication date
CN109547509B (zh) 2022-03-29
EP3668057B1 (en) 2025-07-30
CN109547509A (zh) 2019-03-29
US20200264858A1 (en) 2020-08-20
EP3668057A1 (en) 2020-06-17
US11693642B2 (en) 2023-07-04
EP3668057A4 (en) 2020-10-14
CN114827241A (zh) 2022-07-29

Similar Documents

Publication Publication Date Title
WO2019056882A1 (zh) 一种跨平台部署的方法和系统
US11307906B1 (en) Solver for cluster management system
US10909221B2 (en) Container license management method, and apparatus
CN107580083B (zh) 一种容器ip地址分配的方法和系统
US9405529B2 (en) Designing and cross-configuring software
JP6549787B2 (ja) ネットワークサービスをデプロイするための方法及び装置
CN103608773B (zh) 用于多节点应用的部署系统
US10951655B2 (en) System and method for dynamic reconfiguration in a multitenant application server environment
US9858105B1 (en) Service for managing custom virtual machine images
US20140337493A1 (en) Client/server network environment setup method and system
WO2017012381A1 (zh) 一种生命周期管理方法及装置
CN104885058B (zh) 在虚拟组件生成器环境中进行通用产品连线的系统和方法
US11119817B2 (en) Breaking dependence of distributed service containers
US20170237687A1 (en) Resource trees by management controller
WO2016029774A1 (zh) 基于虚拟化的应用存储方法、执行方法、装置及系统
WO2015117278A1 (zh) 时钟中断信号的获取方法和nfv功能实体
WO2020020154A1 (zh) 云桌面离线管理的方法、设备和存储介质
US20240241762A1 (en) Automated migration-framework for live applications to operator managed orchestration systems
US11601346B2 (en) Service providing apparatus and method
SYN et al. D3. 3: Infrastructures Management Toolkit API
SYN et al. D3. 6: Infrastructures Management Toolkit API v2
JP2009211688A (ja) ファイルをマイグレートする方法、システムおよびコンピュータ・プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18857968

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018857968

Country of ref document: EP

Effective date: 20200312

WWG Wipo information: grant in national office

Ref document number: 2018857968

Country of ref document: EP