Automation

Terraform with vSphere – Part 1

~ Colin Westwater

This has been cross posted from my own blog vGemba.net. Go check it out!

Introduction

Terraform is one of the new products that let you treat infrastructure as Code. What does Infrastructure as Code actually mean?
According to Wikipedia:

Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.

In the case of Terraform this means using code to *declare* what we want from vSphere, AWS, Azure, OpenStack etc. and then Terraform goes and creates the infrastructure to our declared final state. This is the opposite to Procedural Infrastructure where we have to describe *how* to get our end result. Terraform does the hard work in figuring out how to create the infrastructure we have defined – we don’t have to worry how to actually create it or the sequence of steps to get there.

Importance of Version Control in Cloud Development

~ Brian Gerrard

A few years ago, I was asked to deploy vCAC (as it was known then). Soon after I found myself part of a team dedicated to creating a new Service Catalog for an SDDC based Private Cloud offering. It was a huge learning curve for me and I was soon immersed in a world of Cloud development with decisions to make based on these new VMware Cloud tools. The one thing that I did learn very quickly was the importance of version control. Coming from an infrastructure background, this was alien to me but it soon became one of the most critical things I learnt about successfully developing a Private Cloud and more importantly – maintaining it!

At the heart of our Service Catalog was vRealize Orchestrator and as requirements for automated Catalog items grew, so did the team. This caused a lot of issues, with many developers working simultaneously on the same product and as a result changes to the same Workflows occurred and relevant changes lost. It soon became apparent we where lacking a sensible way to ensure our final packages was bug free and not overwritten unintentionally. Natively in vRO we can export a package containing Workflows, Actions, Configuration Files etc, but this is not in an ideal format to efficiently review or track changes. It was becoming impossible to keep tabs on what was happening.

Continue reading →

Completion Request Details in vRO7.x

~ Brian Gerrard

As some of you will be aware, vRA6 will be end of life support by the end of 2017 and as a result i was tasked with deploying a POC for vRA / vRO 7.3 in order to check if our current vRO code was compatible. I expected to see some challenges as we are heavily reliant on vRO for our Service Catalog, however one specific issue I did not expect caught me out.

As part of our Private Cloud offering, we use vRO to request a catalog item rather than vRA. The overall workflow also contains many post request actions such as deploying agents, resetting default passwords etc. All of these rely on the successful deployment passing us the hostname after the catalog request completes. After setting up the POC and running a test deployment I  noticed that although the request was successful, the overall Workflow was failing. Looking deeper I saw some differences in the completion details of vRA7.

In vRA6, we used to get the following, where “tyler-prefix04” is the hostname of the newly created VM:

Continue reading →