status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

website: creating a cluster

This commit is contained in:
Mitchell Hashimoto 2014-04-14 12:47:55 -07:00
parent 5f50c80aef
commit cb1568b8b8
2 changed files with 41 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
website/source/intro/getting-started/join.html.markdown
View File

@ -1,20 +1,23 @@
---
layout: "intro"
page_title: "Join a Cluster"
page_title: "Consul Cluster"
sidebar_current: "gettingstarted-join"
---
# Join a Cluster
# Consul Cluster
In the previous page, we started our first agent. While it showed how easy
it is to run Consul, it wasn't very exciting since we simply made a cluster of
one member. In this page, we'll create a real cluster with multiple members.
By this point, we've started our first agent and registered and queried
one or more services on that agent. This showed how easy it is to use
Consul, but didn't show how this could be extended to a scalable production
service discovery infrastructure. On this page, we'll create our first
real cluster with multiple members.
When starting a Consul agent, it begins without knowledge of any other node, and is
an isolated cluster of one. To learn about other cluster members, the agent must
_join_ an existing cluster. To join an existing cluster, only needs to know
about a _single_ existing member. After it joins, the agent will gossip with this
member and quickly discover the other members in the cluster.
member and quickly discover the other members in the cluster. A Consul
agent can join any other agent, it doesn't have be an agent in server mode.
## Starting the Agents
@ -27,10 +30,12 @@ The node name must be unique and is how a machine is uniquely identified.
By default it is the hostname of the machine, but we'll manually override it.
We are also providing a bind address. This is the address that Consul listens on,
and it *must* be accessible by all other nodes in the cluster. The first node
will act as our server in this cluster.
will act as our server in this cluster. We're still not making a cluster
of servers.
```
$ consul agent -server -bootstrap -data-dir /tmp/consul -node=agent-one -bind=172.20.20.10
$ consul agent -server -bootstrap -data-dir /tmp/consul \
-node=agent-one -bind=172.20.20.10
...
```
@ -80,6 +85,33 @@ agents gossip with each other to propagate full membership information.
In addition to using `consul join` you can use the `-join` flag on
`consul agent` to join a cluster as part of starting up the agent.
## Querying Nodes
Just like querying services, Consul has an API for querying the
nodes themselves. You can do this via the DNS or HTTP API.
For the DNS API, the structure of the names is `NAME.node.consul` or
`NAME.DATACENTER.node.consul`. If the datacenter is omitted, Consul
will only search the local datacenter.
From "agent-one", query "agent-two":
```
$ dig @127.0.0.1 -p 8600 agent-two.node.consul
...
;; QUESTION SECTION:
;agent-two.node.consul. IN A
;; ANSWER SECTION:
agent-two.node.consul. 0 IN A 172.20.20.11
```
The ability to look up nodes in addition to services is incredibly
useful for system administration tasks. For example, knowing the address
of the node to SSH into is as easy as making it part of the Consul cluster
and querying it.
## Leaving a Cluster
To leave the cluster, you can either gracefully quit an agent (using

2
website/source/layouts/intro.erb
View File

@ -55,7 +55,7 @@
</li>
<li<%= sidebar_current("gettingstarted-join") %>>
<a href="/intro/getting-started/join.html">Join a Cluster</a>
<a href="/intro/getting-started/join.html">Consul Cluster</a>
</li>
<li<%= sidebar_current("gettingstarted-checks") %>>