我的书签
添加书签
移除书签Configuration
One difference is that instead of routes you specify gateways. As expected self-gateway connections are ignored, so you can share gateway configurations with minimal fuss.
Once all the gateways are up, these clusters of one will forward messages as expected:
| Property | Description |
|---|---|
name |
Gateway name. |
url |
Hostport <host>:<port> describing where the remote gateway can be reached. If multiple IPs are returned, one is randomly selected. |
urls |
A list of url strings. |
tls |
A tls configuration map for creating a secure gateway connection. If the top-level gateway{} tls block contains certificates that have both client and server purposes, it is possible to omit this one and the server will use the certificates from the gateway{tls{}} section. See additional advice below in TLS Entry. |
By using urls and an array, you can specify a list of endpoints that form part of a cluster as below. A NATS Server will pick one of those addresses randomly and only establish a single outbound gateway connection to one of the members from another cluster:
TLS Entry
If using a certificate bundle which accompanied the issuance of a certificate then the CA in that bundle will typically be for just that certificate. Using only that CA as the CA for gateway authentication is ill-advised. You should ensure that you allow for rolling between Certificate Authorities, even if only between multiple CAs from the same organization entity, and use a separate certificate bundle for verification of peers. This way when DC-B rolls before DC-A, it will not be cut off from your supercluster.
