mirror of
https://github.com/kemko/nomad.git
synced 2026-01-05 01:45:44 +03:00
Fix old references
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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==
|
||||
```
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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]`
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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]`
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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]`
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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
|
||||
|
||||
```
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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).
|
||||
|
||||
@@ -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]
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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
|
||||
# ...
|
||||
```
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
```
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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==
|
||||
```
|
||||
|
||||
|
||||
@@ -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):
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -319,13 +319,13 @@ description: |-
|
||||
<span> </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> </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> </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>
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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"
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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]
|
||||
|
||||
|
||||
@@ -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>
|
||||
|
||||
Reference in New Issue
Block a user