Fixing double-ticks `

pull/13448/head
Jeff Boruszak 2 years ago committed by GitHub
parent c39bf49eab
commit fb916e999b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -24,7 +24,7 @@ You can generate peering tokens and initiate connections from either the server
To begin the cluster peering process, generate a peering token in one of your clusters. The other cluster uses this token to establish the peering connection.
In “cluster-01,” run the ``generate-token`` command.
In “cluster-01,” run the `generate-token` command.
```shell-session
$ consul peering generate-token -peer="cluster-02"
@ -32,7 +32,7 @@ $ consul peering generate-token -peer="cluster-02"
The CLI outputs the peering token, which is an encoded string of alphanumeric characters and symbols.
For the peering token to function correctly, you must enter the second clusters exact name in the ``peer`` parameter.
For the peering token to function correctly, you must enter the second clusters exact name in the `peer` parameter.
## Establish a connection between clusters
@ -42,15 +42,15 @@ Next, use the peering token to establish a secure connection between the cluster
$ consul peering establish -peer="cluster-01" -token="eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1ZCI6IlNvbHIifQ.5T7L_L1MPfQ_5FjKGa1fTPqrzwK4bNSM812nW6oyjb8"
```
In the peer parameter, specify the first clusters exact name. The ``token`` parameter should include the entire peering token created in the first cluster.
In the peer parameter, specify the first clusters exact name. The `token` parameter should include the entire peering token created in the first cluster.
When you connect server agents through cluster peering, they will peer through their default partitions. To connect other partitions through server agents, you must specify the partitions you want to peer using the ``partition`` parameter.
When you connect server agents through cluster peering, they will peer through their default partitions. To connect other partitions through server agents, you must specify the partitions you want to peer using the `partition` parameter.
## Connect service endpoints
After you establish a connection between the clusters, you need to create a configuration entry that defines the services that are available for other clusters. Consul uses this configuration entry to make services and support queries for service mesh available to peered clusters.
First, create a configuration entry and specify the ``Kind`` as ``“exported-services”``.
First, create a configuration entry and specify the `Kind` as `“exported-services”`.
<CodeBlockConfig filename="peering-config.hcl">
@ -88,7 +88,7 @@ Before you proceed, wait for the clusters to sync and make services available to
Before you can call services from peered clusters, you must set service intentions that authorize those clusters to use specific services. Consul prevents services from being exported to unauthorized clusters.
First, create a configuration entry and specify the ``Kind`` as ``“service-intentions”``. Declare the service on "cluster-02" that can access the service in "cluster-01." The following example sets service intentions so that "backend-service" can access "frontend-service."
First, create a configuration entry and specify the `Kind` as `“service-intentions”`. Declare the service on "cluster-02" that can access the service in "cluster-01." The following example sets service intentions so that "backend-service" can access "frontend-service."
<CodeBlockConfig filename="peering-intentions.hcl">
@ -108,7 +108,7 @@ Sources = [
</CodeBlockConfig>
**Tip:** If the peers name is not specified in ``Peer``, then Consul assumes that the service is in the local cluster.
**Tip:** If the peers name is not specified in `Peer`, then Consul assumes that the service is in the local cluster.
Then, add the configuration entry to your cluster.
@ -118,20 +118,20 @@ $ consul config write peering-intentions.hcl
## Check peered cluster status
To confirm that you peered your clusters, you can [query the ``/health/service`` endpoint](https://www.consul.io/api-docs/health) of one cluster from the other cluster. For example, in "cluster-02," query the endpoint and add the ``peer=cluster-01`` parameter to the end of the URL.
To confirm that you peered your clusters, you can [query the `/health/service` endpoint](https://www.consul.io/api-docs/health) of one cluster from the other cluster. For example, in "cluster-02," query the endpoint and add the `peer=cluster-01` parameter to the end of the URL.
```shell-session
$ curl \
http://127.0.0.1:8500/v1/health/service/service-name?peer=cluster-01
```
Successful connections include ``"Status": "passing"`` in the output.
Successful connections include `"Status": "passing"` in the output.
## Remove peering connections
After you create a peering connection between clusters in different datacenters, you can “unpeer” the connected clusters. Deleting a peering connection stops data replication to the peer and deletes imported data, including services and CA certificates.
In “cluster-01,” run the ``peering delete`` command.
In “cluster-01,” run the `peering delete` command.
```shell-session
$ consul peering delete -peer="cluster-02"

Loading…
Cancel
Save