One of the key features of Consul is its support for multiple datacenters. The architecture of Consul is designed to promote a low-coupling of datacenters, so that connectivity issues or failure of any datacenter does not impact the availability of Consul in other regions. This means each datacenter runs independently, with a dedicated group of servers and a private LAN gossip pool.
One of the key features of Consul is its support for multiple datacenters. The architecture of Consul is designed to promote a low-coupling of datacenters so that connectivity issues or failure of any datacenter does not impact the availability of Consul in other regions. This means each datacenter runs independently, with a dedicated group of servers and a private LAN gossip pool.
---
# Multi-Datacenter Deploys
One of the key features of Consul is its support for multiple datacenters.
The [architecture](/docs/internals/architecture.html) of Consul is designed to
promote a low-coupling of datacenters, so that connectivity issues or
promote a low-coupling of datacenters so that connectivity issues or
failure of any datacenter does not impact the availability of Consul in other
regions. This means each datacenter runs independently, with a dedicated
group of servers and a private LAN [gossip pool](/docs/internals/gossip.html).
Very few infrastructures are entirely self-contained, and often rely on a multitude of external service providers. Most services are registered in Consul through the use of a service definition, however that registers the local node as the service provider. In the case of external services, we want to register a service as being provided by an external provider.
Very few infrastructures are entirely self-contained. Most rely on a multitude of external service providers. Consul supports this by allowing for the definition of external services, services that are not provided by a local node.
---
# Registering an External Service
Very few infrastructures are entirely self-contained, and often rely on
a multitude of external service providers. Most services are registered
in Consul through the use of a [service definition](/docs/agent/services.html),
however that registers the local node as the service provider. In the case
of external services, we want to register a service as being provided by
an external provider.
Very few infrastructures are entirely self-contained. Most rely on a multitude
of external service providers. Consul supports this by allowing for the definition
of external services, services that are not provided by a local node.
Consul supports this, however it requires manually registering the service
with the catalog. Once registered, the DNS interface will be able to return
the appropriate A records or CNAME records for the service. The service will
also appear in standard queries against the API.
Most services are registered in Consul through the use of a
[service definition](/docs/agent/services.html). However, this approach registers
the local node as the service provider. In the case of external services, we must
instead register the service with the catalog rather than as part of a standard
node service definition.
Once registered, the DNS interface will be able to return the appropriate A
records or CNAME records for the service. The service will also appear in standard
queries against the API.
Let us suppose we want to register a "search" service that is provided by
"www.google.com", we could do the following:
"www.google.com". We might accomplish that like so:
Ryan Breen
10 years ago