Using Consul to configure API Gateway with Envoy

Scott Weiss
ITNEXT
Published in
4 min readAug 30, 2019

--

API Gateways are a popular solution for managing access to cloud backends, but are typically restricted in the environments they support. Modern solutions for ingress and API Gateway tend to rely on Kubernetes or a specific cloud provider to work properly.

This article dives into Gloo, a modern API Gateway based on Envoy which can use Consul in place of Kubernetes for service discovery, configuration, and access control.

Click here to skip the reading and jump right into a recorded demo running Envoy as an API Gateway on top o Nomad, Consul, and Vault (using Gloo).

A 2018 study conducted by DataDog¹ revealed that only 25% of customer workloads had adopted Docker for containerization, and less than 50% of those were using an orchestration system such as Kubernetes.

Cutting-edge technologies such as Service Mesh and API Gateway are supercharging our ability to orchestrate IT² , but they usually come at the cost of requiring a migration to the newest available technologies. This fact has left a gap in the cloud ecosystem between rapidly emerging tech, and its own challenges to adoption.

but the many workloads which have not already migrated to Kubernetes are left in the dust.

At Solo.io, we build software solutions to help customers transition from monolithic/legacy architectures to modern infrastructure. A primary consideration for any feature is how we will support non-Kubernetes environments, and hybrid environments with workloads running on and off Kubernetes.

This is especially important in Gloo, Solo.io’s Envoy-Powered API Gateway which promises to “glue together” the distributed application components which form logical units of business value. In principle, API Gateways function to unify separate back-end services in a single client-facing entrypoint.

API Gateway Diagram. Source: https://microservices.io/patterns/apigateway.html

The value an API Gateway provides is limited when it can only do its job inside a partition the infrastructure? Its routing ability will be constrained, and it will not be possible to create unified entrypoints unless the infrastructure itself is all housed within a single environment.

With its plugin architecture and separate control plane/data plane architecture, Gloo supports easy extensibility to any backend, regardless of the application stack or infrastructure used to deploy it.

Gloo’s API Gateway Plugin Ecosystem

We extended Gloo to act as an API Gateway for HashiCorp Consul to provide three features:

  • Service Discovery
  • Configuration Storage
  • Access control

Consul is a popular infra tool that can be used as a distributed Key-Value store (similar to etcd), as well as a service discovery backend, storing IPs, ports, health info, and metadata about discovered services.

Gloo can be plugged directly into Consul, removing the requirement a for Kubernetes as a source of configuration and service discovery. When plugging Gloo into Consul:

All services in the Consul Service Catalog become routable endpoints for Gloo:

curl localhost:8080/ -H "Host: petstore"[
{
"id": 1,
"name": "Dog",
"status": "available"
},
{
"id": 2,
"name": "Cat",
"status": "pending"
}
]

And Gloo configuration can be reviewed and modified directly in the Consul Key-Value Store:

Consul configuration is replicated across datacenters, allowing API Gateway configurations to be configured with one Consul agent and shared across any number of datacenters.

Administrators in multi-tenant environments can set policy and permissions with the use of Consul ACL Tokens, securing access to sensitive routing configuration:

Without being coupled with an application runtime, Consul has remained a favored choice for configuration, service discovery, health checks, and access control for workloads both on and off Kubernetes. If you’re new to either Consul or Gloo, we encourage you to check out a brief tutorial running the Gloo API Gateway locally with Consul. No minikube required!

Here’s a video of that same tutorial in action:

In future posts, we will cover how Gloo can leverage HashiCorp Nomad for deployment and HashiCorp Vault for credential management. A full tutorial covering all 3 components can be found here: https://gloo.solo.io/installation/gateway/nomad/.

Thanks for reading, stay tuned for more blogs and exciting open source software from Solo.io!

[1]: Datadog. (June 2018). 8 Surprising Facts about Real Docker Adoption https://www.datadoghq.com/docker-adoption/

[2]: Admittedly, a gross oversimplification of the function of cloud technologies.

--

--

Principal Software Engineer at Solo.io. Topics: Envoy, Kubernetes, Istio and Go. Hobby game dev and artist in spare time (which doesn’t exist).