Introduction to Consul

    Consul solves the challenges that organizations of all sizes encounter with microservices architectures. This ranges from operating in various distributed environments and geographical locations, to meeting the need of securing all application traffic. The world is rapidly changing and evolving, so is the computing networking layer.

    Today’s network must quickly adapt and ensure communication is encrypted at all times. Consul enables organizations to embrace a zero trust model while scaling up. Consul can achieve all this while reducing the burden on both operators and developers through automation of crucial networking tasks

    Consul is a service mesh solution providing a full featured control plane with service discovery, configuration, and segmentation functionality. Each of these features can be used individually as needed, or they can be used together to build a full service mesh. Consul requires a data plane and supports both a proxy and native integration model. Consul ships with a simple built-in proxy so that everything works out of the box, but also supports 3rd party proxy integrations such as Envoy.

    Review the video below to learn more about Consul from HashiCorp’s co-founder Armon.

    • Service Discovery: Clients of Consul can register a service, such as or mysql, and other clients can use Consul to discover providers of a given service. Using either DNS or HTTP, applications can easily find the services they depend upon.

    • Health Checking: Consul clients can provide any number of health checks, either associated with a given service (“is the webserver returning 200 OK”), or with the local node (“is memory utilization below 90%”). This information can be used by an operator to monitor cluster health, and it is used by the service discovery components to route traffic away from unhealthy hosts.

    • KV Store: Applications can make use of Consul’s hierarchical key/value store for any number of purposes, including dynamic configuration, feature flagging, coordination, leader election, and more. The simple HTTP API makes it easy to use.

    • Multi Datacenter: Consul supports multiple datacenters out of the box. This means users of Consul do not have to worry about building additional layers of abstraction to grow to multiple regions.

    Consul is a distributed, highly available system. This section will cover the basics, purposely omitting some unnecessary detail, so you can get a quick understanding of how Consul works. For more detail, please refer to the .

    Every node that provides services to Consul runs a Consul agent. Running an agent is not required for discovering other services or getting/setting key/value data. The agent is responsible for health checking the services on the node as well as the node itself.

    The agents talk to one or more Consul servers. The Consul servers are where data is stored and replicated. The servers themselves elect a leader. While Consul can function with one server, 3 to 5 is recommended to avoid failure scenarios leading to data loss. A cluster of Consul servers is recommended for each datacenter.

    The servers maintain a catalog, which is formed by aggregating information submitted by the agents. The catalog maintains the high-level view of the cluster, including which services are available, which nodes run those services, health information, and more. How agents and the catalog interact can be found here.

    Components of your infrastructure that need to discover other services or nodes can query any of the Consul servers or any of the Consul agents. The agents forward queries to the servers automatically.

    • See to assess how it fits into your existing infrastructure.
    • Continue onwards with HashiCorp Learn to learn more about Consul and how to get Consul up and running.