Network Infrastructure Automation

Network Infrastructure Automation (NIA) enables dynamic updates to network infrastructure devices triggered by service changes. Consul-Terraform-Sync (CTS) utilizes Consul as a data source that contains networking information about services and monitors those services. Terraform is used as the underlying automation tool and leverages the Terraform provider ecosystem to drive relevant changes to the network infrastructure.

CTS executes one or more automation tasks with the most recent service variable values from the Consul service catalog. Each task consists of a runbook automation written as a CTS compatible Terraform module using resources and data sources for the underlying network infrastructure. The consul-terraform-sync daemon runs on the same node as a Consul agent.

CTS is available as an open source and enterprise distribution. Follow the Network Infrastructure Automation introduction tutorial to get started with CTS OSS or read more about CTS Enterprise.

Use Cases

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. CTS 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.

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 organizations 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. CTS runs in near real-time to keep up with the rate of change.

Glossary

  • Condition - A task-level defined environmental requirement. When a task’s condition is met, CTS executes that task to update network infrastructure. Depending on the condition type, the condition definition may also define and enable the module input that the task provides to the configured Terraform Module.

  • Consul objects - Consul objects are the response request objects returned from the Consul API that CTS monitor for changes. Examples of Consul objects can be service instance information, Consul key-value pairs, and service registration. The Consul objects are used to inform a task’s condition and/or module input.

  • Consul-Terraform-Sync (CTS) - GitHub repo and binary/CLI name for the project that is used to perform Network Infrastructure Automation.

  • Dynamic Tasks - A dynamic task is a type of task that is dynamically triggered on a change to any relevant Consul catalog values e.g. service instances, Consul KV, catalog-services. See scheduled tasks for a type of non-dynamic task.

    Note: The terminology “tasks” used throughout the documentation refers to all types of tasks except when specifically stated otherwise.

  • Network Drivers - CTS uses network drivers to execute and update network infrastructure. Drivers transform Consul service-level information into downstream changes by processing and abstracting API and resource details tied to specific network infrastructure.

  • Network Infrastructure Automation (NIA) - Enables dynamic updates to network infrastructure devices triggered when specific conditions, such as service changes and registration, are met.

  • Scheduled Tasks - A scheduled task is a type of task that is triggered only on a schedule. It is configured with a schedule condition.

  • Services - A service in CTS represents a service that is registered with Consul for service discovery. Services are grouped by their service names. There may be more than one instance of a particular service, each with its own unique ID. CTS monitors services based on service names and can provide service instance details to a Terraform module for network automation.

  • Module Input - A module input defines objects that provide values or metadata to the Terraform module. See module input for the supported metadata and values. For example, a user can configure a Consul KV module input to provide KV pairs as variables to their respective Terraform Module.

    The module input can be configured in a couple of ways:

    • Setting the condition block’s use_as_module_input field to true
      • Field was previously named source_includes_var (deprecated)
    • Configuring module_input block(s)
      • Block was previously named source_input (deprecated)

    “Module input” was renamed from “source input” in CTS 0.5.0 due to updates to the configuration names seen above.

    Note: The terminology “tasks” used throughout the documentation refers to all types of tasks except when specifically stated otherwise.

  • Tasks - A task is the translation of dynamic service information from the Consul Catalog into network infrastructure changes downstream.

  • Terraform Cloud - Per the Terraform documentation, “Terraform Cloud” describes both Terraform Cloud and Terraform Enterprise, which are different distributions of the same application. Documentation will apply to both distributions unless specifically stated otherwise.

  • Terraform Module - A Terraform module is a container for multiple Terraform resources that are used together.

  • Terraform Provider - A Terraform provider is responsible for understanding API interactions and exposing resources for an infrastructure type.

Getting Started With Network Infrastructure Automation

The Network Infrastructure Automation (NIA) collection contains examples on how to configure CTS to perform Network Infrastructure Automation. The collection contains also a tutorial to secure your CTS configuration for a production environment and one to help you build you own CTS compatible module.

Community