status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: Avoid redirects by pointing links to new URLs 

Avoid HTTP redirects for internal site links by updating old URLs to
point to the new location for the target content.
This commit is contained in:
Blake Covarrubias 2022-01-10 15:36:16 -08:00
parent 19d5d58e5c
commit 59394e4aa2
118 changed files with 339 additions and 339 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/components/footer/index.jsx
View File

@ -8,7 +8,7 @@ export default function Footer({ openConsentManager }) {
<Link href="/intro">
<a>Intro</a>
</Link>
<Link href="/guides">
<Link href="/docs/guides">
<a>Guides</a>
</Link>
<Link href="/docs">

6
website/content/api-docs/acl/auth-methods.mdx
View File

@ -44,7 +44,7 @@ The corresponding CLI command is [`consul acl auth-method create`](/commands/acl
- `Type` `(string: <required>)` - The type of auth method being configured.
This field is immutable. For allowed values see the [auth method
documentation](/docs/acl/auth-methods).
documentation](/docs/security/acl/auth-methods).
- `Description` `(string: "")` - Free form human readable description of the
auth method.
@ -69,7 +69,7 @@ The corresponding CLI command is [`consul acl auth-method create`](/commands/acl
- `Config` `(map[string]string: <required>)` - The raw configuration to use for
the chosen auth method. Contents will vary depending upon the type chosen.
For more information on configuring specific auth method types, see the [auth
method documentation](/docs/acl/auth-methods).
method documentation](/docs/security/acl/auth-methods).
- `Namespace` `(string: "")` <EnterpriseAlert inline /> - Specifies the namespace to
create the auth method within. If not provided in the JSON body, the value of
@ -252,7 +252,7 @@ The corresponding CLI command is [`consul acl auth-method update`](/commands/acl
- `Config` `(map[string]string: <required>)` - The raw configuration to use for
the chosen auth method. Contents will vary depending upon the type chosen.
For more information on configuring specific auth method types, see the [auth
method documentation](/docs/acl/auth-methods).
method documentation](/docs/security/acl/auth-methods).
- `Namespace` `(string: "")` <EnterpriseAlert inline /> - Specifies the namespace of
the auth method to update. If not provided in the JSON body, the value of

10
website/content/api-docs/acl/index.mdx
View File

@ -276,7 +276,7 @@ agent_prefix "" {
## Login to Auth Method
This endpoint was added in Consul 1.5.0 and is used to exchange an [auth
method](/docs/acl/auth-methods) bearer token for a newly-created
method](/docs/security/acl/auth-methods) bearer token for a newly-created
Consul ACL token.
| Method | Path | Produces |
@ -407,7 +407,7 @@ $ curl \
</EnterpriseAlert>
This endpoint was added in Consul 1.8.0 and is used to obtain an authorization
URL from Consul to start an [OIDC login flow](/docs/acl/auth-methods/oidc).
URL from Consul to start an [OIDC login flow](/docs/security/acl/auth-methods/oidc).
| Method | Path | Produces |
| ------ | -------------------- | ------------------ |
@ -433,10 +433,10 @@ replication enabled.
### Parameters
- `AuthMethod` `(string: <required>)` - The name of the auth method to use for
login. This must be of type [`oidc`](/docs/acl/auth-methods/oidc).
login. This must be of type [`oidc`](/docs/security/acl/auth-methods/oidc).
- `RedirectURI` `(string: <required>)` - See [Redirect
URIs](/docs/acl/auth-methods/oidc#redirect-uris) for more information.
URIs](/docs/security/acl/auth-methods/oidc#redirect-uris) for more information.
- `ClientNonce` `(string: "")` - Optional client-provided nonce that must match
during callback, if present.
@ -513,7 +513,7 @@ replication enabled.
### Parameters
- `AuthMethod` `(string: <required>)` - The name of the auth method to use for
login. This must be of type [`oidc`](/docs/acl/auth-methods/oidc).
login. This must be of type [`oidc`](/docs/security/acl/auth-methods/oidc).
- `State` `(string: <required>)` - Opaque state ID that is part of the
Authorization URL and will be included in the the redirect following

4
website/content/api-docs/acl/legacy.mdx
View File

@ -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 detailed in the [ACL Rule documentation](/docs/acl/acl-rules).
`Rules` property is detailed in the [ACL Rule documentation](/docs/security/acl/acl-rules).
### Sample Payload
@ -296,4 +296,4 @@ $ curl \
## Check ACL Replication
The check ACL replication endpoint has not changed between the legacy system and the new system. Review the [latest documentation](/api/acl/acl#check-acl-replication) to learn more about this endpoint.
The check ACL replication endpoint has not changed between the legacy system and the new system. Review the [latest documentation](/api-docs/acl#check-acl-replication) to learn more about this endpoint.

4
website/content/api-docs/acl/policies.mdx
View File

@ -44,7 +44,7 @@ The corresponding CLI command is [`consul acl policy create`](/commands/acl/poli
- `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 detailed in the [ACL Rules documentation](/docs/acl/acl-rules).
`Rules` property is detailed in the [ACL Rules documentation](/docs/security/acl/acl-rules).
- `Datacenters` `(array<string>)` - Specifies the datacenters the policy is valid within.
When no datacenters are provided the policy is valid in all datacenters including
@ -227,7 +227,7 @@ The corresponding CLI command is [`consul acl policy update`](/commands/acl/poli
- `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 detailed in the [ACL Rules documentation](/docs/acl/acl-rules).
`Rules` property is detailed in the [ACL Rules documentation](/docs/security/acl/acl-rules).
- `Datacenters` `(array<string>)` - Specifies the datacenters this policy is valid within.
When no datacenters are provided the policy is valid in all datacenters including

8
website/content/api-docs/acl/roles.mdx
View File

@ -50,7 +50,7 @@ The corresponding CLI command is [`consul acl role create`](/commands/acl/role/c
breaking tokens.
- `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
identities](/docs/acl/acl-system#acl-service-identities) that should be
identities](/docs/security/acl/acl-system#acl-service-identities) that should be
applied to the role. Added in Consul 1.5.0.
- `ServiceName` `(string: <required>)` - The name of the service. The name
@ -64,7 +64,7 @@ The corresponding CLI command is [`consul acl role create`](/commands/acl/role/c
but may in the future.
- `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
identities](/docs/acl/acl-system#acl-node-identities) that should be
identities](/docs/security/acl/acl-system#acl-node-identities) that should be
applied to the role. Added in Consul 1.8.1.
- `NodeName` `(string: <required>)` - The name of the node. The name
@ -339,11 +339,11 @@ The corresponding CLI command is [`consul acl role update`](/commands/acl/role/u
breaking tokens.
- `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
identities](/docs/acl/acl-system#acl-service-identities) that should be
identities](/docs/security/acl/acl-system#acl-service-identities) that should be
applied to the role. Added in Consul 1.5.0.
- `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
identities](/docs/acl/acl-system#acl-node-identities) that should be
identities](/docs/security/acl/acl-system#acl-node-identities) that should be
applied to the role. Added in Consul 1.8.1.
- `Namespace` `(string: "")` <EnterpriseAlert inline /> - Specifies the namespace of

8
website/content/api-docs/acl/tokens.mdx
View File

@ -62,7 +62,7 @@ The corresponding CLI command is [`consul acl token create`](/commands/acl/token
enables role renaming without breaking tokens. Added in Consul 1.5.0.
- `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
identities](/docs/acl/acl-system#acl-service-identities) that should be
identities](/docs/security/acl/acl-system#acl-service-identities) that should be
applied to the token. Added in Consul 1.5.0.
- `ServiceName` `(string: <required>)` - The name of the service. The name
@ -76,7 +76,7 @@ The corresponding CLI command is [`consul acl token create`](/commands/acl/token
but may in the future.
- `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
identities](/docs/acl/acl-system#acl-node-identities) that should be
identities](/docs/security/acl/acl-system#acl-node-identities) that should be
applied to the token. Added in Consul 1.8.1.
- `NodeName` `(string: <required>)` - The name of the node. The name
@ -329,7 +329,7 @@ The corresponding CLI command is [`consul acl token update`](/commands/acl/token
enables role renaming without breaking tokens.
- `ServiceIdentities` `(array<ServiceIdentity>)` - The list of [service
identities](/docs/acl/acl-system#acl-service-identities) that should be
identities](/docs/security/acl/acl-system#acl-service-identities) that should be
applied to the token. Added in Consul 1.5.0.
- `ServiceName` `(string: <required>)` - The name of the service. The name
@ -343,7 +343,7 @@ The corresponding CLI command is [`consul acl token update`](/commands/acl/token
but may in the future.
- `NodeIdentities` `(array<NodeIdentity>)` - The list of [node
identities](/docs/acl/acl-system#acl-node-identities) that should be
identities](/docs/security/acl/acl-system#acl-node-identities) that should be
applied to the token. Added in Consul 1.8.1.
- `NodeName` `(string: <required>)` - The name of the node. The name

2
website/content/api-docs/agent/check.mdx
View File

@ -18,7 +18,7 @@ using the HTTP API.
It is important to note that the checks known by the agent may be different from
those reported by the catalog. This is usually due to changes being made while
there is no leader elected. The agent performs active
[anti-entropy](/docs/internals/anti-entropy), so in most situations
[anti-entropy](/docs/architecture/anti-entropy), so in most situations
everything will be in sync within a few seconds.
| Method | Path | Produces |

2
website/content/api-docs/agent/index.mdx
View File

@ -12,7 +12,7 @@ The `/agent` endpoints are used to interact with the local Consul agent.
Usually, services and checks are registered with an agent which then takes on
the burden of keeping that data synchronized with the cluster. For example, the
agent registers services and checks with the Catalog and performs
[anti-entropy](/docs/internals/anti-entropy) to recover from outages.
[anti-entropy](/docs/architecture/anti-entropy) to recover from outages.
In addition to these endpoints, additional endpoints are grouped in the
navigation for `Checks` and `Services`.

22
website/content/api-docs/agent/service.mdx
View File

@ -20,7 +20,7 @@ or added dynamically using the HTTP API.
It is important to note that the services known by the agent may be different
from those reported by the catalog. This is usually due to changes being made
while there is no leader elected. The agent performs active
[anti-entropy](/docs/internals/anti-entropy), so in most situations
[anti-entropy](/docs/architecture/anti-entropy), so in most situations
everything will be in sync within a few seconds.
| Method | Path | Produces |
@ -137,7 +137,7 @@ configuration that was registered with the instance.
It is important to note that the services known by the agent may be different
from those reported by the catalog. This is usually due to changes being made
while there is no leader elected. The agent performs active
[anti-entropy](/docs/internals/anti-entropy), so in most situations
[anti-entropy](/docs/architecture/anti-entropy), so in most situations
everything will be in sync within a few seconds.
| Method | Path | Produces |
@ -231,7 +231,7 @@ $ curl \
```
The response has the same structure as the [service
definition](/docs/agent/services) with one extra field `ContentHash` which
definition](/docs/discovery/services) with one extra field `ContentHash` which
contains the [hash-based blocking
query](/api/features/blocking#hash-based-blocking-queries) hash for the result. The
same hash is also present in `X-Consul-ContentHash`.
@ -601,13 +601,13 @@ The corresponding CLI command is [`consul services register`](/commands/services
### Parameters
Note that this endpoint, unlike most also [supports `snake_case`](/docs/agent/services#service-definition-parameter-case)
Note that this endpoint, unlike most also [supports `snake_case`](/docs/discovery/services#service-definition-parameter-case)
service definition keys for compatibility with the config file format.
- `Name` `(string: <required>)` - Specifies the logical name of the service.
Many service instances may share the same logical service name. We recommend using
[valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns).
for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns).
- `ID` `(string: "")` - Specifies a unique ID for this service. This must be
unique per _agent_. This defaults to the `Name` parameter if not provided.
@ -615,7 +615,7 @@ service definition keys for compatibility with the config file format.
- `Tags` `(array<string>: nil)` - Specifies a list of tags to assign to the
service. These tags can be used for later filtering and are exposed via the APIs.
We recommend using [valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns)
for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns)
- `Address` `(string: "")` - Specifies the address of the service. If not
provided, the agent's address is used as the address for the service during
@ -639,9 +639,9 @@ service definition keys for compatibility with the config file format.
- `Kind` `(string: "")` - The kind of service. Defaults to "" which is a
typical Consul service. This value may also be "connect-proxy" for
[Connect](/docs/connect) proxies representing another service,
"mesh-gateway" for instances of a [mesh gateway](/docs/connect/mesh-gateway),
"terminating-gateway" for instances of a [terminating gateway](/docs/connect/terminating-gateway),
or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/ingress-gateway).
"mesh-gateway" for instances of a [mesh gateway](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters),
"terminating-gateway" for instances of a [terminating gateway](/docs/connect/gateways/terminating-gateway),
or "ingress-gateway" for instances of a [ingress gateway](/docs/connect/gateways/ingress-gateway).
- `Proxy` `(Proxy: nil)` - From 1.2.3 on, specifies the configuration for a
Connect service proxy instance. This is only valid if `Kind` defines a proxy or gateway.
@ -681,7 +681,7 @@ service definition keys for compatibility with the config file format.
modifications would be lost.
- `Weights` `(Weights: nil)` - Specifies weights for the service. Please see the
[service documentation](/docs/agent/services) for more information about
[service documentation](/docs/discovery/services) for more information about
weights. If this field is not provided weights will default to
`{"Passing": 1, "Warning": 1}`.
@ -691,7 +691,7 @@ service definition keys for compatibility with the config file format.
are independent of one another. Updating the tags for the service registered
on one node is independent of the same service (by name) registered on
another node. If `EnableTagOverride` is not specified the default value is
`false`. See [anti-entropy syncs](/docs/internals/anti-entropy) for
`false`. See [anti-entropy syncs](/docs/architecture/anti-entropy) for
more info.
#### Connect Structure

8
website/content/api-docs/catalog.mdx
View File

@ -17,7 +17,7 @@ API methods look similar.
This endpoint is a low-level mechanism for registering or updating
entries in the catalog. It is usually preferable to instead use the
[agent endpoints](/api/agent) for registration as they are simpler and
perform [anti-entropy](/docs/internals/anti-entropy).
perform [anti-entropy](/docs/architecture/anti-entropy).
| Method | Path | Produces |
| ------ | ------------------- | ------------------ |
@ -54,7 +54,7 @@ The table below shows this endpoint's support for
provided, it will be defaulted to the value of the `Service.Service` property.
Only one service with a given `ID` may be present per node. We recommend using
[valid DNS labels](https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames)
for service definition names for [compatibility with external DNS](/docs/agent/services#service-and-tag-names-with-dns).
for service definition names for [compatibility with external DNS](/docs/discovery/services#service-and-tag-names-with-dns).
The service `Tags`, `Address`, `Meta`, and `Port` fields are all optional. For more
information about these fields and the implications of setting them,
see the [Service - Agent API](/api/agent/service) page
@ -74,7 +74,7 @@ The table below shows this endpoint's support for
check. The `Status` must be one of `passing`, `warning`, or `critical`.
The `Definition` field can be provided with details for a TCP or HTTP health
check. For more information, see the [Health Checks](/docs/agent/checks) page.
check. For more information, see the [Health Checks](/docs/discovery/checks) page.
Multiple checks can be provided by replacing `Check` with `Checks` and
sending an array of `Check` objects.
@ -168,7 +168,7 @@ $ curl \
This endpoint is a low-level mechanism for directly removing
entries from the Catalog. It is usually preferable to instead use the
[agent endpoints](/api/agent) for deregistration as they are simpler and
perform [anti-entropy](/docs/internals/anti-entropy).
perform [anti-entropy](/docs/architecture/anti-entropy).
| Method | Path | Produces |
| ------ | --------------------- | ------------------ |

2
website/content/api-docs/coordinate.mdx
View File

@ -13,7 +13,7 @@ The `/coordinate` endpoints query for the network coordinates for nodes in the
local datacenter as well as Consul servers in the local datacenter and remote
datacenters.
Please see the [Network Coordinates](/docs/internals/coordinates) internals
Please see the [Network Coordinates](/docs/architecture/coordinates) internals
guide for more information on how these coordinates are computed, and for
details on how to perform calculations with them.

8
website/content/api-docs/discovery-chain.mdx
View File

@ -13,13 +13,13 @@ description: The /discovery-chain endpoints are for interacting with the discove
high-level proxy integration APIs may obviate the need for this API over time.
The `/discovery-chain` endpoint returns the compiled [discovery
chain](/docs/internals/discovery-chain) for a service.
chain](/docs/connect/l7-traffic/discovery-chain) for a service.
This will fetch all related [configuration
entries](/docs/agent/config-entries) and render them into a form suitable
for use by a [connect proxy](/docs/connect/proxies) implementation. This
is a key component of [L7 Traffic
Management](/docs/connect/l7-traffic-management).
Management](/docs/connect/l7-traffic).
## Read Compiled Discovery Chain
@ -95,7 +95,7 @@ The table below shows this endpoint's support for
parameter.
- `OverrideMeshGateway` `(MeshGatewayConfig: <optional>)` - Overrides the final
[mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
for this any service resolved in the compiled chain.
This value comes from either the [proxy
@ -111,7 +111,7 @@ The table below shows this endpoint's support for
### Sample Compilations
Full documentation for the output fields is found on the [discovery chain
internals](/docs/internals/discovery-chain#compileddiscoverychain)
internals](/docs/connect/l7-traffic/discovery-chain#compileddiscoverychain)
page.
#### Multi-Datacenter Failover

4
website/content/api-docs/event.mdx
View File

@ -90,7 +90,7 @@ $ curl \
This endpoint returns the most recent events (up to 256) known by the agent. As a
consequence of how the [event command](/commands/event) works, each
agent may have a different view of the events. Events are broadcast using the
[gossip protocol](/docs/internals/gossip), so they have no global ordering
[gossip protocol](/docs/architecture/gossip), so they have no global ordering
nor do they make a promise of delivery.
| Method | Path | Produces |
@ -150,7 +150,7 @@ $ curl \
The semantics of this endpoint's blocking queries are slightly different. Most
blocking queries provide a monotonic index and block until a newer index is
available. This can be supported as a consequence of the total ordering of the
[consensus protocol](/docs/internals/consensus). With gossip, there is no
[consensus protocol](/docs/architecture/consensus). With gossip, there is no
ordering, and instead `X-Consul-Index` maps to the newest event that matches the
query.

2
website/content/api-docs/health.mdx
View File

@ -421,7 +421,7 @@ Parameters and response format are the same as
-> **1.8.0+:** This API is available in Consul versions 1.8.0 and later.
This endpoint returns the service instances providing an [ingress
gateway](/docs/connect/ingress-gateway) for a service in a given datacenter.
gateway](/docs/connect/gateways/ingress-gateway) for a service in a given datacenter.
| Method | Path | Produces |
| ------ | -------------------------- | ------------------ |

2
website/content/api-docs/index.mdx
View File

@ -40,7 +40,7 @@ Previously this was provided via a `?token=` query parameter. This functionality
exists on many endpoints for backwards compatibility, but its use is **highly
discouraged**, since it can show up in access logs as part of the URL.
To learn more about the ACL system read the [documentation](/docs/acl/acl-system).
To learn more about the ACL system read the [documentation](/docs/security/acl/acl-system).
## Version Prefix

2
website/content/api-docs/operator/area.mdx
View File

@ -425,4 +425,4 @@ $ curl \
- `RTT` is an estimated network round trip time from the server answering the
query to the given server, in nanoseconds. This is computed using [network
coordinates](/docs/internals/coordinates).
coordinates](/docs/architecture/coordinates).

2
website/content/api-docs/operator/index.mdx
View File

@ -14,7 +14,7 @@ operations manually, please check the documentation for the
[`consul operator`](/commands/operator) command.
If ACLs are enabled then a token with operator privileges may be required in
order to use this interface. Check the [ACL Rules documentation](/docs/acl/acl-rules#operator-rules)
order to use this interface. Check the [ACL Rules documentation](/docs/security/acl/acl-rules#operator-rules)
for more information.
Check the [Outage Recovery](https://learn.hashicorp.com/tutorials/consul/recovery-outage) tutorial for some examples of

2
website/content/api-docs/operator/keyring.mdx
View File

@ -9,7 +9,7 @@ description: |-
# Keyring Operator HTTP API
The `/operator/keyring` endpoints allow for management of the gossip encryption
keyring. Please see the [Gossip Protocol Guide](/docs/internals/gossip) for
keyring. Please see the [Gossip Protocol Guide](/docs/architecture/gossip) for
more details on the gossip protocol and its use.
## List Gossip Encryption Keys

2
website/content/api-docs/operator/raft.mdx
View File

@ -11,7 +11,7 @@ description: |-
The `/operator/raft` endpoints provide tools for management of Raft the
consensus subsystem and cluster quorum.
Please see the [Consensus Protocol Guide](/docs/internals/consensus) for
Please see the [Consensus Protocol Guide](/docs/architecture/consensus) for
more information about Raft consensus protocol and its use.
## Read Configuration

6
website/content/api-docs/query.mdx
View File

@ -17,7 +17,7 @@ would be possible given the limited entry points exposed by DNS.
Check the [Geo Failover tutorial](https://learn.hashicorp.com/tutorials/consul/automate-geo-failover) for details and
examples for using prepared queries to implement geo failover for services.
Check the [prepared query rules](/docs/agent/acl-rules#prepared-query-rules)
Check the [prepared query rules](/docs/security/acl/acl-rules#prepared-query-rules)
section of the agent ACL documentation for more details about how prepared
queries work with Consul's ACL system.
@ -187,7 +187,7 @@ The table below shows this endpoint's support for
- `NearestN` `(int: 0)` - Specifies that the query will be forwarded to up
to `NearestN` other datacenters based on their estimated network round
trip time using [Network Coordinates](/docs/internals/coordinates)
trip time using [Network Coordinates](/docs/architecture/coordinates)
from the WAN gossip pool. The median round trip time from the server
handling the query to the servers in the remote datacenter is used to
determine the priority.
@ -214,7 +214,7 @@ The table below shows this endpoint's support for
true, only nodes with checks in the passing state will be returned.
- `Near` `(string: "")` - Specifies a node to sort near based on distance
sorting using [Network Coordinates](/docs/internals/coordinates). The
sorting using [Network Coordinates](/docs/architecture/coordinates). The
nearest instance to the specified node will be returned first, and subsequent
nodes in the response will be sorted in ascending order of estimated
round-trip times. If the node given does not exist, the nodes in the response

2
website/content/api-docs/snapshot.mdx
View File

@ -10,7 +10,7 @@ description: |-
The `/snapshot` endpoints save and restore the state of the Consul
servers for disaster recovery. Snapshots include all state managed by Consul's
Raft [consensus protocol](/docs/internals/consensus).
Raft [consensus protocol](/docs/architecture/consensus).
## Generate Snapshot

2
website/content/commands/acl/index.mdx
View File

@ -12,7 +12,7 @@ line. It exposes top-level commands for bootstrapping the ACL system,
managing tokens and policies, translating legacy rules, and setting the
tokens for use by an agent.
ACLs are also accessible via the [HTTP API](/api/acl/acl).
ACLs are also accessible via the [HTTP API](/api-docs/acl).
Bootstrap Consul's ACLs:

2
website/content/commands/agent.mdx
View File

@ -14,6 +14,6 @@ performs the important task of maintaining membership information,
running checks, announcing services, handling queries, etc.
Due to the power and flexibility of this command, the Consul agent
is documented in its own section. See the [Consul Agent](/docs/agent/basics)
is documented in its own section. See the [Consul Agent](/docs/agent)
section for more information on how to use this command and the
options it has.

2
website/content/commands/connect/expose.mdx
View File

@ -14,7 +14,7 @@ Command: `consul connect expose`
The connect expose subcommand is used to expose a Connect-enabled service
through an Ingress gateway by modifying the gateway's configuration and adding
an intention to allow traffic from the gateway to the service. See the
[Ingress gateway documentation](/docs/connect/ingress-gateway) for more information
[Ingress gateway documentation](/docs/connect/gateways/ingress-gateway) for more information
about Ingress gateways.
```text

6
website/content/commands/event.mdx
View File

@ -19,14 +19,14 @@ The `event` command provides a mechanism to fire a custom user event to an
entire datacenter. These events are opaque to Consul, but they can be used
to build scripting infrastructure to do automated deploys, restart services,
or perform any other orchestration action. Events can be handled by
[using a watch](/docs/agent/watches).
[using a watch](/docs/dynamic-app-config/watches).
Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip).
Under the hood, events are propagated using the [gossip protocol](/docs/architecture/gossip).
While the details are not important for using events, an understanding of
the semantics is useful. The gossip layer will make a best-effort to deliver
the event, but there is **no guaranteed delivery**. Unlike most Consul data, which is
replicated using [consensus](/docs/internals/consensus), event data
replicated using [consensus](/docs/architecture/consensus), event data
is purely peer-to-peer over gossip. This means it is not persisted and does
not have a total ordering. In practice, this means you cannot rely on the
order of message delivery. An advantage however is that events can still

2
website/content/commands/exec.mdx
View File

@ -17,7 +17,7 @@ the `web` service.
Remote execution works by specifying a job, which is stored in the KV store.
Agents are informed about the new job using the [event system](/commands/event),
which propagates messages via the [gossip protocol](/docs/internals/gossip).
which propagates messages via the [gossip protocol](/docs/architecture/gossip).
As a result, delivery is best-effort, and there is **no guarantee** of execution.
While events are purely gossip driven, remote execution relies on the KV store

2
website/content/commands/index.mdx
View File

@ -239,7 +239,7 @@ CONSUL_GRPC_ADDR=unix://var/run/consul_grpc.sock
```
If the agent is [configured with TLS
certificates](/docs/agent/encryption#rpc-encryption-with-tls), then the
certificates](/docs/security/encryption#rpc-encryption-with-tls), then the
gRPC listener will require TLS and present the same certificate as the https
listener. As with `CONSUL_HTTP_ADDR`, if TLS is enabled either the `https://`
scheme should be used, or `CONSUL_HTTP_SSL` set.

6
website/content/commands/info.mdx
View File

@ -19,9 +19,9 @@ There are currently the top-level keys for:
- agent: Provides information about the agent
- consul: Information about the consul library (client or server)
- raft: Provides info about the Raft [consensus library](/docs/internals/consensus)
- serf_lan: Provides info about the LAN [gossip pool](/docs/internals/gossip)
- serf_wan: Provides info about the WAN [gossip pool](/docs/internals/gossip)
- raft: Provides info about the Raft [consensus library](/docs/architecture/consensus)
- serf_lan: Provides info about the LAN [gossip pool](/docs/architecture/gossip)
- serf_wan: Provides info about the WAN [gossip pool](/docs/architecture/gossip)
Here is an example output:

2
website/content/commands/keygen.mdx
View File

@ -12,6 +12,6 @@ description: >-
Command: `consul keygen`
The `keygen` command generates an encryption key that can be used for
[Consul agent traffic encryption](/docs/agent/encryption).
[Consul agent traffic encryption](/docs/security/encryption).
The keygen command uses a cryptographically
strong pseudo-random number generator to generate the key.

2
website/content/commands/keyring.mdx
View File

@ -10,7 +10,7 @@ Command: `consul keyring`
Corresponding HTTP API Endpoints: [\[VARIES\] /v1/operator/keyring](/api-docs/operator/keyring)
The `keyring` command is used to examine and modify the encryption keys used in
Consul's [Gossip Pools](/docs/internals/gossip). It is capable of
Consul's [Gossip Pools](/docs/architecture/gossip). It is capable of
distributing new encryption keys to the cluster, retiring old encryption keys,
and changing the keys used by the cluster to encrypt messages.

2
website/content/commands/operator/area.mdx
View File

@ -269,7 +269,7 @@ spoken by the node.
`RTT` is an estimated network round trip time from the server answering the query
to the given server, in a human-readable format. This is computed using
[network coordinates](/docs/internals/coordinates).
[network coordinates](/docs/architecture/coordinates).
The return code will indicate success or failure.

2
website/content/commands/rtt.mdx
View File

@ -14,7 +14,7 @@ Corresponding HTTP API Endpoints: [\[GET\] /v1/coordinate/datacenters](/api-docs
The `rtt` command estimates the network round trip time between two nodes using
Consul's network coordinate model of the cluster.
See the [Network Coordinates](/docs/internals/coordinates) internals guide
See the [Network Coordinates](/docs/architecture/coordinates) internals guide
for more information on how these coordinates are computed.
The table below shows this command's [required ACLs](/api#authentication). Configuration of

2
website/content/commands/services/deregister.mdx
View File

@ -17,7 +17,7 @@ be paired with `services register`.
This is just one method for service deregistration. If the service was
registered with a configuration file, then deleting that file and
[reloading](/commands/reload) Consul is the correct method to
deregister. See [Service Definition](/docs/agent/services) for more
deregister. See [Service Definition](/docs/discovery/services) for more
information about registering services generally.
The table below shows this command's [required ACLs](/api#authentication). Configuration of

2
website/content/commands/services/index.mdx
View File

@ -8,7 +8,7 @@ page_title: 'Commands: Services'
Command: `consul services`
The `services` command has subcommands for interacting with Consul services
registered with the [local agent](/docs/agent/basics). These provide
registered with the [local agent](/docs/agent). These provide
useful commands such as `register` and `deregister` for easily registering
services in scripts, dev mode, etc.
To view all services in the catalog, instead of only agent-local services,

4
website/content/commands/services/register.mdx
View File

@ -15,7 +15,7 @@ service deregistration. This command simplifies service registration from
scripts, in dev mode, etc.
This is just one method of service registration. Services can also be
registered by placing a [service definition](/docs/agent/services)
registered by placing a [service definition](/docs/discovery/services)
in the Consul agent configuration directory and issuing a
[reload](/commands/reload). This approach is easiest for
configuration management systems that other systems that have access to
@ -74,7 +74,7 @@ arguments are given, the flags below can be used to register a single
service.
Note that the behavior of each of the fields below is exactly the same
as when constructing a standard [service definition](/docs/agent/services).
as when constructing a standard [service definition](/docs/discovery/services).
Please refer to that documentation for full details.
- `-id` - The ID of the service. This will default to `-name` if not set.

4
website/content/commands/watch.mdx
View File

@ -19,7 +19,7 @@ a process with the latest values of the view. If no process is specified,
the current values are dumped to STDOUT which can be a useful way to inspect
data in Consul.
There is more [documentation on watches here](/docs/agent/watches).
There is more [documentation on watches here](/docs/dynamic-app-config/watches).
## Usage
@ -28,7 +28,7 @@ Usage: `consul watch [options] [child...]`
The only required option is `-type` which specifies the particular
data view. Depending on the type, various options may be required
or optionally provided. There is more documentation on watch
[specifications here](/docs/agent/watches).
[specifications here](/docs/dynamic-app-config/watches).
#### API Options

4
website/content/docs/agent/index.mdx
View File

@ -17,7 +17,7 @@ Agents run in either client or server mode. Client nodes are lightweight process
They interface with the server nodes for most operations and maintain very little state of their own.
Clients run on every node where services are running.
In addition to the core agent operations, server nodes participate in the [consensus quorum](/docs/internals/consensus).
In addition to the core agent operations, server nodes participate in the [consensus quorum](/docs/architecture/consensus).
The quorum is based on the Raft protocol, which provides strong consistency and availability in the case of failure.
Server nodes should run on dedicated instances because they are more resource intensive than client nodes.
@ -46,7 +46,7 @@ As a result, agent crashes are handled in the same manner is network failures.
Once a node is marked as failed, this information is updated in the service
catalog.
-> **Note:** Updating the catalog is only possible if the servers can still [form a quorum](/docs/internals/consensus).
-> **Note:** Updating the catalog is only possible if the servers can still [form a quorum](/docs/architecture/consensus).
Once the network recovers or a crashed agent restarts, the cluster will repair itself and unmark a node as failed.
The health check in the catalog will also be updated to reflect the current state.

18
website/content/docs/agent/options.mdx
View File

@ -49,7 +49,7 @@ Environment variables **cannot** be used to configure the Consul client. They
_can_ be used when running other `consul` CLI commands that connect with a
running agent, e.g. `CONSUL_HTTP_ADDR=192.168.0.1:8500 consul members`.
See [Consul Commands](/docs/commands#environment-variables) for more
See [Consul Commands](/commands#environment-variables) for more
information.
## Command-line Options ((#commandline_options))
@ -260,7 +260,7 @@ The options below are all specified on the command-line.
PTR query responses will always use `-domain`, since the desired domain cannot be included in the query.
- `-enable-script-checks` ((#\_enable_script_checks)) This controls whether
[health checks that execute scripts](/docs/agent/checks) are enabled on this
[health checks that execute scripts](/docs/discovery/checks) are enabled on this
agent, and defaults to `false` so operators must opt-in to allowing these. This
was added in Consul 0.9.0.
@ -414,7 +414,7 @@ The options below are all specified on the command-line.
As of Consul 0.9.1, `retry-join` accepts a unified interface using the
[go-discover](https://github.com/hashicorp/go-discover) library for doing
automatic cluster joining using cloud metadata. For more information, see
the [Cloud Auto-join page](/docs/agent/cloud-auto-join).
the [Cloud Auto-join page](/docs/install/cloud-auto-join).
<CodeBlockConfig heading="Using Cloud Auto-Joining">
@ -506,7 +506,7 @@ The options below are all specified on the command-line.
- `-raft-protocol` ((#\_raft_protocol)) - This controls the internal version
of the Raft consensus protocol used for server communications. This must be set
to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/docs/upgrade-specific#raft-protocol-version-compatibility) for more details.
to 3 in order to gain access to Autopilot features, with the exception of [`cleanup_dead_servers`](#cleanup_dead_servers). Defaults to 3 in Consul 1.0.0 and later (defaulted to 2 previously). See [Raft Protocol Version Compatibility](/docs/upgrading/upgrade-specific#raft-protocol-version-compatibility) for more details.
- `-recursor` ((#\_recursor)) - Specifies the address of an upstream DNS
server. This option may be provided multiple times, and is functionally equivalent
@ -710,7 +710,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
secondary Consul datacenters will perform replication of only ACL policies and
roles. Setting this configuration will will enable ACL token replication and
allow for the creation of both [local tokens](/api/acl/tokens#local) and
[auth methods](/docs/acl/auth-methods) in connected secondary datacenters.
[auth methods](/docs/security/acl/auth-methods) in connected secondary datacenters.
~> **Warning:** When enabling ACL token replication on the secondary datacenter,
global tokens already present in the secondary datacenter will be lost. For
@ -1102,7 +1102,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'."
- `static` This object controls configuring the static authorizer setup in the Consul
configuration file. Almost all sub-keys are identical to those provided by the [JWT
Auth Method](/docs/acl/auth-methods/jwt).
Auth Method](/docs/security/acl/auth-methods/jwt).
- `jwt_validation_pub_keys` (Defaults to `[]`) A list of PEM-encoded public keys
to use to authenticate signatures locally.
@ -1634,13 +1634,13 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
- `encrypt_verify_incoming` - This is an optional
parameter that can be used to disable enforcing encryption for incoming gossip
in order to upshift from unencrypted to encrypted gossip on a running cluster.
See [this section](/docs/agent/encryption#configuring-gossip-encryption-on-an-existing-cluster)
See [this section](/docs/security/encryption#configuring-gossip-encryption-on-an-existing-cluster)
for more information. Defaults to true.
- `encrypt_verify_outgoing` - This is an optional
parameter that can be used to disable enforcing encryption for outgoing gossip
in order to upshift from unencrypted to encrypted gossip on a running cluster.
See [this section](/docs/agent/encryption#configuring-gossip-encryption-on-an-existing-cluster)
See [this section](/docs/security/encryption#configuring-gossip-encryption-on-an-existing-cluster)
for more information. Defaults to true.
- `disable_keyring_file` - Equivalent to the
@ -2423,7 +2423,7 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
- `watches` - Watches is a list of watch specifications which
allow an external process to be automatically invoked when a particular data view
is updated. See the [watch documentation](/docs/agent/watches) for more detail.
is updated. See the [watch documentation](/docs/dynamic-app-config/watches) for more detail.
Watches can be modified when the configuration is reloaded.
## TLS Configuration Reference

2
website/content/docs/agent/sentinel.mdx
View File

@ -19,7 +19,7 @@ policies to support full conditional logic and integration with external systems
Sentinel policies are applied during writes to the KV Store.
An optional `sentinel` field specifying code and enforcement level can be added to [ACL policy definitions](/docs/agent/acl-rules#sentinel-integration) for Consul KV. The following policy ensures that the value written during a KV update must end with "dc1".
An optional `sentinel` field specifying code and enforcement level can be added to [ACL policy definitions](/docs/security/acl/acl-rules#sentinel-integration) for Consul KV. The following policy ensures that the value written during a KV update must end with "dc1".
<CodeBlockConfig heading="Ensure values written during KV updates end in 'dc1'">

8
website/content/docs/architecture/anti-entropy.mdx
View File

@ -26,7 +26,7 @@ health checks and updating their local state.
Services and checks within the context of an agent have a rich set of
configuration options available. This is because the agent is responsible for
generating information about its services and their health through the use of
[health checks](/docs/agent/checks).
[health checks](/docs/discovery/checks).
#### Catalog
@ -43,7 +43,7 @@ responsible for recording and returning information _about_ services, nodes, and
health.
The catalog is maintained only by server nodes. This is because the catalog is
replicated via the [Raft log](/docs/internals/consensus) to provide a
replicated via the [Raft log](/docs/architecture/consensus) to provide a
consolidated and consistent view of the cluster.
### Anti-Entropy
@ -118,7 +118,7 @@ database and its monitoring service Redis Sentinel have this kind of
relationship. Redis instances are responsible for much of their
configuration, but Sentinels determine whether the Redis instance is a
primary or a secondary. Using the Consul service configuration item
[enable_tag_override](/docs/agent/services) you can instruct the
[enable_tag_override](/docs/discovery/services) you can instruct the
Consul agent on which the Redis database is running to NOT update the
tags during anti-entropy synchronization. For more information see
[Services](/docs/agent/services#enable-tag-override-and-anti-entropy) page.
[Services](/docs/discovery/services#enable-tag-override-and-anti-entropy) page.

10
website/content/docs/architecture/index.mdx
View File

@ -14,7 +14,7 @@ users and developers of Consul form a mental model of how it works, this
page documents the system architecture.
-> Before describing the architecture, we recommend reading the
[glossary](/docs/glossary) of terms to help
[glossary](/docs/install/glossary) of terms to help
clarify what is being discussed.
The architecture concepts in this document can be used with the [Reference Architecture guide](https://learn.hashicorp.com/tutorials/consul/reference-architecture?utm_source=consul.io&utm_medium=docs) when deploying Consul in production.
@ -36,7 +36,7 @@ availability in the case of failure and performance, as consensus gets progressi
slower as more machines are added. However, there is no limit to the number of clients,
and they can easily scale into the thousands or tens of thousands.
All the agents that are in a datacenter participate in a [gossip protocol](/docs/internals/gossip).
All the agents that are in a datacenter participate in a [gossip protocol](/docs/architecture/gossip).
This means there is a gossip pool that contains all the agents for a given datacenter. This serves
a few purposes: first, there is no need to configure clients with the addresses of servers;
discovery is done automatically. Second, the work of detecting agent failures
@ -47,7 +47,7 @@ when important events such as leader election take place.
The servers in each datacenter are all part of a single Raft peer set. This means that
they work together to elect a single leader, a selected server which has extra duties. The leader
is responsible for processing all queries and transactions. Transactions must also be replicated to
all peers as part of the [consensus protocol](/docs/internals/consensus). Because of this
all peers as part of the [consensus protocol](/docs/architecture/consensus). Because of this
requirement, when a non-leader server receives an RPC request, it forwards it to the cluster leader.
The server agents also operate as part of a WAN gossip pool. This pool is different from the LAN pool
@ -82,8 +82,8 @@ disrupted or the servers are temporarily unavailable.
## Getting in depth
At this point we've covered the high level architecture of Consul, but there are many
more details for each of the subsystems. The [consensus protocol](/docs/internals/consensus) is
documented in detail as is the [gossip protocol](/docs/internals/gossip). The [documentation](/docs/internals/security)
more details for each of the subsystems. The [consensus protocol](/docs/architecture/consensus) is
documented in detail as is the [gossip protocol](/docs/architecture/gossip). The [documentation](/docs/security)
for the security model and protocols used are also available.
For other details, either consult the code, ask in IRC, or reach out to the mailing list.

2
website/content/docs/connect/config-entries/ingress-gateway.mdx
View File

@ -1038,7 +1038,7 @@ You can specify the following parameters to configure ingress gateway configurat
type: 'string: ""',
description: `The name of the service that should be exposed
through this listener. This can be either a service registered in the
catalog, or a service defined only by [other config entries](/docs/connect/l7-traffic-management). If the wildcard specifier,
catalog, or a service defined only by [other config entries](/docs/connect/l7-traffic). If the wildcard specifier,
\`*\`, is provided, then ALL services will be exposed through the listener.
This is not supported for listeners with protocol \`tcp\`.`,
},

2
website/content/docs/connect/config-entries/proxy-defaults.mdx
View File

@ -285,7 +285,7 @@ spec:
name: 'MeshGateway',
type: 'MeshGatewayConfig: <optional>',
description: `Controls the default
[mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
for all proxies. Added in v1.6.0.`,
children: [
{

22
website/content/docs/connect/config-entries/service-defaults.mdx
View File

@ -359,7 +359,7 @@ spec:
[\`service-defaults\`](/docs/connect/config-entries/service-defaults)
config entry for the upstream destination service. Configuring it in a
proxy upstream config will not fully enable some
[L7 features](/docs/connect/l7-traffic-management).
[L7 features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
`,
},
@ -374,7 +374,7 @@ spec:
[\`service-resolver\`](/docs/connect/config-entries/service-resolver)
config entry for the upstream destination service.
Configuring it in a proxy upstream config will not fully enable some
[L7 features](/docs/connect/l7-traffic-management).
[L7 features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
`,
yaml: `The number of milliseconds to allow when making upstream connections before timing out.<br><br>
@ -384,7 +384,7 @@ spec:
[\`ServiceResolver\`](/docs/connect/config-entries/service-resolver)
CRD for the upstream destination service.
Configuring it in a proxy upstream config will not fully enable some
[L7 features](/docs/connect/l7-traffic-management).
[L7 features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
`,
},
@ -393,8 +393,8 @@ spec:
name: 'MeshGateway',
type: 'MeshGatewayConfig: <optional>',
description: `Controls the default
[mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
for this upstream.`,
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
for this upstream.`,
children: [
{
name: 'Mode',
@ -480,7 +480,7 @@ spec:
[\`service-defaults\`](/docs/connect/config-entries/service-defaults)
config entry for the upstream destination service. Configuring it in a
proxy upstream config will not fully enable some
[L7 features](/docs/connect/l7-traffic-management).
[L7 features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
`,
yaml: `The protocol for the upstream listener.<br><br>
@ -490,7 +490,7 @@ spec:
[\`ServiceDefaults\`](/docs/connect/config-entries/service-defaults)
CRD for the upstream destination service. Configuring it in a
proxy upstream config will not fully enable some
[L7 features](/docs/connect/l7-traffic-management).
[L7 features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
`,
},
@ -506,7 +506,7 @@ spec:
[\`service-resolver\`](/docs/connect/config-entries/service-resolver)
config entry for the upstream destination service.
Configuring it in a proxy upstream config will not fully enable some
[L7 features](/docs/connect/l7-traffic-management).
[L7 features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
`,
yaml: `The number of milliseconds to allow when making upstream connections before timing out.<br><br>
@ -516,7 +516,7 @@ spec:
[\`ServiceResolver\`](/docs/connect/config-entries/service-resolver)
CRD for the upstream destination service.
Configuring it in a proxy upstream config will not fully enable some
[L7 features](/docs/connect/l7-traffic-management).
[L7 features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
`,
},
@ -525,7 +525,7 @@ spec:
name: 'MeshGateway',
type: 'MeshGatewayConfig: <optional>',
description: `Controls the default
[mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
for this upstream.`,
children: [
{
@ -629,7 +629,7 @@ spec:
name: 'MeshGateway',
type: 'MeshGatewayConfig: <optional>',
description: `Controls the default
[mesh gateway configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
[mesh gateway configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
for this service. Added in v1.6.0.`,
children: [
{

2
website/content/docs/connect/config-entries/service-resolver.mdx
View File

@ -21,7 +21,7 @@ and discovery terminates.
## Interaction with other Config Entries
- Service resolver config entries are a component of [L7 Traffic
Management](/docs/connect/l7-traffic-management).
Management](/docs/connect/l7-traffic).
## UI

2
website/content/docs/connect/config-entries/service-router.mdx
View File

@ -21,7 +21,7 @@ service of the same name.
## Interaction with other Config Entries
- Service router config entries are a component of [L7 Traffic
Management](/docs/connect/l7-traffic-management).
Management](/docs/connect/l7-traffic).
- Service router config entries are restricted to only services that define
their protocol as HTTP-based via a corresponding

2
website/content/docs/connect/config-entries/service-splitter.mdx
View File

@ -25,7 +25,7 @@ resolution stage.
## Interaction with other Config Entries
- Service splitter config entries are a component of [L7 Traffic
Management](/docs/connect/l7-traffic-management).
Management](/docs/connect/l7-traffic).
- Service splitter config entries are restricted to only services that define
their protocol as http-based via a corresponding

2
website/content/docs/connect/config-entries/terminating-gateway.mdx
View File

@ -20,7 +20,7 @@ and will apply to all instances of the gateway with that name.
across all federated Consul datacenters. If terminating gateways in different Consul datacenters need to route to different
sets of services within their datacenter then the terminating gateways **must** be registered with different names.
See [Terminating Gateway](/docs/connect/terminating-gateway) for more information.
See [Terminating Gateway](/docs/connect/gateways/terminating-gateway) for more information.
## TLS Origination

4
website/content/docs/connect/configuration.mdx
View File

@ -76,7 +76,7 @@ You can override centralized configurations for individual proxy instances in
their
[sidecar service definitions](/docs/connect/registration/sidecar-service),
and the default protocols for service instances in their [service
registrations](/docs/agent/services).
registrations](/docs/discovery/services).
## Schedulers
@ -92,7 +92,7 @@ Connect can be used with Nomad to provide secure service-to-service
communication between Nomad jobs and task groups. The ability to use the dynamic
port feature of Nomad makes Connect particularly easy to use. Learn about how to
configure Connect on Nomad by reading the
[integration documentation](/docs/connect/platform/nomad)
[integration documentation](/docs/connect/nomad)
### Kubernetes

4
website/content/docs/connect/connectivity-tasks.mdx
View File

@ -23,9 +23,9 @@ appropriate destination based on the server name requested. The data within the
the Gateway.
As of Consul 1.8.0, mesh gateways can also forward gossip and RPC traffic between Consul servers.
This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways).
This is enabled by [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway)
For more information about mesh gateways, review the [complete documentation](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters)
and the [mesh gateway tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-gateways).
![Mesh Gateway Architecture](/img/mesh-gateways.png)

2
website/content/docs/connect/gateways/index.mdx
View File

@ -27,7 +27,7 @@ They operate by sniffing and extracting the server name indication (SNI) header
Mesh gateways enable the following scenarios:
- **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways) for additional information.
* **Federate multiple datacenters across a WAN**. Since Consul 1.8.0, mesh gateways can forward gossip and RPC traffic between Consul servers. See [WAN federation via mesh gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways) for additional information.
- **Service-to-service communication across datacenters**. Refer to [Enabling Service-to-service Traffic Across Datacenters](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) for additional information.
- **Service-to-service communication across admin partitions**. Since Consul 1.11.0, you can create administrative boundaries for single Consul deployments called "admin partitions". You can use mesh gateways to facilitate cross-partition communication. Refer to [Enabling Service-to-service Traffic Across Admin Partitions](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions) for additional information.

2
website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters.mdx
View File

@ -35,7 +35,7 @@ Ensure that your Consul environment meets the following requirements.
* Each datacenters must be [WAN joined](https://learn.hashicorp.com/tutorials/consul/federarion-gossip-wan).
* The [primary datacenter](/docs/agent/options#primary_datacenter) must be set to the same value in both datacenters. This specifies which datacenter is the authority for Connect certificates and is required for services in all datacenters to establish mutual TLS with each other.
* [gRPC](/docs/agent/options#grpc_port) must be enabled.
* If you want to [enable gateways globally](/docs/connect/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
### Network

2
website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx
View File

@ -26,7 +26,7 @@ Ensure that your Consul environment meets the following requirements.
* A local Consul agent is required to manage its configuration.
* Consul service mesh must be enabled in all partitions. Refer to the [`connect` documentation](/docs/agent/options#connect) for details.
* Each partition must have a unique name. Refer to the [admin partitions documentation](/docs/enteprise/admin-partitions) for details.
* If you want to [enable gateways globally](/docs/connect/mesh-gateway#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
* If you want to [enable gateways globally](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/docs/agent/options#enable_central_service_config).
### Proxy

4
website/content/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways.mdx
View File

@ -9,7 +9,7 @@ description: |-
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway).
~> This topic requires familiarity with [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters).
WAN federation via mesh gateways allows for Consul servers in different datacenters
to be federated exclusively through mesh gateways.
@ -38,7 +38,7 @@ Sometimes this prerequisite is difficult or undesirable to meet:
Operators looking to simplify their WAN deployment and minimize the exposed
security surface area can elect to join these datacenters together using [mesh
gateways](/docs/connect/gateways/mesh-gateway) to do so.
gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) to do so.
[![WAN federation with mesh gateways](/img/wan-federation-connectivity-mesh-gateways.png)](/img/wan-federation-connectivity-mesh-gateways.png)

6
website/content/docs/connect/gateways/terminating-gateway.mdx
View File

@ -22,14 +22,14 @@ For additional use cases and usage patterns, review the tutorial for
[understanding terminating gateways](https://learn.hashicorp.com/tutorials/consul/service-mesh-terminating-gateways).
~> **Known limitations:** Terminating gateways currently do not support targeting service subsets with
[L7 configuration](/docs/connect/l7-traffic-management). They route to all instances of a service with no capabilities
[L7 configuration](/docs/connect/l7-traffic). They route to all instances of a service with no capabilities
for filtering by instance.
## Security Considerations
~> We recommend that terminating gateways are not exposed to the WAN or open internet. This is because terminating gateways
hold certificates to decrypt Consul Connect traffic directed at them and may be configured with credentials to connect
to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/mesh-gateway)
to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters)
whenever possible since they are not capable of decrypting traffic or connecting directly to services.
By specifying a path to a [CA file](/docs/connect/config-entries/terminating-gateway#cafile) connections
@ -120,7 +120,7 @@ All services registered in the Consul catalog must be associated with a node, ev
not managed by a Consul client agent. All agent-less services with the same address can be registered under the same node name and address.
However, ensure that the [node name](/api/catalog#node) for external services registered directly in the catalog
does not match the node name of any Consul client agent node. If the node name overlaps with the node name of a Consul client agent,
Consul's [anti-entropy sync](/docs/internals/anti-entropy) will delete the services registered via the `/catalog/register` HTTP API endpoint.
Consul's [anti-entropy sync](/docs/architecture/anti-entropy) will delete the services registered via the `/catalog/register` HTTP API endpoint.
For a complete example of how to register external services review the
[external services tutorial](https://learn.hashicorp.com/tutorials/consul/service-registration-external-services).

2
website/content/docs/connect/l7-traffic/discovery-chain.mdx
View File

@ -224,7 +224,7 @@ A single node in the compiled discovery chain.
be considered healthy.
- `MeshGateway` `(MeshGatewayConfig)` - The [mesh gateway
configuration](/docs/connect/mesh-gateway#connect-proxy-configuration)
configuration](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters#connect-proxy-configuration)
to use when connecting to this target's service instances.
- `Mode` `(string: "")` - One of `none`, `local`, or `remote`.

2
website/content/docs/connect/native/index.mdx
View File

@ -138,7 +138,7 @@ natively. This enables the service to be returned as part of service
discovery for Connect-capable services, used by other Connect-native applications
and client [proxies](/docs/connect/proxies).
This can be specified directly in the [service definition](/docs/agent/services):
This can be specified directly in the [service definition](/docs/discovery/services):
```json
{

2
website/content/docs/connect/observability/index.mdx
View File

@ -46,7 +46,7 @@ Find other possible metrics syncs in the [Connect Envoy documentation](/docs/con
You can specify the [service protocol](/docs/connect/config-entries/service-defaults#protocol)
in the `service-defaults` configuration entry. You can override it in the
[service registration](/docs/agent/services). By default, proxies only give
[service registration](/docs/discovery/services). By default, proxies only give
you L4 metrics. This protocol allows proxies to handle requests at the right L7
protocol and emit richer L7 metrics. It also allows proxies to make per-request
load balancing and routing decisions.

6
website/content/docs/connect/proxies/envoy.mdx
View File

@ -23,7 +23,7 @@ Consul can configure Envoy sidecars to proxy traffic over the following protocol
On Consul 1.5.0 and older, Envoy proxies can only proxy TCP traffic at L4.
Some [L7 features](/docs/connect/l7-traffic-management) can be configured using [configuration entries](/docs/agent/config-entries). You can add [custom Envoy configurations](#advanced-configuration) to the [proxy service definition](/docs/connect/registration/service-registration) to use Envoy features that are not currently exposed through configuration entries. Adding custom Envoy configurations to the service definition is an interim solution that enables you to use the more powerful features of Envoy.
Some [L7 features](/docs/connect/l7-traffic) can be configured using [configuration entries](/docs/agent/config-entries). You can add [custom Envoy configurations](#advanced-configuration) to the [proxy service definition](/docs/connect/registration/service-registration) to use Envoy features that are not currently exposed through configuration entries. Adding custom Envoy configurations to the service definition is an interim solution that enables you to use the more powerful features of Envoy.
~> **Note:** When using Envoy with Consul and not using the [`consul connect envoy` command](/commands/connect/envoy)
Envoy must be run with the `--max-obj-name-len` option set to `256` or greater for Envoy versions prior to 1.11.0.
@ -240,7 +240,7 @@ defaults that are inherited by all services.
[`service-defaults`](/docs/connect/config-entries/service-defaults)
config entry for the service. Configuring it in a
proxy config will not fully enable some [L7
features](/docs/connect/l7-traffic-management).
features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
- `bind_address` - Override the address Envoy's public listener binds to. By
@ -274,7 +274,7 @@ definition](/docs/connect/registration/service-registration) or
[`service-defaults`](/docs/connect/config-entries/service-defaults)
config entry for the upstream destination service. Configuring it in a
proxy upstream config will not fully enable some [L7
features](/docs/connect/l7-traffic-management).
features](/docs/connect/l7-traffic).
It is supported here for backwards compatibility with Consul versions prior to 1.6.0.
- `connect_timeout_ms` - The number of milliseconds to allow when making upstream

2
website/content/docs/connect/proxies/integrate.mdx
View File

@ -127,7 +127,7 @@ If you are only implementing L4 support in your proxy, set the
fetching the discovery chain so that L7 features, such as HTTP routing rules, are
not returned.
For each [target](/docs/internals/discovery-chain#targets) in the resulting
For each [target](/docs/connect/l7-traffic/discovery-chain#targets) in the resulting
discovery chain, a list of healthy, Connect-capable endpoints may be fetched
from the [`/v1/health/connect/:service_id`] API endpoint as described in the [Service
Discovery](#service-discovery) section.

8
website/content/docs/connect/proxies/managed-deprecated.mdx
View File

@ -18,7 +18,7 @@ definition.
!> **Consul 1.6.0 removes Managed Proxies completely.**
This documentation is provided for prior versions only. You may consider using
[sidecar service
registrations](/docs/connect/proxies/sidecar-service) instead.
registrations](/docs/connect/registration/sidecar-service) instead.
Managed proxies have been deprecated since Consul 1.3 and have been fully removed
in Consul 1.6. Anyone using Managed Proxies should aim to change their workflow
@ -42,7 +42,7 @@ with other workloads. So the high implementation cost of building robust process
supervision didn't actually benefit most real use-cases.
Instead of this Connect 1.3.0 introduces the concept of [sidecar service
registrations](/docs/connect/proxies/sidecar-service) which
registrations](/docs/connect/registration/sidecar-service) which
have almost all of the benefits of simpler configuration but without any of the
additional process management complexity. As a result they can be used to
simplify configuration in both container-based and realistic production
@ -55,7 +55,7 @@ page will document how they work in the interim.
-> **Deprecation Note:** It's _strongly_ recommended you do not build anything
using Managed proxies and consider using [sidecar service
registrations](/docs/connect/proxies/sidecar-service) instead.
registrations](/docs/connect/registration/sidecar-service) instead.
Managed proxies are given
a unique proxy-specific ACL token that allows read-only access to Connect
@ -103,7 +103,7 @@ to re-adopt them on restart.
### Minimal Configuration
Managed proxies are configured within a
[service definition](/docs/agent/services). The simplest possible
[service definition](/docs/discovery/services). The simplest possible
managed proxy configuration is an empty configuration. This enables the
default managed proxy and starts a listener for that service:

2
website/content/docs/connect/registration/index.mdx
View File

@ -10,7 +10,7 @@ description: >-
# Proxy Registration
To make Connect aware of proxies you will need to register them in a [service
definition](/docs/agent/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations.
definition](/docs/discovery/services), just like you would register any other service with Consul. This section outlines your options for registering Connect proxies, either using independent registrations, or in nested sidecar registrations.
## Proxy Service Registration

8
website/content/docs/connect/registration/service-registration.mdx
View File

@ -193,7 +193,7 @@ You can configure the service mesh proxy to create listeners for upstream servic
Upstreams support multiple destination types. The following examples include information about each implementation.
-> **Snake case**: The examples in this topic use `snake_case` because the syntax is supported in configuration files and API registrations. See [Service Definition Parameter Case](/docs/agent/services#service-definition-parameter-case) for additional information.
-> **Snake case**: The examples in this topic use `snake_case` because the syntax is supported in configuration files and API registrations. See [Service Definition Parameter Case](/docs/discovery/services#service-definition-parameter-case) for additional information.
<CodeTabs heading="Example service destination upstream">
<CodeBlockConfig>
@ -306,7 +306,7 @@ The following examples show additional configuration for transparent proxies.
Added in v1.10.0.
-> Note that `snake_case` is used here as it works in both [config file and API
registrations](/docs/agent/services#service-definition-parameter-case).
registrations](/docs/discovery/services#service-definition-parameter-case).
#### Configure a proxy listener for outbound traffic on port 22500
@ -332,7 +332,7 @@ registrations](/docs/agent/services#service-definition-parameter-case).
The following examples show all possible mesh gateway configurations.
-> Note that `snake_case` is used here as it works in both [config file and API
registrations](/docs/agent/services#service-definition-parameter-case).
registrations](/docs/discovery/services#service-definition-parameter-case).
#### Using a Local/Egress Gateway in the Local Datacenter
@ -390,7 +390,7 @@ non-Connect-enabled applications to contact an HTTP endpoint.
Some examples include: exposing a `/metrics` path for Prometheus or `/healthz` for kubelet liveness checks.
-> Note that `snake_case` is used here as it works in both [config file and API
registrations](/docs/agent/services#service-definition-parameter-case).
registrations](/docs/discovery/services#service-definition-parameter-case).
#### Expose listeners in Envoy for HTTP and GRPC checks registered with the local Consul agent

6
website/content/docs/connect/registration/sidecar-service.mdx
View File

@ -14,7 +14,7 @@ the same VM or running as a separate container in the same network namespace.
To simplify the configuration experience when deploying a sidecar for a service
instance, Consul 1.3 introduced a new field in the Connect block of the [service
definition](/docs/agent/services).
definition](/docs/discovery/services).
To deploy a service and sidecar proxy locally, complete the
[Getting Started guide](https://learn.hashicorp.com/tutorials/consul/get-started-service-networking?utm_source=consul.io&utm_medium=docs).
@ -136,7 +136,7 @@ proxy.
- `kind` - Defaults to `connect-proxy`. This can't be overridden currently.
- `check`, `checks` - By default we add a TCP check on the local address and
port for the proxy, and a [service alias
check](/docs/agent/checks#alias) for the parent service. If either
check](/docs/discovery/checks#alias) for the parent service. If either
`check` or `checks` fields are set, only the provided checks are registered.
- `proxy.destination_service_name` - Defaults to the parent service name.
- `proxy.destination_service_id` - Defaults to the parent service ID.
@ -145,7 +145,7 @@ proxy.
## Limitations
Almost all fields in a [service definition](/docs/agent/services) may be
Almost all fields in a [service definition](/docs/discovery/services) may be
set on the `connect.sidecar_service` except for the following:
- `id` - Sidecar services get an ID assigned and it is an error to override

8
website/content/docs/connect/security.mdx
View File

@ -13,7 +13,7 @@ Connect enables secure service-to-service communication over mutual TLS. This
provides both in-transit data encryption as well as authorization. This page
will document how to secure Connect. To try Connect locally, complete the
[Getting Started guide](https://learn.hashicorp.com/tutorials/consul/service-mesh?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) or for a full security model reference,
see the dedicated [Consul security model](/docs/internals/security) page. When
see the dedicated [Consul security model](/docs/security) page. When
setting up Connect in production, review this [tutorial](https://learn.hashicorp.com/tutorials/consul/service-mesh-production-checklist?utm_source=consul.io&utm_medium=docs).
Connect will function in any Consul configuration. However, unless the checklist
@ -22,7 +22,7 @@ built for. The checklist below can be incrementally adopted towards full
security if you prefer to operate in less secure models initially.
~> **Warning**: The checklist below should not be considered exhaustive. Please
read and understand the [Consul security model](/docs/internals/security)
read and understand the [Consul security model](/docs/security)
in depth to assess whether your deployment satisfies the security requirements
of Consul.
@ -54,7 +54,7 @@ to verify server authenticity with each server having a unique TLS certificate.
affect Connect since requests must also always contain a valid ACL token.
Clients calling Consul APIs should be forced over encrypted connections.
See the [Consul agent encryption page](/docs/agent/encryption) to
See the [Consul agent encryption page](/docs/security/encryption) to
learn more about configuring agent encryption.
**If encryption is not enabled**, a malicious actor can sniff network
@ -68,7 +68,7 @@ clients and servers should be protected from unauthorized access. This
protection must be done outside of Consul via access control systems provided
by your target operating system.
The [full Consul security model](/docs/internals/security) explains the
The [full Consul security model](/docs/security) explains the
risk of unauthorized access for both client agents and server agents. In
general, the blast radius of unauthorized access for client agent directories
is much smaller than servers. However, both must be protected against

2
website/content/docs/discovery/checks.mdx
View File

@ -420,7 +420,7 @@ updating a TTL check via the HTTP interface can set the `notes` value.
Checks may also contain a `token` field to provide an ACL token. This token is
used for any interaction with the catalog for the check, including
[anti-entropy syncs](/docs/internals/anti-entropy) and deregistration.
[anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration.
For Alias checks, this token is used if a remote blocking query is necessary
to watch the state of the aliased node or service.

4
website/content/docs/discovery/dns.mdx
View File

@ -102,7 +102,7 @@ A service lookup is used to query for service providers. Service queries support
two lookup methods: standard and strict [RFC 2782](https://tools.ietf.org/html/rfc2782).
By default, SRV weights are all set at 1, but changing weights is supported using the
`Weights` attribute of the [service definition](/docs/agent/services).
`Weights` attribute of the [service definition](/docs/discovery/services).
Note that DNS is limited in size per request, even when performing DNS TCP
queries.
@ -394,7 +394,7 @@ To find ingress-enabled services:
<service>.ingress.<domain>
```
This will find all [ingress gateway](/docs/connect/ingress-gateway)
This will find all [ingress gateway](/docs/connect/gateways/ingress-gateway)
endpoints for the given `service`.
This endpoint currently only finds services within the same datacenter

10
website/content/docs/discovery/services.mdx
View File

@ -212,7 +212,7 @@ This is the root-level parameter that defines the service. You can specify the p
| `tagged_addresses` | Tagged addresses are additional addresses that may be defined for a node or service. See [Tagged Addresses](#tagged-addresses) for details. | None | Optional |
| `port` | Integer value that specifies a service-specific port number. The port number should be specified when the `address` parameter is defined to improve service discoverability. | Optional |
| `socket_path` | String value that specifies the path to the service socket. <br/>Specify this parameter to expose the service to the mesh if the service listens on a Unix Domain socket. | None | Optional |
| `enable_tag_override` | Boolean value that determines if the anti-entropy feature for the service is enabled. <br/> If set to `true`, then external agents can update this service in the catalog and modify the tags.<br/> Subsequent local sync operations by this agent will ignore the updated tags. <br/> This parameter only applies to the locally-registered service. If multiple nodes register the same service, the `enable_tag_override` configuration, and all other service configuration items, operate independently. <br/>Updating the tags for services registered on one node is independent from the same service (by name) registered on another node. <br/> See [anti-entropy syncs](/docs/internals/anti-entropy) for additional information.<br/> | False | Optional |
| `enable_tag_override` | Boolean value that determines if the anti-entropy feature for the service is enabled. <br/> If set to `true`, then external agents can update this service in the catalog and modify the tags.<br/> Subsequent local sync operations by this agent will ignore the updated tags. <br/> This parameter only applies to the locally-registered service. If multiple nodes register the same service, the `enable_tag_override` configuration, and all other service configuration items, operate independently. <br/>Updating the tags for services registered on one node is independent from the same service (by name) registered on another node. <br/> See [anti-entropy syncs](/docs/architecture/anti-entropy) for additional information.<br/> | False | Optional |
| `checks` | Array of objects that define health checks for the service. See [Health Checks](#health-checks) for details. | None | Optional |
| `kind` | String value that identifies the service as a Connect proxy. See [Connect](#connect) for details. | None | Optional |
| `proxy_destination` | String value that specifies the _name_ of the destination service that the service currently being configured proxies to. <br/>This parameter is deprecated. Use `proxy.destination_service` instead. <br/>See [Connect](#connect) for additional information. | None | Optional |
@ -233,7 +233,7 @@ You can add semantic meta data to the service using the `meta` parameter. This p
### Security Configurations
If the ACL system is enabled, specify a value for the `token` parameter to provide an ACL token. This token is
used for any interaction with the catalog for the service, including [anti-entropy syncs](/docs/internals/anti-entropy) and deregistration.
used for any interaction with the catalog for the service, including [anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration.
Services registered in Consul clusters where both [Consul Namespaces](/docs/enterprise/namespaces)<EnterpriseAlert inline />
and the ACL system are enabled can be registered to specific namespaces that are associated with
@ -252,7 +252,7 @@ The health check name is automatically generated as `service:<service-id>`. If t
registered, the ID will be generated as `service:<service-id>:<num>` where
`<num>` is an incrementing number starting from `1`.
Consul includes several check types with different options. Refer to the [health checks documentation](/docs/agent/checks) for details.
Consul includes several check types with different options. Refer to the [health checks documentation](/docs/discovery/checks) for details.
### Proxy
@ -319,7 +319,7 @@ is present in the agent DNS configuration or the `passing` query parameter is us
Services may also contain a `token` field to provide an ACL token. This token is
used for any interaction with the catalog for the service, including
[anti-entropy syncs](/docs/internals/anti-entropy) and deregistration.
[anti-entropy syncs](/docs/architecture/anti-entropy) and deregistration.
You can optionally disable the anti-entropy feature for this service using the
`enable_tag_override` flag. External agents can modify tags on services in the
@ -336,7 +336,7 @@ configuration items are independent of one another. Updating the tags
for the service registered on one node is independent of the same
service (by name) registered on another node. If `enable_tag_override` is
not specified the default value is false. See [anti-entropy
syncs](/docs/internals/anti-entropy) for more info.
syncs](/docs/architecture/anti-entropy) for more info.
For Consul 0.9.3 and earlier you need to use `enableTagOverride`. Consul 1.0
supports both `enable_tag_override` and `enableTagOverride` but the latter is

10
website/content/docs/dynamic-app-config/kv.mdx
View File

@ -15,7 +15,7 @@ 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) allows clients to forward
functionality](/docs/architecture) 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
@ -32,7 +32,7 @@ subcommands](/commands/kv), [HTTP API](/api/kv), and Consul UI.
To restrict access, enable and configure
[ACLs](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production).
Once the ACL system has been bootstrapped, users and services, will need a
valid token with KV [privileges](/docs/agent/acl-rules#key-value-rules) to
valid token with KV [privileges](/docs/security/acl/acl-rules#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
@ -75,9 +75,9 @@ 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) are a way to monitor data for updates. When
[Watches](/docs/dynamic-app-config/watches) 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#key) watch type should be used.
KV store the [key](/docs/dynamic-app-config/watches#key) watch type should be used.
### Consul Sessions
@ -87,7 +87,7 @@ 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#k-v-integration).
on the [integration](/docs/dynamic-app-config/sessions#k-v-integration).
Review the following tutorials to learn how to use Consul sessions for [application leader election](https://learn.hashicorp.com/tutorials/consul/application-leader-elections) and
to [build distributed semaphores](https://learn.hashicorp.com/tutorials/consul/distributed-semaphore).

2
website/content/docs/dynamic-app-config/sessions.mdx
View File

@ -51,7 +51,7 @@ deleted by Consul.
While this is a simple design, it enables a multitude of usage
patterns. By default, the
[gossip based failure detector](/docs/internals/gossip)
[gossip based failure detector](/docs/architecture/gossip)
is used as the associated health check. This failure detector allows
Consul to detect when a node that is holding a lock has failed and
to automatically release the lock. This ability provides **liveness** to

2
website/content/docs/enterprise/index.mdx
View File

@ -23,7 +23,7 @@ Features include:
- [Namespaces](/docs/enterprise/namespaces)
- [NIA with Terraform Enterprise](/docs/nia/enterprise)
- [Sentinel](/docs/enterprise/sentinel)
- [OIDC Auth Method](/docs/acl/auth-methods/oidc)
- [OIDC Auth Method](/docs/security/acl/auth-methods/oidc)
These features are part of [Consul
Enterprise](https://www.hashicorp.com/consul).

2
website/content/docs/enterprise/license/faq.mdx
View File

@ -37,7 +37,7 @@ The list below is a great starting point for learning more about the license cha
- [Consul Enterprise Upgrade Documentation](https://www.consul.io/docs/enterprise/upgrades)
- [Consul License Documentation](/docs/enterprise/license)
- [Consul License Documentation](/docs/enterprise/license/overview)
- [License configuration values documentation](/docs/enterprise/license/overview#binaries-without-built-in-licenses)

2
website/content/docs/enterprise/network-segments.mdx
View File

@ -142,7 +142,7 @@ segments are:
Each client agent can only be a member of one segment at a time. This will be the
`<default>` segment unless otherwise specified in the agent's
[`segment`](/docs/agent/options.html#_segment) agent configuration option.
[`segment`](/docs/agent/options#_segment) agent configuration option.
### Join a Client to a Segment ((#join_a_client_to_a_segment))

6
website/content/docs/install/bootstrapping.mdx
View File

@ -12,18 +12,18 @@ description: >-
# Bootstrapping a Datacenter
An agent can run in either client or server mode. Server nodes are responsible for running the
[consensus protocol](/docs/internals/consensus) and storing the cluster state.
[consensus protocol](/docs/architecture/consensus) and storing the cluster state.
The client nodes are mostly stateless and rely heavily on the server nodes.
Before a Consul cluster can begin to service requests,
a server node must be elected leader. Bootstrapping is the process
of joining these initial server nodes into a cluster. Read the
[architecture documentation](/docs/internals/architecture) to learn more about
[architecture documentation](/docs/architecture) to learn more about
the internals of Consul.
It is recommended to have three or five total servers per datacenter. A single server deployment is _highly_ discouraged
as data loss is inevitable in a failure scenario. Please refer to the
[deployment table](/docs/internals/consensus#deployment-table) for more detail.
[deployment table](/docs/architecture/consensus#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 documentation](/docs/install/bootstrapping#manually-join-the-servers).

4
website/content/docs/install/glossary.mdx
View File

@ -48,14 +48,14 @@ transactions are applied to a
[finite-state machine](https://en.wikipedia.org/wiki/Finite-state_machine), our definition
of consensus implies the consistency of a replicated state machine. Consensus is described
in more detail on [Wikipedia](<https://en.wikipedia.org/wiki/Consensus_(computer_science)>),
and our implementation is described [here](/docs/internals/consensus).
and our implementation is described [here](/docs/architecture/consensus).
## Gossip
Consul is built on top of [Serf](https://www.serf.io/) which provides a full
[gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) that is used for multiple purposes.
Serf provides membership, failure detection, and event broadcast. Our use of these
is described more in the [gossip documentation](/docs/internals/gossip). It is enough to know
is described more in the [gossip documentation](/docs/architecture/gossip). It is enough to know
that gossip involves random node-to-node communication, primarily over UDP.
## LAN Gossip

2
website/content/docs/install/index.mdx
View File

@ -79,4 +79,4 @@ $ consul version
Consul currently supports all 'evergreen' browsers, as they are generally on
up-to-date versions. For more information on supported browsers, please see our
[FAQ](/docs/faq)
[FAQ](/docs/troubleshoot/faq)

6
website/content/docs/install/manual-bootstrap.mdx
View File

@ -12,13 +12,13 @@ description: >-
When deploying Consul to a datacenter for the first time, there is an initial
bootstrapping that must be done. As of Consul 0.4, an
[automatic bootstrapping](/docs/guides/bootstrapping) is available and is
[automatic bootstrapping](/docs/install/bootstrapping) is available and is
the recommended approach. However, older versions only support a manual
bootstrap that is documented here.
Generally, the first nodes that are started are the server nodes. Remember that
an agent can run in both client and server mode. Server nodes are responsible
for running the [consensus protocol](/docs/internals/consensus), and
for running the [consensus protocol](/docs/architecture/consensus), and
storing the cluster state. The client nodes are mostly stateless and rely on the
server nodes, so they can be started easily.
@ -35,7 +35,7 @@ something like the following will be logged:
```
Once `Node A` is running, we can start the next set of servers. There is a
[deployment table](/docs/internals/consensus#toc_4) that covers various
[deployment table](/docs/architecture/consensus#deployment_table) that covers various
options, but it is recommended to have 3 or 5 total servers per datacenter. A
single server deployment is _**highly**_ discouraged as data loss is inevitable
in a failure scenario. We start the next servers **without** specifying

2
website/content/docs/install/performance.mdx
View File

@ -9,7 +9,7 @@ description: >-
# Server Performance
Since Consul servers run a [consensus protocol](/docs/internals/consensus) to
Since Consul servers run a [consensus protocol](/docs/architecture/consensus) to
process all write operations and are contacted on nearly all read operations, server
performance is critical for overall throughput and health of a Consul cluster. Servers
are generally I/O bound for writes because the underlying Raft log store performs a sync

2
website/content/docs/internals/acl.mdx
View File

@ -12,5 +12,5 @@ description: >-
This content has been moved into the [ACL Guide](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production).
See [Complete ACL Coverage in Consul 0.8](/docs/acl/acl-legacy) for details
See [Complete ACL Coverage in Consul 0.8](/docs/security/acl/acl-legacy) for details
about ACL changes in Consul 0.8 and later.

18
website/content/docs/internals/index.mdx
View File

@ -13,14 +13,14 @@ use it in production.
Please review the following documentation to understand how Consul works.
- [Architecture](/docs/internals/architecture)
- [Consensus Protocol](/docs/internals/consensus)
- [Gossip Protocol](/docs/internals/gossip)
- [Network Coordinates](/docs/internals/coordinates)
- [Sessions](/docs/internals/sessions)
- [Anti-Entropy](/docs/internals/anti-entropy)
- [Security Model](/docs/internals/security)
- [Discovery Chain](/docs/internals/discovery-chain)
- [Architecture](/docs/architecture)
- [Consensus Protocol](/docs/architecture/consensus)
- [Gossip Protocol](/docs/architecture/gossip)
- [Network Coordinates](/docs/architecture/coordinates)
- [Sessions](/docs/security/acl/auth-methods/oidc)
- [Anti-Entropy](/docs/architecture/anti-entropy)
- [Security Model](/docs/security)
- [Discovery Chain](/docs/connect/l7-traffic/discovery-chain)
You should also be familiar with [Jepsen testing](/docs/internals/jepsen), before deploying
You should also be familiar with [Jepsen testing](/docs/architecture/jepsen), before deploying
a production datacenter.

6
website/content/docs/intro/index.mdx
View File

@ -86,7 +86,7 @@ application developers, making it perfect for modern, elastic infrastructures.
Consul is a distributed, highly available system. This section will cover the
basics, purposely omitting some unnecessary detail, so you can get a quick
understanding of how Consul works. For more detail, please refer to the
[in-depth architecture overview](/docs/internals/architecture).
[in-depth architecture overview](/docs/architecture).
Every node that provides services to Consul runs a _Consul agent_. Running
an agent is not required for discovering other services or getting/setting
@ -103,7 +103,7 @@ The servers maintain a _catalog_, which is formed by aggregating information
submitted by the agents. The catalog maintains the high-level view of the cluster,
including which services are available, which nodes run those services, health
information, and more. How agents and the catalog interact can be found
[here](/docs/internals/anti-entropy#catalog).
[here](/docs/architecture/anti-entropy#catalog).
Components of your infrastructure that need to discover other services
or nodes can query any of the Consul servers _or_ any of the Consul agents.
@ -115,7 +115,7 @@ forward the request to the remote datacenter and return the result.
## Next Steps
- See [how Consul compares to other software](/intro/vs) to assess how it fits into your
- See [how Consul compares to other software](/docs/intro/vs) to assess how it fits into your
existing infrastructure.
- Continue onwards with [HashiCorp Learn](https://learn.hashicorp.com/tutorials/consul/get-started-install)
to learn more about Consul and how to get Consul up and running.

4
website/content/docs/intro/vs/eureka.mdx
View File

@ -32,9 +32,9 @@ most applications to be Consul unaware, performing the service registration via
files and discovery via DNS or load balancer sidecars.
Consul provides a strong consistency guarantee, since servers replicate state using the
[Raft protocol](/docs/internals/consensus). Consul supports a rich set of health checks
[Raft protocol](/docs/architecture/consensus). Consul supports a rich set of health checks
including TCP, HTTP, Nagios/Sensu compatible scripts, or TTL based like Eureka. Client nodes
participate in a [gossip based health check](/docs/internals/gossip), which distributes
participate in a [gossip based health check](/docs/architecture/gossip), which distributes
the work of health checking, unlike centralized heartbeating which becomes a scalability challenge.
Discovery requests are routed to the elected Consul leader which allows them to be strongly consistent
by default. Clients that allow for stale reads enable any server to process their request allowing

2
website/content/docs/intro/vs/nagios.mdx
View File

@ -36,7 +36,7 @@ allowing the system to be much more scalable.
An astute reader may notice that if a Consul agent dies, then no edge triggered
updates will occur. From the perspective of other nodes, all checks will appear
to be in a steady state. However, Consul guards against this as well. The
[gossip protocol](/docs/internals/gossip) used between clients and servers
[gossip protocol](/docs/architecture/gossip) used between clients and servers
integrates a distributed failure detector. This means that if a Consul agent fails,
the failure will be detected, and thus all checks being run by that node can be
assumed failed. This failure detector distributes the work among the entire cluster

4
website/content/docs/intro/vs/serf.mdx
View File

@ -21,7 +21,7 @@ Serf does not provide any high-level features such as service discovery, health
checking or key/value storage. Consul is a complete system providing all of those
features.
The internal [gossip protocol](/docs/internals/gossip) used within Consul is in
The internal [gossip protocol](/docs/architecture/gossip) used within Consul is in
fact powered by the Serf library: Consul leverages the membership and failure detection
features and builds upon them to add service discovery. By contrast, the discovery
feature of Serf is at a node level, while Consul provides a service and node level
@ -42,7 +42,7 @@ catalog while Serf is only eventually-consistent.
In addition to the service level abstraction and improved health checking,
Consul provides a key/value store and support for multiple datacenters.
Serf can run across the WAN but with degraded performance. Consul makes use
of [multiple gossip pools](/docs/internals/architecture) so that
of [multiple gossip pools](/docs/architecture) so that
the performance of Serf over a LAN can be retained while still using it over
a WAN for linking together multiple datacenters.

2
website/content/docs/intro/vs/smartstack.mdx
View File

@ -25,7 +25,7 @@ and dynamically configures HAProxy. Finally, clients speak to HAProxy, which doe
health checking and load balancing across service providers.
Consul is a much simpler and more contained system as it does not rely on any external
components. Consul uses an integrated [gossip protocol](/docs/internals/gossip)
components. Consul uses an integrated [gossip protocol](/docs/architecture/gossip)
to track all nodes and perform server discovery. This means that server addresses
do not need to be hardcoded and updated fleet-wide on changes, unlike SmartStack.

4
website/content/docs/k8s/connect/ingress-gateways.mdx
View File

@ -8,10 +8,10 @@ description: Configuring Ingress Gateways on Kubernetes
-> 1.9.0+: This feature is available in Consul versions 1.9.0 and higher
~> This topic requires familiarity with [Ingress Gateways](/docs/connect/ingress-gateway).
~> This topic requires familiarity with [Ingress Gateways](/docs/connect/gateways/ingress-gateway).
This page describes how to enable external access to Connect Service Mesh services running inside Kubernetes using Consul ingress gateways.
See [Ingress Gateways](/docs/connect/ingress-gateway) for more information on use-cases and how it works.
See [Ingress Gateways](/docs/connect/gateways/ingress-gateway) for more information on use-cases and how it works.
Adding an ingress gateway is a multi-step process that consists of the following steps:

2
website/content/docs/k8s/connect/terminating-gateways.mdx
View File

@ -8,7 +8,7 @@ description: Configuring Terminating Gateways on Kubernetes
-> 1.9.0+: This feature is available in Consul versions 1.9.0 and higher
~> This topic requires familiarity with [Terminating Gateways](/docs/connect/terminating-gateway).
~> This topic requires familiarity with [Terminating Gateways](/docs/connect/gateways/terminating-gateway).
Adding a terminating gateway is a multi-step process:

2
website/content/docs/k8s/index.mdx
View File

@ -48,7 +48,7 @@ Kubernetes can choose to leverage Consul.
## Architecture
Consul runs on Kubernetes with the same
[architecture](/docs/internals/architecture)
[architecture](/docs/architecture)
as other platforms. There are some benefits Kubernetes can provide
that eases operating a Consul cluster and we document those below. The standard
[production deployment guide](https://learn.hashicorp.com/consul/datacenter-deploy/deployment-guide) is still an

2
website/content/docs/k8s/installation/deployment-configurations/clients-outside-kubernetes.mdx
View File

@ -26,7 +26,7 @@ with the server pod or host IP addresses.
## Auto-join
The recommended way to join a cluster running within Kubernetes is to
use the ["k8s" cloud auto-join provider](/docs/agent/cloud-auto-join#kubernetes-k8s).
use the ["k8s" cloud auto-join provider](/docs/install/cloud-auto-join#kubernetes-k8s).
The auto-join provider dynamically discovers IP addresses to join using
the Kubernetes API. It authenticates with Kubernetes using a standard

8
website/content/docs/k8s/installation/deployment-configurations/servers-outside-kubernetes.mdx
View File

@ -23,7 +23,7 @@ their pod IPs (`false`).
Finally, `client.join` is set to an array of valid
[`-retry-join` values](/docs/agent/options#retry-join). In the
example above, a fake [cloud auto-join](/docs/agent/cloud-auto-join)
example above, a fake [cloud auto-join](/docs/install/cloud-auto-join)
value is specified. This should be set to resolve to the proper addresses of
your existing Consul cluster.
@ -57,7 +57,7 @@ You may also consider adopting Consul Enterprise for
-> **Note:** Consul on Kubernetes currently does not support external servers that require mutual authentication
for the HTTPS clients of the Consul servers, that is when servers have either
`verify_incoming` or `verify_incoming_https` set to `true`.
As noted in the [Security Model](/docs/internals/security#secure-configuration),
As noted in the [Security Model](/docs/security#secure-configuration),
that setting isn't strictly necessary to support Consul's threat model as it is recommended that
all requests contain a valid ACL token.
@ -94,7 +94,7 @@ to help initialize ACL tokens for Consul clients and consul-k8s components for y
### Manually Bootstrapping ACLs
If you would like to call the [ACL bootstrapping API](/api/acl/acl#bootstrap-acls) yourself or if your cluster has already been bootstrapped with ACLs,
If you would like to call the [ACL bootstrapping API](/api-docs/acl#bootstrap-acls) yourself or if your cluster has already been bootstrapped with ACLs,
you can provide the bootstrap token to the Helm chart. The Helm chart will then use this token to configure ACLs
for Consul clients and any consul-k8s components you are enabling.
@ -128,7 +128,7 @@ The bootstrap token requires the following minimal permissions:
Next, configure external servers. The Helm chart will use this configuration to talk to the Consul server's API
to create policies, tokens, and an auth method. If you are [enabling Consul Connect](/docs/k8s/connect),
`k8sAuthMethodHost` should be set to the address of your Kubernetes API server
so that the Consul servers can validate a Kubernetes service account token when using the [Kubernetes auth method](/docs/acl/auth-methods/kubernetes)
so that the Consul servers can validate a Kubernetes service account token when using the [Kubernetes auth method](/docs/security/acl/auth-methods/kubernetes)
with `consul login`.
<CodeBlockConfig filename="config.yaml">

4
website/content/docs/k8s/installation/install.mdx
View File

@ -98,7 +98,7 @@ cluster with default configurations. We strongly recommend [learning about the c
of Consul. This provides a less complicated out-of-box experience for new users,
but is not appropriate for a production setup. We strongly recommend using
a properly-secured Kubernetes cluster or making sure that you understand and enable
the [recommended security features](/docs/internals/security). Currently,
the [recommended security features](/docs/security). Currently,
some of these features are not supported in the Helm chart and require additional
manual configuration.
@ -180,7 +180,7 @@ NAME: consul
```
If you've already installed Consul and want to make changes, you'll need to run
`helm upgrade`. See [Upgrading](/docs/k8s/operations/upgrading) for more details.
`helm upgrade`. See [Upgrading](/docs/k8s/upgrade) for more details.
## Viewing the Consul UI

2
website/content/docs/k8s/installation/multi-cluster/index.mdx
View File

@ -13,7 +13,7 @@ with one another. This enables the following features:
- Services on all clusters can make calls to each other through Consul Service Mesh.
- [Intentions](/docs/connect/intentions) can be used to enforce rules about which services can communicate across all clusters.
- [L7 Routing Rules](/docs/connect/l7-traffic-management) can enable multi-cluster failover
- [L7 Routing Rules](/docs/connect/l7-traffic) can enable multi-cluster failover
and traffic splitting.
- The Consul UI has a drop-down menu that lets you navigate between datacenters.

4
website/content/docs/k8s/installation/multi-cluster/kubernetes.mdx
View File

@ -9,7 +9,7 @@ description: >-
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/mesh-gateway) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways).
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
-> Looking for a step-by-step guide? Please follow our Learn tutorial: [Secure and Route Service Mesh Communication Across Kubernetes](https://learn.hashicorp.com/tutorials/consul/kubernetes-mesh-gateways).
@ -163,7 +163,7 @@ If you've set `enableAutoEncrypt: true`, this is also supported.
creates a Kubernetes Load Balancer service. If you wish to customize the
mesh gateway, see the [Helm reference](/docs/k8s/helm#v-meshgateway) for that setting.
With the above settings added to your existing config, follow the [Upgrading](/docs/k8s/operations/upgrading)
With the above settings added to your existing config, follow the [Upgrading](/docs/k8s/upgrade)
guide to upgrade your cluster and then come back to the [Federation Secret](#federation-secret) section.
-> **NOTE:** You must be using consul-helm 0.21.0+.

4
website/content/docs/k8s/installation/multi-cluster/vms-and-kubernetes.mdx
View File

@ -9,7 +9,7 @@ description: >-
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and higher
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/mesh-gateway) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways).
~> This topic requires familiarity with [Mesh Gateways](/docs/connect/gateways/mesh-gateway/service-to-service-traffic-datacenters) and [WAN Federation Via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
Consul datacenters running on non-kubernetes platforms like VMs or bare metal can
be federated with Kubernetes datacenters. Just like with Kubernetes, one datacenter
@ -202,7 +202,7 @@ construct the [Federation Secret](/docs/k8s/installation/multi-cluster/kubernete
Kubernetes clusters as secondaries.
-> Your VM cluster must be running mesh gateways, and have mesh gateway WAN
federation enabled. See [WAN Federation via Mesh Gateways](/docs/connect/gateways/wan-federation-via-mesh-gateways).
federation enabled. See [WAN Federation via Mesh Gateways](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways).
You'll need:

6
website/content/docs/k8s/operations/tls-on-existing-cluster.mdx
View File

@ -34,7 +34,7 @@ This upgrade will trigger a rolling update of the clients, as well as any
other `consul-k8s` components, such as sync catalog or client snapshot deployments.
1. Perform a rolling upgrade of the servers, as described in
[Upgrade Consul Servers](/docs/k8s/operations/upgrading#upgrading-consul-servers).
[Upgrade Consul Servers](/docs/k8s/upgrade#upgrading-consul-servers).
1. Repeat steps 1 and 2, turning on TLS verification by setting `global.tls.verify`
to `true`.
@ -71,7 +71,7 @@ applications to it.
```
In this configuration, we're setting `server.updatePartition` to the number of
server replicas as described in [Upgrade Consul Servers](/docs/k8s/operations/upgrading#upgrading-consul-servers)
server replicas as described in [Upgrade Consul Servers](/docs/k8s/upgrade#upgrading-consul-servers)
and `client.updateStrategy` to `OnDelete` to manually trigger an upgrade of the clients.
1. Run `helm upgrade` with the above config file. The upgrade will trigger an update of all
@ -94,7 +94,7 @@ applications to it.
the sidecar proxy. Also, Kubernetes should schedule these applications on the new node pool.
1. Perform a rolling upgrade of the servers described in
[Upgrade Consul Servers](/docs/k8s/operations/upgrading#upgrading-consul-servers).
[Upgrade Consul Servers](/docs/k8s/upgrade#upgrading-consul-servers).
1. If everything is healthy, delete the old node pool.

4
website/content/docs/k8s/service-sync.mdx
View File

@ -92,9 +92,9 @@ then the sync program should work.
For Consul, if ACLs are configured on the cluster, a Consul
[ACL token](https://learn.hashicorp.com/tutorials/consul/access-control-setup-production)
will need to be provided. Review the [ACL rules](/docs/agent/acl-rules)
will need to be provided. Review the [ACL rules](/docs/security/acl/acl-rules)
when creating this token so that it only allows the necessary privileges. The catalog
sync process accepts this token by using the [`CONSUL_HTTP_TOKEN`](/docs/commands#consul_http_token)
sync process accepts this token by using the [`CONSUL_HTTP_TOKEN`](/commands#consul_http_token)
environment variable. This token should be set as a
[Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/#creating-your-own-secrets)
and referenced in the Helm chart.

2
website/content/docs/k8s/upgrade/index.mdx
View File

@ -323,4 +323,4 @@ Consul clients.
If you already have a Consul cluster deployed on Kubernetes and
would like to turn on TLS for internal Consul communication,
please see
[Configuring TLS on an Existing Cluster](/docs/k8s/tls-on-existing-cluster).
[Configuring TLS on an Existing Cluster](/docs/k8s/operations/tls-on-existing-cluster).

2
website/content/docs/nia/api/tasks.mdx
View File

@ -24,7 +24,7 @@ This endpoint allows patch updates to specifically supported fields for existing
#### Response Fields
* `inspect` - Information on how resources would be changed given a proposed task update, similar to [inspect-mode](/docs/nia/cli/cli-overview#inspect-mode). This is only returned when passed the `run=inspect` request parameter
* `inspect` - Information on how resources would be changed given a proposed task update, similar to [inspect-mode](/docs/nia/cli#inspect-mode). This is only returned when passed the `run=inspect` request parameter
* `changes_present` - (bool) Whether or not changes were detected for running the proposed task update
* `plan` - (string) The Terraform plan generated for the proposed task update . Note: a non-empty string does not necessarily indicate changes were detected.

6
website/content/docs/nia/cli/task.mdx
View File

@ -8,7 +8,7 @@ description: >-
## task enable
`task enable` command enables an existing task so that it will run and update task resources. If the task is already enabled, it will return a success. The command generates and outputs a Terraform plan, similar to [inspect-mode](/docs/nia/cli/cli-overview#inspect-mode), of how resources will be modified if task becomes enabled. If resources changes are detected, the command will ask for user approval before enabling the task. If no resources are detected, the command will go ahead and enable the task.
`task enable` command enables an existing task so that it will run and update task resources. If the task is already enabled, it will return a success. The command generates and outputs a Terraform plan, similar to [inspect-mode](/docs/nia/cli#inspect-mode), of how resources will be modified if task becomes enabled. If resources changes are detected, the command will ask for user approval before enabling the task. If no resources are detected, the command will go ahead and enable the task.
### Usage
`consul-terraform-sync task enable [options] <task_name>`
@ -16,7 +16,7 @@ description: >-
**Arguments:**
- `task_name` - (string: required) The name of the task to enable
**Options:** Currently only supporting [general options](/docs/nia/cli/cli-overview#general-options)
**Options:** Currently only supporting [general options](/docs/nia/cli#general-options)
### Example
@ -62,7 +62,7 @@ Enter a value: yes
**Arguments:**
- `task_name` - (string: required) The name of the task to disable
**Options:** Currently only supporting [general options](/docs/nia/cli/cli-overview#general-options)
**Options:** Currently only supporting [general options](/docs/nia/cli#general-options)
### Example

Some files were not shown because too many files have changed in this diff Show More