Consul is a service discovery system that provides a microservice style interface to services, service topology and service health. With service discovery you can look up services which are organized in the topology of your datacenters. Consul uses client agents and RAFT to provide a consistent view of services. Consul provides a consistent view of configuration as well also using RAFT. Consul provides a microservice interface to a replicated view of your service topology and its configuration. Consul can monitor and change services topology based on health of individual nodes. Consul provides scalable distributed health checks. Consul only does minimal datacenter to datacenter communication so each datacenter has its own Consul cluster. Consul provides a domain model for managing topology of datacenters, server nodes, and services running on server nodes along with their configuration and current health status. Consul is like combining the features of a DNS server plus Consistent Key/Value Store like etcd plus features of ZooKeeper for service discovery, and health monitoring like Nagios but all rolled up into a consistent system. Essentially, Consul is all the bits you need to have a coherent domain service model available to provide service discovery, health and replicated config, service topology and health status. Consul also provides a nice REST interface and Web UI to see your service topology and distributed service config. Consul organizes your services in a Catalog called the Service Catalog and then provides a DNS and REST/HTTP/JSON interface to it. To use Consul you start up an agent process. The Consul agent process is a long running daemon on every member of Consul cluster. The agent process can be run in server mode or client mode. Consul agent clients would run on every physical server or OS virtual machine (if that makes more sense). Client runs on server hosting services. The clients use gossip and RPC calls to stay in sync with Consul. A client, consul agent running in client mode, forwards request to a server, consul agent running in server mode. Clients are mostly stateless. The client does LAN gossip to the server nodes to communicate changes. A server, consul agent running in server mode, is like a client agent but with more tasks. The consul servers use the RAFT quorum mechanism to see who is the leader. The consul servers maintain cluster state like the Service Catalog. The leader manages a consistent view of config key/value pairs, and service health and topology. Consul servers also handle WAN gossip to other datacenters. Consul server nodes forwards queries to leader, and forward queries to other datacenters. A Datacenter is fairly obvious. It is anything that allows for fast communication between nodes, with as few or no hops, little or no routing, and in short: high speed communication. This could be an Amazon EC2 availability zone, a networking environment like a subnet, or any private, low latency, high

1. CONSUL
Consul at a glance.
!
The microservices architecture service discovery engine
!
Enabling reactive programming by providing a reliable list of nodes participating in a cluster

2. Consul provides a consistent view of services and
configuration

3. CONSUL
• Service Discovery
• Health
• Config

4. Consul uses a microservices architecture to provide
reliable service discovery and health monitoring

5. CONSUL
• Consul provides service discovery
• Consul provides a consistent view of services
• Consul provides a consistent view of configuration
• Consul uses a microservice interface to a replicated view of your
topology and its configuration
• Consul can monitor and change services topology based on
health

6. FEATURES
• scalable distributed health checks
• minimal dc to dc communication
• event system
• domain model for managing topology of datacenters,
server nodes, and services running on server nodes
along with their configuration

7. CONSUL LIKE
• DNS server plus Consistent Key/Value Store +
ZooKeeper + Nagios + … = Consul
• All the bits you need in a coherent model available
to provide service discovery and replicated config

8. UI

9. SERVICES IN CATALOG
• available via DNS
• available via REST interface
• Consul is a microservice architecture
• HTTP
• JSON

10. AGENT
• Long running daemon on every member of Consul
cluster
• Client or server mode
• Client runs on server hosting services
• All nodes run an agent
• Stays in sync, interface with REST and DHCP

11. CLIENT
• Agent that forwards request to server
• Mostly stateless
• Client does LAN gossip (low traffic)

12. SERVER
• Server also agent with more tasks
• RAFT quorum, who is leader/master
• Maintain cluster state
• Handles WAN gossip to other datacenters
• Forwards queries to leader/master
• Forward queries to other datacenters

13. DATACENTER
• Datacenter - obvious?
• EC2 availability zone
• Networking environment
• Private, low latency, and high bandwidth
• Fast between nodes, no hops, little routing, high speed

14. CONSENSUS
• Agreement on who is the leader
• Transactional finite state machine
• Replicated Log, FSM, Peer Set (who gets the replicated log),
Quorum (majority of peers agree), Committed Entry,
Leader
• End Result: Consistent view of configuration and live
services

15. GOSSIP
• Consul is built on top of Serf,
• Serf is a full gossip protocol
• Serf provides membership, failure detection, and
event broadcast mechanisms
• Clustering of server nodes

16. LAN,WAN,AND RPC
• LAN Gossip -
• LAN gossip pool,
• all agent nodes (client and server) on same local network or datacenter
• WAN Gossip -
• WAN gossip pool
• Only agent servers
• Servers per datacenter (3 to 5 for redundancy per DC)
• WAN gossip is used to communicate over public internet or wide area network
• RPC - Remote Procedure Call. Request / response mechanism allowing a client to make a request of a
server.

17. CONSUL
Image from
www.consul.io and
property of HashiCorp

18. AGENT RESPONSIBILITIES
• Maintains its
• set of service
• check registrations
• health information
• Updates
• health checks
• local state

19. CATALOG
• Backs Consuls service discovery
• Catalog is the service catalog
• Aggregates information submitted by agents.
• Maintains topology view of cluster,:
• Services available,
• Nodes which run those services (Node = Client Agent),
• Health information,
• Services and checks in catalog have less information than agent view
• Catalog is maintained only by server nodes (server agents).
• Catalog is replicated via Consul Consensus (RAFT, Serf)

20. AGENTSVS. CATALOG
• Local agent state (agent client node) is different than catalog state (agent server
node)
• Local Agent notifies Catalog of changes. Updates are synced right away.
• Agents check to make sure its view of the world matches the catalog, and if not the
catalog is updated
• Example: Registers a new service check with agent,
• Agent notifies catalog that this service check exists
• When a check is removed from the agent, it is removed from catalog

21. AGENTSVERSUS CATALOG 2
• If Agents run health checks, and status changes, then update is sent to catalog
• Agent is the authority of that node, and the services that exist on that node
• Scope
• Agent = Server orVirtual Machine
• Catalog = single datacenter, local area network, EC2 availability zone
• Changes are also synchronized periodically every minute to ten minutes

22. CONSUL COMMAND LINE
-server
for server
mode

23. STARTING UP A NEW SERVER
• Expect min amount of servers for bootstrap
$ consul agent -server -data-dir=“/opt/git/dc1" -bootstrap-expect 5

24. HTTP / JSON API ENDPOINTS
• kv - key value
• agent - api for dealing with agent
• catalog - dealing with datacenter catalog
• health - show health checks
• sessions, events, acl, status, etc.

25. CONFIG FILES
• config files can be stored locally and used to
bootstrap config of consul

26. SERVICE DEFINITION
Default check is dead man
switch or tll

27. HEALTH CHECKS
• Dead man switch,
• time to live, you have to dial in with status update every X
• HTTP ping every N time
• HTTP Code 200 - 299 = PASS
• HTTP Code 429 = WARN
• anything else = FAIL
• Run a script every N:
• process 0 = pass,
• process 1 = warn,
• anything else = FAIL

28. SCRIPT CHECK

29. HTTP CHECK

30. DEAD MAN SWITCH CHECK

31. RPC PROTOCOL
• All command line options available viaTCP/
MsgPack
• MsgPack = binary JSON more or less

32. REGISTERING EXTERNAL
SERVICES
External registry plus HTTP health check = integration
of service that has no idea that Consul exists = Legacy
integration of services = service discovery for legacy
services

33. WHAT WE HAVE DONE WITH
CONSUL
• wrote java microservices lib that uses consul for service discovery
• Blog: Using Consul from QBit, the Java, JSON,WebSocket and REST
microservice library, for health monitoring, clustering and service discovery
• used consul to implement clustered, replicated event bus for qbit
• Create general purpose service discovery that uses it
• Used general purpose service discovery to build distributed/clustered stats
service to implement things like client application id rate limiting at high-
speeds

34. THANKYOU
http://www.linkedin.com/in/
rickhigh/en