Removed two space after period exceptions
This commit is contained in:
James Turnbull
parent
39364aa937
commit
25566a292b
|
|
@ -136,5 +136,5 @@ To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_
|
|||
states), Consul will automatically remove dead nodes out of the catalog. This
|
||||
process is called _reaping_. This is currently done on a configurable
|
||||
interval of 72 hours (changing the reap interval is *not* recommended due to
|
||||
its consequences during outage situations). Reaping is similar to leaving,
|
||||
its consequences during outage situations). Reaping is similar to leaving,
|
||||
causing all associated services to be deregistered.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ One of the primary roles of the agent is management of system-level and applicat
|
|||
checks. A health check is considered to be application-level if it is associated with a
|
||||
service. If not associated with a service, the check monitors the health of the entire node.
|
||||
|
||||
A check is defined in a configuration file or added at runtime over the HTTP interface. Checks
|
||||
A check is defined in a configuration file or added at runtime over the HTTP interface. Checks
|
||||
created via the HTTP interface persist with that node.
|
||||
|
||||
There are five different kinds of checks:
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ consul. 0 IN SOA ns.consul. postmaster.consul. 1392836399 3600 600 86400 0
|
|||
|
||||
## Service Lookups
|
||||
|
||||
A service lookup is used to query for service providers. Service queries support
|
||||
A service lookup is used to query for service providers. Service queries support
|
||||
two lookup methods: standard and strict [RFC 2782](https://tools.ietf.org/html/rfc2782).
|
||||
|
||||
### Standard Lookup
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Enabling gossip encryption only requires that you set an encryption key when
|
|||
starting the Consul agent. The key can be set via the `encrypt` parameter: the
|
||||
value of this setting is a configuration file containing the encryption key.
|
||||
|
||||
The key must be 16-bytes, Base64 encoded. As a convenience, Consul provides the
|
||||
The key must be 16-bytes, Base64 encoded. As a convenience, Consul provides the
|
||||
[`consul keygen`](/docs/commands/keygen.html) command to generate a
|
||||
cryptographically suitable key:
|
||||
|
||||
|
|
|
|||
|
|
@ -36,9 +36,9 @@ Certain endpoints support a feature called a "blocking query." A blocking query
|
|||
is used to wait for a potential change using long polling.
|
||||
|
||||
Not all endpoints support blocking, but those that do are clearly designated in the
|
||||
documentation. Any endpoint that supports blocking will also set the HTTP header
|
||||
documentation. Any endpoint that supports blocking will also set the HTTP header
|
||||
`X-Consul-Index`, a unique identifier representing the current state of the
|
||||
requested resource. On subsequent requests for this resource, the client can set the `index`
|
||||
requested resource. On subsequent requests for this resource, the client can set the `index`
|
||||
query string parameter to the value of `X-Consul-Index`, indicating that the client wishes
|
||||
to wait for any changes subsequent to that index.
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ The three read modes are:
|
|||
there is a small window in which a new leader may be elected during which the old leader may
|
||||
service stale values. The trade-off is fast reads but potentially stale values. The condition
|
||||
resulting in stale reads is hard to trigger, and most clients should not need to worry about
|
||||
this case. Also, note that this race condition only applies to reads, not writes.
|
||||
this case. Also, note that this race condition only applies to reads, not writes.
|
||||
|
||||
* consistent - This mode is strongly consistent without caveats. It requires
|
||||
that a leader verify with a quorum of peers that it is still leader. This
|
||||
|
|
@ -87,7 +87,7 @@ by clients to gauge the staleness of a result and take appropriate action.
|
|||
|
||||
## Formatted JSON Output
|
||||
|
||||
By default, the output of all HTTP API requests is minimized JSON. If the client passes `pretty`
|
||||
By default, the output of all HTTP API requests is minimized JSON. If the client passes `pretty`
|
||||
on the query string, formatted JSON will be returned.
|
||||
|
||||
## ACLs
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ to a root user and has the ability to perform any action including
|
|||
creating, modifying, and deleting ACLs.
|
||||
|
||||
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`
|
||||
endpoint.
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ The format of `Rules` is [documented here](/docs/internals/acl.html).
|
|||
|
||||
### <a name="acl_destroy"></a> /v1/acl/destroy/\<id\>
|
||||
|
||||
The destroy endpoint must be hit with a `PUT`. This endpoint destroys the ACL
|
||||
The destroy endpoint must be hit with a `PUT`. This endpoint destroys the ACL
|
||||
token identified by the `id` portion of the path.
|
||||
|
||||
The request is automatically routed to the authoritative ACL datacenter.
|
||||
|
|
@ -107,7 +107,7 @@ Requests to this endpoint must be made with a management token.
|
|||
|
||||
### <a name="acl_info"></a> /v1/acl/info/\<id\>
|
||||
|
||||
The info endpoint must be hit with a `GET`. This endpoint returns the ACL
|
||||
The info endpoint must be hit with a `GET`. This endpoint returns the ACL
|
||||
token information identified by the `id` portion of the path.
|
||||
|
||||
It returns a JSON body like this:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ description: >
|
|||
|
||||
The Agent endpoints are used to interact with the local Consul agent. Usually,
|
||||
services and checks are registered with an agent which then takes on the
|
||||
burden of keeping that data synchronized with the cluster. For example, the
|
||||
burden of keeping that data synchronized with the cluster. For example, the
|
||||
agent registers services and checks with the Catalog and performs
|
||||
[anti-entropy](/docs/internals/anti-entropy.html) to recover from outages.
|
||||
|
||||
|
|
@ -202,10 +202,10 @@ During maintenance mode, the node will be marked as unavailable and will not be
|
|||
present in DNS or API queries. This API call is idempotent. Maintenance mode is
|
||||
persistent and will be automatically restored on agent restart.
|
||||
|
||||
The `?enable` flag is required. Acceptable values are either `true` (to enter
|
||||
The `?enable` flag is required. Acceptable values are either `true` (to enter
|
||||
maintenance mode) or `false` (to resume normal operation).
|
||||
|
||||
The `?reason` flag is optional. If provided, its value should be a text string
|
||||
The `?reason` flag is optional. If provided, its value should be a text string
|
||||
explaining the reason for placing the node into maintenance mode. This is simply
|
||||
to aid human operators. If no reason is provided, a default value will be used instead.
|
||||
|
||||
|
|
@ -214,7 +214,7 @@ The return code is 200 on success.
|
|||
### <a name="agent_join"></a> /v1/agent/join/\<address\>
|
||||
|
||||
This endpoint is hit with a `GET` and is used to instruct the agent to attempt to
|
||||
connect to a given address. For agents running in server mode, providing a `?wan=1`
|
||||
connect to a given address. For agents running in server mode, providing a `?wan=1`
|
||||
query parameter causes the agent to attempt to join using the WAN pool.
|
||||
|
||||
The return code is 200 on success.
|
||||
|
|
@ -222,7 +222,7 @@ The return code is 200 on success.
|
|||
### <a name="agent_force_leave"></a> /v1/agent/force-leave/\<node\>
|
||||
|
||||
This endpoint is hit with a `GET` and is used to instruct the agent to
|
||||
force a node into the `left` state. If a node fails unexpectedly, then
|
||||
force a node into the `left` state. If a node fails unexpectedly, then
|
||||
it will be in a `failed` state. Once in the `failed` state, Consul will
|
||||
attempt to reconnect, and the services and checks belonging to that node
|
||||
will not be cleaned up. Forcing a node into the `left` state allows its
|
||||
|
|
@ -284,10 +284,10 @@ evaluate the script every `Interval` in the given container using the specified
|
|||
|
||||
An `HTTP` check will perform an HTTP `GET` request against the value of
|
||||
`HTTP` (expected to be a URL) every `Interval`. If the response is any
|
||||
`2xx` code, the check is `passing`. If the response is `429 Too Many
|
||||
`2xx` code, the check is `passing`. If the response is `429 Too Many
|
||||
Requests`, the check is `warning`. Otherwise, the check is `critical`.
|
||||
HTTP checks also support SSL. By default, a valid SSL certificate is
|
||||
expected. Certificate verification can be controlled using the
|
||||
expected. Certificate verification can be controlled using the
|
||||
`TLSSkipVerify`.
|
||||
|
||||
If `TLSSkipVerify` is set to `true`, certificate verification will be
|
||||
|
|
@ -295,8 +295,8 @@ disabled. By default, certificate verification is enabled.
|
|||
|
||||
A `TCP` check will perform an TCP connection attempt against the value of `TCP`
|
||||
(expected to be an IP or hostname plus port combination) every `Interval`. If the
|
||||
connection attempt is successful, the check is `passing`. If the connection
|
||||
attempt is unsuccessful, the check is `critical`. In the case of a hostname
|
||||
connection attempt is successful, the check is `passing`. If the connection
|
||||
attempt is unsuccessful, the check is `critical`. In the case of a hostname
|
||||
that resolves to both IPv4 and IPv6 addresses, an attempt will be made to both
|
||||
addresses, and the first successful connection attempt will result in a
|
||||
successful check.
|
||||
|
|
@ -354,7 +354,7 @@ The return code is 200 on success.
|
|||
### <a name="agent_check_fail"></a> /v1/agent/check/fail/\<checkId\>
|
||||
|
||||
This endpoint is used with a check that is of the [TTL
|
||||
type](/docs/agent/checks.html). When this endpoint is accessed via a
|
||||
type](/docs/agent/checks.html). When this endpoint is accessed via a
|
||||
`GET`, the status of the check is set to `critical`, and the TTL clock is
|
||||
reset.
|
||||
|
||||
|
|
@ -394,7 +394,7 @@ The return code is 200 on success.
|
|||
|
||||
The register endpoint is used to add a new service, with an optional
|
||||
health check, to the local agent. There is more documentation on
|
||||
services [here](/docs/agent/services.html). The agent is responsible
|
||||
services [here](/docs/agent/services.html). The agent is responsible
|
||||
for managing the status of its local services, and for sending updates
|
||||
about its local services to the servers to keep the global Catalog in
|
||||
sync.
|
||||
|
|
@ -423,8 +423,8 @@ body must look like:
|
|||
}
|
||||
```
|
||||
|
||||
The `Name` field is mandatory. If an `ID` is not provided, it is set to
|
||||
`Name`. You cannot have duplicate `ID` entries per agent, so it may be
|
||||
The `Name` field is mandatory. If an `ID` is not provided, it is set to
|
||||
`Name`. You cannot have duplicate `ID` entries per agent, so it may be
|
||||
necessary to provide an ID in the case of a collision.
|
||||
|
||||
`Tags`, `Address`, `Port`, `Check` and `EnableTagOverride` are optional.
|
||||
|
|
@ -474,8 +474,8 @@ service. If you have multiple nodes all registering the same service
|
|||
their `EnableTagOverride` configuration and all other service
|
||||
configuration items are independent of one another. Updating the tags
|
||||
for the service registered on one node is independent of the same
|
||||
service (by name) registered on another node. If `EnableTagOverride` is
|
||||
not specified the default value is `false`. See [anti-entropy
|
||||
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
|
||||
|
|
@ -504,10 +504,10 @@ unavailable and will not be present in DNS or API queries. This API call is
|
|||
idempotent. Maintenance mode is persistent and will be automatically restored
|
||||
on agent restart. The maintenance endpoint expects a `PUT` request.
|
||||
|
||||
The `?enable` flag is required. Acceptable values are either `true` (to enter
|
||||
The `?enable` flag is required. Acceptable values are either `true` (to enter
|
||||
maintenance mode) or `false` (to resume normal operation).
|
||||
|
||||
The `?reason` flag is optional. If provided, its value should be a text string
|
||||
The `?reason` flag is optional. If provided, its value should be a text string
|
||||
explaining the reason for placing the service into maintenance mode. This is simply
|
||||
to aid human operators. If no reason is provided, a default value will be used instead.
|
||||
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ you may supply the `?stale` or `?consistent` query parameters with the
|
|||
request to control consistency. To support bounding the acceptable
|
||||
staleness of data, read-only transaction responses provide the
|
||||
`X-Consul-LastContact` header containing the time in milliseconds that a
|
||||
server was last contacted by the leader node. The
|
||||
server was last contacted by the leader node. The
|
||||
`X-Consul-KnownLeader` header also indicates if there is a known leader.
|
||||
These won't be present if the transaction contains any write operations,
|
||||
and any consistency query parameters will be ignored, since writes are
|
||||
|
|
@ -213,7 +213,7 @@ available verbs.
|
|||
|
||||
* `Key` is simply the full path of the entry.
|
||||
|
||||
* `Value` is a Base64-encoded blob of data. Values cannot be larger than
|
||||
* `Value` is a Base64-encoded blob of data. Values cannot be larger than
|
||||
512kB.
|
||||
|
||||
* `Flags` is an opaque unsigned integer that can be attached to each entry. Clients
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ query parameter can be used to specify the datacenter.
|
|||
|
||||
The session being renewed must be provided on the path.
|
||||
|
||||
The return code is 200 on success. The response JSON body looks like this:
|
||||
The return code is 200 on success. The response JSON body looks like this:
|
||||
|
||||
```javascript
|
||||
[
|
||||
|
|
|
|||
|
|
@ -578,9 +578,9 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
|
|||
* <a name="udp_answer_limit"></a><a
|
||||
href="#udp_answer_limit">`udp_answer_limit`</a> - Limit the number of
|
||||
resource records contained in the answer section of a UDP-based DNS
|
||||
response. When answering a question, Consul will use the complete list of
|
||||
response. When answering a question, Consul will use the complete list of
|
||||
matching hosts, shuffle the list randomly, and then limit the number of
|
||||
answers to `udp_answer_limit` (default `3`). In environments where
|
||||
answers to `udp_answer_limit` (default `3`). In environments where
|
||||
[RFC 3484 Section 6](https://tools.ietf.org/html/rfc3484#section-6) Rule 9
|
||||
is implemented and enforced (i.e. DNS answers are always sorted and
|
||||
therefore never random), clients may need to set this value to `1` to
|
||||
|
|
@ -744,12 +744,12 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
|
|||
* <a name="skip_leave_on_interrupt"></a><a
|
||||
href="#skip_leave_on_interrupt">`skip_leave_on_interrupt`</a> This is
|
||||
similar to [`leave_on_terminate`](#leave_on_terminate) but only affects
|
||||
interrupt handling. When Consul receives an interrupt signal (such as
|
||||
interrupt handling. When Consul receives an interrupt signal (such as
|
||||
hitting Control-C in a terminal), Consul will gracefully leave the cluster.
|
||||
Setting this to `true` disables that behavior. The default behavior for
|
||||
Setting this to `true` disables that behavior. The default behavior for
|
||||
this feature varies based on whether or not the agent is running as a
|
||||
client or a server (prior to Consul 0.7 the default value was
|
||||
unconditionally set to `false`). On agents in client-mode, this defaults
|
||||
unconditionally set to `false`). On agents in client-mode, this defaults
|
||||
to `false` and for agents in server-mode, this defaults to `true`
|
||||
(i.e. Ctrl-C on a server will keep the server in the cluster and therefore
|
||||
quorum, and Ctrl-C on a client will gracefully leave).
|
||||
|
|
@ -764,7 +764,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
|
|||
sends its runtime telemetry, and contains the following keys:
|
||||
|
||||
* <a name="telemetry-statsd_address"></a><a href="#telemetry-statsd_address">`statsd_address`</a> This provides the
|
||||
address of a statsd instance in the format `host:port`. If provided, Consul will send various telemetry information to that instance for
|
||||
address of a statsd instance in the format `host:port`. If provided, Consul will send various telemetry information to that instance for
|
||||
aggregation. This can be used to capture runtime information. This sends UDP packets only and can be used with
|
||||
statsd or statsite.
|
||||
|
||||
|
|
@ -811,7 +811,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass
|
|||
Force activation of metrics which already exist and are not currently active. If check management is enabled, the default behavior is to add new metrics as they are encoutered. If the metric already exists in the check, it will **not** be activated. This setting overrides that behavior. By default, this is set to false.
|
||||
|
||||
* <a name="telemetry-circonus_check_instance_id"></a><a href="#telemetry-circonus_check_instance_id">`circonus_check_instance_id`</a>
|
||||
Uniquely identifies the metrics coming from this *instance*. It can be used to maintain metric continuity with transient or ephemeral instances as they move around within an infrastructure. By default, this is set to hostname:application name (e.g. "host123:consul").
|
||||
Uniquely identifies the metrics coming from this *instance*. It can be used to maintain metric continuity with transient or ephemeral instances as they move around within an infrastructure. By default, this is set to hostname:application name (e.g. "host123:consul").
|
||||
|
||||
* <a name="telemetry-circonus_check_search_tag"></a><a href="#telemetry-circonus_check_search_tag">`circonus_check_search_tag`</a>
|
||||
A special tag which, when coupled with the instance id, helps to narrow down the search results when neither a Submission URL or Check ID is provided. By default, this is set to service:application name (e.g. "service:consul").
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ A service definition that is a script looks like:
|
|||
```
|
||||
|
||||
A service definition must include a `name` and may optionally provide an
|
||||
`id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The
|
||||
`id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The
|
||||
`id` is set to the `name` if not provided. It is required that all
|
||||
services have a unique ID per node, so if names might conflict then
|
||||
unique IDs should be provided.
|
||||
|
|
@ -92,10 +92,10 @@ modifications would be lost.
|
|||
It's important to note that this applies only to the locally registered
|
||||
service. If you have multiple nodes all registering the same service
|
||||
their `enableTagOverride` configuration and all other service
|
||||
configuration items are independent of one another. Updating the tags
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -62,8 +62,8 @@ the current state of the catalog can lag behind until the state is reconciled.
|
|||
To prevent an accumulation of dead nodes (nodes in either _failed_ or _left_
|
||||
states), Consul will automatically remove dead nodes out of the catalog. This
|
||||
process is called _reaping_. This is currently done on a configurable
|
||||
interval of 72 hours. Reaping is similar to leaving, causing all associated
|
||||
services to be deregistered. Changing the reap interval for aesthetic
|
||||
interval of 72 hours. Reaping is similar to leaving, causing all associated
|
||||
services to be deregistered. Changing the reap interval for aesthetic
|
||||
reasons to trim the number of _failed_ or _left_ nodes is not advised (nodes
|
||||
in the _failed_ or _left_ state do not cause any additional burden on
|
||||
Consul).
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ Since a join operation is symmetric, it does not matter which node initiates it.
|
|||
|
||||
As a sanity check, the [`consul info`](/docs/commands/info.html) command
|
||||
is a useful tool. It can be used to verify `raft.num_peers` is now 2,
|
||||
and you can view the latest log index under `raft.last_log_index`. When
|
||||
and you can view the latest log index under `raft.last_log_index`. When
|
||||
running [`consul info`](/docs/commands/info.html) on the followers, you
|
||||
should see `raft.last_log_index` converge to the same value once the
|
||||
leader begins replication. That value represents the last log entry that
|
||||
|
|
@ -80,7 +80,7 @@ has been stored on disk.
|
|||
|
||||
Now that the servers are all started and replicating to each other, all
|
||||
the remaining clients can be joined. Clients are much easier as they can
|
||||
join against any existing node. All nodes participate in a gossip
|
||||
join against any existing node. All nodes participate in a gossip
|
||||
protocol to perform basic discovery, so once joined to any member of the
|
||||
cluster, new clients will automatically find the servers and register
|
||||
themselves.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ layout: "docs"
|
|||
page_title: "Forwarding"
|
||||
sidebar_current: "docs-guides-forwarding"
|
||||
description: |-
|
||||
By default, DNS is served from port 53. On most operating systems, this requires elevated privileges. Instead of running Consul with an administrative or root account, it is possible to instead forward appropriate queries to Consul, running on an unprivileged port, from another DNS server or port redirect.
|
||||
By default, DNS is served from port 53. On most operating systems, this requires elevated privileges. Instead of running Consul with an administrative or root account, it is possible to instead forward appropriate queries to Consul, running on an unprivileged port, from another DNS server or port redirect.
|
||||
---
|
||||
|
||||
# Forwarding DNS
|
||||
|
|
@ -16,7 +16,7 @@ running on an unprivileged port, from another DNS server or port redirect.
|
|||
In this guide, we will demonstrate forwarding from
|
||||
[BIND](https://www.isc.org/downloads/bind/) as well as
|
||||
[dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) and
|
||||
[iptables](http://www.netfilter.org/). For the sake of simplicity, BIND
|
||||
[iptables](http://www.netfilter.org/). For the sake of simplicity, BIND
|
||||
and Consul are running on the same machine in this example. For iptables
|
||||
the rules must be set on the same host as the Consul instance and relay
|
||||
hosts should not be on the same host or the redirects will intercept the
|
||||
|
|
@ -80,7 +80,7 @@ DNS on port 8600.
|
|||
### Dnsmasq Setup
|
||||
|
||||
Dnsmasq is typically configured via a `dnsmasq.conf` or a series of files in
|
||||
the `/etc/dnsmasq.d` directory. In Dnsmasq's configuration file
|
||||
the `/etc/dnsmasq.d` directory. In Dnsmasq's configuration file
|
||||
(e.g. `/etc/dnsmasq.d/10-consul`), add the following:
|
||||
|
||||
```text
|
||||
|
|
@ -118,8 +118,8 @@ for additional details):
|
|||
#no-resolv
|
||||
|
||||
# Specify IP address(es) of other DNS servers for queries not handled
|
||||
# directly by consul. There is normally one 'server' entry set for every
|
||||
# 'nameserver' parameter found in '/etc/resolv.conf'. See dnsmasq(8)'s
|
||||
# directly by consul. There is normally one 'server' entry set for every
|
||||
# 'nameserver' parameter found in '/etc/resolv.conf'. See dnsmasq(8)'s
|
||||
# 'server' configuration option for details.
|
||||
#server=1.2.3.4
|
||||
#server=208.67.222.222
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ cover all the possible methods. Instead, we will focus on using Consul's support
|
|||
[sessions](/docs/internals/sessions.html). Sessions allow us to build a system that
|
||||
can gracefully handle failures.
|
||||
|
||||
-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted.
|
||||
-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted.
|
||||
|
||||
## Contending Nodes
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ has not declared the node unhealthy. Additional checks can be specified if desir
|
|||
|
||||
Watching for changes is done via a blocking query against `<prefix>`. If a contender
|
||||
holds a slot, then on any change the `<lock>` should be re-checked to ensure the slot is
|
||||
still held. If no slot is held, then the same acquisition logic is triggered to check
|
||||
still held. If no slot is held, then the same acquisition logic is triggered to check
|
||||
and potentially re-attempt acquisition. This allows a contender to steal the slot from
|
||||
a failed contender or one that has voluntarily released its slot.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ on tokens to which fine grained rules can be applied. It is very similar to
|
|||
## Scope
|
||||
|
||||
When the ACL system was launched in Consul 0.4, it was only possible to specify
|
||||
policies for the KV store. In Consul 0.5, ACL policies were extended to service
|
||||
policies for the KV store. In Consul 0.5, ACL policies were extended to service
|
||||
registrations. In Consul 0.6, ACL's were further extended to restrict service
|
||||
discovery mechanisms, user events, and encryption keyring operations.
|
||||
|
||||
|
|
|
|||
|
|
@ -139,14 +139,14 @@ automatically recover from these types of transient failures.
|
|||
### EnableTagOverride
|
||||
|
||||
Synchronization of service registration can be partially modified to
|
||||
allow external agents to change the tags for a service. This can be
|
||||
allow external agents to change the tags for a service. This can be
|
||||
useful in situations where an external monitoring service needs to be
|
||||
the source of truth for tag information. For example, the Redis
|
||||
the source of truth for tag information. For example, the Redis
|
||||
database and its monitoring service Redis Sentinel have this kind of
|
||||
relationship. Redis instances are responsible for much of their
|
||||
relationship. Redis instances are responsible for much of their
|
||||
configuration, but Sentinels determine whether the Redis instance is a
|
||||
primary or a secondary. Using the Consul service configuration item
|
||||
primary or a secondary. Using the Consul service configuration item
|
||||
[EnableTagOverride](/docs/agent/services.html) you can instruct the
|
||||
Consul agent on which the Redis database is running to NOT update the
|
||||
tags during anti-entropy synchronization. For more information see
|
||||
tags during anti-entropy synchronization. For more information see
|
||||
[Services](/docs/agent/services.html) page.
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ The first definition adds a host-level check named "ping". This check runs
|
|||
on a 30 second interval, invoking `ping -c1 google.com`. On a `script`-based
|
||||
health check, the check runs as the same user that started the Consul process.
|
||||
If the command exits with a non-zero exit code, then the node will be flagged
|
||||
unhealthy. This is the contract for any `script`-based health check.
|
||||
unhealthy. This is the contract for any `script`-based health check.
|
||||
|
||||
The second command modifies the service named `web`, adding a check that sends a
|
||||
request every 10 seconds via curl to verify that the web server is accessible.
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ be extended to a scalable, production-grade service discovery infrastructure.
|
|||
In this step, we'll create our first real cluster with multiple members.
|
||||
|
||||
When a Consul agent is started, it begins without knowledge of any other node:
|
||||
it is an isolated cluster of one. To learn about other cluster members, the
|
||||
agent must _join_ an existing cluster. To join an existing cluster, it only
|
||||
it is an isolated cluster of one. To learn about other cluster members, the
|
||||
agent must _join_ an existing cluster. To join an existing cluster, it only
|
||||
needs to know about a _single_ existing member. After it joins, the agent will
|
||||
gossip with this member and quickly discover the other members in the cluster.
|
||||
A Consul agent can join any other agent, not just agents in server mode.
|
||||
|
|
|
|||
|
|
@ -61,6 +61,6 @@ You can view a live demo of the Consul Web UI
|
|||
|
||||
## Next Steps
|
||||
|
||||
This concludes our Getting Started guide. See the
|
||||
This concludes our Getting Started guide. See the
|
||||
[next steps](next-steps.html) page to learn more about how to continue
|
||||
your journey with Consul!
|
||||
|
|
|
|||
Loading…
Reference in New Issue