DevOps Tools 101 is a series of posts outlining in easy to digest form, the tools available and in use by the DevOps community.
Today we’ll be learning about Consul by Hashicorp.
The Official Description
From Hashicorp’s site
Consul is a service mesh solution providing a full featured control plane with service discovery, configuration, and segmentation functionality.
The Breakdown
service mesh solution - a solution that allows individual services to discover and communicate quickly/securely/reliably with each other
full featured control plane - central control mechanism that can do a lot of stuff
service discovery - services like an API can be discovered and made available to other services in the mesh
[service] configuration - services can be configured from a centralized configuration store
[service] segmentation functionality - services can be separated from each other and have communication rules applied to the traffic between them
The Explanation
Hashicorp’s co-founder Armon Dadgar has a really good video that explains Consul but is also 15 minutes long (well worth a watch though). We’re going to try and summarize and explain it a little quicker.
As we now know, Consul is a service mesh solution that offers a few key functionalities: service discovery, configuration, and segmentation.
In order for it to accomplish this, Consul runs an agent on each of the nodes/servers in a datacenter (on-prem or cloud-based). This agent is responsible for communicating with the services available and enabling the functionalities we looked at above.
Service Discovery
When an instance of a service starts, the agent registers it with the Consul registry and makes it available for traffic. If service A wants to communicate with service B, it queries the registry, which returns one instance of the service, and communicates directly with that instance.
The agent also maintains health checks for services and nodes so if that instance of service B should go down or fail a health check, the agent will report it to the registry and it will no longer be returned when a query is made for service B.
Service Configuration
Each service has some configurations that might be different from other services in the mesh but there might be some that are shared between them (something like a database port or whether the database is in maintenance mode).
Consul can make this available in a centralized key/value store and push it out to each of the services’ configurations. This saves us from having to make the same config change to each service and push it out manually ourselves.
Service Segmentation
We have all of these services running and assuming that they have network connectivity, they can communicate without issue. However, just because they can talk to each other, doesn’t mean that they should be able to talk to each other. Consul uses a component called Connect to address this problem.
Each of our services will have a proxy that runs alongside it (known as a sidecar) and it will handle all communication to and from that service. This proxy verifies TLS certificates for encrypted communication and enforces the policy for service communication maintained by Connect (these policies are called intentions).
If service A wants to communicate with service B, the proxy of service B will verify the certificate of service A and then check if there is an intention from Connect that allows this traffic.
The Alternatives
Many people are working to solve the same problems which means that each problem will more than likely have a multitude of available solutions. Here are a few competing products to Consul.
Hashicorp also has a set of comparison pages that discuss the alternatives to and pros/cons of using Consul versus the other tools.