mirror of https://github.com/status-im/consul.git
Create and Manage Peering Connections additional fixes
This commit is contained in:
parent
ebe0f5408d
commit
61f60ceb4f
|
@ -30,16 +30,16 @@ In “cluster-01,” run the ``generate-token`` command.
|
|||
$ consul peering generate-token -peer="cluster-02"
|
||||
```
|
||||
|
||||
The CLI outputs the peering token, which is a string of alphanumeric characters and symbols.
|
||||
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 cluster’s exact name in the ``peer`` parameter.
|
||||
|
||||
## Establish a connection between clusters
|
||||
|
||||
Next, use the peering token to establish a secure connection between the clusters. In the client agents of “cluster-02,” run the ``peering initiate`` command. This command does not generate an output.
|
||||
Next, use the peering token to establish a secure connection between the clusters. In the client agents of “cluster-02,” run the ``peering establish`` command. This command does not generate an output.
|
||||
|
||||
```shell-session
|
||||
$ consul peering initiate -peer="cluster-01" -token="eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1ZCI6IlNvbHIifQ.5T7L_L1MPfQ_5FjKGa1fTPqrzwK4bNSM812nW6oyjb8"
|
||||
$ consul peering establish -peer="cluster-01" -token="eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1ZCI6IlNvbHIifQ.5T7L_L1MPfQ_5FjKGa1fTPqrzwK4bNSM812nW6oyjb8"
|
||||
```
|
||||
|
||||
In the peer parameter, specify the first cluster’s exact name. The ``token`` parameter should include the entire peering token created in the first cluster.
|
||||
|
@ -48,7 +48,7 @@ When you connect server agents through cluster peering, they will peer through t
|
|||
|
||||
## 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, queries, and key/value stores available to peered clusters.
|
||||
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”``.
|
||||
|
||||
|
@ -84,39 +84,22 @@ $ consul config write peering-config.hcl
|
|||
|
||||
Before you proceed, wait for the clusters to sync and make services available to their peers
|
||||
|
||||
### Check peering connection status
|
||||
|
||||
To find issues blocking the cluster peering, you can call the ``/health/service`` HTTP endpoint.
|
||||
|
||||
```shell-session
|
||||
$ curl \
|
||||
http://127.0.0.1:8500/v1/health/service/service-name?peer=cluster-01
|
||||
```
|
||||
|
||||
You can also check the status of the data replication to the peer cluster.
|
||||
```shell-session
|
||||
$ curl \
|
||||
http://127.0.0.1:8500/v1/peering/cluster-01
|
||||
```
|
||||
|
||||
If the cluster peering process is successful, the output returns both ``"status": "active"`` and ``"connected": true``.
|
||||
|
||||
## Authorize connections from peers
|
||||
|
||||
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”``.
|
||||
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">
|
||||
|
||||
```shell-session
|
||||
Kind = "service-intentions"
|
||||
Name = "service-name"
|
||||
Name = "frontend-service"
|
||||
Partition = "partition-name"
|
||||
|
||||
Sources = [
|
||||
{
|
||||
Name = "orders"
|
||||
Name = "backend-service"
|
||||
Peer = "cluster-02"
|
||||
Action = "allow"
|
||||
}
|
||||
|
@ -133,6 +116,17 @@ Then, add the configuration entry to your cluster.
|
|||
$ 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.
|
||||
|
||||
```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.
|
||||
|
||||
## 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.
|
||||
|
|
Loading…
Reference in New Issue