home
navigate_next
Blog
navigate_next

Consul Terraform Sync

Consul Terraform Sync
Rohan Gupta
Consul Terraform Sync

Problem Statement

Application teams must wait for manual changes in the network to release, scale up/down and re-deploy their applications. This creates a bottleneck, especially in frequent workflows related to scaling up/down the application, breaking the DevOps goal of self-service enablement.

Networking and security teams cannot scale processes to the speed and changes needed. Manual approaches don't scale well, causing backlogs in network and security teams. Even in organisations that have some amount of automation (such as scripting), there is a need for an accurate, real-time source of data to trigger and drive their network automation workflows.

How Does Consul-Terraform-Sync Helps

Consul-Terraform-Sync automates this process, thus decreasing the possibility of human error in manually editing configuration files, as well as decreasing the overall time taken to push out configuration changes.

Consul-Terraform-Sync runs in near real-time to keep up with the rate of change.

Network Infrastructure Automation

Network Infrastructure Automation (NIA) enables dynamic updates to network infrastructure devices triggered by service changes.

Consul Terraform Sync (just Sync from here on) is a service-oriented tool for managing network infrastructure near real-time. Sync runs as a daemon and integrates the network topology maintained by your Consul cluster with your network infrastructure to dynamically secure and connect services.

Github Repo -

https://github.com/hashicorp/consul-terraform-sync

Sync is a daemon that runs alongside Consul, similar to other Consul ecosystem tools like Consul Template. Sync is not included with the Consul binary and will need to be installed separately.

Download

To install Sync, find the appropriate package for your system and download it as a zip archive. Unzip the package to extract the binary named consul-terraform-sync. Move the consul-terraform-sync binary to a location available on your $PATH.

1. Download a pre-compiled, released version from the Sync release page.

2. Extract the binary using unzip or tar.

3. Move the binary into $PATH.

$ wget https://releases.hashicorp.com/consul-terraform-sync/${VERSION}/consul-terraform-sync_${VERSION}_${OS}_${ARCH}.zip
$ unzip consul-terraform-sync_${VERSION}_${OS}_${ARCH}.zip
$ mv consul-terraform-sync /usr/local/bin/consul-terraform-sync

Verify

Once installed, verify the installation works by prompting the help option.

$ consul-terraform-sync -h
Usage of consul-terraform-sync:
 -config-dir value
     A directory to load files for configuring Sync. Configuration files
     require an .hcl or .json file extention in order to specify their format.
     This option can be specified multiple times to load different directories.
 -config-file value
     A file to load for configuring Sync. Configuration file requires an
     .hcl or .json extension in order to specify their format. This option can
     be specified multiple times to load different configuration files.
 -once
     Render templates and run tasks once. Does not run the process as a daemon
     and disables wait timers.
 -version
     Print the version of this daemon.

Documentation on various configuration parameters -

https://www.consul.io/docs/nia/configuration

A sample Problem & solution via Consul-terraform-sync

1.     The infrastructure is deployed onAzure and has 3 VNETs
a. Hashicorp Consul Service hosting VNET.
b. Shared Service VNET (Shared service like Hashicorp Vault and Bastian Host).
c. Application and Network service stack.

2.     A Two Tier Application running VirtualMachines that uses Consul for Service discovery.

NOTE: It should be a Consul Ecosystem. Applications need to register themselves to Consul i.e a consul agent should be running and registered to Consul server.

Normal Workflow

New virtual machines are frequently added and removed to handle scaling requirements.

The overworked NetOps and SecOps teams have to frequently reconfigure the load balancers and firewalls.

The long hours and lengthy job queues result in deployment errors and, potentially security issues.

Current Solution - Scripts to Automate health checks for new servers and add them to Route53.

NIA - Operational Pattern

The Consul - Terraform -Sync sits at the NetOps layer.

Consul monitors application state changes in real-time (IP Addresses and App meta-data).

Consul Terraform Sync uses this information to automatically configure the various network infrastructure, eliminating the need for NetOps teams to be involved after the initial configuration.

NOTE: Consul Terraform Sync automates the management of policy address groups on the Palo Alto Firewalls. This facilitates having fine-grained policies without increasing operational overhead.

Terraform Templates and Configuration file for above setup

https://github.com/hashicorp/field-workshops-consul/tree/master/instruqt-tracks/network-infrastructure-automation

cat << EOF > /etc/consul-tf-sync.d/consul-tf-sync.hcl
# Global Config Options
log_level = "info"
buffer_period {
 min = "5s"
 max = "20s"
}
# Consul Config Options
consul {
 address = "localhost:8500"
 token = "${consul_token}"
}
# Terraform Driver Options
driver "terraform" {
 log = true
 path = "/opt/consul-tf-sync.d/"
 working_dir = "/opt/consul-tf-sync.d/"
 required_providers {
   bigip = {
     source = "F5Networks/bigip"
   },
   panos = {
     source = "PaloAltoNetworks/panos"
   }
 }
}
## Network Infrastructure Options
# BIG-IP Workflow Options
terraform_provider "bigip" {
 address = "${bigip_mgmt_addr}:8443"
 username = "${bigip_admin_user}"
 password = "${bigip_admin_passwd}"
}
# Palo Alto Workflow Options
terraform_provider "panos" {
 alias = "panos1"
 hostname = "${panos_mgmt_addr}"
#  api_key  = "<api_key>"
 username = "${panos_username}"
 password = "${panos_password}"
}
## Consul Terraform Sync Task Definitions
# Load-balancer operations task
task {
 name = "F5-BIG-IP-Load-Balanced-Web-Service"
 description = "Automate F5 BIG-IP Pool Member Ops for Web Service"
 source = "f5devcentral/app-consul-sync-nia/bigip"
 providers = ["bigip"]
 services = ["web"]
}
# Firewall operations task
task {
 name = "DAG_Web_App"
 description = "Automate population of dynamic address group"
 source = "PaloAltoNetworks/ag-dag-nia/panos"
 providers = ["panos.panos1"]
 services = ["web"]
 variable_files = ["/etc/consul-tf-sync.d/panos.tfvars"]
}
EOF
cat << EOF > /etc/consul-tf-sync.d/panos.tfvars
dag_prefix = "cts-addr-grp-"
EOF

Glossary

buffer_period - Configures the default buffer period for all tasks to dampen the affects of flapping services to downstream network devices. It defines the minimum and maximum amount of time to wait for the cluster to reach a consistent state and accumulate changes before triggering task executions. The default is enabled to reduce the number of times downstream infrastructure is updated within a short period of time. This is useful to enable in systems that have a lot of flapping.

The consul block is used to configure Consul-Terraform-Sync connection with a Consul agent to perform queries to the Consul Catalog and Consul KV pertaining to task execution.

The driver block configures the subprocess for Consul-Terraform-Sync to propagate infrastructure change. The Terraform driver is a required configuration for Consul-Terraform-Sync to relay provider discovery and installation information to Terraform, specifically the required_providers stanza. Other driver options do not need to be explicitly configured and has reasonable default values..

A terraform_provider block configures the options to interface with network infrastructure. Define a block for each provider required by the set of Terraform modules across all tasks. This block resembles provider blocks for Terraform configuration. To find details on how to configure a provider, refer to the corresponding documentation for the Terraform provider. The main directory of publicly available providers are hosted on the Terraform Registry.

A task block configures which task to run in automation for the selected services. The list of services can include services explicitly defined by a service block or implicitly declared by the service name. The task block may be specified multiple times to configure multiple tasks.

arrow_back
Back to blog