mirror of https://github.com/status-im/consul.git
Fix some typos in website docs
This commit is contained in:
parent
cf7e9e40d5
commit
3da9291ae1
|
@ -3,7 +3,7 @@ layout: "docs"
|
||||||
page_title: "Encryption"
|
page_title: "Encryption"
|
||||||
sidebar_current: "docs-agent-encryption"
|
sidebar_current: "docs-agent-encryption"
|
||||||
description: |-
|
description: |-
|
||||||
The Consul agent supports encrypting all of its network traffic. The exact method of this encryption is described on the encryption internals page. There are two seperate systems, one for gossip traffic and one for RPC.
|
The Consul agent supports encrypting all of its network traffic. The exact method of this encryption is described on the encryption internals page. There are two separate systems, one for gossip traffic and one for RPC.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Encryption
|
# Encryption
|
||||||
|
@ -11,7 +11,7 @@ description: |-
|
||||||
The Consul agent supports encrypting all of its network traffic. The exact
|
The Consul agent supports encrypting all of its network traffic. The exact
|
||||||
method of this encryption is described on the
|
method of this encryption is described on the
|
||||||
[encryption internals page](/docs/internals/security.html). There are two
|
[encryption internals page](/docs/internals/security.html). There are two
|
||||||
seperate systems, one for gossip traffic and one for RPC.
|
separate systems, one for gossip traffic and one for RPC.
|
||||||
|
|
||||||
## Gossip Encryption
|
## Gossip Encryption
|
||||||
|
|
||||||
|
@ -74,7 +74,7 @@ key pair set using `cert_file` and `key_file`.
|
||||||
If `verify_incoming` is set, then the servers verify the authenticity of all incoming
|
If `verify_incoming` is set, then the servers verify the authenticity of all incoming
|
||||||
connections. Servers will also disallow any non-TLS connections. If this is set, then all
|
connections. Servers will also disallow any non-TLS connections. If this is set, then all
|
||||||
clients must have a valid key pair set using `cert_file` and `key_file`. To force clients to
|
clients must have a valid key pair set using `cert_file` and `key_file`. To force clients to
|
||||||
use TLs, `verify_outgoing` must also be set.
|
use TLS, `verify_outgoing` must also be set.
|
||||||
|
|
||||||
TLS is used to secure the RPC calls between agents, but gossip between nodes is done over UDP
|
TLS is used to secure the RPC calls between agents, but gossip between nodes is done over UDP
|
||||||
and is secured using a symmetric key. See above for enabling gossip encryption.
|
and is secured using a symmetric key. See above for enabling gossip encryption.
|
||||||
|
|
|
@ -188,7 +188,7 @@ be used with a PUT request:
|
||||||
|
|
||||||
* ?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 it allows clients to build more complex
|
operation. This is very useful as it allows clients to build more complex
|
||||||
syncronization primitives on top. If the index is 0, then Consul will only
|
synchronization primitives on top. If the index is 0, then Consul will only
|
||||||
put the key if it does not already exist. If the index is non-zero, then
|
put the key if it does not already exist. If the index is non-zero, then
|
||||||
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.
|
||||||
|
|
||||||
|
@ -607,7 +607,7 @@ 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 direclty removing
|
The deregister endpoint is a low level mechanism for directly removing
|
||||||
entries in the catalog. It is usually recommended to use the agent local
|
entries in the catalog. It is usually recommended to use the agent local
|
||||||
endpoints, as they are simpler and perform anti-entropy.
|
endpoints, as they are simpler and perform anti-entropy.
|
||||||
|
|
||||||
|
|
|
@ -152,7 +152,7 @@ at a single JSON object with configuration within it.
|
||||||
Configuration files are used for more than just setting up the agent,
|
Configuration files are used for more than just setting up the agent,
|
||||||
they are also used to provide check and service definitions. These are used
|
they are also used to provide check and service definitions. These are used
|
||||||
to announce the availability of system servers to the rest of the cluster.
|
to announce the availability of system servers to the rest of the cluster.
|
||||||
They are documented seperately under [check configuration](/docs/agent/checks.html) and
|
They are documented separately under [check configuration](/docs/agent/checks.html) and
|
||||||
[service configuration](/docs/agent/services.html) respectively. The service and check
|
[service configuration](/docs/agent/services.html) respectively. The service and check
|
||||||
definitions support being updated during a reload.
|
definitions support being updated during a reload.
|
||||||
|
|
||||||
|
@ -188,7 +188,7 @@ definitions support being updated during a reload.
|
||||||
* `acl_default_policy` - Either "allow" or "deny", defaults to "allow". The
|
* `acl_default_policy` - Either "allow" or "deny", defaults to "allow". The
|
||||||
default policy controls the behavior of a token when there is no matching
|
default policy controls the behavior of a token when there is no matching
|
||||||
rule. In "allow" mode, ACLs are a blacklist: any operation not specifically
|
rule. In "allow" mode, ACLs are a blacklist: any operation not specifically
|
||||||
prohibited is allowed. In "deny" mode, ACLs are a whilelist: any operation not
|
prohibited is allowed. In "deny" mode, ACLs are a whitelist: any operation not
|
||||||
specifically allowed is blocked.
|
specifically allowed is blocked.
|
||||||
|
|
||||||
* `acl_down_policy` - Either "allow", "deny" or "extend-cache" which is the
|
* `acl_down_policy` - Either "allow", "deny" or "extend-cache" which is the
|
||||||
|
@ -237,12 +237,12 @@ definitions support being updated during a reload.
|
||||||
Must be provided along with the `key_file`.
|
Must be provided along with the `key_file`.
|
||||||
|
|
||||||
* `check_update_interval` - This interval controls how often check output from
|
* `check_update_interval` - This interval controls how often check output from
|
||||||
checks in a steady state is syncronized with the server. By default, this is
|
checks in a steady state is synchronized with the server. By default, this is
|
||||||
set to 5 minutes ("5m"). Many checks which are in a steady state produce
|
set to 5 minutes ("5m"). Many checks which are in a steady state produce
|
||||||
slightly different output per run (timestamps, etc) which cause constant writes.
|
slightly different output per run (timestamps, etc) which cause constant writes.
|
||||||
This configuration allows defering the sync of check output for a given interval to
|
This configuration allows deferring the sync of check output for a given interval to
|
||||||
reduce write pressure. If a check ever changes state, the new state and associated
|
reduce write pressure. If a check ever changes state, the new state and associated
|
||||||
output is syncronized immediately. To disable this behavior, set the value to "0s".
|
output is synchronized immediately. To disable this behavior, set the value to "0s".
|
||||||
|
|
||||||
* `client_addr` - Equivalent to the `-client` command-line flag.
|
* `client_addr` - Equivalent to the `-client` command-line flag.
|
||||||
|
|
||||||
|
@ -260,7 +260,7 @@ definitions support being updated during a reload.
|
||||||
new version releases.
|
new version releases.
|
||||||
|
|
||||||
* `dns_config` - This object allows a number of sub-keys to be set which can tune
|
* `dns_config` - This object allows a number of sub-keys to be set which can tune
|
||||||
how DNS queries are perfomed. See this guide on [DNS caching](/docs/guides/dns-cache.html).
|
how DNS queries are performed. See this guide on [DNS caching](/docs/guides/dns-cache.html).
|
||||||
The following sub-keys are available:
|
The following sub-keys are available:
|
||||||
|
|
||||||
* `allow_stale` - Enables a stale query for DNS information. This allows any Consul
|
* `allow_stale` - Enables a stale query for DNS information. This allows any Consul
|
||||||
|
@ -395,7 +395,7 @@ port.
|
||||||
* Serf LAN (Default 8301). This is used to handle gossip in the LAN.
|
* Serf LAN (Default 8301). This is used to handle gossip in the LAN.
|
||||||
Required by all agents, TCP and UDP.
|
Required by all agents, TCP and UDP.
|
||||||
|
|
||||||
* Serf WAN( Default 8302). This is used by servers to gossip over the
|
* Serf WAN (Default 8302). This is used by servers to gossip over the
|
||||||
WAN to other servers. TCP and UDP.
|
WAN to other servers. TCP and UDP.
|
||||||
|
|
||||||
* CLI RPC (Default 8400). This is used by all agents to handle RPC
|
* CLI RPC (Default 8400). This is used by all agents to handle RPC
|
||||||
|
|
|
@ -32,7 +32,7 @@ in a JSON body when using agent configuration, or as CLI flags for the watch com
|
||||||
|
|
||||||
## Handlers
|
## Handlers
|
||||||
|
|
||||||
The watch specifiation specifies the view of data to be monitored.
|
The watch specification specifies the view of data to be monitored.
|
||||||
Once that view is updated the specified handler is invoked. The handler
|
Once that view is updated the specified handler is invoked. The handler
|
||||||
can be any executable.
|
can be any executable.
|
||||||
|
|
||||||
|
|
|
@ -16,7 +16,7 @@ to build scripting infrastructure to do automated deploys, restart services,
|
||||||
or perform any other orchestration action. Events can be handled by
|
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 propogated 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 guarantee** delivery. Unlike most Consul data, which is
|
the event, but there is **no guarantee** delivery. Unlike most Consul data, which is
|
||||||
|
@ -24,7 +24,7 @@ replicated using [consensus](/docs/internals/consensus.html), event data
|
||||||
is purely peer-to-peer over gossip. This means it is not persisted and does
|
is purely peer-to-peer over gossip. This means it is not persisted and does
|
||||||
not have a total ordering. In practice, this means you cannot rely on the
|
not have a total ordering. In practice, this means you cannot rely on the
|
||||||
order of message delivery. An advantage however is that events can still
|
order of message delivery. An advantage however is that events can still
|
||||||
be used even in the absense of server nodes or during an outage.
|
be used even in the absence of server nodes or during an outage.
|
||||||
|
|
||||||
The underlying gossip also sets limits on the size of a user event
|
The underlying gossip also sets limits on the size of a user event
|
||||||
message. It is hard to give an exact number, as it depends on various
|
message. It is hard to give an exact number, as it depends on various
|
||||||
|
|
|
@ -16,7 +16,7 @@ the `web` service.
|
||||||
|
|
||||||
Remote execution works by specifying a job which is stored in the KV store.
|
Remote execution works by specifying a job which is stored in the KV store.
|
||||||
Agent's are informed about the new job using the [event system](/docs/commands/event.html),
|
Agent's are informed about the new job using the [event system](/docs/commands/event.html),
|
||||||
which propogates messages via the [gossip protocol](/docs/internals/gossip.html).
|
which propagates messages via the [gossip protocol](/docs/internals/gossip.html).
|
||||||
As a result, delivery is best-effort, and there is **no guarantee** of execution.
|
As a result, delivery is best-effort, and there is **no guarantee** of execution.
|
||||||
|
|
||||||
While events are purely gossip driven, remote execution relies on the KV store
|
While events are purely gossip driven, remote execution relies on the KV store
|
||||||
|
|
|
@ -3,12 +3,12 @@ layout: "docs"
|
||||||
page_title: "Sessions"
|
page_title: "Sessions"
|
||||||
sidebar_current: "docs-internals-sessions"
|
sidebar_current: "docs-internals-sessions"
|
||||||
description: |-
|
description: |-
|
||||||
Consul provides a session mechansim which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking, and are heavily inspired by The Chubby Lock Service for Loosely-Coupled Distributed Systems.
|
Consul provides a session mechanism which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking, and are heavily inspired by The Chubby Lock Service for Loosely-Coupled Distributed Systems.
|
||||||
---
|
---
|
||||||
|
|
||||||
# Sessions
|
# Sessions
|
||||||
|
|
||||||
Consul provides a session mechansim which can be used to build distributed locks.
|
Consul provides a session mechanism which can be used to build distributed locks.
|
||||||
Sessions act as a binding layer between nodes, health checks, and key/value data.
|
Sessions act as a binding layer between nodes, health checks, and key/value data.
|
||||||
They are designed to provide granular locking, and are heavily inspired
|
They are designed to provide granular locking, and are heavily inspired
|
||||||
by [The Chubby Lock Service for Loosely-Coupled Distributed Systems](http://research.google.com/archive/chubby.html).
|
by [The Chubby Lock Service for Loosely-Coupled Distributed Systems](http://research.google.com/archive/chubby.html).
|
||||||
|
@ -31,7 +31,7 @@ Below is a diagram showing the relationship between these components:
|
||||||
![Consul Sessions](consul-sessions.png)
|
![Consul Sessions](consul-sessions.png)
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
The contract that Consul provides is that under any of the folllowing
|
The contract that Consul provides is that under any of the following
|
||||||
situations the session will be *invalidated*:
|
situations the session will be *invalidated*:
|
||||||
|
|
||||||
* Node is deregistered
|
* Node is deregistered
|
||||||
|
@ -79,7 +79,7 @@ mechanism by providing a zero delay value.
|
||||||
|
|
||||||
Integration between the Key/Value store and sessions are the primary
|
Integration between the Key/Value store and sessions are the primary
|
||||||
place where sessions are used. A session must be created prior to use,
|
place where sessions are used. A session must be created prior to use,
|
||||||
and is then refered to by it's ID.
|
and is then referred to by it's ID.
|
||||||
|
|
||||||
The Key/Value API is extended to support an `acquire` and `release` operation.
|
The Key/Value API is extended to support an `acquire` and `release` operation.
|
||||||
The `acquire` operation acts like a Check-And-Set operation, except it
|
The `acquire` operation acts like a Check-And-Set operation, except it
|
||||||
|
|
|
@ -30,7 +30,7 @@ integrated health checking, Consul can route traffic away from unhealthy
|
||||||
nodes, allowing systems and services to gracefully recover. Static configuration
|
nodes, allowing systems and services to gracefully recover. Static configuration
|
||||||
that may be provided by configuration management tools can be moved into the
|
that may be provided by configuration management tools can be moved into the
|
||||||
dynamic key/value store. This allows application configuration to be updated
|
dynamic key/value store. This allows application configuration to be updated
|
||||||
without a slow convergence run. Lastly, because each datacenter runs indepedently,
|
without a slow convergence run. Lastly, because each datacenter runs independently,
|
||||||
supporting multiple datacenters is no different than a single datacenter.
|
supporting multiple datacenters is no different than a single datacenter.
|
||||||
|
|
||||||
That said, Consul is not a replacement for configuration management tools.
|
That said, Consul is not a replacement for configuration management tools.
|
||||||
|
|
Loading…
Reference in New Issue