From a7d945e7b9522216fdec397be7c3faece2a1c40d Mon Sep 17 00:00:00 2001 From: Matt Keeler Date: Tue, 17 Nov 2020 10:03:00 -0500 Subject: [PATCH] [docs] Change links to the DNS information to the right place (#8675) The redirects were working in many situations but some (INTERNALS.md) was not. This just flips everything over to using the real link. --- contributing/INTERNALS.md | 2 +- website/pages/api-docs/query.mdx | 2 +- website/pages/docs/agent/config-entries/ingress-gateway.mdx | 2 +- website/pages/docs/agent/options.mdx | 2 +- website/pages/docs/connect/gateways/ingress-gateway.mdx | 4 ++-- website/pages/docs/connect/native/index.mdx | 2 +- website/pages/docs/connect/proxies/index.mdx | 2 +- website/pages/docs/connect/proxies/managed-deprecated.mdx | 2 +- website/pages/docs/discovery/services.mdx | 2 +- website/pages/docs/k8s/dns.mdx | 2 +- website/pages/docs/k8s/service-sync.mdx | 2 +- website/pages/intro/getting-started/agent.mdx | 2 +- 12 files changed, 13 insertions(+), 13 deletions(-) diff --git a/contributing/INTERNALS.md b/contributing/INTERNALS.md index cb1cbe4de..38fd01aaf 100644 --- a/contributing/INTERNALS.md +++ b/contributing/INTERNALS.md @@ -59,7 +59,7 @@ This section addresses some frequently asked questions about Consul's architectu ### How does eventually-consistent gossip relate to the Raft consensus protocol? -When you query Consul for information about a service, such as via the [DNS interface](https://www.consul.io/docs/agent/dns.html), the agent will always make an internal RPC request to a Consul server that will query the consistent state store. Even though an agent might learn that another agent is down via gossip, that won't be reflected in service discovery until the current Raft leader server perceives that through gossip and updates the catalog using Raft. You can see an example of where these layers are plumbed together here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/leader.go#L559-L602. +When you query Consul for information about a service, such as via the [DNS interface](https://www.consul.io/docs/discovery/dns), the agent will always make an internal RPC request to a Consul server that will query the consistent state store. Even though an agent might learn that another agent is down via gossip, that won't be reflected in service discovery until the current Raft leader server perceives that through gossip and updates the catalog using Raft. You can see an example of where these layers are plumbed together here - https://github.com/hashicorp/consul/blob/v1.0.5/agent/consul/leader.go#L559-L602. ## Why does a blocking query sometimes return with identical results? diff --git a/website/pages/api-docs/query.mdx b/website/pages/api-docs/query.mdx index c5a2c4c15..510324c4a 100644 --- a/website/pages/api-docs/query.mdx +++ b/website/pages/api-docs/query.mdx @@ -12,7 +12,7 @@ The `/query` endpoints create, update, destroy, and execute prepared queries. Prepared queries allow you to register a complex service query and then execute it later via its ID or name to get a set of healthy nodes that provide a given service. This is particularly useful in combination with Consul's -[DNS Interface](/docs/agent/dns) as it allows for much richer queries than +[DNS Interface](/docs/discovery/dns) as it allows for much richer queries than 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 diff --git a/website/pages/docs/agent/config-entries/ingress-gateway.mdx b/website/pages/docs/agent/config-entries/ingress-gateway.mdx index cfa06f7ab..aedf21d2b 100644 --- a/website/pages/docs/agent/config-entries/ingress-gateway.mdx +++ b/website/pages/docs/agent/config-entries/ingress-gateway.mdx @@ -38,7 +38,7 @@ gateway: - The ingress gateway will route traffic based on the host/authority header, expecting a value matching `.ingress.*`, or if using namespaces, `.ingress..*`. This matches the [Consul DNS - ingress subdomain](/docs/agent/dns#ingress-service-lookups). + ingress subdomain](/docs/discovery/dns#ingress-service-lookups). A wildcard specifier cannot be set on a listener of protocol `tcp`. diff --git a/website/pages/docs/agent/options.mdx b/website/pages/docs/agent/options.mdx index be74f6ad0..da8dba391 100644 --- a/website/pages/docs/agent/options.mdx +++ b/website/pages/docs/agent/options.mdx @@ -1452,7 +1452,7 @@ Valid time units are 'ns', 'us' (or 'µs'), 'ms', 's', 'm', 'h'." When set to true, in a DNS query for a service, the label between the domain and the `service` label will be treated as a namespace name instead of a datacenter. When set to false, the default, the behavior will be the same as non-Enterprise - versions and will assume the label is the datacenter. See: [this section](/docs/agent/dns#namespaced-services) + versions and will assume the label is the datacenter. See: [this section](/docs/discovery/dns#namespaced-services) for more details. - `domain` Equivalent to the [`-domain` command-line flag](#_domain). diff --git a/website/pages/docs/connect/gateways/ingress-gateway.mdx b/website/pages/docs/connect/gateways/ingress-gateway.mdx index 170a4f460..6c72c3d73 100644 --- a/website/pages/docs/connect/gateways/ingress-gateway.mdx +++ b/website/pages/docs/connect/gateways/ingress-gateway.mdx @@ -23,7 +23,7 @@ to a set of backing [services](/docs/agent/config-entries/ingress-gateway#services). To enable easier service discovery, a new Consul [DNS -subdomain](/docs/agent/dns#ingress-service-lookups) is provided, on +subdomain](/docs/discovery/dns#ingress-service-lookups) is provided, on `.ingress.`. For listeners with a @@ -32,7 +32,7 @@ For listeners with a case, the ingress gateway relies on host/authority headers to decide the service that should receive the traffic. The host used to match traffic defaults to the [Consul DNS ingress -subdomain](/docs/agent/dns#ingress-service-lookups), but can be changed using +subdomain](/docs/discovery/dns#ingress-service-lookups), but can be changed using the [hosts](/docs/agent/config-entries/ingress-gateway#hosts) field. ![Ingress Gateway Architecture](/img/ingress-gateways.png) diff --git a/website/pages/docs/connect/native/index.mdx b/website/pages/docs/connect/native/index.mdx index e4ad13414..5b0f0e049 100644 --- a/website/pages/docs/connect/native/index.mdx +++ b/website/pages/docs/connect/native/index.mdx @@ -52,7 +52,7 @@ Details on the steps are below: - **Service discovery** - This is normal service discovery using Consul, a static IP, or any other mechanism. If you're using Consul DNS, the - [`.connect`](/docs/agent/dns#connect-capable-service-lookups) + [`.connect`](/docs/discovery/dns#connect-capable-service-lookups) syntax to find Connect-capable endpoints for a service. After service discovery, choose one address from the list of **service addresses**. diff --git a/website/pages/docs/connect/proxies/index.mdx b/website/pages/docs/connect/proxies/index.mdx index 430c53609..874871fe8 100644 --- a/website/pages/docs/connect/proxies/index.mdx +++ b/website/pages/docs/connect/proxies/index.mdx @@ -32,7 +32,7 @@ switch service definitions for registering proxies. If an application requires dynamic dependencies that are only available at runtime, it must [natively integrate](/docs/connect/native) with Connect. After natively integrating, the HTTP API or -[DNS interface](/docs/agent/dns#connect-capable-service-lookups) +[DNS interface](/docs/discovery/dns#connect-capable-service-lookups) can be used. !> Connect proxies do not currently support dynamic upstreams. diff --git a/website/pages/docs/connect/proxies/managed-deprecated.mdx b/website/pages/docs/connect/proxies/managed-deprecated.mdx index 757b5171a..24348dd8c 100644 --- a/website/pages/docs/connect/proxies/managed-deprecated.mdx +++ b/website/pages/docs/connect/proxies/managed-deprecated.mdx @@ -119,7 +119,7 @@ default managed proxy and starts a listener for that service: The listener is started on random port within the configured Connect port range. It can be discovered using the -[DNS interface](/docs/agent/dns#connect-capable-service-lookups) +[DNS interface](/docs/discovery/dns#connect-capable-service-lookups) or [Catalog API](#). In most cases, service-to-service communication is established by diff --git a/website/pages/docs/discovery/services.mdx b/website/pages/docs/discovery/services.mdx index cb90f2abe..c1d01f5f2 100644 --- a/website/pages/docs/discovery/services.mdx +++ b/website/pages/docs/discovery/services.mdx @@ -355,7 +355,7 @@ services { ## Service and Tag Names with DNS -Consul exposes service definitions and tags over the [DNS](/docs/agent/dns) +Consul exposes service definitions and tags over the [DNS](/docs/discovery/dns) interface. DNS queries have a strict set of allowed characters and a well-defined format that Consul cannot override. While it is possible to register services or tags with names that don't match the conventions, those diff --git a/website/pages/docs/k8s/dns.mdx b/website/pages/docs/k8s/dns.mdx index 053ce3169..5bb1038d4 100644 --- a/website/pages/docs/k8s/dns.mdx +++ b/website/pages/docs/k8s/dns.mdx @@ -11,7 +11,7 @@ description: >- # Consul DNS on Kubernetes One of the primary query interfaces to Consul is the -[DNS interface](/docs/agent/dns). You can configure Consul DNS in +[DNS interface](/docs/discovery/dns). You can configure Consul DNS in Kubernetes using a [stub-domain configuration](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#configure-stub-domain-and-upstream-dns-servers) if using KubeDNS or a [proxy configuration](https://coredns.io/plugins/proxy/) if using CoreDNS. diff --git a/website/pages/docs/k8s/service-sync.mdx b/website/pages/docs/k8s/service-sync.mdx index 46ab6a8d9..092e18b79 100644 --- a/website/pages/docs/k8s/service-sync.mdx +++ b/website/pages/docs/k8s/service-sync.mdx @@ -21,7 +21,7 @@ automatically installed and configured using the Consul catalog enable Kubernetes services to be accessed by any node that is part of the Consul cluster, including other distinct Kubernetes clusters. For non-Kubernetes nodes, they can access services using the standard -[Consul DNS](/docs/agent/dns) or HTTP API. +[Consul DNS](/docs/discovery/dns) or HTTP API. **Why sync Consul services to Kubernetes?** Syncing Consul services to Kubernetes services enables non-Kubernetes services (such as external to diff --git a/website/pages/intro/getting-started/agent.mdx b/website/pages/intro/getting-started/agent.mdx index 2f9778830..42e3c8231 100644 --- a/website/pages/intro/getting-started/agent.mdx +++ b/website/pages/intro/getting-started/agent.mdx @@ -103,7 +103,7 @@ $ curl localhost:8500/v1/catalog/nodes [{"Node":"Armons-MacBook-Air","Address":"127.0.0.1","TaggedAddresses":{"lan":"127.0.0.1","wan":"127.0.0.1"},"CreateIndex":4,"ModifyIndex":110}] ``` -In addition to the HTTP API, the [DNS interface](/docs/agent/dns) can +In addition to the HTTP API, the [DNS interface](/docs/discovery/dns) can be used to query the node. Note that you have to make sure to point your DNS lookups to the Consul agent's DNS server which runs on port 8600 by default. The format of the DNS entries (such as "Armons-MacBook-Air.node.consul") will