diff --git a/website/source/docs/agent/basics.html.markdown b/website/source/docs/agent/basics.html.markdown index 502e96a888..3f7927ac23 100644 --- a/website/source/docs/agent/basics.html.markdown +++ b/website/source/docs/agent/basics.html.markdown @@ -124,11 +124,8 @@ In the case of a network failure, some nodes may be unreachable by other nodes. In this case, unreachable nodes are marked as _failed_. It is impossible to distinguish between a network failure and an agent crash, so both cases are handled the same. Once a node is marked as failed, this information is updated in the service catalog. -Note: there is some nuance here since this update is only possible if the servers can -still [form a quorum](/docs/internals/consensus.html). Once the network recovers -or a crashed agent restarts the cluster will repair itself and unmark -a node as failed. The health check in the catalog will also be updated to reflect -this. + +-> **Note:** There is some nuance here since this update is only possible if the servers can still [form a quorum](/docs/internals/consensus.html). Once the network recovers or a crashed agent restarts the cluster will repair itself and unmark a node as failed. The health check in the catalog will also be updated to reflect this. When a node _leaves_, it specifies its intent to do so, and the cluster marks that node as having _left_. Unlike the _failed_ case, all of the diff --git a/website/source/docs/agent/dns.html.markdown b/website/source/docs/agent/dns.html.markdown index e023a3d987..771c76c0f7 100644 --- a/website/source/docs/agent/dns.html.markdown +++ b/website/source/docs/agent/dns.html.markdown @@ -14,16 +14,16 @@ discovery without any high-touch integration with Consul. For example, instead of making HTTP API requests to Consul, a host can use the DNS server directly via name lookups -like "redis.service.east-aws.consul". This query automatically -translates to a lookup of nodes that provide the redis service, -are located in the "east-aws" datacenter, and have no failing health checks. +like `redis.service.us-east-1.consul`. This query automatically +translates to a lookup of nodes that provide the `redis` service, +are located in the `us-east-1` datacenter, and have no failing health checks. It's that simple! There are a number of configuration options that are important for the DNS interface, specifically [`client_addr`](/docs/agent/options.html#client_addr), [`ports.dns`](/docs/agent/options.html#dns_port), [`recursors`](/docs/agent/options.html#recursors), [`domain`](/docs/agent/options.html#domain), and [`dns_config`](/docs/agent/options.html#dns_config). -By default, Consul will listen on 127.0.0.1:8600 for DNS queries in the "consul." +By default, Consul will listen on 127.0.0.1:8600 for DNS queries in the `consul.` domain, without support for further DNS recursion. Please consult the [documentation on configuration options](/docs/agent/options.html), specifically the configuration items linked above, for more details. @@ -39,8 +39,7 @@ You can experiment with Consul's DNS server on the command line using tools such $ dig @127.0.0.1 -p 8600 redis.service.dc1.consul. ANY -Note that in DNS, all queries are case-insensitive. A lookup of `PostgreSQL.node.dc1.consul` -will find all nodes named `postgresql`. +-> **Note:** In DNS, all queries are case-insensitive. A lookup of `PostgreSQL.node.dc1.consul` will find all nodes named `postgresql`. ## Node Lookups @@ -50,15 +49,16 @@ A node lookup, a simple query for the address of a named node, looks like this: .node[.datacenter]. -For example, if we have a "foo" node with default settings, we could look for -"foo.node.dc1.consul." The datacenter is an optional part of the FQDN: if not -provided, it defaults to the datacenter of the agent. If we know "foo" is running in -the same datacenter as our local agent, we can instead use "foo.node.consul." This -convention allows for terse syntax where appropriate while supporting queries of -nodes in remote datacenters as necessary. +For example, if we have a `foo` node with default settings, we could +look for `foo.node.dc1.consul.` The datacenter is an optional part of +the FQDN: if not provided, it defaults to the datacenter of the agent. +If we know `foo` is running in the same datacenter as our local agent, +we can instead use `foo.node.consul.` This convention allows for terse +syntax where appropriate while supporting queries of nodes in remote +datacenters as necessary. -For a node lookup, the only records returned are A records containing the IP address of -the node. +For a node lookup, the only records returned are A records containing +the IP address of the node. ```text $ dig @127.0.0.1 -p 8600 foo.node.consul ANY @@ -92,13 +92,14 @@ The format of a standard service lookup is: [tag.].service[.datacenter]. -The `tag` is optional, and, as with node lookups, the `datacenter` is as well. If no tag is -provided, no filtering is done on tag. If no datacenter is provided, the datacenter of -this Consul agent is assumed. +The `tag` is optional, and, as with node lookups, the `datacenter` is as +well. If no tag is provided, no filtering is done on tag. If no +datacenter is provided, the datacenter of this Consul agent is assumed. -If we want to find any redis service providers in our local datacenter, we could query -"redis.service.consul." If we want to find the PostgreSQL master in a particular datacenter, -we could query "master.postgresql.service.dc2.consul." +If we want to find any redis service providers in our local datacenter, +we could query 1redis.service.consul.1 If we want to find the PostgreSQL +primary in a particular datacenter, we could query +`primary.postgresql.service.dc2.consul.` The DNS query system makes use of health check information to prevent routing to unhealthy nodes. When a service query is made, any services failing their health @@ -140,16 +141,16 @@ The format for RFC 2782 SRV lookups is: _._.service[.datacenter][.domain] Per [RFC 2782](https://tools.ietf.org/html/rfc2782), SRV queries should use -underscores (_) as a prefix to the `service` and `protocol` values in a query to +underscores, `_`, as a prefix to the `service` and `protocol` values in a query to prevent DNS collisions. The `protocol` value can be any of the tags for a -service. If the service has no tags, "tcp" should be used. If "tcp" +service. If the service has no tags, `tcp` should be used. If `tcp` is specified as the protocol, the query will not perform any tag filtering. -Other than the query format and default "tcp" protocol/tag value, the behavior +Other than the query format and default `tcp` protocol/tag value, the behavior of the RFC style lookup is the same as the standard style of lookup. -If you registered the service "rabbitmq" on port 5672 and tagged it with "amqp", -you could make an RFC 2782 query for its SRV record as "_rabbitmq._amqp.service.consul": +If you registered the service `rabbitmq` on port 5672 and tagged it with `amqp`, +you could make an RFC 2782 query for its SRV record as `_rabbitmq._amqp.service.consul`: ```text $ dig @127.0.0.1 -p 8600 _rabbitmq._amqp.service.consul SRV diff --git a/website/source/docs/agent/encryption.html.markdown b/website/source/docs/agent/encryption.html.markdown index 03c48016b4..1ea493fb4f 100644 --- a/website/source/docs/agent/encryption.html.markdown +++ b/website/source/docs/agent/encryption.html.markdown @@ -60,9 +60,9 @@ Consul requires that all clients and servers have key pairs that are generated b Certificate Authority. This can be a private CA, used only internally. The CA then signs keys for each of the agents, as in [this tutorial on generating both a CA and signing keys](http://russellsimpkins.blogspot.com/2015/10/consul-adding-tls-using-self-signed.html) -using OpenSSL. Note: client certificates must have -[Extended Key Usage](https://www.openssl.org/docs/manmaster/man5/x509v3_config.html#Extended-Key-Usage) enabled -for client and server authentication. +using OpenSSL. + +-> **Note:** Client certificates must have [Extended Key Usage](https://www.openssl.org/docs/manmaster/man5/x509v3_config.html#Extended-Key-Usage) enabled for client and server authentication. TLS can be used to verify the authenticity of the servers or verify the authenticity of clients. These modes are controlled by the [`verify_outgoing`](/docs/agent/options.html#verify_outgoing), @@ -78,9 +78,9 @@ appropriate key pair set using [`cert_file`](/docs/agent/options.html#cert_file) If [`verify_server_hostname`](/docs/agent/options.html#verify_server_hostname) is set, then outgoing connections perform hostname verification. All servers must have a certificate -valid for "server.\.\" or the client will reject the handshake. This is +valid for `server..` or the client will reject the handshake. This is a new configuration as of 0.5.1, and it is used to prevent a compromised client from being -able to restart in server mode and perform a MITM attack. New deployments should set this +able to restart in server mode and perform a MITM (Man-In-The-Middle) attack. New deployments should set this to true, and generate the proper certificates, but this is defaulted to false to avoid breaking existing deployments. diff --git a/website/source/docs/agent/http/acl.html.markdown b/website/source/docs/agent/http/acl.html.markdown index c368a4dcba..586282e02c 100644 --- a/website/source/docs/agent/http/acl.html.markdown +++ b/website/source/docs/agent/http/acl.html.markdown @@ -31,7 +31,7 @@ Type is either `client` or `management`. A management token is comparable to a root user and has the ability to perform any action including creating, modifying, and deleting ACLs. -By constrast, a client token can only perform actions as permitted by the +By contrast, a client token can only perform actions as permitted by the rules associated. Client tokens can never manage ACLs. Given this limitation, only a management token can be used to make requests to the `/v1/acl/create` endpoint. @@ -40,7 +40,7 @@ In any Consul cluster, only a single datacenter is authoritative for ACLs, so all requests are automatically routed to that datacenter regardless of the agent to which the request is made. -The create endpoint supports a JSON request body with the PUT. The request +The create endpoint supports a JSON request body with the `PUT`. The request body may take the form: ```javascript @@ -51,7 +51,7 @@ body may take the form: } ``` -None of the fields are mandatory. In fact, no body needs to be PUT if the +None of the fields are mandatory. In fact, no body needs to be `PUT` if the defaults are to be used. The `Name` and `Rules` fields default to being blank, and the `Type` defaults to "client". @@ -75,13 +75,13 @@ The update endpoint is used to modify the policy for a given ACL token. It is very similar to the create endpoint; however, instead of generating a new token ID, the `ID` field must be provided. As with [`/v1/acl/create`](#acl_create), requests to this endpoint must be made with a management token. If the ID does not -exist, the ACL will be upserted. In this sense, create and update are identical. +exist, the ACL will be inserted. In this sense, create and update are identical. In any Consul cluster, only a single datacenter is authoritative for ACLs, so all requests are automatically routed to that datacenter regardless of the agent to which the request is made. -The update endpoint requires a JSON request body to the PUT. The request +The update endpoint requires a JSON request body to the `PUT`. The request body may look like: ```javascript @@ -99,7 +99,7 @@ The format of `Rules` is [documented here](/docs/internals/acl.html). ### /v1/acl/destroy/\ -The destroy endpoint must be hit with a PUT. This endpoint destroys the ACL +The destroy endpoint must be hit with a `PUT`. This endpoint destroys the ACL token identified by the `id` portion of the path. The request is automatically routed to the authoritative ACL datacenter. @@ -107,7 +107,7 @@ Requests to this endpoint must be made with a management token. ### /v1/acl/info/\ -The info endpoint must be hit with a GET. This endpoint returns the ACL +The info endpoint must be hit with a `GET`. This endpoint returns the ACL token information identified by the `id` portion of the path. It returns a JSON body like this: @@ -129,7 +129,7 @@ If the ACL is not found, null is returned instead of a JSON list. ### /v1/acl/clone/\ -The clone endpoint must be hit with a PUT. It clones the ACL identified +The clone endpoint must be hit with a `PUT`. It clones the ACL identified by the `id` portion of the path and returns a new token `ID`. This allows a token to serve as a template for others, making it simple to generate new tokens without complex rule management. @@ -148,7 +148,7 @@ created ACL, like so: ### /v1/acl/list -The list endpoint must be hit with a GET. It lists all the active +The list endpoint must be hit with a `GET`. It lists all the active ACL tokens. This is a privileged endpoint and requires a management token. @@ -171,12 +171,12 @@ It returns a JSON body like this: ### /v1/acl/replication Available in Consul 0.7 and later, the endpoint must be hit with a -GET and returns the status of the [ACL replication](/docs/internals/acl.html#replication) +`GET` and returns the status of the [ACL replication](/docs/internals/acl.html#replication) process in the datacenter. This is intended to be used by operators, or by automation checking the health of ACL replication. -By default, the datacenter of the agent is queried; however, the dc can be provided -using the "?dc=" query parameter. +By default, the datacenter of the agent is queried; however, the `dc` can be provided +using the `?dc=` query parameter. It returns a JSON body like this: @@ -203,15 +203,16 @@ replicated from, and will match the `ReplicatedIndex` is the last index that was successfully replicated. You can compare this to the `X-Consul-Index` header returned by the [`/v1/acl/list`](#acl_list) endpoint to determine if the replication process has gotten all available -ACLs. Note that replication runs as a background process approximately every 30 +ACLs. Replication runs as a background process approximately every 30 seconds, and that local updates are rate limited to 100 updates/second, so so it may take several minutes to perform the initial sync of a large set of ACLs. After the initial sync, replica lag should be on the order of about 30 seconds. -`LastSuccess` is the UTC time of the last successful sync operation. Note that -since ACL replication is done with a blocking query, this may not update for up -to 5 minutes if there have been no ACL changes to replicate. A zero value of -"0001-01-01T00:00:00Z" will be present if no sync has been successful. +`LastSuccess` is the UTC time of the last successful sync operation. +Since ACL replication is done with a blocking query, this may not update +for up to 5 minutes if there have been no ACL changes to replicate. A +zero value of "0001-01-01T00:00:00Z" will be present if no sync has been +successful. `LastError` is the UTC time of the last error encountered during a sync operation. If this time is later than `LastSuccess`, you can assume the replication process diff --git a/website/source/docs/agent/http/agent.html.markdown b/website/source/docs/agent/http/agent.html.markdown index 74f3752ca9..8c8e27fb41 100644 --- a/website/source/docs/agent/http/agent.html.markdown +++ b/website/source/docs/agent/http/agent.html.markdown @@ -91,7 +91,7 @@ cluster gossip pool. Due to the nature of gossip, this is eventually consistent: results may differ by agent. The strongly consistent view of nodes is instead provided by "/v1/catalog/nodes". -For agents running in server mode, providing a "?wan=1" query parameter returns +For agents running in server mode, providing a `?wan=1` query parameter returns the list of WAN members instead of the LAN members returned by default. This endpoint is hit with a GET and returns a JSON body like: @@ -123,7 +123,7 @@ This endpoint is hit with a GET and returns a JSON body like: This endpoint is used to return the configuration and member information of the local agent under the `Config` key. -Consul 0.7.0 and later also includes a snapshot of various operating statistics under the `Stats` key. These statistics are intended to help human operators for debugging and may change over time, so this part of the interface should not be consumed programatically. +Consul 0.7.0 and later also includes a snapshot of various operating statistics under the `Stats` key. These statistics are intended to help human operators for debugging and may change over time, so this part of the interface should not be consumed programmatically. It returns a JSON body like this: @@ -214,17 +214,19 @@ The return code is 200 on success. ### /v1/agent/join/\ This endpoint is hit with a GET and is used to instruct the agent to attempt to -connect to a given address. For agents running in server mode, providing a "?wan=1" +connect to a given address. For agents running in server mode, providing a `?wan=1` query parameter causes the agent to attempt to join using the WAN pool. The return code is 200 on success. ### /v1/agent/force-leave/\ -This endpoint is hit with a GET and is used to instruct the agent to force a node into the `left` state. -If a node fails unexpectedly, then it will be in a `failed` state. Once in the `failed` state, Consul will -attempt to reconnect, and the services and checks belonging to that node will not be -cleaned up. Forcing a node into the `left` state allows its old entries to be removed. +This endpoint is hit with a GET and is used to instruct the agent to +force a node into the `left` state. If a node fails unexpectedly, then +it will be in a `failed` state. Once in the `failed` state, Consul will +attempt to reconnect, and the services and checks belonging to that node +will not be cleaned up. Forcing a node into the `left` state allows its +old entries to be removed. The endpoint always returns 200. @@ -280,25 +282,27 @@ If a `DockerContainerID` is provided, the check is a Docker check, and Consul wi evaluate the script every `Interval` in the given container using the specified `Shell`. Note that `Shell` is currently only supported for Docker checks. -An `HTTP` check will perform an HTTP GET request against the value of `HTTP` (expected to -be a URL) every `Interval`. If the response is any `2xx` code, the check is `passing`. -If the response is `429 Too Many Requests`, the check is `warning`. Otherwise, the check -is `critical`. HTTP checks also support SSL. By default, a valid SSL certificate is expected. -Certificate verification can be controlled using the `TLSSkipVerify`. +An `HTTP` check will perform an HTTP GET request against the value of +`HTTP` (expected to be a URL) every `Interval`. If the response is any +`2xx` code, the check is `passing`. If the response is `429 Too Many +Requests`, the check is `warning`. Otherwise, the check is `critical`. +HTTP checks also support SSL. By default, a valid SSL certificate is +expected. Certificate verification can be controlled using the +`TLSSkipVerify`. -If `TLSSkipVerify` is set to `true`, certificate verification will be disabled. By default, -certificate verification is enabled. +If `TLSSkipVerify` is set to `true`, certificate verification will be +disabled. By default, certificate verification is enabled. A `TCP` check will perform an TCP connection attempt against the value of `TCP` -(expected to be an IP/hostname and port combination) every `Interval`. If the +(expected to be an IP or hostname plus port combination) every `Interval`. If the connection attempt is successful, the check is `passing`. If the connection attempt is unsuccessful, the check is `critical`. In the case of a hostname that resolves to both IPv4 and IPv6 addresses, an attempt will be made to both addresses, and the first successful connection attempt will result in a successful check. -If a `TTL` type is used, then the TTL update endpoint must be used periodically to update -the state of the check. +If a `TTL` type is used, then the TTL update endpoint must be used +periodically to update the state of the check. The `ServiceID` field can be provided to associate the registered check with an existing service provided by the agent. @@ -329,9 +333,9 @@ This endpoint is used with a check that is of the [TTL type](/docs/agent/checks. When this endpoint is accessed via a GET, the status of the check is set to `passing` and the TTL clock is reset. -The optional "?note=" query parameter can be used to associate a human-readable message -with the status of the check. This will be passed through to the check's `Output` field -in the check endpoints. +The optional `?note=` query parameter can be used to associate a +human-readable message with the status of the check. This will be passed +through to the check's `Output` field in the check endpoints. The return code is 200 on success. @@ -341,21 +345,22 @@ This endpoint is used with a check that is of the [TTL type](/docs/agent/checks. When this endpoint is accessed via a GET, the status of the check is set to `warning`, and the TTL clock is reset. -The optional "?note=" query parameter can be used to associate a human-readable message -with the status of the check. This will be passed through to the check's `Output` field -in the check endpoints. +The optional `?note=` query parameter can be used to associate a +human-readable message with the status of the check. This will be passed +through to the check's `Output` field in the check endpoints. The return code is 200 on success. ### /v1/agent/check/fail/\ -This endpoint is used with a check that is of the [TTL type](/docs/agent/checks.html). -When this endpoint is accessed via a GET, the status of the check is set to `critical`, -and the TTL clock is reset. +This endpoint is used with a check that is of the [TTL +type](/docs/agent/checks.html). When this endpoint is accessed via a +GET, the status of the check is set to `critical`, and the TTL clock is +reset. -The optional "?note=" query parameter can be used to associate a human-readable message -with the status of the check. This will be passed through to the check's `Output` field -in the check endpoints. +The optional `?note=` query parameter can be used to associate a +human-readable message with the status of the check. This will be passed +through to the check's `Output` field in the check endpoints. The return code is 200 on success. @@ -374,21 +379,25 @@ This endpoint expects a JSON request body to be put. The request body must look } ``` -The `Status` field is mandatory, and must be set to "passing", "warning", or "critical". +The `Status` field is mandatory, and must be set to `passing`, +`warning`, or `critical`. -`Output` is an optional field that will associate a human-readable message with the status -of the check, such as the output of the checking script or process. This will be truncated -if it exceeds 4KB in size. This will be passed through to the check's `Output` field in the -check endpoints. +`Output` is an optional field that will associate a human-readable +message with the status of the check, such as the output of the checking +script or process. This will be truncated if it exceeds 4KB in size. +This will be passed through to the check's `Output` field in the check +endpoints. The return code is 200 on success. ### /v1/agent/service/register -The register endpoint is used to add a new service, with an optional health check, -to the local agent. There is more documentation on services [here](/docs/agent/services.html). -The agent is responsible for managing the status of its local services, and for sending updates -about its local services to the servers to keep the global Catalog in sync. +The register endpoint is used to add a new service, with an optional +health check, to the local agent. There is more documentation on +services [here](/docs/agent/services.html). The agent is responsible +for managing the status of its local services, and for sending updates +about its local services to the servers to keep the global Catalog in +sync. The register endpoint expects a JSON request body to be PUT. The request body must look like: @@ -398,12 +407,12 @@ body must look like: "ID": "redis1", "Name": "redis", "Tags": [ - "master", + "primary", "v1" ], "Address": "127.0.0.1", "Port": 8000, - "EnableTagOverride": false, + "EnableTagOverride": false, "Check": { "DeregisterCriticalServiceAfter": "90m", "Script": "/usr/local/bin/check_redis.py", @@ -414,9 +423,9 @@ body must look like: } ``` -The `Name` field is mandatory. If an `ID` is not provided, it is set to `Name`. -You cannot have duplicate `ID` entries per agent, so it may be necessary to provide an ID -in the case of a collision. +The `Name` field is mandatory. If an `ID` is not provided, it is set to +`Name`. You cannot have duplicate `ID` entries per agent, so it may be +necessary to provide an ID in the case of a collision. `Tags`, `Address`, `Port`, `Check` and `EnableTagOverride` are optional. @@ -428,39 +437,46 @@ an empty `Address` field for a service, use the `Address` field of the agent nod associated with that instance of the service, which is returned alongside the service information. -If `Check` is provided, only one of `Script`, `HTTP`, `TCP` or `TTL` should be specified. -`Script` and `HTTP` also require `Interval`. The created check will be named "service:\". +If `Check` is provided, only one of `Script`, `HTTP`, `TCP` or `TTL` +should be specified. `Script` and `HTTP` also require `Interval`. The +created check will be named "service:\". -In Consul 0.7 and later, checks that are associated with a service may also contain -an optional `DeregisterCriticalServiceAfter` field, which is a timeout in the same Go time -format as `Interval` and `TTL`. If a check is in the critical state for more than this -configured value, then its associated service (and all of its associated checks) -will automatically be deregistered. The minimum timeout is 1 minute, and the -process that reaps critical services runs every 30 seconds, so it may take slightly -longer than the configured timeout to trigger the deregistration. This should -generally be configured with a timeout that's much, much longer than any expected +In Consul 0.7 and later, checks that are associated with a service may +also contain an optional `DeregisterCriticalServiceAfter` field, which +is a timeout in the same [Go time format](https://golang.org/pkg/time/) +as `Interval` and `TTL`. If a check is in the critical state for more +than this configured value, then its associated service (and all of its +associated checks) will automatically be deregistered. The minimum +timeout is 1 minute, and the process that reaps critical services runs +every 30 seconds, so it may take slightly longer than the configured +timeout to trigger the deregistration. This should generally be +configured with a timeout that is much, much longer than any expected recoverable outage for the given service. There is more information about checks [here](/docs/agent/checks.html). -`EnableTagOverride` can optionally be specified to disable the anti-entropy -feature for this service's tags. If `EnableTagOverride` is set to `true` then external -agents can update this service in the [catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent -local sync operations by this agent will ignore the updated tags. For instance, if an external agent -modified both the tags and the port for this service and `EnableTagOverride` -was set to `true` then after the next sync cycle the service's port would revert -to the original value but the tags would maintain the updated value. As a -counter example, if an external agent modified both the tags and port for this -service and `EnableTagOverride` was set to `false` then after the next sync -cycle the service's port _and_ the tags would revert to the original value and -all modifications would be lost. It's important to note that this applies only -to the locally registered service. If you have multiple nodes all registering -the same service their `EnableTagOverride` configuration and all other service -configuration items are independent of one another. Updating the tags for -the service registered on one node is independent of the same service (by name) -registered on another node. If `EnableTagOverride` is not specified the default -value is `false`. See [anti-entropy syncs](/docs/internals/anti-entropy.html) -for more info. +The `EnableTagOverride` option can be specified to disable the +anti-entropy feature for this service's tags. If `EnableTagOverride` is +set to `true` then external agents can update this service in the +[catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent +local sync operations by this agent will ignore the updated tags. For +instance, if an external agent modified both the tags and the port for +this service and `EnableTagOverride` was set to `true` then after the +next sync cycle the service's port would revert to the original value +but the tags would maintain the updated value. As a counter example, if +an external agent modified both the tags and port for this service and +`EnableTagOverride` was set to `false` then after the next sync cycle +the service's port _and_ the tags would revert to the original value and +all modifications would be lost. + +It's important to note that this applies only to the locally registered +service. If you have multiple nodes all registering the same service +their `EnableTagOverride` configuration and all other service +configuration items are independent of one another. Updating the tags +for the service registered on one node is independent of the same +service (by name) registered on another node. If `EnableTagOverride` is +not specified the default value is `false`. See [anti-entropy +syncs](/docs/internals/anti-entropy.html) for more info. This endpoint supports [ACL tokens](/docs/internals/acl.html). If the query string includes a `?token=`, the registration will use the provided @@ -474,7 +490,7 @@ The return code is 200 on success. ### /v1/agent/service/deregister/\ The deregister endpoint is used to remove a service from the local agent. -The ServiceID must be passed after the slash. The agent will take care +The `ServiceID` must be passed after the slash. The agent will take care of deregistering the service with the Catalog. If there is an associated check, that is also deregistered. diff --git a/website/source/docs/agent/http/catalog.html.markdown b/website/source/docs/agent/http/catalog.html.markdown index 858dbabaf2..cbfd66e169 100644 --- a/website/source/docs/agent/http/catalog.html.markdown +++ b/website/source/docs/agent/http/catalog.html.markdown @@ -28,11 +28,11 @@ tunable consistency modes. ### /v1/catalog/register The register endpoint is a low-level mechanism for registering or updating -entries in the catalog. Note: it is usually preferrable instead to use the +entries in the catalog. It is usually preferable to instead use the [agent endpoints](agent.html) for registration as they are simpler and perform [anti-entropy](/docs/internals/anti-entropy.html). -The register endpoint expects a JSON request body to be PUT. The request +The register endpoint expects a JSON request body to be `PUT`. The request body must look something like: ```javascript @@ -48,7 +48,7 @@ body must look something like: "ID": "redis1", "Service": "redis", "Tags": [ - "master", + "primary", "v1" ], "Address": "127.0.0.1", @@ -70,7 +70,7 @@ requires `Node` and `Address` to be provided while `Datacenter` will be defaulte to match that of the agent. If only those are provided, the endpoint will register the node with the catalog. `TaggedAddresses` can be used in conjunction with the [`translate_wan_addrs`](/docs/agent/options.html#translate_wan_addrs) configuration -option and the "wan" address. The "lan" address was added in Consul 0.7 to help find +option and the `wan` address. The `lan` address was added in Consul 0.7 to help find the LAN address if address translation is enabled. If the `Service` key is provided, the service will also be registered. If @@ -78,8 +78,7 @@ If the `Service` key is provided, the service will also be registered. If Only one service with a given `ID` may be present per node. The service `Tags`, `Address`, and `Port` fields are all optional. -If the `Check` key is provided, a health check will also be registered. Note: this -register API manipulates the health check entry in the Catalog, but it does not setup +If the `Check` key is provided, a health check will also be registered. The register API manipulates the health check entry in the Catalog, but it does not setup the script, TTL, or HTTP check to monitor the node's health. To truly enable a new health check, the check must either be provided in agent configuration or set via the [agent endpoint](agent.html). @@ -112,11 +111,11 @@ If the API call succeeds, a 200 status code is returned. ### /v1/catalog/deregister The deregister endpoint is a low-level mechanism for directly removing -entries from the Catalog. Note: it is usually preferrable instead to use the +entries from the Catalog. It is usually preferable to instead use the [agent endpoints](agent.html) for deregistration as they are simpler and perform [anti-entropy](/docs/internals/anti-entropy.html). -The deregister endpoint expects a JSON request body to be PUT. The request +The deregister endpoint expects a JSON request body to be `PUT`. The request body must look like one of the following: ```javascript @@ -164,7 +163,7 @@ If the API call succeeds a 200 status code is returned. ### /v1/catalog/datacenters -This endpoint is hit with a GET and is used to return all the +This endpoint is hit with a `GET` and is used to return all the datacenters that are known by the Consul server. The datacenters will be sorted in ascending order based on the @@ -183,13 +182,13 @@ used as a simple check to see if any Consul servers are routable. ### /v1/catalog/nodes -This endpoint is hit with a GET and returns the nodes registered +This endpoint is hit with a `GET` and returns the nodes registered in a given DC. By default, the datacenter of the agent is queried; -however, the dc can be provided using the "?dc=" query parameter. +however, the dc can be provided using the `?dc=` query parameter. -Adding the optional "?near=" parameter with a node name will sort +Adding the optional `?near=` parameter with a node name will sort the node list in ascending order based on the estimated round trip -time from that node. Passing "?near=_agent" will use the agent's +time from that node. Passing `?near=_agent` will use the agent's node for the sort. It returns a JSON body like this: @@ -219,9 +218,9 @@ This endpoint supports blocking queries and all consistency modes. ### /v1/catalog/services -This endpoint is hit with a GET and returns the services registered +This endpoint is hit with a `GET` and returns the services registered in a given DC. By default, the datacenter of the agent is queried; -however, the dc can be provided using the "?dc=" query parameter. +however, the dc can be provided using the `?dc=` query parameter. It returns a JSON body like this: @@ -230,8 +229,8 @@ It returns a JSON body like this: "consul": [], "redis": [], "postgresql": [ - "master", - "slave" + "primary", + "secondary" ] } ``` @@ -243,17 +242,17 @@ This endpoint supports blocking queries and all consistency modes. ### /v1/catalog/service/\ -This endpoint is hit with a GET and returns the nodes providing a service +This endpoint is hit with a `GET` and returns the nodes providing a service in a given DC. By default, the datacenter of the agent is queried; -however, the dc can be provided using the "?dc=" query parameter. +however, the dc can be provided using the `?dc=` query parameter. The service being queried must be provided on the path. By default all nodes in that service are returned. However, the list can be filtered -by tag using the "?tag=" query parameter. +by tag using the `?tag=` query parameter. -Adding the optional "?near=" parameter with a node name will sort +Adding the optional `?near=` parameter with a node name will sort the node list in ascending order based on the estimated round trip -time from that node. Passing "?near=_agent" will use the agent's +time from that node. Passing `?near=_agent` will use the agent's node for the sort. It returns a JSON body like this: @@ -285,7 +284,7 @@ This endpoint supports blocking queries and all consistency modes. The returned fields are as follows: -- `Address`: IP address of the Consul node on which the service is registered +- `Address`: IP address of the Consul node on which the service is registered - `TaggedAddresses`: List of explicit LAN and WAN IP addresses for the agent - `CreateIndex`: Internal index value representing when the service was created - `ModifyIndex`: Last index that modified the service @@ -299,9 +298,9 @@ The returned fields are as follows: ### /v1/catalog/node/\ -This endpoint is hit with a GET and returns the node's registered services. +This endpoint is hit with a `GET` and returns the node's registered services. By default, the datacenter of the agent is queried; -however, the dc can be provided using the "?dc=" query parameter. +however, the dc can be provided using the `?dc=` query parameter. The node being queried must be provided on the path. It returns a JSON body like this: diff --git a/website/source/docs/agent/http/kv.html.markdown b/website/source/docs/agent/http/kv.html.markdown index 87c377c3c6..680b71ff1e 100644 --- a/website/source/docs/agent/http/kv.html.markdown +++ b/website/source/docs/agent/http/kv.html.markdown @@ -25,18 +25,18 @@ This endpoint manages updates of individual keys, deletes of individual keys or prefixes, and fetches of individual keys or key prefixes. The `GET`, `PUT` and `DELETE` methods are all supported. -By default, the datacenter of the agent is queried; however, the dc can be provided -using the "?dc=" query parameter. It is important to note that each datacenter has +By default, the datacenter of the agent is queried; however, the `dc` can be provided +using the `?dc=` query parameter. It is important to note that each datacenter has its own KV store, and there is no built-in replication between datacenters. If you are interested in replication between datacenters, look at the [Consul Replicate project](https://github.com/hashicorp/consul-replicate). -The KV endpoint supports the use of ACL tokens using the "?token=" query parameter. +The KV endpoint supports the use of ACL tokens using the `?token=` query parameter. #### GET Method When using the `GET` method, Consul will return the specified key. -If the "?recurse" query parameter is provided, it will return +If the `?recurse` query parameter is provided, it will return all keys with the given prefix. This endpoint supports blocking queries and all consistency modes. @@ -62,9 +62,9 @@ when the entry was created. `ModifyIndex` is the last index that modified this key. This index corresponds to the `X-Consul-Index` header value that is returned in responses, and it can -be used to establish blocking queries by setting the "?index" query parameter. +be used to establish blocking queries by setting the `?index` query parameter. You can even perform blocking queries against entire subtrees of the KV store: -if "?recurse" is provided, the returned `X-Consul-Index` corresponds +if `?recurse` is provided, the returned `X-Consul-Index` corresponds to the latest `ModifyIndex` within the prefix, and a blocking query using that "?index" will wait until any key within that prefix is updated. @@ -77,14 +77,15 @@ the lock. `Flags` is an opaque unsigned integer that can be attached to each entry. Clients can choose to use this however makes sense for their application. -`Value` is a Base64-encoded blob of data. Note that values cannot be larger than -512kB. +`Value` is a Base64-encoded blob of data. -It is possible to list just keys without their values by using the "?keys" query +-> **Note:** Values cannot be larger than 512kB. + +It is possible to list just keys without their values by using the `?keys` query parameter. This will return a list of the keys under the given prefix. The optional -"?separator=" can be used to list only up to a given separator. +`?separator=` can be used to list only up to a given separator. -For example, listing "/web/" with a "/" separator may return: +For example, listing `/web/` with a `/` separator may return: ```javascript [ @@ -97,7 +98,7 @@ For example, listing "/web/" with a "/" separator may return: Using the key listing method may be suitable when you do not need the values or flags or want to implement a key-space explorer. -If the "?raw" query parameter is used with a non-recursive GET, +If the `?raw` query parameter is used with a non-recursive `GET`, the response is just the raw value of the key, without any encoding. @@ -107,18 +108,18 @@ If no entries are found, a 404 code is returned. When using the `PUT` method, Consul expects the request body to be the value corresponding to the key. There are a number of query parameters that can -be used with a PUT request: +be used with a `PUT` request: -* ?flags=\ : This can be used to specify an unsigned value between - 0 and (2^64)-1. Clients can choose to use this however makes sense for their application. +* `?flags=` : This can be used to specify an unsigned value between + `0` and `(2^64)-1`. Clients can choose to use this however makes sense for their application. -* ?cas=\ : This flag is used to turn the `PUT` into a Check-And-Set +* `?cas=` : This flag is used to turn the `PUT` into a Check-And-Set operation. This is very useful as a building block for more complex synchronization primitives. If the index is 0, Consul will only put the key if it does not already exist. If the index is non-zero, the key is only set if the index matches the `ModifyIndex` of that key. -* ?acquire=\ : This flag is used to turn the `PUT` into a lock acquisition + * `?acquire=` : This flag is used to turn the `PUT` into a lock acquisition operation. This is useful as it allows leader election to be built on top of Consul. If the lock is not held and the session is valid, this increments the `LockIndex` and sets the `Session` value of the key in addition to updating @@ -127,7 +128,7 @@ be used with a PUT request: the key contents are updated. This lets the current lock holder update the key contents without having to give up the lock and reacquire it. -* ?release=\ : This flag is used to turn the `PUT` into a lock release +* `?release=` : This flag is used to turn the `PUT` into a lock release operation. This is useful when paired with "?acquire=" as it allows clients to yield a lock. This will leave the `LockIndex` unmodified but will clear the associated `Session` of the key. The key must be held by this session to be unlocked. @@ -138,13 +139,13 @@ the update has not taken place. #### DELETE method The `DELETE` method can be used to delete a single key or all keys sharing -a prefix. There are a few query parameters that can be used with a -DELETE request: +a prefix. There are a few query parameters that can be used with a +`DELETE` request: -* ?recurse : This is used to delete all keys which have the specified prefix. +* `?recurse` : This is used to delete all keys which have the specified prefix. Without this, only a key with an exact match will be deleted. -* ?cas=\ : This flag is used to turn the `DELETE` into a Check-And-Set +* `?cas=` : This flag is used to turn the `DELETE` into a Check-And-Set operation. This is very useful as a building block for more complex synchronization primitives. Unlike `PUT`, the index must be greater than 0 for Consul to take any action: a 0 index will not delete the key. If the index @@ -155,13 +156,13 @@ DELETE request: Available in Consul 0.7 and later, this endpoint manages updates or fetches of multiple keys inside a single, atomic transaction. Only the `PUT` method is supported. -By default, the datacenter of the agent receives the transaction; however, the dc -can be provided using the "?dc=" query parameter. It is important to note that each +By default, the datacenter of the agent receives the transaction; however, the `dc` +can be provided using the `?dc=` query parameter. It is important to note that each datacenter has its own KV store, and there is no built-in replication between datacenters. If you are interested in replication between datacenters, look at the [Consul Replicate project](https://github.com/hashicorp/consul-replicate). -The transaction endpoint supports the use of ACL tokens using the "?token=" query +The transaction endpoint supports the use of ACL tokens using the `?token=` query parameter. #### PUT Method @@ -170,16 +171,18 @@ The `PUT` method lets you submit a list of operations to apply to the key/value inside a transaction. If any operation fails, the transaction will be rolled back and none of the changes will be applied. -If the transaction doesn't contain any write operations then it will be fast-pathed -internally to an endpoint that works like other reads, except that blocking queries -are not currently supported. In this mode, you may supply the "?stale" or "?consistent" -query parameters with the request to control consistency. To support bounding the -acceptable staleness of data, read-only transaction responses provide the `X-Consul-LastContact` -header containing the time in milliseconds that a server was last contacted by the leader node. -The `X-Consul-KnownLeader` header also indicates if there is a known leader. These -won't be present if the transaction contains any write operations, and any consistency -query parameters will be ignored, since writes are always managed by the leader via -the Raft consensus protocol. +If the transaction doesn't contain any write operations then it will be +fast-pathed internally to an endpoint that works like other reads, +except that blocking queries are not currently supported. In this mode, +you may supply the `?stale` or `?consistent` query parameters with the +request to control consistency. To support bounding the acceptable +staleness of data, read-only transaction responses provide the +`X-Consul-LastContact` header containing the time in milliseconds that a +server was last contacted by the leader node. The +`X-Consul-KnownLeader` header also indicates if there is a known leader. +These won't be present if the transaction contains any write operations, +and any consistency query parameters will be ignored, since writes are +always managed by the leader via the Raft consensus protocol. The body of the request should be a list of operations to perform inside the atomic transaction. Up to 64 operations may be present in a single transaction. Operations @@ -210,7 +213,7 @@ available verbs. * `Key` is simply the full path of the entry. -* `Value` is a Base64-encoded blob of data. Note that values cannot be larger than +* `Value` is a Base64-encoded blob of data. Values cannot be larger than 512kB. * `Flags` is an opaque unsigned integer that can be attached to each entry. Clients diff --git a/website/source/docs/agent/http/operator.html.markdown b/website/source/docs/agent/http/operator.html.markdown index bc3a5d5e3f..81525c614f 100644 --- a/website/source/docs/agent/http/operator.html.markdown +++ b/website/source/docs/agent/http/operator.html.markdown @@ -45,11 +45,11 @@ When using the `GET` method, the request will be forwarded to the cluster leader to retrieve its latest Raft peer configuration. If the cluster doesn't currently have a leader an error will be returned. You -can use the "?stale" query parameter to read the Raft configuration from any +can use the `?stale` query parameter to read the Raft configuration from any of the Consul servers. By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. +provided using the `?dc=` query parameter. If ACLs are enabled, the client will need to supply an ACL Token with [`operator`](/docs/internals/acl.html#operator) read privileges. @@ -102,8 +102,7 @@ Raft configuration. `Voter` is "true" or "false", indicating if the server has a vote in the Raft configuration. Future versions of Consul may add support for non-voting servers. -The `Index` value is the Raft corresponding to this configuration. Note that -the latest configuration may not yet be committed if changes are in flight. +The `Index` value is the Raft corresponding to this configuration. The latest configuration may not yet be committed if changes are in flight. ### /v1/operator/raft/peer @@ -119,12 +118,12 @@ even though the server is no longer present and known to the cluster. This endpoint can be used to remove the failed server so that it is no longer affects the Raft quorum. -An "?address=" query parameter is required and should be set to the -"IP:port" for the server to remove. The port number is usually 8300, unless +An `?address=` query parameter is required and should be set to the +`IP:port` for the server to remove. The port number is usually 8300, unless configured otherwise. Nothing is required in the body of the request. By default, the datacenter of the agent is targeted; however, the `dc` can be -provided using the "?dc=" query parameter. +provided using the `?dc=` query parameter. If ACLs are enabled, the client will need to supply an ACL Token with [`operator`](/docs/internals/acl.html#operator) write privileges. @@ -137,7 +136,7 @@ Available in Consul 0.7.2 and later, the keyring endpoint supports the `GET`, `POST`, `PUT` and `DELETE` methods. This endpoint supports the use of ACL tokens using either the `X-CONSUL-TOKEN` -header or the "?token=" query parameter. +header or the `?token=` query parameter. #### GET Method @@ -192,7 +191,7 @@ Using the `POST` method, this endpoint will install a new gossip encryption key into the cluster. There is more information on gossip encryption available [here](/docs/agent/encryption.html#gossip-encryption). -The POST method expects a JSON request body to be submitted. The request +The `POST` method expects a JSON request body to be submitted. The request body must look like: ```javascript @@ -216,7 +215,7 @@ key. The key must already be installed before this operation can succeed. There is more information on gossip encryption available [here](/docs/agent/encryption.html#gossip-encryption). -The PUT method expects a JSON request body to be submitted. The request +The `PUT` method expects a JSON request body to be submitted. The request body must look like: ```javascript @@ -240,7 +239,7 @@ the cluster. This operation may only be performed on keys which are not currentl the primary key. There is more information on gossip encryption available [here](/docs/agent/encryption.html#gossip-encryption). -The DELETE method expects a JSON request body to be submitted. The request +The `DELETE` method expects a JSON request body to be submitted. The request body must look like: ```javascript diff --git a/website/source/docs/agent/http/query.html.markdown b/website/source/docs/agent/http/query.html.markdown index 4300912afe..6e5cfa1461 100644 --- a/website/source/docs/agent/http/query.html.markdown +++ b/website/source/docs/agent/http/query.html.markdown @@ -57,7 +57,7 @@ When using the `POST` method, Consul will create a new prepared query and return its ID if it is created successfully. By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. +provided using the `?dc=` query parameter. If ACLs are enabled, the client will need to supply an ACL Token with `query` write privileges for the `Name` of the query being created. @@ -78,7 +78,7 @@ query, like this example: "Datacenters": ["dc1", "dc2"] }, "OnlyPassing": false, - "Tags": ["master", "!experimental"] + "Tags": ["primary", "!experimental"] }, "DNS": { "TTL": "10s" @@ -105,14 +105,14 @@ field is left blank or omitted, the client's ACL Token will be used to determine if they have access to the service being queried. If the client does not supply an ACL Token, the anonymous token will be used. -Note that Consul version 0.6.3 and earlier would automatically capture the ACL +Consul version 0.6.3 and earlier would automatically capture the ACL Token for use in the future when prepared queries were executed and would execute with the same privileges as the definer of the prepared query. Older queries wishing to obtain the new behavior will need to be updated to remove their captured `Token` field. Capturing ACL Tokens is analogous to [PostgreSQL’s SECURITY DEFINER](http://www.postgresql.org/docs/current/static/sql-createfunction.html) attribute which can be set on functions. This change in effect moves Consul -from using `SECURITY DEFINER` by default to `SECURITY INVOKER` by default for +from using `SECURITY DEFINER` to `SECURITY INVOKER` by default for new Prepared Queries. @@ -162,7 +162,7 @@ to pass the tag filter it must have *all* of the required tags, and *none* of th excluded tags (prefixed with `!`). The default value is an empty list, which does no tag filtering. -`TTL` in the `DNS` structure is a duration string that can use "s" as a +`TTL` in the `DNS` structure is a duration string that can use `s` as a suffix for seconds. It controls how the TTL is set when query results are served over DNS. If this isn't specified, then the Consul agent configuration for the given service will be used (see [DNS Caching](/docs/guides/dns-cache.html)). If this is @@ -180,8 +180,10 @@ a JSON body: ``` Prepared Query Templates -Consul 0.6.4 and later also support prepared query templates. These are created similar -to static templates, except with some additional fields and features. Here's an example: + +Consul 0.6.4 and later also support prepared query templates. These are +created similar to static templates, except with some additional fields +and features. Here's an example: ```javascript { @@ -205,9 +207,9 @@ to static templates, except with some additional fields and features. Here's an The new `Template` structure configures a prepared query as a template instead of a static query. It has two fields: -`Type` is the query type, which must be "name_prefix_match". This means that the +`Type` is the query type, which must be `name_prefix_match`. This means that the template will apply to any query lookup with a name whose prefix matches the `Name` -field of the template. In this example, any query for "geo-db" will match this +field of the template. In this example, any query for `geo-db` will match this query. Query templates are resolved using a longest prefix match, so it's possible to have high-level templates that are overridden for specific services. Static queries are always resolved first, so they can also override templates. @@ -224,23 +226,25 @@ before it is executed. All of the string fields inside the `Service` structure a interpolated, with the following variables available: `${name.full}` has the entire name that was queried. For example, a DNS lookup for -"geo-db-customer-master.query.consul" in the example above would set this variable to -"geo-db-customer-master". +`geo-db-customer-primary.query.consul` in the example above would set this variable to +`geo-db-customer-primary`. -`${name.prefix}` has the prefix that matched. This would always be "geo-db" for +`${name.prefix}` has the prefix that matched. This would always be `geo-db` for the example above. `${name.suffix}` has the suffix after the prefix. For example, a DNS lookup for -"geo-db-customer-master.query.consul" in the example above would set this variable to -"-customer-master". +`geo-db-customer-primary.query.consul` in the example above would set this variable to +`-customer-primary`. -`${match(N)}` returns the regular expression match at the given index N. The -0 index will have the entire match, and >0 will have the results of each match -group. For example, a DNS lookup for "geo-db-customer-master.query.consul" in the example -above with a `Regexp` field set to `^geo-db-(.*?)-([^\-]+?)$` would return -"geo-db-customer-master" for `${match(0)}`, "customer" for `${match(1)}`, and -"master" for `${match(2)}`. If the regular expression doesn't match, or an invalid -index is given, then `${match(N)}` will return an empty string. +`${match(N)}` returns the regular expression match at the given index N. +The 0 index will have the entire match, and >0 will have the results of +each match group. For example, a DNS lookup for +`geo-db-customer-primary.query.consul` in the example above with a +`Regexp` field set to `^geo-db-(.*?)-([^\-]+?)$` would return +`geo-db-customer-primary` for `${match(0)}`, `customer` for +`${match(1)}`, and `primary` for `${match(2)}`. If the regular +expression doesn't match, or an invalid index is given, then +`${match(N)}` will return an empty string. See the [query explain](#explain) endpoint which is useful for testing interpolations and determining which query is handling a given name. @@ -275,7 +279,7 @@ only a single catch-all template can be registered at any time. When using the GET method, Consul will provide a listing of all prepared queries. By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. This endpoint supports blocking +provided using the `?dc=` query parameter. This endpoint supports blocking queries and all consistency modes. If ACLs are enabled, then the client will only see prepared queries for which their @@ -299,7 +303,7 @@ This returns a JSON list of prepared queries, which looks like: "Datacenters": ["dc1", "dc2"] }, "OnlyPassing": false, - "Tags": ["master", "!experimental"] + "Tags": ["primary", "!experimental"] }, "DNS": { "TTL": "10s" @@ -322,7 +326,7 @@ The query-specific endpoint supports the `GET`, `PUT`, and `DELETE` methods. The The `PUT` method allows an existing prepared query to be updated. By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. +provided using the `?dc=` query parameter. If ACLs are enabled, the client will need to supply an ACL Token with `query` write privileges for the `Name` of the query being updated. @@ -336,7 +340,7 @@ If the API call succeeds, a 200 status code is returned. The `GET` method allows an existing prepared query to be fetched. By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. This endpoint supports blocking +provided using the `?dc=` query parameter. This endpoint supports blocking queries and all consistency modes. The returned response is the same as the list of prepared queries above, @@ -353,7 +357,7 @@ management token is used. The `DELETE` method is used to delete a prepared query. By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. +provided using the `?dc=` query parameter. If ACLs are enabled, the client will need to supply an ACL Token with `query` write privileges for the `Name` of the query being deleted. @@ -370,17 +374,17 @@ of an existing prepared query, or a name that matches a prefix name for a [prepared query template](#templates). By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. This endpoint does not support +provided using the `?dc=` query parameter. This endpoint does not support blocking queries, but it does support all consistency modes. -Adding the optional "?near=" parameter with a node name will sort the resulting +Adding the optional `?near=` parameter with a node name will sort the resulting list in ascending order based on the estimated round trip time from that node. -Passing "?near=_agent" will use the agent's node for the sort. If this is not +Passing `?near=_agent` will use the agent's node for the sort. If this is not present, the default behavior will shuffle the nodes randomly each time the query is executed. Passing this option will override the built-in near parameter of a prepared query, if present. -An optional "?limit=" parameter can be used to limit the size of the list to +An optional `?limit=` parameter can be used to limit the size of the list to the given number of nodes. This is applied after any sorting or shuffling. If an ACL Token was bound to the query when it was defined then it will be used @@ -465,7 +469,7 @@ which [prepared query template](#templates) matches a given name, and what the final query looks like after interpolation. By default, the datacenter of the agent is queried; however, the `dc` can be -provided using the "?dc=" query parameter. This endpoint does not support +provided using the `?dc=` query parameter. This endpoint does not support blocking queries, but it does support all consistency modes. If ACLs are enabled, then the client will only see prepared queries for which their @@ -495,10 +499,10 @@ a JSON body will be returned like this: "Datacenters": ["dc1", "dc2"] }, "OnlyPassing": true, - "Tags": ["master"] + "Tags": ["primary"] } } ``` -Note that even though this query is a template, it is shown with its `Service` -fields interpolated based on the example query name "geo-db-customer-master". +Even though this query is a template, it is shown with its `Service` +fields interpolated based on the example query name `geo-db-customer-primary`. diff --git a/website/source/docs/agent/http/session.html.markdown b/website/source/docs/agent/http/session.html.markdown index 20d72fd4cb..fcd09b3483 100644 --- a/website/source/docs/agent/http/session.html.markdown +++ b/website/source/docs/agent/http/session.html.markdown @@ -56,10 +56,10 @@ the agent's own node name is used. `Name` can be used to provide a human-readable name for the Session. `Checks` is used to provide a list of associated health checks. It is highly recommended -that, if you override this list, you include the default "serfHealth". +that, if you override this list, you include the default `serfHealth`. `Behavior` can be set to either `release` or `delete`. This controls -the behavior when a session is invalidated. By default, this is `release`, +the behavior when a session is invalidated. By default, this is `release`, causing any locks that are held to be released. Changing this to `delete` causes any locks that are held to be deleted. `delete` is useful for creating ephemeral key/value entries. @@ -84,7 +84,7 @@ The return code is 200 on success and returns the ID of the created session: ### /v1/session/destroy/\ The destroy endpoint is hit with a PUT and destroys the given session. -By default, the local datacenter is used, but the "?dc=" query parameter +By default, the local datacenter is used, but the `?dc=` query parameter can be used to specify the datacenter. The session being destroyed must be provided on the path. @@ -95,7 +95,7 @@ The return code is 200 on success. This endpoint is hit with a GET and returns the requested session information within a given datacenter. By default, the datacenter of the agent is queried; -however, the dc can be provided using the "?dc=" query parameter. +however, the dc can be provided using the `?dc=` query parameter. The session being queried must be provided on the path. It returns a JSON body like this: @@ -121,7 +121,7 @@ This endpoint supports blocking queries and all consistency modes. This endpoint is hit with a GET and returns the active sessions for a given node and datacenter. By default, the datacenter of the agent is queried; -however, the dc can be provided using the "?dc=" query parameter. +however, the dc can be provided using the `?dc=` query parameter. The node being queried must be provided on the path. @@ -148,7 +148,7 @@ This endpoint supports blocking queries and all consistency modes. This endpoint is hit with a GET and returns the active sessions for a given datacenter. By default, the datacenter of the agent is queried; -however, the dc can be provided using the "?dc=" query parameter. +however, the dc can be provided using the `?dc=` query parameter. It returns a JSON body like this: @@ -173,7 +173,7 @@ This endpoint supports blocking queries and all consistency modes. The renew endpoint is hit with a PUT and renews the given session. This is used with sessions that have a TTL, and it extends the -expiration by the TTL. By default, the local datacenter is used, but the "?dc=" +expiration by the TTL. By default, the local datacenter is used, but the `?dc=` query parameter can be used to specify the datacenter. The session being renewed must be provided on the path. @@ -198,6 +198,5 @@ The return code is 200 on success. The response JSON body looks like this: The response body includes the current session. -Note: Consul MAY return a TTL value higher than the one specified during session creation. -This indicates the server is under high load and is requesting clients renew less -often. +-> **Note:** Consul MAY return a TTL value higher than the one specified during session creation. This indicates the server is under high load and is requesting clients renew less often. + diff --git a/website/source/docs/agent/options.html.markdown b/website/source/docs/agent/options.html.markdown index de0bb229ae..e799b032c9 100644 --- a/website/source/docs/agent/options.html.markdown +++ b/website/source/docs/agent/options.html.markdown @@ -241,7 +241,7 @@ will exit with an error at startup. * `-log-level` - The level of logging to show after the Consul agent has started. This defaults to "info". The available log levels are - "trace", "debug", "info", "warn", and "err". Note that you can always connect to an + "trace", "debug", "info", "warn", and "err". You can always connect to an agent via [`consul monitor`](/docs/commands/monitor.html) and use any log level. Also, the log level can be changed during a config reload. @@ -344,7 +344,7 @@ definitions support being updated during a reload. } ``` -Note the use of `ports`: +See, especially, the use of the `ports` setting: ```javascript "ports": { @@ -382,10 +382,10 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass permissions if it does not exist. It allows operators to bootstrap the ACL system with a token ID that is well-known.

- Note that the `acl_master_token` is only installed when a server acquires cluster leadership. If + The `acl_master_token` is only installed when a server acquires cluster leadership. If you would like to install or change the `acl_master_token`, set the new value for `acl_master_token` in the configuration for all servers. Once this is done, restart the current leader to force a - leader election. If the acl_master_token is not supplied, then the servers do not create a master + leader election. If the `acl_master_token` is not supplied, then the servers do not create a master token. When you provide a value, it can be any string value. Using a UUID would ensure that it looks the same as the other tokens, but isn't strictly necessary. @@ -887,7 +887,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass sockets created by Consul:
* `user` - The name or ID of the user who will own the socket file. - * `group` - The group ID ownership of the socket file. Note that this option + * `group` - The group ID ownership of the socket file. This option currently only supports numeric IDs. * `mode` - The permission bits to set on the file. @@ -896,7 +896,7 @@ Consul will not enable TLS for the HTTP API unless the `https` port has been ass connections make use of TLS and that the client provides a certificate signed by the Certificate Authority from the [`ca_file`](#ca_file). By default, this is false, and Consul will not enforce the use of TLS or verify a client's authenticity. This - applies to both server RPC and to the HTTPS API. Note: to enable the HTTPS API, you + applies to both server RPC and to the HTTPS API. To enable the HTTPS API, you must define an HTTPS port via the [`ports`](#ports) configuration. By default, HTTPS is disabled. diff --git a/website/source/docs/agent/services.html.markdown b/website/source/docs/agent/services.html.markdown index f1dbebbf69..31b895c837 100644 --- a/website/source/docs/agent/services.html.markdown +++ b/website/source/docs/agent/services.html.markdown @@ -23,7 +23,7 @@ A service definition that is a script looks like: { "service": { "name": "redis", - "tags": ["master"], + "tags": ["primary"], "address": "", "port": 8000, "enableTagOverride": false, @@ -37,14 +37,15 @@ A service definition that is a script looks like: } ``` -A service definition must include a `name` and may optionally provide -an `id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The `id` is -set to the `name` if not provided. It is required that all services have a unique -ID per node, so if names might conflict then unique IDs should be provided. +A service definition must include a `name` and may optionally provide an +`id`, `tags`, `address`, `port`, `check`, and `enableTagOverride`. The +`id` is set to the `name` if not provided. It is required that all +services have a unique ID per node, so if names might conflict then +unique IDs should be provided. -The `tags` property is a list of values that are opaque to Consul but can be used to -distinguish between "master" or "slave" nodes, different versions, or any other service -level labels. +The `tags` property is a list of values that are opaque to Consul but +can be used to distinguish between `primary` or `secondary` nodes, +different versions, or any other service level labels. The `address` field can be used to specify a service-specific IP address. By default, the IP address of the agent is used, and this does not need to be provided. @@ -58,7 +59,7 @@ used for any interaction with the catalog for the service, including A service can have an associated health check. This is a powerful feature as it allows a web balancer to gracefully remove failing nodes, a database -to replace a failed slave, etc. The health check is strongly integrated in +to replace a failed secondary, etc. The health check is strongly integrated in the DNS interface as well. If a service is failing its health check or a node has any failing system-level check, the DNS interface will omit that node from any service query. @@ -72,37 +73,42 @@ service checks registered, the ID will be generated as `service::` where `` is an incrementing number starting from `1`. -Note: there is more information about [checks here](/docs/agent/checks.html). +-> **Note:** There is more information about [checks here](/docs/agent/checks.html). -The `enableTagOverride` can optionally be specified to disable the anti-entropy -feature for this service. If `enableTagOverride` is set to TRUE then external -agents can update this service in the [catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent -local sync operations by this agent will ignore the updated tags. For instance: If an external agent -modified both the tags and the port for this service and `enableTagOverride` -was set to TRUE then after the next sync cycle the service's port would revert -to the original value but the tags would maintain the updated value. As a -counter example: If an external agent modified both the tags and port for this -service and `enableTagOverride` was set to FALSE then after the next sync -cycle the service's port AND the tags would revert to the original value and -all modifications would be lost. It's important to note that this applies only -to the locally registered service. If you have multiple nodes all registering -the same service their `enableTagOverride` configuration and all other service -configuration items are independent of one another. Updating the tags for -the service registered on one node is independent of the same service (by name) -registered on another node. If `enableTagOverride` is not specified the default -value is false. See [anti-entropy syncs](/docs/internals/anti-entropy.html) -for more info. +The `enableTagOverride` can optionally be specified to disable the +anti-entropy feature for this service. If `enableTagOverride` is set to +`TRUE` then external agents can update this service in the +[catalog](/docs/agent/http/catalog.html) and modify the tags. Subsequent +local sync operations by this agent will ignore the updated tags. For +example, if an external agent modified both the tags and the port for +this service and `enableTagOverride` was set to `TRUE` then after the next +sync cycle the service's port would revert to the original value but the +tags would maintain the updated value. As a counter example: If an +external agent modified both the tags and port for this service and +`enableTagOverride` was set to `FALSE` then after the next sync cycle the +service's port *and* the tags would revert to the original value and all +modifications would be lost. -To configure a service, either provide it as a `-config-file` option to the -agent or place it inside the `-config-dir` of the agent. The file must -end in the ".json" extension to be loaded by Consul. Check definitions can -also be updated by sending a `SIGHUP` to the agent. Alternatively, the -service can be registered dynamically using the [HTTP API](/docs/agent/http.html). +It's important to note that this applies only to the locally registered +service. If you have multiple nodes all registering the same service +their `enableTagOverride` configuration and all other service +configuration items are independent of one another. Updating the tags +for the service registered on one node is independent of the same +service (by name) registered on another node. If `enableTagOverride` is +not specified the default value is false. See [anti-entropy +syncs](/docs/internals/anti-entropy.html) for more info. + +To configure a service, either provide it as a `-config-file` option to +the agent or place it inside the `-config-dir` of the agent. The file +must end in the `.json` extension to be loaded by Consul. Check +definitions can be updated by sending a `SIGHUP` to the agent. +Alternatively, the service can be registered dynamically using the [HTTP +API](/docs/agent/http.html). ## Multiple Service Definitions -Multiple services definitions can be provided at once using the `services` -(plural) key in your configuration file. +Multiple services definitions can be provided at once using the plural +`services` key in your configuration file. ```javascript { @@ -111,7 +117,7 @@ Multiple services definitions can be provided at once using the `services` "id": "red0", "name": "redis", "tags": [ - "master" + "primary" ], "address": "", "port": 6000, @@ -128,7 +134,7 @@ Multiple services definitions can be provided at once using the `services` "name": "redis", "tags": [ "delayed", - "slave" + "secondary" ], "address": "", "port": 7000, diff --git a/website/source/docs/agent/telemetry.html.markdown b/website/source/docs/agent/telemetry.html.markdown index 09e5f064b1..f23033a086 100644 --- a/website/source/docs/agent/telemetry.html.markdown +++ b/website/source/docs/agent/telemetry.html.markdown @@ -161,7 +161,7 @@ These metrics give insight into the health of the cluster as a whole. `consul.serf.events` - This increments when an agent processes an [event](/docs/commands/event.html). Note that Consul uses events internally so there may be additional events showing in telemetry. There are also a per-event counters emitted as `consul.serf.events.`. + This increments when an agent processes an [event](/docs/commands/event.html). Consul uses events internally so there may be additional events showing in telemetry. There are also a per-event counters emitted as `consul.serf.events.`. events / interval counter @@ -185,7 +185,7 @@ These metrics give insight into the health of the cluster as a whole. `consul.http..` - This tracks how long it takes to service the given HTTP request for the given verb and path. Note that paths do not include details like service or key names, for these an underscore will be present as a placeholder (eg. `consul.http.GET.v1.kv._`) + This tracks how long it takes to service the given HTTP request for the given verb and path. Paths do not include details like service or key names, for these an underscore will be present as a placeholder (eg. `consul.http.GET.v1.kv._`) ms timer diff --git a/website/source/docs/commands/event.html.markdown b/website/source/docs/commands/event.html.markdown index a3d5b5b93c..51a3831eeb 100644 --- a/website/source/docs/commands/event.html.markdown +++ b/website/source/docs/commands/event.html.markdown @@ -17,6 +17,7 @@ or perform any other orchestration action. Events can be handled by [using a watch](/docs/agent/watches.html). Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip.html). + While the details are not important for using events, an understanding of the semantics is useful. The gossip layer will make a best-effort to deliver the event, but there is **no guaranteed delivery**. Unlike most Consul data, which is @@ -42,7 +43,7 @@ The list of available flags are: * `-http-addr` - Address to the HTTP server of the agent you want to contact to send this command. If this isn't specified, the command will contact - "127.0.0.1:8500" which is the default HTTP address of a Consul agent. + `127.0.0.1:8500` which is the default HTTP address of a Consul agent. * `-datacenter` - Datacenter to query. Defaults to that of agent. @@ -54,7 +55,7 @@ The list of available flags are: * `-tag` - Regular expression to filter to only nodes with a service that has a matching tag. This must be used with `-service`. As an example, you may - do "-service mysql -tag slave". + do `-service mysql -tag secondary`. * `-token` - The ACL token to use when firing the event. This token must have write-level privileges for the event specified. Defaults to that of the agent. diff --git a/website/source/docs/commands/exec.html.markdown b/website/source/docs/commands/exec.html.markdown index b9d1c26381..89ba0d62e0 100644 --- a/website/source/docs/commands/exec.html.markdown +++ b/website/source/docs/commands/exec.html.markdown @@ -34,20 +34,20 @@ could make the cluster unavailable. Usage: `consul exec [options] [-|command...]` The only required option is a command to execute. This is either given -as trailing arguments, or by specifying '-'; stdin will be read to +as trailing arguments, or by specifying `-`; STDIN will be read to completion as a script to evaluate. The list of available flags are: * `-http-addr` - Address to the HTTP server of the agent you want to contact to send this command. If this isn't specified, the command will contact - "127.0.0.1:8500" which is the default HTTP address of a Consul agent. + `127.0.0.1:8500` which is the default HTTP address of a Consul agent. * `-datacenter` - Datacenter to query. Defaults to that of agent. In version 0.4, that is the only supported value. * `-prefix` - Key prefix in the KV store to use for storing request data. - Defaults to "_rexec". + Defaults to `_rexec`. * `-node` - Regular expression to filter nodes which should evaluate the event. @@ -55,7 +55,7 @@ The list of available flags are: * `-tag` - Regular expression to filter to only nodes with a service that has a matching tag. This must be used with `-service`. As an example, you may - do "-service mysql -tag slave". + do `-service mysql -tag secondary`. * `-wait` - Specifies the period of time in which no agent's respond before considering the job finished. This is basically the quiescent time required to assume completion. @@ -64,10 +64,10 @@ The list of available flags are: * `-wait-repl` - Period to wait after writing the job specification for replication. This is a heuristic value and enables agents to do a stale read of the job. Defaults - to 200msec. + to 200 msec. * `-verbose` - Enables verbose output. * `-token` - The ACL token to use during requests. This token must have access - to the prefix in the KV store as well as exec "write" access for the _rexec + to the prefix in the KV store as well as exec "write" access for the `_rexec` event. Defaults to that of the agent. diff --git a/website/source/docs/commands/force-leave.html.markdown b/website/source/docs/commands/force-leave.html.markdown index 165bae82fa..2c07c233c2 100644 --- a/website/source/docs/commands/force-leave.html.markdown +++ b/website/source/docs/commands/force-leave.html.markdown @@ -3,7 +3,7 @@ layout: "docs" page_title: "Commands: Force Leave" sidebar_current: "docs-commands-forceleave" description: |- - The `force-leave` command forces a member of a Consul cluster to enter the left state. Note that if the member is still actually alive, it will eventually rejoin the cluster. The true purpose of this method is to force remove failed nodes. + The `force-leave` command forces a member of a Consul cluster to enter the left state. If the member is still actually alive, it will eventually rejoin the cluster. The true purpose of this method is to force remove failed nodes. --- # Consul Force Leave @@ -11,7 +11,7 @@ description: |- Command: `consul force-leave` The `force-leave` command forces a member of a Consul cluster to enter the -"left" state. Note that if the member is still actually alive, it will +"left" state. If the member is still actually alive, it will eventually rejoin the cluster. The true purpose of this method is to force remove "failed" nodes. @@ -33,6 +33,6 @@ Every option is optional: * `-rpc-addr` - Address to the RPC server of the agent you want to contact to send this command. If this isn't specified, the command checks the - CONSUL_RPC_ADDR env variable. If this isn't set, the default RPC - address will be set to "127.0.0.1:8400". + `CONSUL_RPC_ADDR` env variable. If this isn't set, the default RPC + address will be set to `127.0.0.1:8400`. diff --git a/website/source/docs/commands/kv/put.html.markdown.erb b/website/source/docs/commands/kv/put.html.markdown.erb index eaf4c3f24c..2a7858c10c 100644 --- a/website/source/docs/commands/kv/put.html.markdown.erb +++ b/website/source/docs/commands/kv/put.html.markdown.erb @@ -110,7 +110,7 @@ $ consul kv put -flags=42 redis/config/password s3cr3t Success! Data written to: redis/config/password ``` -To create or tune a lock, use the `-acquire` and `-session` flags. Note that the session must already exist (this command will not create it or manage it): +To create or tune a lock, use the `-acquire` and `-session` flags. The session must already exist (this command will not create it or manage it): ``` $ consul kv put -acquire -session=abc123 redis/lock/update diff --git a/website/source/docs/commands/rtt.html.markdown b/website/source/docs/commands/rtt.html.markdown index fc5425cfec..19441ac652 100644 --- a/website/source/docs/commands/rtt.html.markdown +++ b/website/source/docs/commands/rtt.html.markdown @@ -21,8 +21,8 @@ for more information on how these coordinates are computed. Usage: `consul rtt [options] node1 [node2]` At least one node name is required. If the second node name isn't given, it -is set to the agent's node name. Note that these are node names as known to -Consul as `consul members` would show, not IP addresses. +is set to the agent's node name. These are the node names as known to +Consul as the `consul members` command would show, not IP addresses. The list of available flags are: diff --git a/website/source/docs/compatibility.html.markdown b/website/source/docs/compatibility.html.markdown index 6c67ff5931..a06dd3a465 100644 --- a/website/source/docs/compatibility.html.markdown +++ b/website/source/docs/compatibility.html.markdown @@ -18,8 +18,9 @@ compatible with _at least_ one prior version. Concretely: version 0.5 can speak to 0.4 (and vice versa) but may not be able to speak to 0.1. Backwards compatibility is automatic unless otherwise noted. Consul agents by -default will speak the latest protocol but can understand earlier ones. Note: -if speaking an earlier protocol, _new features may not be available_. +default will speak the latest protocol but can understand earlier ones. + +-> **Note:** If speaking an earlier protocol, _new features may not be available_. The ability for an agent to speak an earlier protocol is to ensure that any agent can be upgraded without cluster disruption. Consul agents can be updated one diff --git a/website/source/docs/guides/bootstrapping.html.markdown b/website/source/docs/guides/bootstrapping.html.markdown index 93e79c4d26..94ffc31277 100644 --- a/website/source/docs/guides/bootstrapping.html.markdown +++ b/website/source/docs/guides/bootstrapping.html.markdown @@ -70,19 +70,22 @@ Since a join operation is symmetric, it does not matter which node initiates it. [INFO] consul: cluster leadership acquired ``` -As a sanity check, the [`consul info`](/docs/commands/info.html) command is a useful tool. It can be used to -verify `raft.num_peers` is now 2, and you can view the latest log index under `raft.last_log_index`. -When running [`consul info`](/docs/commands/info.html) on the followers, you should see `raft.last_log_index` -converge to the same value once the leader begins replication. That value represents the last -log entry that has been stored on disk. +As a sanity check, the [`consul info`](/docs/commands/info.html) command +is a useful tool. It can be used to verify `raft.num_peers` is now 2, +and you can view the latest log index under `raft.last_log_index`. When +running [`consul info`](/docs/commands/info.html) on the followers, you +should see `raft.last_log_index` converge to the same value once the +leader begins replication. That value represents the last log entry that +has been stored on disk. -Now that the servers are all started and replicating to each other, all the remaining -clients can be joined. Clients are much easier as they can join against any existing node. -All nodes participate in a gossip protocol to perform basic discovery, so once joined to any -member of the cluster, new clients will automatically find the servers and register themselves. +Now that the servers are all started and replicating to each other, all +the remaining clients can be joined. Clients are much easier as they can +join against any existing node. All nodes participate in a gossip +protocol to perform basic discovery, so once joined to any member of the +cluster, new clients will automatically find the servers and register +themselves. -Note: it is not strictly necessary to start the server nodes before the clients; however, most -operations will fail until the servers are available. +-> **Note:** It is not strictly necessary to start the server nodes before the clients; however, most operations will fail until the servers are available. ## Manual Bootstrapping diff --git a/website/source/docs/guides/forwarding.html.markdown b/website/source/docs/guides/forwarding.html.markdown index 88e7dc7eae..7785853858 100644 --- a/website/source/docs/guides/forwarding.html.markdown +++ b/website/source/docs/guides/forwarding.html.markdown @@ -8,26 +8,29 @@ description: |- # Forwarding DNS -By default, DNS is served from port 53. On most operating systems, this +By default, DNS is served from port 53. On most operating systems, this requires elevated privileges. Instead of running Consul with an administrative or root account, it is possible to instead forward appropriate queries to Consul, running on an unprivileged port, from another DNS server or port redirect. -In this guide, we will demonstrate forwarding from [BIND](https://www.isc.org/downloads/bind/) -as well as [dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) and [iptables](http://www.netfilter.org/). -For the sake of simplicity, BIND and Consul are running on the same machine in this example. For iptables the -rules must be set on the same host as the Consul instance and relay hosts should not be on the same host or -the redirects will intercept the traffic. +In this guide, we will demonstrate forwarding from +[BIND](https://www.isc.org/downloads/bind/) as well as +[dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html) and +[iptables](http://www.netfilter.org/). For the sake of simplicity, BIND +and Consul are running on the same machine in this example. For iptables +the rules must be set on the same host as the Consul instance and relay +hosts should not be on the same host or the redirects will intercept the +traffic. It is worth mentioning that, by default, Consul does not resolve DNS records outside the `.consul.` zone unless the [recursors](/docs/agent/options.html#recursors) configuration option -has been set. As an example of how this changes Consul's behavior, +has been set. As an example of how this changes Consul's behavior, suppose a Consul DNS reply includes a CNAME record pointing outside the `.consul` TLD. The DNS reply will only include CNAME records by default. By contrast, when `recursors` is set and the upstream resolver is functioning correctly, Consul will try to resolve CNAMEs and include -any records (e.g. A, AAAA, PTR) for them in its DNS reply. +any records (e.g. A, AAAA, PTR) for them in its DNS reply. You can either do one of the following: @@ -61,7 +64,7 @@ include "/etc/named/consul.conf"; ### Zone File -Then we set up a zone for our Consul managed records in consul.conf: +Then we set up a zone for our Consul managed records in `consul.conf`: ```text zone "consul" IN { @@ -129,15 +132,20 @@ for additional details): ### iptables Setup -On Linux systems that support it, incoming requests and requests to localhost can use `iptables` -to forward ports on the same machine without a secondary service. Since Consul, by default, only -resolves the `.consul` TDL, it is especially important to use the `recursors` option if you wish the -`iptables` setup to resolve for other domains. The recursors should not include the localhost as the -redirects would just intercept the requests. The iptables method is suited for situations where an -external DNS service is already running in your infrastructure and is used as the recursor or if you want -to use an existing DNS server as your query endpoint and forward requests for the consul domain to the -consul server. In both of those cases you may want to query the consul server but not need the overhead -of a separate service on the consul host. +On Linux systems that support it, incoming requests and requests to +the local host can use `iptables` to forward ports on the same machine +without a secondary service. Since Consul, by default, only resolves +the `.consul` TDL, it is especially important to use the `recursors` +option if you wish the `iptables` setup to resolve for other domains. +The recursors should not include the local host as the redirects would +just intercept the requests. + +The iptables method is suited for situations where an external DNS +service is already running in your infrastructure and is used as the +recursor or if you want to use an existing DNS server as your query +endpoint and forward requests for the consul domain to the Consul +server. In both of those cases you may want to query the Consul server +but not need the overhead of a separate service on the Consul host. ``` [root@localhost ~]# iptables -t nat -A PREROUTING -p udp -m udp --dport 53 -j REDIRECT --to-ports 8600 @@ -151,9 +159,9 @@ of a separate service on the consul host. First, perform a DNS query against Consul directly to be sure that the record exists: ```text -[root@localhost ~]# dig @localhost -p 8600 master.redis.service.dc-1.consul. A +[root@localhost ~]# dig @localhost -p 8600 primary.redis.service.dc-1.consul. A -; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost master.redis.service.dc-1.consul. A +; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost primary.redis.service.dc-1.consul. A ; (1 server found) ;; global options: +cmd ;; Got answer: @@ -161,10 +169,10 @@ First, perform a DNS query against Consul directly to be sure that the record ex ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: -;master.redis.service.dc-1.consul. IN A +;primary.redis.service.dc-1.consul. IN A ;; ANSWER SECTION: -master.redis.service.dc-1.consul. 0 IN A 172.31.3.234 +primary.redis.service.dc-1.consul. 0 IN A 172.31.3.234 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) @@ -176,9 +184,9 @@ Then run the same query against your BIND instance and make sure you get a valid result: ```text -[root@localhost ~]# dig @localhost -p 53 master.redis.service.dc-1.consul. A +[root@localhost ~]# dig @localhost -p 53 primary.redis.service.dc-1.consul. A -; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost master.redis.service.dc-1.consul. A +; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.32.amzn1 <<>> @localhost primary.redis.service.dc-1.consul. A ; (1 server found) ;; global options: +cmd ;; Got answer: @@ -186,10 +194,10 @@ valid result: ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: -;master.redis.service.dc-1.consul. IN A +;primary.redis.service.dc-1.consul. IN A ;; ANSWER SECTION: -master.redis.service.dc-1.consul. 0 IN A 172.31.3.234 +primary.redis.service.dc-1.consul. 0 IN A 172.31.3.234 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) diff --git a/website/source/docs/guides/leader-election.html.markdown b/website/source/docs/guides/leader-election.html.markdown index 48adf97926..1a97a627a7 100644 --- a/website/source/docs/guides/leader-election.html.markdown +++ b/website/source/docs/guides/leader-election.html.markdown @@ -17,8 +17,7 @@ cover all the possible methods. Instead, we will focus on using Consul's support [sessions](/docs/internals/sessions.html). Sessions allow us to build a system that can gracefully handle failures. -Note that JSON output in this guide has been pretty-printed for easier -reading. Actual values returned from the API will not be formatted. +-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted. ## Contending Nodes @@ -50,7 +49,7 @@ This will return a JSON object containing the session ID: The next step is to acquire a session for a given key from this node using the PUT method on a [KV entry](/docs/agent/http/kv.html) with the -"?acquire=\" query parameter. The `` of the PUT should be a +`?acquire=` query parameter. The `` of the PUT should be a JSON object representing the local node. This value is opaque to Consul, but it should contain whatever information clients require to communicate with your application (e.g., it could be a JSON object @@ -73,7 +72,7 @@ on ``. This is because the lock may be released, the node may fail, etc. The leader must also watch for changes since its lock may be released by an operator or automatically released due to a false positive in the failure detector. -Note that the session by default makes use of only the gossip failure detector. That +By default, the session makes use of only the gossip failure detector. That is, the session is considered held by a node as long as the default Serf health check has not declared the node unhealthy. Additional checks can be specified if desired. @@ -115,12 +114,14 @@ curl http://localhost:8500/v1/kv/ ] ``` -If the key has no associated `Session`, then there is no leader. Otherwise, the value of -the key will provide all the application-dependent information required as a Base64 encoded -blob in the `Value` field. +If the key has no associated `Session`, then there is no leader. +Otherwise, the value of the key will provide all the +application-dependent information required as a Base64 encoded blob in +the `Value` field. -You can query the [`/v1/session/info`](/docs/agent/http/session.html#session_info) endpoint -to get details about the session: +You can query the +[`/v1/session/info`](/docs/agent/http/session.html#session_info) +endpoint to get details about the session: ```text curl http://localhost:8500/v1/session/info/4ca8e74b-6350-7587-addf-a18084928f3c @@ -130,7 +131,7 @@ curl http://localhost:8500/v1/session/info/4ca8e74b-6350-7587-addf-a18084928f3c "Checks": [ "serfHealth" ], - "Node": "consul-master-bjsiobmvdij6-node-lhe5ihreel7y", + "Node": "consul-primary-bjsiobmvdij6-node-lhe5ihreel7y", "Name": "dbservice", "ID": "4ca8e74b-6350-7587-addf-a18084928f3c", "CreateIndex": 28 @@ -138,6 +139,7 @@ curl http://localhost:8500/v1/session/info/4ca8e74b-6350-7587-addf-a18084928f3c ] ``` -Clients should also watch the key using a blocking query for any changes. If the leader -steps down or fails, the `Session` associated with the key will be cleared. When -a new leader is elected, the key value will also be updated. +Clients should also watch the key using a blocking query for any +changes. If the leader steps down or fails, the `Session` associated +with the key will be cleared. When a new leader is elected, the key +value will also be updated. diff --git a/website/source/docs/guides/outage.html.markdown b/website/source/docs/guides/outage.html.markdown index 404608cba8..d82745e9d1 100644 --- a/website/source/docs/guides/outage.html.markdown +++ b/website/source/docs/guides/outage.html.markdown @@ -15,18 +15,19 @@ Depending on your may take only a single server failure for cluster unavailability. Recovery requires an operator to intervene, but the process is straightforward. -~> This guide is for recovery from a Consul outage due to a majority +~> This guide is for recovery from a Consul outage due to a majority of server nodes in a datacenter being lost. If you are just looking to add or remove a server, [see this guide](/docs/guides/servers.html). ## Failure of a Single Server Cluster -If you had only a single server and it has failed, simply restart it. -Note that a single server configuration requires the +If you had only a single server and it has failed, simply restart it. A +single server configuration requires the [`-bootstrap`](/docs/agent/options.html#_bootstrap) or -[`-bootstrap-expect=1`](/docs/agent/options.html#_bootstrap_expect) flag. If -the server cannot be recovered, you need to bring up a new server. -See the [bootstrapping guide](/docs/guides/bootstrapping.html) for more detail. +[`-bootstrap-expect=1`](/docs/agent/options.html#_bootstrap_expect) +flag. If the server cannot be recovered, you need to bring up a new +server. See the [bootstrapping guide](/docs/guides/bootstrapping.html) +for more detail. In the case of an unrecoverable server failure in a single server cluster, data loss is inevitable since data was not replicated to any other servers. This is @@ -54,8 +55,7 @@ server if it's still a member of the cluster. If [`consul force-leave`](/docs/commands/force-leave.html) isn't able to remove the server, you have two methods available to remove it, depending on your version of Consul: -* In Consul 0.7 and later, you can use the [`consul operator`](/docs/commands/operator.html#raft-remove-peer) -command to remove the stale peer server on the fly with no downtime. +* In Consul 0.7 and later, you can use the [`consul operator`](/docs/commands/operator.html#raft-remove-peer) command to remove the stale peer server on the fly with no downtime. * In versions of Consul prior to 0.7, you can manually remove the stale peer server using the `raft/peers.json` recovery file on all remaining servers. See @@ -94,7 +94,7 @@ In extreme cases, it should be possible to recover with just a single remaining server by starting that single server with itself as the only peer in the `raft/peers.json` recovery file. -Note that prior to Consul 0.7 it wasn't always possible to recover from certain +Prior to Consul 0.7 it wasn't always possible to recover from certain types of outages with `raft/peers.json` because this was ingested before any Raft log entries were played back. In Consul 0.7 and later, the `raft/peers.json` recovery file is final, and a snapshot is taken after it is ingested, so you are @@ -109,19 +109,18 @@ To begin, stop all remaining servers. You can attempt a graceful leave, but it will not work in most cases. Do not worry if the leave exits with an error. The cluster is in an unhealthy state, so this is expected. -~> Note that in Consul 0.7 and later, the peers.json file is no longer present +In Consul 0.7 and later, the `peers.json` file is no longer present by default and is only used when performing recovery. This file will be deleted after Consul starts and ingests this file. Consul 0.7 also uses a new, automatically- created `raft/peers.info` file to avoid ingesting the `raft/peers.json` file on the first start after upgrading. Be sure to leave `raft/peers.info` in place for proper operation. -
-
+ Using `raft/peers.json` for recovery can cause uncommitted Raft log entries to be implicitly committed, so this should only be used after an outage where no other option is available to recover a lost server. Make sure you don't have -any automated processes that will put the peers file in place on a periodic basis, -for example. +any automated processes that will put the peers file in place on a +periodic basis. The next step is to go to the [`-data-dir`](/docs/agent/options.html#_data_dir) of each Consul server. Inside that directory, there will be a `raft/` diff --git a/website/source/docs/guides/semaphore.html.markdown b/website/source/docs/guides/semaphore.html.markdown index 938c31b2ca..6b3205828d 100644 --- a/website/source/docs/guides/semaphore.html.markdown +++ b/website/source/docs/guides/semaphore.html.markdown @@ -21,8 +21,7 @@ cover all the possible methods. Instead, we will focus on using Consul's support [sessions](/docs/internals/sessions.html). Sessions allow us to build a system that can gracefully handle failures. -Note that JSON output in this guide has been pretty-printed for easier -reading. Actual values returned from the API will not be formatted. +-> **Note:** JSON output in this guide has been pretty-printed for easier reading. Actual values returned from the API will not be formatted. ## Contending Nodes diff --git a/website/source/docs/internals/acl.html.markdown b/website/source/docs/internals/acl.html.markdown index fa091879d2..ad52d85007 100644 --- a/website/source/docs/internals/acl.html.markdown +++ b/website/source/docs/internals/acl.html.markdown @@ -121,7 +121,7 @@ configuration to the target datacenter. Bootstrapping the ACL system is done by providing an initial [`acl_master_token` configuration](/docs/agent/options.html#acl_master_token) which will be created -as a "management" type token if it does not exist. Note that the [`acl_master_token` +as a "management" type token if it does not exist. The [`acl_master_token` ](/docs/agent/options.html#acl_master_token) is only installed when a server acquires cluster leadership. If you would like to install or change the [`acl_master_token`](/docs/agent/options.html#acl_master_token), set the new value for @@ -301,7 +301,7 @@ service "" { } ``` -Note that the above will allow access for reading service information only. This +The above will allow access for reading service information only. This level of access allows discovering other services in the system, but is not enough to allow the agent to sync its services and checks into the global catalog during [anti-entropy](/docs/internals/anti-entropy.html). diff --git a/website/source/docs/internals/anti-entropy.html.markdown b/website/source/docs/internals/anti-entropy.html.markdown index b30a92462a..4f61f73b95 100644 --- a/website/source/docs/internals/anti-entropy.html.markdown +++ b/website/source/docs/internals/anti-entropy.html.markdown @@ -138,14 +138,15 @@ automatically recover from these types of transient failures. ### EnableTagOverride -Synchronization of service registration can be partially modified to allow -external agents to change the tags for a service. This can be useful in -situations where an external monitoring service needs to be the source of -truth for tag information. For instance: Redis DB and its monitoring service -Redis Sentinel have this kind of relationship. Redis instances are responsible -for much of their configuration, but Sentinels determine whether the Redis -instance is a master or a slave. Using the Consul service configuration item -[EnableTagOverride](/docs/agent/services.html) you can instruct the Consul -agent on which the Redis DB is running to NOT update the tags during anti-entropy -synchronization. For more information see [Services](/docs/agent/services.html) -page. +Synchronization of service registration can be partially modified to +allow external agents to change the tags for a service. This can be +useful in situations where an external monitoring service needs to be +the source of truth for tag information. For example, the Redis +database and its monitoring service Redis Sentinel have this kind of +relationship. Redis instances are responsible for much of their +configuration, but Sentinels determine whether the Redis instance is a +primary or a secondary. Using the Consul service configuration item +[EnableTagOverride](/docs/agent/services.html) you can instruct the +Consul agent on which the Redis database is running to NOT update the +tags during anti-entropy synchronization. For more information see +[Services](/docs/agent/services.html) page. diff --git a/website/source/docs/upgrade-specific.html.markdown b/website/source/docs/upgrade-specific.html.markdown index 0a3c5c7d7c..c89ee6f23a 100644 --- a/website/source/docs/upgrade-specific.html.markdown +++ b/website/source/docs/upgrade-specific.html.markdown @@ -187,9 +187,10 @@ which require it: policy = "read" } -Note that the agent's [`acl_token`](/docs/agent/options.html#acl_token) is used -when the DNS interface is queried, so be sure that token has sufficient -privileges to return the DNS records you expect to retrieve from it. +When the DNS interface is queried, the agent's +[`acl_token`](/docs/agent/options.html#acl_token) is used, so be sure +that token has sufficient privileges to return the DNS records you +expect to retrieve from it. * Event and keyring ACLs diff --git a/website/source/docs/upgrading.html.markdown b/website/source/docs/upgrading.html.markdown index 7ed12628f4..12ee090670 100644 --- a/website/source/docs/upgrading.html.markdown +++ b/website/source/docs/upgrading.html.markdown @@ -80,7 +80,7 @@ Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use p This says the version of Consul as well as the protocol versions this agent speaks and can understand. -Note that sometimes Consul will default to speak a lower protocol version +Sometimes Consul will default to speak a lower protocol version than it understands, in order to ease compatibility with older agents. For example, Consul agents that understand version 3 claim to speak version 2, and only send version 3 messages to agents that understand version 3. This