Installing Consul on Linux/Centos
Consul is a distributed, highly available service discovery and configuration system. It can be used to present your services and ports in a flexible interface which the clients can access to have details of complete infrastructure. It has different features to keep the details uptodate, highly available and easily queryable.
Few of them are, key value store, dns/http api endpoints, health checks, tagging systems etc
In this article i will explain how to setup a single node consul and do service registration and discovery. Consul cluster setup will be explained in another article at here
Prerequisites
To start with we will be configuring one server and client on same machine
Download
The consul project’s page provides download links to binary packages for Windows, OS X, and Linux. Go to the link and download the package matching your architechture and OS
| 1 2 | wget https://releases.hashicorp.com/consul/0.7.0/consul_0.7.0_linux_amd64.zip unzip consul_0.7.0_linux_amd64.zip |
Copy the resulting file to /usr/local/bin
| 1 | cp consul /usr/local/bin/ |
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | consul usage: consul [—version] [—help] [] Available commands are: agent Runs a Consul agent configtest Validate config file event Fire a new event exec Executes a command on Consul nodes force–leave Forces a member of the cluster to enter the “left” state info Provides debugging information for operators join Tell Consul agent to join cluster keygen Generates a new encryption key keyring Manages gossip layer encryption keys leave Gracefully leaves the Consul cluster and shuts down lock Execute a command holding a lock maint Controls node or service maintenance mode members Lists the members of a Consul cluster monitor Stream logs from a Consul agent operator Provides cluster–level tools for Consul operators reload Triggers the agent to reload configuration files rtt Estimates network round trip time between nodes version Prints the Consul version watch Watch for changes in Consul |
We’ll start the Consul agent in development mode for now. This mode is useful for bringing up a single-node Consul environment quickly and easily. This setup is not recommended in production environment , it doesn’t persist any state and data loss in obvious.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | consul agent –dev == Starting Consul agent... == Starting Consul agent RPC... == Consul agent running! Version: ‘v0.7.0’ Node name: ‘thisnode.test.com’ Datacenter: ‘dc1’ Server: true (bootstrap: false) Client Addr: 127.0.0.1 (HTTP: 8500, HTTPS: –1, DNS: 8600, RPC: 8400) Cluster Addr: 127.0.0.1 (LAN: 8301, WAN: 8302) Gossip encrypt: false, RPC–TLS: false, TLS–Incoming: false Atlas: |
You can see agent started in server mode and taken the leadership role ( as its a single node setup)
Run the following command, to see the members of the cluster
| 1 2 3 4 5 | consul members Node Address Status Type Build Protocol DC thisnode.test.com 127.0.0.1:8301 alive server 0.7.0 2 dc1 |
As this is a single node setup, you will see only one member
Registering Services to Consul
Now we will register our first service and query that service.
There are two ways to do this
1. service definition
2. calling http api
We will use the first way to do this
First, create a directory for Consul configuration , where we keep all the service configurations , which in turn loaded by consul
| 1 2 3 | mkdir /etc/consul.d cd /etc/consul.d/ |
Create a new file web1.json, with following content
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | { “service”: { “name”: “webserver”, “port”: 80, “tags”: [“nginx”, “demonstration”], “check”: { “script”: “curl localhost:80 > /dev/null 2>&1”, “interval”: “10s” } } } |
This configuration has many fields
1 . name : Name of the service
2. Port : Port where service listens
3. check : All the health checks configuration goes here
Now we can restart the consul agent, kill any existing agent processes and start it using
| 1 | consul agent –dev –config–dir=/etc/consul.d |
Consul will pick the config files from /etc/consul.d and start the agent
Now we can query the services, it can be done using either dns or http endpoint
DNS
By default, all DNS names are always in the consul namespace, though this is configurable. The service subdomain tells Consul we’re querying services, and the NAME is the name of the service.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | # dig @127.0.0.1 -p 8600 webserver.service.consul SRV ; <<>> DiG 9.8.2rc1–RedHat–9.8.2–0.47.rc1.el6_8.2 <<>> @127.0.0.1 –p 8600 webserver.service.consul SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; –>>HEADER< ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;webserver.service.consul. IN SRV ;; AUTHORITY SECTION: consul. 0 IN SOA ns.consul. postmaster.consul. 1477321834 3600 600 86400 0 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#8600(127.0.0.1) ;; WHEN: Mon Oct 24 20:40:34 2016 ;; MSG SIZE rcvd: 92 |
The above command retuned empty results because health checks are failing, there is nothing listening on port 80. Now we will start some service which listen on port 80.
For example, i will install httpd server and start it
| 1 2 3 | yum install httpd |
Start it with
| 1 2 3 | /etc/init.d/httpd start |
And make sure its running and listening on port 80
| 1 2 3 4 | # netstat -nap |grep :80 |grep LISTEN tcp 0 0 :::80 :::* LISTEN 22959/httpd |
Now, you can query DNS server again using same command
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | # dig @127.0.0.1 -p 8600 webserver.service.consul SRV ; <<>> DiG 9.8.2rc1–RedHat–9.8.2–0.47.rc1.el6_8.2 <<>> @127.0.0.1 –p 8600 webserver.service.consul SRV ; (1 server found) ;; global options: +cmd ;; Got answer: ;; –>>HEADER< ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;webserver.service.consul. IN SRV ;; ANSWER SECTION: webserver.service.consul. 0 IN SRV 1 1 80 testnode.com.node.dc1.consul. ;; ADDITIONAL SECTION: testnode.com.node.dc1.consul. 0 IN A 127.0.0.1 |
Now you can see the results in the answer section contains the details of service, port and host .
Anyone can make this query and use these results to access that particular service. This is very useful in a microservice based architecture, where applications and ports are assigned dynamically. Whenever an application starts, it registers to the service which assigned to it. Other programmes/agents which want to use this service, can simply query the dns endpoint to find the available IP and Ports, which application exposed.
I will explain Consul clustering, in next article. Let me know if you face any issue.