luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

[docs] Updating links to guides (#5795) 

* fixing links in the docs post guide migartion.

* fixed one more

* Update website/source/docs/acl/acl-legacy.html.md

Co-Authored-By: kaitlincarter-hc <43049322+kaitlincarter-hc@users.noreply.github.com>

* Update website/source/docs/enterprise/connect-multi-datacenter/index.html.md

* Updating based on comments and fixing word wrap

* Update website/source/api/acl-legacy.html.md

* Update website/source/api/acl/acl.html.md

* Update website/source/docs/agent/options.html.md

* Update website/source/docs/faq.html.md

* Update website/source/docs/internals/architecture.html.md

* Update website/source/docs/agent/encryption.html.md
This commit is contained in:
kaitlincarter-hc 2019-05-15 10:49:41 -05:00 committed by GitHub
parent 63fa27b1c6
commit 9074778c0c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
46 changed files with 374 additions and 175 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
website/source/api/acl-legacy.html.md
View File

@ -12,7 +12,8 @@ the new ACL [Token](/docs/api/acl-token.html) and [Policy](/docs/api/acl-policy.
# ACL HTTP API
These `/acl` endpoints create, update, destroy, and query ACL tokens in Consul. For more information about ACLs, please see the [ACL Guide](/docs/guides/acl.html).
These `/acl` endpoints create, update, destroy, and query ACL tokens in Consul. For more information about ACLs, please see the
[ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls).
## Bootstrap ACLs
@ -61,7 +62,8 @@ a 403 means that the cluster has already been bootstrapped, at which point you s
consider the cluster in a potentially compromised state.
The returned token will be a management token which can be used to further configure the
ACL system. Please see the [ACL Guide](/docs/guides/acl.html) for more details.
ACL system. Please see the
[ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls) for more details.
## Create ACL Token
@ -92,7 +94,7 @@ The table below shows this endpoint's support for
are: `client` and `management`.
- `Rules` `(string: "")` - Specifies rules for this ACL token. The format of the
`Rules` property is documented in the [ACL Guide](/docs/guides/acl.html).
`Rules` property is documented in the [ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls).
### Sample Payload
@ -347,8 +349,8 @@ This endpoint returns the status of the ACL replication process in the
datacenter. This is intended to be used by operators, or by automation checking
the health of ACL replication.
Please see the [ACL Guide](/docs/guides/acl.html#replication) replication
section for more details.
Please see the [ACL Replication Guide](https://learn.hashicorp.com/consul/day-2-operations/acl-replication) for more details.
for more details.
| Method | Path | Produces |
| ------ | ---------------------------- | -------------------------- |

6
website/source/api/acl/acl.html.md
View File

@ -80,7 +80,7 @@ consider the cluster in a potentially compromised state.
The returned token will have unrestricted privileges to manage all details of the system.
It can then be used to further configure the ACL system. Please see the
[ACL Guide](/docs/guides/acl.html) for more details.
[ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls) for more details.
## Check ACL Replication
@ -88,8 +88,8 @@ This endpoint returns the status of the ACL replication processes in the
datacenter. This is intended to be used by operators or by automation checking
to discover the health of ACL replication.
Please see the [ACL Guide](/docs/guides/acl.html#replication) replication
section for more details.
Please see the [ACL Replication Guide](https://learn.hashicorp.com/consul/day-2-operations/acl-replication)
for more details.
| Method | Path | Produces |
| ------ | ---------------------------- | -------------------------- |

4
website/source/api/acl/legacy.html.md
View File

@ -14,7 +14,7 @@ the new ACL [Token](/api/acl/tokens.html) and [Policy](/api/acl/policies.html) A
The `/acl` endpoints create, update, destroy, and query ACL tokens in Consul.
For more information about ACLs, please see the [ACL Guide](/docs/guides/acl-legacy.html).
For more information about ACLs, please see the [ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls).
## Create ACL Token
@ -45,7 +45,7 @@ The table below shows this endpoint's support for
are: `client` and `management`.
- `Rules` `(string: "")` - Specifies rules for this ACL token. The format of the
`Rules` property is documented in the [ACL Guide](/docs/guides/acl-legacy.html).
`Rules` property is detailed in the [ACL Rule documentation](/docs/acl/acl-rules.html).
### Sample Payload

4
website/source/api/acl/policies.html.md
View File

@ -44,7 +44,7 @@ The table below shows this endpoint's support for
- `Description` `(string: "")` - Free form human readable description of the policy.
- `Rules` `(string: "")` - Specifies rules for the ACL policy. The format of the
`Rules` property is documented in the [ACL Guide](/docs/guides/acl.html).
`Rules` property is detailed in the [ACL Rules documentation](/docs/acl/acl-rules.html).
- `Datacenters` `(array<string>)` - Specifies the datacenters the policy is valid within.
When no datacenters are provided the policy is valid in all datacenters including
@ -164,7 +164,7 @@ The table below shows this endpoint's support for
- `Description` `(string: "")` - Free form human readable description of this policy.
- `Rules` `(string: "")` - Specifies rules for this ACL policy. The format of the
`Rules` property is documented in the [ACL Guide](/docs/guides/acl.html).
`Rules` property is detailed in the [ACL Rules documentation](/docs/acl/acl-rules.html).
- `Datacenters` `(array<string>)` - Specifies the datacenters this policy is valid within.
When no datacenters are provided the policy is valid in all datacenters including

2
website/source/api/kv.html.md
View File

@ -194,7 +194,7 @@ The table below shows this endpoint's support for
session has locked the key.**
For an example of how to use the lock feature, see the [Leader Election Guide]
(/docs/guides/leader-election.html).
(https://learn.hashicorp.com/consul/developer-configuration/elections).
- `release` `(string: "")` - Supply a session ID to use in a release operation. This is
useful when paired with `?acquire=` as it allows clients to yield a lock. This

4
website/source/api/operator.html.md
View File

@ -15,10 +15,10 @@ operations manually, please see the documentation for the
[`consul operator`](/docs/commands/operator.html) command.
If ACLs are enabled then a token with operator privileges may be required in
order to use this interface. See the [ACL Guide](/docs/guides/acl.html#operator)
order to use this interface. See the [ACL Rules documentation](/docs/acl/acl-rules.html#operator-rules)
for more information.
See the [Outage Recovery](/docs/guides/outage.html) guide for some examples of
See the [Outage Recovery](https://learn.hashicorp.com/consul/day-2-operations/outage) guide for some examples of
how these capabilities are used.
Please choose a sub-section in the navigation for more information.

2
website/source/api/operator/area.html.md
View File

@ -26,7 +26,7 @@ datacenters, so not all servers need to be fully connected. This allows for
complex topologies among Consul datacenters like hub/spoke and more general
trees.
Please see the [Network Areas Guide](/docs/guides/advanced-federation.html) for more details.
Please see the [Network Areas Guide](https://learn.hashicorp.com/consul/day-2-operations/advanced-federation) for more details.
## Create Network Area

2
website/source/api/operator/autopilot.html.md
View File

@ -14,7 +14,7 @@ The `/operator/autopilot` endpoints allow for automatic operator-friendly
management of Consul servers including cleanup of dead servers, monitoring
the state of the Raft cluster, and stable server introduction.
Please see the [Autopilot Guide](/docs/guides/autopilot.html) for more details.
Please see the [Autopilot Guide](https://learn.hashicorp.com/consul/day-2-operations/autopilot) for more details.
## Read Configuration

2
website/source/api/operator/segment.html.md
View File

@ -20,7 +20,7 @@ The network area functionality described here is available only in
later. Network segments are operator-defined sections of agents on the LAN, typically
isolated from other segments by network configuration.
Please see the [Network Segments Guide](/docs/guides/network-segments.html) for more details.
Please see the [Network Segments Guide](https://learn.hashicorp.com/consul/day-2-operations/network-segments) for more details.
## List Network Segments

2
website/source/api/query.html.md
View File

@ -16,7 +16,7 @@ service. This is particularly useful in combination with Consul's
[DNS Interface](/docs/agent/dns.html) as it allows for much richer queries than
would be possible given the limited entry points exposed by DNS.
See the [Geo Failover Guide](/docs/guides/geo-failover.html) for details and
See the [Geo Failover Guide](https://learn.hashicorp.com/consul/developer-discovery/geo-failover) for details and
examples for using prepared queries to implement geo failover for services.
See the [prepared query rules](/docs/agent/acl-rules.html#prepared-query-rules)

2
website/source/api/session.html.md
View File

@ -57,7 +57,7 @@ The table below shows this endpoint's support for
86400s). If 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 sessions low. When locks are forcibly expired, such as when following
the [leader election pattern](/docs/guides/leader-election.html) in an application,
the [leader election pattern](https://learn.hashicorp.com/consul/developer-configuration/elections) in an application,
sessions may not be reaped for up to double this TTL, so long TTL
values (> 1 hour) should be avoided.

2
website/source/discovery.html.erb
View File

@ -167,7 +167,7 @@ web-frontend.service.consul. 0 IN A <code class='keyword'>10.0.1.109</code></cod
<h3>Multi Datacenter</h3>
<p>Consul supports multiple datacenters out of the box with no complicated configuration. Look up services in other datacenters or keep the request local. Advanced features like Prepared Queries enable automatic failover to other datacenters.</p>
<p>
<a class="learn-more" href='/docs/guides/datacenters.html'>Learn more<svg xmlns="http://www.w3.org/2000/svg" width="6" height="10" viewBox="0 0 6 10"><g fill="none" fill-rule="evenodd" transform="translate(-6 -3)"><mask id="a" fill="#fff"><path d="M7.138 3.529a.666.666 0 1 0-.942.942l3.528 3.53-3.529 3.528a.666.666 0 1 0 .943.943l4-4a.666.666 0 0 0 0-.943l-4-4z"/></mask><g fill="#1563FF" mask="url(#a)"><path d="M0 0h16v16H0z"/></g></g></svg></a>
<a class="learn-more" href='https://learn.hashicorp.com/consul/security-networking/datacenters'>Learn more<svg xmlns="http://www.w3.org/2000/svg" width="6" height="10" viewBox="0 0 6 10"><g fill="none" fill-rule="evenodd" transform="translate(-6 -3)"><mask id="a" fill="#fff"><path d="M7.138 3.529a.666.666 0 1 0-.942.942l3.528 3.53-3.529 3.528a.666.666 0 1 0 .943.943l4-4a.666.666 0 0 0 0-.943l-4-4z"/></mask><g fill="#1563FF" mask="url(#a)"><path d="M0 0h16v16H0z"/></g></g></svg></a>
</p>
</div>
</div>

10
website/source/docs/acl/acl-legacy.html.md
View File

@ -6,11 +6,11 @@ description: |-
Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them. It is very similar to AWS IAM in many ways.
---
-> **1.3.0 and earlier:** This document only applies in Consul versions 1.3.0 and before. If you are using version 1.4.0 or later please use the updated documentation [here](/docs/acl/acl-system.html)
# ACL System in Legacy Mode
-> **1.3.0 and earlier:** This guide only applies in Consul versions 1.3.0 and before. If you are using the 1.4.0 or later please use the updated guide [here](/docs/acl/acl-system.html)
~> **Alert: Deprecation Notice**
The ACL system described here was Consul's original ACL implementation. In Consul 1.4.0
the ACL system was rewritten and the legacy system was deprecated. The new ACL system information can be found [here](/docs/acl/acl-system.html).
@ -26,7 +26,7 @@ ACL system in Consul 1.3.0 and older.
# New ACL System Differences
The [ACL System documentation](/docs/acl/acl-system.html) and [legacy ACL
guide](/docs/acl/acl-legacy.html) describes the new and old systems in
documentation](/docs/acl/acl-legacy.html) describes the new and old systems in
detail. Below is a summary of the changes that need to be considered when
migrating legacy tokens to the new system.
@ -820,7 +820,7 @@ EOF
}
```
For more detailed documentation, see the [Consul Sentinel Guide](/docs/guides/sentinel.html).
For more detailed information, see the [Consul Sentinel documentation](/docs/agent/sentinel.html).
#### Keyring Rules

8
website/source/docs/acl/acl-rules.html.md
View File

@ -6,7 +6,7 @@ description: |-
Consul provides an optional Access Control List (ACL) system which can be used to control access to data and APIs. The ACL system is a Capability-based system that relies on tokens which can have fine grained rules applied to them. It is very similar to AWS IAM in many ways.
---
-> **1.4.0 and later:** This guide only applies in Consul versions 1.4.0 and later. The documentation for the legacy ACL system is [here](/docs/acl/acl-legacy.html)
-> **1.4.0 and later:** This document only applies in Consul versions 1.4.0 and later. The documentation for the legacy ACL system is [here](/docs/acl/acl-legacy.html)
# ACL Rules
@ -41,7 +41,7 @@ Policies can have several control levels:
* `read`: allow the resource to be read but not modified.
* `write`: allow the resource to be read and modified.
* `deny`: do not allow the resource to be read or modified.
* `list`: allows access to all the keys under a segment in the Consul KV. Note, this policy can only be used with the `key_prefix` resource and [`acl.enabled_key_list_policy`](https://www.consul.io/docs/guides/acl.html#list-policy-for-keys) must be set to true.
* `list`: allows access to all the keys under a segment in the Consul KV. Note, this policy can only be used with the `key_prefix` resource and [`acl.enable_key_list_policy`](/docs/agent/options.html#acl_enable_key_list) must be set to true.
When using prefix-based rules, the most specific prefix match determines the action. This
allows for flexible rules like an empty prefix to allow read-only access to all
@ -142,8 +142,8 @@ On success, the Policy is returned:
```
The created policy can now be specified either by name or by ID when
[creating a token](https://learn.hashicorp.com/consul/advanced/day-1-operations/acl-guide#step-4-create-an-agent-token). This will grant the rules
provided to the [bearer of that token](https://www.consul.io/api/index.html#authentication).
[creating a token](https://learn.hashicorp.com/consul/security-networking/production-acls#create-the-agent-token). This will grant the rules
provided to the [bearer of that token](/api/index.html#authentication).
Below is a breakdown of each rule type.

2
website/source/docs/agent/dns.html.md
View File

@ -255,7 +255,7 @@ are not truncated.
By default, all DNS results served by Consul set a 0 TTL value. This disables
caching of DNS results. However, there are many situations in which caching is
desirable for performance and scalability. This is discussed more in the guide
for [DNS Caching](/docs/guides/dns-cache.html).
for [DNS caching](https://learn.hashicorp.com/consul/security-networking/dns-caching).
## WAN Address Translation

8
website/source/docs/agent/encryption.html.md
View File

@ -11,7 +11,7 @@ description: |-
The Consul agent supports encrypting all of its network traffic. The exact
method of encryption is described on the [encryption internals page](/docs/internals/security.html).
There are two separate encryption systems, one for gossip traffic and one for RPC.
If you are configuring encryption, review this [guide](/docs/guides/agent-encryption.html).
If you are configuring encryption, review this [guide](https://learn.hashicorp.com/consul/security-networking/agent-encryption).
## Gossip Encryption
@ -57,7 +57,7 @@ order to send and receive cluster information.
## Configuring Gossip Encryption on an existing cluster
As of version 0.8.4, Consul supports upshifting to encrypted gossip on a running cluster
through the following process. Review this [step-by-step guide](/docs/guides/agent-encryption.html#enable-gossip-encryption-existing-cluster)
through the following process. Review this [step-by-step guide](https://learn.hashicorp.com/consul/security-networking/agent-encryption#enable-gossip-encryption-existing-cluster)
to encrypt gossip on an existing cluster.
## RPC Encryption with TLS
@ -66,7 +66,7 @@ Consul supports using TLS to verify the authenticity of servers and clients. To
Consul requires that all clients and servers have key pairs that are generated by a single
Certificate Authority. This can be a private CA, used only internally. The
CA then signs keys for each of the agents, as in
[this tutorial on generating both a CA and signing keys](/docs/guides/creating-certificates.html).
[this tutorial on generating both a CA and signing keys](https://learn.hashicorp.com/consul/security-networking/certificates).
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),
@ -103,5 +103,5 @@ and is secured using a symmetric key. See above for enabling gossip encryption.
As of version 0.8.4, Consul supports migrating to TLS-encrypted traffic on a running cluster
without downtime. This process assumes a starting point with no TLS settings configured, and involves
an intermediate step in order to get to full TLS encryption. Review this step-by-step
[guide](/docs/guides/agent-encryption.html#enable-tls-existing-cluster) to learn how.
[guide](https://learn.hashicorp.com/consul/security-networking/agent-encryption#enable-tls-existing-cluster) to learn how.

74
website/source/docs/agent/kv.html.md
View File

@ -8,38 +8,90 @@ description: |-
# Consul KV
Consul KV is a core feature of Consul and is installed with the Consul agent. Once installed with the agent, it will have sane defaults. Consul KV allows users to store indexed objects, though its main uses are storing configuration parameters and metadata. Please note that it is a simple KV store and is not intended to be a full featured datastore (such as DynamoDB) but has some similarities to one.
Consul KV is a core feature of Consul and is installed with the Consul agent.
Once installed with the agent, it will have sane defaults. Consul KV allows
users to store indexed objects, though its main uses are storing configuration
parameters and metadata. Please note that it is a simple KV store and is not
intended to be a full featured datastore (such as DynamoDB) but has some
similarities to one.
The Consul KV datastore is located on the servers, but can be accessed by any agent (client or server). The natively integrated [RPC functionality](/docs/internals/architecture.html) allows clients to forward requests to servers, including key/value reads and writes. Part of Consul’s core design allows data to be replicated automatically across all the servers. Having a quorum of servers will decrease the risk of data loss if an outage occurs.
The Consul KV datastore is located on the servers, but can be accessed by any
agent (client or server). The natively integrated [RPC
functionality](/docs/internals/architecture.html) allows clients to forward
requests to servers, including key/value reads and writes. Part of Consul’s
core design allows data to be replicated automatically across all the servers.
Having a quorum of servers will decrease the risk of data loss if an outage
occurs.
## Accessing the KV store
The KV store can be accessed by the [consul kv CLI subcommands](/docs/commands/kv.html), [HTTP API](/api/kv.html), and Consul UI. To restrict access, enable and configure [ACLs](https://learn.hashicorp.com/consul/advanced/day-1-operations/acl-guide). Once the ACL system has been bootstrapped, users and services, will need a valid token with KV [privileges](/docs/agent/acl-rules.html#key-value-rules) to access the the data store, this includes even reads. We recommend creating a token with limited privileges, for example, you could create a token with write privileges on one key for developers to update the value related to their application.
The KV store can be accessed by the [consul kv CLI
subcommands](/docs/commands/kv.html), [HTTP API](/api/kv.html), and Consul UI.
To restrict access, enable and configure
[ACLs](https://learn.hashicorp.com/consul/security-networking/production-acls).
Once the ACL system has been bootstrapped, users and services, will need a
valid token with KV [privileges](/docs/agent/acl-rules.html#key-value-rules) to
access the the data store, this includes even reads. We recommend creating a
token with limited privileges, for example, you could create a token with write
privileges on one key for developers to update the value related to their
application.
The datastore itself is located on the Consul servers in the [data directory](/docs/agent/options.html#_data_dir). To ensure data is not lost in the event of a complete outage, use the [`consul snapshot`](/docs/commands/snapshot/restore.html) feature to backup the data.
The datastore itself is located on the Consul servers in the [data
directory](/docs/agent/options.html#_data_dir). To ensure data is not lost in
the event of a complete outage, use the [`consul
snapshot`](/docs/commands/snapshot/restore.html) feature to backup the data.
## Using Consul KV
Objects are opaque to Consul, meaning there are no restrictions on the type of object stored in a key/value entry. The main restriction on an object is size - the maximum is 512 KB. Due to the maximum object size and main use cases, you should not need extra storage; the general [sizing recommendations](/docs/commands/snapshot/restore.html) are usually sufficient.
Objects are opaque to Consul, meaning there are no restrictions on the type of
object stored in a key/value entry. The main restriction on an object is size -
the maximum is 512 KB. Due to the maximum object size and main use cases, you
should not need extra storage; the general [sizing
recommendations](/docs/commands/snapshot/restore.html) are usually sufficient.
Keys, like objects are not restricted by type and can include any character. However, we recommend using URL-safe chars - `[a-zA-Z0-9-_]` with the exception of `/`, which can be used to help organize data. Note, `/` will be treated like any other character and is not fixed to the file system. Meaning, including `/` in a key does not fix it to a directory structure. This model is similar to Amazon S3 buckets. However, `/` is still useful for organizing data and when recursively searching within the data store. We also recommend that you avoid the use of `*`, `?`, `'`, and `%` because they can cause issues when using the API and in shell scripts.
Keys, like objects are not restricted by type and can include any character.
However, we recommend using URL-safe chars - `[a-zA-Z0-9-_]` with the
exception of `/`, which can be used to help organize data. Note, `/` will be
treated like any other character and is not fixed to the file system. Meaning,
including `/` in a key does not fix it to a directory structure. This model is
similar to Amazon S3 buckets. However, `/` is still useful for organizing data
and when recursively searching within the data store. We also recommend that
you avoid the use of `*`, `?`, `'`, and `%` because they can cause issues when
using the API and in shell scripts.
If you have not used Consul KV, check out this [Getting Started guide](https://learn.hashicorp.com/consul/getting-started/kv) on HashiCorp Learn.
If you have not used Consul KV, check out this [Getting Started
guide](https://learn.hashicorp.com/consul/getting-started/kv) on HashiCorp
Learn.
## Extending Consul KV
### Consul Template
If you plan to use Consul KV as part of your configuration management process review the [Consul Template](/docs/guides/consul-template.html) guide on how to update configuration based on value updates in the KV. Consul Template is based on Go Templates and allows for a series of scripted actions to be initiated on value changes to a Consul key.
If you plan to use Consul KV as part of your configuration management process
review the [Consul
Template](https://learn.hashicorp.com/consul/developer-configuration/consul-template)
guide on how to update configuration based on value updates in the KV. Consul
Template is based on Go Templates and allows for a series of scripted actions
to be initiated on value changes to a Consul key.
### Watches
Consul KV can also be extended with the use of watches. [Watches](/docs/agent/watches.html) are a way to monitor data for updates. When an update is detected, an external handler is invoked. To use watches with the KV store the [key](/docs/agent/watches.html#key) watch type should be used.
Consul KV can also be extended with the use of watches.
[Watches](/docs/agent/watches.html) are a way to monitor data for updates. When
an update is detected, an external handler is invoked. To use watches with the
KV store the [key](/docs/agent/watches.html#key) watch type should be used.
### Consul Sessions
Consul sessions can be used to build distributed locks with Consul KV. Sessions act as a binding layer between nodes, health checks, and key/value data. The KV API supports an `acquire` and `release` operation. The `acquire` operation acts like a Check-And-Set operation. On success, there is a key update and an increment to the `LockIndex` and the session value is updated to reflect the session holding the lock. Review the session documentation for more information on the [integration](/docs/internals/sessions.html#k-v-integration)
Consul sessions can be used to build distributed locks with Consul KV. Sessions
act as a binding layer between nodes, health checks, and key/value data. The KV
API supports an `acquire` and `release` operation. The `acquire` operation acts
like a Check-And-Set operation. On success, there is a key update and an
increment to the `LockIndex` and the session value is updated to reflect the
session holding the lock. Review the session documentation for more information
on the [integration](/docs/internals/sessions.html#k-v-integration)
### Vault
If you plan to use Consul KV as a backend for Vault, please review [this guide](https://learn.hashicorp.com/vault/operations/ops-vault-ha-consul).
If you plan to use Consul KV as a backend for Vault, please review [this
guide](https://learn.hashicorp.com/vault/operations/ops-vault-ha-consul).

37
website/source/docs/agent/options.html.md
View File

@ -420,7 +420,7 @@ will exit with an error at startup.
* <a name="_segment"></a><a href="#_segment">`-segment`</a> - (Enterprise-only) This flag is used to set
the name of the network segment the agent belongs to. An agent can only join and communicate with other agents
within its network segment. See the [Network Segments Guide](/docs/guides/network-segments.html) for more details.
within its network segment. See the [Network Segments Guide](https://learn.hashicorp.com/consul/day-2-operations/network-segments) for more details.
By default, this is an empty string, which is the default network segment.
* <a name="_serf_lan_port"></a><a href="#_serf_lan_port">`-serf-lan-port`</a> - the Serf LAN port to listen on.
@ -611,9 +611,7 @@ default will automatically work with some tooling.
<a href="#acl_tokens_default">`default`</a> will be used.
<br/><br/>
This token must at least have write access to the node name it will register as in order to set any
of the node-level information in the catalog such as metadata, or the node's tagged addresses. There
are other places this token is used, please see [ACL Agent Token](/docs/guides/acl.html#acl-agent-token)
for more details.
of the node-level information in the catalog such as metadata, or the node's tagged addresses.
* <a name="acl_tokens_agent_master"></a><a href="#acl_tokens_agent_master">`agent_master`</a> -
Used to access <a href="/api/agent.html">agent endpoints</a> that require agent read
@ -635,7 +633,7 @@ default will automatically work with some tooling.
This designates the datacenter which is authoritative for ACL information. It must be provided to enable ACLs. All servers and datacenters must agree on the ACL datacenter. Setting it on the servers is all you need for cluster-level enforcement, but for the APIs to forward properly from the clients,
it must be set on them too. In Consul 0.8 and later, this also enables agent-level enforcement
of ACLs. Please see the [ACL Guide](/docs/guides/acl.html) for more details.
of ACLs. Please see the [ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls) for more details.
* <a name="acl_default_policy_legacy"></a><a href="#acl_default_policy_legacy">`acl_default_policy`</a> - **Deprecated in Consul 1.4.0.
See the [`acl.default_policy`](#acl_default_policy) field instead.** Either
@ -662,8 +660,7 @@ default will automatically work with some tooling.
or write privileges, or node read privileges, even if Consul servers aren't present to validate
any tokens. This should only be used by operators during outages, regular ACL tokens should normally
be used by applications. This was added in Consul 0.7.2 and is only used when
<a href="#acl_enforce_version_8">`acl_enforce_version_8`</a> is set to true. Please see
[ACL Agent Master Token](/docs/guides/acl.html#acl-agent-master-token) for more details.
<a href="#acl_enforce_version_8">`acl_enforce_version_8`</a> is set to true.
* <a name="acl_agent_token_legacy"></a><a href="#acl_agent_token_legacy">`acl_agent_token`</a> -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.agent`](#acl_tokens_agent) field instead.**
@ -671,9 +668,7 @@ default will automatically work with some tooling.
<a href="#acl_token">`acl_token`</a> will be used. This was added in Consul 0.7.2.
This token must at least have write access to the node name it will register as in order to set any
of the node-level information in the catalog such as metadata, or the node's tagged addresses. There
are other places this token is used, please see [ACL Agent Token](/docs/guides/acl.html#acl-agent-token)
for more details.
of the node-level information in the catalog such as metadata, or the node's tagged addresses.
* <a name="acl_enforce_version_8"></a><a href="#acl_enforce_version_8">`acl_enforce_version_8`</a> -
**Deprecated in Consul 1.4.0**
@ -681,7 +676,7 @@ default will automatically work with some tooling.
previewed before Consul 0.8. Added in Consul 0.7.2, this defaults to false in versions of
Consul prior to 0.8, and defaults to true in Consul 0.8 and later. This helps ease the
transition to the new ACL features by allowing policies to be in place before enforcement begins.
Please see the [ACL Guide](/docs/guides/acl.html#version_8_acls) for more details.
* <a name="acl_master_token_legacy"></a><a href="#acl_master_token_legacy">`acl_master_token`</a> -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.master`](#acl_tokens_master) field instead.** Only used
@ -699,7 +694,8 @@ default will automatically work with some tooling.
* <a name="acl_replication_token_legacy"></a><a href="#acl_replication_token_legacy">`acl_replication_token`</a> -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.replication`](#acl_tokens_replication) field instead.**
Only used for servers outside the [`primary_datacenter`](#primary_datacenter) running Consul 0.7 or later.
When provided, this will enable [ACL replication](/docs/guides/acl.html#replication) using this
When provided, this will enable [ACL replication](https://learn.hashicorp.com/consul/day-2-operations/acl-replication) using this
ACL replication using this
token to retrieve and replicate the ACLs to the non-authoritative local datacenter. In Consul 0.9.1
and later you can enable ACL replication using [`enable_acl_replication`](#enable_acl_replication)
and then set the token later using the [agent token API](/api/agent.html#update-acl-tokens) on each
@ -708,8 +704,7 @@ default will automatically work with some tooling.
If there's a partition or other outage affecting the authoritative datacenter, and the
[`acl_down_policy`](/docs/agent/options.html#acl_down_policy) is set to "extend-cache", tokens not
in the cache can be resolved during the outage using the replicated set of ACLs. Please see the
[ACL Guide](/docs/guides/acl.html#replication) replication section for more details.
in the cache can be resolved during the outage using the replicated set of ACLs.
* <a name="acl_token_legacy"></a><a href="#acl_token_legacy">`acl_token`</a> -
**Deprecated in Consul 1.4.0. See the [`acl.tokens.default`](#acl_tokens_default) field instead.**
@ -765,7 +760,7 @@ default will automatically work with some tooling.
* <a name="autopilot"></a><a href="#autopilot">`autopilot`</a> Added in Consul 0.8, this object
allows a number of sub-keys to be set which can configure operator-friendly settings for Consul servers.
For more information about Autopilot, see the [Autopilot Guide](/docs/guides/autopilot.html).
For more information about Autopilot, see the [Autopilot Guide](https://learn.hashicorp.com/consul/day-2-operations/autopilot).
The following sub-keys are available:
@ -1015,7 +1010,7 @@ default will automatically work with some tooling.
* <a name="dns_config"></a><a href="#dns_config">`dns_config`</a> This object allows a number
of sub-keys to be set which can tune how DNS queries are serviced. See this guide on
[DNS caching](/docs/guides/dns-cache.html) for more detail.
[DNS caching](https://learn.hashicorp.com/consul/security-networking/dns-caching) for more detail.
The following sub-keys are available:
@ -1123,7 +1118,7 @@ default will automatically work with some tooling.
[`-domain` command-line flag](#_domain).
* <a name="enable_acl_replication"></a><a href="#enable_acl_replication">`enable_acl_replication`</a> When
set on a Consul server, enables [ACL replication](/docs/guides/acl.html#replication) without having to set
set on a Consul server, enables ACL replication without having to set
the replication token via [`acl_replication_token`](#acl_replication_token). Instead, enable ACL replication
and then introduce the token using the [agent token API](/api/agent.html#update-acl-tokens) on each server.
See [`acl_replication_token`](#acl_replication_token) for more details.
@ -1264,7 +1259,7 @@ default will automatically work with some tooling.
endpoints that begin with `/v1/acl`. This only works with API endpoints, not `/ui` or
`/debug`, those must be disabled with their respective configuration options. Any CLI
commands that use disabled endpoints will no longer function as well. For more general
access control, Consul's [ACL system](/docs/guides/acl.html) should be used, but this option
access control, Consul's [ACL system](https://learn.hashicorp.com/consul/security-networking/production-acls) should be used, but this option
is useful for removing access to HTTP API endpoints completely, or on specific agents. This
is available in Consul 0.9.0 and later.
@ -1339,7 +1334,7 @@ default will automatically work with some tooling.
* <a name="performance"></a><a href="#performance">`performance`</a> Available in Consul 0.7 and
later, this is a nested object that allows tuning the performance of different subsystems in
Consul. See the [Server Performance](/docs/install/performance.html) guide for more details. The
Consul. See the [Server Performance](/docs/install/performance.html) documentation for more details. The
following parameters are available:
* <a name="leave_drain_time"></a><a href="#leave_drain_time">`leave_drain_time`</a> - A duration
@ -1407,7 +1402,7 @@ default will automatically work with some tooling.
designates the datacenter which is authoritative for ACL information, intentions and is the root
Certificate Authority for Connect. It must be provided to enable ACLs. All servers and datacenters
must agree on the primary datacenter. Setting it on the servers is all you need for cluster-level enforcement, but for the APIs to forward properly from the clients, it must be set on them too. In
Consul 0.8 and later, this also enables agent-level enforcement of ACLs. Please see the [ACL Guide](/docs/guides/acl.html) for more details.
Consul 0.8 and later, this also enables agent-level enforcement of ACLs.
* <a name="raft_protocol"></a><a href="#raft_protocol">`raft_protocol`</a> Equivalent to the
[`-raft-protocol` command-line flag](#_raft_protocol).
@ -1469,7 +1464,7 @@ default will automatically work with some tooling.
* <a name="segments"></a><a href="#segments">`segments`</a> (Enterprise-only) This is a list of nested objects that allows setting
the bind/advertise information for network segments. This can only be set on servers. See the
[Network Segments Guide](/docs/guides/network-segments.html) for more details.
[Network Segments Guide](https://learn.hashicorp.com/consul/day-2-operations/network-segments) for more details.
* <a name="segment_name"></a><a href="#segment_name">`name`</a> - The name of the segment. Must be a string between
1 and 64 characters in length.
* <a name="segment_bind"></a><a href="#segment_bind">`bind`</a> - The bind address to use for the segment's gossip layer.

2
website/source/docs/commands/license.html.markdown.erb
View File

@ -17,7 +17,7 @@ The `license` command provides datacenter-level management of the Consul Enterpr
If ACLs are enabled then a token with operator privileges may be required in
order to use this command. Requests are forwarded internally to the leader
if required, so this can be run from any Consul node in a cluster. See the
[ACL Guide](/docs/guides/acl.html#operator) for more information.
[ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls) for more information.
```text

4
website/source/docs/commands/lock.html.markdown.erb
View File

@ -17,11 +17,11 @@ communication is disrupted, the child process is terminated.
The number of lock holders is configurable with the `-n` flag. By default,
a single holder is allowed, and a lock is used for mutual exclusion. This
uses the [leader election algorithm](/docs/guides/leader-election.html).
uses the [leader election algorithm](https://learn.hashicorp.com/consul/developer-configuration/elections).
If the lock holder count is more than one, then a semaphore is used instead.
A semaphore allows more than a single holder, but this is less efficient than
a simple lock. This follows the [semaphore algorithm](/docs/guides/semaphore.html).
a simple lock. This follows the [semaphore algorithm](https://learn.hashicorp.com/consul/developer-configuration/semaphore).
All locks using the same prefix must agree on the value of `-n`. If conflicting
values of `-n` are provided, an error will be returned.

4
website/source/docs/commands/operator.html.markdown.erb
View File

@ -19,9 +19,9 @@ as interacting with the Raft subsystem. This was added in Consul 0.7.
If ACLs are enabled then a token with operator privileges may be required in
order to use this command. Requests are forwarded internally to the leader
if required, so this can be run from any Consul node in a cluster. See the
[ACL Guide](/docs/guides/acl.html#operator) for more information.
[ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls for more information.
See the [Outage Recovery](/docs/guides/outage.html) guide for some examples of how
See the [Outage Recovery](https://learn.hashicorp.com/consul/day-2-operations/outage) guide for some examples of how
this command is used. For an API to perform these operations programmatically,
please see the documentation for the [Operator](/api/operator.html)
endpoint.

2
website/source/docs/commands/operator/area.html.markdown.erb
View File

@ -24,7 +24,7 @@ and relationships can be made between independent pairs of datacenters, so not a
need to be fully connected. This allows for complex topologies among Consul datacenters like
hub/spoke and more general trees.
See the [Network Areas Guide](/docs/guides/advanced-federation.html) for more details.
See the [Network Areas Guide](https://learn.hashicorp.com/consul/day-2-operations/advanced-federation) for more details.
```text
Usage: consul operator area <subcommand> [options]

2
website/source/docs/commands/operator/autopilot.html.markdown.erb
View File

@ -12,7 +12,7 @@ Command: `consul operator autopilot`
The Autopilot operator command is used to interact with Consul's Autopilot subsystem. The
command can be used to view or modify the current Autopilot configuration. See the
[Autopilot Guide](/docs/guides/autopilot.html) for more information about Autopilot.
[Autopilot Guide](https://learn.hashicorp.com/consul/day-2-operations/autopilot) for more information about Autopilot.
```text
Usage: consul operator autopilot <subcommand> [options]

2
website/source/docs/connect/configuration.html.md
View File

@ -42,7 +42,7 @@ dev mode with `consul agent -dev`.
~> **Security note:** Enabling Connect is enough to try the feature but doesn't
automatically ensure complete security. Please read the [Connect production
guide](/docs/guides/connect-production.html) to understand the additional steps
guide](https://learn.hashicorp.com/consul/developer-segmentation/connect-production) to understand the additional steps
needed for a secure deployment.
## Built-In Proxy Options

2
website/source/docs/connect/index.html.md
View File

@ -73,7 +73,7 @@ There are several ways to try Connect in different environments.
Getting Started guide provides a simple walk through of getting two services
to communicate via Connect using only Consul directly on your local machine.
* The [Envoy guide](/docs/guides/connect-envoy.html) walks through getting
* The [Envoy guide](https://learn.hashicorp.com/consul/developer-segmentation/connect-envoy) walks through getting
started with Envoy as a proxy, and uses Docker to run components locally
without installing anything else.

4
website/source/docs/connect/intentions.html.md
View File

@ -20,7 +20,7 @@ is allowed by testing the intentions. If authorize returns false the
connection must be terminated.
The default intention behavior is defined by the default
[ACL policy](/docs/guides/acl.html). If the default ACL policy is "allow all",
[ACL policy](https://learn.hashicorp.com/consul/security-networking/production-acls). If the default ACL policy is "allow all",
then all Connect connections are allowed by default. If the default ACL policy
is "deny all", then all Connect connections are denied by default.
@ -117,7 +117,7 @@ Consul supporting namespaces.
## Intention Management Permissions
Intention management can be protected by [ACLs](/docs/guides/acl.html).
Intention management can be protected by [ACLs](https://learn.hashicorp.com/consul/security-networking/production-acls).
Permissions for intentions are _destination-oriented_, meaning the ACLs
for managing intentions are looked up based on the destination value
of the intention, not the source.

2
website/source/docs/connect/proxies/envoy.md
View File

@ -47,7 +47,7 @@ compatible Envoy versions.
## Getting Started
To get started with Envoy and see a working example you can follow the [Using
Envoy with Connect](/docs/guides/connect-envoy.html) guide.
Envoy with Connect](https://learn.hashicorp.com/consul/developer-segmentation/connect-envoy) guide.
## Configuration

2
website/source/docs/connect/security.html.md
View File

@ -35,7 +35,7 @@ configuration also forces all service-to-service communication to be explicitly
whitelisted via an allow [intention](/docs/connect/intentions.html).
To learn how to enable ACLs, please see the
[guide on ACLs](/docs/guides/acl.html).
[guide on ACLs](https://learn.hashicorp.com/consul/security-networking/production-acls).
**If ACLs are enabled but are in default allow mode**, then services will be
able to communicate by default. Additionally, if a proper anonymous token

2
website/source/docs/enterprise/connect-multi-datacenter/index.html.md
View File

@ -14,7 +14,7 @@ and federation of Certificate Authority trust.
Sidecar proxy's [upstream configuration](/docs/connect/proxies.html#upstream-configuration-reference)
may specify an alternative datacenter or a prepared query that can address services
in multiple datacenters (such as the [geo failover](/docs/guides/geo-failover.html) pattern).
in multiple datacenters (such as the [geo failover](https://learn.hashicorp.com/consul/developer-discovery/geo-failover) pattern).
[Intentions](/docs/connect/intentions.html) verify connections between services by
source and destination name seamlessly across datacenters. Support for constraining Intentions

2
website/source/docs/enterprise/federation/index.html.md
View File

@ -17,7 +17,7 @@ desirable to have topologies like hub-and-spoke with central management
datacenters and "spoke" datacenters that can't interact with each other.
[Consul Enterprise](https://www.hashicorp.com/consul.html) offers a [network
area mechanism](/docs/guides/advanced-federation.html) that allows operators to
area mechanism](https://learn.hashicorp.com/consul/day-2-operations/advanced-federation) that allows operators to
federate Consul datacenters together on a pairwise basis, enabling
partially-connected network topologies. Once a link is created, Consul agents
can make queries to the remote datacenter in service of both API and DNS

6
website/source/docs/enterprise/network-segments/index.html.md
View File

@ -16,7 +16,7 @@ clusters that have multiple tenants that should not be able to communicate
with each other.
To get started with Network Segments,
[read the guide](/docs/guides/network-segments.html).
[read the guide](https://learn.hashicorp.com/consul/day-2-operations/network-segments).
# Consul Networking Models
@ -36,8 +36,8 @@ cluster each set per "datacenter". These Consul servers are federated together
over the WAN. Consul clients make use of resources in federated clusters by
forwarding RPCs through the Consul servers in their local cluster, but they
never interact with remote Consul servers directly. There are currently two
inter-cluster network models: [WAN Gossip (OSS)](/docs/guides/datacenters.html)
and [Network Areas (Enterprise)](/docs/guides/advanced-federation.html).
inter-cluster network models: [WAN Gossip (OSS)](https://learn.hashicorp.com/consul/security-networking/datacenters)
and [Network Areas (Enterprise)](https://learn.hashicorp.com/consul/day-2-operations/advanced-federation).
**LAN Gossip Pool**: A set of Consul agents that have full mesh connectivity
among themselves, and use Serf to maintain a shared view of the members of the

4
website/source/docs/enterprise/read-scale/index.html.md
View File

@ -11,6 +11,6 @@ description: |-
In [Consul Enterprise](https://www.hashicorp.com/consul.html), servers can be
explicitly marked as non-voters. Non-voters will receive the replication stream
but will not take part in quorum (required by the leader before log entries can
be committed). Adding explicit non-voters will [scale
reads](/docs/guides/autopilot.html#server-read-scaling)
be committed). Adding explicit non-voters will scale
reads
without impacting write latency.

2
website/source/docs/enterprise/redundancy/index.html.md
View File

@ -9,7 +9,7 @@ description: |-
# Consul Enterprise Redundancy Zones
[Consul Enterprise](https://www.hashicorp.com/consul.html) [redundancy
zones](/docs/guides/autopilot.html#redundancy-zones) make
zones](https://learn.hashicorp.com/consul/day-2-operations/autopilot#redundancy-zones) make
it possible to have more servers than availability zones. For example, in an
environment with three availability zones it's now possible to run one voter and
one non-voter in each availability zone, for a total of six servers. If an

4
website/source/docs/enterprise/sentinel/index.html.markdown.erb
View File

@ -12,7 +12,7 @@ and "deny" policies to support full conditional logic and integration with
external systems. [Learn more about Sentinel here.](https://docs.hashicorp.com/sentinel/concepts/).
To get started with Sentinel in Consul,
[read the documentation](https://docs.hashicorp.com/sentinel/app/consul/) or
[start the guide](/docs/guides/sentinel.html).
[read the general documentation](https://docs.hashicorp.com/sentinel/app/consul/) or
[Consul documentation](/docs/agent/sentinel.html).

2
website/source/docs/enterprise/upgrades/index.html.md
View File

@ -9,7 +9,7 @@ description: |-
# Consul Enterprise Automated Upgrades
[Consul Enterprise](https://www.hashicorp.com/consul.html) supports an [upgrade
pattern](/docs/guides/autopilot.html#upgrade-migrations)
pattern](https://learn.hashicorp.com/consul/day-2-operations/autopilot#upgrade-migrations)
that allows operators to deploy a complete cluster of new servers and then just wait
for the upgrade to complete. As the new servers join the cluster, server
introduction logic checks the version of each Consul server. If the version is

2
website/source/docs/faq.html.md
View File

@ -103,5 +103,5 @@ an RPC request to the remote Consul servers for that resource and return the res
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](/docs/guides/acl.html#outages-and-acl-replication) capability, or
[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).

2
website/source/docs/install/bootstrapping.html.md
View File

@ -23,7 +23,7 @@ as data loss is inevitable in a failure scenario. Please refer to the
[deployment table](/docs/internals/consensus.html#deployment-table) for more detail.
~> **Note**: In versions of Consul prior to 0.4, bootstrapping was a manual process. For details on using the `-bootstrap` flag directly, see the
[manual bootstrapping guide](/docs/install/manual-bootstrap.html).
[manual bootstrapping documentation](/docs/install/bootstrapping.html#manually-join-the-servers).
Manual bootstrapping with `-bootstrap` is not recommended in
newer versions of Consul (0.5 and newer) as it is more error-prone.
Instead you should use automatic bootstrapping

6
website/source/docs/install/performance.html.md
View File

@ -112,9 +112,9 @@ or add more powerful servers.
* For DNS-heavy workloads, configuring all Consul agents in a cluster with the
[`allow_stale`](/docs/agent/options.html#allow_stale) configuration option will allow reads to
scale across all Consul servers, not just the leader. Consul 0.7 and later enables stale reads
for DNS by default. See [Stale Reads](/docs/guides/dns-cache.html#stale) in the
[DNS Caching](/docs/guides/dns-cache.html) guide for more details. It's also good to set
reasonable, non-zero [DNS TTL values](/docs/guides/dns-cache.html#ttl) if your clients will
for DNS by default. See [Stale Reads](https://learn.hashicorp.com/consul/security-networking/dns-caching#stale-reads) in the
[DNS Caching](https://learn.hashicorp.com/consul/security-networking/dns-caching) guide for more details. It's also good to set
reasonable, non-zero [DNS TTL values](https://learn.hashicorp.com/consul/security-networking/dns-caching#ttl-values) if your clients will
respect them.
* In other applications that perform high volumes of reads against Consul, consider using the

4
website/source/docs/internals/acl.html.md
View File

@ -8,8 +8,8 @@ description: |-
# ACL System
This content has been moved into the [ACL Guide](/docs/guides/acl.html).
This content has been moved into the [ACL Guide](https://learn.hashicorp.com/consul/security-networking/production-acls).
<a name="version_8_acls"></a>
See [Complete ACL Coverage in Consul 0.8](/docs/guides/acl.html#complete-acl-coverage-in-consul-0-8)
See [Complete ACL Coverage in Consul 0.8](/docs/acl/acl-legacy.html)
for details about ACL changes in Consul 0.8 and later.

4
website/source/docs/internals/architecture.html.md
View File

@ -80,7 +80,7 @@ From a 10,000 foot altitude the architecture of Consul looks like this:
Let's break down this image and describe each piece. First of all, we can see
that there are two datacenters, labeled "one" and "two". Consul has first
class support for [multiple datacenters](/docs/guides/datacenters.html) and
class support for [multiple datacenters](https://learn.hashicorp.com/consul/security-networking/datacenters) and
expects this to be the common case.
Within each datacenter, we have a mixture of clients and servers. It is expected
@ -120,7 +120,7 @@ an RPC request to the remote Consul servers for that resource and return the res
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](/docs/guides/acl.html#outages-and-acl-replication) capability, or
[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).
In some places, client agents may cache data from the servers to make it

2
website/source/docs/internals/consensus.html.md
View File

@ -123,7 +123,7 @@ When getting started, a single Consul server is put into "bootstrap" mode. This
allows it to self-elect as a leader. Once a leader is elected, other servers can be
added to the peer set in a way that preserves consistency and safety. Eventually,
once the first few servers are added, bootstrap mode can be disabled. See [this
guide](/docs/guides/bootstrapping.html) for more details.
document](/docs/install/bootstrapping.html) for more details.
Since all servers participate as part of the peer set, they all know the current
leader. When an RPC request arrives at a non-leader server, the request is

2
website/source/docs/internals/coordinates.html.md
View File

@ -38,7 +38,7 @@ Network coordinates manifest in several ways inside Consul:
* [Prepared queries](/api/query.html) can automatically fail over services
to other Consul datacenters based on network round trip times. See the
[Geo Failover](/docs/guides/geo-failover.html) for some examples.
[Geo Failover](https://learn.hashicorp.com/consul/developer-discovery/geo-failover) for some examples.
* The [Coordinate endpoint](/api/coordinate.html) exposes raw network
coordinates for use in other applications.

2
website/source/docs/internals/sessions.html.md
View File

@ -144,7 +144,7 @@ the goal of Consul to protect against misbehaving clients.
The primitives provided by sessions and the locking mechanisms of the KV
store can be used to build client-side leader election algorithms.
These are covered in more detail in the [Leader Election guide](/docs/guides/leader-election.html).
These are covered in more detail in the [Leader Election guide](https://learn.hashicorp.com/consul/developer-configuration/elections).
## Prepared Query Integration

2
website/source/docs/platform/k8s/index.html.md
View File

@ -13,7 +13,7 @@ to Kubernetes using the Helm chart, sync services between Consul and
Kubernetes, automatically secure Pod communication with Connect, and more.
This section documents the official integrations between Consul and Kubernetes.
-> A step-by-step beginner tutorial and accompanying video can be found at the [Minikube with Consul guide](/docs/guides/minikube.html)
-> A step-by-step beginner tutorial and accompanying video can be found at the [Minikube with Consul guide](https://learn.hashicorp.com/consul/getting-started-k8s/minikube)
## Use Cases

2
website/source/docs/platform/k8s/run.html.md
View File

@ -262,7 +262,7 @@ We recommend running Consul on Kubernetes with the same
[general architecture](/docs/internals/architecture.html)
as running it anywhere else. There are some benefits Kubernetes can provide
that eases operating a Consul cluster and we document those below. The standard
[production deployment guide](/docs/guides/deployment.html) is still an
[production deployment guide](https://learn.hashicorp.com/consul/datacenter-deploy/deployment-guide) is still an
important read even if running Consul within Kubernetes.
Each section below will outline the different components of running Consul

290
website/source/docs/upgrade-specific.html.md
View File

@ -8,21 +8,24 @@ description: |-
# Upgrading Specific Versions
The [upgrading page](/docs/upgrading.html) covers the details of doing
a standard upgrade. However, specific versions of Consul may have more
details provided for their upgrades as a result of new features or changed
behavior. This page is used to document those details separately from the
standard upgrade flow.
The [upgrading page](/docs/upgrading.html) covers the details of doing a
standard upgrade. However, specific versions of Consul may have more details
provided for their upgrades as a result of new features or changed behavior.
This page is used to document those details separately from the standard
upgrade flow.
## Consul 1.4.0
There are two major features in Consul 1.4.0 that may impact upgrades: a [new ACL system](#acl-upgrade) and [multi-datacenter support for Connect](#connect-multi-datacenter) in the Enterprise version.
There are two major features in Consul 1.4.0 that may impact upgrades: a [new
ACL system](#acl-upgrade) and [multi-datacenter support for
Connect](#connect-multi-datacenter) in the Enterprise version.
### ACL Upgrade
Consul 1.4.0 includes a [new ACL system](/docs/guides/acl.html) that is
designed to have a smooth upgrade path but requires care to upgrade components
in the right order.
Consul 1.4.0 includes a [new ACL
system](https://learn.hashicorp.com/consul/security-networking/production-acls)
that is designed to have a smooth upgrade path but requires care to upgrade
components in the right order.
**Note:** As with most major version upgrades, you cannot downgrade once the
upgrade to 1.4.0 is complete as it adds new state to the raft store. As always
@ -104,21 +107,48 @@ This only applies to users upgrading from an older version of Consul Enterprise
In addition, this upgrade will only affect clusters where [Connect is enabled](/docs/connect/configuration.html) on your servers before the migration.
Connect multi-datacenter uses the same primary/secondary approach as ACLs and will use the same [primary_datacenter](#primary-datacenter). When a secondary datacenter server restarts with 1.4.0 it will detect it is not the primary and begin an automatic bootstrap of multi-datacenter CA federation.
Connect multi-datacenter uses the same primary/secondary approach as ACLs and
will use the same [primary_datacenter](#primary-datacenter). When a secondary
datacenter server restarts with 1.4.0 it will detect it is not the primary and
begin an automatic bootstrap of multi-datacenter CA federation.
Datacenters can be upgraded in either order; secondary datacenters will not switch into multi-datacenter mode until all servers in both the secondary and primary datacenter are detected to be running at least Consul 1.4.0. Secondary datacenters monitor this periodically (every few minutes) and will automatically upgrade Connect to use a federated Certificate Authority when they do.
Datacenters can be upgraded in either order; secondary datacenters will not
switch into multi-datacenter mode until all servers in both the secondary and
primary datacenter are detected to be running at least Consul 1.4.0. Secondary
datacenters monitor this periodically (every few minutes) and will
automatically upgrade Connect to use a federated Certificate Authority when
they do.
In general, migrating a Consul cluster from OSS to Enterprise will update the CA to be federated automatically and without impact on Connect traffic. When upgrading Consul Enterprise 1.3.x to Consul Enterprise 1.4.0 upgrades the CA upgrade is seamless, however depending on the size of the cluster, _new_ connection attempts in the secondary datacenter might fail for a short window (typically seconds) while the update is propagated due to the 1.3.x Beta authorization endpoint validating originating cluster in a way that was not fully forwards compatible with migrating between cluster trust domains. That issue is fixed in 1.4.0 as part of General Availability.
In general, migrating a Consul cluster from OSS to Enterprise will update the
CA to be federated automatically and without impact on Connect traffic. When
upgrading Consul Enterprise 1.3.x to Consul Enterprise 1.4.0 upgrades the CA
upgrade is seamless, however depending on the size of the cluster, _new_
connection attempts in the secondary datacenter might fail for a short window
(typically seconds) while the update is propagated due to the 1.3.x Beta
authorization endpoint validating originating cluster in a way that was not
fully forwards compatible with migrating between cluster trust domains. That
issue is fixed in 1.4.0 as part of General Availability.
Once migrated (typically a few seconds). Connect will use the primary datacenter's Certificate Authority as the root of trust for all other datacenters. CA migration or root key changes in the primary will now rotate automatically and without loss of connectivity throughout all datacenters and workloads.
Once migrated (typically a few seconds). Connect will use the primary
datacenter's Certificate Authority as the root of trust for all other
datacenters. CA migration or root key changes in the primary will now rotate
automatically and without loss of connectivity throughout all datacenters and
workloads.
For more information see [Connect Multi-datacenter](/docs/enterprise/connect-multi-datacenter/index.html).
For more information see [Connect
Multi-datacenter](/docs/enterprise/connect-multi-datacenter/index.html).
## Consul 1.3.0
This version added support for multiple tag filters in service discovery queries, however it introduced a subtle bug where API calls to `/catalog/service/:name?tag=<tag>` would ignore the tag filter _only during the upgrade_. It only occurs when clients are still running 1.2.3 or earlier but servers have been upgraded. The `/health/service/:name?tag=<tag>` endpoint and DNS interface were _not_ affected.
This version added support for multiple tag filters in service discovery
queries, however it introduced a subtle bug where API calls to
`/catalog/service/:name?tag=<tag>` would ignore the tag filter _only during the
upgrade_. It only occurs when clients are still running 1.2.3 or earlier but
servers have been upgraded. The `/health/service/:name?tag=<tag>` endpoint and
DNS interface were _not_ affected.
For this reason, we recommend you upgrade directly to 1.3.1 which includes only a fix for this issue.
For this reason, we recommend you upgrade directly to 1.3.1 which includes only
a fix for this issue.
## Consul 1.1.0
@ -133,6 +163,7 @@ The following previously deprecated fields and config options have been removed:
along with the `enable_deprecated_names` option from the metrics configuration.
#### New defaults for Raft Snapshot Creation
Consul 1.0.1 (and earlier versions of Consul) checked for raft snapshots every
5 seconds, and created new snapshots for every 8192 writes. These defaults cause
constant disk IO in large busy clusters. Consul 1.1.0 increases these to larger values,
@ -167,33 +198,81 @@ before proceeding.
#### Carefully Check and Remove Stale Servers During Rolling Upgrades
Consul 1.0 (and earlier versions of Consul when running with [Raft protocol 3](/docs/agent/options.html#_raft_protocol) had an issue where performing rolling updates of Consul servers could result in an outage from old servers remaining in the cluster. [Autopilot](/docs/guides/autopilot.html) would normally remove old servers when new ones come online, but it was also waiting to promote servers to voters in pairs to maintain an odd quorum size. The pairwise promotion feature was removed so that servers become voters as soon as they are stable, allowing Autopilot to remove old servers in a safer way.
Consul 1.0 (and earlier versions of Consul when running with [Raft protocol
3](/docs/agent/options.html#_raft_protocol) had an issue where performing
rolling updates of Consul servers could result in an outage from old servers
remaining in the cluster.
[Autopilot](https://learn.hashicorp.com/consul/day-2-operations/autopilot)
would normally remove old servers when new ones come online, but it was also
waiting to promote servers to voters in pairs to maintain an odd quorum size.
The pairwise promotion feature was removed so that servers become voters as
soon as they are stable, allowing Autopilot to remove old servers in a safer
way.
When upgrading from Consul 1.0, you may need to manually [force-leave](/docs/commands/force-leave.html) old servers as part of a rolling update to Consul 1.0.1.
When upgrading from Consul 1.0, you may need to manually
[force-leave](/docs/commands/force-leave.html) old servers as part of a rolling
update to Consul 1.0.1.
## Consul 1.0
Consul 1.0 has several important breaking changes that are documented here. Please be sure to read over all the details here before upgrading.
Consul 1.0 has several important breaking changes that are documented here.
Please be sure to read over all the details here before upgrading.
#### Raft Protocol Now Defaults to 3
The [`-raft-protocol`](/docs/agent/options.html#_raft_protocol) default has been changed from 2 to 3, enabling all [Autopilot](/docs/guides/autopilot.html) features by default.
The [`-raft-protocol`](/docs/agent/options.html#_raft_protocol) default has
been changed from 2 to 3, enabling all
[Autopilot](https://learn.hashicorp.com/consul/day-2-operations/autopilot)
features by default.
Raft protocol version 3 requires Consul running 0.8.0 or newer on all servers in order to work, so if you are upgrading with older servers in a cluster then you will need to set this back to 2 in order to upgrade. See [Raft Protocol Version Compatibility](/docs/upgrade-specific.html#raft-protocol-version-compatibility) for more details. Also the format of `peers.json` used for outage recovery is different when running with the latest Raft protocol. See [Manual Recovery Using peers.json](/docs/guides/outage.html#manual-recovery-using-peers-json) for a description of the required format.
Raft protocol version 3 requires Consul running 0.8.0 or newer on all servers
in order to work, so if you are upgrading with older servers in a cluster then
you will need to set this back to 2 in order to upgrade. See [Raft Protocol
Version
Compatibility](/docs/upgrade-specific.html#raft-protocol-version-compatibility)
for more details. Also the format of `peers.json` used for outage recovery is
different when running with the latest Raft protocol. See [Manual Recovery
Using
peers.json](https://learn.hashicorp.com/consul/day-2-operations/outage#manual-recovery-using-peers-json)
for a description of the required format.
Please note that the Raft protocol is different from Consul's internal protocol as described on the [Protocol Compatibility Promise](/docs/compatibility.html) page, and as is shown in commands like `consul members` and `consul version`. To see the version of the Raft protocol in use on each server, use the `consul operator raft list-peers` command.
Please note that the Raft protocol is different from Consul's internal protocol
as described on the [Protocol Compatibility Promise](/docs/compatibility.html)
page, and as is shown in commands like `consul members` and `consul version`.
To see the version of the Raft protocol in use on each server, use the `consul
operator raft list-peers` command.
The easiest way to upgrade servers is to have each server leave the cluster, upgrade its Consul version, and then add it back. Make sure the new server joins successfully and that the cluster is stable before rolling the upgrade forward to the next server. It's also possible to stand up a new set of servers, and then slowly stand down each of the older servers in a similar fashion.
The easiest way to upgrade servers is to have each server leave the cluster,
upgrade its Consul version, and then add it back. Make sure the new server
joins successfully and that the cluster is stable before rolling the upgrade
forward to the next server. It's also possible to stand up a new set of
servers, and then slowly stand down each of the older servers in a similar
fashion.
When using Raft protocol version 3, servers are identified by their [`-node-id`](/docs/agent/options.html#_node_id) instead of their IP address when Consul makes changes to its internal Raft quorum configuration. This means that once a cluster has been upgraded with servers all running Raft protocol version 3, it will no longer allow servers running any older Raft protocol versions to be added. If running a single Consul server, restarting it in-place will result in that server not being able to elect itself as a leader. To avoid this, either set the Raft protocol back to 2, or use [Manual Recovery Using peers.json](/docs/guides/outage.html#manual-recovery-using-peers-json) to map the server to its node ID in the Raft quorum configuration.
When using Raft protocol version 3, servers are identified by their
[`-node-id`](/docs/agent/options.html#_node_id) instead of their IP address
when Consul makes changes to its internal Raft quorum configuration. This means
that once a cluster has been upgraded with servers all running Raft protocol
version 3, it will no longer allow servers running any older Raft protocol
versions to be added. If running a single Consul server, restarting it in-place
will result in that server not being able to elect itself as a leader. To avoid
this, either set the Raft protocol back to 2, or use [Manual Recovery Using
peers.json](https://learn.hashicorp.com/consul/day-2-operations/outage#manual-recovery-using-peers-json)
to map the server to its node ID in the Raft quorum configuration.
#### Config Files Require an Extension
As part of supporting the [HCL](https://github.com/hashicorp/hcl#syntax) format for Consul's config files, an `.hcl` or `.json` extension is required for all config files loaded by Consul, even when using the [`-config-file`](/docs/agent/options.html#_config_file) argument to specify a file directly.
As part of supporting the [HCL](https://github.com/hashicorp/hcl#syntax) format
for Consul's config files, an `.hcl` or `.json` extension is required for all
config files loaded by Consul, even when using the
[`-config-file`](/docs/agent/options.html#_config_file) argument to specify a
file directly.
#### Deprecated Options Have Been Removed
All of Consul's previously deprecated command line flags and config options have been removed, so these will need to be mapped to their equivalents before upgrading. Here's the complete list of removed options and their equivalents:
All of Consul's previously deprecated command line flags and config options
have been removed, so these will need to be mapped to their equivalents before
upgrading. Here's the complete list of removed options and their equivalents:
| Removed Option | Equivalent |
| -------------- | ---------- |
@ -228,19 +307,35 @@ All of Consul's previously deprecated command line flags and config options have
#### `statsite_prefix` Renamed to `metrics_prefix`
Since the `statsite_prefix` configuration option applied to all telemetry providers, `statsite_prefix` was renamed to [`metrics_prefix`](/docs/agent/options.html#telemetry-metrics_prefix). Configuration files will need to be updated when upgrading to this version of Consul.
Since the `statsite_prefix` configuration option applied to all telemetry
providers, `statsite_prefix` was renamed to
[`metrics_prefix`](/docs/agent/options.html#telemetry-metrics_prefix).
Configuration files will need to be updated when upgrading to this version of
Consul.
#### `advertise_addrs` Removed
This configuration option was removed since it was redundant with `advertise_addr` and `advertise_addr_wan` in combination with `ports` and also wrongly stated that you could configure both host and port.
This configuration option was removed since it was redundant with
`advertise_addr` and `advertise_addr_wan` in combination with `ports` and also
wrongly stated that you could configure both host and port.
#### Escaping Behavior Changed for go-discover Configs
The format for [`-retry-join`](/docs/agent/options.html#retry-join) and [`-retry-join-wan`](/docs/agent/options.html#retry-join-wan) values that use [go-discover](https://github.com/hashicorp/go-discover) cloud auto joining has changed. Values in `key=val` sequences must no longer be URL encoded and can be provided as literals as long as they do not contain spaces, backslashes `\` or double quotes `"`. If values contain these characters then use double quotes as in `"some key"="some value"`. Special characters within a double quoted string can be escaped with a backslash `\`.
The format for [`-retry-join`](/docs/agent/options.html#retry-join) and
[`-retry-join-wan`](/docs/agent/options.html#retry-join-wan) values that use
[go-discover](https://github.com/hashicorp/go-discover) cloud auto joining has
changed. Values in `key=val` sequences must no longer be URL encoded and can be
provided as literals as long as they do not contain spaces, backslashes `\` or
double quotes `"`. If values contain these characters then use double quotes as
in `"some key"="some value"`. Special characters within a double quoted string
can be escaped with a backslash `\`.
#### HTTP Verbs are Enforced in Many HTTP APIs
Many endpoints in the HTTP API that previously took any HTTP verb now check for specific HTTP verbs and enforce them. This may break clients relying on the old behavior. Here's the complete list of updated endpoints and required HTTP verbs:
Many endpoints in the HTTP API that previously took any HTTP verb now check for
specific HTTP verbs and enforce them. This may break clients relying on the old
behavior. Here's the complete list of updated endpoints and required HTTP
verbs:
| Endpoint | Required HTTP Verb |
| -------- | ------------------ |
@ -287,23 +382,37 @@ Many endpoints in the HTTP API that previously took any HTTP verb now check for
#### Unauthorized KV Requests Return 403
When ACLs are enabled, reading a key with an unauthorized token returns a 403. This previously returned a 404 response.
When ACLs are enabled, reading a key with an unauthorized token returns a 403.
This previously returned a 404 response.
#### Config Section of Agent Self Endpoint has Changed
The /v1/agent/self endpoint's `Config` section has often been in flux as it was directly returning one of Consul's internal data structures. This configuration structure has been moved under `DebugConfig`, and is documents as for debugging use and subject to change, and a small set of elements of `Config` have been maintained and documented. See [Read Configuration](/api/agent.html#read-configuration) endpoint documentation for details.
The /v1/agent/self endpoint's `Config` section has often been in flux as it was
directly returning one of Consul's internal data structures. This configuration
structure has been moved under `DebugConfig`, and is documents as for debugging
use and subject to change, and a small set of elements of `Config` have been
maintained and documented. See [Read
Configuration](/api/agent.html#read-configuration) endpoint documentation for
details.
#### Deprecated `configtest` Command Removed
The `configtest` command was deprecated and has been superseded by the `validate` command.
The `configtest` command was deprecated and has been superseded by the
`validate` command.
#### Undocumented Flags in `validate` Command Removed
The `validate` command supported the `-config-file` and `-config-dir` command line flags but did not document them. This support has been removed since the flags are not required.
The `validate` command supported the `-config-file` and `-config-dir` command
line flags but did not document them. This support has been removed since the
flags are not required.
#### Metric Names Updated
Metric names no longer start with `consul.consul`. To help with transitioning dashboards and other metric consumers, the field `enable_deprecated_names` has been added to the telemetry section of the config, which will enable metrics with the old naming scheme to be sent alongside the new ones. The following prefixes were affected:
Metric names no longer start with `consul.consul`. To help with transitioning
dashboards and other metric consumers, the field `enable_deprecated_names` has
been added to the telemetry section of the config, which will enable metrics
with the old naming scheme to be sent alongside the new ones. The following
prefixes were affected:
| Prefix |
| ------ |
@ -323,35 +432,54 @@ Metric names no longer start with `consul.consul`. To help with transitioning da
#### Checks Validated On Agent Startup
Consul agents now validate health check definitions in their configuration and will fail at startup if any checks are invalid. In previous versions of Consul, invalid health checks would get skipped.
Consul agents now validate health check definitions in their configuration and
will fail at startup if any checks are invalid. In previous versions of Consul,
invalid health checks would get skipped.
## Consul 0.9.0
#### Script Checks Are Now Opt-In
A new [`enable_script_checks`](/docs/agent/options.html#_enable_script_checks) configuration option was added, and defaults to `false`, meaning that in order to allow an agent to run health checks that execute scripts, this will need to be configured and set to `true`. This provides a safer out-of-the-box configuration for Consul where operators must opt-in to allow script-based health checks.
A new [`enable_script_checks`](/docs/agent/options.html#_enable_script_checks)
configuration option was added, and defaults to `false`, meaning that in order
to allow an agent to run health checks that execute scripts, this will need to
be configured and set to `true`. This provides a safer out-of-the-box
configuration for Consul where operators must opt-in to allow script-based
health checks.
If your cluster uses script health checks please be sure to set this to `true` as part of upgrading agents. If this is set to `true`, you should also enable [ACLs](/docs/guides/acl.html) to provide control over which users are allowed to register health checks that could potentially execute scripts on the agent machines.
If your cluster uses script health checks please be sure to set this to `true`
as part of upgrading agents. If this is set to `true`, you should also enable
[ACLs](https://learn.hashicorp.com/consul/security-networking/production-acls)
to provide control over which users are allowed to register health checks that
could potentially execute scripts on the agent machines.
#### Web UI Is No Longer Released Separately
Consul releases will no longer include a `web_ui.zip` file with the compiled web assets. These have been built in to the Consul binary since the 0.7.x series and can be enabled with the [`-ui`](/docs/agent/options.html#_ui) configuration option. These built-in web assets have always been identical to the contents of the `web_ui.zip` file for each release. The [`-ui-dir`](/docs/agent/options.html#_ui_dir) option is still available for hosting customized versions of the web assets, but the vast majority of Consul users can just use the built in web assets.
Consul releases will no longer include a `web_ui.zip` file with the compiled
web assets. These have been built in to the Consul binary since the 0.7.x
series and can be enabled with the [`-ui`](/docs/agent/options.html#_ui)
configuration option. These built-in web assets have always been identical to
the contents of the `web_ui.zip` file for each release. The
[`-ui-dir`](/docs/agent/options.html#_ui_dir) option is still available for
hosting customized versions of the web assets, but the vast majority of Consul
users can just use the built in web assets.
## Consul 0.8.0
#### Upgrade Current Cluster Leader Last
We identified a potential issue with Consul 0.8 that requires the current cluster
leader to be upgraded last when updating multiple servers. Please see
We identified a potential issue with Consul 0.8 that requires the current
cluster leader to be upgraded last when updating multiple servers. Please see
[this issue](https://github.com/hashicorp/consul/issues/2889) for more details.
#### Command-Line Interface RPC Deprecation
The RPC client interface has been removed. All CLI commands that used RPC and the
`-rpc-addr` flag to communicate with Consul have been converted to use the HTTP API
and the appropriate flags for it, and the `rpc` field has been removed from the port
and address binding configs. You will need to remove these fields from your config files
and update any scripts that passed a custom `-rpc-addr` to the following commands:
The RPC client interface has been removed. All CLI commands that used RPC and
the `-rpc-addr` flag to communicate with Consul have been converted to use the
HTTP API and the appropriate flags for it, and the `rpc` field has been removed
from the port and address binding configs. You will need to remove these fields
from your config files and update any scripts that passed a custom `-rpc-addr`
to the following commands:
* `force-leave`
* `info`
@ -364,25 +492,35 @@ and update any scripts that passed a custom `-rpc-addr` to the following command
#### Version 8 ACLs Are Now Opt-Out
The [`acl_enforce_version_8`](/docs/agent/options.html#acl_enforce_version_8) configuration now defaults to `true` to enable [full version 8 ACL support](/docs/guides/acl.html#version_8_acls) by default. If you are upgrading an existing cluster with ACLs enabled, you will need to set this to `false` during the upgrade on **both Consul agents and Consul servers**. Version 8 ACLs were also changed so that [`acl_datacenter`](/docs/agent/options.html#acl_datacenter) must be set on agents in order to enable the agent-side enforcement of ACLs. This makes for a smoother experience in clusters where ACLs aren't enabled at all, but where the agents would have to wait to contact a Consul server before learning that.
The [`acl_enforce_version_8`](/docs/agent/options.html#acl_enforce_version_8)
configuration now defaults to `true` to enable full version 8 ACL support by
default. If you are upgrading an existing cluster with ACLs enabled, you will
need to set this to `false` during the upgrade on **both Consul agents and
Consul servers**. Version 8 ACLs were also changed so that
[`acl_datacenter`](/docs/agent/options.html#acl_datacenter) must be set on
agents in order to enable the agent-side enforcement of ACLs. This makes for a
smoother experience in clusters where ACLs aren't enabled at all, but where the
agents would have to wait to contact a Consul server before learning that.
#### Remote Exec Is Now Opt-In
The default for [`disable_remote_exec`](/docs/agent/options.html#disable_remote_exec) was
changed to "true", so now operators need to opt-in to having agents support running
commands remotely via [`consul exec`](/docs/commands/exec.html).
The default for
[`disable_remote_exec`](/docs/agent/options.html#disable_remote_exec) was
changed to "true", so now operators need to opt-in to having agents support
running commands remotely via [`consul exec`](/docs/commands/exec.html).
#### Raft Protocol Version Compatibility
When upgrading to Consul 0.8.0 from a version lower than 0.7.0, users will need to
set the [`-raft-protocol`](/docs/agent/options.html#_raft_protocol) option to 1 in
order to maintain backwards compatibility with the old servers during the upgrade.
After the servers have been migrated to version 0.8.0, `-raft-protocol` can be moved
up to 2 and the servers restarted to match the default.
When upgrading to Consul 0.8.0 from a version lower than 0.7.0, users will need
to set the [`-raft-protocol`](/docs/agent/options.html#_raft_protocol) option
to 1 in order to maintain backwards compatibility with the old servers during
the upgrade. After the servers have been migrated to version 0.8.0,
`-raft-protocol` can be moved up to 2 and the servers restarted to match the
default.
The Raft protocol must be stepped up in this way; only adjacent version numbers are
compatible (for example, version 1 cannot talk to version 3). Here is a table of the
Raft Protocol versions supported by each Consul version:
The Raft protocol must be stepped up in this way; only adjacent version numbers
are compatible (for example, version 1 cannot talk to version 3). Here is a
table of the Raft Protocol versions supported by each Consul version:
<table class="table table-bordered table-striped">
<tr>
@ -403,18 +541,30 @@ Raft Protocol versions supported by each Consul version:
</tr>
</table>
In order to enable all [Autopilot](/docs/guides/autopilot.html) features, all servers
in a Consul cluster must be running with Raft protocol version 3 or later.
In order to enable all
[Autopilot](https://learn.hashicorp.com/consul/day-2-operations/autopilot)
features, all servers in a Consul cluster must be running with Raft protocol
version 3 or later.
## Consul 0.7.1
#### Child Process Reaping
Child process reaping support has been removed, along with the `reap` configuration option. Reaping is also done via [dumb-init](https://github.com/Yelp/dumb-init) in the [Consul Docker image](https://github.com/hashicorp/docker-consul), so removing it from Consul itself simplifies the code and eases future maintenance for Consul. If you are running Consul as PID 1 in a container you will need to arrange for a wrapper process to reap child processes.
Child process reaping support has been removed, along with the `reap`
configuration option. Reaping is also done via
[dumb-init](https://github.com/Yelp/dumb-init) in the [Consul Docker
image](https://github.com/hashicorp/docker-consul), so removing it from Consul
itself simplifies the code and eases future maintenance for Consul. If you are
running Consul as PID 1 in a container you will need to arrange for a wrapper
process to reap child processes.
#### DNS Resiliency Defaults
The default for [`max_stale`](/docs/agent/options.html#max_stale) has been increased from 5 seconds to a near-indefinite threshold (10 years) to allow DNS queries to continue to be served in the event of a long outage with no leader. A new telemetry counter was added at `consul.dns.stale_queries` to track when agents serve DNS queries that are stale by more than 5 seconds.
The default for [`max_stale`](/docs/agent/options.html#max_stale) has been
increased from 5 seconds to a near-indefinite threshold (10 years) to allow DNS
queries to continue to be served in the event of a long outage with no leader.
A new telemetry counter was added at `consul.dns.stale_queries` to track when
agents serve DNS queries that are stale by more than 5 seconds.
## Consul 0.7
@ -423,10 +573,10 @@ to be aware of during an upgrade are categorized below.
#### Performance Timing Defaults and Tuning
Consul 0.7 now defaults the DNS configuration to allow for stale queries by defaulting
[`allow_stale`](/docs/agent/options.html#allow_stale) to true for better utilization
of available servers. If you want to retain the previous behavior, set the following
configuration:
Consul 0.7 now defaults the DNS configuration to allow for stale queries by
defaulting [`allow_stale`](/docs/agent/options.html#allow_stale) to true for
better utilization of available servers. If you want to retain the previous
behavior, set the following configuration:
```javascript
{
@ -442,8 +592,8 @@ the default Raft timing is set to a lower-performance mode suitable for
[minimal Consul servers](/docs/install/performance.html#minimum).
To continue to use the high-performance settings that were the default prior to
Consul 0.7 (recommended for production servers), add the following configuration
to all Consul servers when upgrading:
Consul 0.7 (recommended for production servers), add the following
configuration to all Consul servers when upgrading:
```javascript
{
@ -515,7 +665,7 @@ the file. Consul 0.7 also uses a new, automatically-created raft/peers.info file
to avoid ingesting the `peers.json` file on the first start after upgrading (the
`peers.json` file is simply deleted on the first start after upgrading).
Please be sure to review the [Outage Recovery Guide](/docs/guides/outage.html)
Please be sure to review the [Outage Recovery Guide](https://learn.hashicorp.com/consul/day-2-operations/outage)
before upgrading for more details.
## Consul 0.6.4
@ -528,7 +678,7 @@ require any ACL to manage them, and prepared queries with a `Name` defined are
now governed by a new `query` ACL policy that will need to be configured
after the upgrade.
See the [ACL Guide](/docs/guides/acl.html#prepared_query_acls) for more details
See the [ACL rules documentation](/docs/acl/acl-rules.html#prepared-query-rules) for more details
about the new behavior and how it compares to previous versions of Consul.
## Consul 0.6