Cloud Automation: How to Use EfficientIP Terraform DDI Provider

Infrastructure is moving to the cloud, private or public, because of its ability to be elastic, programmable and in some cases cheaper. Multi-cloud today tends to be the standard way of building application bases, and automation and software-defined are the new paradigm for helping businesses in their digital transformation.

In the same way, development teams are using specific development frameworks for their applications to improve quality, efficiency and reusability of the software components, and operations teams are relying on orchestration tools. In this area of Infrastructure as Code (IaC), HashiCorp Terraform plays a key role. Being able to describe the infrastructure with pseudo-code, that is idempotent (i.e. can be applied multiple times with the exact same result), reusable, self-supporting and easy to read is really attractive. Ideally, configurations are shared between DevOps and production teams, while continuous integration and continuous deployment processes are set-up to take advantage of automation and integration with development factory tools.

Using descriptive scripting language infrastructure is also recommended when it comes to multi-cloud deployment and reversibility. Being able to redeploy or scale infrastructure on an alternative cloud provider could well be a major business differentiator.

Modern IP Address Management (IPAM) solutions are key in the automation process. IP and DNS are the foundations of the network infrastructure. They link users to applications, guide data flows between producers and consumers and tie micro-services together. Having the DDI (DNS-DHCP-IPAM) solution fully integrated with the Infrastructure-as-Code process is a smart move, helping bring end-to-end automation and orchestration of the whole IT system. This is what EfficientIP proposes with its “Terraform provider” that offers IP management and DNS automation.

The rich set of APIs available in the SOLIDserver DDI solution allows the connection of multiple tools, including orchestrators. We at EfficientIP have chosen to invest in Python, Ansible and Terraform in order to cater to the rapidly increasing number of users who are embracing the Infrastructure-as-Code model. The SOLIDserver provider version 1.0.10 published in May 2019 covers most Terraform IPAM and DNS features. This version is published as open source and opened to the community for improvements, comments, bug reports, and new ideas.

The Terraform SOLIDserver DDI provider can be used as: 1) The source of IP information prior to building an infrastructure resource like a server, or 2) To update the repository after the creation of any resource. It depends on the way the cloud provider handles IP information – some impose their IP addressing plan, others allow using an external plan.

We aim to make Terraform IP address management easy. Let’s dive into some use case example to see how it works. For the following examples, we are using an IPAM already configured with a dedicated space called blog19 and some networks. The overall configuration is shown below:

Use case 1: Reserve an IP address

We need to reserve an IPv4 address prior to provisioning a resource:

resource "solidserver_ip_address" "SX01I02" {
  space = "blog19"
  subnet = "PAR_DC1"
  name = "SX01I02"
}
output "SX01I02-ip" {
  value = "SX01I02: ${solidserver_ip_address.SX01I02.address}"
}

Here we ask for the creation in the IPAM of a host named

"SX01I02"

in a specific subnet of a space. The IP address will be available for all subsequent actions through the variable

"${solidserver_ip_address.SX01I02.address}"

as a calculated value. For example we could provide this information to VMware for the creation of a specific machine.

In the IPAM we have the host created in its subnet:

Use case 2: Reserve an IP address with a device

We need more information for our host and since we know the nature of the device, we create both objects at the same time:

resource "solidserver_device" "p0015232l" {
  name = "p0015232l"
  class = "SRVDC"
  class_parameters {
    serial = "AHCK42"
    form_factor = "R19-2U"
    model = "DELL-R840"
  }
}

# create an IP address for a future host linked to the existing space
resource "solidserver_ip_address" "SX01K03" {
  space = "${data.solidserver_ip_space.blog19.name}"
  subnet = "PAR_DC1"
  name = "SX01K03"
  mac = "62:b5:3d:ee:8f:56"
  device = "${solidserver_device.p0015232l.name}"
}

A device is created in the device manager and an entry in the IPAM linked to it, each containing different kinds of information. The IP address is available through a computed value.

The IPAM subnet now contains the new host:

And in Device Manager we now have the specific hardware for this host:

Use case 3: Reserve an IP address and set DNS entries for A, PTR and CNAME

Thanks to the DDI features for synchronizing IPAM and DNS information, the creation of an entry in the IP address plan can automatically create DNS records for forward (A) and reverse (PRT). The DNS alias (CNAME) will be created for the resource to become available through this name:

resource "solidserver_ip_address" "SX01M04" {
  space   = "${data.solidserver_ip_space.blog19.name}"
  subnet  = "PAR_DC1"
  name	= "SX01M04.blog19"
  mac 	= "f7:93:a1:76:da:d3"
}

resource "solidserver_dns_rr" "CNAME_WWW" {
  dnsserver	= "smart.ud19"
  name     	= "www.blog19"
  type     	= "CNAME"
  value    	= "${solidserver_ip_address.SX01M04.name}"
}

In addition to the IPAM record for the host, the records in the DNS are also created thanks to the synchronization process of DDI, in this case the A and CNAME:

Use case 4: Inform IPAM about new IP address of a resource provided by cloud provider

Sometimes the IP address of a resource is provided after its creation by the cloud service provider. This requires synchronizing the information in the IPAM in order to keep the IP golden records accurate.

Here we create a server on AWS EC2 and get its IP address after completion. The same could be also done for mac address associated to the network interface of the AWS resource.

resource "aws_instance" "sx01p05" {
  ami                   = "ami-acd005d5"
  instance_type      	= "t3.medium"
  key_name           	= "${aws_key_pair.default.id}"
  subnet_id             = "${aws_subnet.par-vpc01-b.id}"
  vpc_security_group_ids = ["${aws_security_group.default.id}"]
}

resource "solidserver_ip_address" "SX01P05" {
  space   = "${solidserver_ip_space.blog.name}"
  subnet  = "PAR-VPC01-b"
  name	= "sx01p05.blog19"
  request_ip = "${aws_instance.sx01p05.private_ip}"
}

Access to the full repository of the sources displayed in this blog is also available on the official EfficientIP source repository on gitlab.

The above set of examples only covers some basic use cases of the SOLIDserver IP management provider for Terraform, more complex scenarios could be imagined. We at EfficientIP are using this for building specific configurations with the guarantee that the end result will be similar on multiple runs. It could also be used to reproduce specific patterns and certainly in more complex environments where multiple cloud and infrastructure resources need to be built, changed frequently and destroyed after usage.