I have written over a dozen posts on Terraform in the past few years and I always find it interesting to hear more use cases for it. A new one I discovered since I joined HashiCorp is a really nice integration with another HashiCorp tool (Consul): Consul-Terraform-Sync.
What’s cool about it is that it complements really well what Terraform can… or rather cannot do.
You see, while Terraform gives you lots of benefits, there’s actually often a fair bit of human interactions required.
The most common example I have seen in around networking and security.
Take a firewall rule. It’s got source IPs and destinations IPs and ports, right? Adding or removing IPs to a security rule should be something that takes minutes, not days. While Terraform by itself will push a config in seconds, you usually need somebody to create the Terraform configuration, somebody to approve that change and somebody to run Terraform.
Take a load-balancer pool. If an app developer needs to scale and adds more servers to a pool, he/she shouldn’t have to go through multiple hoops and tickets to get that change through.
When I was a network engineer – and admittedly, things have changed since it was strictly my role – we would get a spreadsheet from an application team about the app flows and ports that we would need to open up on a firewall. Essentially, the service was registered in an Excel file and we had to manually provision this change on the network devices – after going through the standard painful change management process.
When the app needed updating or scaling up, we would get another request by email (note that the original Excel file would never be updated) and we would have to manually add servers to the server pool or to the firewall rules.
The premise of Consul-Terraform-Sync is that, once users register their services in a service register (Consul), it would automatically trigger the execution of Terraform to deploy these services. And every time the services are updated in the register, it would automatically sync the changes on the firewalls or load-balancers. No need for humans to get involved in the process.
How does it actually work?
CTS is a lightweight application that watches for changes in Consul. In the CTS config, you need to tell CTS which Consul server to monitor.
CTS looks out for changes to services and pulls information from the Consul catalog…
…and based on this info, CTS would generate a new Terraform configuration and apply it to the network devices it needs to configure.
As Workday explained in their use case of CTS, there was no human harmed in the process.
Workday’s discussion around their use case is in this video.
Which Network Vendors are supported?
Well, in principle, this could work with anything that has a Terraform provider. That’s the only requirement. Now, to make this work, we need a module to extract the information from the Consul Service and provide the relevant details (IP addresses, service names, port details, etc…) as inputs and variables to build up the Terraform files.
The modules are published on the Terraform Registry and are typically named *-nia so this search should show you some of the CTS modules available.
If it’s not already there or if you want to extend an existing module, what we’ll do in the next post is write a module! Sneak peek in the Twitter thread below:
Thanks for reading.
nicovibert.com 
4 thoughts on “Consul-Terraform-Sync Part 1: Introduction”