Merge pull request #2846 from hashicorp/f_docs_spelling_units
Spellcheck sweep of website directory
This commit is contained in:
commit
2373f94c74
|
@ -483,7 +483,7 @@ $ curl \
|
|||
- `Restarts`: The number of times the task has restarted.
|
||||
|
||||
- `Events` - An event contains metadata about the event. The latest 10 events
|
||||
are stored per task. Each event is timestamped (unix nano-seconds) and has one
|
||||
are stored per task. Each event is timestamped (Unix nanoseconds) and has one
|
||||
of the following types:
|
||||
|
||||
- `Setup Failure` - The task could not be started because there was a
|
||||
|
|
|
@ -211,7 +211,7 @@ The `Job` object supports the following keys:
|
|||
|
||||
- `Meta` - Annotates the job with opaque metadata.
|
||||
|
||||
- `ParameterizedJob` - Specifies the job as a paramterized job such that it can
|
||||
- `ParameterizedJob` - Specifies the job as a parameterized job such that it can
|
||||
be dispatched against. The `ParamaterizedJob` object supports the following
|
||||
attributes:
|
||||
|
||||
|
@ -428,12 +428,12 @@ The `Task` object supports the following keys:
|
|||
- `Timeout`: This indicates how long Consul will wait for a health
|
||||
check query to succeed.
|
||||
|
||||
- `Path`: The path of the http endpoint which Consul will query to query
|
||||
- `Path`: The path of the HTTP endpoint which Consul will query to query
|
||||
the health of a service if the type of the check is `http`. Nomad
|
||||
will add the IP of the service and the port, users are only required
|
||||
to add the relative URL of the health check endpoint.
|
||||
|
||||
- `Protocol`: This indicates the protocol for the http checks. Valid
|
||||
- `Protocol`: This indicates the protocol for the HTTP checks. Valid
|
||||
options are `http` and `https`. We default it to `http`.
|
||||
|
||||
- `Command`: This is the command that the Nomad client runs for doing
|
||||
|
@ -729,7 +729,7 @@ README][ct].
|
|||
does not conflict with the output file itself.
|
||||
|
||||
- `Perms` - Specifies the rendered template's permissions. File permissions are
|
||||
given as octal of the unix file permissions rwxrwxrwx.
|
||||
given as octal of the Unix file permissions rwxrwxrwx.
|
||||
|
||||
- `RightDelim` - Specifies the right delimiter to use in the template. The default
|
||||
is "}}" for some templates, it may be easier to use a different delimiter that
|
||||
|
|
|
@ -13,7 +13,7 @@ necessary for most users.
|
|||
|
||||
## Force GC
|
||||
|
||||
This endpoint initializes a garbage collection of jobs, evals, allocations, and
|
||||
This endpoint initializes a garbage collection of jobs, evaluations, allocations, and
|
||||
nodes. This is an asynchronous operation.
|
||||
|
||||
| Method | Path | Produces |
|
||||
|
|
|
@ -60,10 +60,10 @@ client {
|
|||
clients can determine their speed automatically, and thus in most cases this
|
||||
should be left unset.
|
||||
|
||||
- `cpu_total_compute` `(int: 0)` - Specifies an override for the total cpu
|
||||
- `cpu_total_compute` `(int: 0)` - Specifies an override for the total CPU
|
||||
compute. This value should be set to `# Cores * Core MHz`. For example, a
|
||||
quadcore running at 2GHz would have a total compute of 8000 (4 * 2000). Most
|
||||
clients can determine their total cpu compute automatically, and thus in most
|
||||
quad-core running at 2 GHz would have a total compute of 8000 (4 * 2000). Most
|
||||
clients can determine their total CPU compute automatically, and thus in most
|
||||
cases this should be left unset.
|
||||
|
||||
- `node_class` `(string: "")` - Specifies an arbitrary string used to logically
|
||||
|
|
|
@ -54,7 +54,7 @@ server {
|
|||
worker threads will dequeue for processing.
|
||||
|
||||
- `encrypt` `(string: "")` - Specifies the secret key to use for encryption of
|
||||
Nomad server's gossip network traffic. This key must be 16-bytes that are
|
||||
Nomad server's gossip network traffic. This key must be 16 bytes that are
|
||||
base64-encoded. The provided key is automatically persisted to the data
|
||||
directory and loaded automatically whenever the agent is restarted. This means
|
||||
that to encrypt Nomad server's gossip protocol, this option only needs to be
|
||||
|
|
|
@ -160,5 +160,5 @@ These `telemetry` parameters apply to
|
|||
- `circonus_broker_select_tag` `(string: "")` - Specifies a special tag which
|
||||
will be used to select a Circonus Broker when a Broker ID is not provided. The
|
||||
best use of this is to as a hint for which broker should be used based on
|
||||
*where* this particular instance is running (e.g. a specific geo location or
|
||||
*where* this particular instance is running (e.g. a specific geographic location or
|
||||
datacenter, dc:sfo).
|
||||
|
|
|
@ -19,7 +19,7 @@ starting the Nomad server. The key can be set via the
|
|||
[`encrypt`](/docs/agent/configuration/server.html#encrypt) parameter: the value
|
||||
of this setting is a server configuration file containing the encryption key.
|
||||
|
||||
The key must be 16-bytes, base64 encoded. As a convenience, Nomad provides the
|
||||
The key must be 16 bytes, base64 encoded. As a convenience, Nomad provides the
|
||||
[`nomad keygen`](/docs/commands/keygen.html) command to generate a cryptographically suitable key:
|
||||
|
||||
```sh
|
||||
|
|
|
@ -216,7 +216,7 @@ when retrieving metrics using the above described signals.
|
|||
# Client Metrics
|
||||
|
||||
The Nomad client emits metrics related to the resource usage of the allocations
|
||||
and tasks running on it and the node itself. Operators have to explicity turn
|
||||
and tasks running on it and the node itself. Operators have to explicitly turn
|
||||
on publishing host and allocation metrics. Publishing allocation and host
|
||||
metrics can be turned on by setting the value of `publish_allocation_metrics`
|
||||
`publish_node_metrics` to `true`.
|
||||
|
|
|
@ -46,7 +46,7 @@ The `docker` driver supports the following configuration in the job spec. Only
|
|||
```
|
||||
|
||||
* `args` - (Optional) A list of arguments to the optional `command`. If no
|
||||
`command` is specified, the args are passed directly to the container.
|
||||
`command` is specified, the arguments are passed directly to the container.
|
||||
References to environment variables or any [interpretable Nomad
|
||||
variables](/docs/runtime/interpolation.html) will be interpreted before
|
||||
launching the task. For example:
|
||||
|
@ -435,7 +435,7 @@ through Nomad plugins or dynamic job configuration.
|
|||
Nomad requires Docker to be installed and running on the host alongside the
|
||||
Nomad agent. Nomad was developed against Docker `1.8.2` and `1.9`.
|
||||
|
||||
By default Nomad communicates with the Docker daemon using the daemon's unix
|
||||
By default Nomad communicates with the Docker daemon using the daemon's Unix
|
||||
socket. Nomad will need to be able to read/write to this socket. If you do not
|
||||
run Nomad as root, make sure you add the Nomad user to the Docker group so
|
||||
Nomad can communicate with the Docker daemon.
|
||||
|
@ -550,9 +550,9 @@ job "docs" {
|
|||
Nomad limits containers' CPU based on CPU shares. CPU shares allow containers
|
||||
to burst past their CPU limits. CPU limits will only be imposed when there is
|
||||
contention for resources. When the host is under load your process may be
|
||||
throttled to stabilize QOS depending on how many shares it has. You can see how
|
||||
throttled to stabilize QoS depending on how many shares it has. You can see how
|
||||
many CPU shares are available to your process by reading `NOMAD_CPU_LIMIT`.
|
||||
1000 shares are approximately equal to 1Ghz.
|
||||
1000 shares are approximately equal to 1 GHz.
|
||||
|
||||
Please keep the implications of CPU shares in mind when you load test workloads
|
||||
on Nomad.
|
||||
|
@ -568,11 +568,11 @@ Since memory is not an elastic resource, you will need to make sure your
|
|||
container does not exceed the amount of memory allocated to it, or it will be
|
||||
terminated or crash when it tries to malloc. A process can inspect its memory
|
||||
limit by reading `NOMAD_MEMORY_LIMIT`, but will need to track its own memory
|
||||
usage. Memory limit is expressed in megabytes so 1024 = 1Gb.
|
||||
usage. Memory limit is expressed in megabytes so 1024 = 1 GB.
|
||||
|
||||
### IO
|
||||
|
||||
Nomad's Docker integration does not currently provide QOS around network or
|
||||
Nomad's Docker integration does not currently provide QoS around network or
|
||||
filesystem IO. These will be added in a later release.
|
||||
|
||||
### Security
|
||||
|
@ -588,9 +588,9 @@ reasons, it is recommended to use full virtualization like
|
|||
|
||||
Docker For Mac runs docker inside a small VM and then allows access to parts of
|
||||
the host filesystem into that VM. At present, nomad uses a syslog server bound to
|
||||
a unix socket within a path that both the host and the VM can access to forward
|
||||
a Unix socket within a path that both the host and the VM can access to forward
|
||||
log messages back to nomad. But at present, Docker For Mac does not work for
|
||||
unix domain sockets (https://github.com/docker/for-mac/issues/483) in one of
|
||||
Unix domain sockets (https://github.com/docker/for-mac/issues/483) in one of
|
||||
these shared paths.
|
||||
|
||||
As a result, using nomad with the docker driver on OS X/macOS will work, but no
|
||||
|
|
|
@ -33,7 +33,7 @@ The `java` driver supports the following configuration in the job spec:
|
|||
and the manifest specifies a main class, this is optional. If shipping classes
|
||||
rather than a Jar, please specify the class to run and the `class_path`.
|
||||
|
||||
* `class_path` - (Optional) The `class_path` specifies the clath path used by
|
||||
* `class_path` - (Optional) The `class_path` specifies the class path used by
|
||||
Java to lookup classes and Jars.
|
||||
|
||||
* `jar_path` - (Optional) The path to the downloaded Jar. In most cases this will just be
|
||||
|
|
|
@ -76,7 +76,7 @@ information.
|
|||
|
||||
The `lxc` driver requires the following:
|
||||
|
||||
* 64bit Linux host
|
||||
* 64-bit Linux host
|
||||
* The `linux_amd64_lxc` Nomad binary
|
||||
* `liblxc` to be installed
|
||||
* `lxc-templates` to be installed
|
||||
|
@ -92,7 +92,7 @@ The `lxc` driver requires the following:
|
|||
The `lxc` driver will set the following client attributes:
|
||||
|
||||
* `driver.lxc` - Set to `1` if LXC is found and enabled on the host node.
|
||||
* `driver.lxc.version` - Version of `lxc` eg: `1.1.0`.
|
||||
* `driver.lxc.version` - Version of `lxc` e.g.: `1.1.0`.
|
||||
|
||||
## Resource Isolation
|
||||
|
||||
|
|
|
@ -178,9 +178,9 @@ The `rkt` driver will set the following client attributes:
|
|||
|
||||
* `driver.rkt` - Set to `1` if rkt is found on the host node. Nomad determines
|
||||
this by executing `rkt version` on the host and parsing the output
|
||||
* `driver.rkt.version` - Version of `rkt` eg: `1.1.0`. Note that the minimum required
|
||||
* `driver.rkt.version` - Version of `rkt` e.g.: `1.1.0`. Note that the minimum required
|
||||
version is `1.0.0`
|
||||
* `driver.rkt.appc.version` - Version of `appc` that `rkt` is using eg: `1.1.0`
|
||||
* `driver.rkt.appc.version` - Version of `appc` that `rkt` is using e.g.: `1.1.0`
|
||||
|
||||
Here is an example of using these properties in a job file:
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ Installing Nomad is simple. There are two approaches to installing Nomad:
|
|||
1. Installing <a href="#from-source">from source</a>
|
||||
|
||||
Downloading a precompiled binary is easiest, and we provide downloads over
|
||||
TLS along with SHA256 sums to verify the binary.
|
||||
TLS along with SHA-256 sums to verify the binary.
|
||||
|
||||
<a name="precompiled-binaries"></a>
|
||||
## Precompiled Binaries
|
||||
|
|
|
@ -94,7 +94,7 @@ artifact {
|
|||
|
||||
### Download using git
|
||||
|
||||
This example downloads the artifact from the provided github url and places it at
|
||||
This example downloads the artifact from the provided GitHub URL and places it at
|
||||
`local/repo`, as specified by the optional `destination` parameter.
|
||||
|
||||
```hcl
|
||||
|
|
|
@ -18,7 +18,7 @@ description: |-
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
The `dispatch_payload` stanza is used in conjuction with a [`parameterized`][parameterized] job
|
||||
The `dispatch_payload` stanza is used in conjunction with a [`parameterized`][parameterized] job
|
||||
that expects a payload. When the job is dispatched with a payload, the payload
|
||||
will be made available to any task that has a `dispatch_payload` stanza. The
|
||||
payload will be written to the configured file before the task is started. This
|
||||
|
|
|
@ -86,7 +86,7 @@ job "docs" {
|
|||
with user-defined metadata.
|
||||
|
||||
- `parameterized` <code>([Parameterized][parameterized]: nil)</code> - Specifies
|
||||
the job as a paramterized job such that it can be dispatched against.
|
||||
the job as a parameterized job such that it can be dispatched against.
|
||||
|
||||
- `periodic` <code>([Periodic][]: nil)</code> - Allows the job to be scheduled
|
||||
at fixed times, dates or intervals.
|
||||
|
|
|
@ -85,7 +85,7 @@ The following examples only show the `network` stanzas. Remember that the
|
|||
|
||||
### Bandwidth
|
||||
|
||||
This example specifies a resource requirement of 1GBits in bandwidth:
|
||||
This example specifies a resource requirement of 1 Gbit in bandwidth:
|
||||
|
||||
```hcl
|
||||
network {
|
||||
|
|
|
@ -26,7 +26,7 @@ stanza is added to a job, the job acts as a function to the cluster as a whole.
|
|||
|
||||
The `parameterized` stanza allows job operators to configure a job that carries
|
||||
out a particular action, define its resource requirements and configure how
|
||||
inputs and configuration are retreived by the tasks within the job.
|
||||
inputs and configuration are retrieved by the tasks within the job.
|
||||
|
||||
To invoke a parameterized job, [`nomad job
|
||||
dispatch`][dispatch command] or the equivalent HTTP APIs are
|
||||
|
|
|
@ -19,7 +19,7 @@ description: |-
|
|||
</table>
|
||||
|
||||
The `resources` stanza describes the requirements a task needs to execute.
|
||||
Resource requirements include memory, network, cpu, and more.
|
||||
Resource requirements include memory, network, CPU, and more.
|
||||
|
||||
```hcl
|
||||
job "docs" {
|
||||
|
@ -73,7 +73,7 @@ resources {
|
|||
### Network
|
||||
|
||||
This example shows network constraints as specified in the [network][] stanza
|
||||
which require 1GBit of bandwidth, dynamically allocates two ports, and
|
||||
which require 1 Gbit of bandwidth, dynamically allocates two ports, and
|
||||
statically allocates one port:
|
||||
|
||||
```hcl
|
||||
|
|
|
@ -95,11 +95,11 @@ does not automatically enable service discovery.
|
|||
|
||||
- `address_mode` `(string: "auto")` - Specifies what address (host or
|
||||
driver-specific) this service should advertise. `host` indicates the host IP
|
||||
and port. `driver` advertises the IP used in the driver (eg Docker's internal
|
||||
IP) and uses the ports specifid in the port map. The default is `auto` which
|
||||
and port. `driver` advertises the IP used in the driver (e.g. Docker's internal
|
||||
IP) and uses the ports specified in the port map. The default is `auto` which
|
||||
behaves the same as `host` unless the driver determines its IP should be used.
|
||||
This setting was added in Nomad 0.6 and only supported by the Docker driver.
|
||||
It will advertise the container IP if a network plugin is used (eg weave).
|
||||
It will advertise the container IP if a network plugin is used (e.g. weave).
|
||||
|
||||
### `check` Parameters
|
||||
|
||||
|
|
|
@ -76,7 +76,7 @@ README][ct]. Since Nomad v0.6.0, templates can be read as environment variables.
|
|||
different delimiter that does not conflict with the output file itself.
|
||||
|
||||
- `perms` `(string: "644")` - Specifies the rendered template's permissions.
|
||||
File permissions are given as octal of the unix file permissions rwxrwxrwx.
|
||||
File permissions are given as octal of the Unix file permissions rwxrwxrwx.
|
||||
|
||||
- `right_delimiter` `(string: "}}")` - Specifies the right delimiter to use in the
|
||||
template. The default is "}}" for some templates, it may be easier to use a
|
||||
|
|
|
@ -70,8 +70,8 @@ job "docs" {
|
|||
label suffix like "30s" or "15m".
|
||||
|
||||
- `healthy_deadline` `(string: "5m")` - Specifies the deadline in which the
|
||||
allocation must be marked as heatlhy after which the allocation is
|
||||
automatically transistioned to unhealthy. This is specified using a label
|
||||
allocation must be marked as healthy after which the allocation is
|
||||
automatically transitioned to unhealthy. This is specified using a label
|
||||
suffix like "2m" or "1h".
|
||||
|
||||
- `auto_revert` `(bool: false)` - Specifies if the job should auto-revert to the
|
||||
|
|
|
@ -22,7 +22,7 @@ standard upgrade flow.
|
|||
Nomad 0.5.5 has a backward incompatible change in the `docker` driver's
|
||||
configuration. Prior to 0.5.5 the `load` configuration option accepted a list
|
||||
images to load, in 0.5.5 it has been changed to a single string. No
|
||||
functionality was changed. Even if more than one item was specificed prior to
|
||||
functionality was changed. Even if more than one item was specified prior to
|
||||
0.5.5 only the first item was used.
|
||||
|
||||
To do a zero-downtime deploy with jobs that use the `load` option:
|
||||
|
@ -56,7 +56,7 @@ tools.
|
|||
## Nomad 0.4.0
|
||||
|
||||
Nomad 0.4.0 has backward incompatible changes in the logic for Consul
|
||||
deregistration. When a Task which was started by Nomad 0.3.X is uncleanly shut
|
||||
deregistration. When a Task which was started by Nomad v0.3.x is uncleanly shut
|
||||
down, the Nomad 0.4 Client will no longer clean up any stale services. If an
|
||||
in-place upgrade of the Nomad client to 0.4 prevents the Task from gracefully
|
||||
shutting down and deregistering its Consul-registered services, the Nomad Client
|
||||
|
@ -69,7 +69,7 @@ node once the upgrade is complete.
|
|||
|
||||
## Nomad 0.3.1
|
||||
|
||||
Nomad 0.3.1 removes artifact downloading from driver configs and places them as
|
||||
Nomad 0.3.1 removes artifact downloading from driver configurations and places them as
|
||||
a first class element of the task. As such, jobs will have to be rewritten in
|
||||
the proper format and resubmitted to Nomad. Nomad clients will properly
|
||||
re-attach to existing tasks but job definitions must be updated before they can
|
||||
|
|
|
@ -126,7 +126,7 @@ role definition or as a blacklist by using `disallowed_policies`.
|
|||
|
||||
If using `allowed_policies`, tasks may only request Vault policies that are in
|
||||
the list. If `disallowed_policies` is used, task may request any policy that is
|
||||
not in the `disallowed_policies` list. There are tradeoffs to both approaches
|
||||
not in the `disallowed_policies` list. There are trade-offs to both approaches
|
||||
but generally it is easier to use the blacklist approach and add policies that
|
||||
you would not like tasks to have access to into the `disallowed_policies` list.
|
||||
|
||||
|
@ -155,14 +155,14 @@ documentation for all possible fields and more complete documentation.
|
|||
under Nomad should have access to.
|
||||
|
||||
* `disallowed_policies` - Specifies the list of disallowed policies as a
|
||||
comma-seperated string. This list should contain all policies that jobs running
|
||||
comma-separated string. This list should contain all policies that jobs running
|
||||
under Nomad should **not** have access to. The policy created above that
|
||||
grants Nomad the ability to generate tokens from the token role should be
|
||||
included in list of disallowed policies. This prevents tokens created by
|
||||
Nomad from generating new tokens with different policies than those granted
|
||||
by Nomad.
|
||||
|
||||
A regression occured in Vault 0.6.4 when validating token creation using a
|
||||
A regression occurred in Vault 0.6.4 when validating token creation using a
|
||||
token role with `disallowed_policies` such that it is not usable with
|
||||
Nomad. This will be remedied in 0.6.5 and does not effect earlier versions
|
||||
of Vault.
|
||||
|
|
|
@ -67,7 +67,7 @@ port.
|
|||
* HTTP API (Default 4646). This is used by clients and servers to serve the HTTP
|
||||
API. TCP only.
|
||||
|
||||
* RPC (Default 4647). This is used by servers and clients to communicate amongst
|
||||
* RPC (Default 4647). This is used by servers and clients to communicate among
|
||||
each other. TCP only.
|
||||
|
||||
* Serf WAN (Default 4648). This is used by servers to gossip over the WAN to
|
||||
|
|
|
@ -112,7 +112,7 @@ job "template" {
|
|||
}
|
||||
```
|
||||
|
||||
## Order of Precendence
|
||||
## Order of Precedence
|
||||
|
||||
The order of precedence for customized settings is as follows:
|
||||
|
||||
|
|
Loading…
Reference in New Issue