Fix old references

This commit is contained in:
Alex Dadgar
2018-03-22 13:39:18 -07:00
parent 1c2cfdc863
commit f5ebe7da8e
69 changed files with 280 additions and 253 deletions

View File

@@ -14,7 +14,7 @@ import (
const (
jobModifyIndexHelp = `To submit the job with version verification run:
nomad run -check-index %d %s
nomad job run -check-index %d %s
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has

View File

@@ -13,7 +13,7 @@ This guide covers the JSON syntax for submitting jobs to Nomad. A useful command
for generating valid JSON versions of HCL jobs is:
```shell
$ nomad run -output my-job.nomad
$ nomad job run -output my-job.nomad
```
## Syntax

View File

@@ -20,10 +20,11 @@ starting the Nomad server. The key can be set via the
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
[`nomad keygen`](/docs/commands/keygen.html) command to generate a cryptographically suitable key:
[`nomad operator keygen`](/docs/commands/operator/keygen.html) command to
generate a cryptographically suitable key:
```sh
$ nomad keygen
$ nomad operator keygen
cg8StVXbQJ0gPvMd9o7yrg==
```

View File

@@ -93,7 +93,7 @@ leave the [consensus](/docs/internals/consensus.html) peer set.
It is especially important that a server node be allowed to leave gracefully
so that there will be a minimal impact on availability as the server leaves
the consensus peer set. If a server does not gracefully leave, and will not
return into service, the [`server-force-leave` command](/docs/commands/server-force-leave.html)
return into service, the [`server force-leave` command](/docs/commands/server/force-leave.html)
should be used to eject it from the consensus peer set.
## Lifecycle
@@ -125,7 +125,7 @@ participate in a [gossip protocol](/docs/internals/gossip.html) both to cluster
within a region and to support multi-region configurations. When a server is
first started, it does not know the address of other servers in the cluster.
To discover its peers, it must _join_ the cluster. This is done with the
[`server-join` command](/docs/commands/server-join.html) or by providing the
[`server join` command](/docs/commands/server/join.html) or by providing the
proper configuration on start. Once a node joins, this information is gossiped
to the entire cluster, meaning all nodes will eventually be aware of each other.

View File

@@ -6,9 +6,7 @@ description: >
The acl command is used to interact with ACL policies and tokens.
---
# Nomad ACL
Command: `nomad acl`
# Command: acl
The `acl` command is used to interact with ACL policies and tokens.

View File

@@ -30,7 +30,7 @@ prefix.
* `-detach`: Return immediately instead of monitoring. A new evaluation ID
will be output, which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command.
[eval status](/docs/commands/eval-status.html) command.
* `-verbose`: Show full information.

View File

@@ -40,7 +40,7 @@ select particular groups to promote.
* `-detach`: Return immediately instead of monitoring. A new evaluation ID
will be output, which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command
[eval status](/docs/commands/eval-status.html) command
* `-verbose`: Show full information.

View File

@@ -29,7 +29,7 @@ prefix.
* `-detach`: Return immediately instead of monitoring. A new evaluation ID
will be output, which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command
[eval status](/docs/commands/eval-status.html) command
* `-verbose`: Show full information.

View File

@@ -1,6 +1,6 @@
---
layout: "docs"
page_title: "Commands: eval-status"
page_title: "Commands: eval status"
sidebar_current: "docs-commands-eval-status"
description: >
The eval status command is used to see the status and potential failed

View File

@@ -42,10 +42,10 @@ the CLI is most commonly used to manipulate or query jobs, you can assume that
any given command is working in that context unless the command name implies
otherwise.
For example, the `nomad run` command is used to run a new job, the `nomad
For example, the `nomad job run` command is used to run a new job, the `nomad
status` command queries information about existing jobs, etc. Conversely,
commands with a prefix in their name likely operate in a different context.
Examples include the `nomad agent-info` or `nomad node-drain` commands,
Examples include the `nomad agent-info` or `nomad node drain` commands,
which operate in the agent or node contexts respectively.
### Remote Usage

View File

@@ -6,10 +6,8 @@ description: >
The job command is used to interact with jobs.
---
# Nomad Job
# Command: job
Command: `nomad job`
The `job` command is used to interact with jobs.
## Usage

View File

@@ -54,7 +54,7 @@ client connection issues or internal errors, are indicated by exit code 1.
* `-detach`: Return immediately instead of monitoring. A new evaluation ID
will be output, which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command
[eval status](/docs/commands/eval-status.html) command
* `-verbose`: Show full information.

View File

@@ -35,8 +35,8 @@ changes to the cluster but gives insight into whether the job could be run
successfully and how it would affect existing allocations.
A job modify index is returned with the plan. This value can be used when
submitting the job using [`nomad run
-check-index`](/docs/commands/run.html#check-index), which will check that the
submitting the job using [`nomad job run
-check-index`](/docs/commands/job/run.html#check-index), which will check that the
job was not modified between the plan and run command before invoking the
scheduler. This ensures the job has not been modified since the plan.
@@ -82,7 +82,7 @@ Scheduler dry-run:
Job Modify Index: 0
To submit the job with version verification run:
nomad run -check-index 0 example.nomad
nomad job run -check-index 0 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
@@ -109,7 +109,7 @@ Scheduler dry-run:
Job Modify Index: 15
To submit the job with version verification run:
nomad run -check-index 15 example.nomad
nomad job run -check-index 15 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
@@ -136,7 +136,7 @@ Scheduler dry-run:
Job Modify Index: 7
To submit the job with version verification run:
nomad run -check-index 7 example.nomad
nomad job run -check-index 7 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
@@ -195,7 +195,7 @@ Scheduler dry-run:
Job Modify Index: 7
To submit the job with version verification run:
nomad run -check-index 7 example.nomad
nomad job run -check-index 7 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has

View File

@@ -40,7 +40,7 @@ select particular groups to promote.
* `-detach`: Return immediately instead of monitoring. A new evaluation ID
will be output, which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command
[eval status](/docs/commands/eval-status.html) command
* `-verbose`: Show full information.

View File

@@ -29,7 +29,7 @@ to revert to.
* `-detach`: Return immediately instead of monitoring. A new evaluation ID
will be output, which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command
[eval status](/docs/commands/eval-status.html) command
* `-verbose`: Show full information.

View File

@@ -55,11 +55,11 @@ precedence, going from highest to lowest: the `-vault-token` flag, the
If a check-index value of zero is passed, the job is only registered if it does
not yet exist. If a non-zero value is passed, it ensures that the job is being
updated from a known state. The use of this flag is most common in conjunction
with [plan command](/docs/commands/plan.html).
with [`job plan` command](/docs/commands/job/plan.html).
* `-detach`: Return immediately instead of monitoring. A new evaluation ID
will be output, which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command
[eval status](/docs/commands/eval-status.html) command
* `-output`: Output the JSON that would be submitted to the HTTP API without
submitting the job.

View File

@@ -36,7 +36,7 @@ the request. It is safe to exit the monitor early using ctrl+c.
* `-detach`: Return immediately instead of entering monitor mode. After the
deregister command is submitted, a new evaluation ID is printed to the screen,
which can be used to examine the evaluation using the
[eval-status](/docs/commands/eval-status.html) command.
[eval status](/docs/commands/eval-status.html) command.
* `-verbose`: Show full information.

View File

@@ -6,12 +6,13 @@ description: >
The namespace command is used to interact with namespaces.
---
# Nomad Namespace
Command: `nomad namespace`
# Command: namespace
The `namespace` command is used to interact with namespaces.
~> Namespace commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
Usage: `nomad namespace <subcommand> [options]`

View File

@@ -12,6 +12,9 @@ description: >
The `namespace inspect` command is used to view raw information about a particular
namespace.
~> Namespace commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -12,6 +12,9 @@ description: >
The `namespace status` command is used to view the status of a particular
namespace.
~> Namespace commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -1,6 +1,6 @@
---
layout: "docs"
page_title: "Commands: node-drain"
page_title: "Commands: node drain"
sidebar_current: "docs-commands-node-drain"
description: >
The node drain command is used to configure a node's drain strategy.

View File

@@ -1,6 +1,6 @@
---
layout: "docs"
page_title: "Commands: node-status"
page_title: "Commands: node status"
sidebar_current: "docs-commands-node-status"
description: >
The node status command is used to display information about nodes.

View File

@@ -6,9 +6,7 @@ description: >
The operator command provides cluster-level tools for Nomad operators.
---
# Nomad Operator
Command: `nomad operator`
# Command: operator
The `operator` command provides cluster-level tools for Nomad operators, such
as interacting with the Raft subsystem. This was added in Nomad 0.5.5.

View File

@@ -6,7 +6,7 @@ description: >
Display the current Autopilot configuration.
---
# Command: `operator autopilot get-config`
# Command: operator autopilot get-config
The Autopilot operator command is used to view the current Autopilot configuration. See the
[Autopilot Guide](/guides/cluster/autopilot.html) for more information about Autopilot.
@@ -60,4 +60,4 @@ UpgradeMigrationTag = ""
- `UpgradeVersionTag` - Controls the node-meta key to use for
version info when performing upgrade migrations. If left blank, the Nomad
version will be used.
version will be used.

View File

@@ -6,7 +6,7 @@ description: >
Modify the current Autopilot configuration.
---
# Command: `operator autopilot set-config`
# Command: operator autopilot set-config
The Autopilot operator command is used to set the current Autopilot configuration. See the
[Autopilot Guide](/guides/cluster/autopilot.html) for more information about Autopilot.

View File

@@ -8,7 +8,7 @@ description: >
cryptographically strong pseudo-random number generator to generate the key.
---
# Command: `operator keygen`
# Command: operator keygen
The `operator keygen` command generates an encryption key that can be used for Nomad
server's gossip traffic encryption. The keygen command uses a cryptographically

View File

@@ -4,7 +4,7 @@ page_title: "Commands: operator keyring"
sidebar_current: "docs-commands-operator-keyring"
---
# Command: `operator keyring`
# Command: operator keyring
The `operator keyring` command is used to examine and modify the encryption keys
used in Nomad server. It is capable of distributing new encryption keys to the

View File

@@ -6,7 +6,7 @@ description: >
Display the current Raft peer configuration.
---
# Command: `operator raft list-peers`
# Command: operator raft list-peers
The Raft list-peers command is used to display the current Raft peer
configuration.

View File

@@ -6,7 +6,7 @@ description: >
Remove a Nomad server from the Raft configuration.
---
# Command: `operator raft remove-peer`
# Command: operator raft remove-peer
Remove the Nomad server with given address from the Raft configuration.
@@ -14,9 +14,9 @@ There are rare cases where a peer may be left behind in the Raft quorum even
though the server is no longer present and known to the cluster. This command
can be used to remove the failed server so that it is no longer affects the Raft
quorum. If the server still shows in the output of the [`nomad
server-members`](/docs/commands/server-members.html) command, it is preferable
server members`](/docs/commands/server/members.html) command, it is preferable
to clean up by simply running [`nomad
server-force-leave`](/docs/commands/server-force-leave.html) instead of this
server force-leave`](/docs/commands/server/force-leave.html) instead of this
command.
See the [Outage Recovery](/guides/outage.html) guide for some examples of how

View File

@@ -6,12 +6,13 @@ description: >
The quota command is used to interact with quota specifications.
---
# Nomad Quota
Command: `nomad quota`
# Command: quota
The `quota` command is used to interact with quota specifications.
~> Quota commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
Usage: `nomad quota <subcommand> [options]`

View File

@@ -10,6 +10,9 @@ description: >
The `quota apply` command is used to create or update quota specifications.
~> Quota commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -10,6 +10,9 @@ description: >
The `quota delete` command is used to delete an existing quota specification.
~> Quota commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -11,6 +11,9 @@ description: >
The `quota init` command is used to create an example quota specification file
that can be used as a starting point to customize further.
~> Quota commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -12,6 +12,9 @@ description: >
The `quota inspect` command is used to view raw information about a particular
quota.
~> Quota commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -10,6 +10,9 @@ description: >
The `quota list` command is used to list available quota specifications.
~> Quota commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -12,6 +12,9 @@ description: >
The `quota status` command is used to view the status of a particular quota
specification.
~> Quota commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -6,12 +6,13 @@ description: >
The sentinel command is used to interact with Sentinel policies.
---
# Nomad Sentinel
Command: `nomad sentinel`
# Command: sentinel
The `sentinel` command is used to interact with Sentinel policies.
~> Sentinel commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
Usage: `nomad sentinel <subcommand> [options]`

View File

@@ -10,6 +10,9 @@ description: >
The `sentinel apply` command is used to write a new, or update an existing, Sentinel policy.
~> Sentinel commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -10,6 +10,9 @@ description: >
The `sentinel delete` command is used to delete a Sentinel policy.
~> Sentinel commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -10,6 +10,9 @@ description: >
The `sentinel list` command is used to display all the installed Sentinel policies.
~> Sentinel commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -10,6 +10,9 @@ description: >
The `sentinel read` command is used to inspect a Sentinel policy.
~> Sentinel commands are new in Nomad 0.7 and are only available with Nomad
Enterprise.
## Usage
```

View File

@@ -1,6 +1,6 @@
---
layout: "docs"
page_title: "Commands: server-members"
page_title: "Commands: server members"
sidebar_current: "docs-commands-server-members"
description: >
The server members command is used to display a list of the known server members and their status.

View File

@@ -212,7 +212,7 @@ job "docs" {
When submitting this job, you would run:
```
$ VAULT_TOKEN="..." nomad run example.nomad
$ VAULT_TOKEN="..." nomad job run example.nomad
```
[constraint]: /docs/job-specification/constraint.html "Nomad constraint Job Specification"

View File

@@ -47,7 +47,7 @@ job "docs" {
```
For information on how to interact with logs after they have been configured,
please see the [`nomad logs`][logs-command] command.
please see the [`nomad alloc logs`][logs-command] command.
## `logs` Parameters
@@ -87,4 +87,4 @@ logs {
}
```
[logs-command]: /docs/commands/logs.html "Nomad logs command"
[logs-command]: /docs/commands/alloc/logs.html "Nomad logs command"

View File

@@ -4,8 +4,8 @@ page_title: "Accessing Logs - Operating a Job"
sidebar_current: "docs-operating-a-job-accessing-logs"
description: |-
Nomad provides a top-level mechanism for viewing application logs and data
files via the command line interface. This section discusses the nomad logs
command and API interface.
files via the command line interface. This section discusses the nomad alloc
logs command and API interface.
---
# Accessing Logs
@@ -15,7 +15,7 @@ problems, or even just verifying the application started correctly. To make this
as simple as possible, Nomad provides:
- Job specification for [log rotation](/docs/job-specification/logs.html)
- CLI command for [log viewing](/docs/commands/logs.html)
- CLI command for [log viewing](/docs/commands/alloc/logs.html)
- API for programatic [log access](/api/client.html#stream-logs)
This section will utilize the job named "docs" from the [previous
@@ -25,7 +25,7 @@ and command largely apply to all jobs in Nomad.
As a reminder, here is the output of the run command from the previous example:
```text
$ nomad run docs.nomad
$ nomad job run docs.nomad
==> Monitoring evaluation "42d788a3"
Evaluation triggered by job "docs"
Allocation "04d9627d" created: node "a1f934c9", group "example"
@@ -40,7 +40,7 @@ command) is required to access the application's logs. To access the logs of our
application, we issue the following command:
```shell
$ nomad logs 04d9627d
$ nomad alloc logs 04d9627d
```
The output will look something like this:
@@ -55,7 +55,7 @@ By default, this will return the logs of the task. If more than one task is
defined in the job file, the name of the task is a required argument:
```shell
$ nomad logs 04d9627d server
$ nomad alloc logs 04d9627d server
```
The logs command supports both displaying the logs as well as following logs,
@@ -63,7 +63,7 @@ blocking for more output, similar to `tail -f`. To follow the logs, use the
appropriately named `-f` flag:
```shell
$ nomad logs -f 04d9627d
$ nomad alloc logs -f 04d9627d
```
This will stream logs to our console.
@@ -71,7 +71,7 @@ This will stream logs to our console.
If you wish to see only the tail of a log, use the `-tail` and `-n` flags:
```shell
$ nomad logs -tail -n 25 04d9627d
$ nomad alloc logs -tail -n 25 04d9627d
```
This will show the last 25 lines. If you omit the `-n` flag, `-tail` will
default to 10 lines.
@@ -80,7 +80,7 @@ By default, only the logs on stdout are displayed. To show the log output from
stderr, use the `-stderr` flag:
```shell
$ nomad logs -stderr 04d9627d
$ nomad alloc logs -stderr 04d9627d
```
## Log Shipper Pattern

View File

@@ -105,14 +105,14 @@ In the above example we see that the job has a "blocked" evaluation that is in
progress. When Nomad can not place all the desired allocations, it creates a
blocked evaluation that waits for more resources to become available.
The `eval-status` command enables us to examine any evaluation in more detail.
The `eval status` command enables us to examine any evaluation in more detail.
For the most part this should never be necessary but can be useful to see why
all of a job's allocations were not placed. For example if we run it on the job
named docs, which had a placement failure according to the above output, we
might see:
```text
$ nomad eval-status 8e38e6cf
$ nomad eval status 8e38e6cf
ID = 8e38e6cf
Status = complete
Status Description = complete
@@ -130,17 +130,17 @@ Task Group "example" (failed to place 3 allocations):
Evaluation "5744eb15" waiting for additional capacity to place remainder
```
For more information on the `eval-status` command, please see the [CLI documentation for <tt>eval-status</tt>](/docs/commands/eval-status.html).
For more information on the `eval status` command, please see the [CLI documentation for <tt>eval status</tt>](/docs/commands/eval-status.html).
## Allocation Status
You can think of an allocation as an instruction to schedule. Just like an
application or service, an allocation has logs and state. The `alloc-status`
application or service, an allocation has logs and state. The `alloc status`
command gives us the most recent events that occurred for a task, its resource
usage, port allocations and more:
```text
$ nomad alloc-status 04d9627d
$ nomad alloc status 04d9627d
ID = 04d9627d
Eval ID = 42d788a3
Name = docs.example[2]
@@ -159,16 +159,16 @@ Time Type Description
10/09/16 00:36:05 UTC Received Task received by client
```
The `alloc-status` command is a good starting to point for debugging an
The `alloc status` command is a good starting to point for debugging an
application that did not start. Hypothetically assume a user meant to start a
Docker container named "redis:2.8", but accidentally put a comma instead of a
period, typing "redis:2,8".
When the job is executed, it produces a failed allocation. The `alloc-status`
When the job is executed, it produces a failed allocation. The `alloc status`
command will give us the reason why:
```text
$ nomad alloc-status 04d9627d
$ nomad alloc status 04d9627d
# ...
Recent Events:
@@ -178,12 +178,12 @@ Time Type Description
06/28/16 15:50:22 UTC Received Task received by client
```
Unfortunately not all failures are as easily debuggable. If the `alloc-status`
Unfortunately not all failures are as easily debuggable. If the `alloc status`
command shows many restarts, there is likely an application-level issue during
start up. For example:
```text
$ nomad alloc-status 04d9627d
$ nomad alloc status 04d9627d
# ...
Recent Events:
@@ -201,5 +201,5 @@ To debug these failures, we will need to utilize the "logs" command, which is
discussed in the [accessing logs](/docs/operating-a-job/accessing-logs.html)
section of this documentation.
For more information on the `alloc-status` command, please see the [CLI
documentation for <tt>alloc-status</tt>](/docs/commands/alloc-status.html).
For more information on the `alloc status` command, please see the [CLI
documentation for <tt>alloc status</tt>](/docs/commands/alloc/status.html).

View File

@@ -12,7 +12,7 @@ description: |-
Understanding the resource utilization of an application is important, and Nomad
supports reporting detailed statistics in many of its drivers. The main
interface for seeing resource utilization is the `alloc-status` command with the
interface for seeing resource utilization is the `alloc status` command with the
`-stats` flag.
This section will utilize the job named "docs" from the [previous
@@ -22,7 +22,7 @@ and command largely apply to all jobs in Nomad.
As a reminder, here is the output of the run command from the previous example:
```text
$ nomad run docs.nomad
$ nomad job run docs.nomad
==> Monitoring evaluation "42d788a3"
Evaluation triggered by job "docs"
Allocation "04d9627d" created: node "a1f934c9", group "example"
@@ -35,7 +35,7 @@ $ nomad run docs.nomad
To see the detailed usage statistics, we can issue the command:
```shell
$ nomad alloc-status -stats 04d9627d
$ nomad alloc status -stats 04d9627d
ID = 04d9627d
Eval ID = 42d788a3
Name = docs.example[2]

View File

@@ -65,12 +65,12 @@ especially if you are working in a team.
## Planning the Job
Once the job file is authored, we need to plan out the changes. The `nomad plan`
Once the job file is authored, we need to plan out the changes. The `nomad job plan`
command invokes a dry-run of the scheduler and inform us of which scheduling
decisions would take place.
```text
$ nomad plan docs.nomad
$ nomad job plan docs.nomad
+ Job: "docs"
+ Task Group: "example" (1 create)
+ Task: "server" (forces create)
@@ -81,7 +81,7 @@ Scheduler dry-run:
Job Modify Index: 0
To submit the job with version verification run:
nomad run -check-index 0 docs.nomad
nomad job run -check-index 0 docs.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
@@ -95,12 +95,12 @@ dry-run and no allocations have taken place.
## Submitting the Job
Assuming the output of the plan looks acceptable, we can ask Nomad to execute
this job. This is done via the `nomad run` command. We can optionally supply
this job. This is done via the `nomad job run` command. We can optionally supply
the modify index provided to us by the plan command to ensure no changes to this
job have taken place between our plan and now.
```text
$ nomad run docs.nomad
$ nomad job run docs.nomad
==> Monitoring evaluation "0d159869"
Evaluation triggered by job "docs"
Allocation "5cbf23a1" created: node "1e1aa1e0", group "example"
@@ -132,7 +132,7 @@ then the run command. For example:
After we save these changes to disk, run the plan command:
```text
$ nomad plan docs.nomad
$ nomad job plan docs.nomad
+/- Job: "docs"
+/- Task Group: "example" (2 create, 1 in-place update)
+/- Count: "1" => "3" (forces create)
@@ -144,7 +144,7 @@ Scheduler dry-run:
Job Modify Index: 131
To submit the job with version verification run:
nomad run -check-index 131 docs.nomad
nomad job run -check-index 131 docs.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
@@ -157,7 +157,7 @@ including the "check-index" parameter. This will ensure that no remote changes
have taken place to the job between our plan and run phases.
```text
nomad run -check-index 131 docs.nomad
nomad job run -check-index 131 docs.nomad
==> Monitoring evaluation "42d788a3"
Evaluation triggered by job "docs"
Allocation "04d9627d" created: node "a1f934c9", group "example"

View File

@@ -76,7 +76,7 @@ can see how this works by changing the image to run the new version:
Next we plan and run these changes:
```text
$ nomad plan docs.nomad
$ nomad job plan docs.nomad
+/- Job: "docs"
+/- Task Group: "api" (5 canary, 5 ignore)
+/- Task: "api-server" (forces create/destroy update)
@@ -90,14 +90,14 @@ Scheduler dry-run:
Job Modify Index: 7
To submit the job with version verification run:
nomad run -check-index 7 example.nomad
nomad job run -check-index 7 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
changed, another user has modified the job and the plan's results are
potentially invalid.
$ nomad run docs.nomad
$ nomad job run docs.nomad
# ...
```
@@ -334,7 +334,7 @@ changing the image to run the new version:
Next we plan and run these changes:
```text
$ nomad plan docs.nomad
$ nomad job plan docs.nomad
+/- Job: "docs"
+/- Task Group: "api" (1 canary, 5 ignore)
+/- Task: "api-server" (forces create/destroy update)
@@ -348,14 +348,14 @@ Scheduler dry-run:
Job Modify Index: 7
To submit the job with version verification run:
nomad run -check-index 7 example.nomad
nomad job run -check-index 7 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
changed, another user has modified the job and the plan's results are
potentially invalid.
$ nomad run docs.nomad
$ nomad job run docs.nomad
# ...
```

View File

@@ -86,12 +86,12 @@ that is configured with the same rolling update strategy from above.
+ image = "geo-api-server:0.2"
```
The [`nomad plan` command](/docs/commands/plan.html) allows
The [`nomad job plan` command](/docs/commands/job/plan.html) allows
us to visualize the series of steps the scheduler would perform. We can analyze
this output to confirm it is correct:
```text
$ nomad plan geo-api-server.nomad
$ nomad job plan geo-api-server.nomad
+/- Job: "geo-api-server"
+/- Task Group: "api-server" (2 create/destroy update, 4 ignore)
+/- Task: "server" (forces create/destroy update)
@@ -105,7 +105,7 @@ Scheduler dry-run:
Job Modify Index: 7
To submit the job with version verification run:
nomad run -check-index 7 my-web.nomad
nomad job run -check-index 7 my-web.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has

View File

@@ -68,7 +68,7 @@ Nomad makes the following directories available to tasks:
* `local/`: This directory is private to each task. It can be used to store
arbitrary data that should not be shared by tasks in the task group.
* `secrets/`: This directory is private to each task, not accessible via the
`nomad fs` command or filesystem APIs and where possible backed by an
`nomad alloc fs` command or filesystem APIs and where possible backed by an
in-memory filesystem. It can be used to store secret data that should not be
visible outside the task.

View File

@@ -75,7 +75,7 @@ raft
Continue with the upgrades across the Server fleet making sure to do a single Nomad
server at a time. You can check state of the servers and clients with the
`nomad server-members` and `nomad node-status` commands which indicate state of the
`nomad server members` and `nomad node status` commands which indicate state of the
nodes.
### 3. Remove the old versions from servers
@@ -87,9 +87,9 @@ If you are doing an upgrade by adding new servers and removing old servers
from the fleet you need to ensure that the server has left the fleet safely.
1. Stop the service on the existing host
2. On another server issue a `nomad server-members` and check the status, if
2. On another server issue a `nomad server members` and check the status, if
the server is now in a left state you are safe to continue.
3. If the server is not in a left state, issue a `nomad server-force-leave <server id>`
3. If the server is not in a left state, issue a `nomad server force-leave <server id>`
to remove the server from the cluster.
Monitor the logs of the other hosts in the Nomad cluster over this period.
@@ -102,15 +102,15 @@ Use the same actions in step #2 above to confirm cluster health.
Following the successful upgrade of the servers you can now update your
clients using a similar process as the servers. If you wish to gracefully
move tasks on a client use the `nomad node-drain <node-id>` command to
gracefully migrate jobs to another client in the cluster. The `node-drain`
move tasks on a client use the `nomad node drain <node-id>` command to
gracefully migrate jobs to another client in the cluster. The `node drain`
command prevents new tasks from being allocated to the client and begins
migrating existing allocations to another client.
## Done!
You are now running the latest Nomad version. You can verify all
Clients joined by running `nomad node-status` and checking all the clients
Clients joined by running `nomad node status` and checking all the clients
are in a `ready` state.
## Upgrading to Nomad Enterprise

View File

@@ -156,6 +156,6 @@ be resubmitted with the updated job syntax using a Nomad 0.3.0 binary.
After updating the Servers and job files, Nomad Clients can be upgraded by first
draining the node so no tasks are running on it. This can be verified by running
`nomad node-status <node-id>` and verify there are no tasks in the `running`
`nomad node status <node-id>` and verify there are no tasks in the `running`
state. Once that is done the client can be killed, the `data_dir` should be
deleted and then Nomad 0.3.0 can be launched.

View File

@@ -203,7 +203,7 @@ To check the Nomad version of the servers, either the [autopilot health]
command can be used:
```
$ nomad server-members
$ nomad server members
Name Address Port Status Leader Protocol Build Datacenter Region
node1 127.0.0.1 4648 alive true 3 0.7.1 dc1 global
node2 127.0.0.1 4748 alive false 3 0.7.1 dc1 global

View File

@@ -3,7 +3,7 @@ layout: "guides"
page_title: "Manually Bootstrapping a Nomad Cluster"
sidebar_current: "guides-cluster-manual"
description: |-
Learn how to manually bootstrap a Nomad cluster using the server-join
Learn how to manually bootstrap a Nomad cluster using the server join
command. This section also discusses Nomad federation across multiple
datacenters and regions.
---
@@ -36,12 +36,12 @@ server {
```
Alternatively, the address can be supplied after the servers have all been
started by running the [`server-join` command](/docs/commands/server-join.html)
started by running the [`server join` command](/docs/commands/server/join.html)
on the servers individually to cluster the servers. All servers can join just
one other server, and then rely on the gossip protocol to discover the rest.
```
$ nomad server-join <known-address>
$ nomad server join <known-address>
```
For Nomad clients, the configuration may look something like:
@@ -53,8 +53,12 @@ client {
}
```
At this time, there is no equivalent of the <tt>server-join</tt> command for
Nomad clients.
The client node's server list can be updated at run time using the [`node
config` command](/docs/commands/node/config.html).
```
$ nomad node config -update-servers <IP>:4647
```
The port corresponds to the RPC port. If no port is specified with the IP
address, the default RPC port of `4647` is assumed.

View File

@@ -48,10 +48,10 @@ to a fully healthy state.
Both of these strategies involve a potentially lengthy time to reboot or rebuild
a failed server. If this is impractical or if building a new server with the same
IP isn't an option, you need to remove the failed server. Usually, you can issue
a [`nomad server-force-leave`](/docs/commands/server-force-leave.html) command
a [`nomad server force-leave`](/docs/commands/server/force-leave.html) command
to remove the failed server if it's still a member of the cluster.
If [`nomad server-force-leave`](/docs/commands/server-force-leave.html) isn't
If [`nomad server force-leave`](/docs/commands/server/force-leave.html) isn't
able to remove the server, you have two methods available to remove it,
depending on your version of Nomad:
@@ -92,7 +92,7 @@ once the remaining servers are all restarted with an identical `raft/peers.json`
configuration.
Any new servers you introduce later can be fresh with totally clean data directories
and joined using Nomad's `server-join` command.
and joined using Nomad's `server join` command.
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
@@ -158,10 +158,10 @@ later you will see them ingest recovery file:
```
If any servers managed to perform a graceful leave, you may need to have them
rejoin the cluster using the [`server-join`](/docs/commands/server-join.html) command:
rejoin the cluster using the [`server join`](/docs/commands/server/join.html) command:
```text
$ nomad server-join <Node Address>
$ nomad server join <Node Address>
Successfully joined cluster by contacting 1 nodes.
```

View File

@@ -105,10 +105,10 @@ Successfully applied namespace "default"!
Lets now run a job in the default namespace now that we have attached a quota:
```
$ nomad init
$ nomad job init
Example job file written to example.nomad
$ nomad run -detach example.nomad
$ nomad job run -detach example.nomad
Job registration successful
Evaluation ID: 985a1df8-0221-b891-5dc1-4d31ad4e2dc3
@@ -128,7 +128,7 @@ scale up the job from `count = 1` to `count = 4`:
```
# Change count
$ nomad run -detach example.nomad
$ nomad job run -detach example.nomad
Job registration successful
Evaluation ID: ce8e1941-0189-b866-3dc4-7cd92dc38a69

View File

@@ -288,7 +288,7 @@ $ # ...and in another
$ nomad agent -config client1.hcl
```
If you run `nomad node-status` now, you'll get an error, like:
If you run `nomad node status` now, you'll get an error, like:
```text
Error querying node status: Get http://127.0.0.1:4646/v1/nodes: malformed HTTP response "\x15\x03\x01\x00\x02\x02"
@@ -299,7 +299,7 @@ HTTPS. We can configure the local Nomad client to connect using TLS and specify
our custom keys and certificates using the command line:
```shell
$ nomad node-status -ca-cert=nomad-ca.pem -client-cert=cli.pem -client-key=cli-key.pem -address=https://127.0.0.1:4646
$ nomad node status -ca-cert=nomad-ca.pem -client-cert=cli.pem -client-key=cli-key.pem -address=https://127.0.0.1:4646
```
This process can be cumbersome to type each time, so the Nomad CLI also
@@ -325,13 +325,13 @@ After these environment variables are correctly configured, the CLI will
respond as expected:
```text
$ nomad node-status
$ nomad node status
ID DC Name Class Drain Status
237cd4c5 dc1 nomad <none> false ready
$ nomad init
$ nomad job init
Example job file written to example.nomad
vagrant@nomad:~$ nomad run example.nomad
vagrant@nomad:~$ nomad job run example.nomad
==> Monitoring evaluation "e9970e1d"
Evaluation triggered by job "example"
Allocation "a1f6c3e7" created: node "237cd4c5", group "cache"
@@ -355,11 +355,11 @@ This encryption key must be added to every server's configuration using the
[`encrypt`](/docs/agent/configuration/server.html#encrypt) parameter or with
the [`-encrypt` command line option](/docs/commands/agent.html).
The Nomad CLI includes a `keygen` command for generating a new secure gossip
The Nomad CLI includes a `operator keygen` command for generating a new secure gossip
encryption key:
```text
$ nomad keygen
$ nomad operator keygen
cg8StVXbQJ0gPvMd9o7yrg==
```

View File

@@ -88,13 +88,13 @@ $ nomad sentinel apply -level=advisory test-policy test.sentinel
Successfully wrote "test-policy" Sentinel policy!
```
Use `nomad init` to create a job file and attempt to submit it:
Use `nomad job init` to create a job file and attempt to submit it:
```
$ nomad init
$ nomad job init
Example job file written to example.nomad
$ nomad run example.nomad
$ nomad job run example.nomad
Job Warnings:
1 warning(s):
@@ -161,7 +161,7 @@ Because our policy is failing, the job was rejected. Since this is a `soft-manda
submit with the `-policy-override` flag set:
```
$ nomad run -policy-override example.nomad
$ nomad job run -policy-override example.nomad
Job Warnings:
1 warning(s):

View File

@@ -66,7 +66,7 @@ An alternative to using the default template is to set the
containing a custom job template. There are two important considerations:
* The template must use the JSON format. You can convert an HCL jobspec to
JSON by running `nomad run -output <job.nomad>`.
JSON by running `nomad job run -output <job.nomad>`.
* `spark.nomad.job.template` should be set to a path on the submitting
machine, not to a URL (even in cluster mode). The template does not need to

View File

@@ -121,10 +121,10 @@ Another viable option for DataNode task group is to use a dedicated
This will deploy a DataNode to every client node in the system, which may or may
not be desirable depending on your use case.
The HDFS job can be deployed using the `nomad run` command:
The HDFS job can be deployed using the `nomad job run` command:
```shell
$ nomad run hdfs.nomad
$ nomad job run hdfs.nomad
```
## Production Deployment Considerations

View File

@@ -95,7 +95,7 @@ $ hdfs dfs -fs hdfs://hdfs.service.consul:8020 -mkdir /spark-events
You can then deploy the history server with:
```shell
$ nomad run spark-history-server-hdfs.nomad
$ nomad job run spark-history-server-hdfs.nomad
```
You can get the private IP for the history server with a Consul DNS lookup:

View File

@@ -319,13 +319,13 @@ description: |-
<span>&nbsp;</span>
<span>
<span class="text-green">admin@hashicorp.com:</span>
<span>nomad validate example.nomad</span>
<span>nomad job validate example.nomad</span>
</span>
<span>Job validation successful</span>
<span>&nbsp;</span>
<span>
<span class="text-green">admin@hashicorp.com:</span>
<span>nomad run example.nomad</span>
<span>nomad job run example.nomad</span>
</span>
<span>==> Monitoring evaluation "feb23392"</span>
<span class="pre"> Evaluation triggered by job "example"</span>
@@ -364,7 +364,7 @@ description: |-
<div class="terminal-content">
<span>
<span class="text-green">admin@hashicorp.com:</span>
<span>nomad plan example.nomad</span>
<span>nomad job plan example.nomad</span>
</span>
<span class="pre"><span class="text-orange">+/-</span> <span class="text-bold">Job: "example"</span></span>
<span class="pre"><span class="text-bold text-orange">+/-</span> <span class="text-bold">Task Group: "cache"</span> (<span class="text-green">2 create</span>, <span class="text-blue">1 in-place update</span>)</span>
@@ -378,7 +378,7 @@ description: |-
<span>&nbsp;</span>
<span>
<span class="text-green">admin@hashicorp.com:</span>
<span>nomad run -check-index 7 example.nomad</span>
<span>nomad job run -check-index 7 example.nomad</span>
</span>
<span>==> Monitoring evaluation "e338a6ae"</span>
<span class="pre"> Evaluation triggered by job "example"</span>
@@ -412,7 +412,7 @@ description: |-
<div class="terminal-content">
<span>
<span class="text-green">admin@hashicorp.com:</span>
<span>nomad logs -tail -job example</span>
<span>nomad alloc logs -tail -job example</span>
</span>
<span><%= Time.now.strftime("%d %b %H:%M:%S") %> # Server started, Redis version 3.2.9</span>
<span><%= Time.now.strftime("%d %b %H:%M:%S") %> * The server is now ready to accept connections on port 6379</span>

View File

@@ -135,11 +135,11 @@ In the output we can see the agent is running in client mode only.
This agent will be available to run tasks but will not participate
in managing the cluster or making scheduling decisions.
Using the [`node-status` command](/docs/commands/node-status.html)
Using the [`node status` command](/docs/commands/node/status.html)
we should see both nodes in the `ready` state:
```text
$ nomad node-status
$ nomad node status
ID Datacenter Name Class Drain Status
fca62612 dc1 nomad <none> false ready
c887deef dc1 nomad <none> false ready
@@ -155,10 +155,10 @@ Now that we have a simple cluster, we can use it to schedule a job.
We should still have the `example.nomad` job file from before, but
verify that the `count` is still set to 3.
Then, use the [`run` command](/docs/commands/run.html) to submit the job:
Then, use the [`job run` command](/docs/commands/job/run.html) to submit the job:
```text
$ nomad run example.nomad
$ nomad job run example.nomad
==> Monitoring evaluation "8e0a7cf9"
Evaluation triggered by job "example"
Evaluation within deployment: "0917b771"
@@ -209,7 +209,7 @@ ID Eval ID Node ID Task Group Desired Status Created At
We can see that all our tasks have been allocated and are running.
Once we are satisfied that our job is happily running, we can tear
it down with `nomad stop`.
it down with `nomad job stop`.
## Next Steps

View File

@@ -49,40 +49,29 @@ $ vagrant ssh
...
vagrant@nomad:~$ nomad
Usage: nomad [-version] [-help] [-autocomplete-(un)install] <command> [args]
Usage: nomad [-version] [-help] [-autocomplete-(un)install] <command> [<args>]
Common commands:
run Run a new job or update an existing job
stop Stop a running job
status Display the status output for a resource
alloc Interact with allocations
job Interact with jobs
node Interact with nodes
agent Runs a Nomad agent
Available commands are:
acl Interact with ACL policies and tokens
agent Runs a Nomad agent
agent-info Display status information about the local agent
alloc-status Display allocation status information and metadata
client-config View or modify client configuration details
deployment Interact with deployments
eval-status Display evaluation status and placement failure reasons
fs Inspect the contents of an allocation directory
init Create an example job file
inspect Inspect a submitted job
job Interact with jobs
keygen Generates a new encryption key
keyring Manages gossip layer encryption keys
logs Streams the logs of a task.
namespace Interact with namespaces
node-drain Toggle drain mode on a given node
node-status Display status information about nodes
operator Provides cluster-level tools for Nomad operators
plan Dry-run a job update to determine its effects
quota Interact with quotas
run Run a new job or update an existing job
sentinel Interact with Sentinel policies
server-force-leave Force a server into the 'left' state
server-join Join server nodes together
server-members Display a list of known servers and their status
status Display the status output for a resource
stop Stop a running job
ui Open the Nomad Web UI
validate Checks if a given job specification is valid
version Prints the Nomad version
Other commands:
acl Interact with ACL policies and tokens
agent-info Display status information about the local agent
deployment Interact with deployments
eval Interact with evaluations
namespace Interact with namespaces
operator Provides cluster-level tools for Nomad operators
quota Interact with quotas
sentinel Interact with Sentinel policies
server Interact with servers
ui Open the Nomad Web UI
version Prints the Nomad version
```
If you get an error that Nomad could not be found, then your Vagrant box

View File

@@ -19,25 +19,25 @@ however we recommend only using JSON when the configuration is generated by a ma
## Running a Job
To get started, we will use the [`init` command](/docs/commands/init.html) which
To get started, we will use the [`job init` command](/docs/commands/job/init.html) which
generates a skeleton job file:
```text
$ nomad init
$ nomad job init
Example job file written to example.nomad
```
You can view the contents of this file by running `cat example.nomad`. In this
example job file, we have declared a single task 'redis' which is using
the Docker driver to run the task. The primary way you interact with Nomad
is with the [`run` command](/docs/commands/run.html). The `run` command takes
is with the [`job run` command](/docs/commands/job/run.html). The `run` command takes
a job file and registers it with Nomad. This is used both to register new
jobs and to update existing jobs.
We can register our example job now:
```text
$ nomad run example.nomad
$ nomad job run example.nomad
==> Monitoring evaluation "13ebb66d"
Evaluation triggered by job "example"
Allocation "883269bf" created: node "e42d6f19", group "cache"
@@ -87,10 +87,10 @@ Here we can see that the result of our evaluation was the creation of an
allocation that is now running on the local node.
An allocation represents an instance of Task Group placed on a node. To inspect
an allocation we use the [`alloc-status` command](/docs/commands/alloc-status.html):
an allocation we use the [`alloc status` command](/docs/commands/alloc/status.html):
```text
$ nomad alloc-status 883269bf
$ nomad alloc status 883269bf
ID = 883269bf
Eval ID = 13ebb66d
Name = example.cache[0]
@@ -129,10 +129,10 @@ We can see that Nomad reports the state of the allocation as well as its
current resource usage. By supplying the `-stats` flag, more detailed resource
usage statistics will be reported.
To see the logs of a task, we can use the [logs command](/docs/commands/logs.html):
To see the logs of a task, we can use the [logs command](/docs/commands/alloc/logs.html):
```text
$ nomad logs 883269bf redis
$ nomad alloc logs 883269bf redis
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 3.2.1 (00000000/0) 64 bit
@@ -168,12 +168,12 @@ For now, edit the `example.nomad` file to update the count and set it to 3:
count = 3
```
Once you have finished modifying the job specification, use the [`plan`
command](/docs/commands/plan.html) to invoke a dry-run of the scheduler to see
Once you have finished modifying the job specification, use the [`job plan`
command](/docs/commands/job/plan.html) to invoke a dry-run of the scheduler to see
what would happen if you ran the updated job:
```text
$ nomad plan example.nomad
$ nomad job plan example.nomad
+/- Job: "example"
+/- Task Group: "cache" (2 create, 1 in-place update)
+/- Count: "1" => "3" (forces create)
@@ -185,7 +185,7 @@ Scheduler dry-run:
Job Modify Index: 7
To submit the job with version verification run:
nomad run -check-index 7 example.nomad
nomad job run -check-index 7 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
@@ -205,7 +205,7 @@ interacting with the job at the same time to ensure the job hasn't changed
before you apply your modifications.
```
$ nomad run -check-index 7 example.nomad
$ nomad job run -check-index 7 example.nomad
==> Monitoring evaluation "93d16471"
Evaluation triggered by job "example"
Evaluation within deployment: "0d06e1b6"
@@ -248,7 +248,7 @@ Scheduler dry-run:
Job Modify Index: 1127
To submit the job with version verification run:
nomad run -check-index 1127 example.nomad
nomad job run -check-index 1127 example.nomad
When running the job with the check-index flag, the job will only be run if the
server side version matches the job modify index returned. If the index has
@@ -264,7 +264,7 @@ a time.
Once ready, use `run` to push the updated specification:
```text
$ nomad run example.nomad
$ nomad job run example.nomad
==> Monitoring evaluation "293b313a"
Evaluation triggered by job "example"
Evaluation within deployment: "f4047b3a"
@@ -285,10 +285,10 @@ scale.
## Stopping a Job
So far we've created, run and modified a job. The final step in a job lifecycle
is stopping the job. This is done with the [`stop` command](/docs/commands/stop.html):
is stopping the job. This is done with the [`job stop` command](/docs/commands/job/stop.html):
```text
$ nomad stop example
$ nomad job stop example
==> Monitoring evaluation "6d4cd6ca"
Evaluation triggered by job "example"
Evaluation within deployment: "f4047b3a"

View File

@@ -74,14 +74,14 @@ certain task drivers will not be available.
## Cluster Nodes
If you run [`nomad node-status`](/docs/commands/node-status.html) in another terminal, you
can see the registered nodes of the Nomad cluster:
If you run [`nomad node status`](/docs/commands/node/status.html) in another
terminal, you can see the registered nodes of the Nomad cluster:
```text
$ vagrant ssh
...
$ nomad node-status
$ nomad node status
ID Datacenter Name Class Drain Status
171a583b dc1 nomad <none> false ready
```
@@ -94,10 +94,10 @@ currently off.
The agent is also running in server mode, which means it is part of
the [gossip protocol](/docs/internals/gossip.html) used to connect all
the server instances together. We can view the members of the gossip
ring using the [`server-members`](/docs/commands/server-members.html) command:
ring using the [`server members`](/docs/commands/server/members.html) command:
```text
$ nomad server-members
$ nomad server members
Name Address Port Status Leader Protocol Build Datacenter Region
nomad.global 127.0.0.1 4648 alive true 2 0.7.0 dc1 global
```
@@ -138,7 +138,7 @@ If an agent is operating as a server, a graceful leave is important to avoid
causing a potential availability outage affecting the
[consensus protocol](/docs/internals/consensus.html). If a server does
forcefully exit and will not be returning into service, the
[`server-force-leave` command](/docs/commands/server-force-leave.html) should
[`server force-leave` command](/docs/commands/server/force-leave.html) should
be used to force the server from a _failed_ to a _left_ state.
## Next Steps

View File

@@ -48,7 +48,7 @@ for the task group.
[![Nomad UI Task Group Detail][img-task-group-detail]][img-task-group-detail]
Click on the allocation in the allocations table. This page lists all tasks for an allocation as well
as the recent events for each task. It is similar to the `nomad alloc-status` command.
as the recent events for each task. It is similar to the `nomad alloc status` command.
[![Nomad UI Alloc Status][img-alloc-status]][img-alloc-status]

View File

@@ -177,34 +177,34 @@
<a href="/docs/commands/acl.html">acl</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-acl-bootstrap") %>>
<a href="/docs/commands/acl/bootstrap.html">acl bootstrap</a>
<a href="/docs/commands/acl/bootstrap.html">bootstrap</a>
</li>
<li<%= sidebar_current("docs-commands-acl-policy-apply") %>>
<a href="/docs/commands/acl/policy-apply.html">acl policy apply</a>
<a href="/docs/commands/acl/policy-apply.html">policy apply</a>
</li>
<li<%= sidebar_current("docs-commands-acl-policy-delete") %>>
<a href="/docs/commands/acl/policy-delete.html">acl policy delete</a>
<a href="/docs/commands/acl/policy-delete.html">policy delete</a>
</li>
<li<%= sidebar_current("docs-commands-acl-policy-info") %>>
<a href="/docs/commands/acl/policy-info.html">acl policy info</a>
<a href="/docs/commands/acl/policy-info.html">policy info</a>
</li>
<li<%= sidebar_current("docs-commands-acl-policy-list") %>>
<a href="/docs/commands/acl/policy-list.html">acl policy list</a>
<a href="/docs/commands/acl/policy-list.html">policy list</a>
</li>
<li<%= sidebar_current("docs-commands-acl-token-create") %>>
<a href="/docs/commands/acl/token-create.html">acl token create</a>
<a href="/docs/commands/acl/token-create.html">token create</a>
</li>
<li<%= sidebar_current("docs-commands-acl-token-delete") %>>
<a href="/docs/commands/acl/token-delete.html">acl token delete</a>
<a href="/docs/commands/acl/token-delete.html">token delete</a>
</li>
<li<%= sidebar_current("docs-commands-acl-token-info") %>>
<a href="/docs/commands/acl/token-info.html">acl token info</a>
<a href="/docs/commands/acl/token-info.html">token info</a>
</li>
<li<%= sidebar_current("docs-commands-acl-token-self") %>>
<a href="/docs/commands/acl/token-self.html">acl token self</a>
<a href="/docs/commands/acl/token-self.html">token self</a>
</li>
<li<%= sidebar_current("docs-commands-acl-token-update") %>>
<a href="/docs/commands/acl/token-update.html">acl token update</a>
<a href="/docs/commands/acl/token-update.html">token update</a>
</li>
</ul>
</li>
@@ -218,13 +218,13 @@
<a href="/docs/commands/alloc.html">alloc</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-alloc-fs") %>>
<a href="/docs/commands/alloc/fs.html">alloc fs</a>
<a href="/docs/commands/alloc/fs.html">fs</a>
</li>
<li<%= sidebar_current("docs-commands-alloc-logs") %>>
<a href="/docs/commands/alloc/logs.html">alloc logs</a>
<a href="/docs/commands/alloc/logs.html">logs</a>
</li>
<li<%= sidebar_current("docs-commands-alloc-status") %>>
<a href="/docs/commands/alloc/status.html">alloc status</a>
<a href="/docs/commands/alloc/status.html">status</a>
</li>
</ul>
</li>
@@ -232,22 +232,22 @@
<a href="/docs/commands/deployment.html">deployment</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-deployment-fail") %>>
<a href="/docs/commands/deployment/fail.html">deployment fail</a>
<a href="/docs/commands/deployment/fail.html">fail</a>
</li>
<li<%= sidebar_current("docs-commands-deployment-list") %>>
<a href="/docs/commands/deployment/list.html">deployment list</a>
<a href="/docs/commands/deployment/list.html">list</a>
</li>
<li<%= sidebar_current("docs-commands-deployment-pause") %>>
<a href="/docs/commands/deployment/pause.html">deployment pause</a>
<a href="/docs/commands/deployment/pause.html">pause</a>
</li>
<li<%= sidebar_current("docs-commands-deployment-promote") %>>
<a href="/docs/commands/deployment/promote.html">deployment promote</a>
<a href="/docs/commands/deployment/promote.html">promote</a>
</li>
<li<%= sidebar_current("docs-commands-deployment-resume") %>>
<a href="/docs/commands/deployment/resume.html">deployment resume</a>
<a href="/docs/commands/deployment/resume.html">resume</a>
</li>
<li<%= sidebar_current("docs-commands-deployment-status") %>>
<a href="/docs/commands/deployment/status.html">deployment status</a>
<a href="/docs/commands/deployment/status.html">status</a>
</li>
</ul>
</li>
@@ -258,40 +258,40 @@
<a href="/docs/commands/job.html">job</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-job-deployments") %>>
<a href="/docs/commands/job/deployments.html">job deployments</a>
<a href="/docs/commands/job/deployments.html">deployments</a>
</li>
<li<%= sidebar_current("docs-commands-job-dispatch") %>>
<a href="/docs/commands/job/dispatch.html">job dispatch</a>
<a href="/docs/commands/job/dispatch.html">dispatch</a>
</li>
<li<%= sidebar_current("docs-commands-job-history") %>>
<a href="/docs/commands/job/history.html">job history</a>
<a href="/docs/commands/job/history.html">history</a>
</li>
<li<%= sidebar_current("docs-commands-job-init") %>>
<a href="/docs/commands/job/init.html">job init</a>
<a href="/docs/commands/job/init.html">init</a>
</li>
<li<%= sidebar_current("docs-commands-job-inspect") %>>
<a href="/docs/commands/job/inspect.html">job inspect</a>
<a href="/docs/commands/job/inspect.html">inspect</a>
</li>
<li<%= sidebar_current("docs-commands-job-plan") %>>
<a href="/docs/commands/job/plan.html">job plan</a>
<a href="/docs/commands/job/plan.html">plan</a>
</li>
<li<%= sidebar_current("docs-commands-job-promote") %>>
<a href="/docs/commands/job/promote.html">job promote</a>
<a href="/docs/commands/job/promote.html">promote</a>
</li>
<li<%= sidebar_current("docs-commands-job-revert") %>>
<a href="/docs/commands/job/revert.html">job revert</a>
<a href="/docs/commands/job/revert.html">revert</a>
</li>
<li<%= sidebar_current("docs-commands-job-run") %>>
<a href="/docs/commands/job/run.html">job run</a>
<a href="/docs/commands/job/run.html">run</a>
</li>
<li<%= sidebar_current("docs-commands-job-status") %>>
<a href="/docs/commands/job/status.html">job status</a>
<a href="/docs/commands/job/status.html">status</a>
</li>
<li<%= sidebar_current("docs-commands-job-stop") %>>
<a href="/docs/commands/job/stop.html">job stop</a>
<a href="/docs/commands/job/stop.html">stop</a>
</li>
<li<%= sidebar_current("docs-commands-job-validate") %>>
<a href="/docs/commands/job/validate.html">job validate</a>
<a href="/docs/commands/job/validate.html">validate</a>
</li>
</ul>
</li>
@@ -299,19 +299,19 @@
<a href="/docs/commands/namespace.html">namespace</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-namespace-apply") %>>
<a href="/docs/commands/namespace/apply.html">namespace apply</a>
<a href="/docs/commands/namespace/apply.html">apply</a>
</li>
<li<%= sidebar_current("docs-commands-namespace-delete") %>>
<a href="/docs/commands/namespace/delete.html">namespace delete</a>
<a href="/docs/commands/namespace/delete.html">delete</a>
</li>
<li<%= sidebar_current("docs-commands-namespace-inspect") %>>
<a href="/docs/commands/namespace/inspect.html">namespace inspect</a>
<a href="/docs/commands/namespace/inspect.html">inspect</a>
</li>
<li<%= sidebar_current("docs-commands-namespace-list") %>>
<a href="/docs/commands/namespace/list.html">namespace list</a>
<a href="/docs/commands/namespace/list.html">list</a>
</li>
<li<%= sidebar_current("docs-commands-namespace-status") %>>
<a href="/docs/commands/namespace/status.html">namespace status</a>
<a href="/docs/commands/namespace/status.html">status</a>
</li>
</ul>
</li>
@@ -319,13 +319,13 @@
<a href="/docs/commands/node.html">node</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-node-config") %>>
<a href="/docs/commands/node/config.html">node config</a>
<a href="/docs/commands/node/config.html">config</a>
</li>
<li<%= sidebar_current("docs-commands-node-drain") %>>
<a href="/docs/commands/node/drain.html">node drain</a>
<a href="/docs/commands/node/drain.html">drain</a>
</li>
<li<%= sidebar_current("docs-commands-node-status") %>>
<a href="/docs/commands/node/status.html">node status</a>
<a href="/docs/commands/node/status.html">status</a>
</li>
</ul>
</li>
@@ -356,22 +356,22 @@
<a href="/docs/commands/quota.html">quota</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-quota-apply") %>>
<a href="/docs/commands/quota/apply.html">quota apply</a>
<a href="/docs/commands/quota/apply.html">apply</a>
</li>
<li<%= sidebar_current("docs-commands-quota-delete") %>>
<a href="/docs/commands/quota/delete.html">quota delete</a>
<a href="/docs/commands/quota/delete.html">delete</a>
</li>
<li<%= sidebar_current("docs-commands-quota-init") %>>
<a href="/docs/commands/quota/init.html">quota init</a>
<a href="/docs/commands/quota/init.html">init</a>
</li>
<li<%= sidebar_current("docs-commands-quota-inspect") %>>
<a href="/docs/commands/quota/inspect.html">quota inspect</a>
<a href="/docs/commands/quota/inspect.html">inspect</a>
</li>
<li<%= sidebar_current("docs-commands-quota-list") %>>
<a href="/docs/commands/quota/list.html">quota list</a>
<a href="/docs/commands/quota/list.html">list</a>
</li>
<li<%= sidebar_current("docs-commands-quota-status") %>>
<a href="/docs/commands/quota/status.html">quota status</a>
<a href="/docs/commands/quota/status.html">status</a>
</li>
</ul>
</li>
@@ -379,16 +379,16 @@
<a href="/docs/commands/sentinel.html">sentinel</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-sentinel-apply") %>>
<a href="/docs/commands/sentinel/apply.html">sentinel apply</a>
<a href="/docs/commands/sentinel/apply.html">apply</a>
</li>
<li<%= sidebar_current("docs-commands-sentinel-delete") %>>
<a href="/docs/commands/sentinel/delete.html">sentinel delete</a>
<a href="/docs/commands/sentinel/delete.html">delete</a>
</li>
<li<%= sidebar_current("docs-commands-sentinel-list") %>>
<a href="/docs/commands/sentinel/list.html">sentinel list</a>
<a href="/docs/commands/sentinel/list.html">list</a>
</li>
<li<%= sidebar_current("docs-commands-sentinel-read") %>>
<a href="/docs/commands/sentinel/read.html">sentinel read</a>
<a href="/docs/commands/sentinel/read.html">read</a>
</li>
</ul>
</li>
@@ -396,13 +396,13 @@
<a href="/docs/commands/server.html">server</a>
<ul class="nav">
<li<%= sidebar_current("docs-commands-server-force-leave") %>>
<a href="/docs/commands/server/force-leave.html">server force-leave</a>
<a href="/docs/commands/server/force-leave.html">force-leave</a>
</li>
<li<%= sidebar_current("docs-commands-server-join") %>>
<a href="/docs/commands/server/join.html">server join</a>
<a href="/docs/commands/server/join.html">join</a>
</li>
<li<%= sidebar_current("docs-commands-server-members") %>>
<a href="/docs/commands/server/members.html">server members</a>
<a href="/docs/commands/server/members.html">members</a>
</li>
</ul>
</li>