Skip to main content
June 20-22 Announcing HashiConf Europe full schedule: keynotes, sessions, labs & more Register Now
Type '/' to Search

What is Consul?

This tutorial also appears in: Consul on Kubernetes and Consul on HCP.

Welcome to HashiCorp's Learn platform! Here you'll find step-by-step examples of how to perform common Consul tasks. This collection will teach you the fundamentals of Consul and how to operate Consul. Before diving into Consul, you must understand what a service mesh is.

»What is a service mesh?

A service mesh is a dedicated layer that provides secure service-to-service communication for on-prem, cloud, or multi-cloud infrastructure. Service meshes are often used with a microservice architectural pattern, but can provide value in any scenario where complex networking is involved.

Service meshes typically consist of a control plane, and a data plane. The control plane maintains a central registry that keeps track of all services and their respective IP addresses, this is called service discovery. As long as the application is registered with the control plane, the control plane will be able to share with other members of the service mesh how to communicate with the application and enforce rules for who can communicate with each other.

The control plane is responsible for securing the mesh, facilitating service discovery, health checking, policy enforcement, and other similar operational concerns. The data plane handles communication between services. Many service mesh solutions employ a sidecar proxy to handle data plane communications, and thus limit the level of awareness the services need to have about the network environment.

With that explanation out of the way, it's time to dive into what Consul is.

»What is Consul?

Consul is the control plane of the service mesh.

Consul is a multi-networking tool that offers a fully-featured service mesh solution that solves the networking and security challenges of operating microservices and cloud infrastructure. Consul offers a software-driven approach to routing and segmentation. It also brings additional benefits such as failure handling, retries, and network observability. Each of these features can be used individually as needed or they can be used together to build a full service mesh and achieve zero trust security.

You can use Consul with virtual machines (VMs), containers, or with container orchestration platforms, such as Nomad and Kubernetes. Consul is platform agnostic which makes it a great fit for all environments, including legacy platforms.

As mentioned earlier, Consul is a multi-networking tool that offers capabilities beyond a service mesh. For the purpose of this tutorial, the scope will be limited to service mesh. To learn more about Consul's networking capabilities, please visit consul.io.

»High level overview

To better understand Consul it helps to understand the problem domains that Consul solves. Please review our video below for a brief introduction to Consul and to understand Consul's use cases.

Now that you understand Consul's benefits and use cases, continue to learn more about the basic architecture of a Consul deployment.

»How does Consul work?

»Architecture overview

Consul is a distributed system designed to run on a cluster of nodes. A Consul node can be a physical server, cloud instance, virtual machine, or container. Connected together, the set of nodes Consul runs on is called a datacenter. A datacenter will have between 3 - 5 servers and many clients.

Consul datacenter

»Consul agent

Consul is available as a single binary and can be run as a long running daemon. A node running Consul binary is frequently referenced as a Consul agent. Consul can run in two modes, server or client. Server agents maintain a consistent state for Consul. Maintaining a consistent state includes many responsibilities, but at a high level, it consists of the following (but not limited to);

  • keep track of available services, their IP address and their current health and status
  • keep track of available nodes, their IP address and their current health and status
  • build a service catalog (DNS) that is aware of the service and nodes availability
  • maintain and update the K/V store
  • communicate updates to all agents (gossip protocol)

Clients are a lightweight process that runs on every node where services are running. Please visit the Consul agent documentation page to dive deeply into the Consul agent.

Application developers will often interact with Consul as a client. Applications are integrated with Consul by using 3rd party proxies such as Envoy. The sidecar is deployed alongside the application and the Consul agent.

The diagram below displays how Consul integrates with an application.

Consul overview image

»Consul and proxies

The data plane in a Consul service mesh is supported and owned by the proxies.

Applications leveraging Consul will point to localhost and direct all traffic (both incoming and outgoing) to the local interface. The proxy will open up ports on localhost and direct traffic from the application to other microservices. The proxy will also receive traffic and direct this traffic back to the application. The Consul agent (client) keeps the proxy up-to-date with information about the service mesh. This includes information such as what services are available (service discovery) and if the application can communicate with other services (service mesh).

In the example code below, there are two instances of the same application communicating with another service, the order service . The first example tab represents the traditional approach where the application is querying the API directly. The second example tab uses Consul and a proxy. Notice how the Consul example application is pointing to localhost instead of the API URL. This abstraction introduces new flexibility to the application. It allows for dynamic network behavior, such as a failover, without having to make application changes.

The proxy will send application traffic to the orders service, through the http://api.example/v1/orders endpoint, but this is configured through Consul. Suppose the target service becomes unavailable or requires failover to a backup instance. In that case, the proxy can handle these responsibilities through Consul configuration.

Traditional
# Go example
resp, err := http.Get("http://api.example/v1/orders")
if err != nil {
   log.Fatalln(err)
}

# Go example
resp, err := http.Get("http://api.example/v1/orders")
if err != nil {
   log.Fatalln(err)
}

# Go example
resp, err := http.Get("http://localhost/v1/orders")
if err != nil {
   log.Fatalln(err)
}

# Go example
resp, err := http.Get("http://localhost/v1/orders")
if err != nil {
   log.Fatalln(err)
}

The Consul agent provides many other benefits to the application and the proxy, such as generating the proxy configuration, creating x509 certificates for mTLS, and rotating the certificates dynamically. By delegating all networking responsibilities to the proxy, application developers can instead focus their attention on developing business logic. Please visit the Consul service mesh documentation page to learn more about the benefits Consul provides applications.

Info: Envoy has first-class integration with Consul. To learn more about Envoy and its integration with Consul, visit the Envoy documentation page.

»Next steps

This "Get Started" collection of HashiCorp Learn will help you build mental models to understand how Consul works with tutorials that you can run locally on your computer. Complete the tutorials in this section sequentially; some of them rely on the previous ones.

Continue to the next tutorial to learn how to use Consul.

Alternatively, you can get hands-on experience with one of the other Get Started tutorials for Consul on the other supported platforms.

stdin: is not a tty