Vra

Upgrading your vRealize Automation instance has some times been a painful exercise. But this was in the early days after VMware purchased the product from DynamicOps. It’s taken a while, but the upgrade process has improved for each and every version, in my opinion, and 7.5 is no exception. If you’re on a previous version, here is a quick rundown on the upgrade process from 7.4 to 7.5. Note: As always, please read the the official upgrade documentation. It includes prerequisites and steps that should always be followed. https://docs.vmware.com/en/vRealize-Automation/7.5/vrealize-automation-7172732to75upgrading.pdf ...

Preventing blueprint sprawl should be a consideration if you’re building out a new cloud through vRealize Automation. Too many blueprints and your users will be confused by the offerings and the more blueprints, the more maintenance needed to manage them. We’ve had custom methods for managing sprawl up until vRA 7.3 was released. Now we have some slick new methods right out of the box to cut down on the number of blueprints in use. These new out of the box configurations are called Component Profiles. ...

vRealize Code Stream Management Pack for IT DevOps (code named Houdini by VMware) allows us to treat our vRealize Automation Blueprints, or other objects, as pieces of code that can be promoted between environments. In previous posts we’ve done just this, but a glaring piece was missing in during those articles. Promoting code between environments is great, but we’ve got to test it first or this process is only good for moving code around. A full release pipeline including unit tests can make your environment much more useful for organizations trying to ensure consistency. ...

In previous posts we covered how to install, configure and setup vRealize Code Stream Management Pack for IT DevOps (code named Houdini) so that we could get to this point. During this post we’ll take one of our vRA blueprints in the development instance and move it to the production instance. Let’s get started. To set the stage, here is my development instance where I have several blueprints at my disposal. Some of them even work! (That was a joke) For this exercise, I want to move the “Server2016” catalog from my development instance to my production instance because I have it working perfectly with my vSphere environment. ...

In the previous post we covered the architecture and setup of the vRealize Code Stream Management Pack for IT DevOps (also known as Houdini). In this post we’ll cover how we need to setup Houdini’s endpoints so that we can use them to release our blueprints or workflows to other instances. Remote Content Server Endpoint Setup To setup our endpoints we can use nicely packaged blueprints right in vRA. It’s pretty nice that our setup deployed some blueprints for us to use, right in the default tenant of our vRA server. Login to the vRA default tenant with your Houdini Administrator that you setup in part 1. Then go to the catalog and request the “Add Remote Content Endpoint” under the “Administration” service. A remote content server (RCS) is a vRA appliance that will cache your packages. It’s a pretty useful thing to have if you’ve got vRA appliances in different sites and you need to move vSphere VMs or other large objects over a WAN. Future releases can be copied from the remote content server instead of always copying from the source. ...

Deploying blueprints in vRealize Automation is one thing, but with all things as code, we need to be able to move this work from our test instances to development and production instances. It’s pretty important to be sure that the code being moved to a new instance is identical. We don’t want to have a user re-create the blueprints or workflows because it’s prone to user error. Luckily for us, we have a solution. VMware has the vRealize Code Stream Management Pack for IT DevOps which I though about nicknaming vRCSMPITDO but that didn’t really roll off the tongue. VMware previously nicknamed this product “Houdini” so for the purposes of this post, we’ll use that too! This article will kick off a few more posts on using the product but for now we’ll focus on installing it. ...

As of vRealize Automation 7.2, you can now deploy workloads to Microsoft Azure through vRA’s native capabilities. Don’t get too excited here though since the process for adding an endpoint is much different than it is for other endpoints such as vSphere or AWS. The process for Azure in vRA 7 is to leverage objects in vRealize Orchestrator to do the heavy lifting. If you know things like resource mappings and vRO objects, you can do very similar tasks in the tool. ...

If you’re trying to get started with vRealize Automation and don’t know where to get started, you’re in luck. Pluralsight has just released my course on “Getting Started with vRealize Automation 7”, which will give you a great leg up on your new skills. In this course you’ll learn to install the solution, configure the basics, connect it to your vSphere environment and publish your first blueprints. The course will explain why you’d want to go down the path of using vRA 7 in the first place and how to use the solution. ...

vRealize Automation has had a different upgrade process for about every version that I can think of. The upgrade from vRA 7.1 to 7.2 is no exception, but this time you can see that some good things are happening to this process. There are fewer manual steps to do to make sure the upgrade goes smoothly and a script is now used to upgrade the IaaS Components which is a nice change from the older methods. As with any upgrade, you should read all of the instructions in the official documentation before proceeding. ...

One of the new features of vRealize Automation in version 7.1 is the ability to scale out or scale in your servers. This sort of scaling is a horizontal scaling of the number of servers. For instance, if you had deployed a single web server, you can scale out to two, three etc. When you scale in, you can go from four servers to three and so on. Use Cases The use cases here could really vary widely. The easiest to get started with would be some sort of a web / database deployment where the web servers have some static front end web pages and can be deployed over and over again with the same configurations. If we were to place the web servers behind a load balancer (yep, think NSX here for you vSphere junkies) then your web applications can be scaled horizontally based on when you run out of resources. ...