In Part I of this series, we explored how to deploy the VEBA appliance. In Part II, we looked at setting up a Windows workstation with the prereqs for interacting with VEBA. Part III focuses on working with vCenter tags and cloning a repository. The sample function will cause a vCenter tag to be applied to a VM when the VM powers on. At the end of Part III, you should have a vCenter tag defined, the tag’s URN, and a copy of the sample code from Github.

If you don’t want to learn about govmomi, you do not need to learn it for the code sample to work. You can create a tag named anything you like in the vCenter GUI. You can then use the get-tag PowerCLI cmdlet to retrieve the needed tag URN for the function.

In the getting started documentation, the Categories and tags section tells us to set 2 environment variables:

export GOVC_INSECURE=true
export GOVC_URL=’https://vcuser:vcpassword@vcenter.ip’

I set them to match my environment

govc tags.ls will list out all of the tags defined in your vCenter. If you have a brand new lab vCenter, this command will return nothing – but it should also not error out. For my lab, it shows the only tag that I have defined: alert-power-operations

I confirm the command was accurate by looking at the Tags & Custom Attributes area of vCenter

A few things about govc – you can invoke help to list all available operations – this is just one page of results

You can also show help on a specific command.

Note that this help dynamically reads environment variables – my lab’s vCenter is showing up as GOVC_URL in this help output.

The VEBA documentation says to take note of the tag’s URN when you create it with govc. We can use the tags.info command to get the URN of an existing tag without having to create it using govc.

You can retrieve the same information from PowerCLI if you’re more familiar with it – you don’t even need to use govc

Next, we need to clone the sample repository. There will be more on git later in this series, but for now you just need to be able to clone a repository and use a text editor.

I create an empty git folder, right-click inside of the folder and choose Git Bash here. 

The documentation says to run the following commands:

git clone https://github.com/vmware-samples/vcenter-event-broker-appliance
cd vcenter-event-broker-appliance/examples/python/tagging

Git clone creates a copy of the VEBA sample code repository on your local system. Note that I passed a folder argument in the git clone command. By default, git would have created a folder called vcenter-event-broker-appliance and cloned the code inside of it. But I already have 2 copies of the repository for various testing reasons. I pass the clone command a folder argument of vcenter-event-broker-appliance3. Git clones the code for me and I CD to the new directory

The code is now downloaded to my laptop. In Part IV, we will customize the code for my lab environment and deploy the sample function to the VEBA appliance

In Part I of this series, we explored how to deploy the VEBA appliance. In Part II, we look at setting up a Windows workstation with the prereqs for interacting with VEBA. As of the 0.3 release of VEBA, we support 2 different event processors – OpenFaaS is built right into the appliance, and we also support AWS EventBridge as an external processor. The content in this post doesn’t apply if you’re using AWS EventBridge – you set it up, VEBA forwards events to EventBridge, and you write code in native AWS to respond to events.

We begin with the Function Deployment section of the Getting Started Guide shown on the VEBA Fling instructions page. The guide lists 3 prereqs to getting started: git, faas-cli, and govc. Going into this I have no idea what any of that means. I know what git is, meaning I know the definition of source control and that git is one of many choices for source control. But I’ve never used it, and don’t know anything about faas-cli or govc

I start with the git download page. As I go through this, I seem to find myself at a disadvantage trying to do code on Windows – everything seems to be focused around Mac and Linux. But I successfully installed the Windows binary on my laptop.

I leave the defaults here

I know the basics of getting around vi, but spend a lot more time in Notepad++, so I switch to it here.

This seems to be an OK option – I’m not sure what people typically use. Through the sample code deployment I was only calling git from the Git Bash anyway, so I guess it doesn’t make a difference.

I don’t think I have a need to use Windows CAs so I kept OpenSSL.

I leave this default since it was the recommended Windows setting

I don’t like the Windows default console windows, I figured MinTTY couldn’t be any worse – I select it.

I leave all these default.

The next preqeq is faas-cli. I have no idea what this is, so I click on the link and read about it. faas-cli is a command line interface for OpenFaaS – a serverless functions framework for Docker and Kubernetes. OpenFaaS is built into the VEBA appliance – it is how you publish your custom code to run when an event happens.

For Windows, all I did is go to the releases page and download faas-cli.exe.

I decide to create a specific folder for any executables related to this project, so I created a folder and added that folder to my PATH variable. This way I can invoke the executable no matter where I am in the filesystem.

The final prereq is something called govc, part of govmomi. govmomi is a Go library for interacting with the vSphere APIs. govc is a CLI interface to the library. I did not know why govmomi existed when I started documenting my work with VEBA – thanks to Michael Gasch for explaining “govmomi is a library many VMware products and OSS projects use to provide a vSphere API library for the Go programming language.”

I was able to find and download govc_windows_386.exe at the govmomi releases page. I put it in the same folder as faas-cli.exe

We have now installed all of the prereqs for running our first sample function. In Part III, we will set up vCenter tags for the sample function and download the VEBA sample code to our local workstation with git.