With multi-cloud templates, you can create a single service that can be deployed on multiple datacenters, as well as multiple private, public, or hybrid clouds.
Here are some examples of services that you can publish using multi-cloud templates:
- a service that can be deployed on vCenter, SCVMM, AWS, or Azure
- a service that can be deployed on multiple vCenters
You can also use multi-cloud templates to make it easier to keep the service catalog up to date. Create a multi-cloud template that contains a single base OS template, such as CentOS, and then create multiple published services that point to this multi-cloud template. Use completion workflows or configuration management tools (such as Chef or Puppet) to install custom software on the deployed VMs. When it's time to update the template, you only have to edit the multi-cloud template; all published services pointing to this template will automatically be updated.
Depending on your environment, you can create multi-cloud services in different ways. For example, if you want to create a three-tier service, you could:
- Create three multi-cloud templates, one for each tier, as shown in the image above
- Create two multi-cloud templates: one for the database, and one for both the web server and middleware tiers. The web server and middleware tiers could then be configured using Chef, Puppet, or a configuration spec.
Publishing a multi-cloud service involves two steps:
You can create multi-cloud services from existing services. See Create Multi-Cloud Service Catalogs from Existing Services.
- The details of a multi-cloud catalog entry don't include information about its source multi-cloud templates.
- Multi-cloud services aren't yet supported for Google Cloud Platform.
- You can't add any of the following to a multi-cloud template: CloudFormation templates, ARM templates, virtual service templates, OVA templates, or OVF templates.
Configuration > Self-Service
Commander Role of Superuser, Enterprise Admin
- Click the Catalog tab.
- On the Catalog page, click Multi-Cloud > Manage multi-cloud templates.
- In the Manage Multi-Cloud Templates dialog, click New Multi-Cloud Template.
- Provide a name for the template, and an optional description. For example, if you're creating a multi-cloud template for Windows 2012 , use the name "Windows 2012".
- To add a private template:
- Click Add VM Template and choose VM Template, Image or AMI.
- In the Available Templates and VMs dialog, navigate to the first VM template you want to add to the list, select it, customize the name if you wish, and click Add to Multi-Cloud Template.
- Click Close to close the Available VMs and Templates dialog.
- To add an AMI from the Amazon Marketplace:
- Click Add and choose Amazon Marketplace AMI.
- If necessary, use the Show drop-down list to change the scope of the list.
Use the Quick Search to locate VM templates.
The Add Amazon Marketplace AMI dialog displays a list of Marketplace AMIs, sorted by name.
If you very recently installed Commander or added an AWS account as a cloud account, you may have to wait a few minutes for the list to be populated.
- Favorites: Displays a list of favorite AMIs. Only the latest version of each AMI is available in the favorites list. You can customize the favorite AMIs list.
- Marketplace (latest version): Display only the latest version of each AMI.
- Marketplace (all): Display all Marketplace AMIs.
- entering text in the search field. The search is based on the AWS properties Name, Description and ID
- making a selection from the Platform drop-down list
If Commander is unable to determine the platform for an AMI from the AWS API, the Platform is displayed as Unknown.
When you select an AMI, its details are displayed in the Details section to the right. The ID property isn't shown in Commander. The Regions property shows whether an AMI can be deployed to all regions, or only to a subset.
Important: If you have not subscribed, service deployment will fail.
This is the component name that a user sees when completing a service request form.
Because Amazon Marketplace AMIs are typically deployable in all regions, once you've added an Amazon Marketplace AMI to a multi-cloud template, you can't add another Marketplace AMI, or a non-Marketplace AMI. The Regions property in the Details section of the Add Amazon Marketplace AMI dialog shows whether an AMI can be deployed to all regions, or only a subset.
In our example, we've added a Windows 2012 VM template from our vCenter and AWS cloud accounts. For public clouds, make sure to add an image from each region where you want to be able to deploy this service.
Once you've added a VM template, the list is automatically filtered to show only compatible items. The following rules are used:
- You can add only one VM template from each VMware datacenter.
- You can add only one VM template from each public cloud region.
- You can add only one VM template from each SCVMM cloud account.
- All VM templates of the same cloud account type must have the same number of disks and network adapters. For example, all VMware VM templates in a multi-cloud template must have the same number of disks and templates.
Configuration > Self-Service > Catalog tab
Commander Role of Superuser, Enterprise Admin
- On the Catalog tab, click Add Service.
- On the Service Description page, enter a Name to be displayed for the service in the Service Catalog.
This name is used as the label for the Service section of the Request New Service form. Choose a distinctive Service Name to help requesters fill out the form.
- Optional: Enter a Description for this service.
Along with the Name field, the Description field is used in Service Catalog searches, so adding a description can help users find service catalog entries.
- Choose an Icon from those available. To add an icon, click Manage Icons. See Manage icons for the service catalog for more details.
- To help users find this service in a long list, choose one or more Categories from those available. To add a category, click Manage Categories. See Manage Service Catalog categories for more details.
- On the Component Blueprints page, click Add > Multi-Cloud Template.
- In the Add Multi-Cloud Template dialog, select a multi-cloud template and click Add to Service.
- Add more multi-cloud templates or custom components to the service if desired.
- Click Close.
If the service-level form elements such as Quantity and Expiry Date don't make sense for this service, you can hide the service portion of the service request form by clearing the Display service form when this service is requested checkbox.
All multi-cloud templates added to a service must share at least one VM template location. For example, let's say one multi-cloud template includes a base OS template that can be deployed only on-premises. You could add another multi-cloud template that includes a base OS template that can be deployed to any of your cloud accounts.
The multi-cloud templates you added appear on the Component Blueprints page.
A component blueprint page appears in the wizard for each multi-cloud template you added. Each component blueprint page contains at least four tabs: Infrastructure, Resources, Attributes and Form. See the following sections for details on each option.
If your multi-cloud template includes templates from multiple cloud types (for example, AWS and VMware), you will see cloud-independent settings at the top of the Infrastructure tab, and cloud-specific settings at the bottom of the Infrastructure tab.
There are no Infrastructure settings specific to SCVMM.
If your multi-cloud template includes templates from multiple cloud types (for example, AWS and VMware), you will see a section for each cloud in the Resources tab.
You can assign metadata to the service component with custom attributes and groups.
Attributes tab settings apply globally to the deployed component. If you want custom attribute values and groups to vary depending on whether the VM is deployed, you should instead create conditional component-level completion workflows. For example, you may want to assign different power schedule groups for VMs deployed on AWS and VMware. In this case, you'd add two conditional Set Groups steps to the component-level completion workflow: one that acts on components deployed on AWS, and one that acts on components deployed on VMware. To learn more about conditional workflows, see Make Workflow Steps Conditional.
Set custom attributes and their default values for this specific component. On the Form tab, you can allow requesters to set values for custom attributes. If you don't specify a default value, no default is set for the component. If you add an attribute on the Form tab, the default value you set on the Attributes tab is presented to the requester as the default value.
To be able to add a custom attribute for this component on the request form, you must add the custom attribute on the Attributes tab first.
If custom attributes were defined for the source VM template, they are prepopulated here. Click if you don't want this attribute to apply to this service component.
Custom attributes defined for source VM templates aren't displayed for multi-cloud services.
Click Add Attributes to select from the list of existing custom attributes. In the Add Attributes dialog, Form attributes and custom attributes applicable to the current component type are displayed.
To edit existing custom attributes, click Manage Attributes. On the Custom Attributes page, you can add and edit custom attributes. Click the browser's Back button to return to the Attributes tab.
If you add list-type custom attributes that are interrelated, the attributes are displayed in the order of parent to child to grandchild (if applicable). Your selection of a default value for the parent affects the selectable values for the sublist attribute. To learn more, see Create Relationships Between Attributes Used on Forms.
Set the default groups for this component. To learn about groups, including other methods for assigning groups to new services, see Manage Service Groups.
If this component is a VM or VM template, groups assigned to the source template or VM aren't prepopulated on the Attributes tab.
Click Add Groups to select one or more group types and click OK. On the Attributes tab, select a group from the relevant menu.
To add, edit, or delete groups, click Manage Groups; when finished, click your browser's Back button to return to the Attributes tab.
If you have integrated a Puppet server with Commander, Puppet environments, classes and groups are displayed on the Puppet tab for service components. Select an environment for the VM component. Once you select an environment, only those classes and groups found in that environment are available for selection.
You can select one or more default classes and groups. Ctrl-click to select multiple classes and groups.
Assign classes to nodes indirectly by assigning groups to nodes, rather than directly assigning classes to nodes. If you use the Configure Puppet workflow step to assign classes and variables to a node, Commander creates a group with the same name as the node and pins the node to the group. A parent group named "vCommander" is also created to contain these groups.
You can also allow users to select classes and/or groups on the Form tab. You can then use variables to return the requested values through a completion workflow. See Integrate Puppet with Commander for more information.
If you have integrated one or more Chef servers or organizations with Commander, Chef information is displayed on the Chef tab for service components.
If you have added multiple Chef servers or organizations, select a server or organization from the Chef Organization menu. Otherwise, the Chef organization is displayed as a read-only value.
Select an environment from the Chef Environment menu. The roles and recipes for the selected environment are displayed.
Select one or more default roles and recipes from the Available Roles and Recipes pick-list. Ctrl-click to select multiple roles and recipes. Use the arrow buttons between the lists to move your selections into the Current Run-List. Then order the roles and recipes properly.
If you don't select default roles and recipes, no defaults are applied.
You can then use variables to return your selections through a completion workflow. For more information, see Integrate Chef with Commander.
On this tab, you customize the form users see when they request this specific component. Adding elements to the Form tab allows requesters to change the default settings you configured on the other tabs.
You must add form elements applicable to each cloud; for example, if you want users to modify storage resources for a service that can be deployed on VMware or AWS, you must add both the Storage and the Storage-AWS form elements. If you want users to modify resource requirements for a service that can be deployed on VMware or AWS, you must add the CPU Count, Memory and Instance Type form elements. When a user requests a multi-cloud service, the component form automatically displays only the elements applicable to the selected destination.
If a user requests changes from the default settings configured in the service catalog, these changes are displayed in approval emails, on the approval landing page, and in the Request Details dialog.
If you leave the Form tab blank for all components added to the service, users won't see a component form when they request a service; they will see only the service-level form page provided by the new service request definition. For more information, see Create New Service Requests.
When you've finished setting options for each component in the service, specify deployment options for the entire service.
Deployment Order/Startup Order or Deployment Order
Some components in a multi-tier service may require other components to be started and running before they can start.
If you deploy the service as a virtual service, you specify both the order in which the components are deployed and the order in which the components are started.
If you deploy the service as individual components, you specify the order in which the components are deployed. The reverse order is used for shutdown.
There is a 120 second delay between startup and shutdown of each component.
Within each group, components are sorted in alphabetical order. Components are deployed serially, not in parallel.
An administrator can override this deployment order by manually deploying components in a different order. It's also possible for Commander and Service Portal users with permissions to edit the start order for a deployed vApp.
Completion workflows allow you to specify actions to be carried out after deployment.
If you have set up one or more service-level completion workflows, you can select one from the drop-down list.
You can click Add Workflow to create a new workflow.
You can click Edit Workflow to edit the workflow that's currently selected in the drop-down list.
When you edit the workflow using this link, you're editing the workflow for all of the components or services it's assigned to.
There are no Deployment settings specific to AWS.
There are no Deployment settings specific to Azure.
If you enable this option, all components in the service will be deployed as highly available VMs.
An administrator can override this option during manual deployment. If this option is enabled, automated deployment will use a deployment destination that supports high availability.
Start Deployed Components
By default, VMs are powered on during deployment. If you want to deploy VMs in this service in a powered-off state, clear this option.
When this option isn't enabled and a customization spec is assigned to a component in the service, if the VM is migrated to a different datastore before its first power on, the customization spec won't run.
When you assign a placement attribute value to a published service, you're identifying the requirements of that published service to help ensure that services are deployed to the best destination.
- Click Edit Placement Attributes.
- In the Edit Placement Attributes dialog, in the Not Required pane, select an attribute value that's provided by this destination and click Add to move it to the Required pane.
- Click OK to close the Edit Placement Attributes dialog.
- The placement attribute values you've assigned to this service are displayed on the Placement page.
- For a placement attribute with selectable values, use the Up and Down arrow buttons to order the attribute values by preference. For example, if a service can be deployed on either private or public cloud, but private cloud is preferable, make sure the Private Cloud attribute value is first in the list.
To learn more, see Configure Placement Attributes.
Specify which users and groups can request this service.
Review the details and click Finish.
The service that you added or changed is displayed in the Service Catalog List View or Table View.
To edit the service at any time, select it in the list and click Edit. You can use the Service Type column of the service catalog Table View to distinguish multi-cloud services from single-cloud services.
Updating multi-cloud templates
If you edit a multi-cloud template, Commander automatically updates any service catalog entries referencing the multi-cloud template. However, you may need to review blueprint configuration settings. For example, if you add an Azure VM template to a multi-cloud template that already includes VMware and AWS VM templates, Commander will automatically apply default Azure settings to all multi-cloud services referencing the multi-cloud template. But if the Azure VM template requires credentials, and you have not configured the request form to prompt for credentials, you need to add credentials to the service catalog blueprints for all catalog entries referencing that multi-cloud template to ensure successful deployment.
See also Repair corrupt service catalog entries.
If you see the following error when attempting to add a multi-cloud template to a service that already contains a multi-cloud template:
"The VM template locations in the selected multi-cloud template don't match locations in previously added multi-cloud templates. These new locations won't be used when this service is deployed."
This means that some of the VM templates in the service will never be deployed.
For example, let's say the first multi-cloud template added to the service contains VM templates from AWS US-East-1 and a VMware datacenter named Engineering. If you add a second multi-cloud template that contains VM templates from AWS US-East-1 and a VMware datacenter named Automation, the multi-cloud service will never be deployed to VMware, because the VMware locations don't match.