vRA8 with OneFuse: DNS Integration

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.

Prerequisites

• The OneFuse appliance should be deployed and configured, see the following articles if you need to walk through the OneFuse deployment and configuration.
  • Deploying the OneFuse Appliance
  • Configuring the OneFuse Appliance
  • Creating a OneFuse DNS Policy
• The OneFuse Workflow package needs to be installed and configured within vRA8.  The following article can walk you through is you have not completed this yet.
  • Installing the OneFuse Workflow Package into vRA8
• vRA installed and a working vSphere Blueprint

While not required to follow along I will be starting off using a blueprint I had previously created in my article: vRA8 with OneFuse: IPAM Integration.  If you want to follow along from where we left off in that article you will want to read the below articles before continuing.

• Creating a OneFuse Naming Policy
• vRA8 with OneFuse: Custom Naming
• vRA8 with OneFuse: IPAM integration

Adding DNS to a vRA8 Blueprint

I am going to use the blueprint that I walked through creating in the previous article vRA8 IPAM Integration with OneFuse.  In my previous article I cloned a blueprint that was previously used for my naming article.  In this example I’m not going to clone the blueprint but utilize the version control that exists within vRA8.

To begin you will need to open the blueprint for editing so we can add the appropriate items for consuming our DNS policy that we created.  If you have not yet created your IPAM Policy, you can learn how by reading: Creating a OneFuse DNS Policy.

Before we go ahead and add the needed configuration to our blueprint, we are going to create a version so we can make a record of its current state.  To do this we need to open the blueprint and select “version” from the lower menu.

Once the version dialog opens give it a description and optionally change log information and select “Create”.

Now that we have a tracked version of the current state we can go ahead and add the properties needed to integrate DNS into our blueprint.

1. We need to add the following property to our blueprint:
   • OneFuse_DnsPolicy_Nic0 
     • The property supports 10 NICs. 
     • You can set the NIC by changing the number at the end from 0-9.
2. Next, we need to set the value for the property.  The value is broken up into 3 parts separated by a colon as outlined below.
   • OneFuse_Endpoint:Policy_Name:DNS_Suffix
   • For my environment this will be onefuseblog:default:{{dns_suffix}}  This will result in the following being added to the blueprint:
     • OneFuse_DnsPolicy_Nic0: ‘onefuseblog:default:{{dns_suffix}}’
   • 
   • You will notice the {{dns_suffix}} is getting it’s value from a property that already exists and has been used in the previous examples for naming and IPAM. 
     • It’s important to note that this is not vA8 Blueprint expression syntax, but it is OneFuse Jinja 2 template syntax. 
     • It’s also important to note that you can use blueprint expression syntax or a combination of both blueprint expression and Jinja 2 template syntax with OneFuse properties.  There are reasons you may choose to utilize one over the other, however that is a conversation for another article.
   • For the purposes of this article, it is convenient to use the same property that has provided the DNS suffix to the Naming and IPAM modules, however you may not always want to do this.  You also may want to ensure you are using the exact suffix that was leveraged for IPAM and you can.  You can specify to use the DNS Suffix from the IPAM configuration by using the following value:
   • {{OneFuse_Ipam_Nic0.dnsSuffix}}
   • This tells OneFuse to use the DNS Suffix associated with the assigned Nic0 value.
3. Below is the blueprint yaml for this example:

   formatVersion: 1
    inputs: {}
    resources:
      Cloud_vSphere_Machine_1:
        type: Cloud.vSphere.Machine
        properties:
          #vRA Properties
          imageRef: Centos7
          cpuCount: 1
          totalMemoryMB: 1024
          #OneFuse Module Properties
          OneFuse_NamingPolicy: 'onefuseblog:default'
          OneFuse_IpamPolicy_Nic0: 'onefuseblog:default'
          OneFuse_DnsPolicy_Nic0: 'onefuseblog:default:{{dns_suffix}}'
          #Additional Properties used to generate name
          nameGroup: pp
          nameLocation: atl
          nameEnv: prod
          nameOS: l
          nameApp: web
          dns_suffix: infoblox851.sovlabs.net

4. Once the blueprint is completed, we will do a deploy to test that our DNS integration is working as expected.  Select “Deploy” in the lower left corner.
   • 
5. When the deployment dialog opens give your deployment a name and select “Deploy”
   • 
6. Within a few minutes of starting the deployment a name will have been generated, an IP address will have been reserved, and DNS records will have been created.  To view the name, IP reservation, and DNS records you can login to the OneFuse UI and view the managed objects.  You will also be able to see this information within vRA as well. 
   • To view the managed objects within OneFuse login to the OneFuse UI navigate to the module and view the Managed object for that module. 
   • In this example, we will have a Naming object, an IPAM object, and a DNS object.
   • 
   • On the DNS Object record you can expand details to view the created DNS records.
7. Within vRA8 you can view the details of your deployment and view the name and IP Address.  If you expand Network you will see the network the workload was assigned to and other details.  You can view the entire output from these as well as DNS under properties.
   • 
   • Below is a sample of the information stored with the output:

     {"_links":{"self":{"href":"/api/v3/onefuse/dnsReservations/1/","title":"ppatlprodlweb009"},"workspace":{"href":"/api/v3/onefuse/workspaces/2/","title":"Default"},"policy":{"href":"/api/v3/onefuse/dnsPolicies/1/","title":"default"},"jobMetadata":{"href":"/api/v3/onefuse/jobMetadata/33/","title":"Job Metadata Record id 33"}},"name":"ppatlprodlweb009","id":1,"records":[{"type":"host","name":"ppatlprodlweb009.infoblox851.sovlabs.net","value":"10.30.29.231"}],"trackingId":"9537794d-55e9-41ca-95ee-03aacdb2f9d5","endpoint":"onefuseblog"}

We have now successfully added and tested DNS within vRA8.  While this is a basic example of consuming a static DNS Policy, it is possible to drive the DNS integration more flexibly without having to know which specific DNS technology/vendor is being used – policy abstraction at it’s best!  In future articles I will discuss not only how to drive the OneFuse module dynamically, but vRA8 as well.

Want to try out OneFuse with vRA for yourself? Check out the WWT Hands on Lab Accelerating vRealize Automation 8.x with OneFuse.