SYSTEM AND METHOD FOR IMPLEMENTING A TRANS-CLOUD APPLICATION TEMPLATE - Patent application

Abstract

A system and method for implementing a trans-cloud infrastructure deployment receives input from a user, the input including a Topology and Orchestration Specification for Cloud Applications (TOSCA) template and input parameters for instantiation via a graphical user interface (GUI), and includes applying the input parameters to the TOSCA template, creating a directed acyclic graph of the TOSCA template based on defined relationships, and executing the instantiation model through API calls to an orchestration engine based on an order defined in the acyclic graph. The TOSCA template and input parameters can specify a region for the deployment and / or a server plan.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 63 / 079,413, filed September 16, 2020, which is incorporated herein in its entirety.

[0002] TECHNICAL FIELD OF THE DISCLOSED EMBODIMENTS The present disclosure relates to the configuration and deployment of cloud computing infrastructure. [Background technology]

[0003] Systems for deploying infrastructure in cloud computing environments focus on automated deployment of infrastructure to a specific cloud vendor. Such systems allow for the configuration and deployment of cloud infrastructure, such as RightScale Cloud Application Templates, Cloudify, and Hashicorp Terraform. However, known solutions require that configuration be limited to a specific cloud vendor, making this difficult and inefficient. These solutions are "multi-cloud" in the sense that they allow for describing infrastructure on different cloud vendors, but they require specific descriptions for each cloud vendor. However, such solutions do not generally allow for configuring infrastructure across multiple cloud vendors at once. Summary of the Invention

[0004] The embodiments disclosed herein allow for describing infrastructure independent of cloud vendor, making cloud vendor selection a mere parameter in the automated deployment of the infrastructure, and allowing for automated deployment of the complete infrastructure in any cloud vendor's cloud. This trans-cloud approach allows for configuring infrastructure across multiple cloud vendors at once.

[0005] The embodiments disclosed herein allow users to automatically deploy infrastructure in multiple cloud vendors based on infrastructure descriptions (service templates). The embodiments disclosed herein provide abstraction over specific cloud vendor infrastructure. The embodiments disclosed herein use the Topology and Orchestration Specification for Cloud Applications (TOSCA) standard to describe the infrastructure independent of the implementation, and use a new component, a TOSCA interpreter that extends known orchestration engines (e.g., Ingram Micro Cloud Orchestrator), to enable workflow automation. This improvement allows users to dynamically select cloud vendors, regions, server plans, etc. during deployment of a cloud application template.

[0006] The systems and methods provided enable automated trans-cloud deployment of cloud infrastructure. [Brief description of the drawings]

[0007] The embodiments and other features, advantages and disclosures contained herein, as well as the manner of achieving the same, will become apparent and the disclosure will be better understood by referring to the following description of various exemplary embodiments of the disclosure in conjunction with the accompanying drawings.

[0008] [Figure 1] FIG. 1 is a schematic diagram of an embodiment of a system for automating cloud infrastructure deployment, according to an exemplary embodiment.

[0009] [Diagram 2] FIG. 1 is a schematic diagram of a cloud orchestrator architecture, according to an example embodiment.

[0010] [Diagram 3] FIG. 2 is a schematic diagram of a process performed by a TOSCA interpreter, according to an exemplary embodiment.

[0011] [Figure 4] FIG. 2 illustrates a directed acyclic graph (DAG) instantiation provided by a TOSCA interpreter, according to one exemplary embodiment.

[0012] [Diagram 5] FIG. 1 illustrates an exemplary computing device, according to one exemplary embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe those embodiments, nevertheless it will be understood that no limitation of the scope of the disclosure is thereby intended.

[0014] In one embodiment, the solution may be implemented using a cloud orchestrator such as Ingram Micro Cloud Orchestrator (available from Ingram Micro Inc., Irvine, Calif., USA). In some embodiments, the cloud orchestrator allows a user to create and deploy a complete infrastructure step by step (i.e., blueprint by blueprint, network by network, firewall profile by firewall, server by server). The cloud orchestrator does not allow for the complete infrastructure to be deployed automatically.

[0015] FIG. 1 illustrates a cloud infrastructure deployment system that enables automated deployment of a complete infrastructure in any cloud vendor's cloud. According to some embodiments, a transcloud application template provides a transcloud abstraction that can be created and processed to deploy the infrastructure. As shown diagrammatically in FIG. 1, a cloud orchestrator 110 is integrated with a cloud service broker (CSB) platform 120 (e.g., "Ingram Micro Cloud Blue Platform," or other CSB platform) via a connector 140.

[0016] In some embodiments, the cloud orchestrator 110 may include one or more systems for managing cloud infrastructure of different cloud vendors 105. The cloud vendors 105 may include, for example, public cloud vendors (e.g., Amazon Web Services (AWS), Azure, Google Cloud Platform, IBM Bluemix, etc.) and private cloud vendors (e.g., VMware, OpenStack, etc.).

[0017] In some embodiments, the connector 140 may be implemented with an administrative application programming interface (API). The connector 140 may provision customers, users, and cloud credentials on the CSB platform 120. In some embodiments, the connector also initiates a single sign-on (SSO) workflow that allows a user to log into the CSB platform 120.

[0018] In some non-limiting examples, a user (e.g., a customer, developer, administrator, etc.) logs into the CSB platform 120 and creates a subscription to a public cloud service (e.g., Azure service, etc.). The user then configures and deploys the infrastructure through a cloud orchestrator portal, e.g., configuration management tool 130. The CSB platform handles the business logic such as collecting usage data, storing the service catalog with prices, invoicing customers, creating / deleting / modifying subscriptions, managing access, providing SSO to public cloud vendor portals and cloud orchestrator portals, providing multi-tier and multi-channel management and business intelligence, etc.

[0019] 2 is a schematic diagram of a cloud orchestrator architecture in the context of a cloud infrastructure deployment system. Referring to FIG. 2, a system 200 for performing a trans-cloud infrastructure deployment includes a cloud orchestrator 210 architecture, a public cloud vendor, Da, and a configuration management tool 240.

[0020] Typically, cloud infrastructure may be deployed manually, piece by piece, through a web user interface (UI) or through an API. For example, a user may create a virtual network and then create two subnets within it. The user may place a server within each subnet, and each server has a firewall profile and a specific blueprint describing the software configuration (including the operating system (OS)). In this blueprint, the user may point one server to another server. Traditionally, the blueprint and firewall profile were independent of the cloud vendor. The cloud vendor had to be selected during the creation of the network (if the server is part of the virtual network) or the server (if the server is not part of the virtual network). Previously, the user had to manually create the network, blueprint, server, etc.

[0021] According to embodiments described herein, cloud orchestrator 210 enables automation of infrastructure deployment processes, including transcloud application templates. This differs from conventional systems that only allow automation through tedious tasks using APIs, which requires, for example, ad-hoc scripting to execute a list of API calls. According to some embodiments, system 200 enables dynamic connection of front-end servers to back-end servers. That is, if the IP address of the back-end server changes at some point, the front-end server automatically updates the IP address it is pointing to. This aspect differs from conventional systems that do not update the connection.

[0022] According to some embodiments, cloud orchestrator 210 may include a cloud vendor catalog 212 , a customer object database 214 , a configuration data hub 216 , a cloud orchestrator API 218 , a TOSCA interpreter 220 , a cloud orchestrator portal 222 , and an orchestration engine 230 .

[0023] Cloud vendor catalog 212 stores generic images for different operating systems and different applications. Cloud vendor catalog 212 can store scripts that periodically communicate with cloud vendor image catalogs and update the cloud orchestrator's cloud vendor catalog. Customer object database 214 can store information about customer objects including information related to one or more cloud service subscriptions, SSO information, configuration information, etc. Configuration data hub 216 can store one or more roles to define patterns and processes that exist across nodes in an organization, for example belonging to a job function.

[0024] In comparison with conventional systems, the embodiment of the system 200 includes a transcloud TOSCA interpreter 220 as shown in Fig. 2. The TOSCA interpreter 220 can perform communication with other components and perform automation of the complete infrastructure deployment.

[0025] The TOSCA interpreter 220 may be a TOSCA orchestration component that executes the service template by calls to the cloud orchestrator API 218. In some non-limiting examples, the TOSCA interpreter 220 receives as input a TOSCA archive and additional input parameters. The input parameters may be anything that is a property of a TOSCA node. For example, a network CIDR (Classless Inter-Domain Routing) for a private network, the number of instances for a server array, etc. In the case of the TOSCA interpreter of the embodiments disclosed herein, it may also be a cloud provider or region of a network or server, or a server plan for a server. The TOSCA archive includes the service template and any additional files (Chef cookbooks, scripts, etc.). The service template includes a description of all infrastructure components (networks, servers, firewall profiles, load balancers, etc.) along with a description of the software stack to be run on the infrastructure. The TOSCA interpreter applies the additional input parameters to the template and instantiates the template by creating all the required resources through the orchestration engine.

[0026] According to some embodiments, TOSCA interpreter 220 dynamically builds a directed acyclic graph of TOSCA node template instances. To instantiate TOSCA service templates, TOSCA interpreter 220 uses abstractions of computing, networking, and software nodes and relationship types derived from TOSCA standard types. TOSCA service templates are cloud vendor independent. Cloud vendors may have a special order for instantiating servers and networks, sometimes the network should be configured first and sometimes vice versa. Orchestration RationThe engine 230 defines the order that is compatible with a particular cloud vendor. The TOSCA interpreter 220 Ration The order defined in the TOSCA service template can be modified to suit the engine. For example, the TOSCA interpreter 220 has a standard model for coupling servers to a network via "ports" (which essentially act as virtual NICs (Virtual Network Interface Controllers)). Ports are virtual NICs, not real NICs, and essentially orchestrate a server's access to the network. In TOSCA, the relationship between Compute node templates and Network node templates is mediated by the Port node template, which has more or less the same role as a virtual NIC on the cloud vendor side. What the TOSCA interpreter is doing here is that instead of following the dependency order defined in the TOSCA service template of first the server, then the virtual NIC, it uses the dependency order defined in the TOSCA service template to orchestrate the server's access to the network. Ration The trick is to create the NIC and the server in a collaborative process to meet the sequence required by the engine.

[0027] During the TOSCA service template instantiation process, the TOSCA interpreter 220 uploads the list of cookbooks selected by the user to the orchestration engine, which then creates the roles in a configuration data hub, e.g., Chef.

[0028] The TOSCA interpreter 220 then deploys the infrastructure on the cloud vendor premises according to that service template. During or after the server boot (depending on the cloud vendor), the TOSCA interpreter 220 installs a small client program on the server that deploys and manages the software stack by installing a client that connects to a configuration management tool to get the correct software configuration. The client program also ensures that specified startup scripts are executed.

[0029] The cloud orchestrator API 218 provides an integration layer between the TOSCA interpreter 220 and the orchestration engine 230. The cloud orchestrator API 218 provides an orchestration engine that is provided on a web user interface. Ration It provides programmatic access to all operations of the engine 230, including defining firewall profiles, uploading software blueprints, Chef cookbooks, defining scripts, creating networks and servers, etc.

[0030] The cloud orchestrator portal 222 provides a UI through which a user can interact with and implement the cloud orchestrator. Through the cloud orchestrator portal 222, a user can select subscriptions on one or more public cloud vendors and create blueprints in which the user can select applications to deploy on this infrastructure and how the applications should be deployed (e.g., front-end to AWS servers, back-end to Azure). The user can enter other inputs including, but not limited to, an operating system (OS), Chef cookbooks, and scripts to be executed, for example, at server startup or shutdown, or manually at any time the server is running. The user can also select additional services including, but not limited to, firewalls, load balancers, etc.

[0031] The orchestration engine 230 generates the abstractions necessary to create the cloud infrastructure. It communicates with configuration management tools and with different cloud vendors to facilitate the deployment and operation of networks and servers with different software configurations across different cloud vendors. The orchestration engine 230 defines the order in which to instantiate servers and networks compatible with different cloud vendors. The creation of unified API calls is manual. The cloud orchestrator portal 222 (including the orchestrator web UI) and the cloud orchestrator API 218 can be used to control the orchestration engine 230. The core of this instantiation is the creation of firewall profiles, networks, and servers in the correct order. And part of the creation of a server is its blueprint (the orchestrator web UI) that defines its software configuration. Ration The first step is to define the engine blueprint.

[0032] The cloud orchestration engine 230 may include a network manager 231, an infrastructure manager 232, a cookbook 233, an orchestration engine blueprint 234, and one or more scripts 235.

[0033] The network manager 231 configures the network. The infrastructure manager 232 creates and configures the infrastructure.

[0034] Cookbooks 233 provide a unit of configuration and policy distribution in a configuration management tool (e.g., Chef). Cookbooks define a scenario and include each of the following components required to support the scenario: a) A recipe that specifies the resources to be used and the order in which they should be applied. b) Attribute values. c) File distribution. d) Extensions to Chef, such as custom resources and libraries. e) Cookbook (Attributes) - Configurable parameters from the Cookbook Recipe Run List. f) Cookbook (Run List) - The order of cookbook recipes that install the software. A Run List is not constrained to an individual cookbook. A Run List is typically a list of recipes from different cookbooks. g) Cookbook (order) - A group of recipes that affect a particular cookbook.

[0035] The orchestration engine blueprint 234 provides reusable configurations for virtual machines. The orchestration engine blueprint is a server blueprint that describes the software configuration (full software stack including OS) to be provisioned on an individual server. This is different from a TOSCA service template or a TOSCA topology template.

[0036] A script 235 is a list of executable commands that can be executed by one or more scripting engines. A script 235 can be in the form of a text document that includes instructions written using a scripting language for generating an executable process. A script 235 can include one or more script parameters, including parameters that affect the script, scripts that are manually introduced for a particular script, and script attachments, which can allow the script to include uploading or referencing any external documents with script code.

[0037] Configuration management tools 240 automate infrastructure configuration by transforming infrastructure into code. The tools automate how infrastructure is configured, deployed, and managed across a network, regardless of the size and / or type of cloud. Examples of configuration management tools include, but are not limited to, Chef, Puppet, Ansible, etc. Configuration management tools may include servers that are launched in the cloud by users to connect clients with the configuration management.

[0038] Cloud vendor catalog 212 stores generic images for different operating systems and different applications, and includes scripts that periodically communicate with the cloud vendor's image catalog and update the cloud orchestrator's cloud vendor catalog.

[0039] Embodiments of the cloud orchestrator architectures 110 and 210 allow users to deploy any infrastructure in multiple cloud vendors by creating a single service template. The cloud vendor, region and server plan selections can be provided as parameters of the service template.

[0040] According to some embodiments, the network and server node templates defined for the cloud orchestrator in the embodiments disclosed herein have a "region" property that specifies the cloud provider and region where a particular network or server should be deployed. This is in contrast to TOSCA implementations that do not describe the deployment region where the described infrastructure may be assumed to be deployed in a particular environment. By including the region property, a single service template can be provided to describe the infrastructure to be deployed across different cloud providers and regions. Furthermore, by expecting one or more regions as a TOSCA input parameter, the service template can be parameterized to specify one or more locations to deploy the actual infrastructure or parts thereof.

[0041] In a non-limiting example, a user specifies in a service template to run one server on Ubuntu 18.04 and another on Windows Server 2012. The user leaves server plans for both as parameters of the service template and runs on cloud orchestrator portal 222. The user runs the server plans to run the Ubuntu server in AWS East Virginia on a t3.medium server plan and the Windows server in Azure in West US on a Standard B2 server plan. Firewall rules can be automatically applied to both servers, independent of which cloud vendor they are deployed on. TOSCA Interpreter 220 It will discover the Ubuntu image on that AWS region and the Windows image on the Azure region and launch the correct server configuration.

[0042] In one non-limiting example, a user writes a TOSCA service template, i.e., a piece of code for infrastructure configuration. The first part of the TOSCA service template can include a topology template, which defines inputs, outputs, and nodes, node relationships, and policies. According to some embodiments of the system 200, cloud orchestrator-specific TOSCA data and node types allow the transcloud infrastructure to be defined.

[0043] 3 is a flow diagram of a method 300 for performing a trans-cloud infrastructure deployment according to some embodiments of the disclosure. In some embodiments, the method 300 provides operational steps for performing an implementation of a TOSCA template executed by the TOSCA interpreter 220. As noted above, the TOSCA interpreter 220 can execute inputs provided by a user via the cloud orchestrator portal 222. According to some embodiments, the process 300 can include execution of operations provided as inputs. Such operations can be input, for example, as software code uploaded by a user to the cloud orchestrator portal 222 for execution by the TOSCA interpreter 220.

[0044] 3, a computing device may receive input from a user including a TOSCA template and / or information related to the TOSCA template at operation 305. According to some embodiments, operation 305 may include receiving the input as software code uploaded by the user to cloud orchestrator portal 222 to be executed by TOSCA interpreter 220.

[0045] At operation 305, a service template can be created and a topology template can be specified to set several topology template inputs. The topology template inputs can include, for example, a region in which the network and servers should be deployed, a server plan, and a Classless Inter-Domain Routing (CIDR) specification. A non-limiting example of this code is provided below.

[0046] In this example, a topology template nested mapping is provided, with region and serve r p Input parameters are defined, including the lan parameter. tosca_definitions_version: tosca_simple_yaml_1_2 metadata: template_name: Magento template_author: Ingram Micro template_version: 0.8 topology_template: inputs: region: type: ingrammicro.orchestrator.datatypes.Region required: true description: Region for Magento servers metadata: order: 1 server_plan: type: ingrammicro.orchestrator.datatypes.ServerPlan required: true description: Server plan for Magento servers metadata: dependency: region order: 2 cidr: type: ingrammicro.orchestrator.datatypes.vpc.CIDR required: true default: 10.0.0.0 / 24 description: The CIDR block describing the VPC IPv4 address range metadata: order: 3 private_subnet_cidr: type: ingrammicro.orchestrator.datatypes.vpc.CIDR required: true default: 10.0.0.0 / 25 description: The CIDR block describing the VPC IPv4 address range metadata: order: 4 dependency: cidr public_subnet_cidr: type: ingrammicro.orchestrator.datatypes.vpc.CIDR required: true default: 10.0.0.128 / 26 description: The CIDR block describing the VPC IPv4 address range metadata: order: 5 dependency: cidr admin_user: type: string required: true description: Administrator user metadata: order: 6 admin_password: type: string required: true description: Administrator password metadata: order: 7 db_password: type: string required: true description: Password of the Magento DB metadata: order: 8 server_root_password: type: string required: true description: Root password of the server metadata: order: 9 sample_data: type: boolean default: true description: Create Sample Shop? metadata: order: 10

[0047] At operation 310, the computing device may receive input from a user including one or more input parameters associated with a TOSCA template for instantiation of a trans cloud infrastructure.

[0048] For example, at 310, a user can configure a node template to specify the network, the configuration of the servers, the relationships between each server, and in which regions they should be deployed. For each server, a software stack can be specified using available solutions from a configuration management tool.

[0049] A non-limiting example of a node template is provided below that specifies input parameters for instantiation of an infrastructure model, including a deployment region. Magento: type: ingrammicro.orchestrator.nodes.network.VPC properties: cidr: {get_input: cidr} region: {get_input: region} ip_version: 4 attributes: {} Magento Private Subnet: type: ingrammicro.orchestrator.nodes.network.Subnet properties: cidr: {get_input: private_subnet_cidr} gateway_type: private ip_version: 4 attributes: {} requirements: - vpc: Magento Magento Public Subnet: type: ingrammicro.orchestrator.nodes.network.Subnet properties: cidr: {get_input: public_subnet_cidr} gateway_type: public ip_version: 4 attributes: {} requirements: - vpc: Magento Magento Backend: type: ingrammicro.orchestrator.nodes.Compute properties: private: true region: {get_input: region} server_plan: {get_input: server_plan} attributes: {} capabilities: endpoint: properties: initiator: source network_name: PRIVATE port: 22 protocol: tcp secure: true attributes: {} Magento Backend Port: type: tosca.nodes.network.Port properties: is_default: true order: 0 attributes: {} requirements: - link: Magento Private Subnet - binding: Magento Backend Magento Frontend: type: ingrammicro.orchestrator.nodes.Compute properties: private: false region: {get_input: region} server_plan: {get_input: server_plan} attributes: {} capabilities: endpoint: properties: initiator: source network_name: PRIVATE port: 22 protocol: tcp secure: true attributes: {} Magento Frontend Port: type: tosca.nodes.network.Port properties: is_default: true order: 0 attributes: {} requirements: - link: Magento Public Subnet - binding: Magento Frontend Magento Backend Stack: type: ingrammicro.orchestrator.nodes.SoftwareStack requirements: - blueprint: Magento Backend Blueprint - host: Magento Backend Magento Backend Blueprint: type: ingrammicro.orchestrator.nodes.Blueprint properties: service_list: - magento::database@0.7.1 configuration_attributes: magento: db: password: {get_input: db_password} sample_data: {get_input: sample_data} user: username: {get_input: admin_user} password: {get_input: admin_password} mysql: allow_remote_root: "true" root_network_acl: 0.0.0.0 / 0 root_password: {get_input: server_root_password} capabilities: os: properties: architecture: x86_64 distribution: ubuntu type: linux version: "14.04" interfaces: Standard: create: inputs: cookbook_file: { get_artifact: [SELF, magento_cookbook]} artifacts: magento_cookbook: type: ingrammicro.orchestrator.artifacts.Chef.CookbookArchive file: cookbooks / magento-0.7.1.tar.gz Magento Frontend Stack: type: ingrammicro.orchestrator.nodes.SoftwareStack properties: configuration_variables: backend: reference: get_attribute: [Magento Backend, tosca_id] type: server requirements: - host: Magento Frontend - blueprint: Magento Frontend Blueprint - dependency: Magento Backend Magento Frontend Blueprint: type: ingrammicro.orchestrator.nodes.Blueprint properties: service_list: - magento::frontend@0.7.1 configuration_attributes: magento: db: host: $apply: - $private_ip - $server: backend password: {get_input: db_password} sample_data: {get_input: sample_data} user: username: {get_input: admin_user} password: {get_input: admin_password} Capabilities: OS: properties: architecture: x86_64 Distribution: ubuntu type: linux version: "14.04"

[0050] At operation 315, the computing device may apply one or more inputs at 310 to the TOSCA template specified at 305. Referring to the non-limiting example above, 315 may include applying the region and serve r p This may include applying the input parameters specifying the lan parameters and other input parameters received in 310 to a TOSCA template.

[0051] In operation 320, the computing device may create a directed acyclic graph (DAG) of TOSCA node instances based on the relationships defined in the above steps. The topology template is converted as a DAG, which describes the structure of the application to be deployed and includes its components in the form of nodes based on the node templates defined in 315 and their relationships (e.g., edges) that may be defined based on relationship templates. The DAG may include application-specific components, middleware, infrastructure components, etc.

[0052] An exemplary DAG specifying node instances 401 and 402 and relationships 410 between the node elements is provided in Figure 4 for illustration of the non-limiting example mentioned above. The DAG 400 specifies one server run 401 in Ubuntu 18.04 and another server 402 in Windows Server 2012. The Ubuntu server runs in AWS East Virginia on a t3.medium server plan and the Windows server runs in Azure in West US on a Standard B2 server plan.

[0053] The computing device may execute the instantiated model at operation 325. Operation 325 may include receiving API calls by an orchestration engine based on an order defined in the DAG.

[0054] According to some embodiments, operation 325 may include receiving the cookbook 233 by the orchestration engine 230. In a non-limiting example, a user may upload a cookbook 233 to be received by the orchestration engine 230.

[0055] Cookbooks 233 provide a unit of configuration and policy distribution in a configuration management tool (such as Chef). Cookbooks define scenarios and contain components including recipes for specifying resources to be used and the order in which to apply the resources, as described above, attribute values, file distributions, Chef extensions, and other components.

[0056] According to some embodiments, operation 325 may include receiving blueprints that define reusable configurations for the virtual machines. For example, each blueprint may describe a software configuration to be provided on each individual server.

[0057] According to some embodiments, operation 325 may include receiving a script 235 including a list of executable commands, which may be executed by one or more scripting engines, for example, at startup, shutdown, or any other applicable time. Operation 235 may include receiving a script including one or more script parameters including parameters affecting the script, script code for a particular script, and script attachments.

[0058] In one non-limiting example, the orchestration engine can receive inputs including policies via API calls. For example, a user can set policies, such as firewall configurations, which are submitted to the orchestration engine. Exemplary code submitted to the orchestration engine for implementing a firewall, including firewall policies, is provided below. - Magento Backend Firewall: type: ingrammicro.orchestrator.policies.FirewallProfile properties: rules: -port_range: - twenty two - twenty two source: any type: tcp -port_range: - 5985 - 5985 source: any type: tcp -port_range: - 3389 - 3389 source: any type: tcp -port_range: - 10050 - 10050 source: any type: tcp - name: mysql port_range: - 3306 - 3306 source: {get_input: cidr} type: tcp targets: - Magento Backend - Magento Frontend Firewall: type: ingrammicro.orchestrator.policies.FirewallProfile properties: rules: - port_range: - 22 - 22 source: any type: tcp - port_range: - 5985 - 5985 source: any type: tcp - port_range: - 3389 - 3389 source: any type: tcp - port_range: - 443 - 443 source: any type: tcp - port_range: - 80 - 80 source: any type: tcp - port_range: - 10050 - 10050 source: any type: tcp targets: - Magento Frontend outputs: frontend_ip: type: string description: IP of Magento Frontend server value: {get_attribute: [Magento Frontend, public_address]} frontend_id: type: string description: TOSCA ID of Magento Frontend server value: {get_attribute: [Magento Frontend, tosca_id]}

[0059] Various embodiments are shown, for example, in FIG. 5 The computer system 500 may be implemented using one or more computer systems, such as the computer system 500 shown in FIG. One or more computer systems 500 may be used to implement, for example, any of the embodiments described herein, as well as combinations and subcombinations thereof. For example, the computer system 500 may be used to implement the system 200 for performing a trans-cloud infrastructure deployment including the cloud orchestration architecture 210 of FIG. 2, the method 300 for performing a trans-cloud infrastructure deployment, and / or any other implementation of the disclosed embodiments.

[0060] Computer system 500 may include one or more processors (also referred to as central processing units, or CPUs), such as processor 504. Processor 504 may be connected to a communications infrastructure or bus 506.

[0061] The computer system 500 also includes user input / output devices such as a monitor, keyboard, pointing device, etc. S These may be in communication with the communications infrastructure 506 through the user input / output interface 502 .

[0062] One or more of the processors 504 may be a graphics processing unit (GPU). In some embodiments, a GPU may be a processor that is a specialized electronic circuit designed to handle mathematically intensive applications. GPUs may have an efficient parallel structure for parallel processing of large blocks of data, such as the mathematically intensive data common in computer graphics applications, images, video, and the like.

[0063] The computer system 500 may also include a main or primary memory 508, such as a random access memory (RAM). The main memory 508 may include one or more levels of cache. The main memory 508 may store therein control logic (i.e., computer software) and / or data.

[0064] The computer system 500 may also include one or more secondary storage devices or memories 510. 509 may include, for example, a hard disk drive 512 and / or a removable storage device or drive 514. The removable storage drive 514 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, a tape backup device, and / or any other storage device / drive.

[0065] Removable Storage Drives 515 may interact with a removable storage unit 518. 515 may include a computer usable or readable storage device on which computer software (control logic) and / or data are stored. 515 The removable storage drive 514 may be a floppy disk, a magnetic tape, a compact disk, a DVD, an optical storage disk, and / or any other computer data storage device. 515 It can be read and / or written.

[0066] Secondary Memory 509 may include other means, devices, components, equipment or other techniques for allowing computer programs and / or other instructions and / or data to be accessed by the computer system 500. Such means, devices, components, equipment or other techniques may include, for example, a removable storage unit, 517 and interface 516 A removable storage unit may be included. 517 and interface 516 Examples may include a program cartridge and cartridge interface (such as found in a video game device), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and / or any other removable storage unit and associated interface.

[0067] Computer system 500 may further include a communications or network interface 524. Communications interface 524 may enable computer system 500 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referred to by reference numeral 528). For example, communications interface 524 may enable computer system 500 to communicate with a communications path. 510 Through external or remote devices 520 A communication path that allows communication with 510 can be wired and / or wireless (or a combination thereof) and may include any combination of a LAN, a WAN, the Internet, etc. Control logic and / or data may be transmitted to and from computer system 500 via communications path 526.

[0068] The computer system 500 may also be any one or any combination of a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet, a smartphone, a smart watch or other wearable, an appliance, part of the Internet of Things, and / or an embedded system, to name a few non-limiting examples.

[0069] Computer system 500 can be a client or server that accesses or hosts any application and / or data through any delivery paradigm, including, but not limited to, remote or distributed cloud computing solutions, local or on-premise software ("on-premise" cloud-based solutions), "as-a-service" models (e.g., Content as a Service (CaaS), Digital Content as a Service (DCaaS), Software as a Service (SaaS), Managed Software as a Service (MSaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Framework as a Service (FaaS), Backend as a Service (BaaS), Mobile Backend as a Service (MBaaS), Infrastructure as a Service (IaaS), etc.), and / or hybrid models including any combination of the above examples or other service or delivery paradigms.

[0070] Any applicable data structures, file formats, and schemas in computer system 500 may be derived from standards including, but not limited to, JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations, alone or in combination. Alternatively, proprietary data structures, formats, or schemas may be used, alone or in combination with known or published standards.

[0071] In some embodiments, a tangible, non-transitory apparatus or article of manufacture that comprises a tangible, non-transitory computer usable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device, including, but not limited to, the computer system 500, the main memory 508, the secondary memory 509, the 509 , and a removable storage unit 515 and 517 and a tangible article of manufacture embodying any combination of the above. Such control logic, when executed by one or more data processing devices (such as computer system 500), can cause such data processing devices to operate as described herein.

[0072] From the above disclosure, it will be appreciated that the disclosed embodiments provide an abstraction to a specific cloud vendor infrastructure. Thus, a user can define templates that can be easily parameterized to the cloud vendor that the user wants to use to deploy the template. Thus, while prior art systems claim to be multi-cloud, this solution is much more than that. This is why the term "trans-cloud" is more suitable to characterize this approach.

[0073] The disclosed embodiments enable an integrated description of all aspects of a cloud application, from infrastructure and networks to software components and their relationships. It decouples the description of the topology from the implementing technology. It describes more than just the infrastructure. It enables abstraction over the implementing technology.

[0074] While the disclosure has been illustrated and described in detail in the drawings and foregoing description, the same is to be considered as illustrative and not restrictive in nature, it being understood that only specific embodiments have been illustrated and described and that all changes and modifications that come within the spirit of the disclosure are sought to be protected.

Claims

1. 1. A system for processing a trans-cloud application template, comprising: a server coupled to a processor and configured to execute instructions, the instructions comprising: receiving input from a user, the input including a Topology and Orchestration Specification for Cloud Applications (TOSCA) template and input parameters for instantiation of a TransCloud infrastructure via a Graphical User Interface (GUI); applying the input parameters to the TOSCA template; parsing the TOSCA template to dynamically build a directed acyclic graph of template instances of TOSCA nodes based on relationships defined between components of the infrastructure; Executing an instantiation model through API calls to an orchestration engine based on an order defined in the directed acyclic graph, the orchestration engine supporting dynamic selection of cloud vendor, region, server plan, and other parameters during deployment of the trans-cloud application template, the orchestration engine being configured to define an order compatible with the one or more cloud vendors and adapted to the order defined in the TOSCA service template through modification by a TOSCA interpreter; instructions to cause the server to receive one or more cookbooks including one or more recipes, attribute values, file distributions, and / or Chef extensions; The cookbook provides units of configuration and policy distribution, defines a scenario, includes components required to support the scenario, and includes custom resources, libraries as an extension of Chef; receiving one or more cookbooks by the orchestration engine and receiving the API call by the orchestration engine based on an order defined in the directed acyclic graph; the orchestration engine is configured to enable dynamic selection of the cloud vendor and region based on an order defined in the directed acyclic graph such that various components of an application may be deployed to distinct cloud vendors and regions based on the TOSCA template; The system is configured to process the cookbooks together with the TOSCA templates in a cloud environment to deploy and configure application components.

2. The system of claim 1 , wherein the server comprises a cloud orchestrator API, the TOSCA interpreter, and the orchestration engine.

3. The system of claim 1 , wherein the TOSCA template comprises a cloud provider and / or region property that specifies at least one of a region in which a particular network or server should be deployed.

4. 2. The system of claim 1, wherein the TOSCA template includes a server plan property that specifies a plan for a node specified in the TOSCA template and configured to instantiate the server.

5. The system of claim 1 , wherein the executing the instantiation model comprises deploying a cloud infrastructure based on the directed acyclic graph.

6. The system of claim 1 , wherein the system is further configured to automate a deployment process of infrastructure in a transcloud.

7. The system of claim 1 , wherein creating the directed acyclic graph comprises dynamically constructing, by the TOSCA interpreter, a directed acyclic graph of TOSCA node template instances based on the TOSCA template and input parameters.

8. receiving input from a user including a Topology and Orchestration Specification for Cloud Applications (TOSCA) template and input parameters for instantiation of a trans-cloud infrastructure via a Graphical User Interface (GUI); applying the input parameters to the TOSCA template; and parsing the TOSCA template to dynamically build a directed acyclic graph of TOSCA based on defined relationships between infrastructure components; Executing instantiation models through API calls to an orchestration engine based on an ordering defined in the directed acyclic graph, the orchestration engine supporting dynamic selection of cloud vendor, region, server plan, and other parameters during deployment of a trans-cloud application template, the orchestration engine being configured to define an ordering compatible with the one or more cloud vendors and adapted to the ordering defined in the TOSCA service template through modification by a TOSCA interpreter; receiving one or more cookbooks including one or more recipes, attribute values, file distributions, and / or Chef extensions; The cookbook provides configuration and policy distribution units, defines scenarios and includes components required to support the scenarios, and includes custom resources and libraries as an extension of Chef; receiving one or more cookbooks by the orchestration engine and receiving the API call by the orchestration engine based on an order defined in the directed acyclic graph; the orchestration engine is configured to enable dynamic selection of the cloud vendor and region based on an order defined in the directed acyclic graph such that various components of an application may be deployed to distinct cloud vendors and regions based on the TOSCA template; A computer-implemented method, wherein a computer is configured to process the cookbook together with the TOSCA template within a cloud environment to deploy and configure application components.

9. The method of claim 8 , wherein the TOSCA template comprises a cloud provider and / or region property that specifies at least one of a region in which a particular network or server should be deployed.

10. 9. The method of claim 8, wherein the TOSCA template comprises a server plan property that specifies a plan for a node configured to instantiate a server specified in the TOSCA template.

11. The method of claim 8 , wherein the executing the instantiation model comprises deploying a cloud infrastructure based on the directed acyclic graph.

12. 9. The method of claim 8, wherein creating the directed acyclic graph comprises dynamically constructing, by a TOSCA interpreter, the directed acyclic graph of TOSCA node template instances based on the TOSCA template and input parameters.

13. A non-transitory tangible computer readable device having instructions stored thereon that, when executed by a computing device, cause the computing device to perform operations, including: receiving input from a user including a TOSCA template and input parameters for instantiation of a transcloud infrastructure via a graphical user interface (GUI); applying the input parameters to the TOSCA template; and parsing the TOSCA template to dynamically build a directed acyclic graph of TOSCA based on defined relationships between infrastructure components; Executing instantiation models through API calls to an orchestration engine based on an ordering defined in the directed acyclic graph, the orchestration engine supporting dynamic selection of cloud vendor, region, server plan, and other parameters during deployment of a trans-cloud application template, the orchestration engine being configured to define an ordering compatible with the one or more cloud vendors and adapted to the ordering defined in the TOSCA service template through modification by a TOSCA interpreter; receiving one or more cookbooks including one or more recipes, attribute values, file distributions, and / or Chef extensions; The cookbook provides configuration and policy distribution units, defines a scenario, includes components required to support the scenario, and includes custom resources, libraries as an extension of Chef; receiving one or more cookbooks by the orchestration engine and receiving the API call by the orchestration engine based on an order defined in the directed acyclic graph; the orchestration engine is configured to enable dynamic selection of the cloud vendor and region based on an order defined in the directed acyclic graph such that various components of an application may be deployed to distinct cloud vendors and regions based on the TOSCA template; The computing device is a non-transitory, tangible, computer-readable device configured to process the cookbooks together with the TOSCA templates in a cloud environment to deploy and configure application components.

14. 14. The non-transitory, tangible, computer-readable device of claim 13, wherein instructions are configured to utilize the TOSCA interpreter to execute the orchestration engine of the computing device.

15. 14. The non-transitory tangible computer readable device of claim 13, wherein the TOSCA template comprises a region property that specifies a cloud provider and / or at least one of a region in which a particular network or server should be deployed, and a server plan property that specifies a plan for a node specified in the TOSCA template and configured to instantiate a server.

16. 14. The non-transitory, tangible, computer-readable device of claim 13, wherein the executing the instantiation model comprises deploying a cloud infrastructure based on the directed acyclic graph.

17. 14. The non-transitory, tangible, computer readable device of claim 13, wherein the non-transitory, tangible, computer readable device is further configured to automate a deployment process of infrastructure in a trans cloud.

18. 14. The non-transitory, tangible, computer-readable device of claim 13, wherein creating the directed acyclic graph includes dynamically constructing, by a TOSCA interpreter, a directed acyclic graph of TOSCA node template instances based on the TOSCA template and input parameters.

Images