Following on from Part 1 of this blog article, I wanted to explore how to implement the InfoBlox integration into vRealize Automation blueprints.
So, maybe don’t do it that way…! There are two other approaches, and I’ll outline each of them in Part 3 of this series of articles. I’ll also explain below some more details about how the provisioning options work.
But for now, I’ll explain some of the common elements across the integration methods.
A quick word on one other property – “Infoblox.IPAM.vmName”. In my view, this property is a bit redundant when using vRA, as I was already using vRA Dynamic Hostname workflows to determine a special hostname, and didn’t want to populate this separately in a new field. In my case, I went and edited a few of the InfoBlox workflows to just pickup the vRA name.
My snippet of additional code is below, which was inserted into the “Retrieve Properties” workflow scripting elements.
Have a look through the InfoBlox to explore some other use-cases you can try out with the DNS and Network views – as these will apply well to multi-tenanted usage, overlapping network ranges, etc. This is something considerably beefed up in the later vNIOS 7.x version of InfoBlox which I haven’t covered in these articles.
One last word of warning – the “Infoblox.enableDHCP” property is defined automatically when you generate the Build Profiles with the provided workflow. However, this property is never referenced in the later call-outs, and so might give you the wrong impression for this parameter that there is some DHCP-specific IP assignment. There is not – static IP allocation and assignment is the only method implemented, at least in the version of the plug-in I have been reviewing.
That's it for this article on the common elements of integration. Please go ahead and read Part 3 to understand the juicy details of specific integration methods, and how you might actually go about using this for your own environment!
Please let me know any comments or feedback!
First approach
When first learning about how to utilize the IPAM integration, I believe I actually went down the complicated route first (Method 2, in Part 3!). I assumed I would NOT use vRA to manage and assign IP addressing at all, and would delegate this entirely to InfoBlox. In order to do this, I had to disable the vRA Network Profile in the Reservation, whose job it would normally be to create the IP information. This had two implications:- In my environment, not all VM requests were going to be IPAM integrated, so I had to create a NEW Reservation in vRA, overlapping with my existing ones, with the Network Profile disabled. I then had to make duplicate blueprints to be associated with the new reservation. Of course, I could have made the Reservation Policy be dynamically selected during request, but that is just another complication.
- Now that vRA was not supplying the networking parameters to go with the IP address (subnet mask, DNS servers, DNS suffix, etc), I had to supply this is additional vRA Build Profile properties.
So, maybe don’t do it that way…! There are two other approaches, and I’ll outline each of them in Part 3 of this series of articles. I’ll also explain below some more details about how the provisioning options work.
But for now, I’ll explain some of the common elements across the integration methods.
Using the Build Profiles
After creating the initial Build Profile (as per Part 1), I went back into vRA and modified the Build Profile to pre-populate the static attributes that I knew I would use.Common properties
There is one set of common properties that are used no matter which IPAM methodology you use. There are a number of “create-something” attributes, and you need to choose exactly what type of Infoblox record you wish to create.DNS-integrated Host record
If you specify this option, as cannot specify any of the other below types. It is both an InfoBlox record type and a DNS record type.- Infoblox.IPAM.createHostRecord
InfoBlox address record type
You can choose between either of the below options, depending on how you plan to use InfoBlox records. I believe Fixed Address probably fits the use case most people think of for the automation use-case.- Infoblox.IPAM.createFixedAddress
- Infoblox.IPAM.createReservation
DNS address record type
If you are not creating an InfoBlox/DNS host record (above), then you can either specify to create a DNS A record alone, or both the A and PTR records for the entry. Obviously “one or both” means you don’t choose both these options!- Infoblox.IPAM.createAddressRecord
- Infoblox.IPAM.createAddressAndPtrRecords
Additional common properties
There are a list of additional properties created in the Build Profile, most of which I have not used. One property I did statically populate was “Infoblox.IPAM.comment” with a string such as “Record created by vRealize Automation”, so that when managing my addresses directly in InfoBlox I could quickly determine which entries are under automated management.A quick word on one other property – “Infoblox.IPAM.vmName”. In my view, this property is a bit redundant when using vRA, as I was already using vRA Dynamic Hostname workflows to determine a special hostname, and didn’t want to populate this separately in a new field. In my case, I went and edited a few of the InfoBlox workflows to just pickup the vRA name.
My snippet of additional code is below, which was inserted into the “Retrieve Properties” workflow scripting elements.
vmname=vCACVmProperties.get("Infoblox.IPAM.vmName");
if(vmname=="")
{
vmname=vCACVm.virtualMachineName;
}
Property list
- Infoblox.IPAM.vmName
- Infoblox.IPAM.dnsView
- Infoblox.IPAM.networkView
- Infoblox.IPAM.comment
- Infoblox.IPAM.enableDHCP (see comments below)
- Infoblox.IPAM.aliases
- Infoblox.IPAM.defaultPortGroup
Have a look through the InfoBlox to explore some other use-cases you can try out with the DNS and Network views – as these will apply well to multi-tenanted usage, overlapping network ranges, etc. This is something considerably beefed up in the later vNIOS 7.x version of InfoBlox which I haven’t covered in these articles.
One last word of warning – the “Infoblox.enableDHCP” property is defined automatically when you generate the Build Profiles with the provided workflow. However, this property is never referenced in the later call-outs, and so might give you the wrong impression for this parameter that there is some DHCP-specific IP assignment. There is not – static IP allocation and assignment is the only method implemented, at least in the version of the plug-in I have been reviewing.
That's it for this article on the common elements of integration. Please go ahead and read Part 3 to understand the juicy details of specific integration methods, and how you might actually go about using this for your own environment!
Please let me know any comments or feedback!
No comments:
Post a Comment