commit
ee16675eda
|
@ -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
|
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.
|
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.
|
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
|
-> **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.
|
||||||
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
|
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
|
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
|
states), Consul will automatically remove dead nodes out of the catalog. This
|
||||||
process is called _reaping_. This is currently done on a configurable
|
process is called _reaping_. This is currently done on a configurable
|
||||||
interval of 72 hours (changing the reap interval is *not* recommended due to
|
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.
|
causing all associated services to be deregistered.
|
||||||
|
|
|
@ -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
|
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.
|
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.
|
created via the HTTP interface persist with that node.
|
||||||
|
|
||||||
There are five different kinds of checks:
|
There are five different kinds of checks:
|
||||||
|
|
|
@ -14,16 +14,16 @@ discovery without any high-touch integration with Consul.
|
||||||
|
|
||||||
For example, instead of making HTTP API requests to Consul,
|
For example, instead of making HTTP API requests to Consul,
|
||||||
a host can use the DNS server directly via name lookups
|
a host can use the DNS server directly via name lookups
|
||||||
like "redis.service.east-aws.consul". This query automatically
|
like `redis.service.us-east-1.consul`. This query automatically
|
||||||
translates to a lookup of nodes that provide the redis service,
|
translates to a lookup of nodes that provide the `redis` service,
|
||||||
are located in the "east-aws" datacenter, and have no failing health checks.
|
are located in the `us-east-1` datacenter, and have no failing health checks.
|
||||||
It's that simple!
|
It's that simple!
|
||||||
|
|
||||||
There are a number of configuration options that are important for the DNS interface,
|
There are a number of configuration options that are important for the DNS interface,
|
||||||
specifically [`client_addr`](/docs/agent/options.html#client_addr),
|
specifically [`client_addr`](/docs/agent/options.html#client_addr),
|
||||||
[`ports.dns`](/docs/agent/options.html#dns_port), [`recursors`](/docs/agent/options.html#recursors),
|
[`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).
|
[`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
|
domain, without support for further DNS recursion. Please consult the
|
||||||
[documentation on configuration options](/docs/agent/options.html),
|
[documentation on configuration options](/docs/agent/options.html),
|
||||||
specifically the configuration items linked above, for more details.
|
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
|
$ 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`
|
-> **Note:** In DNS, all queries are case-insensitive. A lookup of `PostgreSQL.node.dc1.consul` will find all nodes named `postgresql`.
|
||||||
will find all nodes named `postgresql`.
|
|
||||||
|
|
||||||
## Node Lookups
|
## 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>
|
<node>.node[.datacenter].<domain>
|
||||||
|
|
||||||
For example, if we have a "foo" node with default settings, we could look for
|
For example, if we have a `foo` node with default settings, we could
|
||||||
"foo.node.dc1.consul." The datacenter is an optional part of the FQDN: if not
|
look for `foo.node.dc1.consul.` The datacenter is an optional part of
|
||||||
provided, it defaults to the datacenter of the agent. If we know "foo" is running in
|
the FQDN: if not provided, it defaults to the datacenter of the agent.
|
||||||
the same datacenter as our local agent, we can instead use "foo.node.consul." This
|
If we know `foo` is running in the same datacenter as our local agent,
|
||||||
convention allows for terse syntax where appropriate while supporting queries of
|
we can instead use `foo.node.consul.` This convention allows for terse
|
||||||
nodes in remote datacenters as necessary.
|
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
|
For a node lookup, the only records returned are A records containing
|
||||||
the node.
|
the IP address of the node.
|
||||||
|
|
||||||
```text
|
```text
|
||||||
$ dig @127.0.0.1 -p 8600 foo.node.consul ANY
|
$ 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
|
## 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).
|
two lookup methods: standard and strict [RFC 2782](https://tools.ietf.org/html/rfc2782).
|
||||||
|
|
||||||
### Standard Lookup
|
### Standard Lookup
|
||||||
|
@ -92,13 +92,14 @@ The format of a standard service lookup is:
|
||||||
|
|
||||||
[tag.]<service>.service[.datacenter].<domain>
|
[tag.]<service>.service[.datacenter].<domain>
|
||||||
|
|
||||||
The `tag` is optional, and, as with node lookups, the `datacenter` is as well. If no tag is
|
The `tag` is optional, and, as with node lookups, the `datacenter` is as
|
||||||
provided, no filtering is done on tag. If no datacenter is provided, the datacenter of
|
well. If no tag is provided, no filtering is done on tag. If no
|
||||||
this Consul agent is assumed.
|
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
|
If we want to find any redis service providers in our local datacenter,
|
||||||
"redis.service.consul." If we want to find the PostgreSQL master in a particular datacenter,
|
we could query `redis.service.consul.` If we want to find the PostgreSQL
|
||||||
we could query "master.postgresql.service.dc2.consul."
|
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
|
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
|
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]
|
_<service>._<protocol>.service[.datacenter][.domain]
|
||||||
|
|
||||||
Per [RFC 2782](https://tools.ietf.org/html/rfc2782), SRV queries should use
|
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
|
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.
|
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.
|
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",
|
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":
|
you could make an RFC 2782 query for its SRV record as `_rabbitmq._amqp.service.consul`:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
$ dig @127.0.0.1 -p 8600 _rabbitmq._amqp.service.consul SRV
|
$ dig @127.0.0.1 -p 8600 _rabbitmq._amqp.service.consul SRV
|
||||||
|
|
|
@ -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
|
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.
|
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
|
[`consul keygen`](/docs/commands/keygen.html) command to generate a
|
||||||
cryptographically suitable key:
|
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
|
Certificate Authority. This can be a private CA, used only internally. The
|
||||||
CA then signs keys for each of the agents, as in
|
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)
|
[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
|
using OpenSSL.
|
||||||
[Extended Key Usage](https://www.openssl.org/docs/manmaster/man5/x509v3_config.html#Extended-Key-Usage) enabled
|
|
||||||
for client and server authentication.
|
-> **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.
|
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),
|
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
|
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
|
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
|
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
|
to true, and generate the proper certificates, but this is defaulted to false to avoid breaking
|
||||||
existing deployments.
|
existing deployments.
|
||||||
|
|
||||||
|
|
|
@ -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.
|
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
|
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
|
`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
|
query string parameter to the value of `X-Consul-Index`, indicating that the client wishes
|
||||||
to wait for any changes subsequent to that index.
|
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
|
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
|
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
|
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
|
* 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
|
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
|
## 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.
|
on the query string, formatted JSON will be returned.
|
||||||
|
|
||||||
## ACLs
|
## ACLs
|
||||||
|
|
|
@ -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
|
to a root user and has the ability to perform any action including
|
||||||
creating, modifying, and deleting ACLs.
|
creating, modifying, and deleting ACLs.
|
||||||
|
|
||||||
By constrast, a client token can only perform actions as permitted by the
|
By contrast, a client token can only perform actions as permitted by the
|
||||||
rules associated. Client tokens can never manage ACLs. Given this limitation,
|
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`
|
only a management token can be used to make requests to the `/v1/acl/create`
|
||||||
endpoint.
|
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
|
all requests are automatically routed to that datacenter regardless
|
||||||
of the agent to which the request is made.
|
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:
|
body may take the form:
|
||||||
|
|
||||||
```javascript
|
```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
|
defaults are to be used. The `Name` and `Rules` fields default to being
|
||||||
blank, and the `Type` defaults to "client".
|
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
|
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),
|
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
|
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
|
In any Consul cluster, only a single datacenter is authoritative for ACLs, so
|
||||||
all requests are automatically routed to that datacenter regardless
|
all requests are automatically routed to that datacenter regardless
|
||||||
of the agent to which the request is made.
|
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:
|
body may look like:
|
||||||
|
|
||||||
```javascript
|
```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\>
|
### <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.
|
token identified by the `id` portion of the path.
|
||||||
|
|
||||||
The request is automatically routed to the authoritative ACL datacenter.
|
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\>
|
### <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.
|
token information identified by the `id` portion of the path.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
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\>
|
### <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
|
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
|
a token to serve as a template for others, making it simple to generate new
|
||||||
tokens without complex rule management.
|
tokens without complex rule management.
|
||||||
|
@ -148,7 +148,7 @@ created ACL, like so:
|
||||||
|
|
||||||
### <a name="acl_list"></a> /v1/acl/list
|
### <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
|
ACL tokens. This is a privileged endpoint and requires a
|
||||||
management token.
|
management token.
|
||||||
|
|
||||||
|
@ -171,12 +171,12 @@ It returns a JSON body like this:
|
||||||
### <a name="acl_replication_status"></a> /v1/acl/replication
|
### <a name="acl_replication_status"></a> /v1/acl/replication
|
||||||
|
|
||||||
Available in Consul 0.7 and later, the endpoint must be hit with a
|
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
|
process in the datacenter. This is intended to be used by operators, or by
|
||||||
automation checking the health of ACL replication.
|
automation checking the health of ACL replication.
|
||||||
|
|
||||||
By default, the datacenter of the agent is queried; however, the dc can be provided
|
By default, the datacenter of the agent is queried; however, the `dc` can be provided
|
||||||
using the "?dc=" query parameter.
|
using the `?dc=` query parameter.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
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
|
`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)
|
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
|
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
|
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.
|
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.
|
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
|
`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
|
Since ACL replication is done with a blocking query, this may not update
|
||||||
to 5 minutes if there have been no ACL changes to replicate. A zero value of
|
for up to 5 minutes if there have been no ACL changes to replicate. A
|
||||||
"0001-01-01T00:00:00Z" will be present if no sync has been successful.
|
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.
|
`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
|
If this time is later than `LastSuccess`, you can assume the replication process
|
||||||
|
|
|
@ -10,7 +10,7 @@ description: >
|
||||||
|
|
||||||
The Agent endpoints are used to interact with the local Consul agent. Usually,
|
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
|
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
|
agent registers services and checks with the Catalog and performs
|
||||||
[anti-entropy](/docs/internals/anti-entropy.html) to recover from outages.
|
[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
|
[anti-entropy](/docs/internals/anti-entropy.html), so in most situations everything will
|
||||||
be in sync within a few seconds.
|
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
|
```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
|
[anti-entropy](/docs/internals/anti-entropy.html), so in most situations everything will
|
||||||
be in sync within a few seconds.
|
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
|
```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
|
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
|
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
|
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.
|
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
|
```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.
|
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:
|
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
|
present in DNS or API queries. This API call is idempotent. Maintenance mode is
|
||||||
persistent and will be automatically restored on agent restart.
|
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).
|
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
|
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.
|
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\>
|
### <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
|
This endpoint is hit with a `GET` and is used to instruct the agent to attempt to
|
||||||
connect to a given address. For agents running in server mode, providing a "?wan=1"
|
connect to a given address. For agents running in server mode, providing a `?wan=1`
|
||||||
query parameter causes the agent to attempt to join using the WAN pool.
|
query parameter causes the agent to attempt to join using the WAN pool.
|
||||||
|
|
||||||
The return code is 200 on success.
|
The return code is 200 on success.
|
||||||
|
|
||||||
### <a name="agent_force_leave"></a> /v1/agent/force-leave/\<node\>
|
### <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.
|
This endpoint is hit with a `GET` and is used to instruct the agent to
|
||||||
If a node fails unexpectedly, then it will be in a `failed` state. Once in the `failed` state, Consul will
|
force a node into the `left` state. If a node fails unexpectedly, then
|
||||||
attempt to reconnect, and the services and checks belonging to that node will not be
|
it will be in a `failed` state. Once in the `failed` state, Consul will
|
||||||
cleaned up. Forcing a node into the `left` state allows its old entries to be removed.
|
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.
|
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
|
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.
|
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:
|
body must look like:
|
||||||
|
|
||||||
```javascript
|
```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
|
evaluate the script every `Interval` in the given container using the specified
|
||||||
`Shell`. Note that `Shell` is currently only supported for Docker checks.
|
`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
|
An `HTTP` check will perform an HTTP `GET` request against the value of
|
||||||
be a URL) every `Interval`. If the response is any `2xx` code, the check is `passing`.
|
`HTTP` (expected to be a URL) every `Interval`. If the response is any
|
||||||
If the response is `429 Too Many Requests`, the check is `warning`. Otherwise, the check
|
`2xx` code, the check is `passing`. If the response is `429 Too Many
|
||||||
is `critical`. HTTP checks also support SSL. By default, a valid SSL certificate is expected.
|
Requests`, the check is `warning`. Otherwise, the check is `critical`.
|
||||||
Certificate verification can be controlled using the `TLSSkipVerify`.
|
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,
|
If `TLSSkipVerify` is set to `true`, certificate verification will be
|
||||||
certificate verification is enabled.
|
disabled. By default, certificate verification is enabled.
|
||||||
|
|
||||||
A `TCP` check will perform an TCP connection attempt against the value of `TCP`
|
A `TCP` check will perform an TCP connection attempt against the value of `TCP`
|
||||||
(expected to be an IP/hostname and port combination) every `Interval`. If the
|
(expected to be an IP or hostname plus port combination) every `Interval`. If the
|
||||||
connection attempt is successful, the check is `passing`. If the connection
|
connection attempt is successful, the check is `passing`. If the connection
|
||||||
attempt is unsuccessful, the check is `critical`. In the case of a hostname
|
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
|
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
|
addresses, and the first successful connection attempt will result in a
|
||||||
successful check.
|
successful check.
|
||||||
|
|
||||||
If a `TTL` type is used, then the TTL update endpoint must be used periodically to update
|
If a `TTL` type is used, then the TTL update endpoint must be used
|
||||||
the state of the check.
|
periodically to update the state of the check.
|
||||||
|
|
||||||
The `ServiceID` field can be provided to associate the registered check with an
|
The `ServiceID` field can be provided to associate the registered check with an
|
||||||
existing service provided by the agent.
|
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\>
|
### <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).
|
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.
|
and the TTL clock is reset.
|
||||||
|
|
||||||
The optional "?note=" query parameter can be used to associate a human-readable message
|
The optional `?note=` query parameter can be used to associate a
|
||||||
with the status of the check. This will be passed through to the check's `Output` field
|
human-readable message with the status of the check. This will be passed
|
||||||
in the check endpoints.
|
through to the check's `Output` field in the check endpoints.
|
||||||
|
|
||||||
The return code is 200 on success.
|
The return code is 200 on success.
|
||||||
|
|
||||||
### <a name="agent_check_warn"></a> /v1/agent/check/warn/\<checkId\>
|
### <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).
|
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.
|
and the TTL clock is reset.
|
||||||
|
|
||||||
The optional "?note=" query parameter can be used to associate a human-readable message
|
The optional `?note=` query parameter can be used to associate a
|
||||||
with the status of the check. This will be passed through to the check's `Output` field
|
human-readable message with the status of the check. This will be passed
|
||||||
in the check endpoints.
|
through to the check's `Output` field in the check endpoints.
|
||||||
|
|
||||||
The return code is 200 on success.
|
The return code is 200 on success.
|
||||||
|
|
||||||
### <a name="agent_check_fail"></a> /v1/agent/check/fail/\<checkId\>
|
### <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).
|
This endpoint is used with a check that is of the [TTL
|
||||||
When this endpoint is accessed via a GET, the status of the check is set to `critical`,
|
type](/docs/agent/checks.html). When this endpoint is accessed via a
|
||||||
and the TTL clock is reset.
|
`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
|
The optional `?note=` query parameter can be used to associate a
|
||||||
with the status of the check. This will be passed through to the check's `Output` field
|
human-readable message with the status of the check. This will be passed
|
||||||
in the check endpoints.
|
through to the check's `Output` field in the check endpoints.
|
||||||
|
|
||||||
The return code is 200 on success.
|
The return code is 200 on success.
|
||||||
|
|
||||||
### <a name="agent_check_update"></a> /v1/agent/check/update/\<checkId\>
|
### <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).
|
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.
|
updated and the TTL clock is reset.
|
||||||
|
|
||||||
This endpoint expects a JSON request body to be put. The request body must look like:
|
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
|
`Output` is an optional field that will associate a human-readable
|
||||||
of the check, such as the output of the checking script or process. This will be truncated
|
message with the status of the check, such as the output of the checking
|
||||||
if it exceeds 4KB in size. This will be passed through to the check's `Output` field in the
|
script or process. This will be truncated if it exceeds 4KB in size.
|
||||||
check endpoints.
|
This will be passed through to the check's `Output` field in the check
|
||||||
|
endpoints.
|
||||||
|
|
||||||
The return code is 200 on success.
|
The return code is 200 on success.
|
||||||
|
|
||||||
### <a name="agent_service_register"></a> /v1/agent/service/register
|
### <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,
|
The register endpoint is used to add a new service, with an optional
|
||||||
to the local agent. There is more documentation on services [here](/docs/agent/services.html).
|
health check, to the local agent. There is more documentation on
|
||||||
The agent is responsible for managing the status of its local services, and for sending updates
|
services [here](/docs/agent/services.html). The agent is responsible
|
||||||
about its local services to the servers to keep the global Catalog in sync.
|
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:
|
body must look like:
|
||||||
|
|
||||||
```javascript
|
```javascript
|
||||||
|
@ -410,7 +419,7 @@ body must look like:
|
||||||
"ID": "redis1",
|
"ID": "redis1",
|
||||||
"Name": "redis",
|
"Name": "redis",
|
||||||
"Tags": [
|
"Tags": [
|
||||||
"master",
|
"primary",
|
||||||
"v1"
|
"v1"
|
||||||
],
|
],
|
||||||
"Address": "127.0.0.1",
|
"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`.
|
The `Name` field is mandatory. If an `ID` is not provided, it is set to
|
||||||
You cannot have duplicate `ID` entries per agent, so it may be necessary to provide an ID
|
`Name`. You cannot have duplicate `ID` entries per agent, so it may be
|
||||||
in the case of a collision.
|
necessary to provide an ID in the case of a collision.
|
||||||
|
|
||||||
`Tags`, `Address`, `Port`, `Check` and `EnableTagOverride` are optional.
|
`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
|
associated with that instance of the service, which is returned alongside the service
|
||||||
information.
|
information.
|
||||||
|
|
||||||
If `Check` is provided, only one of `Script`, `HTTP`, `TCP` or `TTL` should be specified.
|
If `Check` is provided, only one of `Script`, `HTTP`, `TCP` or `TTL`
|
||||||
`Script` and `HTTP` also require `Interval`. The created check will be named "service:\<ServiceId\>".
|
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
|
In Consul 0.7 and later, checks that are associated with a service may
|
||||||
an optional `DeregisterCriticalServiceAfter` field, which is a timeout in the same Go time
|
also contain an optional `DeregisterCriticalServiceAfter` field, which
|
||||||
format as `Interval` and `TTL`. If a check is in the critical state for more than this
|
is a timeout in the same [Go time format](https://golang.org/pkg/time/)
|
||||||
configured value, then its associated service (and all of its associated checks)
|
as `Interval` and `TTL`. If a check is in the critical state for more
|
||||||
will automatically be deregistered. The minimum timeout is 1 minute, and the
|
than this configured value, then its associated service (and all of its
|
||||||
process that reaps critical services runs every 30 seconds, so it may take slightly
|
associated checks) will automatically be deregistered. The minimum
|
||||||
longer than the configured timeout to trigger the deregistration. This should
|
timeout is 1 minute, and the process that reaps critical services runs
|
||||||
generally be configured with a timeout that's much, much longer than any expected
|
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.
|
recoverable outage for the given service.
|
||||||
|
|
||||||
There is more information about checks [here](/docs/agent/checks.html).
|
There is more information about checks [here](/docs/agent/checks.html).
|
||||||
|
|
||||||
`EnableTagOverride` can optionally be specified to disable the anti-entropy
|
The `EnableTagOverride` option can be specified to disable the
|
||||||
feature for this service's tags. If `EnableTagOverride` is set to `true` then external
|
anti-entropy feature for this service's tags. If `EnableTagOverride` is
|
||||||
agents can update this service in the [catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
|
set to `true` then external agents can update this service in the
|
||||||
local sync operations by this agent will ignore the updated tags. For instance, if an external agent
|
[catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
|
||||||
modified both the tags and the port for this service and `EnableTagOverride`
|
local sync operations by this agent will ignore the updated tags. For
|
||||||
was set to `true` then after the next sync cycle the service's port would revert
|
instance, if an external agent modified both the tags and the port for
|
||||||
to the original value but the tags would maintain the updated value. As a
|
this service and `EnableTagOverride` was set to `true` then after the
|
||||||
counter example, if an external agent modified both the tags and port for this
|
next sync cycle the service's port would revert to the original value
|
||||||
service and `EnableTagOverride` was set to `false` then after the next sync
|
but the tags would maintain the updated value. As a counter example, if
|
||||||
cycle the service's port _and_ the tags would revert to the original value and
|
an external agent modified both the tags and port for this service and
|
||||||
all modifications would be lost. It's important to note that this applies only
|
`EnableTagOverride` was set to `false` then after the next sync cycle
|
||||||
to the locally registered service. If you have multiple nodes all registering
|
the service's port _and_ the tags would revert to the original value and
|
||||||
the same service their `EnableTagOverride` configuration and all other service
|
all modifications would be lost.
|
||||||
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)
|
It's important to note that this applies only to the locally registered
|
||||||
registered on another node. If `EnableTagOverride` is not specified the default
|
service. If you have multiple nodes all registering the same service
|
||||||
value is `false`. See [anti-entropy syncs](/docs/internals/anti-entropy.html)
|
their `EnableTagOverride` configuration and all other service
|
||||||
for more info.
|
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
|
This endpoint supports [ACL tokens](/docs/internals/acl.html). If the query
|
||||||
string includes a `?token=<token-id>`, the registration will use the provided
|
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\>
|
### <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 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
|
of deregistering the service with the Catalog. If there is an associated
|
||||||
check, that is also deregistered.
|
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
|
"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
|
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
|
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).
|
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
|
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.
|
to aid human operators. If no reason is provided, a default value will be used instead.
|
||||||
|
|
||||||
|
|
|
@ -28,11 +28,11 @@ tunable consistency modes.
|
||||||
### <a name="catalog_register"></a> /v1/catalog/register
|
### <a name="catalog_register"></a> /v1/catalog/register
|
||||||
|
|
||||||
The register endpoint is a low-level mechanism for registering or updating
|
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
|
[agent endpoints](agent.html) for registration as they are simpler and perform
|
||||||
[anti-entropy](/docs/internals/anti-entropy.html).
|
[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:
|
body must look something like:
|
||||||
|
|
||||||
```javascript
|
```javascript
|
||||||
|
@ -48,7 +48,7 @@ body must look something like:
|
||||||
"ID": "redis1",
|
"ID": "redis1",
|
||||||
"Service": "redis",
|
"Service": "redis",
|
||||||
"Tags": [
|
"Tags": [
|
||||||
"master",
|
"primary",
|
||||||
"v1"
|
"v1"
|
||||||
],
|
],
|
||||||
"Address": "127.0.0.1",
|
"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
|
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
|
the node with the catalog. `TaggedAddresses` can be used in conjunction with the
|
||||||
[`translate_wan_addrs`](/docs/agent/options.html#translate_wan_addrs) configuration
|
[`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.
|
the LAN address if address translation is enabled.
|
||||||
|
|
||||||
If the `Service` key is provided, the service will also be registered. If
|
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`,
|
Only one service with a given `ID` may be present per node. The service `Tags`, `Address`,
|
||||||
and `Port` fields are all optional.
|
and `Port` fields are all optional.
|
||||||
|
|
||||||
If the `Check` key is provided, a health check will also be registered. Note: this
|
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
|
||||||
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
|
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
|
health check, the check must either be provided in agent configuration or set via
|
||||||
the [agent endpoint](agent.html).
|
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
|
### <a name="catalog_deregister"></a> /v1/catalog/deregister
|
||||||
|
|
||||||
The deregister endpoint is a low-level mechanism for directly removing
|
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
|
[agent endpoints](agent.html) for deregistration as they are simpler and perform
|
||||||
[anti-entropy](/docs/internals/anti-entropy.html).
|
[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:
|
body must look like one of the following:
|
||||||
|
|
||||||
```javascript
|
```javascript
|
||||||
|
@ -164,7 +163,7 @@ If the API call succeeds a 200 status code is returned.
|
||||||
|
|
||||||
### <a name="catalog_datacenters"></a> /v1/catalog/datacenters
|
### <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.
|
datacenters that are known by the Consul server.
|
||||||
|
|
||||||
The datacenters will be sorted in ascending order based on the
|
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
|
### <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;
|
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
|
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.
|
node for the sort.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
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
|
### <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;
|
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:
|
It returns a JSON body like this:
|
||||||
|
|
||||||
|
@ -230,8 +229,8 @@ It returns a JSON body like this:
|
||||||
"consul": [],
|
"consul": [],
|
||||||
"redis": [],
|
"redis": [],
|
||||||
"postgresql": [
|
"postgresql": [
|
||||||
"master",
|
"primary",
|
||||||
"slave"
|
"secondary"
|
||||||
]
|
]
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
@ -243,17 +242,17 @@ This endpoint supports blocking queries and all consistency modes.
|
||||||
|
|
||||||
### <a name="catalog_service"></a> /v1/catalog/service/\<service\>
|
### <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;
|
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
|
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
|
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
|
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.
|
node for the sort.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
It returns a JSON body like this:
|
||||||
|
@ -299,9 +298,9 @@ The returned fields are as follows:
|
||||||
|
|
||||||
### <a name="catalog_node"></a> /v1/catalog/node/\<node\>
|
### <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;
|
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.
|
The node being queried must be provided on the path.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
It returns a JSON body like this:
|
||||||
|
|
|
@ -25,7 +25,7 @@ The following endpoints are supported:
|
||||||
|
|
||||||
### <a name="coordinate_datacenters"></a> /v1/coordinate/datacenters
|
### <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.
|
all Consul servers, organized by DCs.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
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
|
### <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;
|
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:
|
It returns a JSON body like this:
|
||||||
|
|
||||||
|
|
|
@ -24,11 +24,11 @@ needs a `name`, provided on the path. The endpoint also supports several
|
||||||
optional parameters on the query string.
|
optional parameters on the query string.
|
||||||
|
|
||||||
By default, the agent's local datacenter is used, but another datacenter
|
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"
|
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.
|
reserved for Consul's internal use.
|
||||||
|
|
||||||
The `?node=`, `?service=`, and `?tag=` query parameters may optionally
|
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
|
### <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
|
events known by the agent. As a consequence of how the
|
||||||
[event command](/docs/commands/event.html) works, each agent
|
[event command](/docs/commands/event.html) works, each agent
|
||||||
may have a different view of the events. Events are broadcast using
|
may have a different view of the events. Events are broadcast using
|
||||||
|
|
|
@ -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\>
|
### <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;
|
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:
|
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
|
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
|
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
|
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
|
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\>
|
### <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;
|
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
|
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.
|
node for the sort.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
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\>
|
### <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;
|
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
|
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.
|
node for the sort.
|
||||||
|
|
||||||
By default, all nodes matching the service are returned. The list can be filtered
|
By default, all nodes matching the service are returned. The list can be filtered
|
||||||
by tag using the "?tag=" query parameter.
|
by tag using the "?tag=" query parameter.
|
||||||
|
|
||||||
Providing the "?passing" query parameter, added in Consul 0.2, will filter results
|
Providing the `?passing` query parameter, added in Consul 0.2, will
|
||||||
to only nodes with all checks in the `passing` state. This can be used to avoid extra filtering
|
filter results to only nodes with all checks in the `passing` state.
|
||||||
logic on the client side.
|
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
|
endpoint automatically returns the status of the associated health check
|
||||||
as well as any system level health checks. This allows a client to avoid
|
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.
|
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\>
|
### <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;
|
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
|
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.
|
node for the sort.
|
||||||
|
|
||||||
The supported states are `any`, `passing`, `warning`, or `critical`.
|
The supported states are `any`, `passing`, `warning`, or `critical`.
|
||||||
|
|
|
@ -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
|
prefixes, and fetches of individual keys or key prefixes. The `GET`, `PUT` and
|
||||||
`DELETE` methods are all supported.
|
`DELETE` methods are all supported.
|
||||||
|
|
||||||
By default, the datacenter of the agent is queried; however, the dc can be provided
|
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
|
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
|
its own KV store, and there is no built-in replication between datacenters. If you
|
||||||
are interested in replication between datacenters, look at the
|
are interested in replication between datacenters, look at the
|
||||||
[Consul Replicate project](https://github.com/hashicorp/consul-replicate).
|
[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
|
#### GET Method
|
||||||
|
|
||||||
When using the `GET` method, Consul will return the specified key.
|
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.
|
all keys with the given prefix.
|
||||||
|
|
||||||
This endpoint supports blocking queries and all consistency modes.
|
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
|
`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
|
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:
|
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
|
to the latest `ModifyIndex` within the prefix, and a blocking query using that
|
||||||
"?index" will wait until any key within that prefix is updated.
|
"?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
|
`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.
|
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
|
`Value` is a Base64-encoded blob of data.
|
||||||
512kB.
|
|
||||||
|
|
||||||
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
|
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
|
```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
|
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.
|
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
|
the response is just the raw value of the key, without any
|
||||||
encoding.
|
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
|
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
|
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
|
* `?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.
|
`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
|
operation. This is very useful as a building block for more complex
|
||||||
synchronization primitives. If the index is 0, Consul will only
|
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,
|
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.
|
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
|
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
|
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
|
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
|
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.
|
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
|
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
|
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.
|
`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
|
#### DELETE method
|
||||||
|
|
||||||
The `DELETE` method can be used to delete a single key or all keys sharing
|
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
|
a prefix. There are a few query parameters that can be used with a
|
||||||
DELETE request:
|
`DELETE` request:
|
||||||
|
|
||||||
* ?recurse : This is used to delete all keys which have the specified prefix.
|
* `?recurse` : This is used to delete all keys which have the specified prefix.
|
||||||
Without this, only a key with an exact match will be deleted.
|
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
|
operation. This is very useful as a building block for more complex
|
||||||
synchronization primitives. Unlike `PUT`, the index must be greater than 0
|
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
|
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
|
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.
|
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
|
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
|
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
|
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
|
datacenters. If you are interested in replication between datacenters, look at the
|
||||||
[Consul Replicate project](https://github.com/hashicorp/consul-replicate).
|
[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.
|
parameter.
|
||||||
|
|
||||||
#### PUT Method
|
#### 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
|
inside a transaction. If any operation fails, the transaction will be rolled back and
|
||||||
none of the changes will be applied.
|
none of the changes will be applied.
|
||||||
|
|
||||||
If the transaction doesn't contain any write operations then it will be fast-pathed
|
If the transaction doesn't contain any write operations then it will be
|
||||||
internally to an endpoint that works like other reads, except that blocking queries
|
fast-pathed internally to an endpoint that works like other reads,
|
||||||
are not currently supported. In this mode, you may supply the "?stale" or "?consistent"
|
except that blocking queries are not currently supported. In this mode,
|
||||||
query parameters with the request to control consistency. To support bounding the
|
you may supply the `?stale` or `?consistent` query parameters with the
|
||||||
acceptable staleness of data, read-only transaction responses provide the `X-Consul-LastContact`
|
request to control consistency. To support bounding the acceptable
|
||||||
header containing the time in milliseconds that a server was last contacted by the leader node.
|
staleness of data, read-only transaction responses provide the
|
||||||
The `X-Consul-KnownLeader` header also indicates if there is a known leader. These
|
`X-Consul-LastContact` header containing the time in milliseconds that a
|
||||||
won't be present if the transaction contains any write operations, and any consistency
|
server was last contacted by the leader node. The
|
||||||
query parameters will be ignored, since writes are always managed by the leader via
|
`X-Consul-KnownLeader` header also indicates if there is a known leader.
|
||||||
the Raft consensus protocol.
|
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
|
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
|
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.
|
* `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.
|
512kB.
|
||||||
|
|
||||||
* `Flags` is an opaque unsigned integer that can be attached to each entry. Clients
|
* `Flags` is an opaque unsigned integer that can be attached to each entry. Clients
|
||||||
|
|
|
@ -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.
|
leader to retrieve its latest Raft peer configuration.
|
||||||
|
|
||||||
If the cluster doesn't currently have a leader an error will be returned. You
|
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.
|
of the Consul servers.
|
||||||
|
|
||||||
By default, the datacenter of the agent is queried; however, the `dc` can be
|
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
|
If ACLs are enabled, the client will need to supply an ACL Token with
|
||||||
[`operator`](/docs/internals/acl.html#operator) read privileges.
|
[`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
|
`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.
|
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 `Index` value is the Raft corresponding to this configuration. The latest configuration may not yet be committed if changes are in flight.
|
||||||
the latest configuration may not yet be committed if changes are in flight.
|
|
||||||
|
|
||||||
### <a name="raft-peer"></a> /v1/operator/raft/peer
|
### <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
|
endpoint can be used to remove the failed server so that it is no longer
|
||||||
affects the Raft quorum.
|
affects the Raft quorum.
|
||||||
|
|
||||||
An "?address=" query parameter is required and should be set to the
|
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
|
`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.
|
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
|
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
|
If ACLs are enabled, the client will need to supply an ACL Token with
|
||||||
[`operator`](/docs/internals/acl.html#operator) write privileges.
|
[`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.
|
`GET`, `POST`, `PUT` and `DELETE` methods.
|
||||||
|
|
||||||
This endpoint supports the use of ACL tokens using either the `X-CONSUL-TOKEN`
|
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
|
#### 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
|
into the cluster. There is more information on gossip encryption available
|
||||||
[here](/docs/agent/encryption.html#gossip-encryption).
|
[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:
|
body must look like:
|
||||||
|
|
||||||
```javascript
|
```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
|
is more information on gossip encryption available
|
||||||
[here](/docs/agent/encryption.html#gossip-encryption).
|
[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:
|
body must look like:
|
||||||
|
|
||||||
```javascript
|
```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
|
the primary key. There is more information on gossip encryption available
|
||||||
[here](/docs/agent/encryption.html#gossip-encryption).
|
[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:
|
body must look like:
|
||||||
|
|
||||||
```javascript
|
```javascript
|
||||||
|
|
|
@ -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.
|
its ID if it is created successfully.
|
||||||
|
|
||||||
By default, the datacenter of the agent is queried; however, the `dc` can be
|
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`
|
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.
|
write privileges for the `Name` of the query being created.
|
||||||
|
@ -78,7 +78,7 @@ query, like this example:
|
||||||
"Datacenters": ["dc1", "dc2"]
|
"Datacenters": ["dc1", "dc2"]
|
||||||
},
|
},
|
||||||
"OnlyPassing": false,
|
"OnlyPassing": false,
|
||||||
"Tags": ["master", "!experimental"]
|
"Tags": ["primary", "!experimental"]
|
||||||
},
|
},
|
||||||
"DNS": {
|
"DNS": {
|
||||||
"TTL": "10s"
|
"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
|
if they have access to the service being queried. If the client does not supply
|
||||||
an ACL Token, the anonymous token will be used.
|
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
|
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
|
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
|
queries wishing to obtain the new behavior will need to be updated to remove
|
||||||
their captured `Token` field. Capturing ACL Tokens is analogous to
|
their captured `Token` field. Capturing ACL Tokens is analogous to
|
||||||
[PostgreSQL’s SECURITY DEFINER](http://www.postgresql.org/docs/current/static/sql-createfunction.html)
|
[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
|
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.
|
new Prepared Queries.
|
||||||
|
|
||||||
<a name="near"></a>
|
<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
|
excluded tags (prefixed with `!`). The default value is an empty list, which does
|
||||||
no tag filtering.
|
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
|
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
|
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
|
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>
|
<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
|
```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
|
The new `Template` structure configures a prepared query as a template instead of a
|
||||||
static query. It has two fields:
|
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`
|
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
|
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
|
to have high-level templates that are overridden for specific services. Static
|
||||||
queries are always resolved first, so they can also override templates.
|
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:
|
interpolated, with the following variables available:
|
||||||
|
|
||||||
`${name.full}` has the entire name that was queried. For example, a DNS lookup for
|
`${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-primary.query.consul` in the example above would set this variable to
|
||||||
"geo-db-customer-master".
|
`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.
|
the example above.
|
||||||
|
|
||||||
`${name.suffix}` has the suffix after the prefix. For example, a DNS lookup for
|
`${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
|
`geo-db-customer-primary.query.consul` in the example above would set this variable to
|
||||||
"-customer-master".
|
`-customer-primary`.
|
||||||
|
|
||||||
`${match(N)}` returns the regular expression match at the given index N. The
|
`${match(N)}` returns the regular expression match at the given index N.
|
||||||
0 index will have the entire match, and >0 will have the results of each match
|
The 0 index will have the entire match, and >0 will have the results of
|
||||||
group. For example, a DNS lookup for "geo-db-customer-master.query.consul" in the example
|
each match group. For example, a DNS lookup for
|
||||||
above with a `Regexp` field set to `^geo-db-(.*?)-([^\-]+?)$` would return
|
`geo-db-customer-primary.query.consul` in the example above with a
|
||||||
"geo-db-customer-master" for `${match(0)}`, "customer" for `${match(1)}`, and
|
`Regexp` field set to `^geo-db-(.*?)-([^\-]+?)$` would return
|
||||||
"master" for `${match(2)}`. If the regular expression doesn't match, or an invalid
|
`geo-db-customer-primary` for `${match(0)}`, `customer` for
|
||||||
index is given, then `${match(N)}` will return an empty string.
|
`${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
|
See the [query explain](#explain) endpoint which is useful for testing interpolations
|
||||||
and determining which query is handling a given name.
|
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
|
#### 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
|
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.
|
queries and all consistency modes.
|
||||||
|
|
||||||
If ACLs are enabled, then the client will only see prepared queries for which their
|
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"]
|
"Datacenters": ["dc1", "dc2"]
|
||||||
},
|
},
|
||||||
"OnlyPassing": false,
|
"OnlyPassing": false,
|
||||||
"Tags": ["master", "!experimental"]
|
"Tags": ["primary", "!experimental"]
|
||||||
},
|
},
|
||||||
"DNS": {
|
"DNS": {
|
||||||
"TTL": "10s"
|
"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.
|
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
|
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`
|
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.
|
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.
|
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
|
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.
|
queries and all consistency modes.
|
||||||
|
|
||||||
The returned response is the same as the list of prepared queries above,
|
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.
|
The `DELETE` method is used to delete a prepared query.
|
||||||
|
|
||||||
By default, the datacenter of the agent is queried; however, the `dc` can be
|
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`
|
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.
|
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).
|
[prepared query template](#templates).
|
||||||
|
|
||||||
By default, the datacenter of the agent is queried; however, the `dc` can be
|
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.
|
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.
|
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
|
present, the default behavior will shuffle the nodes randomly each time the
|
||||||
query is executed. Passing this option will override the built-in
|
query is executed. Passing this option will override the built-in
|
||||||
<a href="#near">near parameter</a> of a prepared query, if present.
|
<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.
|
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
|
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.
|
final query looks like after interpolation.
|
||||||
|
|
||||||
By default, the datacenter of the agent is queried; however, the `dc` can be
|
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.
|
blocking queries, but it does support all consistency modes.
|
||||||
|
|
||||||
If ACLs are enabled, then the client will only see prepared queries for which their
|
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"]
|
"Datacenters": ["dc1", "dc2"]
|
||||||
},
|
},
|
||||||
"OnlyPassing": true,
|
"OnlyPassing": true,
|
||||||
"Tags": ["master"]
|
"Tags": ["primary"]
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Note that even though this query is a template, it is shown with its `Service`
|
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".
|
fields interpolated based on the example query name `geo-db-customer-primary`.
|
||||||
|
|
|
@ -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).
|
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.
|
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:
|
body must look like:
|
||||||
|
|
||||||
```javascript
|
```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.
|
if the defaults are to be used.
|
||||||
|
|
||||||
By default, the agent's local datacenter is used; another datacenter
|
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.
|
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.
|
seconds. The default is 15s.
|
||||||
|
|
||||||
`Node` must refer to a node that is already registered, if specified. By default,
|
`Node` must refer to a node that is already registered, if specified. By default,
|
||||||
|
@ -56,7 +56,7 @@ the agent's own node name is used.
|
||||||
`Name` can be used to provide a human-readable name for the Session.
|
`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
|
`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
|
`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`,
|
||||||
|
@ -64,7 +64,7 @@ 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
|
causes any locks that are held to be deleted. `delete` is useful for creating ephemeral
|
||||||
key/value entries.
|
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.
|
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
|
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
|
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\>
|
### <a name="session_destroy"></a> /v1/session/destroy/\<session\>
|
||||||
|
|
||||||
The destroy endpoint is hit with a PUT and destroys the given session.
|
The destroy endpoint is hit with a `PUT` and destroys the given session.
|
||||||
By default, the local datacenter is used, but the "?dc=" query parameter
|
By default, the local datacenter is used, but the `?dc=` query parameter
|
||||||
can be used to specify the datacenter.
|
can be used to specify the datacenter.
|
||||||
|
|
||||||
The session being destroyed must be provided on the path.
|
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\>
|
### <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;
|
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.
|
The session being queried must be provided on the path.
|
||||||
|
|
||||||
It returns a JSON body like this:
|
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\>
|
### <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;
|
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.
|
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
|
### <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;
|
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:
|
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\>
|
### <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
|
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.
|
query parameter can be used to specify the datacenter.
|
||||||
|
|
||||||
The session being renewed must be provided on the path.
|
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
|
```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.
|
The response body includes the current session.
|
||||||
|
|
||||||
Note: Consul MAY return a TTL value higher than the one specified during session creation.
|
-> **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.
|
||||||
This indicates the server is under high load and is requesting clients renew less
|
|
||||||
often.
|
|
||||||
|
|
|
@ -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.
|
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
|
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
|
By default, snapshots use consistent mode which means the request is internally
|
||||||
forwarded to the cluster leader, and leadership is checked before performing the
|
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
|
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`
|
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
|
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.
|
cluster of Consul servers.
|
||||||
|
|
||||||
By default, the datacenter of the agent is targeted; however, the `dc` can be
|
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
|
If ACLs are enabled, the client will need to supply an ACL Token with management
|
||||||
privileges.
|
privileges.
|
||||||
|
|
|
@ -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
|
* <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
|
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
|
agent via [`consul monitor`](/docs/commands/monitor.html) and use any log level. Also, the
|
||||||
log level can be changed during a config reload.
|
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
|
```javascript
|
||||||
"ports": {
|
"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
|
permissions if it does not exist. It allows operators to bootstrap the ACL system
|
||||||
with a token ID that is well-known.
|
with a token ID that is well-known.
|
||||||
<br><br>
|
<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`
|
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
|
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
|
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.
|
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
|
* <a name="udp_answer_limit"></a><a
|
||||||
href="#udp_answer_limit">`udp_answer_limit`</a> - Limit the number of
|
href="#udp_answer_limit">`udp_answer_limit`</a> - Limit the number of
|
||||||
resource records contained in the answer section of a UDP-based DNS
|
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
|
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
|
[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
|
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
|
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
|
* <a name="skip_leave_on_interrupt"></a><a
|
||||||
href="#skip_leave_on_interrupt">`skip_leave_on_interrupt`</a> This is
|
href="#skip_leave_on_interrupt">`skip_leave_on_interrupt`</a> This is
|
||||||
similar to [`leave_on_terminate`](#leave_on_terminate) but only affects
|
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.
|
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
|
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
|
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`
|
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
|
(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).
|
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:
|
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
|
* <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
|
aggregation. This can be used to capture runtime information. This sends UDP packets only and can be used with
|
||||||
statsd or statsite.
|
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.
|
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>
|
* <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 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").
|
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:
|
sockets created by Consul:
|
||||||
<br>
|
<br>
|
||||||
* `user` - The name or ID of the user who will own the socket file.
|
* `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.
|
currently only supports numeric IDs.
|
||||||
* `mode` - The permission bits to set on the file.
|
* `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
|
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
|
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
|
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
|
must define an HTTPS port via the [`ports`](#ports) configuration. By default, HTTPS
|
||||||
is disabled.
|
is disabled.
|
||||||
|
|
||||||
|
|
|
@ -23,7 +23,7 @@ A service definition that is a script looks like:
|
||||||
{
|
{
|
||||||
"service": {
|
"service": {
|
||||||
"name": "redis",
|
"name": "redis",
|
||||||
"tags": ["master"],
|
"tags": ["primary"],
|
||||||
"address": "",
|
"address": "",
|
||||||
"port": 8000,
|
"port": 8000,
|
||||||
"enableTagOverride": false,
|
"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
|
A service definition must include a `name` and may optionally provide an
|
||||||
an `id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The `id` is
|
`id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The
|
||||||
set to the `name` if not provided. It is required that all services have a unique
|
`id` is set to the `name` if not provided. It is required that all
|
||||||
ID per node, so if names might conflict then unique IDs should be provided.
|
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
|
The `tags` property is a list of values that are opaque to Consul but
|
||||||
distinguish between "master" or "slave" nodes, different versions, or any other service
|
can be used to distinguish between `primary` or `secondary` nodes,
|
||||||
level labels.
|
different versions, or any other service level labels.
|
||||||
|
|
||||||
The `address` field can be used to specify a service-specific IP address. By
|
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.
|
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
|
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
|
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
|
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 has any failing system-level check, the DNS interface will omit that
|
||||||
node from any service query.
|
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
|
`service:<service-id>:<num>` where `<num>` is an incrementing number starting
|
||||||
from `1`.
|
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
|
The `enableTagOverride` can optionally be specified to disable the
|
||||||
feature for this service. If `enableTagOverride` is set to TRUE then external
|
anti-entropy feature for this service. If `enableTagOverride` is set to
|
||||||
agents can update this service in the [catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
|
`TRUE` then external agents can update this service in the
|
||||||
local sync operations by this agent will ignore the updated tags. For instance: If an external agent
|
[catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent
|
||||||
modified both the tags and the port for this service and `enableTagOverride`
|
local sync operations by this agent will ignore the updated tags. For
|
||||||
was set to TRUE then after the next sync cycle the service's port would revert
|
example, if an external agent modified both the tags and the port for
|
||||||
to the original value but the tags would maintain the updated value. As a
|
this service and `enableTagOverride` was set to `TRUE` then after the next
|
||||||
counter example: If an external agent modified both the tags and port for this
|
sync cycle the service's port would revert to the original value but the
|
||||||
service and `enableTagOverride` was set to FALSE then after the next sync
|
tags would maintain the updated value. As a counter example: If an
|
||||||
cycle the service's port AND the tags would revert to the original value and
|
external agent modified both the tags and port for this service and
|
||||||
all modifications would be lost. It's important to note that this applies only
|
`enableTagOverride` was set to `FALSE` then after the next sync cycle the
|
||||||
to the locally registered service. If you have multiple nodes all registering
|
service's port *and* the tags would revert to the original value and all
|
||||||
the same service their `enableTagOverride` configuration and all other service
|
modifications would be lost.
|
||||||
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
|
It's important to note that this applies only to the locally registered
|
||||||
agent or place it inside the `-config-dir` of the agent. The file must
|
service. If you have multiple nodes all registering the same service
|
||||||
end in the ".json" extension to be loaded by Consul. Check definitions can
|
their `enableTagOverride` configuration and all other service
|
||||||
also be updated by sending a `SIGHUP` to the agent. Alternatively, the
|
configuration items are independent of one another. Updating the tags
|
||||||
service can be registered dynamically using the [HTTP API](/docs/agent/http.html).
|
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 Service Definitions
|
||||||
|
|
||||||
Multiple services definitions can be provided at once using the `services`
|
Multiple services definitions can be provided at once using the plural
|
||||||
(plural) key in your configuration file.
|
`services` key in your configuration file.
|
||||||
|
|
||||||
```javascript
|
```javascript
|
||||||
{
|
{
|
||||||
|
@ -111,7 +117,7 @@ Multiple services definitions can be provided at once using the `services`
|
||||||
"id": "red0",
|
"id": "red0",
|
||||||
"name": "redis",
|
"name": "redis",
|
||||||
"tags": [
|
"tags": [
|
||||||
"master"
|
"primary"
|
||||||
],
|
],
|
||||||
"address": "",
|
"address": "",
|
||||||
"port": 6000,
|
"port": 6000,
|
||||||
|
@ -128,7 +134,7 @@ Multiple services definitions can be provided at once using the `services`
|
||||||
"name": "redis",
|
"name": "redis",
|
||||||
"tags": [
|
"tags": [
|
||||||
"delayed",
|
"delayed",
|
||||||
"slave"
|
"secondary"
|
||||||
],
|
],
|
||||||
"address": "",
|
"address": "",
|
||||||
"port": 7000,
|
"port": 7000,
|
||||||
|
|
|
@ -161,7 +161,7 @@ These metrics give insight into the health of the cluster as a whole.
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td>`consul.serf.events`</td>
|
<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>events / interval</td>
|
||||||
<td>counter</td>
|
<td>counter</td>
|
||||||
</tr>
|
</tr>
|
||||||
|
@ -185,7 +185,7 @@ These metrics give insight into the health of the cluster as a whole.
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td>`consul.http.<verb>.<path>`</td>
|
<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>ms</td>
|
||||||
<td>timer</td>
|
<td>timer</td>
|
||||||
</tr>
|
</tr>
|
||||||
|
|
|
@ -17,6 +17,7 @@ or perform any other orchestration action. Events can be handled by
|
||||||
[using a watch](/docs/agent/watches.html).
|
[using a watch](/docs/agent/watches.html).
|
||||||
|
|
||||||
Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip.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
|
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 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
|
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
|
* `-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
|
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.
|
* `-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
|
* `-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
|
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
|
* `-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.
|
write-level privileges for the event specified. Defaults to that of the agent.
|
||||||
|
|
|
@ -34,20 +34,20 @@ could make the cluster unavailable.
|
||||||
Usage: `consul exec [options] [-|command...]`
|
Usage: `consul exec [options] [-|command...]`
|
||||||
|
|
||||||
The only required option is a command to execute. This is either given
|
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.
|
completion as a script to evaluate.
|
||||||
|
|
||||||
The list of available flags are:
|
The list of available flags are:
|
||||||
|
|
||||||
* `-http-addr` - Address to the HTTP server of the agent you want to contact
|
* `-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
|
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
|
* `-datacenter` - Datacenter to query. Defaults to that of agent. In version
|
||||||
0.4, that is the only supported value.
|
0.4, that is the only supported value.
|
||||||
|
|
||||||
* `-prefix` - Key prefix in the KV store to use for storing request data.
|
* `-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.
|
* `-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
|
* `-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
|
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
|
* `-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.
|
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.
|
* `-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
|
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.
|
* `-verbose` - Enables verbose output.
|
||||||
|
|
||||||
* `-token` - The ACL token to use during requests. This token must have access
|
* `-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.
|
event. Defaults to that of the agent.
|
||||||
|
|
|
@ -3,7 +3,7 @@ layout: "docs"
|
||||||
page_title: "Commands: Force Leave"
|
page_title: "Commands: Force Leave"
|
||||||
sidebar_current: "docs-commands-forceleave"
|
sidebar_current: "docs-commands-forceleave"
|
||||||
description: |-
|
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
|
# Consul Force Leave
|
||||||
|
@ -11,7 +11,7 @@ description: |-
|
||||||
Command: `consul force-leave`
|
Command: `consul force-leave`
|
||||||
|
|
||||||
The `force-leave` command forces a member of a Consul cluster to enter the
|
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
|
eventually rejoin the cluster. The true purpose of this method is to force
|
||||||
remove "failed" nodes.
|
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
|
* `-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
|
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
|
`CONSUL_RPC_ADDR` env variable. If this isn't set, the default RPC
|
||||||
address will be set to "127.0.0.1:8400".
|
address will be set to `127.0.0.1:8400`.
|
||||||
|
|
||||||
|
|
|
@ -110,7 +110,7 @@ $ consul kv put -flags=42 redis/config/password s3cr3t
|
||||||
Success! Data written to: redis/config/password
|
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
|
$ consul kv put -acquire -session=abc123 redis/lock/update
|
||||||
|
|
|
@ -21,8 +21,8 @@ for more information on how these coordinates are computed.
|
||||||
Usage: `consul rtt [options] node1 [node2]`
|
Usage: `consul rtt [options] node1 [node2]`
|
||||||
|
|
||||||
At least one node name is required. If the second node name isn't given, it
|
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
|
is set to the agent's node name. These are the node names as known to
|
||||||
Consul as `consul members` would show, not IP addresses.
|
Consul as the `consul members` command would show, not IP addresses.
|
||||||
|
|
||||||
The list of available flags are:
|
The list of available flags are:
|
||||||
|
|
||||||
|
|
|
@ -13,7 +13,7 @@ Command: `consul watch`
|
||||||
The `watch` command provides a mechanism to watch for changes in a particular
|
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
|
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,
|
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.
|
data in Consul.
|
||||||
|
|
||||||
There is more [documentation on watches here](/docs/agent/watches.html).
|
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
|
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.
|
* `-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
|
* `-stale=[true|false]` - Specifies if watch data is permitted to be stale. Defaults
|
||||||
to false.
|
to false.
|
||||||
|
@ -45,7 +45,7 @@ The list of available flags are:
|
||||||
* `-name`- Event name to watch. Only for `event` type.
|
* `-name`- Event name to watch. Only for `event` type.
|
||||||
|
|
||||||
* `-passingonly=[true|false]` - Should only passing entries be returned. Defaults to
|
* `-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.
|
* `-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.
|
* `-tag` - Service tag to filter on. Optional for `service` type.
|
||||||
|
|
||||||
* `-type` - Watch type. Required, one of "key", "keyprefix", "services",
|
* `-type` - Watch type. Required, one of "`key`, `keyprefix`, `services`,
|
||||||
"nodes", "service", "checks", or "event".
|
`nodes`, `service`, `checks`, or `event`.
|
||||||
|
|
||||||
|
|
|
@ -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.
|
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
|
Backwards compatibility is automatic unless otherwise noted. Consul agents by
|
||||||
default will speak the latest protocol but can understand earlier ones. Note:
|
default will speak the latest protocol but can understand earlier ones.
|
||||||
if speaking an earlier protocol, _new features may not be available_.
|
|
||||||
|
-> **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
|
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
|
can be upgraded without cluster disruption. Consul agents can be updated one
|
||||||
|
|
|
@ -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_
|
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
|
states), Consul will automatically remove dead nodes out of the catalog. This
|
||||||
process is called _reaping_. This is currently done on a configurable
|
process is called _reaping_. This is currently done on a configurable
|
||||||
interval of 72 hours. Reaping is similar to leaving, causing all associated
|
interval of 72 hours. Reaping is similar to leaving, causing all associated
|
||||||
services to be deregistered. Changing the reap interval for aesthetic
|
services to be deregistered. Changing the reap interval for aesthetic
|
||||||
reasons to trim the number of _failed_ or _left_ nodes is not advised (nodes
|
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
|
in the _failed_ or _left_ state do not cause any additional burden on
|
||||||
Consul).
|
Consul).
|
||||||
|
|
|
@ -70,19 +70,22 @@ Since a join operation is symmetric, it does not matter which node initiates it.
|
||||||
[INFO] consul: cluster leadership acquired
|
[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
|
As a sanity check, the [`consul info`](/docs/commands/info.html) command
|
||||||
verify `raft.num_peers` is now 2, and you can view the latest log index under `raft.last_log_index`.
|
is a useful tool. It can be used to verify `raft.num_peers` is now 2,
|
||||||
When running [`consul info`](/docs/commands/info.html) on the followers, you should see `raft.last_log_index`
|
and you can view the latest log index under `raft.last_log_index`. When
|
||||||
converge to the same value once the leader begins replication. That value represents the last
|
running [`consul info`](/docs/commands/info.html) on the followers, you
|
||||||
log entry that has been stored on disk.
|
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
|
Now that the servers are all started and replicating to each other, all
|
||||||
clients can be joined. Clients are much easier as they can join against any existing node.
|
the remaining clients can be joined. Clients are much easier as they can
|
||||||
All nodes participate in a gossip protocol to perform basic discovery, so once joined to any
|
join against any existing node. All nodes participate in a gossip
|
||||||
member of the cluster, new clients will automatically find the servers and register themselves.
|
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
|
-> **Note:** It is not strictly necessary to start the server nodes before the clients; however, most operations will fail until the servers are available.
|
||||||
operations will fail until the servers are available.
|
|
||||||
|
|
||||||
## Manual Bootstrapping
|
## Manual Bootstrapping
|
||||||
|
|
||||||
|
|
|
@ -3,26 +3,29 @@ layout: "docs"
|
||||||
page_title: "Forwarding"
|
page_title: "Forwarding"
|
||||||
sidebar_current: "docs-guides-forwarding"
|
sidebar_current: "docs-guides-forwarding"
|
||||||
description: |-
|
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
|
# 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
|
requires elevated privileges. Instead of running Consul with an administrative
|
||||||
or root account, it is possible to instead forward appropriate queries to Consul,
|
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.
|
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/)
|
In this guide, we will demonstrate forwarding from
|
||||||
as well as [dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) and [iptables](http://www.netfilter.org/).
|
[BIND](https://www.isc.org/downloads/bind/) as well as
|
||||||
For the sake of simplicity, BIND and Consul are running on the same machine in this example. For iptables the
|
[dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) and
|
||||||
rules must be set on the same host as the Consul instance and relay hosts should not be on the same host or
|
[iptables](http://www.netfilter.org/). For the sake of simplicity, BIND
|
||||||
the redirects will intercept the traffic.
|
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
|
It is worth mentioning that, by default, Consul does not resolve DNS
|
||||||
records outside the `.consul.` zone unless the
|
records outside the `.consul.` zone unless the
|
||||||
[recursors](/docs/agent/options.html#recursors) configuration option
|
[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
|
suppose a Consul DNS reply includes a CNAME record pointing outside
|
||||||
the `.consul` TLD. The DNS reply will only include CNAME records by
|
the `.consul` TLD. The DNS reply will only include CNAME records by
|
||||||
default. By contrast, when `recursors` is set and the upstream resolver is
|
default. By contrast, when `recursors` is set and the upstream resolver is
|
||||||
|
@ -61,7 +64,7 @@ include "/etc/named/consul.conf";
|
||||||
|
|
||||||
### Zone File
|
### 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
|
```text
|
||||||
zone "consul" IN {
|
zone "consul" IN {
|
||||||
|
@ -77,7 +80,7 @@ DNS on port 8600.
|
||||||
### Dnsmasq Setup
|
### Dnsmasq Setup
|
||||||
|
|
||||||
Dnsmasq is typically configured via a `dnsmasq.conf` or a series of files in
|
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:
|
(e.g. `/etc/dnsmasq.d/10-consul`), add the following:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
|
@ -115,8 +118,8 @@ for additional details):
|
||||||
#no-resolv
|
#no-resolv
|
||||||
|
|
||||||
# Specify IP address(es) of other DNS servers for queries not handled
|
# Specify IP address(es) of other DNS servers for queries not handled
|
||||||
# directly by consul. There is normally one 'server' entry set for every
|
# directly by consul. There is normally one 'server' entry set for every
|
||||||
# 'nameserver' parameter found in '/etc/resolv.conf'. See dnsmasq(8)'s
|
# 'nameserver' parameter found in '/etc/resolv.conf'. See dnsmasq(8)'s
|
||||||
# 'server' configuration option for details.
|
# 'server' configuration option for details.
|
||||||
#server=1.2.3.4
|
#server=1.2.3.4
|
||||||
#server=208.67.222.222
|
#server=208.67.222.222
|
||||||
|
@ -129,15 +132,20 @@ for additional details):
|
||||||
|
|
||||||
### iptables Setup
|
### iptables Setup
|
||||||
|
|
||||||
On Linux systems that support it, incoming requests and requests to localhost can use `iptables`
|
On Linux systems that support it, incoming requests and requests to
|
||||||
to forward ports on the same machine without a secondary service. Since Consul, by default, only
|
the local host can use `iptables` to forward ports on the same machine
|
||||||
resolves the `.consul` TDL, it is especially important to use the `recursors` option if you wish the
|
without a secondary service. Since Consul, by default, only resolves
|
||||||
`iptables` setup to resolve for other domains. The recursors should not include the localhost as the
|
the `.consul` TDL, it is especially important to use the `recursors`
|
||||||
redirects would just intercept the requests. The iptables method is suited for situations where an
|
option if you wish the `iptables` setup to resolve for other domains.
|
||||||
external DNS service is already running in your infrastructure and is used as the recursor or if you want
|
The recursors should not include the local host as the redirects would
|
||||||
to use an existing DNS server as your query endpoint and forward requests for the consul domain to the
|
just intercept the requests.
|
||||||
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.
|
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
|
[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:
|
First, perform a DNS query against Consul directly to be sure that the record exists:
|
||||||
|
|
||||||
```text
|
```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)
|
; (1 server found)
|
||||||
;; global options: +cmd
|
;; global options: +cmd
|
||||||
;; Got answer:
|
;; 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
|
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
|
||||||
|
|
||||||
;; QUESTION SECTION:
|
;; QUESTION SECTION:
|
||||||
;master.redis.service.dc-1.consul. IN A
|
;primary.redis.service.dc-1.consul. IN A
|
||||||
|
|
||||||
;; ANSWER SECTION:
|
;; 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
|
;; Query time: 4 msec
|
||||||
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
;; 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:
|
valid result:
|
||||||
|
|
||||||
```text
|
```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)
|
; (1 server found)
|
||||||
;; global options: +cmd
|
;; global options: +cmd
|
||||||
;; Got answer:
|
;; Got answer:
|
||||||
|
@ -186,10 +194,10 @@ valid result:
|
||||||
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
|
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
|
||||||
|
|
||||||
;; QUESTION SECTION:
|
;; QUESTION SECTION:
|
||||||
;master.redis.service.dc-1.consul. IN A
|
;primary.redis.service.dc-1.consul. IN A
|
||||||
|
|
||||||
;; ANSWER SECTION:
|
;; 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
|
;; Query time: 4 msec
|
||||||
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
;; SERVER: 127.0.0.1#53(127.0.0.1)
|
||||||
|
|
|
@ -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
|
[sessions](/docs/internals/sessions.html). Sessions allow us to build a system that
|
||||||
can gracefully handle failures.
|
can gracefully handle failures.
|
||||||
|
|
||||||
Note that JSON output in this guide has been pretty-printed for easier
|
-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted.
|
||||||
reading. Actual values returned from the API will not be formatted.
|
|
||||||
|
|
||||||
## Contending Nodes
|
## 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
|
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
|
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
|
JSON object representing the local node. This value is opaque to
|
||||||
Consul, but it should contain whatever information clients require to
|
Consul, but it should contain whatever information clients require to
|
||||||
communicate with your application (e.g., it could be a JSON object
|
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
|
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.
|
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
|
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.
|
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
|
If the key has no associated `Session`, then there is no leader.
|
||||||
the key will provide all the application-dependent information required as a Base64 encoded
|
Otherwise, the value of the key will provide all the
|
||||||
blob in the `Value` field.
|
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
|
You can query the
|
||||||
to get details about the session:
|
[`/v1/session/info`](/docs/agent/http/session.html#session_info)
|
||||||
|
endpoint to get details about the session:
|
||||||
|
|
||||||
```text
|
```text
|
||||||
curl http://localhost:8500/v1/session/info/4ca8e74b-6350-7587-addf-a18084928f3c
|
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": [
|
"Checks": [
|
||||||
"serfHealth"
|
"serfHealth"
|
||||||
],
|
],
|
||||||
"Node": "consul-master-bjsiobmvdij6-node-lhe5ihreel7y",
|
"Node": "consul-primary-bjsiobmvdij6-node-lhe5ihreel7y",
|
||||||
"Name": "dbservice",
|
"Name": "dbservice",
|
||||||
"ID": "4ca8e74b-6350-7587-addf-a18084928f3c",
|
"ID": "4ca8e74b-6350-7587-addf-a18084928f3c",
|
||||||
"CreateIndex": 28
|
"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
|
Clients should also watch the key using a blocking query for any
|
||||||
steps down or fails, the `Session` associated with the key will be cleared. When
|
changes. If the leader steps down or fails, the `Session` associated
|
||||||
a new leader is elected, the key value will also be updated.
|
with the key will be cleared. When a new leader is elected, the key
|
||||||
|
value will also be updated.
|
||||||
|
|
|
@ -15,18 +15,19 @@ Depending on your
|
||||||
may take only a single server failure for cluster unavailability. Recovery
|
may take only a single server failure for cluster unavailability. Recovery
|
||||||
requires an operator to intervene, but the process is straightforward.
|
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
|
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).
|
add or remove a server, [see this guide](/docs/guides/servers.html).
|
||||||
|
|
||||||
## Failure of a Single Server Cluster
|
## Failure of a Single Server Cluster
|
||||||
|
|
||||||
If you had only a single server and it has failed, simply restart it.
|
If you had only a single server and it has failed, simply restart it. A
|
||||||
Note that a single server configuration requires the
|
single server configuration requires the
|
||||||
[`-bootstrap`](/docs/agent/options.html#_bootstrap) or
|
[`-bootstrap`](/docs/agent/options.html#_bootstrap) or
|
||||||
[`-bootstrap-expect=1`](/docs/agent/options.html#_bootstrap_expect) flag. If
|
[`-bootstrap-expect=1`](/docs/agent/options.html#_bootstrap_expect)
|
||||||
the server cannot be recovered, you need to bring up a new server.
|
flag. If the server cannot be recovered, you need to bring up a new
|
||||||
See the [bootstrapping guide](/docs/guides/bootstrapping.html) for more detail.
|
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
|
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
|
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
|
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:
|
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)
|
* 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.
|
||||||
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
|
* 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
|
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
|
server by starting that single server with itself as the only peer in the
|
||||||
`raft/peers.json` recovery file.
|
`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
|
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`
|
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
|
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
|
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.
|
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
|
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-
|
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
|
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
|
first start after upgrading. Be sure to leave `raft/peers.info` in place for proper
|
||||||
operation.
|
operation.
|
||||||
<br>
|
|
||||||
<br>
|
|
||||||
Using `raft/peers.json` for recovery can cause uncommitted Raft log entries to be
|
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
|
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
|
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,
|
any automated processes that will put the peers file in place on a
|
||||||
for example.
|
periodic basis.
|
||||||
|
|
||||||
The next step is to go to the [`-data-dir`](/docs/agent/options.html#_data_dir)
|
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/`
|
of each Consul server. Inside that directory, there will be a `raft/`
|
||||||
|
|
|
@ -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
|
[sessions](/docs/internals/sessions.html). Sessions allow us to build a system that
|
||||||
can gracefully handle failures.
|
can gracefully handle failures.
|
||||||
|
|
||||||
Note that JSON output in this guide has been pretty-printed for easier
|
-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted.
|
||||||
reading. Actual values returned from the API will not be formatted.
|
|
||||||
|
|
||||||
## Contending Nodes
|
## 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
|
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
|
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
|
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.
|
a failed contender or one that has voluntarily released its slot.
|
||||||
|
|
||||||
|
|
|
@ -17,7 +17,7 @@ on tokens to which fine grained rules can be applied. It is very similar to
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
When the ACL system was launched in Consul 0.4, it was only possible to specify
|
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
|
registrations. In Consul 0.6, ACL's were further extended to restrict service
|
||||||
discovery mechanisms, user events, and encryption keyring operations.
|
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`
|
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
|
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
|
](/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
|
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
|
[`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
|
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
|
enough to allow the agent to sync its services and checks into the global
|
||||||
catalog during [anti-entropy](/docs/internals/anti-entropy.html).
|
catalog during [anti-entropy](/docs/internals/anti-entropy.html).
|
||||||
|
|
|
@ -138,14 +138,15 @@ automatically recover from these types of transient failures.
|
||||||
|
|
||||||
### EnableTagOverride
|
### EnableTagOverride
|
||||||
|
|
||||||
Synchronization of service registration can be partially modified to allow
|
Synchronization of service registration can be partially modified to
|
||||||
external agents to change the tags for a service. This can be useful in
|
allow external agents to change the tags for a service. This can be
|
||||||
situations where an external monitoring service needs to be the source of
|
useful in situations where an external monitoring service needs to be
|
||||||
truth for tag information. For instance: Redis DB and its monitoring service
|
the source of truth for tag information. For example, the Redis
|
||||||
Redis Sentinel have this kind of relationship. Redis instances are responsible
|
database and its monitoring service Redis Sentinel have this kind of
|
||||||
for much of their configuration, but Sentinels determine whether the Redis
|
relationship. Redis instances are responsible for much of their
|
||||||
instance is a master or a slave. Using the Consul service configuration item
|
configuration, but Sentinels determine whether the Redis instance is a
|
||||||
[EnableTagOverride](/docs/agent/services.html) you can instruct the Consul
|
primary or a secondary. Using the Consul service configuration item
|
||||||
agent on which the Redis DB is running to NOT update the tags during anti-entropy
|
[EnableTagOverride](/docs/agent/services.html) you can instruct the
|
||||||
synchronization. For more information see [Services](/docs/agent/services.html)
|
Consul agent on which the Redis database is running to NOT update the
|
||||||
page.
|
tags during anti-entropy synchronization. For more information see
|
||||||
|
[Services](/docs/agent/services.html) page.
|
||||||
|
|
|
@ -187,9 +187,10 @@ which require it:
|
||||||
policy = "read"
|
policy = "read"
|
||||||
}
|
}
|
||||||
|
|
||||||
Note that the agent's [`acl_token`](/docs/agent/options.html#acl_token) is used
|
When the DNS interface is queried, the agent's
|
||||||
when the DNS interface is queried, so be sure that token has sufficient
|
[`acl_token`](/docs/agent/options.html#acl_token) is used, so be sure
|
||||||
privileges to return the DNS records you expect to retrieve from it.
|
that token has sufficient privileges to return the DNS records you
|
||||||
|
expect to retrieve from it.
|
||||||
|
|
||||||
* Event and keyring ACLs
|
* Event and keyring ACLs
|
||||||
|
|
||||||
|
|
|
@ -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
|
This says the version of Consul as well as the protocol versions this
|
||||||
agent speaks and can understand.
|
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
|
than it understands, in order to ease compatibility with older agents. For
|
||||||
example, Consul agents that understand version 3 claim to speak version 2,
|
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
|
and only send version 3 messages to agents that understand version 3. This
|
||||||
|
|
|
@ -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
|
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.
|
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
|
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
|
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.
|
request every 10 seconds via curl to verify that the web server is accessible.
|
||||||
|
|
|
@ -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.
|
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:
|
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
|
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
|
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
|
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.
|
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.
|
A Consul agent can join any other agent, not just agents in server mode.
|
||||||
|
|
|
@ -61,6 +61,6 @@ You can view a live demo of the Consul Web UI
|
||||||
|
|
||||||
## Next Steps
|
## 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
|
[next steps](next-steps.html) page to learn more about how to continue
|
||||||
your journey with Consul!
|
your journey with Consul!
|
||||||
|
|
Loading…
Reference in New Issue