Register a healthy web service
Create a service definition file for a web app on port 8080 with an HTTP health check every 10s. Register it and verify it appears healthy in the catalog.
DevOps & Tooling / Knowledge library
HashiCorp Consul
service discovery and networking control plane
Why learn HashiCorp Consul?
Consul helps distributed systems find each other, stay health-aware, and enforce service-to-service security policies across VMs, containers, and multiple environments.
Where it came from
2014: HashiCorp released Consul for service discovery and health checking. Consul included a KV store and distributed coordination primitives early on. Connect introduced service mesh capabilities, including mTLS and intentions. Consul expanded with Kubernetes integrations and multi-cluster networking patterns like peering.
- 2014: HashiCorp released Consul for service discovery and health checking.
- Consul included a KV store and distributed coordination primitives early on.
- Connect introduced service mesh capabilities, including mTLS and intentions.
- Consul expanded with Kubernetes integrations and multi-cluster networking patterns like peering.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Create a service definition file for a web app on port 8080 with an HTTP health check every 10s. Register it and verify it appears healthy in the catalog.
- Set default-deny for a namespace, then allow only frontend -> payments traffic. Validate blocked and allowed paths with test requests.
- Given two services with failing mTLS traffic, find whether the issue is ACL token scope, sidecar registration, or intention policy. Provide a fix plan in 5 steps.
- Establish cluster peering between staging and shared-services clusters, then resolve a remote service name from staging. Document required ports, trust, and policy controls.
- Design a rollout checklist for enabling Consul in production: TLS, ACL bootstrap, backup/restore, health SLOs, and failure testing.
More ways to practice
Lock down service access with intentions
Set default-deny for a namespace, then allow only frontend -> payments traffic. Validate blocked and allowed paths with test requests.
Troubleshoot mesh communication failure
Given two services with failing mTLS traffic, find whether the issue is ACL token scope, sidecar registration, or intention policy. Provide a fix plan in 5 steps.
Peer two Consul clusters
Establish cluster peering between staging and shared-services clusters, then resolve a remote service name from staging. Document required ports, trust, and policy controls.
Production readiness drill
Design a rollout checklist for enabling Consul in production: TLS, ACL bootstrap, backup/restore, health SLOs, and failure testing.
Documentation and sources
- Consul documentation (developer.hashicorp.com)
- Consul tutorials (developer.hashicorp.com)
- Service mesh (Connect) docs (developer.hashicorp.com)
- ACL system docs (developer.hashicorp.com)
- Consul GitHub repository (github.com)
Catalog research notes
- Consul Dataplane is now a common default path for service mesh sidecar operations.
- Cluster peering is a key pattern for cross-cluster service discovery without full WAN federation.
- Managed Consul offerings continue expanding guided workflows for upgrades, ACLs, and observability.
- Recent platform guidance emphasizes stronger default security with TLS and ACL-first setups.
Connect the ideas
Explore next
Real World Example
Dynamic Service Discovery for Retail Inventory
A regional retail chain managing distributed inventory microservices across hybrid cloud environments.
The business problem
Manual IP address management and static configuration files cause frequent service outages when inventory nodes scale or migrate, leading to failed customer orders.
How this topic solves it
Consul provides a centralized service registry and health checking mechanism that allows services to dynamically discover each other's network locations without manual intervention.
- Deploy Consul server agents in a cluster to maintain the global service registry state.
- Install Consul client agents on every node running inventory microservices to facilitate local communication.
- Define service configurations including health checks to ensure only operational instances are discoverable.
- Register inventory services with the local Consul agent to enable automatic catalog updates.
- Configure applications to query the Consul DNS interface or HTTP API for real-time service locations.
Explains how inventory services register and discover peers via the Consul agent.
Application workload
Local node daemon
Global registry state
- Inventory Service → registers service → Consul Client Agent
- Consul Client Agent → syncs catalog → Consul Server Cluster
- Inventory Service → queries peer location → Consul Client Agent
Expected business outcome
Inventory microservices achieve seamless connectivity and automated recovery, as the network topology updates instantly when instances are added or removed.
Limitations and checks
The primary trade-off is the dependency on the Consul control plane; if the server cluster becomes unreachable, new service lookups will fail, which can be monitored by checking the health status of the Consul server nodes via the HTTP API.