Update FAQ + formatting (#7816)
* Update FAQ + formatting * Fix 80 chars lines in FAQ
This commit is contained in:
parent
3eb4e4012a
commit
38ba851993
|
@ -10,10 +10,11 @@ sidebar_title: FAQ
|
|||
|
||||
Consul makes use of a HashiCorp service called [Checkpoint](http://checkpoint.hashicorp.com)
|
||||
which is used to check for updates and critical security bulletins.
|
||||
Only anonymous information, which cannot be used to identify the user or host, is
|
||||
sent to Checkpoint . An anonymous ID is sent which helps de-duplicate warning messages.
|
||||
This anonymous ID can be disabled. In fact, using the Checkpoint service is optional
|
||||
and can be disabled.
|
||||
Only anonymous information, which cannot be used to identify the user or host,
|
||||
is sent to Checkpoint. An anonymous ID is sent which helps de-duplicate warning
|
||||
messages.
|
||||
This anonymous ID can be disabled. In fact, using the Checkpoint service is
|
||||
optional and can be disabled.
|
||||
|
||||
See [`disable_anonymous_signature`](/docs/agent/options#disable_anonymous_signature)
|
||||
and [`disable_update_check`](/docs/agent/options#disable_update_check).
|
||||
|
@ -21,26 +22,29 @@ and [`disable_update_check`](/docs/agent/options#disable_update_check).
|
|||
## Q: Does Consul rely on UDP Broadcast or Multicast?
|
||||
|
||||
Consul uses the [Serf](https://www.serf.io) gossip protocol which relies on
|
||||
TCP and UDP unicast. Broadcast and Multicast are rarely available in a multi-tenant
|
||||
or cloud network environment. For that reason, Consul and Serf were both
|
||||
designed to avoid any dependence on those capabilities.
|
||||
TCP and UDP unicast. Broadcast and Multicast are rarely available in a
|
||||
multi-tenant or cloud network environment. For that reason, Consul and Serf
|
||||
were both designed to avoid any dependence on those capabilities.
|
||||
|
||||
## Q: Is Consul eventually or strongly consistent?
|
||||
|
||||
Consul has two important subsystems, the service catalog and the gossip protocol.
|
||||
Consul has two important subsystems, the service catalog and the gossip
|
||||
protocol.
|
||||
The service catalog stores all the nodes, service instances, health check data,
|
||||
ACLs, and KV information. It is strongly consistent, and replicated
|
||||
using the [consensus protocol](/docs/internals/consensus).
|
||||
|
||||
The [gossip protocol](/docs/internals/gossip) is used to track which
|
||||
nodes are part of the cluster and to detect a node or agent failure. This information
|
||||
is eventually consistent by nature. When the servers detects a change in membership,
|
||||
or receive a health update, they update the service catalog appropriately.
|
||||
nodes are part of the cluster and to detect a node or agent failure. This
|
||||
information is eventually consistent by nature. When the servers detects a
|
||||
change in membership, or receive a health update, they update the service
|
||||
catalog appropriately.
|
||||
|
||||
Because of this split, the answer to the question is subtle. Almost all client APIs
|
||||
interact with the service catalog and are strongly consistent. Updates to the
|
||||
catalog may come via the gossip protocol which is eventually consistent, meaning
|
||||
the current state of the catalog can lag behind until the state is reconciled.
|
||||
Because of this split, the answer to the question is subtle. Almost all client
|
||||
APIs interact with the service catalog and are strongly consistent. Updates to
|
||||
the catalog may come via the gossip protocol which is eventually consistent
|
||||
meaning the current state of the catalog can lag behind until the state is
|
||||
reconciled.
|
||||
|
||||
## Q: Are _failed_ or _left_ nodes ever removed?
|
||||
|
||||
|
@ -66,7 +70,8 @@ as well as race conditions between data updates and watch registrations.
|
|||
|
||||
## Q: What network ports does Consul use?
|
||||
|
||||
The [Ports Used](/docs/agent/options#ports) section of the Configuration documentation lists all ports that Consul uses.
|
||||
The [Ports Used](/docs/agent/options#ports) section of the Configuration
|
||||
documentation lists all ports that Consul uses.
|
||||
|
||||
## Q: Does Consul require certain user process resource limits?
|
||||
|
||||
|
@ -98,23 +103,35 @@ is not designed to be used as a general purpose database. See
|
|||
## Q: What data is replicated between Consul datacenters?
|
||||
|
||||
In general, data is not replicated between different Consul datacenters. When a
|
||||
request is made for a resource in another datacenter, the local Consul servers forward
|
||||
an RPC request to the remote Consul servers for that resource and return the results.
|
||||
request is made for a resource in another datacenter, the local Consul servers
|
||||
forward an RPC request to the remote Consul servers for that resource and
|
||||
return the results.
|
||||
If the remote datacenter is not available, then those resources will also not be
|
||||
available, but that won't otherwise affect the local datacenter. There are some special
|
||||
situations where a limited subset of data can be replicated, such as with Consul's built-in
|
||||
[ACL replication](https://learn.hashicorp.com/consul/day-2-operations/acl-replication) capability, or
|
||||
external tools like [consul-replicate](https://github.com/hashicorp/consul-replicate).
|
||||
available from that datacenter. That will not affect the requests to the local
|
||||
datacenter. There are some special situations where a limited subset of data
|
||||
can be replicated, such as with Consul's built-in
|
||||
[ACL replication](https://learn.hashicorp.com/consul/day-2-operations/acl-replication)
|
||||
capability, or external tools like
|
||||
[consul-replicate](https://github.com/hashicorp/consul-replicate).
|
||||
|
||||
## Q: Can Consul natively handle protecting against other processes accessing Consul's memory state?
|
||||
|
||||
Consul does not provide built-in memory access protections, and doesn't interact with the host system to change or manipulate
|
||||
Consul does not provide built-in memory access protections, and doesn't
|
||||
interact with the host system to change or manipulate
|
||||
viewing and doesn't interact with the host system to change or manipulate
|
||||
application security.
|
||||
|
||||
We recommend taking any precautions or
|
||||
remediation steps that you would normally do for individual processes, based
|
||||
on your operating system.
|
||||
We recommend taking any precautions or remediation steps that you would
|
||||
normally do for individual processes, based on your operating system.
|
||||
|
||||
Please see our
|
||||
[Security Model](/docs/internals/security) for more information.
|
||||
|
||||
## Q: Are the Consul Docker Images OCI Compliant?
|
||||
|
||||
The official [Consul Docker image](https://hub.docker.com/_/consul/) uses
|
||||
[Docker image schema](https://docs.docker.com/registry/spec/manifest-v2-2/) V2,
|
||||
which is OCI Compliant. To check the docker images on Docker Hub, use the
|
||||
command `docker manifest inspect consul` to inspect the manifest payload. The
|
||||
`docker manifest inspect` may require you to enable experimental features to
|
||||
use.
|
||||
|
|
Loading…
Reference in New Issue