One of the really cool projects VMware is working on is a new tool called the “vROPS Management Pack Builder” which is currently in a closed Beta state.
I was privileged to be accepted into the beta program, and have been playing around with it for the past few weeks.
I also have been playing around with Tanzu Application Platform (TAP) a lot over the last few months, and decided to try and build a Management Pack to visualize TAP Workloads via vROPS.
In this post we will show how this can be achieved and also share some photos from my environment on what this looks like.
vROPS Management Pack Builder
The VROPs Management Pack Builder, is an OVA with a web UI that enables you to create management packs for vROPS without writing any code!
You can sign up for the BETA here. Currently VMware is taking feedback from customers to help shape the future of this product.
The only thing you really need to know in order to build a management pack is how to access the data you need via REST API!
Having the ability to create management packs in such an easy and intuitive manner adds amazing capabilities for any vROPS environment. A management pack can not only create net new objects in vROPS, but can also enrich existing objects by adding metrics or properties, as well as create relationships between objects allowing for endless customizations and optimizations for how and what you want to visualize and monitor.
Building a Management Pack
In order to build a Management Pack you first need to deploy the OVA.
Once this is done we can access the Web UI and begin working on our project.
Accessing Kubernetes Objects via REST API
As TAP is a Kubernetes native platform, in which all objects are resources within our Kubernetes cluster, we need to use the Kubernetes API in order to get our data.
While there is not much out there in terms of documentation on how to call the Kubernetes API directly using REST API tools, the process is really easy.
Lets say for example that i want to get all of the instances of an object type called workload across my entire cluster.
The typical way of doing this would be to run a command like this via kubectl:
kubectl get workloads.carto.run –all-namespaces
This command is great and utilizes the Kubernetes REST API in the backend but the question is how to we get the URL and additional details needed to make the request.
In order to do this we can simply run the kubectl command with a verbosity level of 7 and it will be printed to us as part of the output
kubectl get workloads.carto.run –all-namespaces -v 7
As can be seen from the output, to get the workload we simply need to make a GET call to the Kubernetes API server at “/apis/carto.run/v1alpha1/workloads”.
Another important thing we will need is to authenticate against the API. there are many ways to do this but the easiest is to to a Service Account and use its Token which is then utilized in our API calls as a Bearer token.
The last key thing we need when querying the API is filtering. we need to query for resources based on labels in our case, and when using kubectl there is a simple flag “-l / –selector” which gives us the needed functionality.
To figure out what this looks like from a REST API point of view, we can simply run the command with verbosity set to 7 and we will get just like before the call being made.
As can be seen this is a very easy API to use, and we will now see how we build our Management pack using these APIs.
Setting Up The Management Pack Settings
The first thing we must do when building a Management Pack is to setup the source information.
This includes things such as the FQDN or IP of the system we are targeting, TLS settings, Authentication Mechanism, and also Headers which should be used in all API calls.
As can be seen above, we have given the endpoint details of a Kubernetes cluster with TAP installed as well as the port, set TLS certs to not be validated as I am using self signed certs, and configured the Auth type to custom and have set a parameter named Authorization where the value is marked as sensitive. we can see in the third column of the table that in order to use this parameter across our management pack, we simply need to copy the variable usage “${authentication.credentials.authorization}” and paste that wherever it is needed.
As we are using a Bearer token against the Kubernetes API, we know that the Bearer token must be provided via a header as can be seen bellow:
The final step in the initial setup, is to test our settings using the connect method
When we run this command we will hopefully get a green pop up message saying this was successful.
At this stage we are ready to start configuring the Management Pack itself.
What Data Is Neeed
The next step when building a Management Pack is to build out he API calls that will give us the data we need.
In our case, as we are trying to visualize the resources generated by a workload, we will be looking at getting the following resources:
- Workload
- FluxCD Git Repositories
- TBS Images
- TBS Builds
- Source Scans
- Image Scans
- Deliverables
- Pod Intents
- Tekton Task Runs
- Knative Services
- Knative Revisions
While this is only a subset of the resources we may want to show and use, for the purpose of this POC, these were the resources I decided to start with.
Lets see what the configuration looks like for getting the workload objects in my cluster:
This is a very simple API call that doesn’t require any parameters or special headers. All we needed to provide was the URI needed and the HTTP method to use for the call.
We can examine the response this call will return by clicking on the Request button at the bottom, which will give us a clear visualization of the request made and the response we received back:
Now that we have our call to get the main object, what we want to do is get all of the other objects, but in relation with our workload.
Cartographer, the underlying project in TAP which stamps out all of our objects, adds a label to the resources it generates with the workload name that it is related to.
With this knowledge at hand, we can now show an example of how to Chain API calls, which will allow us to use data returned from a previous call in making another call.
Lets take the Git Repository resource as an example:
As we can see, by selecting yes for the API call chaining, we are provided a list of API calls / Requests that are already configured in the system by us. we can select the call we want to chain to this one, and then on the right side, we receive a list of the fields that were returned in a sample API call made. We simply need to select the field we want to utilize in our chained request, and we can also set what the sample value should be for when we test out this API call.
As can be seen, in order to use this variable in the actual API request, we simply need to use the string “${param}” where ever it is needed. this could be in the URL, a header, or in our case, in a query parameter.
This is the same approach we have taken with all our API calls, and as you can see, it is a very simple process to configure.
Once we have configured the different API calls in the system, we now get into the fun part, which is building our vROPS objects, using this data.
Building the relevant objects
Building our objects is actually a very simple process.
We simply go to the objects tab in the UI and click on the “Add New Object” button.
Once we have done that, we are presented with a new card on the screen:
We can now give our object a name by clicking the pencil icon at the top, and then we can select from the list, which configured API call, we want to use to populate the fields of our object.
Lets take for example the Image resource.
As you can see, once we select the API call, a list of the available fields in the response, are provided to us. We simply can select which fields we want added to our new object.
The next step is to review the metrics and properties, and to set different things such as whether it is a property or a metric, if the field is a KPI or not, What the Label should be, and if the returned field is numeric, we can select the unit type of this field.
Now that we have done this, the last step is select which field should be used as the objects name, which field should be used as the ID for the object, as well as any other identifier fields that may be included within the payload. We can also select at this point, which icon from the preset of icons, should be used for this object type.
As you can see, this is a very easy and simple task. While it can be time consuming, the complexity is as low as it could be and is pretty intuitive to use.
Now that we have our objects defined, the final step is to configure the relationships between the different objects.
Building out the relationships
In vROPS, the relationship mechanism is a Parent Child relationship. this means we can for example configure that our Knative Service is the parent of a Knative Revision.
One very important thing though is that we must tell the system how to find the relationship between these objects.
The way this can be done currently, is by selecting a field from the parent and the child resources that must have the same value. if both have the same value, the relationship is made.
For example, when defining the relationship between an Image resource and a Build resource, we can configure it as follows:
we simply say, that the field “name” on the Image object must be equal to the field “image_name” on the build resource in order to build the relationship.
In this specific management pack, i have not connected these object with native vROPS objects, however you can also build out relationships with Objects outside of your management pack, which is a very interesting topic for another blog post.
Now that we have defined all of our objects and relationships, we can validate and generate our management pack!
Generating the Management Pack
Before generating the Management pack, I like to set a few additional small configurations in the configuration tab.
As can be seen, in this tab, we can configure the Name, Author, Version and Description for our management pack, as well as additional properties like the default port, timeout settings etc.
Now lets go back to our management pack and generate it.
To do this, we click on the preview button at the top right of the screen, which will bring up a new popup interface:
Here we must click Validate. this will validate that we don’t have any configuration issues that would prevent our management pack from being compiled.
As we can see, 2 buttons were unlocked when the validation finished successfully.
The perform collection option can run a sample data collection for our management pack and return to us the objects that would be generated, their properties and the relationships.
Once we are happy with the data collection preview, we can simply click on the build button and wait a few seconds.
Once this message is returned, we can simply click on the link “Go to build” and we will be presented with the list of Management Pack build we have done in the system.
In order to download a build, simple click on the name in the second column and the download of the generated .pak file will begin!
Now lets see what this looks like from an installation and usage perspective.
Configuring the Management Pack in vROPS
As with all management packs the process is very simple:
Step 1 – Install the Management Pack
Go to the Integrations page under Data sources, and go to the repository tab
Next click on “Add” and select the .pak file we just downloaded:
Select the first checkbox as shown in the picture above and click upload.
Once uploaded, click next and a popup will show up for us to confirm that we want to install the management pack as it is unsigned.
We can select yes and then on the next page we must accept the EULA:
Finally, click next and wait for the installation to complete which can take a few minutes.
Now that the Management Pack is installed, we can add Adapter instances.
Step 2 – Adding a TAP cluster to vROPS
On the same page as before change to the Accounts tab and click on Add Account.
Next click on the “Tanzu Application Platform” icon:
In the form we are presented with, Give a name for the Adapter instance, and the FQDN or IP of your cluster
We then need to add a new Credential object for our cluster with a Bearer token that has credentials for all TAP resources accessed in the Management pack.
I have create a small BASH script that is pasted bellow for a way to do this. While I am using the cluster-admin role for simplicity, you can also change it to be more restrictive which is probably a good idea in real production environments.
kubectl create sa vrops-tap-mp-user
echo “Bearer `kubectl get secret $(kubectl get sa vrops-tap-mp-user -o json | jq -r .secrets[0].name) -o json | jq -r .data.token | base64 -d`”
The example output would be something like:
Now that we have our Authentication header, we can create the credential object by clicking on the + symbol:
We can give any name we want to the credential object and simply paste the entire out string starting with “Bearer” into the Authorization field:
Click OK and then click on the advanced setting option.
Make sure the Port and SSL Configuration settings are correct for your cluster and then click on the Validate Connection button to make sure that authentication works as expected.
Once we see that the test connection worked we can save the Adapter instance and go get a cup of coffee while the initial Data Collection takes place which can take about 10 minutes.
Now that we have our adapter instance configured the next step is to create a dashboard to visualize our TAP workloads.
Creating An Example Dashboard
All management packs generated by the Management Pack Builder have a sample dashboard which simply shows us what was collected basically.
While this is nice to have, I went ahead and built a custom dashboard to give a more TAP centric approach to the visualization.
Summary
As you can hopefully see, The vROPS Management Pack Builder is an amazing tool that has huge potential to really make vROPS an even better tool and a truly unique tool in its domain.
The other thing that become very evident I believe through this exploration is the huge benefit it gives us that TAP is completely based on the Kubernetes API. having such a simple and unified API mechanism is critical when we want to integrate it with external systems such as vROPS and i can say that while i have made a few Management Packs using the Builder in the past few weeks, any time that it is a Kubernetes API based solution, the experience is just so much more streamlined.
Hopefully after a bit more polishing and addition of a few more resources, I will share out the management pack file for people to test out and play with as well as any Dashboards i may end up building around the Management Pack as well.