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

Convert absolute URLs to relative URLs for consul.io

This commit is contained in:
Blake Covarrubias 2022-01-10 15:42:51 -08:00
parent 59394e4aa2
commit 26401c5c26
21 changed files with 35 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/content/docs/connect/transparent-proxy.mdx
View File

@ -136,7 +136,7 @@ transparent proxy's datacenter. Services can also dial explicit upstreams in oth
[annotation](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) such as
`"consul.hashicorp.com/connect-service-upstreams": "my-service:1234:dc2"` to reach an upstream service called `my-service`
in the datacenter `dc2`.
* In the deployment configuration where a [single Consul datacenter spans multiple Kubernetes clusters](https://www.consul.io/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s), services in one Kubernetes cluster must explicitly dial a service in another Kubernetes cluster using the [consul.hashicorp.com/connect-service-upstreams](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation. An example would be
* In the deployment configuration where a [single Consul datacenter spans multiple Kubernetes clusters](/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s), services in one Kubernetes cluster must explicitly dial a service in another Kubernetes cluster using the [consul.hashicorp.com/connect-service-upstreams](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation. An example would be
`"consul.hashicorp.com/connect-service-upstreams": "my-service:1234"`, where `my-service` is the service that exists in another Kubernetes cluster and is exposed on port `1234`. Although Transparent Proxy is enabled, KubeDNS is not utilized when communicating between services existing on separate Kubernetes clusters.
* When dialing headless services the request will be proxied using a plain TCP proxy with a 5s connection timeout.
Currently the upstream's protocol and connection timeout are not considered.

2
website/content/docs/enterprise/audit-logging.mdx
View File

@ -25,7 +25,7 @@ For more experience leveraging Consul's audit logging functionality, explore our
HashiCorp Learn tutorial [Capture Consul Events with Audit Logging](https://learn.hashicorp.com/tutorials/consul/audit-logging).
For detailed configuration information on configuring the Consul Enterprise's audit
logging, review the Consul [Audit Log](https://www.consul.io/docs/agent/options#audit)
logging, review the Consul [Audit Log](/docs/agent/options#audit)
documentation.
## Example Configuration

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

@ -35,7 +35,7 @@ Please visit the [Enterprise License Tutorial](https://learn.hashicorp.com/tutor
The list below is a great starting point for learning more about the license changes introduced in Consul Enterprise 1.10.0+ent.
- [Consul Enterprise Upgrade Documentation](https://www.consul.io/docs/enterprise/upgrades)
- [Consul Enterprise Upgrade Documentation](/docs/enterprise/upgrades)
- [Consul License Documentation](/docs/enterprise/license/overview)
@ -90,7 +90,7 @@ Consul snapshot agents will attempt to retrieve the license from servers if cert
## Q: Where can users get a trial license for Consul Enterprise?
Visit https://www.consul.io/trial for a free 30-day trial license.
Visit [consul.io/trial](/trial) for a free 30-day trial license.
## Q: Are the license files locked to a specific cluster?

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

@ -85,7 +85,7 @@ operations they can perform.
Consul uses Access Control Lists (ACLs) to secure the UI, API, CLI, service
communications, and agent communications.
Visit [Consul ACL Documentation and Guides](https://www.consul.io/docs/acl)
Visit [Consul ACL Documentation and Guides](/docs/security/acl)
## API Gateway
An Application Programming Interface (API) is a common software interface that

2
website/content/docs/integrate/partnerships.mdx
View File

@ -33,7 +33,7 @@ By leveraging Consul’s RESTful HTTP API system, prospective partners are able
**Infrastructure**: There are two integration options in this category: natively through a direct integration with Consul or via Consul-Terraform-Sync (CTS). By leveraging Consul’s powerful **Network Infrastructure Automation (NIA)*** capabilities through CTS, changes in an infrastructure are seamlessly automated when Consul detects a change in its service catalog. For example, these integrations could be used to automate IP updates of load balancers or firewall security policies by leveraging Consul service discovery.
-> **Network Infrastructure Automation (NIA)***: These integrations leverage Consul’s service catalog to seamlessly integrate with Consul-Terraform-Sync (CTS) to automate changes in network infrastructure via a publisher-subscriber method. More details can be found [here](https://www.consul.io/docs/integrate/nia-integration).
-> **Network Infrastructure Automation (NIA)***: These integrations leverage Consul’s service catalog to seamlessly integrate with Consul-Terraform-Sync (CTS) to automate changes in network infrastructure via a publisher-subscriber method. More details can be found [here](/docs/integrate/nia-integration).
## Development Process

2
website/content/docs/k8s/installation/compatibility.mdx
View File

@ -33,7 +33,7 @@ Prior to Consul Kubernetes 0.33.0, a separately versioned Consul Helm chart was
## Supported Envoy versions
Supported versions of Envoy for Consul versions are also found in [Envoy - Supported Versions](https://www.consul.io/docs/connect/proxies/envoy#supported-versions). The recommended best practice is to use the default version of Envoy that is provided in the Helm values.yml file, as that is the version that has been tested with the default Consul and Consul Kubernetes binaries for a given Helm chart.
Supported versions of Envoy for Consul versions are also found in [Envoy - Supported Versions](/docs/connect/proxies/envoy#supported-versions). The recommended best practice is to use the default version of Envoy that is provided in the Helm values.yml file, as that is the version that has been tested with the default Consul and Consul Kubernetes binaries for a given Helm chart.
## Red Hat OpenShift compatability

6
website/content/docs/k8s/installation/deployment-configurations/single-dc-multi-k8s.mdx
View File

@ -169,7 +169,7 @@ the value of `cluster.server` for the second cluster.
Lastly, we need to set up the clients so that they can discover the servers in the first cluster.
For this, we will use Consul's cloud auto-join feature
for the [Kubernetes provider](https://www.consul.io/docs/install/cloud-auto-join#kubernetes-k8s).
for the [Kubernetes provider](/docs/install/cloud-auto-join#kubernetes-k8s).
To use it we need to provide a way for the Consul clients to reach the first Kubernetes cluster.
To do that, we need to save the `kubeconfig` for the first cluster as a Kubernetes secret in the second cluster
and reference it in the `clients.join` value. Note that we're making that secret available to the client pods
@ -177,7 +177,7 @@ by setting it in `client.extraVolumes`.
~> **Note:** The kubeconfig you're providing to the client should have minimal permissions.
The cloud auto-join provider will only need permission to read pods.
Please see [Kubernetes Cloud auto-join](https://www.consul.io/docs/install/cloud-auto-join#kubernetes-k8s)
Please see [Kubernetes Cloud auto-join](/docs/install/cloud-auto-join#kubernetes-k8s)
for more details.
Now we're ready to install!
@ -188,7 +188,7 @@ $ helm install cluster2 --values cluster2-config.yaml hashicorp/consul
## Verifying the Consul Service Mesh works
~> When Transparent proxy is enabled, services in one Kubernetes cluster that need to communicate with a service in another Kubernetes cluster must have a explicit upstream configured through the ["consul.hashicorp.com/connect-service-upstreams"](https://www.consul.io/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation.
~> When Transparent proxy is enabled, services in one Kubernetes cluster that need to communicate with a service in another Kubernetes cluster must have a explicit upstream configured through the ["consul.hashicorp.com/connect-service-upstreams"](/docs/k8s/connect#consul-hashicorp-com-connect-service-upstreams) annotation.
Now that we have our Consul cluster in multiple k8s clusters up and running, we will
deploy two services and verify that they can connect to each other.

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

@ -63,7 +63,7 @@ The following sections detail how to export this data.
==> Saved vm-dc-server-consul-0-key.pem
```
-> Note the `-node` option in the above command. This should be same as the node name of the [Consul Agent](https://www.consul.io/docs/agent#running-an-agent). This is a [requirement](https://www.consul.io/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways#tls) for Consul Federation to work. Alternatively, if you plan to use the same certificate and key pair on all your Consul server nodes, or you don't know the nodename in advance, use `-node "*"` instead.
-> Note the `-node` option in the above command. This should be same as the node name of the [Consul Agent](/docs/agent#running-an-agent). This is a [requirement](/docs/connect/gateways/mesh-gateway/wan-federation-via-mesh-gateways#tls) for Consul Federation to work. Alternatively, if you plan to use the same certificate and key pair on all your Consul server nodes, or you don't know the nodename in advance, use `-node "*"` instead.
Not satisfying this requirement would result in the following error in the Consul Server logs:
`[ERROR] agent.server.rpc: TLS handshake failed: conn=from= error="remote error: tls: bad certificate"`

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

@ -60,7 +60,7 @@ $ vault secrets enable -path=consul kv-v2
### Vault PKI Engine
The Vault PKI Engine must be enabled in order to leverage Vault for issuiing Consul Server TLS certificates. More details for configuring the PKI Engine is found in [Bootstrapping the PKI Engine](https://www.consul.io/docs/k8s/installation/vault/server-tls#bootstrapping-the-pki-engine) under the Server TLS section.
The Vault PKI Engine must be enabled in order to leverage Vault for issuiing Consul Server TLS certificates. More details for configuring the PKI Engine is found in [Bootstrapping the PKI Engine](/docs/k8s/installation/vault/server-tls#bootstrapping-the-pki-engine) under the Server TLS section.
```shell-session
$ vault secrets enable pki

2
website/content/docs/k8s/operations/gossip-encryption-key-rotation.mdx
View File

@ -8,7 +8,7 @@ description: Rotate the Gossip Encryption Key on Kubernetes Cluster safely
The following instructions provides a step-by-step manual process for rotating [gossip encryption](/docs/security/encryption#gossip-encryption) keys on Consul clusters that are deployed onto a Kubernetes cluster with Consul on Kubernetes.
The following steps should only be performed in the *primary datacenter* if your Consul clusters are [federated](https://www.consul.io/docs/k8s/installation/multi-cluster/kubernetes). Rotating the gossip encryption in the primary datacenter will automatically rotate the gossip encryption in the secondary datacenters.
The following steps should only be performed in the *primary datacenter* if your Consul clusters are [federated](/docs/k8s/installation/multi-cluster/kubernetes). Rotating the gossip encryption in the primary datacenter will automatically rotate the gossip encryption in the secondary datacenters.
-> **Note:** Careful precaution should be taken to prohibit new clients from joining during the gossip encryption rotation process, otherwise the new clients will join the gossip pool without knowledge of the new primary gossip encryption key. In addition, deletion of a gossip encryption key from the keyring should occur only after clients have safely migrated to utilizing the new gossip encryption key for communication.

2
website/content/docs/nia/configuration.mdx
View File

@ -98,7 +98,7 @@ consul {
- `max_idle_conns` - (int: 0) The maximum number of total idle connections across all hosts. The limit is disabled by default.
- `max_idle_conns_per_host` - (int: 100) The maximum number of idle connections per remote host. The majority of connections are established with one host, the Consul agent.
- To achieve the shortest latency between a Consul service update to a task execution, configure `max_idle_conns_per_host` equal to or greater than the number of services in automation across all tasks.
- This value should be lower than the configured [`http_max_conns_per_client`](https://www.consul.io/docs/agent/options#http_max_conns_per_client) for the Consul agent. If `max_idle_conns_per_host` and the number of services in automation is greater than the Consul agent limit, Consul-Terraform-Sync may error due to connection limits (status code 429). You may increase the agent limit with caution. _Note: requests to the Consul agent made by Terraform subprocesses or any other process on the same host as Consul-Terraform-Sync will contribute to the Consul agent connection limit._
- This value should be lower than the configured [`http_max_conns_per_client`](/docs/agent/options#http_max_conns_per_client) for the Consul agent. If `max_idle_conns_per_host` and the number of services in automation is greater than the Consul agent limit, Consul-Terraform-Sync may error due to connection limits (status code 429). You may increase the agent limit with caution. _Note: requests to the Consul agent made by Terraform subprocesses or any other process on the same host as Consul-Terraform-Sync will contribute to the Consul agent connection limit._
- `tls_handshake_timeout` - (string: "10s") amount of time to wait to complete the TLS handshake.
## Service

2
website/content/docs/nia/installation/requirements.mdx
View File

@ -56,7 +56,7 @@ $ curl --request PUT --data @payload.json http://localhost:8500/v1/agent/service
The above example registers a service named "web" with your Consul agent. This represents a non-existent web service running at 10.10.10.10:8000. Your web service is now available for Consul-Terraform-Sync to consume. In Consul-Terraform-Sync, you can optionally configure the web service with a [service block](/docs/nia/configuration#service) if it has any non-default values. You can also have Consul-Terraform-Sync monitor the web service to execute a task and update network device(s) by configuring "web" in [`task.services`](/docs/nia/configuration#services) of a task block.
For more details on registering a service by HTTP API request, refer to the [register service API docs](https://www.consul.io/api-docs/agent/service#register-service).
For more details on registering a service by HTTP API request, refer to the [register service API docs](/api-docs/agent/service#register-service).
For more details on registering a service by loading a service definition, refer to the [Getting Started: Register a Service with Consul Service Discovery Tutorial](https://learn.hashicorp.com/tutorials/consul/get-started-service-discovery?in=consul/getting-started).

2
website/content/docs/release-notes/1-10-0.mdx
View File

@ -22,4 +22,4 @@ page_title: 1.10.0
- Drops support for Envoy version 1.13.x.
- (Enterprise Only) Consul Enterprise has removed support for temporary licensing. All server agents must have a valid license at startup and client agents must have a license at startup or be able to retrieve one from the servers.
For more detailed information, please refer to the [upgrade details page](https://www.consul.io/docs/upgrading/upgrade-specific#consul-1-10-0) and the [1.10.0 changelog](https://github.com/hashicorp/consul/releases/tag/v1.10.0).
For more detailed information, please refer to the [upgrade details page](/docs/upgrading/upgrade-specific#consul-1-10-0) and the [1.10.0 changelog](https://github.com/hashicorp/consul/releases/tag/v1.10.0).

2
website/content/docs/release-notes/1-9-0.mdx
View File

@ -21,7 +21,7 @@ page_title: 1.9.0
- **Active Health Checks for Consul on Kubernetes:** Consul service mesh now integrates with Kubernetes Readiness probes. This provides the ability to natively detect health status from Kubernetes via Readiness probe, and is then used for directing service mesh traffic.
- **Streaming:** This feature introduces a major architectural enhancement in how update notifications for blocking queries are delivered within the cluster. Streaming results in very significant reduction of CPU and network bandwidth usage on Consul servers in large-scale deployments. Streaming is particularly helpful in scaling blocking queries in Consul clusters that have rapid changes in service state.
- Streaming is now available for the service health HTTP endpoint, and can be enabled through the [`use_streaming_backend`](https://www.consul.io/docs/agent/options#use_streaming_backend) client configuration option, and [`rpc.enable_streaming`](https://www.consul.io/docs/agent/options#rpc_enable_streaming) option on the servers. We will continue to enable streaming in more endpoints in subsequent releases.
- Streaming is now available for the service health HTTP endpoint, and can be enabled through the [`use_streaming_backend`](/docs/agent/options#use_streaming_backend) client configuration option, and [`rpc.enable_streaming`](/docs/agent/options#rpc_enable_streaming) option on the servers. We will continue to enable streaming in more endpoints in subsequent releases.
## What's Changed

2
website/content/docs/security/acl/acl-federated-datacenters.mdx
View File

@ -164,7 +164,7 @@ production environments, consider configuring ACL replication in your initial
datacenter bootstrapping process.
~> **Warning:** If you are using [Consul Enterprise](/docs/enterprise) and
the [Admin Partitions](https://www.consul.io/docs/enterprise/admin-partitions)
the [Admin Partitions](/docs/enterprise/admin-partitions)
feature, only ACL tokens in the default partition are replicated to other datacenters.
## WAN Join Servers

4
website/content/docs/security/acl/acl-system.mdx
View File

@ -69,7 +69,7 @@ If the ACL system becomes inoperable, you can follow the
### ACL Policies
An ACL policy (not to be confused with [policy dispositions](/docs/security/acl/acl-rules#policy-dispositions)) is a named set of rules and several attributes that define the policy domain. The ID is generated when the policy is created, but you can specify the attributes when creating the policy. Refer to the [ACL policy command line](https://www.consul.io/commands/acl/policy) documentation or [ACL policy API](/api-docs/acl/policies) documentation for additional information on how to create policies.
An ACL policy (not to be confused with [policy dispositions](/docs/security/acl/acl-rules#policy-dispositions)) is a named set of rules and several attributes that define the policy domain. The ID is generated when the policy is created, but you can specify the attributes when creating the policy. Refer to the [ACL policy command line](/commands/acl/policy) documentation or [ACL policy API](/api-docs/acl/policies) documentation for additional information on how to create policies.
ACL policies can have the following attributes:
@ -219,7 +219,7 @@ of the following elements:
### ACL Tokens
Consul uses ACL tokens to determine if the caller is authorized to perform an action. An ACL token is composed of several attributes that you can specify when creating the token. Refer to the [ACL token command line](https://www.consul.io/commands/acl/token) documentation or [ACL token API](/api-docs/acl/tokens) documentation for additional information on how to create tokens.:
Consul uses ACL tokens to determine if the caller is authorized to perform an action. An ACL token is composed of several attributes that you can specify when creating the token. Refer to the [ACL token command line](/commands/acl/token) documentation or [ACL token API](/api-docs/acl/tokens) documentation for additional information on how to create tokens.:
- **Accessor ID** - The token's public identifier.
- **Secret ID** -The bearer token used when making requests to Consul.

4
website/content/docs/security/security-models/core.mdx
View File

@ -235,7 +235,7 @@ environment and adapt these configurations accordingly.
- **Customize HTTP Response Headers** - Additional security headers, such as
[`X-XSS-Protection`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection), can be
[configured](https://www.consul.io/docs/agent/options#response_headers) for HTTP API responses.
[configured](/docs/agent/options#response_headers) for HTTP API responses.
```hcl
http_config {
@ -411,6 +411,6 @@ The following are not part of the threat model for client agents:
- **Gateways** - Consul supports a variety of [gateways](/docs/connect/gateways) to allow traffic in-and-out of the
service mesh to support a variety of workloads. When using an internet-exposed gateway, you should be sure to harden
your Consul agent and host configurations. In most configurations, ACLS, gossip encryption, and mTLS should be
enforced. If an [escape hatch override](https://www.consul.io/docs/connect/proxies/envoy#escape-hatch-overrides) is
enforced. If an [escape hatch override](/docs/connect/proxies/envoy#escape-hatch-overrides) is
required, the proxy configuration should be audited to ensure security configurations remain intact, and do not
violate Consul’s security model.

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

@ -25,7 +25,7 @@ For upgrades we strive to ensure backwards compatibility. To support this,
nodes gossip their protocol version and builds. This enables clients and
servers to intelligently enable new features when available, or to gracefully
fallback to a backward compatible mode of operation otherwise.
Visit the [General Upgrade Process](https://www.consul.io/docs/upgrading/instructions/general-process) for a detailed upgrade guide.
Visit the [General Upgrade Process](/docs/upgrading/instructions/general-process) for a detailed upgrade guide.
For most upgrades, the process is simple. Assuming the current version of
Consul is A, and version B is released.

4
website/content/docs/upgrading/instructions/general-process.mdx
View File

@ -71,8 +71,8 @@ Version 1
This will ensure you have a safe fallback option in case something goes wrong. Store
this snapshot somewhere safe. More documentation on snapshot usage is available here:
- https://www.consul.io/commands/snapshot
- https://learn.hashicorp.com/tutorials/consul/backup-and-restore
- [consul.io/commands/snapshot](/commands/snapshot)
- <https://learn.hashicorp.com/tutorials/consul/backup-and-restore>
**2.** Temporarily modify your Consul configuration so that its [log_level](/docs/agent/options#_log_level)
is set to `debug`. After doing this, issue the following command on your servers to

2
website/content/docs/upgrading/instructions/upgrade-to-1-2-x.mdx
View File

@ -120,7 +120,7 @@ moving to newer versions.
The full list of changes is available here:
- https://www.consul.io/docs/upgrading/upgrade-specific#deprecated-options-have-been-removed
- [Upgrade Specific Versions: Consul 1.0 - Deprecated Options](/docs/upgrading/upgrade-specific#deprecated-options-have-been-removed)
You can make sure your config changes are valid by copying your existing configuration files,
making the changes, and then verifying them by using `consul validate $CONFIG_FILE1_PATH $CONFIG_FILE2_PATH ...`.

12
website/content/docs/upgrading/instructions/upgrade-to-1-6-x.mdx
View File

@ -18,9 +18,9 @@ as part of this upgrade. The 1.6.x series is the last series that had support fo
ACL tokens, so this migration _must_ happen before upgrading past the 1.6.x release series.
Here is some documentation that may prove useful for reference during this upgrade process:
- [ACL System in Legacy Mode](https://www.consul.io/docs/acl/acl-legacy) - You can find
- [ACL System in Legacy Mode](/docs/security/acl/acl-legacy) - You can find
information about legacy configuration options and differences between modes here.
- [Configuration](https://www.consul.io/docs/agent/options) - You can find more details
- [Configuration](/docs/agent/options) - You can find more details
around legacy ACL and new ACL configuration options here. Legacy ACL config options
will be listed as deprecates as of 1.4.0.
@ -51,7 +51,7 @@ Looking through these changes prior to upgrading is highly recommended.
Two very notable items are:
- 1.6.2 introduced more strict JSON decoding. Invalid JSON that was previously ignored might result in errors now (e.g., `Connect: null` in service definitions). See [[GH#6680](https://github.com/hashicorp/consul/pull/6680)].
- 1.6.3 introduced the [http_max_conns_per_client](https://www.consul.io/docs/agent/options#http_max_conns_per_client) limit. This defaults to 200. Prior to this, connections per client were unbounded. [[GH#7159](https://github.com/hashicorp/consul/issues/7159)]
- 1.6.3 introduced the [http_max_conns_per_client](/docs/agent/options#http_max_conns_per_client) limit. This defaults to 200. Prior to this, connections per client were unbounded. [[GH#7159](https://github.com/hashicorp/consul/issues/7159)]
## Procedure
@ -189,7 +189,7 @@ You should receive output similar to this:
}
```
**6.** Migrate your legacy ACL tokens to the new ACL system by following the instructions in our [ACL Token Migration guide](https://www.consul.io/docs/acl/acl-migrate-tokens).
**6.** Migrate your legacy ACL tokens to the new ACL system by following the instructions in our [ACL Token Migration guide](/docs/security/acl/acl-migrate-tokens).
~> This step _must_ be completed before upgrading to a version higher than 1.6.x.
@ -202,8 +202,8 @@ update those now to avoid issues when moving to newer versions.
These are the changes you will need to make:
- `acl_datacenter` is now named `primary_datacenter` (review our [docs](https://www.consul.io/docs/agent/options#primary_datacenter) for more info)
- `acl_default_policy`, `acl_down_policy`, `acl_ttl`, `acl_*_token` and `enable_acl_replication` options are now specified like this (review our [docs](https://www.consul.io/docs/agent/options#acl) for more info):
- `acl_datacenter` is now named `primary_datacenter` (review our [docs](/docs/agent/options#primary_datacenter) for more info)
- `acl_default_policy`, `acl_down_policy`, `acl_ttl`, `acl_*_token` and `enable_acl_replication` options are now specified like this (review our [docs](/docs/agent/options#acl) for more info):
```hcl
acl {
enabled = true/false