HashiCorp has announced the release of version 0.5 of Consul-Terraform-Sync (CTS). CTS enables automating common networking tasks by creating Terraform modules that can be run as services are added or removed from Consul. This release adds new secure API endpoints to facilitate modifying existing tasks, new ecosystem integrations, and support for triggering Terraform workflows on Consul key-value changes.
CTS is part of the Network Infrastructure Automation (NIA) solution which focuses on automating common "day two" network tasks such as updating load balancer pools or firewall policies. CTS monitors the Consul service catalog for updates using a watcher. For each value being monitored a separate thread is maintained by the watcher process. When a change is detected, any tasks that depend upon the watched value are run.
With this release, it is now simpler to modify a task after its creation. Prior to this release, modifying an existing task required stopping the CTS process, adjusting the configuration file, and then restarting the CTS process. The release introduces four new API endpoints and a CLI to create, update, delete, and read tasks.
For example, a GET request to /tasks/:task_name can be used to get information about an existing task. Creating a task can be done via POST to /tasks as follows:
curl --header "Content-Type: application/json" \
--request POST \
--data @payload.json \
localhost:8558/v1/tasks
The route accepts an optional parameter, run, that can be set to either create and execute the task immediately (now) or run in a no-op mode (inspect). The task is defined as JSON and sent as the --data parameter. In the above example, the contents of payload.json could look like the following:
{
"task": {
"description": "Writes the service name, id, and IP address to a file",
"enabled": true,
"name": "task_a",
"providers": ["my-provider"],
"condition": {
"services": {
"names": ["web", "api"]
}
},
"module": "path/to/module"
}
}
All four tasks can be executed via the new CLI as well. For example, task creation can be done by calling consul-terraform-sync task create -task-file=task_example.hcl, where task_example.hcl contains the task definition similar to the above example.
In the 0.4 release the module_input block was added to the task configuration (in 0.4 this was called source_input). A module_input block specifies a Consul object containing values or metadata which is provided to the Terraform Module. At the time of its original release, module_input was only configurable within scheduled tasks. With this release, the module_input block can be used with all task types. It is also possible to configure more than one module_input block per task as long as they are unique.
For example, this scheduled task queries all Consul services with web as the suffix. The metadata for any matching services are then provided to the Terraform module:
task {
name = "schedule_condition_task"
description = "execute every Monday using information from service names starting with web"
module = "path/to/module"
condition "schedule" {
cron = "* * * * Mon"
}
module_input "services" {
regexp = "^web.*"
datacenter = "dc1"
namespace = "default"
filter = "Service.Tags not contains \"prod\""
cts_user_defined_meta {
key = "value"
}
}
}
A Consul KV module_input block can also be used with Consul KV to monitor changes within that service which are then provided as Consul KV module input to the Terraform module. This input can be configured for a single Consul KV entry or for any Consul KV entries that are prefixed with a given path.
This release also adds new ecosystem integrations with Cisco Secure Firewall Management Center (FMC) and Fortinet FortiManager. Both integrations are provided through new Terraform modules.
CTS can be used with Terraform OSS, Terraform Enterprise, and Terraform Cloud. More details about the release can be found in the change log. More information on CTS can be found within the documentation or HashiCorp Learn guides.