FAQ

Service Registry & Health Monitoring with Consul

Learn how Consul provides service discovery in a service-based architecture.

Speakers

  • Jake Lundberg
    Jake LundbergField CTO, HashiCorp

Transcript

I am Jake Lundberg from the solutions engineering group at HashiCorp. I'm here to talk to you about service discovery and health monitoring for Consul.

Challenges with tracking dynamic services

At its core, Consul is a service discovery and servicing networking tool. Some of the service registry challenges that it addresses come down to how people would configure their systems in previous iterations of their service delivery techniques.

Configuration could go anywhere from people logging things inside of spreadsheets to manually controlling any of their load balancing configurations—through either files or direct API calls—and then some platform-specific tools generally within UI capabilities within those platforms. When it comes to cloud operations, each cloud has its own specific way of configuring those cloud tools.

After delivering Consul, you have the capabilities of having a highly dynamic system that updates any of the service registries on its own. It allows you to understand things like what services are running inside of your environment, where the location of those things are inside of your service network, what the status and health status of those services are, and the ability to understand the topology of your applications across platforms and regions.

How does service registry work within the system?

The very first step of a service registry is that any of your applications that are registering themselves can either use configuration files or API calls to notify Consul that they are alive, and then give them information about health checks to determine what the health of those applications are.

Once an application comes alive, it will automatically register itself with Consul through the local Consul agent. Then as new services continuously come alive, they will automatically register themselves with Consul.

When a consuming service needs to find one of these downstream services, all it has to do is either a basic DNS check or lookup via an API call to the Consul agent or back to the Consul servers. Once that discovery process is done, a healthy node will be returned to the querying instance with an IP address in a port for the location of the destination service.

Once the consuming service has access to that, it can connect directly to the target service. This is slightly different than a load balancing situation where the load balancer takes the connection and automatically determines where to send the traffic. In this instance, the consuming service connects directly to the target service, as opposed to going through an intermediary layer.

In the event of service failures, Consul will automatically prune any of the unhealthy services so that any kind of consuming service will automatically connect to a viable and healthy service on the upstream.

More resources like this one

  • 3/15/2023
  • Case Study

Using Consul Dataplane on Kubernetes to implement service mesh at an Adfinis client

  • 1/20/2023
  • FAQ

Introduction to Zero Trust Security

  • 1/4/2023
  • Presentation

A New Architecture for Simplified Service Mesh Deployments in Consul

  • 12/31/2022
  • Presentation

Canary Deployments with Consul Service Mesh on K8s