Blog HCP Consul on Azure goes GA, plus more Consul news from HashiConf EU Read more
  • Overview
    • Consul on Kubernetes
    • Control access with Consul API Gateway
    • Discover Services with Consul
    • Enforce Zero Trust Networking with Consul
    • Load Balancing with Consul
    • Manage Traffic with Consul
    • Multi-Platform Service Mesh with Consul
    • Network Infrastructure Automation with Consul
    • Observability with Consul
  • Enterprise
  • Tutorials
  • Docs
  • API
  • CLI
  • Community
GitHub
Download
Try HCP Consul
    • v1.12.x (latest)
    • v1.11.x
    • v1.10.x
    • v1.9.x
    • v1.8.x
    • Overview
      • Overview
      • What is a Service Mesh?
      • Overview
      • Chef, Puppet, etc.
      • Nagios
      • SkyDNS
      • SmartStack
      • Serf
      • Eureka
      • Istio
      • Envoy and Other Proxies
      • Custom Solutions
    • Overview
    • Manual Bootstrap
    • Consul Agent
    • Glossary
    • Required Ports
    • Bootstrapping a Datacenter
    • Cloud Auto-join
    • Server Performance
    • Kubernetes
  • API
  • Commands (CLI)
    • Register Services - Service Definitions
    • Find Services - DNS Interface
    • Monitor Services - Check Definitions
    • Overview
    • How Service Mesh Works
    • Configuration
      • Overview
      • Ingress Gateway
      • Mesh
      • Exported Services
      • Proxy Defaults
      • Service Defaults
      • Service Intentions
      • Service Resolver
      • Service Router
      • Service Splitter
      • Terminating Gateway
      • Overview
      • Envoy
      • Built-in Proxy
      • Proxy Integration
      • Managed (Deprecated)
      • Overview
      • Proxy Service Registration
      • Sidecar Service Registration
    • Service-to-service permissions - Intentions
    • Service-to-service permissions - Intentions (Legacy Mode)
    • Transparent Proxy
      • Overview
      • UI Visualization
      • Overview
      • Discovery Chain
    • Connectivity Tasks
    • Distributed Tracing
      • Overview
        • WAN Federation
        • Enabling Service-to-service Traffic Across Datacenters
        • Enabling Service-to-service Traffic Across Admin Partitions
      • Ingress Gateways
      • Terminating Gateways
      • What is Cluster Peering
      • Create and Manage Peering Connections
      • Cluster Peering on Kubernetes
    • Nomad
    • Kubernetes
      • Overview
      • Go Integration
      • Overview
      • Built-In CA
      • Vault
      • ACM Private CA
    • Develop and Debug
    • Security
    • Overview
    • Installation
    • Technical Specifications
    • Common Errors
    • Upgrades
    • Overview
    • Architecture
      • Installing Consul on Kubernetes
      • Installing Consul K8s CLI
        • Minikube
        • Kind
        • AKS (Azure)
        • EKS (AWS)
        • GKE (Google Cloud)
        • Red Hat OpenShift
        • Self Hosted Kubernetes
        • Consul Clients Outside Kubernetes
        • Consul Servers Outside Kubernetes
        • Single Consul Datacenter in Multiple Kubernetes Clusters
        • Consul Enterprise
        • Overview
        • Federation Between Kubernetes Clusters
        • Federation Between VMs and Kubernetes
        • Overview
        • Systems Integration
          • Overview
          • Bootstrap Token
          • Enterprise License
          • Gossip Encryption Key
          • Partition Token
          • Replication Token
          • Server TLS
          • Service Mesh Certificates
          • Snapshot Agent Config
          • Webhook Certificates
        • WAN Federation
      • Overview
      • Transparent Proxy
      • Ingress Gateways
      • Terminating Gateways
      • Ingress Controllers
      • Configuring a Connect CA Provider
      • Health Checks
        • Metrics
    • Service Sync
      • Overview
      • Upgrade An Existing Cluster to CRDs
    • Annotations and Labels
    • Consul DNS
      • Upgrading Consul on Kubernetes
      • Upgrading Consul K8s CLI
      • Uninstall
      • Certificate Rotation
      • Gossip Encryption Key Rotation
      • Configure TLS on an Existing Cluster
      • Common Error Messages
      • FAQ
    • Compatibility Matrix
    • Helm Chart Configuration
    • Consul K8s CLI Reference
    • Overview
    • Requirements
    • Task Resource Usage
      • Installation
      • Secure Configuration
      • Migrate Existing Tasks
      • Installation
      • Secure Configuration
      • ACL Controller
    • Architecture
    • Consul Enterprise
    • Configuration Reference
    • Overview
    • Register Lambda Functions
    • Invoke Lambda Functions
    • Overview
      • Installation
      • Requirements
      • Configure
      • Run Consul-Terraform-Sync
    • Architecture
      • Overview
      • Status
      • Tasks
      • Health
      • Overview
      • task
      • start
    • Configuration
    • Tasks
    • Terraform Modules
      • Overview
      • License
      • Terraform Cloud Driver
      • Overview
      • Terraform
      • Terraform Cloud
    • Compatibility
    • Consul KV
    • Sessions
    • Watches
    • Overview
      • General
      • CLI Reference
      • Configuration Reference
    • Configuration Entries
    • Telemetry
    • Sentinel
    • RPC
    • Overview
      • ACL System Overview
      • Tokens
      • Policies
      • Roles
      • Rules Reference
      • Legacy Mode
      • Token Migration
      • ACLs in Federated Datacenters
        • Overview
        • Kubernetes
        • JWT
        • OIDC
        • AWS IAM
    • Encryption
      • Overview
      • Core
      • Network Infrastructure Automation
    • Overview
    • Admin Partitions
    • Audit Logging
    • Automated Backups
    • Automated Upgrades
    • Enhanced Read Scalability
    • Single sign-on - OIDC
    • Redundancy Zones
    • Advanced Federation
    • Network Segments
    • Namespaces
    • NIA with TFE
    • Sentinel
      • Overview
      • FAQ
    • Overview
    • Improving Consul Resilience
    • Anti-Entropy
    • Consensus Protocol
    • Gossip Protocol
    • Jepsen Testing
    • Network Coordinates
    • Consul Integration Program
    • NIA Integration Program
    • Vault Integration
    • Proxy Integration
  • Consul Tools
    • Overview
    • Compatibility Promise
    • Specific Version Details
      • Overview
      • General Process
      • Upgrading to 1.2.4
      • Upgrading to 1.6.9
      • Upgrading to 1.8.13
      • Upgrading to 1.10.0
    • Common Error Messages
    • FAQ
    • Overview
      • v1.11.x
      • v1.10.x
      • v1.9.x
      • v0.3.x
      • v0.2.x
      • v0.1.x
      • v0.4.x
      • v0.3.x
      • v0.2.x
      • v0.6.x
      • v0.5.x
    • Overview
    • ACL
  • Guides
Type '/' to Search

»Configure Consul-Terraform-Sync

The page will cover the main components for configuring your Network Infrastructure Automation with Consul at a high level. For the full list of configuration options, visit the Consul-Terraform-Sync (CTS) configuration page.

»Tasks

A task captures a network automation process by defining which network resources to update on a given condition. Configure CTS with one or more tasks that contain a list of Consul services, a Terraform module, and various Terraform providers.

Within the task block, the list of services for a task represents the service layer that drives network automation. The module is the discovery location of the Terraform module that defines the network automation process for the task. The condition, not shown below, defaults to the services condition when unconfigured such that network resources are updated on changes to the list of services over time.

Review the Terraform module to be used for network automation and identify the Terraform providers required by the module. If the module depends on a set of providers, include the list of provider names in the providers field to associate the corresponding provider configuration with the task. These providers will need to be configured later in a separate block.

task {
  name        = "website-x"
  description = "automate services for website-x"
  module      = "namespace/example/module"
  version     = "1.0.0"
  providers   = ["myprovider"]
  condition "services" {
    names = ["web", "api"]
  }
}
task {
  name        = "website-x"
  description = "automate services for website-x"
  module      = "namespace/example/module"
  version     = "1.0.0"
  providers   = ["myprovider"]
  condition "services" {
    names = ["web", "api"]
  }
}

»Terraform Providers

Configuring Terraform providers within CTS requires 2 config components. The first component is required within the driver.terraform block. All providers configured for CTS must be listed within the required_providers stanza to satisfy a Terraform v0.13+ requirement for Terraform to discover and install them. The providers listed are later organized by CTS to be included in the appropriate Terraform configuration files for each task.

driver "terraform" {
  required_providers {
    myprovider = {
      source  = "namespace/myprovider"
      version = "1.3.0"
    }
  }
}
driver "terraform" {
  required_providers {
    myprovider = {
      source  = "namespace/myprovider"
      version = "1.3.0"
    }
  }
}

The second component for configuring a provider is the terraform_provider block. This block resembles provider blocks for Terraform configuration and has the same responsibility for understanding API interactions and exposing resources for a specific infrastructure platform.

Terraform modules configured for task automation may require configuring the referenced providers. For example, configuring the host address and authentication to interface with your network infrastructure. Refer to the Terraform provider documentation hosted on the Terraform Registry to find available options. The terraform_provider block is loaded by CTS during runtime and processed to be included in autogenerated Terraform configuration files used for task automation. Omitting the terraform_provider block for a provider will defer to the Terraform behavior assuming an empty default configuration.

terraform_provider "myprovider" {
  address = "myprovider.example.com"
}
terraform_provider "myprovider" {
  address = "myprovider.example.com"
}

»Summary

Piecing it all together, the configuration file for CTS will have several HCL blocks in addition to other options for configuring the CTS daemon: task, driver.terraform, and terraform_provider blocks.

An example HCL configuration file is shown below to automate one task to execute a Terraform module on the condition when there are changes to two services.

log_level = "info"

syslog {
  enabled = true
}

consul {
  address = "consul.example.com"
}

task {
  name        = "website-x"
  description = "automate services for website-x"
  module      = "namespace/example/module"
  version     = "1.0.0"
  providers   = ["myprovider"]
  condition "services" {
    names = ["web", "api"]
  }
  buffer_period {
    min = "10s"
  }
}

driver "terraform" {
  log = true

  required_providers {
    myprovider = {
      source  = "namespace/myprovider"
      version = "1.3.0"
    }
  }
}

terraform_provider "myprovider" {
  address = "myprovider.example.com"
}
cts-example-config.hcl
log_level = "info"

syslog {
  enabled = true
}

consul {
  address = "consul.example.com"
}

task {
  name        = "website-x"
  description = "automate services for website-x"
  module      = "namespace/example/module"
  version     = "1.0.0"
  providers   = ["myprovider"]
  condition "services" {
    names = ["web", "api"]
  }
  buffer_period {
    min = "10s"
  }
}

driver "terraform" {
  log = true

  required_providers {
    myprovider = {
      source  = "namespace/myprovider"
      version = "1.3.0"
    }
  }
}

terraform_provider "myprovider" {
  address = "myprovider.example.com"
}
github logoEdit this page
IntroGuidesDocsCommunityPrivacySecurityBrandConsent Manager