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.
Year: 2018
Improving the vRA Admin Experience – Reservation Alerts to Slack
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.
Improving the vRA Customer Experience – Send Chef errors to Slack
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.
Installing ElasticStack Beats on vCenter 6.7
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.
VMware vRealize Suite Lifecycle Manager 1.2 – First Impressions
When VMware created the vRealize brand, they grouped together some of their most complex products under one banner. vRealize Automation (vRA) required the deployment and configuration of two components – a virtual appliance and a Windows server. The Windows server had a long list of prerequisites. In terms of operational management, using products like vRA meant ongoing work on scripts, workflows and other artifacts. The logical response to this is to create a non-production instance to protect your production instance. Moving updates to production could be achieved manually or via VMware’s Codestream product, but both approaches left a lot to be desired. vRealize Suite Life Cycle Manager (vRSLCM or just LCM) is a new approach to this set of problems.
Getting LCM Running
LCM comes supplied as a “Virtual Application” where a few configuration options are required to provision it. One of the LCM-specific settings is whether you want to enable the vaguely named “Content Management”. Enabling this will cause the appliance to use 4 processors instead of 2. Once the appliance is deployed and started, the rest of the configuration happens via the web interface.
Blizzard’s IT Architecture and Testing at Blizzcon 2017
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:
Blizzard’s Overarching Architectural Philosophy
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…
Testing and Documentation
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.
Giving people space to be creative
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.