2

Integrating Tanzu Mission Control with vRealize Automation Custom Resources

 3 years ago
source link: https://blogs.vmware.com/management/2021/04/integrating-tanzu-mission-control-with-vrealize-automation.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
Integrating Tanzu Mission Control with vRealize Automation Custom Resources

VMware Tanzu Mission Control provides multi-cluster Kubernetes management across clouds.

VMware Tanzu Mission Control is a centralized management platform for consistently operating and securing your Kubernetes infrastructure and modern applications across teams and clouds.

https://tanzu.vmware.com/mission-control

This blog post details the use of a Dynamic Type in vRealize Orchestrator to provide Tanzu Mission Control Managed Kubernetes Clusters as a Custom Resource within vRealize Automation. This means that you can create VMware Cloud Templates to deploy Tanzu Mission Control managed Kubernetes Clusters on-demand, with the benefits of vRealize Automation wrapped around.

Note: The code and instructions in this blog post are the art of the possible. This is not a VMware supported solution, nor is it recommended for a production environment without first having the knowledge and skillset to develop and maintain Dynamic Types.

Configuring the Dynamic Type

Dynamic Types are an advanced customization topic and do require a good understanding of vRealize Orchestrator and vRealize Automation to successfully configure.

Prerequisites

Generate an API Token

To configure access for vRealize Automation to manage Tanzu Mission Control clusters you need to create a new API Token from you VMware Cloud Services console. Head over to My Account > API Tokens and click GENERATE TOKEN. Configure appropriate permissions (I’ve configured Organization Member and Tanzu Mission Control Admin) and generate the token.

Import the Cache plugin

Download the Cache plugin from the GitHub repository and log into the vRealize Orchestrator Control Center (https://appliance.fqdn/vco-controlcenter). Navigate to the Manage Plug-ins page. Browse to the downloaded plugin file, then click UPLOAD. Accept the (empty) EULA, and click INSTALL. Once the plugin is installed you need to wait 2-5 minutes without making changes in order for the Orchestrator service to restart and load the Plugin.

Note: The Cache plugin is community provided and is not supported by VMware.

Import the Dynamic Type package

In the vRealize Orchestrator UI, expand Library > Workflows and run the “Import Configuration From Package” workflow from the Library/Dynamic Types/Configuration folder. Select the downloaded TanzuMissionControl-DynamicType.package and check the TanzuMissionControl namespace to import.

It is very important to import the package using this workflow, and not the standard package import mechanism! This workflow configures the Dynamic Type.

You can validate that the Dynamic Type has imported successfully by going to the Administration > Inventory view in vRealize Orchestrator and expanding the Dynamic Types explorer. The Type Hierarchy should include the Organizations and Clusters types. There should also be an empty TanzuMissionControl namespace.

Adding a Tanzu Mission Control Organization

The Dynamic Type package includes a workflow to add Tanzu Mission Control organizations to the configuration. Under Workflows > TanzuMissionControl > Configuration, run the “Add a Tanzu Mission Control Organization” workflow. There are two inputs, the tmcOrg amd tmcApiKey – the API key is the one you generated earlier, and the Org is part of your Tanzu Mission Control URL – e.g in https://smcgorg.tmc.cloud.vmware.com the Org name is “smcgorg”

The “Add a Tanzu Mission Control Organization” workflow will create an entry in the ConfigurationItem TanzuMissionControl/Organizations, trigger the Dynamic Type creation and import the SSL certificate for Tanzu Mission Control.

The organization should now be listed under the Dynamic Types inventory, and any existing clusters should be listed (I don’t have any in my TMC Org yet)

One final check is to look at the Activity > Workflow Runs page, which should show the execution of the TanzuMissionControl “finder” workflows. (The failed workflow here is because there are no Clusters configured, it can be safely ignored!)

Adding Tanzu Mission Control Types to Cloud Assembly

In order to consume and manage Tanzu Mission Control clusters from Cloud Assembly they must first be added as Custom Resources.

From the Design > Custom Resources page, add a new Custom Resource and configure the Name, Resource Type, Scope and Lifecycle Actions

The package also includes an example Day 2 action – creating an additional Worker Node Pool. This action can be added to the Additional actions configuration:

Once created, the new type should be available to add to Cloud Templates (blueprints).

Creating a Tanzu Mission Control Cluster Cloud Template

With the Custom Resource created the Custom.TMCCluster object can be dragged onto the design pane and the properties set either in the YAML or UI to configure a cluster deployment just like any other resource type:

You might notice that there are a lot of properties available for the cluster object – this is because there are a lot of options when deploying the cluster in Tanzu Mission Control.

You can hard code values for a specific cluster type into the blueprint YAML and just customize a few fields with inputs, such as the cluster name when requesting the blueprint – this might serve well if you need self-service clusters of a uniform type. The GitHub repository has some Cloud Template Examples, including one to import existing Tanzu Mission Control Clusters into management by vRealize Automation.

The example YAML code below describes a Cloud Template for a Development (non-HA control plane) cluster deployed on AWS with the choice of 1, 3 or 5 worker nodes:

formatVersion: 1 inputs: tmcClusterName: type: string title: Cluster Name description: Existing Tanzu Mission Control Cluster Name default: test-01 tmcOrganziationId: type: string title: Organization ID description: Dynamic Types TMC Organization ID default: a06792a4-70b5-469b-9dfc-3a3fb49ec3ae tmcProvisionerSshKey: type: string title: SSH Key description: Name of the SSH key (AWS - us-east-1) default: smcg-tmc-us-west-1 tmcNodePoolCount: type: string title: Number of Worker Nodes description: Name of the SSH key (AWS - us-east-1) default: '1' enum: - '1' - '3' - '5' resources: TMCCluster: type: Custom.TMCCluster properties: tmcOrganizationId: '${input.tmcOrganziationId}' tmcClusterName: '${input.tmcClusterName}' tmcClusterGroupName: default tmcClusterManagementCluster: aws-hosted tmcClusterProvisioner: spc-46-aws tmcProvisionerRegion: us-east-1 tmcProvisionerPodCIDR: 192.168.0.0/16 tmcProvisionerKubernetesVersion: 1.19.1-3-amazon2 tmcProvisionerServiceCIDR: 10.96.0.0/12 tmcProvisionerSshKey: '${input.tmcProvisionerSshKey}' tmcControlPlaneAz1: us-east-1a tmcControlPlaneInstanceType: m5.large tmcNodePoolName: default-node-pool tmcNodePoolAz: us-east-1a tmcNodePoolInstance: m5.large tmcNodePoolCount: '${input.tmcNodePoolCount}' tmcProvisionerVPC: vpc-0aebc773082a7afc9 tmcProviderPublicSubnetAz1: subnet-0ce512b804f2e79ee tmcProviderPrivateSubnetAz1: subnet-0e8ddb5720120be86 tmcProvisionerCredential: spc-46-aws

This gives a few options to the requestor, but controls other options (such as whether it’s HA, what size of node to deploy etc). This requires some knowledge up front, for example the relevant VPC ID, the Subnet IDs or the correct Kubernetes version.

Using Custom Forms

Understanding the various input combinations is a bit tricky, so to make life a little easier, we can create a Custom Form in Service Broker to provide some dynamic form inputs, and input validation. The package includes Orchestrator Actions designed for use with Custom Forms to generate the populated forms by querying the Tanzu Mission Control API.

Using these Actions, it’s possible to create a more complex, dynamic form to account for many different options, the following video shows the TMC Kubernetes Cluster – Custom Cloud Template and Custom Forms used together to create a more dynamic custom request:

As I mentioned above, you can also assign Day 2 actions to perform on Custom Resource types, and included in the package is an example to add a Worker Node Pool to a Tanzu Mission Control Cluster. When you select the Cluster in a Deployment you can use the Actions menu to add worker nodes to the cluster:

The following examples are useful in understanding vRealize Orchestrator Dynamic Types (they’re older – but DTs have not changed much in the past 5+ years!)

Next steps

The TanzuMissionControl-DynamicType package is available to download from our GitHub repository, which includes everything needed to get started.

If you want to find out more about vRealize Automation please visit our website, or learn more about our features,and to explore vRealize Automation Cloud get started with a free 45-day trial! You can also test drive Tanzu Mission Control using this Hands-On-Lab to explore the product.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK