Partner Guide - Consul NIA, Terraform, and A10 ADC
Hybrid cloud environments emerge when organizations migrate some applications to the cloud while keeping their existing on-premises datacenters. These types of environments can increase complexity and complicate operations.
Many organizations adopt DevOps practices to solve challenges associated with hybrid cloud environments. DevOps helps you enable self-service models and automate operational tasks, including automated flows between your service networking control plane, your infrastructure provisioning platform, and your network devices.
HashiCorp and A10 Networks collaborated on a strategy for this using HashiCorp's Network Infrastructure Automation (NIA).
This tutorial provides step-by-step instructions on how to automate the configuration update process for an A10 Thunder Application Delivery Controller (ADC) using Terraform and Consul. You can use the workflow presented as a blueprint, to get familiar with the pattern and accelerate your own networking infrastructure management.
Prerequisites
To complete the tutorial you need the following components:
- HashiCorp Terraform for infrastructure as code,
- HashiCorp Consul for service networking and service mesh,
- Consul-Terraform-Sync (CTS) for automation between those two products,
- A10 Thunder Application Delivery Controller (ADC).
The diagram below shows an example NIA workflow with Terraform, Consul, CTS, and A10 Thunder ADC.
Network device - A10 Thunder Application Delivery Controller (ADC)
The first step is to enable automated provisioning workflows for network devices. This tutorial uses A10 Thunder Application Delivery Controller (ADC) as an example, but this workflow can also work with other vendors that have built NIA integrations.
One of the main ADC use-cases is as a reverse proxy for application servers. This increases service resiliency with server load balancing, application acceleration, and security features, and enables agile traffic control including CI/CD operation support. Furthermore, global server load balancing (GSLB), which comes with A10 ADC by default, can intelligently distribute the traffic across available global sites based on regions and locations, contents and language localization policy, or the site’s load and health condition regardless of cloud or platform types. GSLB can work as a cloud selector and effectively utilize hybrid and multi-cloud environments and resources.
Terraform
Terraform is a tool for deploying and managing infrastructure as code. The A10 Terraform provider supports the provisioning and configuration updates for A10 Thunder ADC in any form factors or underlying cloud infrastructure.
Below is an example Terraform configuration that shows a minimum service load
balancing (SLB) configuration required for A10 ADC and NIA integration. This
defines a service group web80
and a virtual server named vip-web80
. The
application server resources are automatically added or deleted via the NIA
workflow process that is explained later in the tutorial.
Note
It is assumed that system, interface, and routing are already configured on the A10 Thunder ADC during the installation process.
Note
Consul-Terraform-Sync requires Terraform 0.13+
to operate. You
can either install Terraform before starting the Consul-Terraform-Sync or let
the Consul-Terraform-Sync daemon install a compatible Terraform version for you.
Consul
In NIA, application servers and their services' status are monitored via Consul. Consul builds a service catalog by communicating with each service instance node via a local Consul agent.
Once Consul is deployed and all agents have joined the datacenter, it is time to prepare Consul-Terraform-Sync (CTS).
Consul-Terraform-Sync
Consul-Terraform-Sync (CTS) is a tool that uses Consul’s service catalog as a source of truth for all applications running in a given environment. When changes to these applications are detected (e.g., a new service node is added or deleted from the service list), CTS dynamically applies the necessary changes to your network infrastructure using Terraform.
Configure Consul-Terraform-Sync
You will define a set of tasks for CTS to execute whenever a service is registered or removed from Consul. The CTS configuration (in HCL format) below contains several blocks:
The driver
defines all Terraform providers required to execute the task. In
this case, source = "a10networks/thunder"
is listed.
The terraform_provider
specifies the options and variables to interface with
network infrastructure, such as ADC. The example above includes the IP address
of an A10 Thunder ADC, an alias, and a login credential.
Note
For security purposes, we recommend separating login credentials from the CTS configuration files and loading them dynamically via shell (Env), Consul KV, or HashiCorp Vault.
The task
block identifies a task to run as automation for the selected
services. The task named slb_auto_config
includes a list, under condition "services"
, of
logical service names that should match the service name(s) registered on the
Consul catalog. providers
lists the network infrastructure (e.g., Thunder ADC)
with aliases (if applicable). module
specifies a path to the Thunder Terraform
module defined for CTS that allows A10 Thunder ADC to dynamically manage ADC
configuration (e.g., SLB server and SLB service group) for the services
monitored on the Consul catalog.
Note
For more details about the configuration, refer to the Consul NIA documentation. For more details on the Terraform NIA module for A10 Thunder, refer to the Terraform Registry or GitHub.
Consul privileges (ACL config) and connectivity
Consul-Terraform-Sync needs to access different data in the Consul catalog and if you're using Consul as Terraform backend, you'll also need privileges to store the Terraform state into Consul's KV store.
In production environments, we recommend to configure Consul with Access Control Lists (ACLs) enabled. In these scenarios, in order for Consul-Terraform-Sync to access information from Consul, a token needs to be passed to its configuration. Please visit the Secure Consul with Access Control Lists (ACLs) to learn how to configure Consul with ACLs.
Services and nodes privileges
In the configuration used as example above you are defining a task that reacts
on changes to instances of the service named web80
, so you need a policy
giving you read
access to those services.
The example includes read permissions over all nodes. If your naming conventions permit you to setup a prefix for the client nodes hosting the services, you can have a stricter rule for the nodes, too.
Consul KV privileges
When Terraform uses Consul as a backend, it will also need privileges to store the state inside the Consul KV and to use sessions to ensure locking during the Terraform state changes.
Note
By default Consul-Terraform-Sync will use the
consul-terraform-sync
KV path to store the Terraform state. However, you can
configure the path in the driver.terraform.backend
section of the configuration.
Run Consul-Terraform-Sync
Once CTS is configured, start it using the consul-terraform-sync
command.
On startup, CTS will download and install Terraform providers and modules
according to the HCL config file, create Terraform files for the tasks
defined, and connect to Consul.
Verify NIA automation workflow
Once Consul-Terraform-Sync is configured and started, you can verify the
workflow by registering new instances of the web80
service in the Consul
service catalog.
On each Consul agent, create a service registration file where you will define the service details (IP, port, etc.) and health check information.
Note
The service name should match the service-group
name defined
on the A10 Thunder ADC and the condition "services"
block defined in your CTS
task configuration.
Once the configuration file is placed into the Consul home directory (e.g.,
/etc/consul.d/
), reload the Consul configuration
After the reload, the Consul catalog will show the new instances of the application server in the Services tab:
On CTS, the change is picked up and the task slb_auto_config
is executed
automatically.
In this process, CTS automatically creates a new slb server for
each instance of the web80
service registered in Consul and adds it into the
service-group
named web80
, using Terraform, on the Thunder ADC.
The CTS task adds the new instances to the vThunder ADC (VIP with service port 80). Once the task is executed the instances will be visible from the ADC console.
The same task will be executed each time a service with the same name is added to the Consul catalog and, thanks to NIA automation, the A10 Thunder ADC’s SLB configurations are automatically updated in near-real time.
Next steps
The NIA solution using CTS is a powerful network automation enabler and works perfectly with A10 Thunder ADC whenever any new service instances are added or when any status change is detected by Consul in the existing instances.
This automates the operations necessary in case of infrastructure change or if any unexpected server failure happens. Furthermore, you can extend this NIA solution to support CI/CD operations, including blue-green deployment by leveraging Terraform and service tags on Consul.
Consul's integration with A10 Thunder results in portable workflows, with minimal changes, across various cloud providers, hypervisors, and platforms. This increases your flexibility and simplifies workflow migration across different solutions.
Links and references
For more resources on how to try NIA out yourself, check out:
- Consul documentation
- Try A10 Thunder free for 30 days
- Get the Terraform NIA module for A10 Thunder
- Webinar: Automating Network Infrastructure Tasks with A10 and HashiCorp