Version 7.2 of vRealize Automation introduced containers to the vRA solution. This post is designed to get you up and running with some basic containers and give you the tools needed to deploy some of your own containers in your environment.

The steps involved in this post assume that you have the “Container Administrator” and “Container Architect” roles. These are administrative roles that you’d need to get things started in your vRA instance.

Host Setup

Before you can deploy any containers, you’ll need to deploy some container hosts. To make things simple, I’ve downloaded the swarm blueprint from Ryan Kelly‘s blog vmtocloud.com and imported the blueprint into my vRA instance through the cloud client. You can deploy one of your existing blueprints, but I love Ryan’s blueprint for deploying swarm and docker through the blueprint designer so why re-create the wheel. However you want do deploy your container hosts through vRA is fine.

The thing to note here is that vRA will automatically detect container hosts and add them to the inventory if one of the built in-property groups is used with the blueprint. The screenshot below shows the default property groups that came with vRA 7.2 and you’ll notice a third property group that I’m using which is a copy of the “Container host properties with user/password authentiation”. I like to copy the build in stuff before I make any modifications to them.

You can see that I modified Ryan’s blueprint to add both my new container property group as well as one to pass some info over to vRO for DNS purposes. That one is not necessary for containers, but nice if you’ve got any event subscriptions that run during deployment like I do. (Adding to DNS is particularly useful). Also note, that I’ve only added the property group to the “Swarm Node” machines and not the manager, even though you could add it as a container host as well.

Here are the changes to the Containers property group that I made from the default settings. The connection port is 2375 and the scheme is http. The default property group assumes you’re doing things property and using an encrypted https connection over port 2376. Yeah, I cheated, but this is why I made a copy of the default property groups and modified them.

Publish your blueprint and entitle it for your users to request from the service catalog. When you’re done, request the catalog item and wait for it to provision.

Once your catalog item has been requested, you can take a look in the “Containers” tab and you’ll see your container hosts listed there. I’ve deployed three in this example.

Placements

Placements are used in much the same way a reservation is used with deploying virtual machines through vRA. Placements carve up the resources on a container and set limits on how many resources can be used. For instance, you might only allow 5 GB of memory to be used out of a container host that has 6 GB of memory. This would leave you memory for the host operating system to use.

Placements have a priority which is used to determine which placement might take precedence and a placement is also tied to a business group, just like a reservation is on the IaaS side of vRA.

These placements are then placed into a placement zone which is simply a grouping of hosts. So you might have three different placements part of the same zone. When a user goes to deploy a container, the priority, zone and business group will determine which hosts the container may run on. The diagram below shows how you can split up placements across multiple placement zones to manage which hosts are available for the business group.

Under the “Placements” menu in the “Containers” tab, click the plus sign to add a new placement. Give it a name, and either select the default placement zone or create your own. Then set a priority (lower number means higher priority) and assign the business group. If you’d like, you may assign it some limits, or by default, the entire container host is available to be used.

You can further restrict your placements by using a deployment policy. If you’re saavy with VM deployment already, think of a deployment policy like a reservation policy. When a deployment policy is tied to a placement and a template, it will ensure it runs on that hosts you specify in the placement zone.

Templates

Now that you’ve got the container hosts and placement zones all figured out we can use one of the default templates to deploy as a test. I selected the hello-world-nginx template. Find your container template and click provision.

After you click the “Provision” button on the template you want to deploy, a new box will appear for you to select the business group that’s requesting it. In my case I only belong to a single business group so I’ve got one option. Click the “Provision” button again to start the process.

Once the provisioning starts, don’t blink or you’ll miss it. The right hand side of the screen will show you your provisioning status.

After the provisioning has completed, you can look at the containers tab under resources to see what containers are running.

If you click on the container you’ll get additional information such as the ports, address and any logs from the container host.

If you then go to the web address of the container, you’ll see that my container is running, although only a simple hello-world container running nginx.

Summary

I’m not sure that container purists or developers will be in love with the containers options in vRA. I think most of them would prefer to use the command line, but for an operations team this might be a nice feature. You can add your own templates as well if you have a docker-compose file so this does give you some nifty options. Take a peek when you have time and try it out for yourself.