This article will focus on the most frequently used Consul terms and then explain the story behind the launch command to prepare for building a Consul cluster.

Agent Consul A process running in the back of the Agent Consul cluster is an Agent. The agent is started on Consul Agent. The agent can run in client or server mode. Because each node in a cluster must have an agent, it is easier to call a node a client or a server. All proxies can have DNS or HTTP interfaces that are responsible for health checks and keeping services in sync.

Client The Client is the proxy that forwards all RPC requests to the server. The client is relatively stateless. The only daemon the client runs is to participate in the GOSSIP pool of the LAN. This activity has minimal resource overhead and consumes only a small amount of network bandwidth.

The Server Server is an agent with an extended set of responsibilities, including participating in Raft mediation, maintaining cluster state, responding to RPC requests, exchanging WAN Gossip with other data centers, and forwarding queries to the cluster leader or remote data center.

The Datacenter is a private, low latency, high bandwidth network environment. This does not include communications across the public network, of course, but for our purposes, multiple available areas within a single EC2 area will be considered part of a single data center.

Consensus protocol is the Consensus protocol and transaction order for the cluster to elect the leader. Since these transactions apply to finite state machines, our definition of consistency means consistency of a replicated state machine. Consensus is described in more detail at Wikipedia, and a later article will talk about Consul’s implementation.

Gossip Consul is built on top of Serf, which provides a complete Gossip protocol that can be used for a variety of purposes. Serf provides functions such as member management, fault detection, and event broadcasting. We will focus on the Gossip protocol later. Gossip involves random node-to-node UDP traffic.

LAN Gossip refers to the LAN Gossip pool, which contains nodes that are all on the same LAN or data center.

WAN Gossip refers to the WAN Gossip pool that contains only the server. These Consul servers are located in different data centers and generally communicate over the Internet or wan.

RPC remote procedure call. A request/response mode that allows clients to make requests to the server.

Serf Serf, like Consul, is an open source project from Hashicorp that implements the decentralized Gossip protocol, which defines a virus-like message transmission process. Some well-known open source projects, such as Docker and Consul, rely on SERFs to implement the core components of network management and service discovery. However, the serFs behind them seem to be poorly understood. On the one hand, their complex theories and incomplete documentation are daunting. On the other hand, the gossip protocol’s naturally weak data consistency limits serF usage scenarios.

To create a data center, create a server cluster. The recommended way to create a server is to use the -bootstrap-expect option. This option is the expected number of Consul server nodes to be created and automatically boots when that many servers are available. To avoid inconsistencies and splintering (a cluster that multiple servers treat as the leader), it is necessary to specify the same value for -bootstrap-expect, or none at all on all servers. Only servers with specified values will attempt to boot the cluster.

Suppose you are starting a cluster of three service nodes. Nodes A, B, and C can be started by supplying the -bootstrap-expect 3 identifier, respectively. After the node is started, you can see a warning message in the service output.

[WARN] raft: EnableSingleNode disabled, and no known peers. Aborting election.
Copy the code

A warning indicates that the node expects two peers but does not know it yet. This command will be used in the next article on how to start a three-point Consul cluster.

Start command following an article

docker run \
    -d \
    -p 8500:8500 \
    -p 8600:8600/udp \
    --name=badger \
    consul agent -server -ui -node=server -bootstrap-expect=1
Copy the code

The bootstrap-expect value is set to 1 when Consul node is created. This is a one-node Consul cluster. Since it is an experimental course, 1 and 1 nodes can be used as a service, but not in the production environment

Port A server Consul node requires a maximum of six ports to function properly. Some ports use TCP, UDP, or both.

Before running Consul, you should make sure you have access to the following bound ports.

Port Function DNS Interface Used to resolve DNS queries

The HTTP API client requests the server through the HTTP API

The HTTPS API (optional) is disabled by default, but port 8501 is used by many tools by default.

GRPC API (Optional) Currently, gRPC is only used to expose the xDS API to Envoy proxies. It is off by default, but port 8502 is used by various tools by default. The default is 8502 in -dev mode.

Serf LAN is used to process the Gossip protocol in a LAN. All agents need it.

Serf WAN server WAN servers use it to propagate to other servers over the WAN. Starting from Consul 0.8, WAN connection flooding requires Serf WAN port (TCP/UDP) to listen on WAN and LAN interfaces.

RPC servers are used to handle requests from other agents.

In summary, this article introduces terminology and startup command options for Consul, as well as ports that you will use to learn about Consul paving the way in this article.