luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Documentation pass 

I was reviewing some docs and found a few issues.

1. Fixed some spelling mistakes.
2. Re-formatted some paragraphs.
3. Changed some potentially loaded language.
4. Fixed some grammar issues.
5. Tried to consistently use syntax-highlighting.
6. Fixed post-period spacing.
7. Fixed some formatting issues and inconsistency.
8. All "notes" are either proper notes or re-written.
This commit is contained in:
James Turnbull 2016-11-25 11:00:02 -05:00
parent 861ebd5971
commit dd4918fd16
28 changed files with 425 additions and 385 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
website/source/docs/agent/basics.html.markdown
View File

@ -124,11 +124,8 @@ In the case of a network failure, some nodes may be unreachable by other nodes.
In this case, unreachable nodes are marked as _failed_. It is impossible to distinguish
between a network failure and an agent crash, so both cases are handled the same.
Once a node is marked as failed, this information is updated in the service catalog.
Note: there is some nuance here since this update is only possible if the servers can
still [form a quorum](/docs/internals/consensus.html). Once the network recovers
or a crashed agent restarts the cluster will repair itself and unmark
a node as failed. The health check in the catalog will also be updated to reflect
this.
-> **Note:** There is some nuance here since this update is only possible if the servers can still [form a quorum](/docs/internals/consensus.html). Once the network recovers or a crashed agent restarts the cluster will repair itself and unmark a node as failed. The health check in the catalog will also be updated to reflect this.
When a node _leaves_, it specifies its intent to do so, and the cluster
marks that node as having _left_. Unlike the _failed_ case, all of the

51
website/source/docs/agent/dns.html.markdown
View File

@ -14,16 +14,16 @@ discovery without any high-touch integration with Consul.
For example, instead of making HTTP API requests to Consul,
a host can use the DNS server directly via name lookups
like "redis.service.east-aws.consul". This query automatically
translates to a lookup of nodes that provide the redis service,
are located in the "east-aws" datacenter, and have no failing health checks.
like `redis.service.us-east-1.consul`. This query automatically
translates to a lookup of nodes that provide the `redis` service,
are located in the `us-east-1` datacenter, and have no failing health checks.
It's that simple!
There are a number of configuration options that are important for the DNS interface,
specifically [`client_addr`](/docs/agent/options.html#client_addr),
[`ports.dns`](/docs/agent/options.html#dns_port), [`recursors`](/docs/agent/options.html#recursors),
[`domain`](/docs/agent/options.html#domain), and [`dns_config`](/docs/agent/options.html#dns_config).
By default, Consul will listen on 127.0.0.1:8600 for DNS queries in the "consul."
By default, Consul will listen on 127.0.0.1:8600 for DNS queries in the `consul.`
domain, without support for further DNS recursion. Please consult the
[documentation on configuration options](/docs/agent/options.html),
specifically the configuration items linked above, for more details.
@ -39,8 +39,7 @@ You can experiment with Consul's DNS server on the command line using tools such
$ dig @127.0.0.1 -p 8600 redis.service.dc1.consul. ANY
Note that in DNS, all queries are case-insensitive. A lookup of `PostgreSQL.node.dc1.consul`
will find all nodes named `postgresql`.
-> **Note:** In DNS, all queries are case-insensitive. A lookup of `PostgreSQL.node.dc1.consul` will find all nodes named `postgresql`.
## Node Lookups
@ -50,15 +49,16 @@ A node lookup, a simple query for the address of a named node, looks like this:
<node>.node[.datacenter].<domain>
For example, if we have a "foo" node with default settings, we could look for
"foo.node.dc1.consul." The datacenter is an optional part of the FQDN: if not
provided, it defaults to the datacenter of the agent. If we know "foo" is running in
the same datacenter as our local agent, we can instead use "foo.node.consul." This
convention allows for terse syntax where appropriate while supporting queries of
nodes in remote datacenters as necessary.
For example, if we have a `foo` node with default settings, we could
look for `foo.node.dc1.consul.` The datacenter is an optional part of
the FQDN: if not provided, it defaults to the datacenter of the agent.
If we know `foo` is running in the same datacenter as our local agent,
we can instead use `foo.node.consul.` This convention allows for terse
syntax where appropriate while supporting queries of nodes in remote
datacenters as necessary.
For a node lookup, the only records returned are A records containing the IP address of
the node.
For a node lookup, the only records returned are A records containing
the IP address of the node.
```text
$ dig @127.0.0.1 -p 8600 foo.node.consul ANY
@ -92,13 +92,14 @@ The format of a standard service lookup is:
[tag.]<service>.service[.datacenter].<domain>
The `tag` is optional, and, as with node lookups, the `datacenter` is as well. If no tag is
provided, no filtering is done on tag. If no datacenter is provided, the datacenter of
this Consul agent is assumed.
The `tag` is optional, and, as with node lookups, the `datacenter` is as
well. If no tag is provided, no filtering is done on tag. If no
datacenter is provided, the datacenter of this Consul agent is assumed.
If we want to find any redis service providers in our local datacenter, we could query
"redis.service.consul." If we want to find the PostgreSQL master in a particular datacenter,
we could query "master.postgresql.service.dc2.consul."
If we want to find any redis service providers in our local datacenter,
we could query 1redis.service.consul.1 If we want to find the PostgreSQL
primary in a particular datacenter, we could query
`primary.postgresql.service.dc2.consul.`
The DNS query system makes use of health check information to prevent routing
to unhealthy nodes. When a service query is made, any services failing their health
@ -140,16 +141,16 @@ The format for RFC 2782 SRV lookups is:
_<service>._<protocol>.service[.datacenter][.domain]
Per [RFC 2782](https://tools.ietf.org/html/rfc2782), SRV queries should use
underscores (_) as a prefix to the `service` and `protocol` values in a query to
underscores, `_`, as a prefix to the `service` and `protocol` values in a query to
prevent DNS collisions. The `protocol` value can be any of the tags for a
service. If the service has no tags, "tcp" should be used. If "tcp"
service. If the service has no tags, `tcp` should be used. If `tcp`
is specified as the protocol, the query will not perform any tag filtering.
Other than the query format and default "tcp" protocol/tag value, the behavior
Other than the query format and default `tcp` protocol/tag value, the behavior
of the RFC style lookup is the same as the standard style of lookup.
If you registered the service "rabbitmq" on port 5672 and tagged it with "amqp",
you could make an RFC 2782 query for its SRV record as "_rabbitmq._amqp.service.consul":
If you registered the service `rabbitmq` on port 5672 and tagged it with `amqp`,
you could make an RFC 2782 query for its SRV record as `_rabbitmq._amqp.service.consul`:
```text
$ dig @127.0.0.1 -p 8600 _rabbitmq._amqp.service.consul SRV

10
website/source/docs/agent/encryption.html.markdown
View File

@ -60,9 +60,9 @@ Consul requires that all clients and servers have key pairs that are generated b
Certificate Authority. This can be a private CA, used only internally. The
CA then signs keys for each of the agents, as in
[this tutorial on generating both a CA and signing keys](http://russellsimpkins.blogspot.com/2015/10/consul-adding-tls-using-self-signed.html)
using OpenSSL. Note: client certificates must have
[Extended Key Usage](https://www.openssl.org/docs/manmaster/man5/x509v3_config.html#Extended-Key-Usage) enabled
for client and server authentication.
using OpenSSL.
-> **Note:** Client certificates must have [Extended Key Usage](https://www.openssl.org/docs/manmaster/man5/x509v3_config.html#Extended-Key-Usage) enabled for client and server authentication.
TLS can be used to verify the authenticity of the servers or verify the authenticity of clients.
These modes are controlled by the [`verify_outgoing`](/docs/agent/options.html#verify_outgoing),
@ -78,9 +78,9 @@ appropriate key pair set using [`cert_file`](/docs/agent/options.html#cert_file)
If [`verify_server_hostname`](/docs/agent/options.html#verify_server_hostname) is set, then
outgoing connections perform hostname verification. All servers must have a certificate
valid for "server.\<datacenter\>.\<domain\>" or the client will reject the handshake. This is
valid for `server.<datacenter>.<domain>` or the client will reject the handshake. This is
a new configuration as of 0.5.1, and it is used to prevent a compromised client from being
able to restart in server mode and perform a MITM attack. New deployments should set this
able to restart in server mode and perform a MITM (Man-In-The-Middle) attack. New deployments should set this
to true, and generate the proper certificates, but this is defaulted to false to avoid breaking
existing deployments.

35
website/source/docs/agent/http/acl.html.markdown
View File

@ -31,7 +31,7 @@ Type is either `client` or `management`. A management token is comparable
to a root user and has the ability to perform any action including
creating, modifying, and deleting ACLs.
By constrast, a client token can only perform actions as permitted by the
By contrast, a client token can only perform actions as permitted by the
rules associated. Client tokens can never manage ACLs. Given this limitation,
only a management token can be used to make requests to the `/v1/acl/create`
endpoint.
@ -40,7 +40,7 @@ In any Consul cluster, only a single datacenter is authoritative for ACLs, so
all requests are automatically routed to that datacenter regardless
of the agent to which the request is made.
The create endpoint supports a JSON request body with the PUT. The request
The create endpoint supports a JSON request body with the `PUT`. The request
body may take the form:
```javascript
@ -51,7 +51,7 @@ body may take the form:
}
```
None of the fields are mandatory. In fact, no body needs to be PUT if the
None of the fields are mandatory. In fact, no body needs to be `PUT` if the
defaults are to be used. The `Name` and `Rules` fields default to being
blank, and the `Type` defaults to "client".
@ -75,13 +75,13 @@ The update endpoint is used to modify the policy for a given ACL token. It
is very similar to the create endpoint; however, instead of generating a new
token ID, the `ID` field must be provided. As with [`/v1/acl/create`](#acl_create),
requests to this endpoint must be made with a management token. If the ID does not
exist, the ACL will be upserted. In this sense, create and update are identical.
exist, the ACL will be inserted. In this sense, create and update are identical.
In any Consul cluster, only a single datacenter is authoritative for ACLs, so
all requests are automatically routed to that datacenter regardless
of the agent to which the request is made.
The update endpoint requires a JSON request body to the PUT. The request
The update endpoint requires a JSON request body to the `PUT`. The request
body may look like:
```javascript
@ -99,7 +99,7 @@ The format of `Rules` is [documented here](/docs/internals/acl.html).
### <a name="acl_destroy"></a> /v1/acl/destroy/\<id\>
The destroy endpoint must be hit with a PUT. This endpoint destroys the ACL
The destroy endpoint must be hit with a `PUT`. This endpoint destroys the ACL
token identified by the `id` portion of the path.
The request is automatically routed to the authoritative ACL datacenter.
@ -107,7 +107,7 @@ Requests to this endpoint must be made with a management token.
### <a name="acl_info"></a> /v1/acl/info/\<id\>
The info endpoint must be hit with a GET. This endpoint returns the ACL
The info endpoint must be hit with a `GET`. This endpoint returns the ACL
token information identified by the `id` portion of the path.
It returns a JSON body like this:
@ -129,7 +129,7 @@ If the ACL is not found, null is returned instead of a JSON list.
### <a name="acl_clone"></a> /v1/acl/clone/\<id\>
The clone endpoint must be hit with a PUT. It clones the ACL identified
The clone endpoint must be hit with a `PUT`. It clones the ACL identified
by the `id` portion of the path and returns a new token `ID`. This allows
a token to serve as a template for others, making it simple to generate new
tokens without complex rule management.
@ -148,7 +148,7 @@ created ACL, like so:
### <a name="acl_list"></a> /v1/acl/list
The list endpoint must be hit with a GET. It lists all the active
The list endpoint must be hit with a `GET`. It lists all the active
ACL tokens. This is a privileged endpoint and requires a
management token.
@ -171,12 +171,12 @@ It returns a JSON body like this:
### <a name="acl_replication_status"></a> /v1/acl/replication
Available in Consul 0.7 and later, the endpoint must be hit with a
GET and returns the status of the [ACL replication](/docs/internals/acl.html#replication)
`GET` and returns the status of the [ACL replication](/docs/internals/acl.html#replication)
process in the datacenter. This is intended to be used by operators, or by
automation checking the health of ACL replication.
By default, the datacenter of the agent is queried; however, the dc can be provided
using the "?dc=" query parameter.
By default, the datacenter of the agent is queried; however, the `dc` can be provided
using the `?dc=` query parameter.
It returns a JSON body like this:
@ -203,15 +203,16 @@ replicated from, and will match the
`ReplicatedIndex` is the last index that was successfully replicated. You can
compare this to the `X-Consul-Index` header returned by the [`/v1/acl/list`](#acl_list)
endpoint to determine if the replication process has gotten all available
ACLs. Note that replication runs as a background process approximately every 30
ACLs. Replication runs as a background process approximately every 30
seconds, and that local updates are rate limited to 100 updates/second, so so it
may take several minutes to perform the initial sync of a large set of ACLs.
After the initial sync, replica lag should be on the order of about 30 seconds.
`LastSuccess` is the UTC time of the last successful sync operation. Note that
since ACL replication is done with a blocking query, this may not update for up
to 5 minutes if there have been no ACL changes to replicate. A zero value of
"0001-01-01T00:00:00Z" will be present if no sync has been successful.
`LastSuccess` is the UTC time of the last successful sync operation.
Since ACL replication is done with a blocking query, this may not update
for up to 5 minutes if there have been no ACL changes to replicate. A
zero value of "0001-01-01T00:00:00Z" will be present if no sync has been
successful.
`LastError` is the UTC time of the last error encountered during a sync operation.
If this time is later than `LastSuccess`, you can assume the replication process

158
website/source/docs/agent/http/agent.html.markdown
View File

@ -91,7 +91,7 @@ cluster gossip pool. Due to the nature of gossip, this is eventually consistent:
results may differ by agent. The strongly consistent view of nodes is
instead provided by "/v1/catalog/nodes".
For agents running in server mode, providing a "?wan=1" query parameter returns
For agents running in server mode, providing a `?wan=1` query parameter returns
the list of WAN members instead of the LAN members returned by default.
This endpoint is hit with a GET and returns a JSON body like:
@ -123,7 +123,7 @@ This endpoint is hit with a GET and returns a JSON body like:
This endpoint is used to return the configuration and member information of the local agent under the `Config` key.
Consul 0.7.0 and later also includes a snapshot of various operating statistics under the `Stats` key. These statistics are intended to help human operators for debugging and may change over time, so this part of the interface should not be consumed programatically.
Consul 0.7.0 and later also includes a snapshot of various operating statistics under the `Stats` key. These statistics are intended to help human operators for debugging and may change over time, so this part of the interface should not be consumed programmatically.
It returns a JSON body like this:
@ -214,17 +214,19 @@ The return code is 200 on success.
### <a name="agent_join"></a> /v1/agent/join/\<address\>
This endpoint is hit with a GET and is used to instruct the agent to attempt to
connect to a given address. For agents running in server mode, providing a "?wan=1"
connect to a given address. For agents running in server mode, providing a `?wan=1`
query parameter causes the agent to attempt to join using the WAN pool.
The return code is 200 on success.
### <a name="agent_force_leave"></a> /v1/agent/force-leave/\<node\>
This endpoint is hit with a GET and is used to instruct the agent to force a node into the `left` state.
If a node fails unexpectedly, then it will be in a `failed` state. Once in the `failed` state, Consul will
attempt to reconnect, and the services and checks belonging to that node will not be
cleaned up. Forcing a node into the `left` state allows its old entries to be removed.
This endpoint is hit with a GET and is used to instruct the agent to
force a node into the `left` state. If a node fails unexpectedly, then
it will be in a `failed` state. Once in the `failed` state, Consul will
attempt to reconnect, and the services and checks belonging to that node
will not be cleaned up. Forcing a node into the `left` state allows its
old entries to be removed.
The endpoint always returns 200.
@ -280,25 +282,27 @@ If a `DockerContainerID` is provided, the check is a Docker check, and Consul wi
evaluate the script every `Interval` in the given container using the specified
`Shell`. Note that `Shell` is currently only supported for Docker checks.
An `HTTP` check will perform an HTTP GET request against the value of `HTTP` (expected to
be a URL) every `Interval`. If the response is any `2xx` code, the check is `passing`.
If the response is `429 Too Many Requests`, the check is `warning`. Otherwise, the check
is `critical`. HTTP checks also support SSL. By default, a valid SSL certificate is expected.
Certificate verification can be controlled using the `TLSSkipVerify`.
An `HTTP` check will perform an HTTP GET request against the value of
`HTTP` (expected to be a URL) every `Interval`. If the response is any
`2xx` code, the check is `passing`. If the response is `429 Too Many
Requests`, the check is `warning`. Otherwise, the check is `critical`.
HTTP checks also support SSL. By default, a valid SSL certificate is
expected. Certificate verification can be controlled using the
`TLSSkipVerify`.
If `TLSSkipVerify` is set to `true`, certificate verification will be disabled. By default,
certificate verification is enabled.
If `TLSSkipVerify` is set to `true`, certificate verification will be
disabled. By default, certificate verification is enabled.
A `TCP` check will perform an TCP connection attempt against the value of `TCP`
(expected to be an IP/hostname and port combination) every `Interval`. If the
(expected to be an IP or hostname plus port combination) every `Interval`. If the
connection attempt is successful, the check is `passing`. If the connection
attempt is unsuccessful, the check is `critical`. In the case of a hostname
that resolves to both IPv4 and IPv6 addresses, an attempt will be made to both
addresses, and the first successful connection attempt will result in a
successful check.
If a `TTL` type is used, then the TTL update endpoint must be used periodically to update
the state of the check.
If a `TTL` type is used, then the TTL update endpoint must be used
periodically to update the state of the check.
The `ServiceID` field can be provided to associate the registered check with an
existing service provided by the agent.
@ -329,9 +333,9 @@ This endpoint is used with a check that is of the [TTL type](/docs/agent/checks.
When this endpoint is accessed via a GET, the status of the check is set to `passing`
and the TTL clock is reset.
The optional "?note=" query parameter can be used to associate a human-readable message
with the status of the check. This will be passed through to the check's `Output` field
in the check endpoints.
The optional `?note=` query parameter can be used to associate a
human-readable message with the status of the check. This will be passed
through to the check's `Output` field in the check endpoints.
The return code is 200 on success.
@ -341,21 +345,22 @@ This endpoint is used with a check that is of the [TTL type](/docs/agent/checks.
When this endpoint is accessed via a GET, the status of the check is set to `warning`,
and the TTL clock is reset.
The optional "?note=" query parameter can be used to associate a human-readable message
with the status of the check. This will be passed through to the check's `Output` field
in the check endpoints.
The optional `?note=` query parameter can be used to associate a
human-readable message with the status of the check. This will be passed
through to the check's `Output` field in the check endpoints.
The return code is 200 on success.
### <a name="agent_check_fail"></a> /v1/agent/check/fail/\<checkId\>
This endpoint is used with a check that is of the [TTL type](/docs/agent/checks.html).
When this endpoint is accessed via a GET, the status of the check is set to `critical`,
and the TTL clock is reset.
This endpoint is used with a check that is of the [TTL
type](/docs/agent/checks.html). When this endpoint is accessed via a
GET, the status of the check is set to `critical`, and the TTL clock is
reset.
The optional "?note=" query parameter can be used to associate a human-readable message
with the status of the check. This will be passed through to the check's `Output` field
in the check endpoints.
The optional `?note=` query parameter can be used to associate a
human-readable message with the status of the check. This will be passed
through to the check's `Output` field in the check endpoints.
The return code is 200 on success.
@ -374,21 +379,25 @@ This endpoint expects a JSON request body to be put. The request body must look
}
```
The `Status` field is mandatory, and must be set to "passing", "warning", or "critical".
The `Status` field is mandatory, and must be set to `passing`,
`warning`, or `critical`.
`Output` is an optional field that will associate a human-readable message with the status
of the check, such as the output of the checking script or process. This will be truncated
if it exceeds 4KB in size. This will be passed through to the check's `Output` field in the
check endpoints.
`Output` is an optional field that will associate a human-readable
message with the status of the check, such as the output of the checking
script or process. This will be truncated if it exceeds 4KB in size.
This will be passed through to the check's `Output` field in the check
endpoints.
The return code is 200 on success.
### <a name="agent_service_register"></a> /v1/agent/service/register
The register endpoint is used to add a new service, with an optional health check,
to the local agent. There is more documentation on services [here](/docs/agent/services.html).
The agent is responsible for managing the status of its local services, and for sending updates
about its local services to the servers to keep the global Catalog in sync.
The register endpoint is used to add a new service, with an optional
health check, to the local agent. There is more documentation on
services [here](/docs/agent/services.html). The agent is responsible
for managing the status of its local services, and for sending updates
about its local services to the servers to keep the global Catalog in
sync.
The register endpoint expects a JSON request body to be PUT. The request
body must look like:
@ -398,7 +407,7 @@ body must look like:
"ID": "redis1",
"Name": "redis",
"Tags": [
"master",
"primary",
"v1"
],
"Address": "127.0.0.1",
@ -414,9 +423,9 @@ body must look like:
}
```
The `Name` field is mandatory. If an `ID` is not provided, it is set to `Name`.
You cannot have duplicate `ID` entries per agent, so it may be necessary to provide an ID
in the case of a collision.
The `Name` field is mandatory. If an `ID` is not provided, it is set to
`Name`. You cannot have duplicate `ID` entries per agent, so it may be
necessary to provide an ID in the case of a collision.
`Tags`, `Address`, `Port`, `Check` and `EnableTagOverride` are optional.
@ -428,39 +437,46 @@ an empty `Address` field for a service, use the `Address` field of the agent nod
associated with that instance of the service, which is returned alongside the service
information.
If `Check` is provided, only one of `Script`, `HTTP`, `TCP` or `TTL` should be specified.
`Script` and `HTTP` also require `Interval`. The created check will be named "service:\<ServiceId\>".
If `Check` is provided, only one of `Script`, `HTTP`, `TCP` or `TTL`
should be specified. `Script` and `HTTP` also require `Interval`. The
created check will be named "service:\<ServiceId\>".
In Consul 0.7 and later, checks that are associated with a service may also contain
an optional `DeregisterCriticalServiceAfter` field, which is a timeout in the same Go time
format as `Interval` and `TTL`. If a check is in the critical state for more than this
configured value, then its associated service (and all of its associated checks)
will automatically be deregistered. The minimum timeout is 1 minute, and the
process that reaps critical services runs every 30 seconds, so it may take slightly
longer than the configured timeout to trigger the deregistration. This should
generally be configured with a timeout that's much, much longer than any expected
In Consul 0.7 and later, checks that are associated with a service may
also contain an optional `DeregisterCriticalServiceAfter` field, which
is a timeout in the same [Go time format](https://golang.org/pkg/time/)
as `Interval` and `TTL`. If a check is in the critical state for more
than this configured value, then its associated service (and all of its
associated checks) will automatically be deregistered. The minimum
timeout is 1 minute, and the process that reaps critical services runs
every 30 seconds, so it may take slightly longer than the configured
timeout to trigger the deregistration. This should generally be
configured with a timeout that is much, much longer than any expected
recoverable outage for the given service.
There is more information about checks [here](/docs/agent/checks.html).
`EnableTagOverride` can optionally be specified to disable the anti-entropy
feature for this service's tags. If `EnableTagOverride` is set to `true` then external
agents can update this service in the [catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
local sync operations by this agent will ignore the updated tags. For instance, if an external agent
modified both the tags and the port for this service and `EnableTagOverride`
was set to `true` then after the next sync cycle the service's port would revert
to the original value but the tags would maintain the updated value. As a
counter example, if an external agent modified both the tags and port for this
service and `EnableTagOverride` was set to `false` then after the next sync
cycle the service's port _and_ the tags would revert to the original value and
all modifications would be lost. It's important to note that this applies only
to the locally registered service. If you have multiple nodes all registering
the same service their `EnableTagOverride` configuration and all other service
configuration items are independent of one another. Updating the tags for
the service registered on one node is independent of the same service (by name)
registered on another node. If `EnableTagOverride` is not specified the default
value is `false`. See [anti-entropy syncs](/docs/internals/anti-entropy.html)
for more info.
The `EnableTagOverride` option can be specified to disable the
anti-entropy feature for this service's tags. If `EnableTagOverride` is
set to `true` then external agents can update this service in the
[catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
local sync operations by this agent will ignore the updated tags. For
instance, if an external agent modified both the tags and the port for
this service and `EnableTagOverride` was set to `true` then after the
next sync cycle the service's port would revert to the original value
but the tags would maintain the updated value. As a counter example, if
an external agent modified both the tags and port for this service and
`EnableTagOverride` was set to `false` then after the next sync cycle
the service's port _and_ the tags would revert to the original value and
all modifications would be lost.
It's important to note that this applies only to the locally registered
service. If you have multiple nodes all registering the same service
their `EnableTagOverride` configuration and all other service
configuration items are independent of one another. Updating the tags
for the service registered on one node is independent of the same
service (by name) registered on another node. If `EnableTagOverride` is
not specified the default value is `false`. See [anti-entropy
syncs](/docs/internals/anti-entropy.html) for more info.
This endpoint supports [ACL tokens](/docs/internals/acl.html). If the query
string includes a `?token=<token-id>`, the registration will use the provided
@ -474,7 +490,7 @@ The return code is 200 on success.
### <a name="agent_service_deregister"></a> /v1/agent/service/deregister/\<serviceId\>
The deregister endpoint is used to remove a service from the local agent.
The ServiceID must be passed after the slash. The agent will take care
The `ServiceID` must be passed after the slash. The agent will take care
of deregistering the service with the Catalog. If there is an associated
check, that is also deregistered.

47
website/source/docs/agent/http/catalog.html.markdown
View File

@ -28,11 +28,11 @@ tunable consistency modes.
### <a name="catalog_register"></a> /v1/catalog/register
The register endpoint is a low-level mechanism for registering or updating
entries in the catalog. Note: it is usually preferrable instead to use the
entries in the catalog. It is usually preferable to instead use the
[agent endpoints](agent.html) for registration as they are simpler and perform
[anti-entropy](/docs/internals/anti-entropy.html).
The register endpoint expects a JSON request body to be PUT. The request
The register endpoint expects a JSON request body to be `PUT`. The request
body must look something like:
```javascript
@ -48,7 +48,7 @@ body must look something like:
"ID": "redis1",
"Service": "redis",
"Tags": [
"master",
"primary",
"v1"
],
"Address": "127.0.0.1",
@ -70,7 +70,7 @@ requires `Node` and `Address` to be provided while `Datacenter` will be defaulte
to match that of the agent. If only those are provided, the endpoint will register
the node with the catalog. `TaggedAddresses` can be used in conjunction with the
[`translate_wan_addrs`](/docs/agent/options.html#translate_wan_addrs) configuration
option and the "wan" address. The "lan" address was added in Consul 0.7 to help find
option and the `wan` address. The `lan` address was added in Consul 0.7 to help find
the LAN address if address translation is enabled.
If the `Service` key is provided, the service will also be registered. If
@ -78,8 +78,7 @@ If the `Service` key is provided, the service will also be registered. If
Only one service with a given `ID` may be present per node. The service `Tags`, `Address`,
and `Port` fields are all optional.
If the `Check` key is provided, a health check will also be registered. Note: this
register API manipulates the health check entry in the Catalog, but it does not setup
If the `Check` key is provided, a health check will also be registered. The register API manipulates the health check entry in the Catalog, but it does not setup
the script, TTL, or HTTP check to monitor the node's health. To truly enable a new
health check, the check must either be provided in agent configuration or set via
the [agent endpoint](agent.html).
@ -112,11 +111,11 @@ If the API call succeeds, a 200 status code is returned.
### <a name="catalog_deregister"></a> /v1/catalog/deregister
The deregister endpoint is a low-level mechanism for directly removing
entries from the Catalog. Note: it is usually preferrable instead to use the
entries from the Catalog. It is usually preferable to instead use the
[agent endpoints](agent.html) for deregistration as they are simpler and perform
[anti-entropy](/docs/internals/anti-entropy.html).
The deregister endpoint expects a JSON request body to be PUT. The request
The deregister endpoint expects a JSON request body to be `PUT`. The request
body must look like one of the following:
```javascript
@ -164,7 +163,7 @@ If the API call succeeds a 200 status code is returned.
### <a name="catalog_datacenters"></a> /v1/catalog/datacenters
This endpoint is hit with a GET and is used to return all the
This endpoint is hit with a `GET` and is used to return all the
datacenters that are known by the Consul server.
The datacenters will be sorted in ascending order based on the
@ -183,13 +182,13 @@ used as a simple check to see if any Consul servers are routable.
### <a name="catalog_nodes"></a> /v1/catalog/nodes
This endpoint is hit with a GET and returns the nodes registered
This endpoint is hit with a `GET` and returns the nodes registered
in a given DC. By default, the datacenter of the agent is queried;
however, the dc can be provided using the "?dc=" query parameter.
however, the dc can be provided using the `?dc=` query parameter.
Adding the optional "?near=" parameter with a node name will sort
Adding the optional `?near=` parameter with a node name will sort
the node list in ascending order based on the estimated round trip
time from that node. Passing "?near=_agent" will use the agent's
time from that node. Passing `?near=_agent` will use the agent's
node for the sort.
It returns a JSON body like this:
@ -219,9 +218,9 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="catalog_services"></a> /v1/catalog/services
This endpoint is hit with a GET and returns the services registered
This endpoint is hit with a `GET` and returns the services registered
in a given DC. By default, the datacenter of the agent is queried;
however, the dc can be provided using the "?dc=" query parameter.
however, the dc can be provided using the `?dc=` query parameter.
It returns a JSON body like this:
@ -230,8 +229,8 @@ It returns a JSON body like this:
"consul": [],
"redis": [],
"postgresql": [
"master",
"slave"
"primary",
"secondary"
]
}
```
@ -243,17 +242,17 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="catalog_service"></a> /v1/catalog/service/\<service\>
This endpoint is hit with a GET and returns the nodes providing a service
This endpoint is hit with a `GET` and returns the nodes providing a service
in a given DC. By default, the datacenter of the agent is queried;
however, the dc can be provided using the "?dc=" query parameter.
however, the dc can be provided using the `?dc=` query parameter.
The service being queried must be provided on the path. By default
all nodes in that service are returned. However, the list can be filtered
by tag using the "?tag=" query parameter.
by tag using the `?tag=` query parameter.
Adding the optional "?near=" parameter with a node name will sort
Adding the optional `?near=` parameter with a node name will sort
the node list in ascending order based on the estimated round trip
time from that node. Passing "?near=_agent" will use the agent's
time from that node. Passing `?near=_agent` will use the agent's
node for the sort.
It returns a JSON body like this:
@ -299,9 +298,9 @@ The returned fields are as follows:
### <a name="catalog_node"></a> /v1/catalog/node/\<node\>
This endpoint is hit with a GET and returns the node's registered services.
This endpoint is hit with a `GET` and returns the node's registered services.
By default, the datacenter of the agent is queried;
however, the dc can be provided using the "?dc=" query parameter.
however, the dc can be provided using the `?dc=` query parameter.
The node being queried must be provided on the path.
It returns a JSON body like this:

73
website/source/docs/agent/http/kv.html.markdown
View File

@ -25,18 +25,18 @@ This endpoint manages updates of individual keys, deletes of individual keys or
prefixes, and fetches of individual keys or key prefixes. The `GET`, `PUT` and
`DELETE` methods are all supported.
By default, the datacenter of the agent is queried; however, the dc can be provided
using the "?dc=" query parameter. It is important to note that each datacenter has
By default, the datacenter of the agent is queried; however, the `dc` can be provided
using the `?dc=` query parameter. It is important to note that each datacenter has
its own KV store, and there is no built-in replication between datacenters. If you
are interested in replication between datacenters, look at the
[Consul Replicate project](https://github.com/hashicorp/consul-replicate).
The KV endpoint supports the use of ACL tokens using the "?token=" query parameter.
The KV endpoint supports the use of ACL tokens using the `?token=` query parameter.
#### GET Method
When using the `GET` method, Consul will return the specified key.
If the "?recurse" query parameter is provided, it will return
If the `?recurse` query parameter is provided, it will return
all keys with the given prefix.
This endpoint supports blocking queries and all consistency modes.
@ -62,9 +62,9 @@ when the entry was created.
`ModifyIndex` is the last index that modified this key. This index corresponds
to the `X-Consul-Index` header value that is returned in responses, and it can
be used to establish blocking queries by setting the "?index" query parameter.
be used to establish blocking queries by setting the `?index` query parameter.
You can even perform blocking queries against entire subtrees of the KV store:
if "?recurse" is provided, the returned `X-Consul-Index` corresponds
if `?recurse` is provided, the returned `X-Consul-Index` corresponds
to the latest `ModifyIndex` within the prefix, and a blocking query using that
"?index" will wait until any key within that prefix is updated.
@ -77,14 +77,15 @@ the lock.
`Flags` is an opaque unsigned integer that can be attached to each entry. Clients
can choose to use this however makes sense for their application.
`Value` is a Base64-encoded blob of data. Note that values cannot be larger than
512kB.
`Value` is a Base64-encoded blob of data.
It is possible to list just keys without their values by using the "?keys" query
-> **Note:** Values cannot be larger than 512kB.
It is possible to list just keys without their values by using the `?keys` query
parameter. This will return a list of the keys under the given prefix. The optional
"?separator=" can be used to list only up to a given separator.
`?separator=` can be used to list only up to a given separator.
For example, listing "/web/" with a "/" separator may return:
For example, listing `/web/` with a `/` separator may return:
```javascript
[
@ -97,7 +98,7 @@ For example, listing "/web/" with a "/" separator may return:
Using the key listing method may be suitable when you do not need
the values or flags or want to implement a key-space explorer.
If the "?raw" query parameter is used with a non-recursive GET,
If the `?raw` query parameter is used with a non-recursive `GET`,
the response is just the raw value of the key, without any
encoding.
@ -107,18 +108,18 @@ If no entries are found, a 404 code is returned.
When using the `PUT` method, Consul expects the request body to be the
value corresponding to the key. There are a number of query parameters that can
be used with a PUT request:
be used with a `PUT` request:
* ?flags=\<num\> : This can be used to specify an unsigned value between
0 and (2^64)-1. Clients can choose to use this however makes sense for their application.
* `?flags=<num>` : This can be used to specify an unsigned value between
`0` and `(2^64)-1`. Clients can choose to use this however makes sense for their application.
* ?cas=\<index\> : This flag is used to turn the `PUT` into a Check-And-Set
* `?cas=<index>` : This flag is used to turn the `PUT` into a Check-And-Set
operation. This is very useful as a building block for more complex
synchronization primitives. If the index is 0, Consul will only
put the key if it does not already exist. If the index is non-zero,
the key is only set if the index matches the `ModifyIndex` of that key.
* ?acquire=\<session\> : This flag is used to turn the `PUT` into a lock acquisition
* `?acquire=<session>` : This flag is used to turn the `PUT` into a lock acquisition
operation. This is useful as it allows leader election to be built on top
of Consul. If the lock is not held and the session is valid, this increments
the `LockIndex` and sets the `Session` value of the key in addition to updating
@ -127,7 +128,7 @@ be used with a PUT request:
the key contents are updated. This lets the current lock holder update the key
contents without having to give up the lock and reacquire it.
* ?release=\<session\> : This flag is used to turn the `PUT` into a lock release
* `?release=<session>` : This flag is used to turn the `PUT` into a lock release
operation. This is useful when paired with "?acquire=" as it allows clients to
yield a lock. This will leave the `LockIndex` unmodified but will clear the associated
`Session` of the key. The key must be held by this session to be unlocked.
@ -139,12 +140,12 @@ the update has not taken place.
The `DELETE` method can be used to delete a single key or all keys sharing
a prefix. There are a few query parameters that can be used with a
DELETE request:
`DELETE` request:
* ?recurse : This is used to delete all keys which have the specified prefix.
* `?recurse` : This is used to delete all keys which have the specified prefix.
Without this, only a key with an exact match will be deleted.
* ?cas=\<index\> : This flag is used to turn the `DELETE` into a Check-And-Set
* `?cas=<index>` : This flag is used to turn the `DELETE` into a Check-And-Set
operation. This is very useful as a building block for more complex
synchronization primitives. Unlike `PUT`, the index must be greater than 0
for Consul to take any action: a 0 index will not delete the key. If the index
@ -155,13 +156,13 @@ DELETE request:
Available in Consul 0.7 and later, this endpoint manages updates or fetches of
multiple keys inside a single, atomic transaction. Only the `PUT` method is supported.
By default, the datacenter of the agent receives the transaction; however, the dc
can be provided using the "?dc=" query parameter. It is important to note that each
By default, the datacenter of the agent receives the transaction; however, the `dc`
can be provided using the `?dc=` query parameter. It is important to note that each
datacenter has its own KV store, and there is no built-in replication between
datacenters. If you are interested in replication between datacenters, look at the
[Consul Replicate project](https://github.com/hashicorp/consul-replicate).
The transaction endpoint supports the use of ACL tokens using the "?token=" query
The transaction endpoint supports the use of ACL tokens using the `?token=` query
parameter.
#### PUT Method
@ -170,16 +171,18 @@ The `PUT` method lets you submit a list of operations to apply to the key/value
inside a transaction. If any operation fails, the transaction will be rolled back and
none of the changes will be applied.
If the transaction doesn't contain any write operations then it will be fast-pathed
internally to an endpoint that works like other reads, except that blocking queries
are not currently supported. In this mode, you may supply the "?stale" or "?consistent"
query parameters with the request to control consistency. To support bounding the
acceptable staleness of data, read-only transaction responses provide the `X-Consul-LastContact`
header containing the time in milliseconds that a server was last contacted by the leader node.
The `X-Consul-KnownLeader` header also indicates if there is a known leader. These
won't be present if the transaction contains any write operations, and any consistency
query parameters will be ignored, since writes are always managed by the leader via
the Raft consensus protocol.
If the transaction doesn't contain any write operations then it will be
fast-pathed internally to an endpoint that works like other reads,
except that blocking queries are not currently supported. In this mode,
you may supply the `?stale` or `?consistent` query parameters with the
request to control consistency. To support bounding the acceptable
staleness of data, read-only transaction responses provide the
`X-Consul-LastContact` header containing the time in milliseconds that a
server was last contacted by the leader node. The
`X-Consul-KnownLeader` header also indicates if there is a known leader.
These won't be present if the transaction contains any write operations,
and any consistency query parameters will be ignored, since writes are
always managed by the leader via the Raft consensus protocol.
The body of the request should be a list of operations to perform inside the atomic
transaction. Up to 64 operations may be present in a single transaction. Operations
@ -210,7 +213,7 @@ available verbs.
* `Key` is simply the full path of the entry.
* `Value` is a Base64-encoded blob of data. Note that values cannot be larger than
* `Value` is a Base64-encoded blob of data. Values cannot be larger than
512kB.
* `Flags` is an opaque unsigned integer that can be attached to each entry. Clients

21
website/source/docs/agent/http/operator.html.markdown
View File

@ -45,11 +45,11 @@ When using the `GET` method, the request will be forwarded to the cluster
leader to retrieve its latest Raft peer configuration.
If the cluster doesn't currently have a leader an error will be returned. You
can use the "?stale" query parameter to read the Raft configuration from any
can use the `?stale` query parameter to read the Raft configuration from any
of the Consul servers.
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter.
provided using the `?dc=` query parameter.
If ACLs are enabled, the client will need to supply an ACL Token with
[`operator`](/docs/internals/acl.html#operator) read privileges.
@ -102,8 +102,7 @@ Raft configuration.
`Voter` is "true" or "false", indicating if the server has a vote in the Raft
configuration. Future versions of Consul may add support for non-voting servers.
The `Index` value is the Raft corresponding to this configuration. Note that
the latest configuration may not yet be committed if changes are in flight.
The `Index` value is the Raft corresponding to this configuration. The latest configuration may not yet be committed if changes are in flight.
### <a name="raft-peer"></a> /v1/operator/raft/peer
@ -119,12 +118,12 @@ even though the server is no longer present and known to the cluster. This
endpoint can be used to remove the failed server so that it is no longer
affects the Raft quorum.
An "?address=" query parameter is required and should be set to the
"IP:port" for the server to remove. The port number is usually 8300, unless
An `?address=` query parameter is required and should be set to the
`IP:port` for the server to remove. The port number is usually 8300, unless
configured otherwise. Nothing is required in the body of the request.
By default, the datacenter of the agent is targeted; however, the `dc` can be
provided using the "?dc=" query parameter.
provided using the `?dc=` query parameter.
If ACLs are enabled, the client will need to supply an ACL Token with
[`operator`](/docs/internals/acl.html#operator) write privileges.
@ -137,7 +136,7 @@ Available in Consul 0.7.2 and later, the keyring endpoint supports the
`GET`, `POST`, `PUT` and `DELETE` methods.
This endpoint supports the use of ACL tokens using either the `X-CONSUL-TOKEN`
header or the "?token=" query parameter.
header or the `?token=` query parameter.
#### GET Method
@ -192,7 +191,7 @@ Using the `POST` method, this endpoint will install a new gossip encryption key
into the cluster. There is more information on gossip encryption available
[here](/docs/agent/encryption.html#gossip-encryption).
The POST method expects a JSON request body to be submitted. The request
The `POST` method expects a JSON request body to be submitted. The request
body must look like:
```javascript
@ -216,7 +215,7 @@ key. The key must already be installed before this operation can succeed. There
is more information on gossip encryption available
[here](/docs/agent/encryption.html#gossip-encryption).
The PUT method expects a JSON request body to be submitted. The request
The `PUT` method expects a JSON request body to be submitted. The request
body must look like:
```javascript
@ -240,7 +239,7 @@ the cluster. This operation may only be performed on keys which are not currentl
the primary key. There is more information on gossip encryption available
[here](/docs/agent/encryption.html#gossip-encryption).
The DELETE method expects a JSON request body to be submitted. The request
The `DELETE` method expects a JSON request body to be submitted. The request
body must look like:
```javascript

72
website/source/docs/agent/http/query.html.markdown
View File

@ -57,7 +57,7 @@ When using the `POST` method, Consul will create a new prepared query and return
its ID if it is created successfully.
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter.
provided using the `?dc=` query parameter.
If ACLs are enabled, the client will need to supply an ACL Token with `query`
write privileges for the `Name` of the query being created.
@ -78,7 +78,7 @@ query, like this example:
"Datacenters": ["dc1", "dc2"]
},
"OnlyPassing": false,
"Tags": ["master", "!experimental"]
"Tags": ["primary", "!experimental"]
},
"DNS": {
"TTL": "10s"
@ -105,14 +105,14 @@ field is left blank or omitted, the client's ACL Token will be used to determine
if they have access to the service being queried. If the client does not supply
an ACL Token, the anonymous token will be used.
Note that Consul version 0.6.3 and earlier would automatically capture the ACL
Consul version 0.6.3 and earlier would automatically capture the ACL
Token for use in the future when prepared queries were executed and would
execute with the same privileges as the definer of the prepared query. Older
queries wishing to obtain the new behavior will need to be updated to remove
their captured `Token` field. Capturing ACL Tokens is analogous to
[PostgreSQL’s SECURITY DEFINER](http://www.postgresql.org/docs/current/static/sql-createfunction.html)
attribute which can be set on functions. This change in effect moves Consul
from using `SECURITY DEFINER` by default to `SECURITY INVOKER` by default for
from using `SECURITY DEFINER` to `SECURITY INVOKER` by default for
new Prepared Queries.
<a name="near"></a>
@ -162,7 +162,7 @@ to pass the tag filter it must have *all* of the required tags, and *none* of th
excluded tags (prefixed with `!`). The default value is an empty list, which does
no tag filtering.
`TTL` in the `DNS` structure is a duration string that can use "s" as a
`TTL` in the `DNS` structure is a duration string that can use `s` as a
suffix for seconds. It controls how the TTL is set when query results are served
over DNS. If this isn't specified, then the Consul agent configuration for the given
service will be used (see [DNS Caching](/docs/guides/dns-cache.html)). If this is
@ -180,8 +180,10 @@ a JSON body:
```
<a name="templates"><b>Prepared Query Templates</b></a>
Consul 0.6.4 and later also support prepared query templates. These are created similar
to static templates, except with some additional fields and features. Here's an example:
Consul 0.6.4 and later also support prepared query templates. These are
created similar to static templates, except with some additional fields
and features. Here's an example:
```javascript
{
@ -205,9 +207,9 @@ to static templates, except with some additional fields and features. Here's an
The new `Template` structure configures a prepared query as a template instead of a
static query. It has two fields:
`Type` is the query type, which must be "name_prefix_match". This means that the
`Type` is the query type, which must be `name_prefix_match`. This means that the
template will apply to any query lookup with a name whose prefix matches the `Name`
field of the template. In this example, any query for "geo-db" will match this
field of the template. In this example, any query for `geo-db` will match this
query. Query templates are resolved using a longest prefix match, so it's possible
to have high-level templates that are overridden for specific services. Static
queries are always resolved first, so they can also override templates.
@ -224,23 +226,25 @@ before it is executed. All of the string fields inside the `Service` structure a
interpolated, with the following variables available:
`${name.full}` has the entire name that was queried. For example, a DNS lookup for
"geo-db-customer-master.query.consul" in the example above would set this variable to
"geo-db-customer-master".
`geo-db-customer-primary.query.consul` in the example above would set this variable to
`geo-db-customer-primary`.
`${name.prefix}` has the prefix that matched. This would always be "geo-db" for
`${name.prefix}` has the prefix that matched. This would always be `geo-db` for
the example above.
`${name.suffix}` has the suffix after the prefix. For example, a DNS lookup for
"geo-db-customer-master.query.consul" in the example above would set this variable to
"-customer-master".
`geo-db-customer-primary.query.consul` in the example above would set this variable to
`-customer-primary`.
`${match(N)}` returns the regular expression match at the given index N. The
0 index will have the entire match, and >0 will have the results of each match
group. For example, a DNS lookup for "geo-db-customer-master.query.consul" in the example
above with a `Regexp` field set to `^geo-db-(.*?)-([^\-]+?)$` would return
"geo-db-customer-master" for `${match(0)}`, "customer" for `${match(1)}`, and
"master" for `${match(2)}`. If the regular expression doesn't match, or an invalid
index is given, then `${match(N)}` will return an empty string.
`${match(N)}` returns the regular expression match at the given index N.
The 0 index will have the entire match, and >0 will have the results of
each match group. For example, a DNS lookup for
`geo-db-customer-primary.query.consul` in the example above with a
`Regexp` field set to `^geo-db-(.*?)-([^\-]+?)$` would return
`geo-db-customer-primary` for `${match(0)}`, `customer` for
`${match(1)}`, and `primary` for `${match(2)}`. If the regular
expression doesn't match, or an invalid index is given, then
`${match(N)}` will return an empty string.
See the [query explain](#explain) endpoint which is useful for testing interpolations
and determining which query is handling a given name.
@ -275,7 +279,7 @@ only a single catch-all template can be registered at any time.
When using the GET method, Consul will provide a listing of all prepared queries.
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter. This endpoint supports blocking
provided using the `?dc=` query parameter. This endpoint supports blocking
queries and all consistency modes.
If ACLs are enabled, then the client will only see prepared queries for which their
@ -299,7 +303,7 @@ This returns a JSON list of prepared queries, which looks like:
"Datacenters": ["dc1", "dc2"]
},
"OnlyPassing": false,
"Tags": ["master", "!experimental"]
"Tags": ["primary", "!experimental"]
},
"DNS": {
"TTL": "10s"
@ -322,7 +326,7 @@ The query-specific endpoint supports the `GET`, `PUT`, and `DELETE` methods. The
The `PUT` method allows an existing prepared query to be updated.
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter.
provided using the `?dc=` query parameter.
If ACLs are enabled, the client will need to supply an ACL Token with `query`
write privileges for the `Name` of the query being updated.
@ -336,7 +340,7 @@ If the API call succeeds, a 200 status code is returned.
The `GET` method allows an existing prepared query to be fetched.
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter. This endpoint supports blocking
provided using the `?dc=` query parameter. This endpoint supports blocking
queries and all consistency modes.
The returned response is the same as the list of prepared queries above,
@ -353,7 +357,7 @@ management token is used.
The `DELETE` method is used to delete a prepared query.
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter.
provided using the `?dc=` query parameter.
If ACLs are enabled, the client will need to supply an ACL Token with `query`
write privileges for the `Name` of the query being deleted.
@ -370,17 +374,17 @@ of an existing prepared query, or a name that matches a prefix name for a
[prepared query template](#templates).
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter. This endpoint does not support
provided using the `?dc=` query parameter. This endpoint does not support
blocking queries, but it does support all consistency modes.
Adding the optional "?near=" parameter with a node name will sort the resulting
Adding the optional `?near=` parameter with a node name will sort the resulting
list in ascending order based on the estimated round trip time from that node.
Passing "?near=_agent" will use the agent's node for the sort. If this is not
Passing `?near=_agent` will use the agent's node for the sort. If this is not
present, the default behavior will shuffle the nodes randomly each time the
query is executed. Passing this option will override the built-in
<a href="#near">near parameter</a> of a prepared query, if present.
An optional "?limit=" parameter can be used to limit the size of the list to
An optional `?limit=` parameter can be used to limit the size of the list to
the given number of nodes. This is applied after any sorting or shuffling.
If an ACL Token was bound to the query when it was defined then it will be used
@ -465,7 +469,7 @@ which [prepared query template](#templates) matches a given name, and what the
final query looks like after interpolation.
By default, the datacenter of the agent is queried; however, the `dc` can be
provided using the "?dc=" query parameter. This endpoint does not support
provided using the `?dc=` query parameter. This endpoint does not support
blocking queries, but it does support all consistency modes.
If ACLs are enabled, then the client will only see prepared queries for which their
@ -495,10 +499,10 @@ a JSON body will be returned like this:
"Datacenters": ["dc1", "dc2"]
},
"OnlyPassing": true,
"Tags": ["master"]
"Tags": ["primary"]
}
}
```
Note that even though this query is a template, it is shown with its `Service`
fields interpolated based on the example query name "geo-db-customer-master".
Even though this query is a template, it is shown with its `Service`
fields interpolated based on the example query name `geo-db-customer-primary`.

17
website/source/docs/agent/http/session.html.markdown
View File

@ -56,7 +56,7 @@ the agent's own node name is used.
`Name` can be used to provide a human-readable name for the Session.
`Checks` is used to provide a list of associated health checks. It is highly recommended
that, if you override this list, you include the default "serfHealth".
that, if you override this list, you include the default `serfHealth`.
`Behavior` can be set to either `release` or `delete`. This controls
the behavior when a session is invalidated. By default, this is `release`,
@ -84,7 +84,7 @@ The return code is 200 on success and returns the ID of the created session:
### <a name="session_destroy"></a> /v1/session/destroy/\<session\>
The destroy endpoint is hit with a PUT and destroys the given session.
By default, the local datacenter is used, but the "?dc=" query parameter
By default, the local datacenter is used, but the `?dc=` query parameter
can be used to specify the datacenter.
The session being destroyed must be provided on the path.
@ -95,7 +95,7 @@ The return code is 200 on success.
This endpoint is hit with a GET and returns the requested session information
within a given datacenter. By default, the datacenter of the agent is queried;
however, the dc can be provided using the "?dc=" query parameter.
however, the dc can be provided using the `?dc=` query parameter.
The session being queried must be provided on the path.
It returns a JSON body like this:
@ -121,7 +121,7 @@ This endpoint supports blocking queries and all consistency modes.
This endpoint is hit with a GET and returns the active sessions
for a given node and datacenter. By default, the datacenter of the agent is queried;
however, the dc can be provided using the "?dc=" query parameter.
however, the dc can be provided using the `?dc=` query parameter.
The node being queried must be provided on the path.
@ -148,7 +148,7 @@ This endpoint supports blocking queries and all consistency modes.
This endpoint is hit with a GET and returns the active sessions
for a given datacenter. By default, the datacenter of the agent is queried;
however, the dc can be provided using the "?dc=" query parameter.
however, the dc can be provided using the `?dc=` query parameter.
It returns a JSON body like this:
@ -173,7 +173,7 @@ This endpoint supports blocking queries and all consistency modes.
The renew endpoint is hit with a PUT and renews the given session.
This is used with sessions that have a TTL, and it extends the
expiration by the TTL. By default, the local datacenter is used, but the "?dc="
expiration by the TTL. By default, the local datacenter is used, but the `?dc=`
query parameter can be used to specify the datacenter.
The session being renewed must be provided on the path.
@ -198,6 +198,5 @@ The return code is 200 on success. The response JSON body looks like this:
The response body includes the current session.
Note: Consul MAY return a TTL value higher than the one specified during session creation.
This indicates the server is under high load and is requesting clients renew less
often.
-> **Note:** Consul MAY return a TTL value higher than the one specified during session creation. This indicates the server is under high load and is requesting clients renew less often.

12
website/source/docs/agent/options.html.markdown
View File

@ -241,7 +241,7 @@ will exit with an error at startup.
* <a name="_log_level"></a><a href="#_log_level">`-log-level`</a> - The level of logging to
show after the Consul agent has started. This defaults to "info". The available log levels are
"trace", "debug", "info", "warn", and "err". Note that you can always connect to an
"trace", "debug", "info", "warn", and "err". You can always connect to an
agent via [`consul monitor`](/docs/commands/monitor.html) and use any log level. Also, the
log level can be changed during a config reload.
@ -344,7 +344,7 @@ definitions support being updated during a reload.
}
```
Note the use of `ports`:
See, especially, the use of the `ports` setting:
```javascript
"ports": {
@ -382,10 +382,10 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
permissions if it does not exist. It allows operators to bootstrap the ACL system
with a token ID that is well-known.
<br><br>
Note that the `acl_master_token` is only installed when a server acquires cluster leadership. If
The `acl_master_token` is only installed when a server acquires cluster leadership. If
you would like to install or change the `acl_master_token`, set the new value for `acl_master_token`
in the configuration for all servers. Once this is done, restart the current leader to force a
leader election. If the acl_master_token is not supplied, then the servers do not create a master
leader election. If the `acl_master_token` is not supplied, then the servers do not create a master
token. When you provide a value, it can be any string value. Using a UUID would ensure that it looks
the same as the other tokens, but isn't strictly necessary.
@ -887,7 +887,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
sockets created by Consul:
<br>
* `user` - The name or ID of the user who will own the socket file.
* `group` - The group ID ownership of the socket file. Note that this option
* `group` - The group ID ownership of the socket file. This option
currently only supports numeric IDs.
* `mode` - The permission bits to set on the file.
@ -896,7 +896,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
connections make use of TLS and that the client provides a certificate signed
by the Certificate Authority from the [`ca_file`](#ca_file). By default, this is false, and
Consul will not enforce the use of TLS or verify a client's authenticity. This
applies to both server RPC and to the HTTPS API. Note: to enable the HTTPS API, you
applies to both server RPC and to the HTTPS API. To enable the HTTPS API, you
must define an HTTPS port via the [`ports`](#ports) configuration. By default, HTTPS
is disabled.

80
website/source/docs/agent/services.html.markdown
View File

@ -23,7 +23,7 @@ A service definition that is a script looks like:
{
"service": {
"name": "redis",
"tags": ["master"],
"tags": ["primary"],
"address": "",
"port": 8000,
"enableTagOverride": false,
@ -37,14 +37,15 @@ A service definition that is a script looks like:
}
```
A service definition must include a `name` and may optionally provide
an `id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The `id` is
set to the `name` if not provided. It is required that all services have a unique
ID per node, so if names might conflict then unique IDs should be provided.
A service definition must include a `name` and may optionally provide an
`id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The
`id` is set to the `name` if not provided. It is required that all
services have a unique ID per node, so if names might conflict then
unique IDs should be provided.
The `tags` property is a list of values that are opaque to Consul but can be used to
distinguish between "master" or "slave" nodes, different versions, or any other service
level labels.
The `tags` property is a list of values that are opaque to Consul but
can be used to distinguish between `primary` or `secondary` nodes,
different versions, or any other service level labels.
The `address` field can be used to specify a service-specific IP address. By
default, the IP address of the agent is used, and this does not need to be provided.
@ -58,7 +59,7 @@ used for any interaction with the catalog for the service, including
A service can have an associated health check. This is a powerful feature as
it allows a web balancer to gracefully remove failing nodes, a database
to replace a failed slave, etc. The health check is strongly integrated in
to replace a failed secondary, etc. The health check is strongly integrated in
the DNS interface as well. If a service is failing its health check or a
node has any failing system-level check, the DNS interface will omit that
node from any service query.
@ -72,37 +73,42 @@ service checks registered, the ID will be generated as
`service:<service-id>:<num>` where `<num>` is an incrementing number starting
from `1`.
Note: there is more information about [checks here](/docs/agent/checks.html).
-> **Note:** There is more information about [checks here](/docs/agent/checks.html).
The `enableTagOverride` can optionally be specified to disable the anti-entropy
feature for this service. If `enableTagOverride` is set to TRUE then external
agents can update this service in the [catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
local sync operations by this agent will ignore the updated tags. For instance: If an external agent
modified both the tags and the port for this service and `enableTagOverride`
was set to TRUE then after the next sync cycle the service's port would revert
to the original value but the tags would maintain the updated value. As a
counter example: If an external agent modified both the tags and port for this
service and `enableTagOverride` was set to FALSE then after the next sync
cycle the service's port AND the tags would revert to the original value and
all modifications would be lost. It's important to note that this applies only
to the locally registered service. If you have multiple nodes all registering
the same service their `enableTagOverride` configuration and all other service
configuration items are independent of one another. Updating the tags for
the service registered on one node is independent of the same service (by name)
registered on another node. If `enableTagOverride` is not specified the default
value is false. See [anti-entropy syncs](/docs/internals/anti-entropy.html)
for more info.
The `enableTagOverride` can optionally be specified to disable the
anti-entropy feature for this service. If `enableTagOverride` is set to
`TRUE` then external agents can update this service in the
[catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
local sync operations by this agent will ignore the updated tags. For
example, if an external agent modified both the tags and the port for
this service and `enableTagOverride` was set to `TRUE` then after the next
sync cycle the service's port would revert to the original value but the
tags would maintain the updated value. As a counter example: If an
external agent modified both the tags and port for this service and
`enableTagOverride` was set to `FALSE` then after the next sync cycle the
service's port *and* the tags would revert to the original value and all
modifications would be lost.
To configure a service, either provide it as a `-config-file` option to the
agent or place it inside the `-config-dir` of the agent. The file must
end in the ".json" extension to be loaded by Consul. Check definitions can
also be updated by sending a `SIGHUP` to the agent. Alternatively, the
service can be registered dynamically using the [HTTP API](/docs/agent/http.html).
It's important to note that this applies only to the locally registered
service. If you have multiple nodes all registering the same service
their `enableTagOverride` configuration and all other service
configuration items are independent of one another. Updating the tags
for the service registered on one node is independent of the same
service (by name) registered on another node. If `enableTagOverride` is
not specified the default value is false. See [anti-entropy
syncs](/docs/internals/anti-entropy.html) for more info.
To configure a service, either provide it as a `-config-file` option to
the agent or place it inside the `-config-dir` of the agent. The file
must end in the `.json` extension to be loaded by Consul. Check
definitions can be updated by sending a `SIGHUP` to the agent.
Alternatively, the service can be registered dynamically using the [HTTP
API](/docs/agent/http.html).
## Multiple Service Definitions
Multiple services definitions can be provided at once using the `services`
(plural) key in your configuration file.
Multiple services definitions can be provided at once using the plural
`services` key in your configuration file.
```javascript
{
@ -111,7 +117,7 @@ Multiple services definitions can be provided at once using the `services`
"id": "red0",
"name": "redis",
"tags": [
"master"
"primary"
],
"address": "",
"port": 6000,
@ -128,7 +134,7 @@ Multiple services definitions can be provided at once using the `services`
"name": "redis",
"tags": [
"delayed",
"slave"
"secondary"
],
"address": "",
"port": 7000,

4
website/source/docs/agent/telemetry.html.markdown
View File

@ -161,7 +161,7 @@ These metrics give insight into the health of the cluster as a whole.
</tr>
<tr>
<td>`consul.serf.events`</td>
<td>This increments when an agent processes an [event](/docs/commands/event.html). Note that Consul uses events internally so there may be additional events showing in telemetry. There are also a per-event counters emitted as `consul.serf.events.<event name>`.</td>
<td>This increments when an agent processes an [event](/docs/commands/event.html). Consul uses events internally so there may be additional events showing in telemetry. There are also a per-event counters emitted as `consul.serf.events.<event name>`.</td>
<td>events / interval</td>
<td>counter</td>
</tr>
@ -185,7 +185,7 @@ These metrics give insight into the health of the cluster as a whole.
</tr>
<tr>
<td>`consul.http.<verb>.<path>`</td>
<td>This tracks how long it takes to service the given HTTP request for the given verb and path. Note that paths do not include details like service or key names, for these an underscore will be present as a placeholder (eg. `consul.http.GET.v1.kv._`)</td>
<td>This tracks how long it takes to service the given HTTP request for the given verb and path. Paths do not include details like service or key names, for these an underscore will be present as a placeholder (eg. `consul.http.GET.v1.kv._`)</td>
<td>ms</td>
<td>timer</td>
</tr>

5
website/source/docs/commands/event.html.markdown
View File

@ -17,6 +17,7 @@ or perform any other orchestration action. Events can be handled by
[using a watch](/docs/agent/watches.html).
Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip.html).
While the details are not important for using events, an understanding of
the semantics is useful. The gossip layer will make a best-effort to deliver
the event, but there is **no guaranteed delivery**. Unlike most Consul data, which is
@ -42,7 +43,7 @@ The list of available flags are:
* `-http-addr` - Address to the HTTP server of the agent you want to contact
to send this command. If this isn't specified, the command will contact
"127.0.0.1:8500" which is the default HTTP address of a Consul agent.
`127.0.0.1:8500` which is the default HTTP address of a Consul agent.
* `-datacenter` - Datacenter to query. Defaults to that of agent.
@ -54,7 +55,7 @@ The list of available flags are:
* `-tag` - Regular expression to filter to only nodes with a service that has
a matching tag. This must be used with `-service`. As an example, you may
do "-service mysql -tag slave".
do `-service mysql -tag secondary`.
* `-token` - The ACL token to use when firing the event. This token must have
write-level privileges for the event specified. Defaults to that of the agent.

10
website/source/docs/commands/exec.html.markdown
View File

@ -34,20 +34,20 @@ could make the cluster unavailable.
Usage: `consul exec [options] [-|command...]`
The only required option is a command to execute. This is either given
as trailing arguments, or by specifying '-'; stdin will be read to
as trailing arguments, or by specifying `-`; STDIN will be read to
completion as a script to evaluate.
The list of available flags are:
* `-http-addr` - Address to the HTTP server of the agent you want to contact
to send this command. If this isn't specified, the command will contact
"127.0.0.1:8500" which is the default HTTP address of a Consul agent.
`127.0.0.1:8500` which is the default HTTP address of a Consul agent.
* `-datacenter` - Datacenter to query. Defaults to that of agent. In version
0.4, that is the only supported value.
* `-prefix` - Key prefix in the KV store to use for storing request data.
Defaults to "_rexec".
Defaults to `_rexec`.
* `-node` - Regular expression to filter nodes which should evaluate the event.
@ -55,7 +55,7 @@ The list of available flags are:
* `-tag` - Regular expression to filter to only nodes with a service that has
a matching tag. This must be used with `-service`. As an example, you may
do "-service mysql -tag slave".
do `-service mysql -tag secondary`.
* `-wait` - Specifies the period of time in which no agent's respond before considering
the job finished. This is basically the quiescent time required to assume completion.
@ -69,5 +69,5 @@ The list of available flags are:
* `-verbose` - Enables verbose output.
* `-token` - The ACL token to use during requests. This token must have access
to the prefix in the KV store as well as exec "write" access for the _rexec
to the prefix in the KV store as well as exec "write" access for the `_rexec`
event. Defaults to that of the agent.

8
website/source/docs/commands/force-leave.html.markdown
View File

@ -3,7 +3,7 @@ layout: "docs"
page_title: "Commands: Force Leave"
sidebar_current: "docs-commands-forceleave"
description: |-
The `force-leave` command forces a member of a Consul cluster to enter the left state. Note that if the member is still actually alive, it will eventually rejoin the cluster. The true purpose of this method is to force remove failed nodes.
The `force-leave` command forces a member of a Consul cluster to enter the left state. If the member is still actually alive, it will eventually rejoin the cluster. The true purpose of this method is to force remove failed nodes.
---
# Consul Force Leave
@ -11,7 +11,7 @@ description: |-
Command: `consul force-leave`
The `force-leave` command forces a member of a Consul cluster to enter the
"left" state. Note that if the member is still actually alive, it will
"left" state. If the member is still actually alive, it will
eventually rejoin the cluster. The true purpose of this method is to force
remove "failed" nodes.
@ -33,6 +33,6 @@ Every option is optional:
* `-rpc-addr` - Address to the RPC server of the agent you want to contact
to send this command. If this isn't specified, the command checks the
CONSUL_RPC_ADDR env variable. If this isn't set, the default RPC
address will be set to "127.0.0.1:8400".
`CONSUL_RPC_ADDR` env variable. If this isn't set, the default RPC
address will be set to `127.0.0.1:8400`.

2
website/source/docs/commands/kv/put.html.markdown.erb
View File

@ -110,7 +110,7 @@ $ consul kv put -flags=42 redis/config/password s3cr3t
Success! Data written to: redis/config/password
```
To create or tune a lock, use the `-acquire` and `-session` flags. Note that the session must already exist (this command will not create it or manage it):
To create or tune a lock, use the `-acquire` and `-session` flags. The session must already exist (this command will not create it or manage it):
```
$ consul kv put -acquire -session=abc123 redis/lock/update

4
website/source/docs/commands/rtt.html.markdown
View File

@ -21,8 +21,8 @@ for more information on how these coordinates are computed.
Usage: `consul rtt [options] node1 [node2]`
At least one node name is required. If the second node name isn't given, it
is set to the agent's node name. Note that these are node names as known to
Consul as `consul members` would show, not IP addresses.
is set to the agent's node name. These are the node names as known to
Consul as the `consul members` command would show, not IP addresses.
The list of available flags are:

5
website/source/docs/compatibility.html.markdown
View File

@ -18,8 +18,9 @@ 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.
Backwards compatibility is automatic unless otherwise noted. Consul agents by
default will speak the latest protocol but can understand earlier ones. Note:
if speaking an earlier protocol, _new features may not be available_.
default will speak the latest protocol but can understand earlier ones.
-> **Note:** If speaking an earlier protocol, _new features may not be available_.
The ability for an agent to speak an earlier protocol is to ensure that any agent
can be upgraded without cluster disruption. Consul agents can be updated one

25
website/source/docs/guides/bootstrapping.html.markdown
View File

@ -70,19 +70,22 @@ Since a join operation is symmetric, it does not matter which node initiates it.
[INFO] consul: cluster leadership acquired
```
As a sanity check, the [`consul info`](/docs/commands/info.html) command is a useful tool. It can be used to
verify `raft.num_peers` is now 2, and you can view the latest log index under `raft.last_log_index`.
When running [`consul info`](/docs/commands/info.html) on the followers, you should see `raft.last_log_index`
converge to the same value once the leader begins replication. That value represents the last
log entry that has been stored on disk.
As a sanity check, the [`consul info`](/docs/commands/info.html) command
is a useful tool. It can be used to verify `raft.num_peers` is now 2,
and you can view the latest log index under `raft.last_log_index`. When
running [`consul info`](/docs/commands/info.html) on the followers, you
should see `raft.last_log_index` converge to the same value once the
leader begins replication. That value represents the last log entry that
has been stored on disk.
Now that the servers are all started and replicating to each other, all the remaining
clients can be joined. Clients are much easier as they can join against any existing node.
All nodes participate in a gossip protocol to perform basic discovery, so once joined to any
member of the cluster, new clients will automatically find the servers and register themselves.
Now that the servers are all started and replicating to each other, all
the remaining clients can be joined. Clients are much easier as they can
join against any existing node. All nodes participate in a gossip
protocol to perform basic discovery, so once joined to any member of the
cluster, new clients will automatically find the servers and register
themselves.
Note: it is not strictly necessary to start the server nodes before the clients; however, most
operations will fail until the servers are available.
-> **Note:** It is not strictly necessary to start the server nodes before the clients; however, most operations will fail until the servers are available.
## Manual Bootstrapping

54
website/source/docs/guides/forwarding.html.markdown
View File

@ -13,11 +13,14 @@ requires elevated privileges. Instead of running Consul with an administrative
or root account, it is possible to instead forward appropriate queries to Consul,
running on an unprivileged port, from another DNS server or port redirect.
In this guide, we will demonstrate forwarding from [BIND](https://www.isc.org/downloads/bind/)
as well as [dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) and [iptables](http://www.netfilter.org/).
For the sake of simplicity, BIND and Consul are running on the same machine in this example. For iptables the
rules must be set on the same host as the Consul instance and relay hosts should not be on the same host or
the redirects will intercept the traffic.
In this guide, we will demonstrate forwarding from
[BIND](https://www.isc.org/downloads/bind/) as well as
[dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) and
[iptables](http://www.netfilter.org/). For the sake of simplicity, BIND
and Consul are running on the same machine in this example. For iptables
the rules must be set on the same host as the Consul instance and relay
hosts should not be on the same host or the redirects will intercept the
traffic.
It is worth mentioning that, by default, Consul does not resolve DNS
records outside the `.consul.` zone unless the
@ -61,7 +64,7 @@ include "/etc/named/consul.conf";
### Zone File
Then we set up a zone for our Consul managed records in consul.conf:
Then we set up a zone for our Consul managed records in `consul.conf`:
```text
zone "consul" IN {
@ -129,15 +132,20 @@ for additional details):
### iptables Setup
On Linux systems that support it, incoming requests and requests to localhost can use `iptables`
to forward ports on the same machine without a secondary service. Since Consul, by default, only
resolves the `.consul` TDL, it is especially important to use the `recursors` option if you wish the
`iptables` setup to resolve for other domains. The recursors should not include the localhost as the
redirects would just intercept the requests. The iptables method is suited for situations where an
external DNS service is already running in your infrastructure and is used as the recursor or if you want
to use an existing DNS server as your query endpoint and forward requests for the consul domain to the
consul server. In both of those cases you may want to query the consul server but not need the overhead
of a separate service on the consul host.
On Linux systems that support it, incoming requests and requests to
the local host can use `iptables` to forward ports on the same machine
without a secondary service. Since Consul, by default, only resolves
the `.consul` TDL, it is especially important to use the `recursors`
option if you wish the `iptables` setup to resolve for other domains.
The recursors should not include the local host as the redirects would
just intercept the requests.
The iptables method is suited for situations where an external DNS
service is already running in your infrastructure and is used as the
recursor or if you want to use an existing DNS server as your query
endpoint and forward requests for the consul domain to the Consul
server. In both of those cases you may want to query the Consul server
but not need the overhead of a separate service on the Consul host.
```
[root@localhost ~]# iptables -t nat -A PREROUTING -p udp -m udp --dport 53 -j REDIRECT --to-ports 8600
@ -151,9 +159,9 @@ of a separate service on the consul host.
First, perform a DNS query against Consul directly to be sure that the record exists:
```text
[root@localhost ~]# dig @localhost -p 8600 master.redis.service.dc-1.consul. A
[root@localhost ~]# dig @localhost -p 8600 primary.redis.service.dc-1.consul. A
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost master.redis.service.dc-1.consul. A
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost primary.redis.service.dc-1.consul. A
; (1 server found)
;; global options: +cmd
;; Got answer:
@ -161,10 +169,10 @@ First, perform a DNS query against Consul directly to be sure that the record ex
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;master.redis.service.dc-1.consul. IN A
;primary.redis.service.dc-1.consul. IN A
;; ANSWER SECTION:
master.redis.service.dc-1.consul. 0 IN A 172.31.3.234
primary.redis.service.dc-1.consul. 0 IN A 172.31.3.234
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
@ -176,9 +184,9 @@ Then run the same query against your BIND instance and make sure you get a
valid result:
```text
[root@localhost ~]# dig @localhost -p 53 master.redis.service.dc-1.consul. A
[root@localhost ~]# dig @localhost -p 53 primary.redis.service.dc-1.consul. A
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost master.redis.service.dc-1.consul. A
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost primary.redis.service.dc-1.consul. A
; (1 server found)
;; global options: +cmd
;; Got answer:
@ -186,10 +194,10 @@ valid result:
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;master.redis.service.dc-1.consul. IN A
;primary.redis.service.dc-1.consul. IN A
;; ANSWER SECTION:
master.redis.service.dc-1.consul. 0 IN A 172.31.3.234
primary.redis.service.dc-1.consul. 0 IN A 172.31.3.234
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

28
website/source/docs/guides/leader-election.html.markdown
View File

@ -17,8 +17,7 @@ cover all the possible methods. Instead, we will focus on using Consul's support
[sessions](/docs/internals/sessions.html). Sessions allow us to build a system that
can gracefully handle failures.
Note that JSON output in this guide has been pretty-printed for easier
reading. Actual values returned from the API will not be formatted.
-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted.
## Contending Nodes
@ -50,7 +49,7 @@ This will return a JSON object containing the session ID:
The next step is to acquire a session for a given key from this node
using the PUT method on a [KV entry](/docs/agent/http/kv.html) with the
"?acquire=\<session\>" query parameter. The `<body>` of the PUT should be a
`?acquire=<session>` query parameter. The `<body>` of the PUT should be a
JSON object representing the local node. This value is opaque to
Consul, but it should contain whatever information clients require to
communicate with your application (e.g., it could be a JSON object
@ -73,7 +72,7 @@ on `<key>`. This is because the lock may be released, the node may fail, etc.
The leader must also watch for changes since its lock may be released by an operator
or automatically released due to a false positive in the failure detector.
Note that the session by default makes use of only the gossip failure detector. That
By default, the session makes use of only the gossip failure detector. That
is, the session is considered held by a node as long as the default Serf health check
has not declared the node unhealthy. Additional checks can be specified if desired.
@ -115,12 +114,14 @@ curl http://localhost:8500/v1/kv/<key>
]
```
If the key has no associated `Session`, then there is no leader. Otherwise, the value of
the key will provide all the application-dependent information required as a Base64 encoded
blob in the `Value` field.
If the key has no associated `Session`, then there is no leader.
Otherwise, the value of the key will provide all the
application-dependent information required as a Base64 encoded blob in
the `Value` field.
You can query the [`/v1/session/info`](/docs/agent/http/session.html#session_info) endpoint
to get details about the session:
You can query the
[`/v1/session/info`](/docs/agent/http/session.html#session_info)
endpoint to get details about the session:
```text
curl http://localhost:8500/v1/session/info/4ca8e74b-6350-7587-addf-a18084928f3c
@ -130,7 +131,7 @@ curl http://localhost:8500/v1/session/info/4ca8e74b-6350-7587-addf-a18084928f3c
"Checks": [
"serfHealth"
],
"Node": "consul-master-bjsiobmvdij6-node-lhe5ihreel7y",
"Node": "consul-primary-bjsiobmvdij6-node-lhe5ihreel7y",
"Name": "dbservice",
"ID": "4ca8e74b-6350-7587-addf-a18084928f3c",
"CreateIndex": 28
@ -138,6 +139,7 @@ curl http://localhost:8500/v1/session/info/4ca8e74b-6350-7587-addf-a18084928f3c
]
```
Clients should also watch the key using a blocking query for any changes. If the leader
steps down or fails, the `Session` associated with the key will be cleared. When
a new leader is elected, the key value will also be updated.
Clients should also watch the key using a blocking query for any
changes. If the leader steps down or fails, the `Session` associated
with the key will be cleared. When a new leader is elected, the key
value will also be updated.

25
website/source/docs/guides/outage.html.markdown
View File

@ -21,12 +21,13 @@ add or remove a server, [see this guide](/docs/guides/servers.html).
## Failure of a Single Server Cluster
If you had only a single server and it has failed, simply restart it.
Note that a single server configuration requires the
If you had only a single server and it has failed, simply restart it. A
single server configuration requires the
[`-bootstrap`](/docs/agent/options.html#_bootstrap) or
[`-bootstrap-expect=1`](/docs/agent/options.html#_bootstrap_expect) flag. If
the server cannot be recovered, you need to bring up a new server.
See the [bootstrapping guide](/docs/guides/bootstrapping.html) for more detail.
[`-bootstrap-expect=1`](/docs/agent/options.html#_bootstrap_expect)
flag. If the server cannot be recovered, you need to bring up a new
server. See the [bootstrapping guide](/docs/guides/bootstrapping.html)
for more detail.
In the case of an unrecoverable server failure in a single server cluster, data
loss is inevitable since data was not replicated to any other servers. This is
@ -54,8 +55,7 @@ server if it's still a member of the cluster.
If [`consul force-leave`](/docs/commands/force-leave.html) isn't able to remove the
server, you have two methods available to remove it, depending on your version of Consul:
* In Consul 0.7 and later, you can use the [`consul operator`](/docs/commands/operator.html#raft-remove-peer)
command to remove the stale peer server on the fly with no downtime.
* In Consul 0.7 and later, you can use the [`consul operator`](/docs/commands/operator.html#raft-remove-peer) command to remove the stale peer server on the fly with no downtime.
* In versions of Consul prior to 0.7, you can manually remove the stale peer
server using the `raft/peers.json` recovery file on all remaining servers. See
@ -94,7 +94,7 @@ In extreme cases, it should be possible to recover with just a single remaining
server by starting that single server with itself as the only peer in the
`raft/peers.json` recovery file.
Note that prior to Consul 0.7 it wasn't always possible to recover from certain
Prior to Consul 0.7 it wasn't always possible to recover from certain
types of outages with `raft/peers.json` because this was ingested before any Raft
log entries were played back. In Consul 0.7 and later, the `raft/peers.json`
recovery file is final, and a snapshot is taken after it is ingested, so you are
@ -109,19 +109,18 @@ To begin, stop all remaining servers. You can attempt a graceful leave,
but it will not work in most cases. Do not worry if the leave exits with an
error. The cluster is in an unhealthy state, so this is expected.
~> Note that in Consul 0.7 and later, the peers.json file is no longer present
In Consul 0.7 and later, the `peers.json` file is no longer present
by default and is only used when performing recovery. This file will be deleted
after Consul starts and ingests this file. Consul 0.7 also uses a new, automatically-
created `raft/peers.info` file to avoid ingesting the `raft/peers.json` file on the
first start after upgrading. Be sure to leave `raft/peers.info` in place for proper
operation.
<br>
<br>
Using `raft/peers.json` for recovery can cause uncommitted Raft log entries to be
implicitly committed, so this should only be used after an outage where no
other option is available to recover a lost server. Make sure you don't have
any automated processes that will put the peers file in place on a periodic basis,
for example.
any automated processes that will put the peers file in place on a
periodic basis.
The next step is to go to the [`-data-dir`](/docs/agent/options.html#_data_dir)
of each Consul server. Inside that directory, there will be a `raft/`

3
website/source/docs/guides/semaphore.html.markdown
View File

@ -21,8 +21,7 @@ cover all the possible methods. Instead, we will focus on using Consul's support
[sessions](/docs/internals/sessions.html). Sessions allow us to build a system that
can gracefully handle failures.
Note that JSON output in this guide has been pretty-printed for easier
reading. Actual values returned from the API will not be formatted.
-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted.
## Contending Nodes

4
website/source/docs/internals/acl.html.markdown
View File

@ -121,7 +121,7 @@ configuration to the target datacenter.
Bootstrapping the ACL system is done by providing an initial [`acl_master_token`
configuration](/docs/agent/options.html#acl_master_token) which will be created
as a "management" type token if it does not exist. Note that the [`acl_master_token`
as a "management" type token if it does not exist. The [`acl_master_token`
](/docs/agent/options.html#acl_master_token) is only installed when a server acquires
cluster leadership. If you would like to install or change the
[`acl_master_token`](/docs/agent/options.html#acl_master_token), set the new value for
@ -301,7 +301,7 @@ service "" {
}
```
Note that the above will allow access for reading service information only. This
The above will allow access for reading service information only. This
level of access allows discovering other services in the system, but is not
enough to allow the agent to sync its services and checks into the global
catalog during [anti-entropy](/docs/internals/anti-entropy.html).

23
website/source/docs/internals/anti-entropy.html.markdown
View File

@ -138,14 +138,15 @@ automatically recover from these types of transient failures.
### EnableTagOverride
Synchronization of service registration can be partially modified to allow
external agents to change the tags for a service. This can be useful in
situations where an external monitoring service needs to be the source of
truth for tag information. For instance: Redis DB and its monitoring service
Redis Sentinel have this kind of relationship. Redis instances are responsible
for much of their configuration, but Sentinels determine whether the Redis
instance is a master or a slave. Using the Consul service configuration item
[EnableTagOverride](/docs/agent/services.html) you can instruct the Consul
agent on which the Redis DB is running to NOT update the tags during anti-entropy
synchronization. For more information see [Services](/docs/agent/services.html)
page.
Synchronization of service registration can be partially modified to
allow external agents to change the tags for a service. This can be
useful in situations where an external monitoring service needs to be
the source of truth for tag information. For example, the Redis
database and its monitoring service Redis Sentinel have this kind of
relationship. Redis instances are responsible for much of their
configuration, but Sentinels determine whether the Redis instance is a
primary or a secondary. Using the Consul service configuration item
[EnableTagOverride](/docs/agent/services.html) you can instruct the
Consul agent on which the Redis database is running to NOT update the
tags during anti-entropy synchronization. For more information see
[Services](/docs/agent/services.html) page.

7
website/source/docs/upgrade-specific.html.markdown
View File

@ -187,9 +187,10 @@ which require it:
policy = "read"
}
Note that the agent's [`acl_token`](/docs/agent/options.html#acl_token) is used
when the DNS interface is queried, so be sure that token has sufficient
privileges to return the DNS records you expect to retrieve from it.
When the DNS interface is queried, the agent's
[`acl_token`](/docs/agent/options.html#acl_token) is used, so be sure
that token has sufficient privileges to return the DNS records you
expect to retrieve from it.
* Event and keyring ACLs

2
website/source/docs/upgrading.html.markdown
View File

@ -80,7 +80,7 @@ Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use p
This says the version of Consul as well as the protocol versions this
agent speaks and can understand.
Note that sometimes Consul will default to speak a lower protocol version
Sometimes Consul will default to speak a lower protocol version
than it understands, in order to ease compatibility with older agents. For
example, Consul agents that understand version 3 claim to speak version 2,
and only send version 3 messages to agents that understand version 3. This