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

Merge pull request #2532 from jamtur01/docspass 

Documentation pass
This commit is contained in:
James Phillips 2016-11-29 15:15:04 -08:00 committed by GitHub
parent 35e6d30572 214fbbbad2
commit 2dea48193c
39 changed files with 516 additions and 476 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
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
@ -139,5 +136,5 @@ To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_
states), Consul will automatically remove dead nodes out of the catalog. This
process is called _reaping_. This is currently done on a configurable
interval of 72 hours (changing the reap interval is *not* recommended due to
its consequences during outage situations). Reaping is similar to leaving,
its consequences during outage situations). Reaping is similar to leaving,
causing all associated services to be deregistered.

2
website/source/docs/agent/checks.html.markdown
View File

@ -12,7 +12,7 @@ One of the primary roles of the agent is management of system-level and applicat
checks. A health check is considered to be application-level if it is associated with a
service. If not associated with a service, the check monitors the health of the entire node.
A check is defined in a configuration file or added at runtime over the HTTP interface. Checks
A check is defined in a configuration file or added at runtime over the HTTP interface. Checks
created via the HTTP interface persist with that node.
There are five different kinds of checks:

53
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
@ -83,7 +83,7 @@ consul. 0 IN SOA ns.consul. postmaster.consul. 1392836399 3600 600 86400 0
## Service Lookups
A service lookup is used to query for service providers. Service queries support
A service lookup is used to query for service providers. Service queries support
two lookup methods: standard and strict [RFC 2782](https://tools.ietf.org/html/rfc2782).
### Standard Lookup
@ -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 `redis.service.consul.` 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

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

@ -18,7 +18,7 @@ Enabling gossip encryption only requires that you set an encryption key when
starting the Consul agent. The key can be set via the `encrypt` parameter: the
value of this setting is a configuration file containing the encryption key.
The key must be 16-bytes, Base64 encoded. As a convenience, Consul provides the
The key must be 16-bytes, Base64 encoded. As a convenience, Consul provides the
[`consul keygen`](/docs/commands/keygen.html) command to generate a
cryptographically suitable key:
@ -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.

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

@ -36,9 +36,9 @@ Certain endpoints support a feature called a "blocking query." A blocking query
is used to wait for a potential change using long polling.
Not all endpoints support blocking, but those that do are clearly designated in the
documentation. Any endpoint that supports blocking will also set the HTTP header
documentation. Any endpoint that supports blocking will also set the HTTP header
`X-Consul-Index`, a unique identifier representing the current state of the
requested resource. On subsequent requests for this resource, the client can set the `index`
requested resource. On subsequent requests for this resource, the client can set the `index`
query string parameter to the value of `X-Consul-Index`, indicating that the client wishes
to wait for any changes subsequent to that index.
@ -63,7 +63,7 @@ The three read modes are:
there is a small window in which a new leader may be elected during which the old leader may
service stale values. The trade-off is fast reads but potentially stale values. The condition
resulting in stale reads is hard to trigger, and most clients should not need to worry about
this case. Also, note that this race condition only applies to reads, not writes.
this case. Also, note that this race condition only applies to reads, not writes.
* consistent - This mode is strongly consistent without caveats. It requires
that a leader verify with a quorum of peers that it is still leader. This
@ -87,7 +87,7 @@ by clients to gauge the staleness of a result and take appropriate action.
## Formatted JSON Output
By default, the output of all HTTP API requests is minimized JSON. If the client passes `pretty`
By default, the output of all HTTP API requests is minimized JSON. If the client passes `pretty`
on the query string, formatted JSON will be returned.
## ACLs

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

@ -31,8 +31,8 @@ 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
rules associated. Client tokens can never manage ACLs. Given this limitation,
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

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

@ -10,7 +10,7 @@ description: >
The Agent endpoints are used to interact with the local Consul agent. Usually,
services and checks are registered with an agent which then takes on the
burden of keeping that data synchronized with the cluster. For example, the
burden of keeping that data synchronized with the cluster. For example, the
agent registers services and checks with the Catalog and performs
[anti-entropy](/docs/internals/anti-entropy.html) to recover from outages.
@ -44,7 +44,7 @@ due to changes being made while there is no leader elected. The agent performs a
[anti-entropy](/docs/internals/anti-entropy.html), so in most situations everything will
be in sync within a few seconds.
This endpoint is hit with a GET and returns a JSON body like this:
This endpoint is hit with a `GET` and returns a JSON body like this:
```javascript
{
@ -71,7 +71,7 @@ due to changes being made while there is no leader elected. The agent performs a
[anti-entropy](/docs/internals/anti-entropy.html), so in most situations everything will
be in sync within a few seconds.
This endpoint is hit with a GET and returns a JSON body like this:
This endpoint is hit with a `GET` and returns a JSON body like this:
```javascript
{
@ -90,12 +90,12 @@ This endpoint is hit with a GET and returns a JSON body like this:
This endpoint is used to return the members the agent sees in the
cluster gossip pool. Due to the nature of gossip, this is eventually consistent: the
results may differ by agent. The strongly consistent view of nodes is
instead provided by "/v1/catalog/nodes".
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:
This endpoint is hit with a `GET` and returns a JSON body like:
```javascript
[
@ -124,7 +124,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:
@ -203,10 +203,10 @@ During maintenance mode, the node will be marked as unavailable and will not be
present in DNS or API queries. This API call is idempotent. Maintenance mode is
persistent and will be automatically restored on agent restart.
The `?enable` flag is required. Acceptable values are either `true` (to enter
The `?enable` flag is required. Acceptable values are either `true` (to enter
maintenance mode) or `false` (to resume normal operation).
The `?reason` flag is optional. If provided, its value should be a text string
The `?reason` flag is optional. If provided, its value should be a text string
explaining the reason for placing the node into maintenance mode. This is simply
to aid human operators. If no reason is provided, a default value will be used instead.
@ -225,18 +225,20 @@ 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"
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`
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.
@ -247,7 +249,7 @@ There is more documentation on checks [here](/docs/agent/checks.html).
Checks may be of script, HTTP, TCP, or TTL type. The agent is responsible for
managing the status of the check and keeping the Catalog in sync.
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 like:
```javascript
@ -292,25 +294,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
connection attempt is successful, the check is `passing`. If the connection
attempt is unsuccessful, the check is `critical`. In the case of a hostname
(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.
@ -338,43 +342,44 @@ The return code is 200 on success.
### <a name="agent_check_pass"></a> /v1/agent/check/pass/\<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 `passing`
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.
### <a name="agent_check_warn"></a> /v1/agent/check/warn/\<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 `warning`,
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.
### <a name="agent_check_update"></a> /v1/agent/check/update/\<checkId\>
This endpoint is used with a check that is of the [TTL type](/docs/agent/checks.html).
When this endpoint is accessed with a PUT, the status and output of the check are
When this endpoint is accessed with a `PUT`, the status and output of the check are
updated and the TTL clock is reset.
This endpoint expects a JSON request body to be put. The request body must look like:
@ -386,23 +391,27 @@ 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
The register endpoint expects a JSON request body to be `PUT`. The request
body must look like:
```javascript
@ -410,7 +419,7 @@ body must look like:
"ID": "redis1",
"Name": "redis",
"Tags": [
"master",
"primary",
"v1"
],
"Address": "127.0.0.1",
@ -426,9 +435,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.
@ -440,39 +449,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
@ -486,7 +502,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.
@ -498,12 +514,12 @@ The service maintenance endpoint allows placing a given service into
"maintenance mode". During maintenance mode, the service will be marked as
unavailable and will not be present in DNS or API queries. This API call is
idempotent. Maintenance mode is persistent and will be automatically restored
on agent restart. The maintenance endpoint expects a PUT request.
on agent restart. The maintenance endpoint expects a `PUT` request.
The `?enable` flag is required. Acceptable values are either `true` (to enter
The `?enable` flag is required. Acceptable values are either `true` (to enter
maintenance mode) or `false` (to resume normal operation).
The `?reason` flag is optional. If provided, its value should be a text string
The `?reason` flag is optional. If provided, its value should be a text string
explaining the reason for placing the service into maintenance mode. This is simply
to aid human operators. If no reason is provided, a default value will be used instead.

49
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:
@ -285,7 +284,7 @@ This endpoint supports blocking queries and all consistency modes.
The returned fields are as follows:
- `Address`: IP address of the Consul node on which the service is registered
- `Address`: IP address of the Consul node on which the service is registered
- `TaggedAddresses`: List of explicit LAN and WAN IP addresses for the agent
- `CreateIndex`: Internal index value representing when the service was created
- `ModifyIndex`: Last index that modified the service
@ -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:

6
website/source/docs/agent/http/coordinate.html.markdown
View File

@ -25,7 +25,7 @@ The following endpoints are supported:
### <a name="coordinate_datacenters"></a> /v1/coordinate/datacenters
This endpoint is hit with a GET and returns the WAN network coordinates for
This endpoint is hit with a `GET` and returns the WAN network coordinates for
all Consul servers, organized by DCs.
It returns a JSON body like this:
@ -55,9 +55,9 @@ cluster. Also, it does not support blocking queries or any consistency modes.
### <a name=""coordinate_nodes></a> /v1/coordinate/nodes
This endpoint is hit with a GET and returns the LAN network coordinates for
This endpoint is hit with a `GET` and returns the LAN network coordinates for
all nodes 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:

8
website/source/docs/agent/http/event.html.markdown
View File

@ -24,11 +24,11 @@ needs a `name`, provided on the path. The endpoint also supports several
optional parameters on the query string.
By default, the agent's local datacenter is used, but another datacenter
can be specified using the "?dc=" query parameter.
can be specified using the `?dc=` query parameter.
The fire endpoint expects a PUT request with an optional body.
The fire endpoint expects a `PUT` request with an optional body.
The body contents are opaque to Consul and become the "payload"
of the event. Names starting with the "_" prefix should be considered
of the event. Names starting with the `_` prefix should be considered
reserved for Consul's internal use.
The `?node=`, `?service=`, and `?tag=` query parameters may optionally
@ -54,7 +54,7 @@ The `ID` field uniquely identifies the newly fired event.
### <a name="event_list"></a> /v1/event/list
This endpoint is hit with a GET and returns the most recent
This endpoint is hit with a `GET` and returns the most recent
events known by the agent. As a consequence of how the
[event command](/docs/commands/event.html) works, each agent
may have a different view of the events. Events are broadcast using

38
website/source/docs/agent/http/health.html.markdown
View File

@ -24,9 +24,9 @@ All of the health endpoints support blocking queries and all consistency modes.
### <a name="health_node"></a> /v1/health/node/\<node\>
This endpoint is hit with a GET and returns the checks specific to the node
This endpoint is hit with a `GET` and returns the checks specific to the node
provided on the path. 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:
@ -56,7 +56,7 @@ It returns a JSON body like this:
```
In this case, we can see there is a system level check (that is, a check with
no associated `ServiceID`) as well as a service check for Redis. The "serfHealth" check
no associated `ServiceID`) as well as a service check for Redis. The `serfHealth` check
is special in that it is automatically present on every node. When a node
joins the Consul cluster, it is part of a distributed failure detection
provided by Serf. If a node fails, it is detected and the status is automatically
@ -66,13 +66,13 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="health_checks"></a> /v1/health/checks/\<service\>
This endpoint is hit with a GET and returns the checks associated with
This endpoint is hit with a `GET` and returns the checks associated with
the service provided on the path. 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:
@ -96,23 +96,23 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="health_service"></a> /v1/health/service/\<service\>
This endpoint is hit with a GET and returns the nodes providing
This endpoint is hit with a `GET` and returns the nodes providing
the service indicated on the path. 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.
By default, all nodes matching the service are returned. The list can be filtered
by tag using the "?tag=" query parameter.
Providing the "?passing" query parameter, added in Consul 0.2, will filter results
to only nodes with all checks in the `passing` state. This can be used to avoid extra filtering
logic on the client side.
Providing the `?passing` query parameter, added in Consul 0.2, will
filter results to only nodes with all checks in the `passing` state.
This can be used to avoid extra filtering logic on the client side.
This endpoint is very similar to the /v1/catalog/service endpoint; however, this
This endpoint is very similar to the `/v1/catalog/service` endpoint; however, this
endpoint automatically returns the status of the associated health check
as well as any system level health checks. This allows a client to avoid
sending traffic to nodes that are failing health tests or reporting warnings.
@ -170,13 +170,13 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="health_state"></a> /v1/health/state/\<state\>
This endpoint is hit with a GET and returns the checks in the
This endpoint is hit with a `GET` and returns the checks in the
state provided on the path. 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.
The supported states are `any`, `passing`, `warning`, or `critical`.

75
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.
@ -138,13 +139,13 @@ the update has not taken place.
#### DELETE method
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:
a prefix. There are a few query parameters that can be used with a
`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

74
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.
@ -272,10 +276,10 @@ only a single catch-all template can be registered at any time.
#### GET Method
When using the GET method, Consul will provide a listing of all prepared queries.
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`.

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

@ -26,7 +26,7 @@ The create endpoint is used to initialize a new session.
There is more documentation on sessions [here](/docs/internals/sessions.html).
Sessions must be associated with a node and may be associated with any number of checks.
The create endpoint expects a JSON request body to be PUT. The request
The create endpoint expects a JSON request body to be `PUT`. The request
body must look like:
```javascript
@ -44,10 +44,10 @@ None of the fields are mandatory, and in fact no body needs to be PUT
if the defaults are to be used.
By default, the agent's local datacenter is used; another datacenter
can be specified using the "?dc=" query parameter. However, it is not recommended
can be specified using the `?dc=` query parameter. However, it is not recommended
to use cross-datacenter sessions.
`LockDelay` can be specified as a duration string using a "s" suffix for
`LockDelay` can be specified as a duration string using an `s` suffix for
seconds. The default is 15s.
`Node` must refer to a node that is already registered, if specified. By default,
@ -56,15 +56,15 @@ 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`,
the behavior when a session is invalidated. By default, this is `release`,
causing any locks that are held to be released. Changing this to `delete`
causes any locks that are held to be deleted. `delete` is useful for creating ephemeral
key/value entries.
The `TTL` field is a duration string, and like `LockDelay` it can use "s" as
The `TTL` field is a duration string, and like `LockDelay` it can use `s` as
a suffix for seconds. If specified, it must be between 10s and 86400s currently.
When provided, the session is invalidated if it is not renewed before the TTL
expires. The lowest practical TTL should be used to keep the number of managed
@ -83,8 +83,8 @@ 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
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
can be used to specify the datacenter.
The session being destroyed must be provided on the path.
@ -93,9 +93,9 @@ The return code is 200 on success.
### <a name="session_info"></a> /v1/session/info/\<session\>
This endpoint is hit with a GET and returns the requested session information
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:
@ -119,9 +119,9 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="session_node"></a> /v1/session/node/\<node\>
This endpoint is hit with a GET and returns the active sessions
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.
@ -146,9 +146,9 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="session_list"></a> /v1/session/list
This endpoint is hit with a GET and returns the active sessions
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:
@ -171,14 +171,14 @@ This endpoint supports blocking queries and all consistency modes.
### <a name="session_renew"></a> /v1/session/renew/\<session\>
The renew endpoint is hit with a PUT and renews the given session.
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.
The return code is 200 on success. The response JSON body looks like this:
The return code is 200 on success. The response JSON body looks like this:
```javascript
[
@ -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.

6
website/source/docs/agent/http/snapshot.html.markdown
View File

@ -51,11 +51,11 @@ internal to Consul and not intended to be used other than for restore operations
In particular, the archives are not designed to be modified before a restore.
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.
By default, snapshots use consistent mode which means the request is internally
forwarded to the cluster leader, and leadership is checked before performing the
snapshot. If `stale` is specified using the "?stale" query parameter, then any
snapshot. If `stale` is specified using the `?stale` query parameter, then any
server can handle the request and the results may be arbitrarily stale. To support
bounding the acceptable staleness of snapshots, responses provide the `X-Consul-LastContact`
header containing the time in milliseconds that a server was last contacted by
@ -83,7 +83,7 @@ intended to be used when recovering from a disaster, restoring into a fresh
cluster of Consul servers.
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 management
privileges.

26
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.
@ -578,9 +578,9 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
* <a name="udp_answer_limit"></a><a
href="#udp_answer_limit">`udp_answer_limit`</a> - Limit the number of
resource records contained in the answer section of a UDP-based DNS
response. When answering a question, Consul will use the complete list of
response. When answering a question, Consul will use the complete list of
matching hosts, shuffle the list randomly, and then limit the number of
answers to `udp_answer_limit` (default `3`). In environments where
answers to `udp_answer_limit` (default `3`). In environments where
[RFC 3484 Section 6](https://tools.ietf.org/html/rfc3484#section-6) Rule 9
is implemented and enforced (i.e. DNS answers are always sorted and
therefore never random), clients may need to set this value to `1` to
@ -744,12 +744,12 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
* <a name="skip_leave_on_interrupt"></a><a
href="#skip_leave_on_interrupt">`skip_leave_on_interrupt`</a> This is
similar to [`leave_on_terminate`](#leave_on_terminate) but only affects
interrupt handling. When Consul receives an interrupt signal (such as
interrupt handling. When Consul receives an interrupt signal (such as
hitting Control-C in a terminal), Consul will gracefully leave the cluster.
Setting this to `true` disables that behavior. The default behavior for
Setting this to `true` disables that behavior. The default behavior for
this feature varies based on whether or not the agent is running as a
client or a server (prior to Consul 0.7 the default value was
unconditionally set to `false`). On agents in client-mode, this defaults
unconditionally set to `false`). On agents in client-mode, this defaults
to `false` and for agents in server-mode, this defaults to `true`
(i.e. Ctrl-C on a server will keep the server in the cluster and therefore
quorum, and Ctrl-C on a client will gracefully leave).
@ -764,7 +764,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
sends its runtime telemetry, and contains the following keys:
* <a name="telemetry-statsd_address"></a><a href="#telemetry-statsd_address">`statsd_address`</a> This provides the
address of a statsd instance in the format `host:port`. If provided, Consul will send various telemetry information to that instance for
address of a statsd instance in the format `host:port`. If provided, Consul will send various telemetry information to that instance for
aggregation. This can be used to capture runtime information. This sends UDP packets only and can be used with
statsd or statsite.
@ -811,7 +811,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
Force activation of metrics which already exist and are not currently active. If check management is enabled, the default behavior is to add new metrics as they are encoutered. If the metric already exists in the check, it will **not** be activated. This setting overrides that behavior. By default, this is set to false.
* <a name="telemetry-circonus_check_instance_id"></a><a href="#telemetry-circonus_check_instance_id">`circonus_check_instance_id`</a>
Uniquely identifies the metrics coming from this *instance*. It can be used to maintain metric continuity with transient or ephemeral instances as they move around within an infrastructure. By default, this is set to hostname:application name (e.g. "host123:consul").
Uniquely identifies the metrics coming from this *instance*. It can be used to maintain metric continuity with transient or ephemeral instances as they move around within an infrastructure. By default, this is set to hostname:application name (e.g. "host123:consul").
* <a name="telemetry-circonus_check_search_tag"></a><a href="#telemetry-circonus_check_search_tag">`circonus_check_search_tag`</a>
A special tag which, when coupled with the instance id, helps to narrow down the search results when neither a Submission URL or Check ID is provided. By default, this is set to service:application name (e.g. "service:consul").
@ -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.

12
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.
@ -64,10 +64,10 @@ The list of available flags are:
* `-wait-repl` - Period to wait after writing the job specification for replication.
This is a heuristic value and enables agents to do a stale read of the job. Defaults
to 200msec.
to 200 msec.
* `-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:

12
website/source/docs/commands/watch.html.markdown
View File

@ -13,7 +13,7 @@ Command: `consul watch`
The `watch` command provides a mechanism to watch for changes in a particular
data view (list of nodes, service members, key value, etc) and to invoke
a process with the latest values of the view. If no process is specified,
the current values are dumped to stdout which can be a useful way to inspect
the current values are dumped to STDOUT which can be a useful way to inspect
data in Consul.
There is more [documentation on watches here](/docs/agent/watches.html).
@ -33,9 +33,9 @@ The list of available flags are:
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.
* `-datacenter` - Datacenter to query. Defaults to that of agent.
* `-datacenter` - Datacenter to query. Defaults to that of the agent.
* `-token` - ACL token to use. Defaults to that of agent.
* `-token` - ACL token to use. Defaults to that of the agent.
* `-stale=[true|false]` - Specifies if watch data is permitted to be stale. Defaults
to false.
@ -45,7 +45,7 @@ The list of available flags are:
* `-name`- Event name to watch. Only for `event` type.
* `-passingonly=[true|false]` - Should only passing entries be returned. Defaults to
false and only applies for `service` type.
`false` and only applies for `service` type.
* `-prefix` - Key prefix to watch. Only for `keyprefix` type.
@ -55,6 +55,6 @@ The list of available flags are:
* `-tag` - Service tag to filter on. Optional for `service` type.
* `-type` - Watch type. Required, one of "key", "keyprefix", "services",
"nodes", "service", "checks", or "event".
* `-type` - Watch type. Required, one of "`key`, `keyprefix`, `services`,
`nodes`, `service`, `checks`, or `event`.

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

4
website/source/docs/faq.html.markdown
View File

@ -62,8 +62,8 @@ the current state of the catalog can lag behind until the state is reconciled.
To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_
states), Consul will automatically remove dead nodes out of the catalog. This
process is called _reaping_. This is currently done on a configurable
interval of 72 hours. Reaping is similar to leaving, causing all associated
services to be deregistered. Changing the reap interval for aesthetic
interval of 72 hours. Reaping is similar to leaving, causing all associated
services to be deregistered. Changing the reap interval for aesthetic
reasons to trim the number of _failed_ or _left_ nodes is not advised (nodes
in the _failed_ or _left_ state do not cause any additional burden on
Consul).

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

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

@ -3,31 +3,34 @@ layout: "docs"
page_title: "Forwarding"
sidebar_current: "docs-guides-forwarding"
description: |-
By default, DNS is served from port 53. On most operating systems, this 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.
By default, DNS is served from port 53. On most operating systems, this 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.
---
# Forwarding DNS
By default, DNS is served from port 53. On most operating systems, this
By default, DNS is served from port 53. On most operating systems, this
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
[recursors](/docs/agent/options.html#recursors) configuration option
has been set. As an example of how this changes Consul's behavior,
has been set. As an example of how this changes Consul's behavior,
suppose a Consul DNS reply includes a CNAME record pointing outside
the `.consul` TLD. The DNS reply will only include CNAME records by
default. By contrast, when `recursors` is set and the upstream resolver is
functioning correctly, Consul will try to resolve CNAMEs and include
any records (e.g. A, AAAA, PTR) for them in its DNS reply.
any records (e.g. A, AAAA, PTR) for them in its DNS reply.
You can either do one of the following:
@ -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 {
@ -77,7 +80,7 @@ DNS on port 8600.
### Dnsmasq Setup
Dnsmasq is typically configured via a `dnsmasq.conf` or a series of files in
the `/etc/dnsmasq.d` directory. In Dnsmasq's configuration file
the `/etc/dnsmasq.d` directory. In Dnsmasq's configuration file
(e.g. `/etc/dnsmasq.d/10-consul`), add the following:
```text
@ -115,8 +118,8 @@ for additional details):
#no-resolv
# Specify IP address(es) of other DNS servers for queries not handled
# directly by consul. There is normally one 'server' entry set for every
# 'nameserver' parameter found in '/etc/resolv.conf'. See dnsmasq(8)'s
# directly by consul. There is normally one 'server' entry set for every
# 'nameserver' parameter found in '/etc/resolv.conf'. See dnsmasq(8)'s
# 'server' configuration option for details.
#server=1.2.3.4
#server=208.67.222.222
@ -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.

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

@ -15,18 +15,19 @@ Depending on your
may take only a single server failure for cluster unavailability. Recovery
requires an operator to intervene, but the process is straightforward.
~> This guide is for recovery from a Consul outage due to a majority
~> This guide is for recovery from a Consul outage due to a majority
of server nodes in a datacenter being lost. If you are just looking to
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/`

5
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
@ -130,7 +129,7 @@ has not declared the node unhealthy. Additional checks can be specified if desir
Watching for changes is done via a blocking query against `<prefix>`. If a contender
holds a slot, then on any change the `<lock>` should be re-checked to ensure the slot is
still held. If no slot is held, then the same acquisition logic is triggered to check
still held. If no slot is held, then the same acquisition logic is triggered to check
and potentially re-attempt acquisition. This allows a contender to steal the slot from
a failed contender or one that has voluntarily released its slot.

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

@ -17,7 +17,7 @@ on tokens to which fine grained rules can be applied. It is very similar to
## Scope
When the ACL system was launched in Consul 0.4, it was only possible to specify
policies for the KV store. In Consul 0.5, ACL policies were extended to service
policies for the KV store. In Consul 0.5, ACL policies were extended to service
registrations. In Consul 0.6, ACL's were further extended to restrict service
discovery mechanisms, user events, and encryption keyring operations.
@ -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

2
website/source/intro/getting-started/checks.html.markdown
View File

@ -43,7 +43,7 @@ The first definition adds a host-level check named "ping". This check runs
on a 30 second interval, invoking `ping -c1 google.com`. On a `script`-based
health check, the check runs as the same user that started the Consul process.
If the command exits with a non-zero exit code, then the node will be flagged
unhealthy. This is the contract for any `script`-based health check.
unhealthy. This is the contract for any `script`-based health check.
The second command modifies the service named `web`, adding a check that sends a
request every 10 seconds via curl to verify that the web server is accessible.

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

@ -17,8 +17,8 @@ be extended to a scalable, production-grade service discovery infrastructure.
In this step, we'll create our first real cluster with multiple members.
When a Consul agent is started, it begins without knowledge of any other node:
it is an isolated cluster of one. To learn about other cluster members, the
agent must _join_ an existing cluster. To join an existing cluster, it only
it is an isolated cluster of one. To learn about other cluster members, the
agent must _join_ an existing cluster. To join an existing cluster, it only
needs to know about a _single_ existing member. After it joins, the agent will
gossip with this member and quickly discover the other members in the cluster.
A Consul agent can join any other agent, not just agents in server mode.

2
website/source/intro/getting-started/ui.html.markdown
View File

@ -61,6 +61,6 @@ You can view a live demo of the Consul Web UI
## Next Steps
This concludes our Getting Started guide. See the
This concludes our Getting Started guide. See the
[next steps](next-steps.html) page to learn more about how to continue
your journey with Consul!