OneFuse IPAM policies have some special qualities that make managing IPAM integrations very easy, flexible, and portable. IPAM policies in OneFuse define the network or networks they represent abstracted from the actual IPAM provider. This offers many benefits over network definitions that are tightly tied to a specific provider. This allows for the use of more than one provider in the environment, it also allows for easy migration from one IPAM provider to another.Continue reading “Creating a OneFuse IPAM Policy”
In this article, I am going to walk you through creating a Naming Policy within OneFuse. Before we begin, I want to go over why OneFuse Naming is a game changer for organizations. Many of you reading this may be thinking you don’t need an integration for naming. Read on, and I’ll explain why you may want to think otherwise.Continue reading “Creating a OneFuse Naming Policy”
In my previous article “Deploying the OneFuse Appliance”, we deployed OneFuse and was able to login to begin the configuration.
In this article, we are going to configure a few useful items within the OneFuse platform that will be used when we begin to configure the modules for specific integrations.Continue reading “Configuring the OneFuse Appliance”
In this article, I’m going to walk you through how simple it is to deploy the OneFuse integration platform. The OneFuse appliance can be deployed and ready to configure in as quick as 5 minutes.Continue reading “Deploying the OneFuse Appliance”
SovLabs has been busy developing a tool that is intended to analyse your vRealize Automation 7 environment and provide helpful feedback on areas where you can optimize. The tool collects data on dozens of vRealize Automation 7 constructs such as number of blueprints, types of blueprints, number of business groups, network profiles, reservations, etc. and looks for key indicators to see if there is room for optimization. It also goes a step further and looks for items that could create challenges when customers are looking to migrate to vRealize Automation 8.
The goal here is to optimize your vRealize Automation 7 environments before adopting vRealize Automation 8. We all acknowledge that vRealize Automation 7 will be around for at least another 18-24 months – if not longer. Even if you are making the move to vRealize Automation 8 today, you will likely still be maintaining your vRealize Automation 7 environments alongside for some time to come. By optimizing your vRealize Automation 7 environments you will be reducing the maintenance overhead required for your current environment while also making it easier to migrate and adopt your solution on vRealize Automation 8. The more aligned the two instances are, the simpler it will be to maintain both environments side by side.
The best part is it’s free, yes that is correct I said free. You simply register at https://www.sovlabs.com/vrealize-automation-optimization-assessment and, once registered, a member of the SovLabs team will reach out to assist you with the data collection. The data is done using a vRO workflow that produces a JSON output. The data that is collected is non-identifying or sensitive so you don’t have to worry. The data collected is also presented in plain text so you can review the data before you send it back to Sovlabs for analysis. If you have more than one vRealize Automation 7 environment you can run the collector for each environment and then zip all the files together for upload.
Once data collection is complete, you then head over to https://optimize.sovlabs.com/ and upload your results file. From there the folks at SovLabs will take the result, run it through their analysis tool and produce a report detailing all the areas where you can optimize your vRealize Automation 7 environment(s). A SovLabs technical representative will reach out to schedule a time to go over the report and send you a copy. Whether you are looking to Optimize your vRealize Automation 7 environment or gain some insight into your pending vRealize Automation 8 migration, the SovLabs Optimization and Upgrade Assessment provides great information and insights to help plan and prepare your automation path.
In Part 1 of this two-part series on the vRealize Automation Migration Assessment Tool, we looked at the vRA8 migration tool to see how it might help you plan your migration from vRA7 to vRA8. In this article, we are going to look at what it will take to migrate your custom workflows from vRA7 to vRA8. To start, we will explore what a custom workflow looks like to day in vRA7.
vRA7 Workflow Components
In vRA7, there are a number of components that come together to make the magic happen. Each component plays a vital role in how you design, build, and invoke your customizations.
The event broker was introduced in vRA7 to make it easier to trigger the workflow stubs that existed within the IaaS server. These stubs were always there, but only a handful were accessible and they were not easy to configure. The Event Broker also introduced a more granular way to decide when a workflow should or should not be executed. Although the event broker has dozens of events you could subscribe to the following were the most commonly used:
- Machine Requested
- Building Machine
- Machine Provisioned
- Machine Activated
- Machine Destroyed
Many of these states included a pre and a post execution allowing you to decide if you wanted to execute your workflow before of after vRA’s execution of that state. These states that are the core of vRA7 extensibility no longer exist in vRA8. vRA8 is a completely new platform, written from the ground up, and no longer includes the IaaS host that controlled all of these states in vRA7.
Welcome to Part 2 of 2 of our “First Impressions” of vRA8 article. In Part 1, we discussed what’s new, good, not so good, and really good about Documentation and Tagging in vRA8. Below, we discuss ABX and policies, which are both very new and very different in vRA8.
Action Based Extensibility (ABX), vRealize Orchestrator and Extensibility
ABX is the new extensibility offering packaged with vRA8 (in addition to vRealize Orchestrator) that uses a FaaS provider (AWS, Azure and On Prem offered today) to provide extensibility for the new platform. As someone who has spent countless hours working with vRO, ABX is probably one of the more intriguing announcements surrounding vRA8.
One of the things that I am impressed with right out of the gate is that the ABX action runs show you the code that was used as well as the payload that was passed for use in the action. In fact, both Orchestrator and ABX runs can be monitored directly from the Cloud Assembly UI. No more having to log in to a separate interface to see what is happening with your extensibility. This methodology makes troubleshooting much more accessible.
Many of us have been eager to get our hands on vRealize Automation 8 (vRA8) for some time now. If any of you are like me, you may have dabbled in the Hands On Labs with vRealize Automation Cloud (formerly CAS) for the past year. But, without having the capability or the requisite login for the service, you kept abreast of any updates coming out of the vRAC camp. I have been through quite a few versions, upgrades, migrations and code changes in my time working with the vRealize products. Most of this experience was spent in architecture, engineering, and development at a large enterprise customer, where we had to carefully navigate each of these changes. This article covers some of my first impressions of vRA8 as an advanced user of the product since the early days, circa vRA6.
There is a lot to cover here. The product has been re-written from the ground up. The Cafe and IaaS nodes that we are all familiar with are now gone. Custom workflows will most likely have to be completely re-written. Migrations will have to be planned and extensive testing required prior to any production deployment. It will likely take the better part of the next year for the community to get a handle on the new product. However, if you’re reading this blog post, you are probably actively engaged in working with vRA in some fashion, and you’re excited to see the new capabilities offered in vRA8.x.
The following is a two-part summary of some of the very high level aspects of the new system that have jumped out at me in the first 2-3 weeks of working with VMware’s reconstructed code for vRealize Automation. In part one, I explain my experience working with the Documentation of vRA8 and Tagging, the new way to manage your machine metadata. Part 2 will cover my take on ABX and Policies. Also, we’re going in depth on these and other topics in our December 10th webinar: Top vRA8 Deployment Considerations. Click here to sign up.
vRealize Automation veterans may still remember the migrations from vRA 5.x to 6.x and 6.x to 7.x. However, for many enterprises utilizing vRealize Automation, the migration from vRA 7.x to vRA 8.x will be your first major vRA migration. In an ideal world these migrations would only take a few clicks of the mouse. Migrating from vRA7.x to vRA8.x is going to be a lot like switching banks. Trying to figure out all the services that have your bank card on file for automatic billing and moving over automatic bill payments is tedious and time consuming. Which payments are monthly, quarterly, annually, and for how much? Wouldn’t it be nice if there were a simple tool to identify and update all the services that you have on auto-pay?
vRealize Automation is a lot like that. Whether it’s frequently deployed common workloads, special purpose blueprints that are used a few times a month, quarterly, or a handful or fewer times a year, or software customizations specific to vRA, you have to identify everything that will require hand-holding when you begin the migration from vRA7 to vRA8. The good news is that, unlike your bank, VMware does offer a migration assessment tool to help you determine if your blueprints are ready to be migrated from vRA7 to vRA8. As of this writing, we have not yet learned if the migration assessment tool will determine if your customizations and workloads are ready for migration.
Integrating Red Hat Ansible Tower with VMware vRealize Automation is a very popular enterprise automation solution. SovLabs has several excellent integrations that can help you accomplish and scale your integration of these two powerful cloud automation tools. This article is the first in a series of four articles covering the integration of Red Hat Ansible Tower with VMware vRealize Automation, based primarily on the content and discussion from our webinar with Red Hat Ansible on May 22.
- Requesting a vRealize Automation deployment from Ansible. How, and why you would want to do it.
- The SovLabs Ansible Tower Module for vRealize Automation with Static Inventory
- The SovLabs Ansible Tower Module for vRealize Automation with Dynamic Inventory
- The SovLabs Ansible Tower Plug-in for vRealize Automation CM Framework
Requesting a vRealize Automation deployment from Ansible
With Ansible Tower quickly growing in popularity, many developers and system administrators want to be able to utilize Ansible Tower to deploy infrastructure. This type of deployment is the subject of many debates within enterprise organizations, especially those with cloud teams trying to develop standards while enforcing policy and governance across organizations.
The good news is that organizations no longer have to choose between solutions. If you want to use Ansible to develop standards while enforcing policy and governance across organizations, now you can. Using the solution below you can request workloads from Ansible facilitated by vRA to enforce the desired standards and governance policies. Let’s take a look at how it works.Continue reading “Request vRealize Automation Blueprints with Ansible Tower”