website: replace serf with consul

This commit is contained in:
Armon Dadgar 2014-02-18 17:37:23 -08:00
parent 7b1883760d
commit 076c5f2043
2 changed files with 34 additions and 65 deletions

View File

@ -1,27 +1,27 @@
---
layout: "docs"
page_title: "Serf Protocol Compatibility Promise"
page_title: "Consul Protocol Compatibility Promise"
sidebar_current: "docs-upgrading-compatibility"
---
# Protocol Compatibility Promise
We expect Serf to run in large clusters as long-running agents. Because
We expect Consul to run in large clusters as long-running agents. Because
upgrading agents in this sort of environment relies heavily on protocol
compatibility, this page makes it clear on our promise to keeping different
Serf versions compatible with each other.
Consul versions compatible with each other.
We promise that every subsequent release of Serf will remain backwards
We promise that every subsequent release of Consul will remain backwards
compatible with _at least_ one prior version. Concretely: version 0.5 can
speak to 0.4 (and vice versa), but may not be able to speak to 0.1.
The backwards compatibility must be explicitly enabled: Serf agents by
The backwards compatibility must be explicitly enabled: Consul agents by
default will speak the latest protocol, but can be configured to speak earlier
ones. If speaking an earlier protocol, _new features may not be available_.
The ability for an agent to speak an earlier protocol is only so that they
can be upgraded without cluster disruption.
This compatibility guarantee makes it possible to upgrade Serf agents one
This compatibility guarantee makes it possible to upgrade Consul agents one
at a time, one version at a time. For more details on the specifics of
upgrading, see the [upgrading page](/docs/upgrading.html).
@ -36,36 +36,5 @@ upgrading, see the [upgrading page](/docs/upgrading.html).
<td>0.1</td>
<td>0</td>
</tr>
<tr>
<td>0.2</td>
<td>0, 1</td>
</tr>
<tr>
<td>0.3</td>
<td>0, 1, 2&nbsp;&nbsp;&nbsp;<span class="label label-info">see warning below</span></td>
</tr>
<tr>
<td>0.4</td>
<td>1, 2, 3&nbsp;&nbsp;&nbsp;<span class="label label-info">see warning below</span></td>
</tr>
</table>
<div class="alert alert-info">
<p>
<strong>Warning: </strong> Version 0.3 introduces support for dynamic ports, allowing each
agent to bind to a different port. However, this feature is only supported
if all agents are running protocol version 2. Due to the nature of this
feature, it is hard to detect using the versioning scheme. If ports are kept
consistent across the cluster, then protocol version 2 is fully backwards
compatible.
</p>
</div>
<div class="alert alert-info">
<p>
<strong>Warning: </strong> Version 0.4 introduces support for dynamic tags, allowing each
agent to provide key/value tags and update them without restarting. This feature is only supported
if all agents are running protocol version 3. If an agent is running an older protocol,
then only the "role" tag is supported for backwards compatibility.
</p>
</div>

View File

@ -1,67 +1,67 @@
---
layout: "docs"
page_title: "Upgrading Serf"
page_title: "Upgrading Consul"
sidebar_current: "docs-upgrading-upgrading"
---
# Upgrading Serf
# Upgrading Consul
Serf is meant to be a long-running agent on any nodes participating in a
Serf cluster. These nodes consistently communicate with each other. As such,
Consul is meant to be a long-running agent on any nodes participating in a
Consul cluster. These nodes consistently communicate with each other. As such,
protocol level compatibility and ease of upgrades is an important thing to
keep in mind when using Serf.
keep in mind when using Consul.
This page documents how to upgrade Serf when a new version is released.
This page documents how to upgrade Consul when a new version is released.
## Upgrading Serf
## Upgrading Consul
In short, upgrading Serf is a short series of easy steps. For the steps
below, assume you're running version A of Serf, and then version B comes out.
In short, upgrading Consul is a short series of easy steps. For the steps
below, assume you're running version A of Consul, and then version B comes out.
1. On each node, install version B of Serf.
1. On each node, install version B of Consul.
2. Shut down version A, and start version B with the `-protocol=PREVIOUS`
flag, where "PREVIOUS" is the protocol version of version A (which can
be discovered by running `serf -v` or `serf members -detailed).
be discovered by running `consul -v` or `consul members -detailed`).
3. Once all nodes are running version B, go through every node and restart
the version B agent _without_ the `-protocol` flag.
4. Done! You're now running the latest Serf agent speaking the latest protocol.
You can verify this is the case by running `serf members -detailed` to
4. Done! You're now running the latest Consul agent speaking the latest protocol.
You can verify this is the case by running `consul members -detailed` to
make sure all members are speaking the same, latest protocol version.
The key to making this work is the [protocol compatibility](/docs/compatibility.html)
of Serf. The protocol version system is discussed below.
of Consul. The protocol version system is discussed below.
## Protocol Versions
By default, Serf agents speak the latest protocol they can. However, each
new version of Serf is also able to speak the previous protocol, if there
By default, Consul agents speak the latest protocol they can. However, each
new version of Consul is also able to speak the previous protocol, if there
were any protocol changes.
You can see what protocol versions your version of Serf understands by
running `serf -v`. You'll see output similar to that below:
You can see what protocol versions your version of Consul understands by
running `consul -v`. You'll see output similar to that below:
```
$ serf -v
Serf v0.2.0
$ consul -v
Consul v0.1.0
Agent Protocol: 1 (Understands back to: 0)
```
This says the version of Serf as well as the latest protocol version (1,
in this case). It also says the earliest protocol version that this Serf
This says the version of Consul as well as the latest protocol version (1,
in this case). It also says the earliest protocol version that this Consul
agent can understand (0, in this case).
By specifying the `-protocol` flag on `serf agent`, you can tell the
Serf agent to speak any protocol version that it can understand. This
only specifies the protocol version to _speak_. Every Serf agent can
By specifying the `-protocol` flag on `consul agent`, you can tell the
Consul agent to speak any protocol version that it can understand. This
only specifies the protocol version to _speak_. Every Consul agent can
always understand the entire range of protocol versions it claims to
on `serf -v`.
on `consul -v`.
<div class="alert alert-block alert-warning">
<strong>By running a previous protocol version</strong>, some features
of Serf, especially newer features, may not be available. If this is the
case, Serf will typically warn you. In general, you should always upgrade
of Consul, especially newer features, may not be available. If this is the
case, Consul will typically warn you. In general, you should always upgrade
your cluster so that you can run the latest protocol version.
</div>