Network Infrastructure Automation (NIA) with Terraform and Consul

In this whiteboard video, Armon Dadgar shows why it's crucial — in the cloud adoption era — to use infrastructure as code not only for automating and templatizing your system's required compute and database resources, but also its networking infrastructure, such as firewalls, load balancers, routers, etc.

In addition, your network's service discovery (sometimes called a service registry) and potential service mesh system needs to send automated triggers to your infrastructure as code provisioning tool. See how this best-practice system looks for top-tier IT teams among the Global 2000 organizations.

Visit our Network Infrastructure Automation page to learn more.

Transcript

Hello. I want to spend a bit of time today talking about using Consul for doing networking infrastructure automation. When we talk about Consul, I think the most common use case people think about is service discovery. And that's the core of what Consul originally was meant to solve.

One way to think about service discovery is as a common registry of all the different applications we have running. If we have applications A, B, C, and D, for example, all of them register implicitly with Consul, and so we have the catalog of all the applications and where are they running.

This initial use case is what we call "service discovery," or you can think about it as service registry, where you have this bird's-eye catalog of where everything is running.

What this enables us to do is, as these services want to talk to one another, they can query Consul and use it as a dynamic dictionary or directory of all the different services.

One way to think about it is the dynamic linker of the network. Instead of A hardcoding the IP address of B, it's querying Consul. And Consul's saying, "Here's the IP to go talk to B; here's the way to get to C." That's layer 1.

When Middleware Is in the Picture

The reality is, in most networks, it's not as simple as independent applications on a flat network talking to one another. In practice, you have different middleware that exists between them.

For example, if A wants to talk to a database, that database might have, for example, a firewall that sits behind it. Or we might have traffic that needs to come in from the public internet. We have an API gateway as an example. And that API gateway is sending traffic to services C and D.

The reality is we're going to have a bunch of different middleware. It might be firewalls, API gateways, load balancers, for example. Service B might be very popular, and lots of services are reaching it. So we have a load balancer that's fronting traffic coming in.

There are lots of these different middleware appliances that exist within the network. I think a common challenge that we end up seeing is that the changes to these services sit behind a ticketing mechanism.

If I'm deploying a new instance of A, and that thing needs to be able to reach the database, oftentimes I have to file a ticket and wait for someone to manually update this firewall rule so that I can get access to the database.

Similarly, if I launch a new instance of B, you have to file a ticket, and someone updates the load balancer for scaling system D up. Someone has to manually update the API gateway to add it into the configuration.

The Benefits of Consul-Aware Solutions

There are a few areas where Consul can help us to do this infrastructure automation. More modern, sophisticated solutions—modern API gateways, modern load balancers, modern firewalls—oftentimes they're directly Consul-aware.

If we're, for example, using an F5 BIG-IP device as our API gateway, great. F5 is Consul-aware. We can configure it to say, "C and D are my upstream services in this case. I'm not going to provide a static set of IPs. Just go and integrate query.consul.

Now if I scale up D, I don't need to file a ticket to manually update the API gateway. It automatically gets it by virtue of just querying Consul and treating it as the service discovery, or service registry.

Similarly, if I'm using a modern load balancer, say Nginx as an example, it can also query Consul and do the same thing.

This makes sense if I have these more modern appliances. They might be Consul-aware; they can do the more dynamic discovery.

Network Infrastructure Automation

What if I don't have that? Maybe I have a more traditional firewall that's not Consul-aware. It can't integrate with it. This is where we have a use case that we refer to as "network infrastructure automation."

With network infrastructure automation, the idea is, I still don't want to be in the business of managing low-level IPs. I don't want to manage the set of IPs that say, "What are the set of IPs that belong to A, and how do I manually keep those up to date to talk to the database, which itself might have a dynamic set of IPs?"

Instead, we want to focus on a high-level set of rules. I want to say service A is allowed to talk to my database. I don't really care what the IPs of A are, and I don't really care what the IPs of the database are. They're going to scale up and down, things might move around, etc. I want to be reactive to that.

In this use case, we leverage Terraform. We offer a snippet of Terraform configuration.

Terraform is infrastructure as code. Our input is service A as well as the set of database nodes.

We're going to configure, as part of our Terraform ,the rules, for example, to configure our Palo Alto firewall. This is a publisher-subscriber relationship. When these services and new instance A comes up, it's registering with Consul and publishing the fact that there's a new instance of A.

We configure this Terraform snippet using what we call the "Consul-Terraform-Sync agent." It's going to look and say, "I'm subscribed to the changes in service A or to service database."

The moment this gets published and there's a new instance of A, it triggers the subscription. So we say, "Great; before you only had this one instance of A, and now there's a second IP." Those get fed as inputs to this Terraform configuration, which then gets executed and automatically updates the Palo Alto device.

This creates a clean separation for us. As an application developer, our contract as we deploy our application, the application publishes and registers to Consul.

It says, "I'm a new instance of A," or, "I'm a new instance of D." Then we can drive the downstream subscription. That subscription might be to an API gateway that's Consul-aware, so it automatically can add D as a backend.

But it might be driving a subscription through our Terraform agent. What that allows us to do is define, using Terraform in the existing resources, how we want that to be reflected to, let's say, our firewall, though it could be our load balancer or an API gateway.

Partnering with the Big Players

When we announced this network infrastructure play, we did it in partnership with the biggest, most common networking providers. You can get a full list on our website, but it includes Cisco, Juniper, A10, Checkpoint, Palo Alto, etc. The list goes on.

The idea is you can still bring along your network and automate it as part of this broader infrastructure, using the publisher-subscriber mechanism, with Consul acting as that central broker.

That gives you full discovery and visibility. It works natively with modern apps that can query Consul, modern networking solutions that are integrated.

And we can apply this network infrastructure automation approach using Terraform to then automate against all of the other things that we have. As long as they have an API and have a Terraform provider, we can fit it into this model.

This starts to give us a story around, How do we automate our infrastructure end to end, where our application deployment might be automated?

But now this includes the networking updates as part of that. We don't have to file a ticket and then wait for someone to manually update a firewall or manually update a load balancer. We're really flowing that automation end to end through the system.

Hopefully this gives a sense of how Consul fits in and how it can be integrated with Terraform as part of our network infrastructure automation.

Thanks.