Nomad
Command: job plan
Alias: nomad plan
The job plan
command can be used to invoke the scheduler in a dry-run mode
with new jobs or when updating existing jobs to determine what would happen if
the job is submitted. Job files must conform to the job specification format.
Usage
nomad job plan [options] <path>
The job plan
command requires a single argument, specifying the path to a file
containing an HCL job specification. This file will be read and the resulting
parsed job will be validated. If the supplied path is "-", the job file is read
from STDIN. Otherwise it is read from the file at the supplied path or
downloaded and read from URL specified. Nomad downloads the job file using
go-getter
and supports go-getter
syntax.
Plan invokes a dry-run of the scheduler to determine the effects of submitting either a new or updated version of a job. The plan will not result in any 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 job run -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.
A structured diff between the local and remote job is displayed to give insight into what the scheduler will attempt to do and why.
If the job has specified the region, the -region
flag and NOMAD_REGION
environment variable are overridden and the job's region is used.
Plan will return one of the following exit codes:
- 0: No allocations created or destroyed.
- 1: Allocations created or destroyed.
- 255: Error determining plan results.
When ACLs are enabled, this command requires a token with the submit-job
capability for the job's namespace.
General Options
-address=<addr>
: The address of the Nomad server. Overrides theNOMAD_ADDR
environment variable if set. Defaults tohttp://127.0.0.1:4646
.-region=<region>
: The region of the Nomad server to forward commands to. Overrides theNOMAD_REGION
environment variable if set. Defaults to the Agent's local region.-namespace=<namespace>
: The target namespace for queries and actions bound to a namespace. Overrides theNOMAD_NAMESPACE
environment variable if set. If set to'*'
, job and alloc subcommands query all namespacecs authorized to user. Defaults to the "default" namespace.-no-color
: Disables colored command output. Alternatively,NOMAD_CLI_NO_COLOR
may be set.-ca-cert=<path>
: Path to a PEM encoded CA cert file to use to verify the Nomad server SSL certificate. Overrides theNOMAD_CACERT
environment variable if set.-ca-path=<path>
: Path to a directory of PEM encoded CA cert files to verify the Nomad server SSL certificate. If both-ca-cert
and-ca-path
are specified,-ca-cert
is used. Overrides theNOMAD_CAPATH
environment variable if set.-client-cert=<path>
: Path to a PEM encoded client certificate for TLS authentication to the Nomad server. Must also specify-client-key
. Overrides theNOMAD_CLIENT_CERT
environment variable if set.-client-key=<path>
: Path to an unencrypted PEM encoded private key matching the client certificate from-client-cert
. Overrides theNOMAD_CLIENT_KEY
environment variable if set.-tls-server-name=<value>
: The server name to use as the SNI host when connecting via TLS. Overrides theNOMAD_TLS_SERVER_NAME
environment variable if set.-tls-skip-verify
: Do not verify TLS certificate. This is highly not recommended. Verification will also be skipped ifNOMAD_SKIP_VERIFY
is set.-token
: The SecretID of an ACL token to use to authenticate API requests with. Overrides theNOMAD_TOKEN
environment variable if set.
Plan Options
-diff
: Determines whether the diff between the remote job and planned job is shown. Defaults to true.-policy-override
: Sets the flag to force override any soft mandatory Sentinel policies.-hcl1
: If set, HCL1 parser is used for parsing the job spec.-verbose
: Increase diff verbosity.
Examples
Plan a new job that has not been previously submitted:
$ nomad job plan job1.nomad
nomad job plan example.nomad
+ Job: "example"
+ Task Group: "cache" (1 create)
+ Task: "redis" (forces create)
Scheduler dry-run:
- All tasks successfully allocated.
Job Modify Index: 0
To submit the job with version verification run:
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
job modify index given matches the server-side version. If the index has
changed, another user has modified the job and the plan's results are
potentially invalid.
Increase the count of an existing without sufficient cluster capacity:
$ nomad job plan example.nomad
+/- Job: "example"
+/- Task Group: "cache" (7 create, 1 in-place update)
+/- Count: "1" => "8" (forces create)
Task: "redis"
Scheduler dry-run:
- WARNING: Failed to place all allocations.
Task Group "cache" (failed to place 3 allocations):
* Resources exhausted on 1 nodes
* Dimension "cpu" exhausted on 1 nodes
Job Modify Index: 15
To submit the job with version verification run:
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
job modify index given matches the server-side version. If the index has
changed, another user has modified the job and the plan's results are
potentially invalid.
Update an existing job such that it would cause a rolling update:
$ nomad job plan example.nomad
+/- Job: "example"
+/- Task Group: "cache" (3 create/destroy update)
+/- Task: "redis" (forces create/destroy update)
+/- Config {
+/- image: "redis:2.8" => "redis:3.2"
port_map[0][db]: "6379"
}
Scheduler dry-run:
- All tasks successfully allocated.
- Rolling update, next evaluation will be in 10s.
Job Modify Index: 7
To submit the job with version verification run:
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
job modify index given matches the server-side version. If the index has
changed, another user has modified the job and the plan's results are
potentially invalid.
Add a task to the task group using verbose mode:
$ nomad job plan -verbose example.nomad
+/- Job: "example"
+/- Task Group: "cache" (3 create/destroy update)
+ Task: "my-website" (forces create/destroy update)
+ Driver: "docker"
+ KillTimeout: "5000000000"
+ Config {
+ image: "node:6.2"
+ port_map[0][web]: "80"
}
+ Resources {
+ CPU: "500"
+ DiskMB: "300"
+ MemoryMB: "256"
+ Network {
+ MBits: "10"
+ Dynamic Port {
+ Label: "web"
}
}
}
+ LogConfig {
+ MaxFileSizeMB: "10"
+ MaxFiles: "10"
}
+ Service {
+ Name: "website"
+ PortLabel: "web"
+ Check {
Command: ""
+ Interval: "10000000000"
+ Name: "alive"
Path: ""
Protocol: ""
+ Timeout: "2000000000"
+ Type: "tcp"
}
}
Task: "redis"
Scheduler dry-run:
- All tasks successfully allocated.
- Rolling update, next evaluation will be in 10s.
Job Modify Index: 7
To submit the job with version verification run:
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
job modify index given matches the server-side version. If the index has
changed, another user has modified the job and the plan's results are
potentially invalid.