Onboard existing workloads in Cloud Automation Services
Whenever I talk to customers regarding vRealize Automation or Cloud Automation Services the same questions/remarks pop up on how to onboard existing workloads.
“This is probably only for green field deployments?!”
“Can I use this to manage existing workloads?
“What about my existing vSphere/AWS/Azure deployments?”
This is a hot topic and I understand that not all customers are able to start with a clean slate and to be honest, why should you. Only a small percentage of my customers have the luxury of starting with no history, no luggage and a decent cloud management solution should be able to do both. Start from scratch or onboard you existing environment.
I must admit, vRealize Automation is able to onboard existing workloads but it’s not the best, fool proof, low effort on boarding process I’ve seen. VMware’s new Cloud Automation Services however makes onboarding existing workloads simple again. So, how does that work?
Cloud Automation Services uses onboarding plans to add existing unmanaged machines to a Cloud Assembly project. Unmanaged machines are those machines that were created before their source cloud accounts were added to your Cloud Assembly project. You can onboard unmanaged machines by selecting them from a list or by using filters that match one or more machine conditions, such as name or IP address. These machines can be grouped in a single deployment or each machine can be onboarded as its own deployment.
First start with a simple onboarding plan. In Cloud Automation Services go to the Infrastructure tab and select Onboarding in the left column. Here we create a new onboarding plan which I named ‘vSphere 2 CAS’.
You select the cloud account you would like to onboard workloads from and you select a project to which the existing workloads will be assigned.
Next we select the workloads we would like to onboard. To do this, go to the Machines tab. Here you will see all the machines that are discovered using the specific cloud account. You can now simply select the machines you want to manage using Cloud Automation Services.
Once you’re done, select Ok and now you have four options to handle how the selected machines will be presented in Cloud Automation Services. You can create a new deployment or add the machine to an existing deployment and you have different options to group or seperate the machines.
You can now run the onboarding plan and because I selected to create a deployment for each machine, I ended up with seven new deployments in Cloud Automation Services.
This is a very easy onboarding process which is a hundred times better than with vRealize Automation. But besides that it’s very easy and basic it’s also static. You can use this process if you don’t have many machines to onboard and your environment is very static.
But what if you want to make this dynamic? You don’t want to spend a lot of time sorting through all machines and you especially don’t want to do this on a daily or weekly basis. Let’s see how to improve this onboarding plan.
To do this, select the existing onboarding plan and remove the machine selection. Then go to the Rules tab
You can create filtering rules to select machines for onboarding based on criteria such as machine name, status, IP address, and tags.
I’ve assigned two tags in my vSphere environment, ‘Managed by CAS‘ and ‘AppID‘. This creates the following scenario:
|Virtual machine||AppID||Managed by CAS|
The onboarding rule selects all the virtual machines which have the ‘Managed by CAS’ set to ‘Yes‘. This way you can easily include the virtual machine in the rule and therefor bring it under management by assigning this tag.
The second tagged called ‘AppID’ is used to group the applications into two separate deployments instead of five. The Finance application will contain two virtual machines (App_A_Web Server, App_A_DB Server). The HR application will contain three virtual machines (App_B_Application Server, App_B_Web Server, App_B_DB Server). To do this, go to the Onboarding rule Summary tab and enter the Deployment tag key. This tag category (in vSphere speak) will be used to determine which virtual machine belong together and will be grouped into one deployment. When you’ve entered the Deployment tag key select Apply.
Now go to the Deployment tab and you will see the two deployments and the virtual machines belonging to each deployment.
Select both deployments, select ‘Blueprint’ and select the option ‘Create blueprint in Cloud Assembly format‘. This will create two new blueprints based on the existing workloads and the application construct you’ve just created using the tags.
The overall result is that you’ve created a dynamic onboarding rule which will detect new workloads tagged in vSphere with the ‘Managed by CAS’ set to ‘Yes‘. Which will be grouped according to the value entered in the ‘AppID’ tag category. The new onboard applications will then show up in Cloud Automation Services under the ‘Deployments tab’. Now you can start managing your workloads through Cloud Automation Services.
This dynamic nature of the onboarding rules is especially useful when IT Admins or Developers want to keep using the element managers like vCenter or the native Azure or AWS console. The auto discovery of new workloads will place them under management of Cloud Automation Services and will enforce the policies assigned to the specific project.
Onboarding existing workloads has never been simpler than this!