WilliamLam.com

vSphere Event-Driven Automation using VMware Event Router on VMware Cloud on AWS with Knative or AWS EventBridge

by // Leave a Comment

The VMware Event Broker Application (VEBA) is a popular VMware Event-Driven Automation solution that can be consumed using either the open source or commercial offering from VMware. The commercial offering of VEBA is already available to customers today via our Tanzu Application Platform (TAP) offering, which I have previously written about here. The open source offering of VEBA can be consumed in either a pre-packaged Virtual Appliance or a native Kubernetes Application called for those with an existing Kubernetes cluster.

Deploying the VEBA Virtual Appliance is well documented (here and here) and I wanted to spend some time covering the native Kubernetes deployment model, as it there are actually a couple of options and most recently, this came up in a customer discussions as they were interested in forwarding vSphere Events from VEBA to AWS EventBridge.

In the open source version of VEBA, there is a component called the VMware Event Router, which is responsible for connecting to an event source such as vCenter Server and then forwarding those events to a processor which can either be a a function that you have written to react to a specific event using Knative or to AWS EventBridge to integrate with other AWS native services like CloudWatch as an example.

To demonstrate the two different ways to deploy the VMware Event Router, I have created the following Github repo https://github.com/lamw/vsphere-event-driven-automation-vmware-event-router that provides an example to easily deploy the VMware Event Router to an existing Kubernetes cluster. For my environment, I will be using VMware Cloud on AWS and the managed Kubernetes offering called Tanzu services, which is included as part of the base offering and there is no additional cost of running the Kubernetes infrastructure, which is certainly an added bonus 😀

[Read more...]

How to configure Knative and containerd in VMware Event Broker Appliance (VEBA) to use a private registry?

by // 1 Comment

I was recently helping out fellow colleague Patrick Kremer who was looking into an issue that one of our users had filed on how to configure the VMware Event Broker Appliance (VEBA) so that it can take advantage of a custom container registry for deploying VEBA functions. If you attempt to specify a container image from a private container registry, especially one that has a self-signed certificate, you will see the following error:

Unable to fetch image "harbor.primp-industries.local/library/veba/kn-py-echo:1.0": failed to resolve image to digest: Get "https://harbor.primp-industries.local/v2/": x509: certificate signed by unknown authority; Get "https://harbor.primp-industries.local:443/v2/": x509: certificate signed by unknown authority

I had assumed that this should have been a pretty trivial configuration change to make the underlying Kubernetes container runtime trust the desired container registry and that there would be an easy to follow tutorial that Patrick could search for. The latest release of VEBA has moved away from using the Docker runtime to containerd and this should have helped narrow down the search results, at least that was our assumption.

Not only are there plenty of resources online, but there seem to be multiple methods depending on the version of Kubernetes and containerd which was pretty overwhelming. After several attempts using various blog articles, Patrick found that the trust error has still not gone away. I finally decided to take a closer look and discovered that there are actually two components that must be updated to properly support a private container registry: containerd & Knative Serving Controller. I eventually found this page in the Knative Serving documentation that provided a hint but ultimately, I was not able to fully grok the details until I came across this Github thread that brought clarity on how to create the required secret for the root CA certificate which would allow the Knative Serving controller to trust the root CA certificate.

Below are the instructions for the required changes and I have also attempted to simplify the steps by providing automation snippets that makes it easy for anyone to consume. In my setup, I am using Harbor registry which was built from my Harbor Virtual Appliance but the steps should apply for any other private container registry.

[Read more...]

Custom webhook function to publish events into VMware Event Broker Appliance (VEBA)

by // Leave a Comment

In my previous article, I demonstrated how you can leverage the upcoming v0.7 release of the VMware Event Broker Appliance (VEBA) to publish and consume custom events to easily extend your event-driven automation to other event sources. As a recap, this is accomplished by constructing and sending a conformant CloudEvent to VEBA, which can then be consumed by your functions.


This is perfect for external event sources that can create a custom HTTP payload that conforms to the CloudEvent specification, however not all solutions have this type of functionality or flexibility. An alternative solution to this is to simply create a VEBA function that can accept a custom payload and then handle the transformation of the data into a valid CloudEvent and then forward that off to broker running within VEBA. This is just one of the many benefits of Knative, the backend for VEBA, where each function deployment includes an endpoint that is automatically served as a subdomain to the VEBA hostname (e.g. https://my-function.NAMESPACE.VEBA-FQDN)


This solution would enable external "Event Producer" to send a non-CloudEvent payload which can then be processed by your function and re-publish as a conformant CloudEvent that can then be consumed by other function and services.

  1. Event Provider would make HTTP request to the function webhook with a custom payload
  2. A conformant CloudEvent payload is constructed by the webhook function
  3. Webhook function will then forward the CloudEvent internally to the VMware Event Broker Appliance
  4. VEBA functions can now react to these custom CloudEvents

[Read more...]