In this article we are going to add OneFuse DNS support to a vRA8 blueprint. If you have been following my previous articles you probably have an idea of how this is going to work. We are going to build upon the examples from previous articles by leveraging the same blueprint that we created in the article “vRA8 with OneFuse: IPAM integration”.
By the end of this article, we will have a blueprint that leverages OneFuse to generate a name, assign Network/IP Address as well as create DNS records for the deployed machine. Although these examples are simple and static, they are setting the foundation for future articles where we will dive into creating more flexible and dynamic blueprints. Continue reading “vRA8 with OneFuse: DNS Integration”
Automating the creation of DNS records is becoming increasingly more important in the enterprise. One bad record or typo can cause outages or mission critical services. In this article, I’m going to walk through creating a DNS Policy in OneFuse using Infoblox as a DNS provider. Continue reading “Creating a OneFuse DNS Policy”
If you have read some of my other articles you have heard me mention the OneFuse Terraform provider, but only that it has one. Well in this article we are going to dive right in and take a first hand look at how awesome it really is.
For those of you that know me, you probably know I’m a long time die hard vRA fanboy going all the way back to before it was vRA in the DynamicOps days. Well I’m still a bit of a vRA fanboy, but I’m really in love with Terraform. Not just Terraform, but Terraform with OneFuse. Continue reading “Terraform with OneFuse: Better Together”
In Part 1 of this series we walked through how you can use the SovLabs Property Toolkit and Template Engine to configure vRealize Automation (vRA) for our environment input. In this second part of the series, we’re going to walk through setting up the Application and Compliance inputs for our particular use case. If you are starting to see smoke, don’t be alarmed. It’s just our Genie being let out of the lamp.
In Part 1, we determined that the required options for our Application input will be:
Determine the Outcome
In this scenario, the selection of the application will have a significant impact on the outcome. However, while we need to think about the application, we also need to look at the larger picture. What do I mean by “the bigger picture”? Well, once we figure out the desired outcome for each of these items, we need to think about how each item relates to the environment and the choices we made in Part 1.
What if the requester chooses WordPress as the application and Production as the environment? Alternatively, what if they choose Microsoft SQL and Development? Will the outcome of the application differ based on the environment to which it is being deployed?
Some things to consider:
- Do the workload specs change based on the environment selection?
- Do development, test, and production instances have the same CPU and Memory requirements?
- Do any of the integrations change based on application and environment?
- Do WordPress and Microsoft SQL have the same backup requirements?
- Does this requirement change based on which environment the workload is being deployed to?
- What else could affect the outcome?
To read the entire article please see the original article on the SovLabs Blog.