Content, vRealize Operations, vRealize Suite Lifecycle Manager, vROps, vRSLCM

vRealize Operations Content Management – CD Pipeline – Part 1

vRealize Operations provide a wide range of content OOB. It gives the Ops teams a variety of dashboards, view, alerts etc. to run and manage their environments.

Sooner or later, in most cases rather sooner than later, vROps users will create their own content. It might be completely new dashboards or maybe just adjusted alert definitions.

Whatever content you create in vRealize Operations, you should treat it like every other software development project.

Ideally you have a development, test and production vROps instances. If this footprint is just too big for your environment, you should at least have a single node test/dev for content development and testing before you import that content into your production instance.

Managing content in vROps, exporting dashboards, views, alert definitions etc. and importing the corresponding files into another vROps instance may be very cumbersome and error prone.

This is where vRealize Suite Lifecycle Manager comes into play.

vRSLCM offers all features to make the management of vRealize Operations (and vRA/vRO/vCenter) content an easy task.

In this post I will describe the basics of vROps content management using vRealize Suite Lifecycle Manager and GitLab.

Logical Design

The procedure described in this post is based on the following logical design of the vROps environment including vRSLCM and GitLab.

Figure 1: Logical design

vRSLCM Configuration Overview

In this post I am not going to describe how to configure vRealize Suite Lifecycle Manager, how to add content endpoints is described in detail here:

https://docs.vmware.com/en/VMware-vRealize-Suite-Lifecycle-Manager/8.0.1/com.vmware.vrsuite.lcm.8.0.1.doc/GUID-44C44ECA-6893-4F0D-BE00-54B0817DF5EE.html

For the walkthrough presented in this post I have configured following content endpoints in my vRSLCM.

Figure 2: vRSLCM content endpoints

I have a vRSLCM-deployed vROps instance, serving as my Dev/Test and a vROps-P1 which is the production instance.

Important configuration detail here is, that the production vROps, vROps-P1, is set to accept source controlled content only. If you have only one vROps checking in content into vRSLCM repository you probably won’t set that option. If you do, you will need a source control endpoint, like GitLab. I have set that option to showcase the usage of GitLab and how changes to the content source in GitLab itself can be handled.

Walkthrough – Overview

The steps in my walkthrough are:

  1. Have a content in Dev/Test vROps you would like to deploy to Prod vROps.
  2. Capture content from Dev/Test into vRSLCM repo and GitLab (including Git merge).
  3. Try to deploy content to Prod vROps from vRSLCM repo directly.
  4. Capture and deploy content from GitLab to Prod vROps.
  5. Modify content in GitLab.
  6. Re-capture from GitLab and deploy to all vROps endpoints.

Step 1 – vROps Content

For the demo I am using a simple dashboard as shown in the following picture.

Figure 3: vROps dashboard – first version

The goal is to deploy this dashboard into the production vROps environment.

Step 2 – Capture Content

We start the capture process using the “Add Content” feature.

Figure 4: “Add Content” vRSLCM feature

Obviously we select vRealize Operations as the content endpoint type.

Figure 5: Content capture – endpoint type

As we want to capture the content into the internal vRSLCM repository and into the source controlled repo – GitLab in one step, we are selecting both respective options.

Figure 6: Capture and check in

We select the source endpoint and the dashboard itself. I have also set the option to import all dependencies. In this case there are no dependencies like for e.g. views used as widgets, in other scenarios, vRSLCM will resolve the dependencies and import all needed content parts. I have also selected the “mark content as production ready” option to allow that content to be deployed to my production vROps.

Figure 7: Content capture settings

As we are checking in the content into GitLab, we need to specify the endpoint, repo and branch.

Figure 8: Checking in content into GitLab

After few seconds the content pipelines complete.

Figure 9: Content pipelines

Now we see the merge request in GitLab and after merging the request, the dashboard is available in GitLab repo and treated as any other code.

Figure 10: GitLab merge request
Figure 11: Dashboard as code in GitLab

Step 3 – Deploy Content – First Attempt

At this point we have our dashboard as content in vRSLCM repo and in GitLab.

Figure 12: Content in vRSLCM repo

If we now open the tkopton-Dashjboard-01 we will see the details of the first version and the option to deploy the content to another vROps endpoints.

Figure 13: Content details and deployment – first attempt

In the next picture we can see that our vROps-P1 is not listed as an available endpoint. This is because I have configured that endpoint to accept source controlled content only. This version is not source controlled, it has been captured from Dev/Test vROps into vRSLCM repo, not from the GitLab.

That means, we need to capture the content from GitLab first to be able to deploy it into the production vROps.

Step 4 – Capture from GitLab and Deploy Content – Second Attempt

We start another capture and deploy (in one step) process and this time we select our GitLab as the source.

Figure 14: Capture and deploy content from GitLab
Figure 15: Capture and deploy in one step

We use the same settings as during the first attempt, the capture endpoint is different.

Figure 16: GitLab as capture endpoint

As we are doing capture and deploy in one step, we need to specify the deployment target and options.

Figure 17: Deployment target settings

And now we can see in the Figure 17 that our production vROps-P1 is available in the list of destination endpoints.

Now the same dashboard is available in the production vROps and in vRSLCM repo we see the second version of the dashboard wich is source controlled.

Figure 18: Source controlled content

Step 5 – Edit Content in GitLab

Let us change the name of one of our widgets. And let us do it in GitLab instead of editing the dashboard in vROps. The dashboard is just another source code from the content repository perspective.

Figure 19: Editing the content source in GitLab

Step 6 – Re-Capture and Re-Deploy Content

After re-capturing the content from GitLab following the same procedure as in step 4 but this time without deploying the content, we see another version in the vRSLCM repo.

Figure 20: GitLab updated version of the dashboard in vRSLCM

After deploying the updated content to our vROps endpoints, we see the dashboard having a new caption for the first widget.

Figure 21: Updated dashboard in vROps

Conclusion

With vRealize Suite Lifecycle Manager and GitLab you have a perfect foundation to create your own CD pipeline for vRealize Operations content.

In the next part I will describe how to extend the pipelines with custom workflows provided by e.g. vRealize Orchestrator.

Stay safe.

Thomas – https://twitter.com/ThomasKopton

Leave a Reply

Your email address will not be published.