Minor documentation fixes
- Correct spotted typos - Ran JSON snippets through jsonpp for consistent display of JSON results - Unfortunately my editor stripped EOL whitespace so there's a bit of whitespace diff
This commit is contained in:
Gavin M. Roy
parent
b54e1696f2
commit
ab2e3bf0f5
|
|
@ -76,7 +76,7 @@ There are several important components that `consul agent` outputs:
|
|||
|
||||
## Stopping an Agent
|
||||
|
||||
An agent can be stoped in two ways: gracefully or forcefully. To gracefully
|
||||
An agent can be stopped in two ways: gracefully or forcefully. To gracefully
|
||||
halt an agent, send the process an interrupt signal, which is usually
|
||||
`Ctrl-C` from a terminal. When gracefully exiting, the agent first notifies
|
||||
the cluster it intends to leave the cluster. This way, other cluster members
|
||||
|
|
@ -88,7 +88,7 @@ eventually (usually within seconds) detect that the node has died and will
|
|||
notify the cluster that the node has _failed_.
|
||||
|
||||
It is especially important that a server node be allowed to gracefully leave,
|
||||
so that there will be a minimal impact on availablity as the server leaves
|
||||
so that there will be a minimal impact on availability as the server leaves
|
||||
the consensus quorum.
|
||||
|
||||
For client agents, the difference between a node _failing_ and a node _leaving_
|
||||
|
|
@ -96,4 +96,3 @@ may not be important for your use case. For example, for a web server and load
|
|||
balancer setup, both result in the same action: remove the web node
|
||||
from the load balancer pool. But for other situations, you may handle
|
||||
each scenario differently.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ There are two different kinds of checks:
|
|||
every 30 seconds). This is similar to the Nagios plugin system.
|
||||
|
||||
* TTL - These checks retain their last known state for a given TTL. The state
|
||||
of the check must be updated periodicadically over the HTTP interface. If an
|
||||
of the check must be updated periodically over the HTTP interface. If an
|
||||
external system fails to update the status within a given TTL, the check is
|
||||
set to the failed state. This mechanism is used to allow an application to
|
||||
directly report it's health. For example, a web app can periodically curl the
|
||||
|
|
@ -79,4 +79,3 @@ a specific meaning. Specifically:
|
|||
This is the only convention that Consul depends on. Any output of the script
|
||||
will be captured and stored in the `notes` field so that it can be viewed
|
||||
by human operators.
|
||||
|
||||
|
|
|
|||
|
|
@ -268,7 +268,7 @@ The endpoint always returns 200.
|
|||
|
||||
The register endpoint is used to add a new check to the local agent.
|
||||
There is more documentation on checks [here](/docs/agent/checks.html).
|
||||
Checks are either a script or TTL type. The agent is reponsible for managing
|
||||
Checks are either a script or TTL type. The agent is responsible for managing
|
||||
the status of the check and keeping the Catalog in sync.
|
||||
|
||||
The register endpoint expects a JSON request body to be PUT. The request
|
||||
|
|
@ -279,8 +279,8 @@ body must look like:
|
|||
"Name": "Memory utilization",
|
||||
"Notes": "Ensure we don't oversubscribe memory",
|
||||
"Script": "/usr/local/bin/check_mem.py",
|
||||
"Interval": "10s",
|
||||
"TTL": "15s"
|
||||
"Interval": 10,
|
||||
"TTL": 15
|
||||
}
|
||||
|
||||
The `Name` field is mandatory, as is either `Script` and `Interval`
|
||||
|
|
@ -332,7 +332,7 @@ The return code is 200 on success.
|
|||
|
||||
The register endpoint is used to add a new service to the local agent.
|
||||
There is more documentation on services [here](/docs/agent/services.html).
|
||||
Services may also provide a health check. The agent is reponsible for managing
|
||||
Services may also provide a health check. The agent is responsible for managing
|
||||
the status of the check and keeping the Catalog in sync.
|
||||
|
||||
The register endpoint expects a JSON request body to be PUT. The request
|
||||
|
|
@ -341,12 +341,15 @@ body must look like:
|
|||
{
|
||||
"ID": "redis1",
|
||||
"Name": "redis",
|
||||
"Tags": ["master", "v1"],
|
||||
"Tags": [
|
||||
"master",
|
||||
"v1"
|
||||
],
|
||||
"Port": 8000,
|
||||
"Check": {
|
||||
"Script": "/usr/local/bin/check_redis.py",
|
||||
"Interval": "10s",
|
||||
"TTL": "15s"
|
||||
"Interval": 10,
|
||||
"TTL": 15
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -402,8 +405,11 @@ body must look like:
|
|||
"Service": {
|
||||
"ID": "redis1",
|
||||
"Service": "redis",
|
||||
"Tags": ["master", "v1"],
|
||||
"Port": 8000,
|
||||
"Tags": [
|
||||
"master",
|
||||
"v1"
|
||||
],
|
||||
"Port": 8000
|
||||
},
|
||||
"Check": {
|
||||
"Node": "foobar",
|
||||
|
|
@ -523,7 +529,10 @@ It returns a JSON body like this:
|
|||
{
|
||||
"consul": [],
|
||||
"redis": [],
|
||||
"postgresql":["master","slave"]
|
||||
"postgresql": [
|
||||
"master",
|
||||
"slave"
|
||||
]
|
||||
}
|
||||
|
||||
The main object keys are the service names, while the array
|
||||
|
|
@ -580,7 +589,9 @@ It returns a JSON body like this:
|
|||
"redis": {
|
||||
"ID": "redis",
|
||||
"Service": "redis",
|
||||
"Tags":["v1"],
|
||||
"Tags": [
|
||||
"v1"
|
||||
],
|
||||
"Port": 8000
|
||||
}
|
||||
}
|
||||
|
|
@ -590,7 +601,7 @@ This endpoint supports blocking queries and all consistency modes.
|
|||
|
||||
## Health
|
||||
|
||||
The Health used to query health related information. It is provided seperately
|
||||
The Health used to query health related information. It is provided separately
|
||||
from the Catalog, since users may prefer to not use the health checking mechanisms
|
||||
as they are totally optional. Additionally, some of the query results from the Health system are filtered, while the Catalog endpoints provide the raw entries.
|
||||
|
||||
|
|
@ -716,7 +727,8 @@ It returns a JSON body like this:
|
|||
"Output": "",
|
||||
"ServiceID": "redis",
|
||||
"ServiceName": "redis"
|
||||
},{
|
||||
},
|
||||
{
|
||||
"Node": "foobar",
|
||||
"CheckID": "serfHealth",
|
||||
"Name": "Serf Health Status",
|
||||
|
|
@ -792,5 +804,3 @@ This endpoint is used to get the Raft peers for the datacenter
|
|||
the agent is running in. It returns a list of addresses like:
|
||||
|
||||
["10.1.10.12:8300", "10.1.10.11:8300", "10.1.10.10:8300"]
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -28,8 +28,8 @@ The options below are all specified on the command-line.
|
|||
|
||||
* `-bootstrap` - This flag is used to control if a server is in "bootstrap" mode. It is important that
|
||||
no more than one server *per* datacenter be running in this mode. The initial server **must** be in bootstrap
|
||||
mode. Technically, a server in boostrap mode is allowed to self-elect as the Raft leader. It is important
|
||||
that only a single node is in this mode, because otherwise consistency cannot be guarenteed if multiple
|
||||
mode. Technically, a server in bootstrap mode is allowed to self-elect as the Raft leader. It is important
|
||||
that only a single node is in this mode, because otherwise consistency cannot be guaranteed if multiple
|
||||
nodes are able to self-elect. Once there are multiple servers in a datacenter, it is generally a good idea
|
||||
to disable bootstrap mode on all of them.
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ The options below are all specified on the command-line.
|
|||
* `-server` - This flag is used to control if an agent is in server or client mode. When provided,
|
||||
an agent will act as a Consul server. Each Consul cluster must have at least one server, and ideally
|
||||
no more than 5 *per* datacenter. All servers participate in the Raft consensus algorithm, to ensure that
|
||||
transactions occur in a consistent, linearlizable manner. Transactions modify cluster state, which
|
||||
transactions occur in a consistent, linearizable manner. Transactions modify cluster state, which
|
||||
is maintained on all server nodes to ensure availability in the case of node failure. Server nodes also
|
||||
participate in a WAN gossip pool with server nodes in other datacenters. Servers act as gateways
|
||||
to other datacenters and forward traffic as appropriate.
|
||||
|
|
@ -158,7 +158,8 @@ definitions support being updated during a reload.
|
|||
Must be provided along with the `key_file`.
|
||||
|
||||
* `domain` - By default, Consul responds to DNS queries in the "consul." domain.
|
||||
This flag can be used to change that domain. All queries in this domain are assumed to be handled by Consul, and will not be recursively resolved.
|
||||
This flag can be used to change that domain. All queries in this domain are assumed
|
||||
to be handled by Consul, and will not be recursively resolved.
|
||||
|
||||
* `enable_debug` - When set, enables some additional debugging features. Currently,
|
||||
only used to set the runtime profiling HTTP endpoints.
|
||||
|
|
@ -213,4 +214,3 @@ definitions support being updated during a reload.
|
|||
the Certificate Authority from the `ca_file`. By default, this is false, and Consul
|
||||
will not make use of TLS for outgoing connections. This applies to clients and servers,
|
||||
as both will make outgoing connections.
|
||||
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ we may start getting messages like:
|
|||
{"Log": "2013/12/03 13:06:53 [INFO] agent: Received event: member-join"}
|
||||
```
|
||||
|
||||
It is important to realize that these messages are sent asyncronously,
|
||||
It is important to realize that these messages are sent asynchronously,
|
||||
and not in response to any command. That means if a client is streaming
|
||||
commands, there may be logs streamed while a client is waiting for a
|
||||
response to a command. This is why the `Seq` must be used to pair requests
|
||||
|
|
@ -214,4 +214,3 @@ There is no request body, the response body looks like:
|
|||
...
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue