docker containers<\/a> and therefore we have it installed in all the three nodes.<\/p>\nLet us first set up a consul container on consul-node1 with a –bootstrap-expect flag. The number associated with this flag will be the number of nodes required to start bootstrapping. If you give this flag in all the nodes either of it will start the bootstrap process. Alternatively, node that is assigned the flag will start in particular.<\/p>\n
[js]
\ndocker run -d -h consul-node1 -v \/mnt:\/data \\
\n -p 192.168.33.60:8300:8300 \\
\n -p 192.168.33.60:8301:8301 \\
\n -p 192.168.33.60:8301:8301\/udp \\
\n -p 192.168.33.60:8302:8302 \\
\n -p 192.168.33.60:8302:8302\/udp \\
\n -p 192.168.33.60:8400:8400 \\
\n -p 192.168.33.60:8500:8500 \\
\n -p 172.17.0.1:53:53\/udp \\
\n progrium\/consul -server -advertise 192.168.33.60 -bootstrap-expect 3
\n[\/js]<\/p>\n
In this command, 192.168.33.60 is the machine IP while\u00a0172.17.0.1 is the docker0 interface IP. When we see the logs of the container it shows:<\/p>\n
![\"consul1\"](\"\/blog\/wp-ttn-blog\/uploads\/2017\/02\/consul1.png\")
<\/p>\n
Similarly, when we see the UI of the consul we see no nodes appearing.<\/p>\n
![\"consul2\"](\"\/blog\/wp-ttn-blog\/uploads\/2017\/02\/consul2.png\")
<\/p>\n
Now run the consul containers on the two other machines with –advertise flag and –join flag. With –join flag we give the IP of the bootstrapping node, i.e, 192.168.33.60.<\/p>\n
[js]
\ndocker run -d -h consul-node2 -v \/mnt:\/data \\
\n -p 192.168.33.61:8300:8300 \\
\n -p 192.168.33.61:8301:8301 \\
\n -p 192.168.33.61:8301:8301\/udp \\
\n -p 192.168.33.61:8302:8302 \\
\n -p 192.168.33.61:8302:8302\/udp \\
\n -p 192.168.33.61:8400:8400 \\
\n -p 192.168.33.61:8500:8500 \\
\n -p 172.17.0.1:53:53\/udp \\
\n progrium\/consul -server -advertise 192.168.33.61 -join 192.168.33.60
\n[\/js]<\/p>\n
When the other container is up and running, we see the logs of the first container. You can see that it tries to join the cluster. However, since there are only two nodes, \u00a0bootstrap process has not yet begun.<\/p>\n
![\"consul3\"](\"\/blog\/wp-ttn-blog\/uploads\/2017\/02\/consul3.png\")
<\/p>\n
Next, run the third consul container on consul-node3 and observe the logs of the\u00a0first container. As you can see, the cluster leadership is complete and we have 3 node consul cluster functioning.<\/p>\n
[js]
\ndocker run -d -h consul-node3 -v \/mnt:\/data \\
\n -p 192.168.33.62:8300:8300 \\
\n -p 192.168.33.62:8301:8301 \\
\n -p 192.168.33.62:8301:8301\/udp \\
\n -p 192.168.33.62:8302:8302 \\
\n -p 192.168.33.62:8302:8302\/udp \\
\n -p 192.168.33.62:8400:8400 \\
\n -p 192.168.33.62:8500:8500 \\
\n -p 172.17.0.1:53:53\/udp \\
\n progrium\/consul -server -advertise 192.168.33.62 -join 192.168.33.60
\n[\/js]<\/p>\n
![\"consul4\"](\"\/blog\/wp-ttn-blog\/uploads\/2017\/02\/consul4.png\")
<\/p>\n
![\"consul5\"](\"\/blog\/wp-ttn-blog\/uploads\/2017\/02\/consul5.png\")
<\/p>\n
Consequently, when we run a docker container on consul-node3, it is not discovered by consul because we are not running any registrators. Thus we need to run 3 registrators for and on each node so that the data is in sync. These registrators give necessary information of the cluster to the consul master.<\/p>\n
[js]
\ndocker run -d –name=registrator1 –net=host –volume=\/var\/run\/docker.sock:\/tmp\/docker.sock gliderlabs\/registrator:latest consul:\/\/192.168.33.60:8500
\ndocker run -d –name=registrator2 –net=host –volume=\/var\/run\/docker.sock:\/tmp\/docker.sock gliderlabs\/registrator:latest consul:\/\/192.168.33.61:8500
\ndocker run -d –name=registrator3 –net=host –volume=\/var\/run\/docker.sock:\/tmp\/docker.sock gliderlabs\/registrator:latest consul:\/\/192.168.33.62:8500
\n[\/js]<\/p>\n
This will be done on all the nodes. As you can see, after running registrators on all nodes, the services are running perfectly.<\/p>\n
![\"consul6\"](\"\/blog\/wp-ttn-blog\/uploads\/2017\/02\/consul6.png\")
<\/p>\n
We are through with setting up Consul Multinode Cluster With Docker. I hope the blog was useful. Watch out this space for more such knowledge.<\/p>\n","protected":false},"excerpt":{"rendered":"
Consul is a service discovery and a configuration system tool used to discover the services running on multiple nodes. It is both distributed and highly available. It provides a powerful interface to get a better picture of infrastructure and services running on them. Consul gives us a variety of features that help to determine our […]<\/p>\n","protected":false},"author":969,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":67},"categories":[2348,1],"tags":[178,4435,4494,1891,1892,1883],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/46234"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/969"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=46234"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/46234\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=46234"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=46234"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=46234"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"consul-logo\"](\"\/blog\/wp-ttn-blog\/uploads\/2017\/02\/consul-logo.png\"){kind=logo}
<\/p>\n