From bca0e557708f2a914c920706bc841e36df228e9c Mon Sep 17 00:00:00 2001 From: Ryan Breen Date: Fri, 27 Feb 2015 19:00:13 -0500 Subject: [PATCH] Website: Cleanup for docs/guides/external.html. --- .../docs/guides/datacenters.html.markdown | 4 +- .../source/docs/guides/external.html.markdown | 39 +++++++++++-------- 2 files changed, 24 insertions(+), 19 deletions(-) diff --git a/website/source/docs/guides/datacenters.html.markdown b/website/source/docs/guides/datacenters.html.markdown index 146e3cfe0e..595e55c1b5 100644 --- a/website/source/docs/guides/datacenters.html.markdown +++ b/website/source/docs/guides/datacenters.html.markdown @@ -3,14 +3,14 @@ layout: "docs" page_title: "Multiple Datacenters" sidebar_current: "docs-guides-datacenters" description: |- - 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). diff --git a/website/source/docs/guides/external.html.markdown b/website/source/docs/guides/external.html.markdown index 64cbfa274e..3e190be8d3 100644 --- a/website/source/docs/guides/external.html.markdown +++ b/website/source/docs/guides/external.html.markdown @@ -3,29 +3,33 @@ layout: "docs" page_title: "External Services" sidebar_current: "docs-guides-external" description: |- - 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: ```text -$ curl -X PUT -d '{"Datacenter": "dc1", "Node": "google", "Address": "www.google.com", -"Service": {"Service": "search", "Port": 80}}' http://127.0.0.1:8500/v1/catalog/register +$ curl -X PUT -d '{"Datacenter": "dc1", "Node": "google", + "Address": "www.google.com", + "Service": {"Service": "search", "Port": 80}}' + http://127.0.0.1:8500/v1/catalog/register ``` If we do a DNS lookup now, we can see the new search service: @@ -53,11 +57,12 @@ www.google.com. 264 IN A 74.125.239.116 ;; MSG SIZE rcvd: 178 ``` -If at any time we want to deregister the service, we can simply do: +If at any time we want to deregister the service, we simply do: ```text $ curl -X PUT -d '{"Datacenter": "dc1", "Node": "google"}' http://127.0.0.1:8500/v1/catalog/deregister ``` -This will deregister the `google` node, along with all services it provides. -To learn more, read about the [HTTP API](/docs/agent/http.html). +This will deregister the `google` node along with all services it provides. + +For more information, please see the [HTTP Catalog API](/docs/agent/http/catalog.html).