VMware released an update for vRealize Automation (vRA) at the start of this month. This was a slight increment from 7.5 to 7.6. At a high level, two key areas of change are NSX integration and the vRealize Orchestrator (vRO) user experience. The Release Notes goes into a bit more detail and I’ll be using those more detailed items as a guide for the content in this post. I will be skipping over the new NSX pieces as I don’t have those available to me.
Following the installation of a replacement UPS I made a horrible discovery – there was problems with my vRealize Automation setup. The first sign of what was to come was when I reviewed the console of the vRealize Automation (vRA) Virtual Applications.
Anyone who has had to setup vRealize Automation would probably know the sinking feeling I started feeling. Having to setup vRA again from scratch was not something I really wanted to do….
F5 Load Balancers (LB) have been a common feature across a number of environments I’ve worked at. While administration of these devices is generally performed via the web interface, F5s also have a REST API that allows the same management tasks to be performed. This opens the possibility of using VMware’s vRealize Orchestrator (vRO) to manage F5 Load Balancers via the same REST API.
Packer is a tool that many IT Infrastructure professions would be familiar with. Packer allows the creation of “machine images” (or base templates) in a way that’s consistent and highly repeatable. The result is machine images that can be used on a variety of platforms such as cloud providers like AWS or Azure or on-prem infrastructure like VMware, all configured to your organisation’s needs.
Nutanix has its own Virtual Machine format called AHV, which runs on Nutanix’s hypervisor Acropolis. Since this hypervisor is based off the KVM hypervisor, and Packer has support for KVM, Packer can be used to build templates for a Nutanix target platform. This post will detail the process I went through to create a Windows 2016 template for Nutanix.
PowerShell Hosts are one of the types of endpoint available in vRealize Orchestrator’s Inventory. By having a PowerShell Host, you can leverage the breadth of PowerShell functionality from within your vRealize Orchestrator workflows. In this article, I’ll run through adding a PowerShell Host as well as some considerations from a technical and security point of view.
Adding A PowerShell Host vRealize Orchestrator has a built-in Workflow for adding a Host under Library > PowerShell > Configuration. Run the “Add a PowerShell host” Workflow to start it. The opening interface is below:
vRealize Orchestrator (vRO) has a lot of plugins that allow it to integrate with other systems and services. One of such plugin is for Active Directory. This plugin allows you to perform a number of standard AD activities, like creating users. vRO already has built in workflows to create and manipulate users. In this post, I’m going to run through what you might end up implementing if you wanted to be able to create Service Accounts via vRO.
The Reservation system in vRealize Automation (vRA) provides a bucket of resources to a team or business unit via Business Group. A risk with Reservations comes about with how I think VMware intended them to be used vs how some organisations may use them. I suspect VMware’s intention was that Reservations should be self-managed by the Business Group associated with it. This makes sense if each individual team has a Business Group as the scope of what’s in the Reservation is “their stuff”. It would mean if a Reservation reached capacity, it would be up to that team to manage the situation.
What if the Business Group was being used differently, where it covers multiple teams? In the event of the Reservation becoming full, the scope is larger than one team. In this situation, it might be good to get a heads up on when Reservations are running low on resources. Email alerts can be setup and yes, sent through to Slack, the formatting in Slack is less than desirable. So I decided to look at a way of doing it better.
One of the issues that can be amplified by automation is logging. Some logs have an ephemeral nature, having a short lifespan due to various factors. This can be especially painful if the logs relate to failures and contain information that could assist in fixing the problem.
This was the issue I was seeing when vRealize Automation (vRA) requests would fail when Chef attempted to apply settings. If Chef failed critically, vRA would be made aware of it and fail the entire request. Of course, vRA would then delete the virtual machine and the local Chef logs. In many cases, there was a gap of only a minute or two between the Chef failure and the vRA cleanup tasks.
I recently deployed a vCenter appliance to 6.7 after a power outage corrupted the 6.5 instance. A followup task for the virtual appliance was getting the ElasticStack Beats (MetricBeat, Filebeat) installed again. In this post, I will go through the process of installing the Beats and some of the minor issues I ran into.
Last November I was able to attend Blizzcon in Anaheim. Blizzcon is the annual convention hosted by Blizzard Entertainment (creators of Overwatch, Diablo, Starcraft, World of Warcraft, etc). In the past the focus has been solely on the games and the game developers. In the last 2-3 years there have been more panels that give more of a look “behind the curtain”. These panels have more information about design processes and engineering practices at Blizzard. There were 2 panels I went to which highlighted this – one was engineering and the other was about level design. Some points that jumped out were:
During the Q&A for the engineering panel, the engineers were asked about whether there was any sort of mandated technologies that have to be used across the business or in particular areas. The response? They used whatever technology or tools that made sense for that area of the business and its needs. The team that handles the websites end up using technologies that make sense in that area. This led into a discussion about the Blizzard’s use of APIs as the means to allow these different technology islands to talk to each other. This approach allows the best tools for the job in an area, but creates a reliance on ensuring any API changes to don’t have downstream effects. Which leads into the next topic…
There was an interesting reference to how Blizzard deal with keeping documentation up to date. With their reliance on APIs, there would most likely be a process where changes have to be tested. Part of their test model involves taking sample data and assets from documentation and run tests with it. If the documentation’s samples haven’t been updated reflect changes in functionality, the test should fail and be flagged. This approach isn’t completely foolproof, but it was an interesting approach to the issue of documentation in IT.
The level design panel blew away one major assumption I had about Blizzard’s level design process for World of Warcraft. My assumption was that the game designers would detail the game world to a fine degree. The level design people would build that without much scope for changing things. The reality was that the game designers would only outline what a particular zone or area would need (mostly in terms of quest flow or general look and feel). It was the level designers who would flesh out the world. Many of those pieces of “character” or “flavour” in the game world were due to the level designers filling those gaps with their own stories.
I’m hoping in the future, they’ll keep doing these sort of panels. One with a bit more focus on the infrastructure side of things would be cool to see.