Hi, my name is Andre and today, I'd like to
show you how to do service discovery with
Consul comes as a simple zip file, it contains
a single binary which is used for both the
client and the server.
And in order to prepare for running the server,
we have to create a couple of directories...
One for the service definitions and another
one for runtime data, where Consul server
and clients will store connected agents, provided
services on the agents, encryption keys, all
the runtime data the actual Consul infrastructure
needs to have to run.
Now let's create these two directories and
dive right in and start the Consul server.
We're starting it with the option "-server"
and, in our case, "-bootstrap-expect 1" which
tells it to only expect one Consul server,
not a quorum of three or five servers which
could handle network partitions, but for this
video, we're using one server. And we tell
it where to find service definitions and where
to store its runtime data and that's about
it.
See.. It's started up in a cluster without
a master and became elected the master.
With "consul members", we can have a look
at the cluster and its members. Right now,
there's only our freshly started Consul master
which is a server in this cluster and let's
add a couple of clients now.
In the top window, you can see the log output
from the master, in the middle window, now
we're creating the data directories for our
Consul client.
And we're starting the client with just the
data and configuration directories. You can
also add the "-join" and the hostname of the
Consul master option, but we'll do this by
a command on a running client to show you
that you can also remote control the running
Consul service.
Now here we're going to join the cluster running
on consul-master. There we go, that's all
it takes. "consul join" and the name of either
one or multiple Consul master servers and
looking at the Consul members, we now see
our client connected to the Consul cluster.
Now let's do the same for another host...
Do the same steps: Create the directory for
the service definitions, create a directory
for the runtime data and start the client
and have it join the cluster running on consul-master
afterwards.
Now we've got two clients connected to our
Consul master. We'll see that we've got a
Consul server and we got two clients, all
of them running in the datacentre "dc1". You
can also state an option that you've got services
running in different datacentres. So in the
case of a network partition, you can select
hosts just by the datacentre they're located
in and you might have asked yourself how to
use the actual Consul client, you don't even
have to, because Consul provides an easy to
use DNS interface.
You can query, well, for example you can query
hostnames. Let's query one of the Consul clients'
IP addresses.. There you go. And we could
have queried services, but there aren't any
yet. So let's create a service.
I've installed an nginx webserver on both
the clients, it will render out a differently
coloured website stating the name of the server
you're on.
So that's why we use a tag of "colourserver",
I could have tagged them with "yellow" or
"purple" which are the colours they will be
using, but for now, it's just "colourserver".
And there we have it, it's registered with
the Consul daemon. Let's query for a service
named "webserver" on our Consul server and
there you have it, we get the IP address of
our Consul client.
You can also request a SRV record which will
include a bit more information, it will contain
the name of the client running the service,
the IP address running the service, the port
number of the running service and even health
status which we can fill with a customised
health check which we won't cover in this
video, but you can also do health checks of
services and they will either register or
deregister depending on the health check outcome.
So if you've got a non-functional service,
it will actually deregister the service from
the Consul environment.
Now let's add the same service to the other
server, so we can have a look at what happens
with the DNS interface if you've got the same
service on two machines.
Also send the hangup signal to the Consul
daemon to reread the configuration and now
we've got two clients providing the same service
"webserver" and there you have it, you get,
just like any normal DNS, you get a couple
of servers registered to the same name. If
you fetch the SRV record, you get a couple
of servers running the same service.
Instead of DNS, you can also use HTTP, it
also has an HTTP api which will return JSON
objects with the requested information.
Using it from the commandline, you can add
a query parameter "pretty" which will pretty
format the JSON and well, there we queried
all the services available in our cluster,
we only have the "webserver" service and if
we dig a little deeper and query the actual
"webserver" service, we get the nodes associated
with the "webserver" service.
In this case, our consul-client1 and consul-client2.
So this is how you query the data in your
Consul daemon. You can not only register services,
but you can also add arbitrary key/value pairs,
so you could, well, if you've got some weighting
included in some loadbalancer, you could add
the number of worker threads in there, so
you can give an appropiate weight to the server.
Now in order to show you that you can already
use this data with existing services, I've
also installed an nginx server on the Consul
master, I've added a couple of configuration
directives.. For example, I've changed the
resolver to be the Consul server or the DNS
interface of the Consul server, I've set the
"consul-webserver" to one of the Consul DNS
entries, in this case the "webserver" service
and using a variable for a proxy backend in
nginx forces it to do a DNS lookup every time
it's accessed.
And now let's have a look at this in the browser.
We'll start a Firefox browser and just open
the website on the Consul master where this
loadbalancing nginx is installed and there
you have it, consul-client1, consul-client2,
yellow, purple, these are the two "colourservers"
and, well, not on every reload, but in general,
you get 50% of requests on one side, 50% on
the other side, just like round-robin DNS
entries. So this was just a quick introduction
on how to get started with the Consul service
discovery daemon... In the background you
can see that it switches arbitrarily, but
more or less 50/50 between the two backend
servers and in the next video, I'll be showing
you how you can use the Consul service discovery
with services that either don't support DNS
lookups on every request or they don't support
the HTTP API of Consul, there are ways around
that, because there is also a service called
"consul-template" which will query the Consul
daemon in regular intervals and when things
change, it will roll out a new template and
restart a service or reload a service or execute
arbitrary commands.
So for now, thanks for watching. If you like
this video, like it, subscribe to my channel
or just come back in a couple of days when
I put up the "consul-template" video.
