As a cloud admin, you need a certain toolset to get the job done. Occasionally these tools are not readily available, or updated ones are released and you need to be able to consume them without too much fuss. Running these apps as containers are often a great way to achieve this, and by far the best way of provisioning them is though vRealize Automation.

In this post I will show you how to offer the vRealize CloudClient as a container and provision it from your vRealize Automation catalog.

Getting started

Create a folder on your workstation that has Docker installed. Download the latest version of CloudClient (at the time of writing this is version 4.4.0, and can be downloaded from https://my.vmware.com/web/vmware/details?downloadGroup=CLOUDCLIENT_440&productId=624) and unzip to the newly created folder.

Create a file named Dockerfile and add the following:

# Use CentOS as the base OS
FROM centos:latest

# Author
MAINTAINER virtualhobbit

# Download software requirements
RUN yum install -y which java-1.8.0-openjdk.x86_64

# Create working directory and hidden config directory
RUN mkdir /cloudclient
RUN mkdir /root/.cloudclient

# Add the CloudClient folder to the container and a config file to accept the EULA
ADD VMware_vRealize_CloudClient-4.4.0-5511232/ /cloudclient
ADD cloudclient.config /root/.cloudclient

# Set the working directory
WORKDIR /cloudclient/bin

# Define the entrypoint
CMD ["sh","cloudclient.sh"]

Open a command line, and use the following to build the container:

docker build -t vrealize-cloudclient .

Your container will begin building. When complete, it should look something like this:Now list your images:

docker image ls

This should show something like:Now we need to tag our build using the image number from above (substitute with your repo name):

docker tag d517d07f1880 virtualhobbit/vrealize-cloudclient:latest

As we’ll be saving this to the Docker hub for others to use, we need to login in first (again, substitute accordingly):

docker login --username=virtualhobbit

Enter your Docker Hub password when requested. You can use any repository you wish (it doesn’t have to be Docker Hub), for example VMware Harbor.

Finally, push your container to the repository:

docker push virtualhobbit/vrealize-cloudclient

The container image will have been pushed into the repo. In my it can be found at https://hub.docker.com/r/virtualhobbit/vrealize-cloudclient/.

vRealize Automation Blueprint

The next step is to create a blueprint in vRealize Automation to enable our customers to be able to consume this new container image.

Create a new blueprint, giving it a name and a short description. Drag a new container to the blueprint canvass, and enter the URL of your container image:

Save, publish and entitled the blueprint as necessary. It should then appear in your catalog ready to be consumed.

Once provisioned, you can view the container running in vRealize Automation:

Final thoughts

It’s important to remember that some tools like the vRealize CloudClient and Ruby vSphere Console should only be able to be consumed by authorized admins. One of vRealize Automation’s greatest strengths is the strong governance you can implement to ensure only the appropriate users can receive the blueprints you make available. Policies can be set that require managerial approval before tools such as those above can be provisioned to customers.

To make the user experience as smooth as possible, I didn’t want the consumer to have to accept the EULA when logging into CloudClient. To prevent it from appearing I copied a configuration file into the container root user folder (as seen in the Dockerfile).

Please note: as others have pointed out, accepting the EULA on behalf of users probably violates the terms and conditions. I am in no way suggesting you should do this, merely that you can. I also have no answer for as to why this is possible given that it is against the terms and conditions 😉

When a user connects to vRealize Automation using CloudClient for the first time, they are prompted to accept any untrusted certificates. To stop this from happening, you could also use the Dockerfile to copy in a certificate trust store (cloudclient.secure.trusture) taken from another machine into the same folder.

Happy containerizing!