kemko/nomad
1
0
Fork 0
mirror of https://github.com/kemko/nomad.git synced 2026-01-06 10:25:42 +03:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into feature/2334

Browse Source
This commit is contained in:
Alex Dadgar
2017-05-31 14:27:07 -07:00
committed by GitHub
parent 20fd19d6e2 633ec0c39c
commit e9f6769f74
88 changed files with 5008 additions and 4217 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
website/source/docs/agent/configuration/client.html.md
View File

@@ -100,6 +100,12 @@ client {
- `gc_inode_usage_threshold` `(float: 70)` - Specifies the inode usage percent
which Nomad tries to maintain by garbage collecting terminal allocations.
- `gc_max_allocs` `(int: 50)` - Specifies the maximum number of allocations
which a client will track before triggering a garbage collection of terminal
allocations. This will *not* limit the number of allocations a node can run at
a time, however after `gc_max_allocs` every new allocation will cause terminal
allocations to be GC'd.
- `gc_parallel_destroys` `(int: 2)` - Specifies the maximum number of
parallel destroys allowed by the garbage collector. This value should be
relatively low to avoid high resource usage during garbage collections.

2
website/source/docs/commands/inspect.html.md.erb
View File

@@ -18,7 +18,7 @@ nomad inspect [options] <job>
The `inspect` command requires a single argument, a submitted job's name, and
will retrieve the JSON version of the job. This JSON is valid to be submitted to
the [Job HTTP API](/docs/http/job.html). This command is useful to inspect what
the [Job HTTP API](/api/jobs.html). This command is useful to inspect what
version of a job Nomad is running.
## General Options

7
website/source/docs/commands/operator-raft-list-peers.html.md.erb
View File

@@ -9,11 +9,11 @@ description: >
# Command: `operator raft list-peers`
The Raft list-peers command is used to display the current Raft peer
configuration.
configuration.
See the [Outage Recovery](/guides/outage.html) guide for some examples of how
this command is used. For an API to perform these operations programatically,
please see the documentation for the [Operator](/docs/http/operator.html)
please see the documentation for the [Operator](/api/operator.html)
endpoint.
## Usage
@@ -36,7 +36,7 @@ server.
## Examples
An example output with three servers is as follows:
```
$ nomad operator raft list-peers
Node ID Address State Voter
@@ -58,4 +58,3 @@ Raft configuration.
- `Voter` is "true" or "false", indicating if the server has a vote in the Raft
configuration. Future versions of Nomad may add support for non-voting servers.

3
website/source/docs/commands/operator-raft-remove-peer.html.md.erb
View File

@@ -21,7 +21,7 @@ command.
See the [Outage Recovery](/guides/outage.html) guide for some examples of how
this command is used. For an API to perform these operations programatically,
please see the documentation for the [Operator](/docs/http/operator.html)
please see the documentation for the [Operator](/api/operator.html)
endpoint.
## Usage
@@ -38,4 +38,3 @@ nomad operator raft remove-peer [options]
* `-peer-address`: Remove a Nomad server with given address from the Raft
configuration. The format is "IP:port"

47
website/source/docs/http/agent-force-leave.html.md
View File

@@ -1,47 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/agent/force-leave"
sidebar_current: "docs-http-agent-force-leave"
description: |-
The '/1/agent/force-leave' endpoint is force a gossip member to leave.
---
# /v1/agent/force-leave
The `force-leave` endpoint is used to force a member of the gossip pool from
the "failed" state into the "left" state. This allows the consensus protocol to
remove the peer and stop attempting replication. This is only applicable for
servers.
## PUT / POST
<dl>
<dt>Description</dt>
<dd>
Force a failed gossip member into the left state.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/agent/force-leave`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">node</span>
<span class="param-flags">required</span>
The name of the node to force leave.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
A `200` status code on success.
</dd>
</dl>

53
website/source/docs/http/agent-join.html.md
View File

@@ -1,53 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/agent/join"
sidebar_current: "docs-http-agent-join"
description: |-
The '/1/agent/join' endpoint is used to cluster the Nomad servers.
---
# /v1/agent/join
The `join` endpoint is used to cluster the Nomad servers using a gossip pool.
The servers participate in a peer-to-peer gossip, and `join` is used to introduce
a member to the pool. This is only applicable for servers.
## PUT / POST
<dl>
<dt>Description</dt>
<dd>
Initiate a join between the agent and target peers.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/agent/join`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">address</span>
<span class="param-flags">required</span>
The address to join. Can be provided multiple times
to attempt joining multiple peers.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"num_joined": 1,
"error": ""
}
```
</dd>
</dl>

70
website/source/docs/http/agent-members.html.md
View File

@@ -1,70 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/agent/members"
sidebar_current: "docs-http-agent-members"
description: |-
The '/1/agent/members' endpoint is used to query the gossip peers.
---
# /v1/agent/members
The `members` endpoint is used to query the agent for the known peers in
the gossip pool. This is only applicable to servers.
## GET
<dl>
<dt>Description</dt>
<dd>
Lists the known members of the gossip pool.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/agent/members`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"ServerName": "DIPTANUs-MBP",
"ServerRegion": "global",
"ServerDC": "dc1",
"Members": [
{
"Name": "DIPTANUs-MBP.global",
"Addr": "127.0.0.1",
"Port": 4648,
"Tags": {
"mvn": "1",
"build": "0.5.0rc2",
"port": "4647",
"bootstrap": "1",
"role": "nomad",
"region": "global",
"dc": "dc1",
"vsn": "1"
},
"Status": "alive",
"ProtocolMin": 1,
"ProtocolMax": 4,
"ProtocolCur": 2,
"DelegateMin": 2,
"DelegateMax": 4,
"DelegateCur": 4
}
]
}
```
</dd>
</dl>

163
website/source/docs/http/agent-self.html.md
View File

@@ -1,163 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/agent/self"
sidebar_current: "docs-http-agent-self"
description: |-
The '/1/agent/self' endpoint is used to query the state of the agent.
---
# /v1/agent/self
The `self` endpoint is used to query the state of the target agent.
## GET
<dl>
<dt>Description</dt>
<dd>
Query the state of the target agent.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/agent/self`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"config": {
"Region": "global",
"Datacenter": "dc1",
"NodeName": "",
"DataDir": "",
"LogLevel": "DEBUG",
"BindAddr": "127.0.0.1",
"EnableDebug": true,
"Ports": {
"HTTP": 4646,
"RPC": 4647,
"Serf": 4648
},
"Addresses": {
"HTTP": "",
"RPC": "",
"Serf": ""
},
"AdvertiseAddrs": {
"RPC": "",
"Serf": ""
},
"Client": {
"Enabled": true,
"StateDir": "",
"AllocDir": "",
"Servers": null,
"NodeID": "",
"NodeClass": "",
"Meta": null
},
"Server": {
"Enabled": true,
"Bootstrap": false,
"BootstrapExpect": 0,
"DataDir": "",
"ProtocolVersion": 0,
"NumSchedulers": 0,
"EnabledSchedulers": null
},
"Telemetry": null,
"LeaveOnInt": false,
"LeaveOnTerm": false,
"EnableSyslog": false,
"SyslogFacility": "",
"DisableUpdateCheck": false,
"DisableAnonymousSignature": true,
"Revision": "",
"Version": "0.1.0",
"VersionPrerelease": "dev",
"DevMode": true,
"Atlas": null
},
"member": {
"Name": "Armons-MacBook-Air.local.global",
"Addr": "127.0.0.1",
"Port": 4648,
"Tags": {
"bootstrap": "1",
"build": "0.1.0dev",
"dc": "dc1",
"port": "4647",
"region": "global",
"role": "nomad",
"vsn": "1"
},
"Status": "alive",
"ProtocolMin": 1,
"ProtocolMax": 3,
"ProtocolCur": 2,
"DelegateMin": 2,
"DelegateMax": 4,
"DelegateCur": 4
},
"stats": {
"client": {
"heartbeat_ttl": "19116443712",
"known_servers": "0",
"last_heartbeat": "8222075779",
"num_allocations": "0"
},
"nomad": {
"bootstrap": "false",
"known_regions": "1",
"leader": "true",
"server": "true"
},
"raft": {
"applied_index": "91",
"commit_index": "91",
"fsm_pending": "0",
"last_contact": "never",
"last_log_index": "91",
"last_log_term": "1",
"last_snapshot_index": "0",
"last_snapshot_term": "0",
"num_peers": "0",
"state": "Leader",
"term": "1"
},
"runtime": {
"arch": "amd64",
"cpu_count": "4",
"goroutines": "58",
"kernel.name": "darwin",
"max_procs": "1",
"version": "go1.4.2"
},
"serf": {
"encrypted": "false",
"event_queue": "0",
"event_time": "1",
"failed": "0",
"intent_queue": "0",
"left": "0",
"member_time": "1",
"members": "1",
"query_queue": "0",
"query_time": "1"
}
}
}
```
</dd>
</dl>

82
website/source/docs/http/agent-servers.html.md
View File

@@ -1,82 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/agent/servers"
sidebar_current: "docs-http-agent-servers"
description: |-
The '/v1/agent/servers' endpoint is used to query and update the servers list.
---
# /v1/agent/servers
The `servers` endpoint is used to query an agent in client mode for its list
of known servers. Client nodes register themselves with these server addresses
so that they may dequeue work. The `servers` endpoint can be used to keep this
configuration up to date if there are changes in the cluster.
## GET
<dl>
<dt>Description</dt>
<dd>
Lists the known server nodes.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/agent/servers`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
"server1.local:4647",
"server2.local:4647"
]
```
</dd>
</dl>
## PUT / POST
<dl>
<dt>Description</dt>
<dd>
Updates the list of known servers to the provided list. Replaces
all previous server addresses with the new list.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/agent/servers`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">address</span>
<span class="param-flags">required</span>
The address of a server node in host:port format. This
parameter may be specified multiple times to configure
multiple servers on the client.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
A 200 status code on success.
</dd>
</dl>

281
website/source/docs/http/alloc.html.md
View File

@@ -1,281 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/allocation"
sidebar_current: "docs-http-alloc-"
description: |-
The '/1/allocation' endpoint is used to query a specific allocation.
---
# /v1/allocation
The `allocation` endpoint is used to query a specific allocation.
By default, the agent's local region is used; another region can
be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Query a specific allocation.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/allocation/<ID>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"ID": "203266e5-e0d6-9486-5e05-397ed2b184af",
"EvalID": "e68125ed-3fba-fb46-46cc-291addbc4455",
"Name": "example.cache[0]",
"NodeID": "e02b6169-83bd-9df6-69bd-832765f333eb",
"JobID": "example",
"ModifyIndex": 9,
"Resources": {
"Networks": [
{
"DynamicPorts": [
{
"Value": 20802,
"Label": "db"
}
],
"ReservedPorts": null,
"MBits": 10,
"IP": "",
"CIDR": "",
"Device": ""
}
],
"IOPS": 0,
"DiskMB": 0,
"MemoryMB": 256,
"CPU": 500
},
"TaskGroup": "cache",
"Job": {
"ModifyIndex": 5,
"CreateIndex": 5,
"StatusDescription": "",
"Status": "",
"Meta": null,
"Update": {
"MaxParallel": 1,
"Stagger": 1e+10
},
"TaskGroups": [
{
"Meta": null,
"Tasks": [
{
"Meta": null,
"Resources": {
"Networks": [
{
"DynamicPorts": [
{
"Value": 20802,
"Label": "db"
}
],
"ReservedPorts": null,
"MBits": 0,
"IP": "127.0.0.1",
"CIDR": "",
"Device": "lo"
}
],
"IOPS": 0,
"DiskMB": 0,
"MemoryMB": 256,
"CPU": 500
},
"Constraints": null,
"Services": [
{
"Checks": [
{
"Timeout": 2e+09,
"Interval": 1e+10,
"Protocol": "",
"Http": "",
"Script": "",
"Type": "tcp",
"Name": "alive",
"Id": ""
}
],
"PortLabel": "db",
"Tags": [
"global",
"cache"
],
"Name": "example-cache-redis",
"Id": ""
}
],
"Env": null,
"Config": {
"port_map": [
{
"db": 6379
}
],
"image": "redis:latest"
},
"Driver": "docker",
"Name": "redis"
}
],
"RestartPolicy": {
"Delay": 2.5e+10,
"Interval": 3e+11,
"Attempts": 10
},
"Constraints": null,
"Count": 1,
"Name": "cache"
}
],
"Region": "global",
"ID": "example",
"Name": "example",
"Type": "service",
"Priority": 50,
"AllAtOnce": false,
"Datacenters": [
"dc1"
],
"Constraints": [
{
"Operand": "=",
"RTarget": "linux",
"LTarget": "${attr.kernel.name}"
}
]
},
"TaskResources": {
"redis": {
"Networks": [
{
"DynamicPorts": [
{
"Value": 20802,
"Label": "db"
}
],
"ReservedPorts": null,
"MBits": 0,
"IP": "127.0.0.1",
"CIDR": "",
"Device": "lo"
}
],
"IOPS": 0,
"DiskMB": 0,
"MemoryMB": 256,
"CPU": 500
}
},
"Metrics": {
"CoalescedFailures": 0,
"AllocationTime": 1590406,
"NodesEvaluated": 1,
"NodesFiltered": 0,
"ClassFiltered": null,
"ConstraintFiltered": null,
"NodesExhausted": 0,
"ClassExhausted": null,
"DimensionExhausted": null,
"Scores": {
"e02b6169-83bd-9df6-69bd-832765f333eb.binpack": 6.133651487695705
}
},
"DesiredStatus": "run",
"DesiredDescription": "",
"ClientStatus": "running",
"ClientDescription": "",
"TaskStates": {
"redis": {
"Events": [
{
"KillError": "",
"Message": "",
"Signal": 0,
"ExitCode": 0,
"DriverError": "",
"Time": 1447806038427841000,
"Type": "Started"
}
],
"State": "running"
"FinishedAt": "0001-01-01T00:00:00Z",
"StartedAt": "2017-03-31T22:51:40.248633594Z",
"Failed": false,
}
},
"CreateIndex": 7
}
```
</dd>
</dl>
### Field Reference
* `TaskStates` - `TaskStates` is a map of tasks to their current state and the
latest events that have effected the state.
A task can be in the following states:
* `TaskStatePending` - The task is waiting to be run, either for the first
time or due to a restart.
* `TaskStateRunning` - The task is currently running.
* `TaskStateDead` - The task is dead and will not run again.
Further the state contains the `StartedAt` and `FinishedAt` times of the
task. `StartedAt` can be updated multiple times if the task restarts but
`FinishedAt` is set only when the task transistions to `TaskStateDead`
<p>The latest 10 events are stored per task. Each event is timestamped (unix nano-seconds)
and has one of the following types:</p>
* `Setup Failure` - The task could not be started because there was a
failure setting up the task prior to it running.
* `Driver Failure` - The task could not be started due to a failure in the
driver.
* `Started` - The task was started; either for the first time or due to a
restart.
* `Terminated` - The task was started and exited.
* `Killing` - The task has been sent the kill signal.
* `Killed` - The task was killed by an user.
* `Received` - The task has been pulled by the client at the given timestamp.
* `Failed Validation` - The task was invalid and as such it didn't run.
* `Restarting` - The task terminated and is being restarted.
* `Not Restarting` - the task has failed and is not being restarted because it has exceeded its restart policy.
* `Downloading Artifacts` - The task is downloading the artifact(s) specified in the task.
* `Failed Artifact Download` - Artifact(s) specified in the task failed to download.
* `Restart Signaled` - The task was signalled to be restarted.
* `Signaling` - The task was is being sent a signal.
* `Sibling Task Failed` - A task in the same task group failed.
* `Leader Task Dead` - The group's leader task is dead.
* `Driver` - A message from the driver.
* `Task Setup` - Task setup messages.
Depending on the type the event will have applicable annotations.

86
website/source/docs/http/allocs.html.md
View File

@@ -1,86 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/allocations"
sidebar_current: "docs-http-allocs"
description: |-
The '/1/allocations' endpoint is used to list the allocations.
---
# /v1/allocations
The `allocations` endpoint is used to query the status of allocations.
By default, the agent's local region is used; another region can
be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Lists all the allocations.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/allocations`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">prefix</span>
<span class="param-flags">optional</span>
<span class="param-flags">even-length</span>
Filter allocations based on an identifier prefix.
</li>
</ul>
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "203266e5-e0d6-9486-5e05-397ed2b184af",
"EvalID": "e68125ed-3fba-fb46-46cc-291addbc4455",
"Name": "example.cache[0]",
"NodeID": "e02b6169-83bd-9df6-69bd-832765f333eb",
"JobID": "example",
"TaskGroup": "cache",
"DesiredStatus": "run",
"DesiredDescription": ""
"ClientDescription": "",
"ClientStatus": "running",
"TaskStates": {
"redis": {
"Events": [
{
"KillError": "",
"Message": "",
"Signal": 0,
"ExitCode": 0,
"DriverError": "",
"Time": 1447806038427841000,
"Type": "Started"
}
],
"State": "running"
}
},
"CreateIndex": 7,
"ModifyIndex": 9,
}
...
]
```
</dd>
</dl>

155
website/source/docs/http/client-allocation-stats.html.md
View File

@@ -1,155 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/client/allocation/stats"
sidebar_current: "docs-http-client-allocation-stats"
description: |-
The '/v1/client/allocation/` endpoint is used to query the actual resources
consumed by an allocation.
---
# /v1/client/allocation
The client `allocation` endpoint is used to query the actual resources consumed
by an allocation. The API endpoint is hosted by the Nomad client and requests
have to be made to the nomad client whose resource usage metrics are of
interest.
## GET
<dl>
<dt>Description</dt>
<dd>
Query resource usage of an allocation running on a client.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/allocation/<ID>/stats`</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"ResourceUsage": {
"CpuStats": {
"Measured": [
"System Mode",
"User Mode",
"Percent"
],
"Percent": 105.77854560628487,
"SystemMode": 6.860067935411291,
"ThrottledPeriods": 0,
"ThrottledTime": 0,
"TotalTicks": 714.0051828424228,
"UserMode": 98.9184820888787
},
"MemoryStats": {
"Cache": 0,
"KernelMaxUsage": 0,
"KernelUsage": 0,
"MaxUsage": 0,
"Measured": [
"RSS",
"Swap"
],
"RSS": 14098432,
"Swap": 0
}
},
"Tasks": {
"redis": {
"Pids": {
"27072": {
"CpuStats": {
"Measured": [
"System Mode",
"User Mode",
"Percent"
],
"Percent": 6.8607999603563385,
"SystemMode": 5.880684245133524,
"ThrottledPeriods": 0,
"ThrottledTime": 0,
"TotalTicks": 0,
"UserMode": 0.9801144039714172
},
"MemoryStats": {
"Cache": 0,
"KernelMaxUsage": 0,
"KernelUsage": 0,
"MaxUsage": 0,
"Measured": [
"RSS",
"Swap"
],
"RSS": 13418496,
"Swap": 0
}
},
"27073": {
"CpuStats": {
"Measured": [
"System Mode",
"User Mode",
"Percent"
],
"Percent": 98.91774564592852,
"SystemMode": 0.9793836902777665,
"ThrottledPeriods": 0,
"ThrottledTime": 0,
"TotalTicks": 0,
"UserMode": 97.93836768490729
},
"MemoryStats": {
"Cache": 0,
"KernelMaxUsage": 0,
"KernelUsage": 0,
"MaxUsage": 0,
"Measured": [
"RSS",
"Swap"
],
"RSS": 679936,
"Swap": 0
}
}
},
"ResourceUsage": {
"CpuStats": {
"Measured": [
"System Mode",
"User Mode",
"Percent"
],
"Percent": 105.77854560628487,
"SystemMode": 6.860067935411291,
"ThrottledPeriods": 0,
"ThrottledTime": 0,
"TotalTicks": 714.0051828424228,
"UserMode": 98.9184820888787
},
"MemoryStats": {
"Cache": 0,
"KernelMaxUsage": 0,
"KernelUsage": 0,
"MaxUsage": 0,
"Measured": [
"RSS",
"Swap"
],
"RSS": 14098432,
"Swap": 0
}
},
"Timestamp": 1465865820750959600
}
},
"Timestamp": 1465865820750959600
}
```
</dd>
</dl>

370
website/source/docs/http/client-fs.html.md
View File

@@ -1,370 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/client/fs"
sidebar_current: "docs-http-client-fs"
description: |-
The '/v1/client/fs` endpoints are used to read the contents of an allocation
directory.
---
# /v1/client/fs
The client `fs` endpoints are used to read the contents of files and
directories inside an allocation directory. The API endpoints are hosted by the
Nomad client and requests have to be made to the Client where the particular
allocation was placed.
## GET
<dl>
<dt>Description</dt>
<dd>
Read contents of a file in an allocation directory.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/fs/cat/<Allocation-ID>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
The path relative to the root of the allocation directory. It
defaults to `/`
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```
...
07:49 docker/3e8f0f4a67c2[924]: 1:M 22 Jun 21:07:49.110 # Server started, Redis version 3.2.1
07:49 docker/3e8f0f4a67c2[924]: 1:M 22 Jun 21:07:49.110 * The server is now ready to accept connections on port 6379
...
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Read contents of a file in an allocation directory at a particular offset.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/fs/readat/<Allocation-ID>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
The path relative to the root of the allocation directory. It
defaults to `/`
</li>
</ul>
<ul>
<li>
<span class="param">offset</span>
<span class="param-flags">required</span>
The byte offset from where content is going to be read.
</li>
</ul>
<ul>
<li>
<span class="param">limit</span>
<span class="param-flags">required</span>
The number of bytes to read from the offset.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```
...
07:49 docker/3e8f0f4a67c2[924]: 1:M 22 Jun 21:07:49.110 # Server started, Redis version 3.2.1
07:49 docker/3e8f0f4a67c2[924]: 1:M 22 Jun 21:07:49.110 * The server is now ready to accept connections on port 6379
...
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Stream contents of a file in an allocation directory.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/fs/stream/<Allocation-ID>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
The path relative to the root of the allocation directory. It
defaults to `/`
</li>
<li>
<span class="param">offset</span>
The offset to start streaming from. Defaults to 0.
</li>
<li>
<span class="param">origin</span>
Origin can be either "start" or "end" and applies the offset relative to
either the start or end of the file respectively. Defaults to "start".
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```
...
{
"File":"alloc/logs/redis.stdout.0",
"Offset":3604480
"Data": "NTMxOTMyCjUzMTkzMwo1MzE5MzQKNTMx..."
}
{
"File":"alloc/logs/redis.stdout.0",
"FileEvent": "file deleted"
}
```
</dd>
<dt>Field Reference</dt>
<dd>
The return value is a stream of frames. These frames contain the following
fields:
<ul>
<li>
<span class="param">Data</span>
A base64 encoding of the bytes being streamed.
</li>
<li>
<span class="param">FileEvent</span>
An event that could cause a change in the streams position. The possible
values are "file deleted" and "file truncated".
</li>
<li>
<span class="param">Offset</span>
Offset is the offset into the stream.
</li>
<li>
<span class="param">File</span>
The name of the file being streamed.
</li>
</ul>
</dd>
</dl>
<a id="logs"></a>
<dl>
<dt>Description</dt>
<dd>
Stream a task's stdout/stderr logs.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/fs/logs/<Allocation-ID>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">task</span>
<span class="param-flags">required</span>
The name of the task inside the allocation to stream logs from.
</li>
<li>
<span class="param">follow</span>
<span class="param-flags">required</span>
A boolean of whether to follow logs.
</li>
<li>
<span class="param">type</span>
Either, "stdout" or "stderr", defaults to "stdout" if omitted.
</li>
<li>
<span class="param">offset</span>
The offset to start streaming from. Defaults to 0.
</li>
<li>
<span class="param">origin</span>
Origin can be either "start" or "end" and applies the offset relative to
either the start or end of the logs respectively. Defaults to "start".
</li>
<li>
<span class="param">plain</span>
A boolean of whether to return just the plain text without framing.
This can be usef when viewing logs in a browser.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```
...
{
"File":"alloc/logs/redis.stdout.0",
"Offset":3604480
"Data": "NTMxOTMyCjUzMTkzMwo1MzE5MzQKNTMx..."
}
{
"File":"alloc/logs/redis.stdout.0",
"FileEvent": "file deleted"
}
```
</dd>
<dt>Field Reference</dt>
<dd>
The return value is a stream of frames. These frames contain the following
fields:
<ul>
<li>
<span class="param">Data</span>
A base64 encoding of the bytes being streamed.
</li>
<li>
<span class="param">FileEvent</span>
An event that could cause a change in the streams position. The possible
values are "file deleted" and "file truncated".
</li>
<li>
<span class="param">Offset</span>
Offset is the offset into the stream.
</li>
<li>
<span class="param">File</span>
The name of the file being streamed.
</li>
</ul>
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
List files in an allocation directory.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/fs/ls/<Allocation-ID>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
The path relative to the root of the allocation directory. It
defaults to `/`, the root of the allocation directory.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"Name": "alloc",
"IsDir": true,
"Size": 4096,
"FileMode": "drwxrwxr-x",
"ModTime": "2016-03-15T15:40:00.414236712-07:00"
},
{
"Name": "redis",
"IsDir": true,
"Size": 4096,
"FileMode": "drwxrwxr-x",
"ModTime": "2016-03-15T15:40:56.810238153-07:00"
}
]
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Stat a file in an allocation directory.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/fs/stat/<Allocation-ID>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">path</span>
<span class="param-flags">required</span>
The path of the file relative to the root of the allocation directory.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"Name": "redis-syslog-collector.out",
"IsDir": false,
"Size": 96,
"FileMode": "-rw-rw-r--",
"ModTime": "2016-03-15T15:40:56.822238153-07:00"
}
```
</dd>
</dl>

88
website/source/docs/http/client-stats.html.md
View File

@@ -1,88 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/client/stats"
sidebar_current: "docs-http-client-stats"
description: |-
The '/v1/client/stats` endpoint is used to query the actual resources consumed
on the node.
---
# /v1/client/stats
The client `stats` endpoint is used to query the actual resources consumed on a node.
The API endpoint is hosted by the Nomad client and requests have to be made to
the nomad client whose resource usage metrics are of interest.
## GET
<dl>
<dt>Description</dt>
<dd>
Query the actual resource usage of a Nomad client
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/client/stats`</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"CPU": [
{
"CPU": "cpu0",
"Idle": 89.2156862745098,
"System": 4.901960784313726,
"Total": 10.784313725490197,
"User": 5.88235294117647
},
{
"CPU": "cpu1",
"Idle": 100,
"System": 0,
"Total": 0,
"User": 0
},
{
"CPU": "cpu2",
"Idle": 94.05940594059405,
"System": 2.9702970297029703,
"Total": 5.9405940594059405,
"User": 2.9702970297029703
},
{
"CPU": "cpu3",
"Idle": 99.00990099009901,
"System": 0,
"Total": 0.9900990099009901,
"User": 0.9900990099009901
}
],
"CPUTicksConsumed": 119.5762958648806,
"DiskStats": [
{
"Available": 16997969920,
"Device": "/dev/disk1",
"InodesUsedPercent": 85.84777164286838,
"Mountpoint": "/",
"Size": 120108089344,
"Used": 102847975424,
"UsedPercent": 85.62951586835626
}
],
"Memory": {
"Available": 3724746752,
"Free": 2446233600,
"Total": 8589934592,
"Used": 4865187840
},
"Timestamp": 1465839167993064200,
"Uptime": 101149
}
```
</dd>
</dl>

131
website/source/docs/http/eval.html.md
View File

@@ -1,131 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/evaluation"
sidebar_current: "docs-http-eval-"
description: |-
The '/v1/evaluation' endpoint is used to query a specific evaluation.
---
# /v1/evaluation
The `evaluation` endpoint is used to query a specific evaluations.
By default, the agent's local region is used; another region can
be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Query a specific evaluation.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/evaluation/<ID>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"ID": "055c0867-8bf7-5068-b3a3-d64e4e84e702",
"Priority": 50,
"Type": "service",
"TriggeredBy": "job-register",
"JobID": "example",
"JobModifyIndex": 13,
"NodeID": "",
"NodeModifyIndex": 0,
"Status": "complete",
"StatusDescription": "",
"Wait": 0,
"NextEval": "",
"PreviousEval": "",
"BlockedEval": "fee40e32-aa0f-bf5e-b2fd-b08350875fdb",
"FailedTGAllocs": {
"cache": {
"NodesEvaluated": 1,
"NodesFiltered": 0,
"NodesAvailable": {
"dc1": 1
},
"ClassFiltered": null,
"ConstraintFiltered": null,
"NodesExhausted": 1,
"ClassExhausted": null,
"DimensionExhausted": {
"memory exhausted": 1
},
"Scores": null,
"AllocationTime": 61601,
"CoalescedFailures": 2
}
},
"CreateIndex": 14,
"ModifyIndex": 17
}
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Query the allocations created or modified by an evaluation.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/evaluation/<ID>/allocations`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "3575ba9d-7a12-0c96-7b28-add168c67984",
"EvalID": "151accaa-1ac6-90fe-d427-313e70ccbb88",
"Name": "binstore-storagelocker.binsl[0]",
"NodeID": "a703c3ca-5ff8-11e5-9213-970ee8879d1b",
"JobID": "binstore-storagelocker",
"TaskGroup": "binsl",
"DesiredStatus": "run",
"DesiredDescription": "",
"ClientStatus": "running",
"ClientDescription": "",
"CreateIndex": 16,
"ModifyIndex": 16
},
...
]
```
</dd>
</dl>

73
website/source/docs/http/evals.html.md
View File

@@ -1,73 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/evaluations"
sidebar_current: "docs-http-evals"
description: |-
The '/1/evaluations' endpoint is used to list the evaluations.
---
# /v1/evaluations
The `evaluations` endpoint is used to query the status of evaluations.
By default, the agent's local region is used; another region can
be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Lists all the evaluations.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/evaluations`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">prefix</span>
<span class="param-flags">optional</span>
<span class="param-flags">even-length</span>
Filter evaluations based on an identifier prefix.
</li>
</ul>
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "151accaa-1ac6-90fe-d427-313e70ccbb88",
"Priority": 50,
"Type": "service",
"TriggeredBy": "job-register",
"JobID": "binstore-storagelocker",
"JobModifyIndex": 14,
"NodeID": "",
"NodeModifyIndex": 0,
"Status": "complete",
"StatusDescription": "",
"Wait": 0,
"NextEval": "",
"PreviousEval": "",
"CreateIndex": 15,
"ModifyIndex": 17
},
...
]
```
</dd>
</dl>

98
website/source/docs/http/index.html.md
View File

@@ -1,98 +0,0 @@
---
layout: "http"
page_title: "HTTP API"
sidebar_current: "docs-http-overview"
description: |-
Nomad has an HTTP API that can be used to programmatically use Nomad.
---
# HTTP API
The Nomad HTTP API is the primary interface to using Nomad, and is used
to query the current state of the system as well as to modify it.
The Nomad CLI makes use of the Go HTTP client and invokes the HTTP API.
All API routes are prefixed with `/v1/`. This documentation is only for the v1 API.
## Data Model and API Layout
There are four primary "nouns" in Nomad, these are jobs, nodes, allocations, and evaluations:
[![Nomad Data Model](/assets/images/nomad-data-model.png)](/assets/images/nomad-data-model.png)
Jobs are submitted by users and represent a _desired state_. A job is a declarative description
of tasks to run which are bounded by constraints and require resources. Nodes are the servers
in the clusters that tasks can be scheduled on. The mapping of tasks in a job to nodes is done
using allocations. An allocation is used to declare that a set of tasks in a job should be run
on a particular node. Scheduling is the process of determining the appropriate allocations and
is done as part of an evaluation.
The API is modeled closely on the underlying data model. Use the links to the left for
documentation about specific endpoints. There are also "Agent" APIs which interact with
a specific agent and not the broader cluster used for administration.
<a name="blocking-queries"></a>
## Blocking Queries
Certain endpoints support a feature called a "blocking query." A blocking query
is used to wait for a potential change using long polling.
Not all endpoints support blocking, but those that do are clearly designated in
the documentation. Any endpoint that supports blocking will set the HTTP header
`X-Nomad-Index`, a unique identifier representing the current state of the
requested resource. On subsequent requests for this resource, the client can set
the `index` query string parameter to the value of `X-Nomad-Index`, indicating
that the client wishes to wait for any changes subsequent to that index.
In addition to `index`, endpoints that support blocking will also honor a `wait`
parameter specifying a maximum duration for the blocking request. This is limited to
10 minutes. If not set, the wait time defaults to 5 minutes. This value can be specified
in the form of "10s" or "5m" (i.e., 10 seconds or 5 minutes, respectively).
A critical note is that the return of a blocking request is **no guarantee** of a change. It
is possible that the timeout was reached or that there was an idempotent write that does
not affect the result of the query.
## Consistency Modes
Most of the read query endpoints support multiple levels of consistency. Since no policy will
suit all clients' needs, these consistency modes allow the user to have the ultimate say in
how to balance the trade-offs inherent in a distributed system.
The two read modes are:
* default - If not specified, the default is strongly consistent in almost all cases. However,
there is a small window in which a new leader may be elected during which the old leader may
service stale values. The trade-off is fast reads but potentially stale values. The condition
resulting in stale reads is hard to trigger, and most clients should not need to worry about
this case. Also, note that this race condition only applies to reads, not writes.
* stale - This mode allows any server to service the read regardless of whether
it is the leader. This means reads can be arbitrarily stale; however, results are generally
consistent to within 50 milliseconds of the leader. The trade-off is very fast and
scalable reads with a higher likelihood of stale values. Since this mode allows reads without
a leader, a cluster that is unavailable will still be able to respond to queries.
To switch these modes, use the `stale` query parameter on request.
To support bounding the acceptable staleness of data, responses provide the `X-Nomad-LastContact`
header containing the time in milliseconds that a server was last contacted by the leader node.
The `X-Nomad-KnownLeader` header also indicates if there is a known leader. These can be used
by clients to gauge the staleness of a result and take appropriate action.
## Cross-Region Requests
By default any request to the HTTP API is assumed to pertain to the region of the machine
servicing the request. A target region can be explicitly specified with the `region` query
parameter. The request will be transparently forwarded and serviced by a server in the
appropriate region.
## Compressed Responses
The HTTP API will gzip the response if the HTTP request denotes that the client accepts
gzip compression. This is achieved via the standard, `Accept-Encoding: gzip`
## Formatted JSON Output
By default, the output of all HTTP API requests is minimized JSON. If the client passes `pretty`
on the query string, formatted JSON will be returned.

748
website/source/docs/http/job.html.md
View File

@@ -1,748 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/job"
sidebar_current: "docs-http-job-"
description: |-
The '/1/job' endpoint is used for CRUD on a single job.
---
# /v1/job
The `job` endpoint is used for CRUD on a single job. By default, the agent's local
region is used; another region can be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Query a single job for its specification and status.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"Region": "global",
"ID": "binstore-storagelocker",
"Name": "binstore-storagelocker",
"Type": "service",
"Priority": 50,
"AllAtOnce": false,
"Datacenters": [
"us2",
"eu1"
],
"Constraints": [
{
"LTarget": "${attr.kernel.os}",
"RTarget": "windows",
"Operand": "="
}
],
"TaskGroups": [
{
"Name": "binsl",
"Count": 5,
"Constraints": [
{
"LTarget": "${attr.kernel.os}",
"RTarget": "linux",
"Operand": "="
}
],
"Tasks": [
{
"Name": "binstore",
"Driver": "docker",
"Config": {
"image": "hashicorp/binstore"
},
"Constraints": null,
"Resources": {
"CPU": 500,
"MemoryMB": 0,
"DiskMB": 0,
"IOPS": 0,
"Networks": [
{
"Device": "",
"CIDR": "",
"IP": "",
"MBits": 100,
"ReservedPorts": null,
"DynamicPorts": null
}
]
},
"Meta": null
},
{
"Name": "storagelocker",
"Driver": "java",
"Config": {
"image": "hashicorp/storagelocker"
},
"Constraints": [
{
"LTarget": "${attr.kernel.arch}",
"RTarget": "amd64",
"Operand": "="
}
],
"Resources": {
"CPU": 500,
"MemoryMB": 0,
"DiskMB": 0,
"IOPS": 0,
"Networks": null
},
"Meta": null
}
],
"Meta": {
"elb_checks": "3",
"elb_interval": "10",
"elb_mode": "tcp"
}
}
],
"Update": {
"Stagger": 0,
"MaxParallel": 0
},
"Meta": {
"foo": "bar"
},
"Status": "",
"StatusDescription": "",
"Version": 3,
"CreateIndex": 14,
"ModifyIndex": 14
}
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Query all versions of a single job.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/versions`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"Region": "global",
"ID": "binstore-storagelocker",
"Version": 2,
...
},
{
"Region": "global",
"ID": "binstore-storagelocker",
"Version": 1,
...
},
{
"Region": "global",
"ID": "binstore-storagelocker",
"Version": 0,
...
}
]
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Query the allocations belonging to a single job.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/allocations`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">all</span>
<span class="param-flags">optional</span>
Returns all allocations of job with the given ID including those from
past instances of the job.
</li>
</ul>
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "3575ba9d-7a12-0c96-7b28-add168c67984",
"EvalID": "151accaa-1ac6-90fe-d427-313e70ccbb88",
"Name": "binstore-storagelocker.binsl[0]",
"NodeID": "a703c3ca-5ff8-11e5-9213-970ee8879d1b",
"JobID": "binstore-storagelocker",
"TaskGroup": "binsl",
"DesiredStatus": "run",
"DesiredDescription": "",
"ClientStatus": "running",
"ClientDescription": "",
"CreateIndex": 16,
"ModifyIndex": 16
},
...
]
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Query the evaluations belonging to a single job.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/evaluations`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "151accaa-1ac6-90fe-d427-313e70ccbb88",
"Priority": 50,
"Type": "service",
"TriggeredBy": "job-register",
"JobID": "binstore-storagelocker",
"JobModifyIndex": 14,
"NodeID": "",
"NodeModifyIndex": 0,
"Status": "complete",
"StatusDescription": "",
"Wait": 0,
"NextEval": "",
"PreviousEval": "",
"CreateIndex": 15,
"ModifyIndex": 17
},
...
]
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Query the summary of a job.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/summary`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"JobID": "example",
"Children": {
"Dead": 0,
"Running": 7,
"Pending": 2
},
"Summary": {
"cache": {
"Queued": 0,
"Complete": 0,
"Failed": 0,
"Running": 1,
"Starting": 0,
"Lost": 0
}
},
"CreateIndex": 6,
"ModifyIndex": 10
}
```
</dd>
</dl>
## PUT / POST
<dl>
<dt>Description</dt>
<dd>
Registers a new job or updates an existing job
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">Job</span>
<span class="param-flags">required</span>
The JSON definition of the job.
</li>
<li>
<span class="param">EnforceIndex</span>
<span class="param-flags">optional</span>
If EnforceIndex is set the job will only be registered if the passed
JobModifyIndex matches the current job's index. If the index is zero,
the register only occurs if the job is new. This paradigm allows
check-and-set style job updating.
</li>
<li>
<span class="param">JobModifyIndex</span>
<span class="param-flags">optional</span>
The JobModifyIndex to enforce the current job is at.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"EvalID": "d092fdc0-e1fd-2536-67d8-43af8ca798ac",
"EvalCreateIndex": 35,
"JobModifyIndex": 34,
}
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Dispatch a new instance of a parameterized job.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/dispatch`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">Payload</span>
<span class="param-flags">optional</span>
A `[]byte` array encoded as a base64 string with a maximum size of 16KiB.
</li>
<li>
<span class="param">Meta</span>
<span class="param-flags">optional</span>
A `map[string]string` of metadata keys to their values.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"Index": 13,
"JobCreateIndex": 12,
"EvalCreateIndex": 13,
"EvalID": "e5f55fac-bc69-119d-528a-1fc7ade5e02c",
"DispatchedJobID": "example/dispatch-1485408778-81644024"
}
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Creates a new evaluation for the given job. This can be used to force
run the scheduling logic if necessary.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/evaluate`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"EvalID": "d092fdc0-e1fd-2536-67d8-43af8ca798ac",
"EvalCreateIndex": 35,
"JobModifyIndex": 34,
}
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Invoke a dry-run of the scheduler for the job.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/plan`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">Job</span>
<span class="param-flags">required</span>
The JSON definition of the job.
</li>
<li>
<span class="param">Diff</span>
<span class="param-flags">optional</span>
Whether the diff structure between the submitted and server side version
of the job should be included in the response.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"Index": 0,
"NextPeriodicLaunch": "0001-01-01T00:00:00Z",
"Diff": {
"Type": "Added",
"TaskGroups": [
{
"Updates": {
"create": 1
},
"Type": "Added",
"Tasks": [
{
"Type": "Added",
"Objects": [...],
"Name": "redis",
"Fields": [
{
"Type": "Added",
"Old": "",
"New": "docker",
"Name": "Driver",
"Annotations": null
},
{
"Type": "Added",
"Old": "",
"New": "5000000000",
"Name": "KillTimeout",
"Annotations": null
}
],
"Annotations": [
"forces create"
]
}
],
"Objects": [...],
"Name": "cache",
"Fields": [...]
}
],
"Objects": [
{
"Type": "Added",
"Objects": null,
"Name": "Datacenters",
"Fields": [...]
},
{
"Type": "Added",
"Objects": null,
"Name": "Constraint",
"Fields": [...]
},
{
"Type": "Added",
"Objects": null,
"Name": "Update",
"Fields": [...]
}
],
"ID": "example",
"Fields": [...],
...
]
},
"CreatedEvals": [
{
"ModifyIndex": 0,
"CreateIndex": 0,
"SnapshotIndex": 0,
"AnnotatePlan": false,
"EscapedComputedClass": false,
"NodeModifyIndex": 0,
"NodeID": "",
"JobModifyIndex": 0,
"JobID": "example",
"TriggeredBy": "job-register",
"Type": "batch",
"Priority": 50,
"ID": "312e6a6d-8d01-0daf-9105-14919a66dba3",
"Status": "blocked",
"StatusDescription": "created to place remaining allocations",
"Wait": 0,
"NextEval": "",
"PreviousEval": "80318ae4-7eda-e570-e59d-bc11df134817",
"BlockedEval": "",
"FailedTGAllocs": null,
"ClassEligibility": {
"v1:7968290453076422024": true
}
}
],
"JobModifyIndex": 0,
"FailedTGAllocs": {
"cache": {
"CoalescedFailures": 3,
"AllocationTime": 46415,
"Scores": null,
"NodesEvaluated": 1,
"NodesFiltered": 0,
"NodesAvailable": {
"dc1": 1
},
"ClassFiltered": null,
"ConstraintFiltered": null,
"NodesExhausted": 1,
"ClassExhausted": null,
"DimensionExhausted": {
"cpu exhausted": 1
}
}
},
"Annotations": {
"DesiredTGUpdates": {
"cache": {
"DestructiveUpdate": 0,
"InPlaceUpdate": 0,
"Stop": 0,
"Migrate": 0,
"Place": 11,
"Ignore": 0
}
}
}
}
```
</dd>
<dt>Field Reference</dt>
<dd>
<ul>
<li>
<span class="param">Diff</span>
A diff structure between the submitted job and the server side version.
The top-level object is a Job Diff which contains Task Group Diffs,
which in turn contain Task Diffs. Each of these objects then has Object
and Field Diff structures embedded.
</li>
<li>
<span class="param">NextPeriodicLaunch</span>
If the job being planned is periodic, this field will include the next
launch time for the job.
</li>
<li>
<span class="param">CreatedEvals</span>
A set of evaluations that were created as a result of the dry-run. These
evaluations can signify a follow-up rolling update evaluation or a
blocked evaluation.
</li>
<li>
<span class="param">JobModifyIndex</span>
The JobModifyIndex of the server side version of this job.
</li>
<li>
<span class="param">FailedTGAllocs</span>
A set of metrics to understand any allocation failures that occurred for
the Task Group.
</li>
<li>
<span class="param">Annotations</span>
Annotations include the DesiredTGUpdates, which tracks what the
scheduler would do given enough resources for each Task Group.
</li>
</ul>
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Forces a new instance of the periodic job. A new instance will be created
even if it violates the job's
[`prohibit_overlap`](/docs/job-specification/periodic.html#prohibit_overlap) settings. As
such, this should be only used to immediately run a periodic job.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>/periodic/force`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"EvalCreateIndex": 7,
"EvalID": "57983ddd-7fcf-3e3a-fd24-f699ccfb36f4"
}
```
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Deregisters a job, and stops all allocations part of it.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/v1/job/<ID>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"EvalID": "d092fdc0-e1fd-2536-67d8-43af8ca798ac",
"EvalCreateIndex": 35,
"JobModifyIndex": 34,
}
```
</dd>
</dl>

104
website/source/docs/http/jobs.html.md
View File

@@ -1,104 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/jobs"
sidebar_current: "docs-http-jobs"
description: |-
The '/1/jobs' endpoint is used list jobs and register new ones.
---
# /v1/jobs
The `jobs` endpoint is used to query the status of existing jobs in Nomad
and to register new jobs. By default, the agent's local region is used;
another region can be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Lists all the jobs registered with Nomad.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/jobs`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">prefix</span>
<span class="param-flags">optional</span>
Filter jobs based on an identifier prefix.
</li>
</ul>
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "binstore-storagelocker",
"Name": "binstore-storagelocker",
"Type": "service",
"Priority": 50,
"Status": "",
"StatusDescription": "",
"CreateIndex": 14,
"ModifyIndex": 14
},
...
]
```
</dd>
</dl>
## PUT / POST
<dl>
<dt>Description</dt>
<dd>
Registers a new job.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/jobs`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">Job</span>
<span class="param-flags">required</span>
The JSON definition of the job. The general structure is given
by the [job specification](/docs/http/json-jobs.html).
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"EvalID": "d092fdc0-e1fd-2536-67d8-43af8ca798ac",
"EvalCreateIndex": 35,
"JobModifyIndex": 34,
}
```
</dd>
</dl>

761
website/source/docs/http/json-jobs.html.md
View File

@@ -1,761 +0,0 @@
---
layout: "http"
page_title: "HTTP API: JSON Job Specification"
sidebar_current: "docs-http-json-jobs"
description: |-
Jobs can also be specified via the HTTP API using a JSON format. This guide
discusses the job specification in JSON format.
---
# Job Specification
This guide covers the JSON syntax for submitting jobs to Nomad. A useful command
for generating valid JSON versions of HCL jobs is
`nomad run -output <job.nomad>` which will emit a JSON version of the job.
## JSON Syntax
Below is an example of a JSON object that submits a `periodic` job to Nomad:
```json
{
"Job":{
"Region":"global",
"ID":"example",
"Name":"example",
"Type":"batch",
"Priority":50,
"AllAtOnce":false,
"Datacenters":[
"dc1"
],
"Constraints":[
{
"LTarget":"${attr.kernel.name}",
"RTarget":"linux",
"Operand":"="
}
],
"TaskGroups":[
{
"Name":"cache",
"Count":1,
"Constraints":null,
"Tasks":[
{
"Name":"redis",
"Driver":"docker",
"User":"foo-user",
"Config":{
"image":"redis:latest",
"port_map":[
{
"db":6379
}
]
},
"Constraints":null,
"Env":{
"foo":"bar",
"baz":"pipe"
},
"Services":[
{
"Name":"cache-redis",
"Tags":[
"global",
"cache"
],
"PortLabel":"db",
"Checks":[
{
"Id":"",
"Name":"alive",
"Type":"tcp",
"Command":"",
"Args":null,
"Path":"",
"Protocol":"",
"Interval":10000000000,
"Timeout":2000000000
}
]
}
],
"Vault": {
"Policies": ["policy-name"],
"Env": true,
"ChangeMode": "restart",
"ChangeSignal": ""
},
"Resources":{
"CPU":500,
"MemoryMB":256,
"IOPS":0,
"Networks":[
{
"ReservedPorts":[
{
"Label":"rpc",
"Value":25566
}
],
"DynamicPorts":[
{
"Label":"db"
}
],
"MBits":10
}
]
},
"Meta":{
"foo":"bar",
"baz":"pipe"
},
"KillTimeout":5000000000,
"LogConfig":{
"MaxFiles":10,
"MaxFileSizeMB":10
},
"Templates":[
{
"SourcePath": "local/config.conf.tpl",
"DestPath": "local/config.conf",
"EmbeddedTmpl": "",
"ChangeMode": "signal",
"ChangeSignal": "SIGUSR1",
"Splay": 5000000000
}
],
"Artifacts":[
{
"GetterSource":"http://foo.com/artifact.tar.gz",
"GetterOptions":{
"checksum":"md5:c4aa853ad2215426eb7d70a21922e794"
},
"RelativeDest":"local/"
}
],
"DispatchPayload": {
"File": "config.json"
}
}
],
"RestartPolicy":{
"Interval":300000000000,
"Attempts":10,
"Delay":25000000000,
"Mode":"delay"
},
"Meta":{
"foo":"bar",
"baz":"pipe"
}
}
],
"Update":{
"Stagger":10000000000,
"MaxParallel":1
},
"Periodic":{
"Enabled":true,
"Spec":"* * * * *",
"SpecType":"cron",
"ProhibitOverlap":true
},
"Meta":{
"foo":"bar",
"baz":"pipe"
},
"ParameterizedJob": {
"Payload": "required",
"MetaRequired": [
"foo"
],
"MetaOptional": [
"bar"
]
},
"Payload": null
}
}
```
## Syntax Reference
Following is a syntax reference for the possible keys that are supported
and their default values if any for each type of object.
### Job
The `Job` object supports the following keys:
* `AllAtOnce` - Controls if the entire set of tasks in the job must
be placed atomically or if they can be scheduled incrementally.
This should only be used for special circumstances. Defaults to `false`.
* `Constraints` - A list to define additional constraints where a job can be
run. See the constraint reference for more details.
* `Datacenters` - A list of datacenters in the region which are eligible
for task placement. This must be provided, and does not have a default.
* `TaskGroups` - A list to define additional task groups. See the task group
reference for more details.
* `Meta` - Annotates the job with opaque metadata.
* `ParameterizedJob` - Specifies the job as a paramterized job such that it can
be dispatched against. The `ParamaterizedJob` object supports the following
attributes:
* `MetaOptional` - Specifies the set of metadata keys that may be provided
when dispatching against the job as a string array.
* `MetaRequired` - Specifies the set of metadata keys that must be provided
when dispatching against the job as a string array.
* `Payload` - Specifies the requirement of providing a payload when
dispatching against the parameterized job. The options for this field are
"optional", "required" and "forbidden". The default value is "optional".
* `Payload` - The payload may not be set when submitting a job but may appear in
a dispatched job. The `Payload` will be a base64 encoded string containing the
payload that the job was dispatched with. The `payload` has a **maximum size
of 16 KiB**.
* `Priority` - Specifies the job priority which is used to prioritize
scheduling and access to resources. Must be between 1 and 100 inclusively,
and defaults to 50.
* `Region` - The region to run the job in, defaults to "global".
* `Type` - Specifies the job type and switches which scheduler
is used. Nomad provides the `service`, `system` and `batch` schedulers,
and defaults to `service`. To learn more about each scheduler type visit
[here](/docs/runtime/schedulers.html)
* `Update` - Specifies the task's update strategy. When omitted, rolling
updates are disabled. The `Update` object supports the following attributes:
* `MaxParallel` - `MaxParallel` is given as an integer value and specifies
the number of tasks that can be updated at the same time.
* `Stagger` - `Stagger` introduces a delay between sets of task updates and
is given in nanoseconds.
An example `Update` block:
```json
{
"Update": {
"MaxParallel" : 3,
"Stagger" : 10000000000
}
}
```
* `Periodic` - `Periodic` allows the job to be scheduled at fixed times, dates
or intervals. The periodic expression is always evaluated in the UTC
timezone to ensure consistent evaluation when Nomad Servers span multiple
time zones. The `Periodic` object is optional and supports the following attributes:
* `Enabled` - `Enabled` determines whether the periodic job will spawn child
jobs.
* `time_zone` - Specifies the time zone to evaluate the next launch interval
against. This is useful when wanting to account for day light savings in
various time zones. The time zone must be parsable by Golang's
[LoadLocation](https://golang.org/pkg/time/#LoadLocation). The default is
UTC.
* `SpecType` - `SpecType` determines how Nomad is going to interpret the
periodic expression. `cron` is the only supported `SpecType` currently.
* `Spec` - A cron expression configuring the interval the job is launched
at. Supports predefined expressions such as "@daily" and "@weekly" See
[here](https://github.com/gorhill/cronexpr#implementation) for full
documentation of supported cron specs and the predefined expressions.
* <a id="prohibit_overlap">`ProhibitOverlap`</a> - `ProhibitOverlap` can
be set to true to enforce that the periodic job doesn't spawn a new
instance of the job if any of the previous jobs are still running. It is
defaulted to false.
An example `periodic` block:
```json
{
"Periodic": {
"Spec": "*/15 * * * * *"
"SpecType": "cron",
"Enabled": true,
"ProhibitOverlap": true
}
}
```
### Task Group
`TaskGroups` is a list of `TaskGroup` objects, each supports the following
attributes:
* `Constraints` - This is a list of `Constraint` objects. See the constraint
reference for more details.
* `Count` - Specifies the number of the task groups that should
be running. Must be non-negative, defaults to one.
* `Meta` - A key-value map that annotates the task group with opaque metadata.
* `Name` - The name of the task group. Must be specified.
* `RestartPolicy` - Specifies the restart policy to be applied to tasks in this group.
If omitted, a default policy for batch and non-batch jobs is used based on the
job type. See the [restart policy reference](#restart_policy) for more details.
* `EphemeralDisk` - Specifies the group's ephemeral disk requirements. See the
[ephemeral disk reference](#ephemeral_disk) for more details.
* `Tasks` - A list of `Task` object that are part of the task group.
### Task
The `Task` object supports the following keys:
* `Artifacts` - `Artifacts` is a list of `Artifact` objects which define
artifacts to be downloaded before the task is run. See the artifacts
reference for more details.
* `Config` - A map of key-value configuration passed into the driver
to start the task. The details of configurations are specific to
each driver.
* `Constraints` - This is a list of `Constraint` objects. See the constraint
reference for more details.
- `DispatchPayload` - Configures the task to have access to dispatch payloads.
The `DispatchPayload` object supports the following attributes:
* `File` - Specifies the file name to write the content of dispatch payload
to. The file is written relative to the task's local directory.
* `Driver` - Specifies the task driver that should be used to run the
task. See the [driver documentation](/docs/drivers/index.html) for what
is available. Examples include `docker`, `qemu`, `java`, and `exec`.
* `Env` - A map of key-value representing environment variables that
will be passed along to the running process. Nomad variables are
interpreted when set in the environment variable values. See the table of
interpreted variables [here](/docs/runtime/interpolation.html).
For example the below environment map will be reinterpreted:
```json
{
"Env": {
"NODE_CLASS" : "${nomad.class}"
}
}
```
* `KillTimeout` - `KillTimeout` is a time duration in nanoseconds. It can be
used to configure the time between signaling a task it will be killed and
actually killing it. Drivers first sends a task the `SIGINT` signal and then
sends `SIGTERM` if the task doesn't die after the `KillTimeout` duration has
elapsed. The default `KillTimeout` is 5 seconds.
* `leader` - Specifies whether the task is the leader task of the task group. If
set to true, when the leader task completes, all other tasks within the task
group will be gracefully shutdown.
* `LogConfig` - This allows configuring log rotation for the `stdout` and `stderr`
buffers of a Task. See the log rotation reference below for more details.
* `Meta` - Annotates the task group with opaque metadata.
* `Name` - The name of the task. This field is required.
* `Resources` - Provides the resource requirements of the task.
See the resources reference for more details.
* `Services` - `Services` is a list of `Service` objects. Nomad integrates with
Consul for service discovery. A `Service` object represents a routable and
discoverable service on the network. Nomad automatically registers when a task
is started and de-registers it when the task transitions to the dead state.
[Click here](/docs/service-discovery/index.html) to learn more about
services. Below is the fields in the `Service` object:
* `Name`: An explicit name for the Service. Nomad will replace `${JOB}`,
`${TASKGROUP}` and `${TASK}` by the name of the job, task group or task,
respectively. `${BASE}` expands to the equivalent of
`${JOB}-${TASKGROUP}-${TASK}`, and is the default name for a Service.
Each service defined for a given task must have a distinct name, so if
a task has multiple services only one of them can use the default name
and the others must be explicitly named. Names must adhere to
[RFC-1123 §2.1](https://tools.ietf.org/html/rfc1123#section-2) and are
limited to alphanumeric and hyphen characters (i.e. `[a-z0-9\-]`), and be
less than 64 characters in length.
* `Tags`: A list of string tags associated with this Service. String
interpolation is supported in tags.
* `PortLabel`: `PortLabel` is an optional string and is used to associate
a port with the service. If specified, the port label must match one
defined in the resources block. This could be a label of either a
dynamic or a static port.
* `Checks`: `Checks` is an array of check objects. A check object defines a
health check associated with the service. Nomad supports the `script`,
`http` and `tcp` Consul Checks. Script checks are not supported for the
qemu driver since the Nomad client doesn't have access to the file system
of a task using the Qemu driver.
* `Type`: This indicates the check types supported by Nomad. Valid
options are currently `script`, `http` and `tcp`.
* `Name`: The name of the health check.
* `Interval`: This indicates the frequency of the health checks that
Consul will perform.
* `Timeout`: This indicates how long Consul will wait for a health
check query to succeed.
* `Path`: The path of the http endpoint which Consul will query to query
the health of a service if the type of the check is `http`. Nomad
will add the IP of the service and the port, users are only required
to add the relative URL of the health check endpoint.
* `Protocol`: This indicates the protocol for the http checks. Valid
options are `http` and `https`. We default it to `http`.
* `Command`: This is the command that the Nomad client runs for doing
script based health check.
* `Args`: Additional arguments to the `command` for script based health
checks.
* `TLSSkipVerify`: If true, Consul will not attempt to verify the
certificate when performing HTTPS checks. Requires Consul >= 0.7.2.
* `Templates` - Specifies the set of [`Template`](#template) objects to render for the task.
Templates can be used to inject both static and dynamic configuration with
data populated from environment variables, Consul and Vault.
* `User` - Set the user that will run the task. It defaults to the same user
the Nomad client is being run as. This can only be set on Linux platforms.
### Resources
The `Resources` object supports the following keys:
* `CPU` - The CPU required in MHz.
* `IOPS` - The number of IOPS required given as a weight between 10-1000.
* `MemoryMB` - The memory required in MB.
* `Networks` - A list of network objects.
The Network object supports the following keys:
* `MBits` - The number of MBits in bandwidth required.
Nomad can allocate two types of ports to a task - Dynamic and Static/Reserved
ports. A network object allows the user to specify a list of `DynamicPorts` and
`ReservedPorts`. Each object supports the following attributes:
* `Value` - The port number for static ports. If the port is dynamic, then this
attribute is ignored.
* `Label` - The label to annotate a port so that it can be referred in the
service discovery block or environment variables.
<a id="ephemeral_disk"></a>
### Ephemeral Disk
The `EphemeralDisk` object supports the following keys:
* `Migrate` - Specifies that the Nomad client should make a best-effort attempt
to migrate the data from a remote machine if placement cannot be made on the
original node. During data migration, the task will block starting until the
data migration has completed. Value is a boolean and the default is false.
* `SizeMB` - Specifies the size of the ephemeral disk in MB. Default is 300.
* `Sticky` - Specifies that Nomad should make a best-effort attempt to place the
updated allocation on the same machine. This will move the `local/` and
`alloc/data` directories to the new allocation. Value is a boolean and the
default is false.
<a id="restart_policy"></a>
### Restart Policy
The `RestartPolicy` object supports the following keys:
* `Attempts` - `Attempts` is the number of restarts allowed in an `Interval`.
* `Interval` - `Interval` is a time duration that is specified in nanoseconds.
The `Interval` begins when the first task starts and ensures that only
`Attempts` number of restarts happens within it. If more than `Attempts`
number of failures happen, behavior is controlled by `Mode`.
* `Delay` - A duration to wait before restarting a task. It is specified in
nanoseconds. A random jitter of up to 25% is added to the delay.
* `Mode` - `Mode` is given as a string and controls the behavior when the task
fails more than `Attempts` times in an `Interval`. Possible values are listed
below:
* `delay` - `delay` will delay the next restart until the next `Interval` is
reached.
* `fail` - `fail` will not restart the task again.
### Constraint
The `Constraint` object supports the following keys:
* `LTarget` - Specifies the attribute to examine for the
constraint. See the table of attributes [here](/docs/runtime/interpolation.html#interpreted_node_vars).
* `RTarget` - Specifies the value to compare the attribute against.
This can be a literal value, another attribute or a regular expression if
the `Operator` is in "regexp" mode.
* `Operand` - Specifies the test to be performed on the two targets. It takes on the
following values:
* `regexp` - Allows the `RTarget` to be a regular expression to be matched.
* `set_contains` - Allows the `RTarget` to be a comma separated list of values
that should be contained in the LTarget's value.
* `distinct_host` - If set, the scheduler will not co-locate any task groups on the same
machine. This can be specified as a job constraint which applies the
constraint to all task groups in the job, or as a task group constraint which
scopes the effect to just that group. The constraint may not be
specified at the task level.
Placing the constraint at both the job level and at the task group level is
redundant since when placed at the job level, the constraint will be applied
to all task groups. When specified, `LTarget` and `RTarget` should be
omitted.
* `distinct_property` - If set, the scheduler selects nodes that have a
distinct value of the specified property for each allocation. This can
be specified as a job constraint which applies the constraint to all
task groups in the job, or as a task group constraint which scopes the
effect to just that group. The constraint may not be specified at the
task level.
Placing the constraint at both the job level and at the task group level is
redundant since when placed at the job level, the constraint will be applied
to all task groups. When specified, `LTarget` should be the property
that should be distinct and and `RTarget` should be omitted.
* Comparison Operators - `=`, `==`, `is`, `!=`, `not`, `>`, `>=`, `<`, `<=`. The
ordering is compared lexically.
### Log Rotation
The `LogConfig` object configures the log rotation policy for a task's `stdout` and
`stderr`. The `LogConfig` object supports the following attributes:
* `MaxFiles` - The maximum number of rotated files Nomad will retain for
`stdout` and `stderr`, each tracked individually.
* `MaxFileSizeMB` - The size of each rotated file. The size is specified in
`MB`.
If the amount of disk resource requested for the task is less than the total
amount of disk space needed to retain the rotated set of files, Nomad will return
a validation error when a job is submitted.
```json
{
"LogConfig": {
"MaxFiles": 3,
"MaxFileSizeMB": 10
}
}
```
In the above example we have asked Nomad to retain 3 rotated files for both
`stderr` and `stdout` and size of each file is 10MB. The minimum disk space that
would be required for the task would be 60MB.
### Artifact
Nomad downloads artifacts using
[`go-getter`](https://github.com/hashicorp/go-getter). The `go-getter` library
allows downloading of artifacts from various sources using a URL as the input
source. The key-value pairs given in the `options` block map directly to
parameters appended to the supplied `source` URL. These are then used by
`go-getter` to appropriately download the artifact. `go-getter` also has a CLI
tool to validate its URL and can be used to check if the Nomad `artifact` is
valid.
Nomad allows downloading `http`, `https`, and `S3` artifacts. If these artifacts
are archives (zip, tar.gz, bz2, etc.), these will be unarchived before the task
is started.
The `Artifact` object supports the following keys:
* `GetterSource` - The path to the artifact to download.
* `RelativeDest` - An optional path to download the artifact into relative to the
root of the task's directory. If omitted, it will default to `local/`.
* `GetterOptions` - A `map[string]string` block of options for `go-getter`.
Full documentation of supported options are available
[here](https://github.com/hashicorp/go-getter/tree/ef5edd3d8f6f482b775199be2f3734fd20e04d4a#protocol-specific-options-1).
An example is given below:
```json
{
"GetterOptions": {
"checksum": "md5:c4aa853ad2215426eb7d70a21922e794",
"aws_access_key_id": "<id>",
"aws_access_key_secret": "<secret>",
"aws_access_token": "<token>"
}
}
```
An example of downloading and unzipping an archive is as simple as:
```json
{
"Artifacts": [
{
"GetterSource": "https://example.com/my.zip",
"GetterOptions": {
"checksum": "md5:7f4b3e3b4dd5150d4e5aaaa5efada4c3"
}
}
]
}
```
#### S3 examples
S3 has several different types of addressing and more detail can be found
[here](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html#access-bucket-intro)
S3 region specific endpoints can be found
[here](http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region)
Path based style:
```json
{
"Artifacts": [
{
"GetterSource": "https://s3-us-west-2.amazonaws.com/my-bucket-example/my_app.tar.gz",
}
]
}
```
or to override automatic detection in the URL, use the S3-specific syntax
```json
{
"Artifacts": [
{
"GetterSource": "s3::https://s3-eu-west-1.amazonaws.com/my-bucket-example/my_app.tar.gz",
}
]
}
```
Virtual hosted based style
```json
{
"Artifacts": [
{
"GetterSource": "my-bucket-example.s3-eu-west-1.amazonaws.com/my_app.tar.gz",
}
]
}
```
### Template
The `Template` block instantiates an instance of a template renderer. This
creates a convenient way to ship configuration files that are populated from
environment variables, Consul data, Vault secrets, or just general
configurations within a Nomad task.
Nomad utilizes a tool called [Consul Template][ct]. Since Nomad v0.5.3, the
template can reference [Nomad's runtime environment variables][env]. For a full
list of the API template functions, please refer to the [Consul Template
README][ct].
`Template` object supports following attributes:
- `ChangeMode` - Specifies the behavior Nomad should take if the rendered
template changes. The default value is `"restart"`. The possible values are:
- `"noop"` - take no action (continue running the task)
- `"restart"` - restart the task
- `"signal"` - send a configurable signal to the task
* `ChangeSignal` - Specifies the signal to send to the task as a string like
"SIGUSR1" or "SIGINT". This option is required if the `ChangeMode` is
`signal`.
* `DestPath` - Specifies the location where the resulting template should be
rendered, relative to the task directory.
* `EmbeddedTmpl` - Specifies the raw template to execute. One of `SourcePath`
or `EmbeddedTmpl` must be specified, but not both. This is useful for smaller
templates, but we recommend using `SourcePath` for larger templates.
* `LeftDelim` - Specifies the left delimiter to use in the template. The default
is "{{" for some templates, it may be easier to use a different delimiter that
does not conflict with the output file itself.
* `Perms` - Specifies the rendered template's permissions. File permissions are
given as octal of the unix file permissions rwxrwxrwx.
* `RightDelim` - Specifies the right delimiter to use in the template. The default
is "}}" for some templates, it may be easier to use a different delimiter that
does not conflict with the output file itself.
* `SourcePath` - Specifies the path to the template to be rendered. `SourcePath`
is mutually exclusive with `EmbeddedTmpl` attribute. The source can be fetched
using an [`Artifact`](#artifact) resource. The template must exist on the
machine prior to starting the task; it is not possible to reference a template
inside of a Docker container, for example.
* `Splay` - Specifies a random amount of time to wait between 0ms and the given
splay value before invoking the change mode. Should be specified in
nanoseconds.
```json
{
"Templates": [
{
"SourcePath": "local/config.conf.tpl",
"DestPath": "local/config.conf",
"EmbeddedTmpl": "",
"ChangeMode": "signal",
"ChangeSignal": "SIGUSR1",
"Splay": 5000000000
}
]
}
```
[ct]: https://github.com/hashicorp/consul-template "Consul Template by HashiCorp"
[env]: /docs/runtime/environment.html "Nomad Runtime Environment"

392
website/source/docs/http/node.html.md
View File

@@ -1,392 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/node"
sidebar_current: "docs-http-node-"
description: |-
The '/1/node-' endpoint is used to query a specific client node.
---
# /v1/node
The `node` endpoint is used to query the a specific client node.
By default, the agent's local region is used; another region can
be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Query the status of a client node registered with Nomad.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/node/<ID>`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"ID": "c9972143-861d-46e6-df73-1d8287bc3e66",
"Datacenter": "dc1",
"Name": "Armons-MacBook-Air.local",
"Attributes": {
"arch": "amd64",
"cpu.frequency": "1300.000000",
"cpu.modelname": "Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz",
"cpu.numcores": "2",
"cpu.totalcompute": "2600.000000",
"driver.exec": "1",
"driver.java": "1",
"driver.java.runtime": "Java(TM) SE Runtime Environment (build 1.8.0_05-b13)",
"driver.java.version": "1.8.0_05",
"driver.java.vm": "Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)",
"hostname": "Armons-MacBook-Air.local",
"kernel.name": "darwin",
"kernel.version": "14.4.0",
"memory.totalbytes": "8589934592",
"network.ip-address": "127.0.0.1",
"os.name": "darwin",
"os.version": "14.4.0",
"storage.bytesfree": "35888713728",
"storage.bytestotal": "249821659136",
"storage.volume": "/dev/disk1"
},
"Resources": {
"CPU": 2600,
"MemoryMB": 8192,
"DiskMB": 34226,
"IOPS": 0,
"Networks": null
},
"Reserved": {
"CPU": 0,
"MemoryMB": 0,
"DiskMB": 0,
"IOPS": 0,
"Networks": null
},
"Links": {},
"Meta": {},
"NodeClass": "",
"Drain": false,
"Status": "ready",
"StatusDescription": "",
"CreateIndex": 3,
"ModifyIndex": 4
}
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Query the allocations belonging to a single node.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/node/<ID>/allocations`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "203266e5-e0d6-9486-5e05-397ed2b184af",
"EvalID": "e68125ed-3fba-fb46-46cc-291addbc4455",
"Name": "example.cache[0]",
"NodeID": "e02b6169-83bd-9df6-69bd-832765f333eb",
"JobID": "example",
"ModifyIndex": 9,
"Resources": {
"Networks": [
{
"DynamicPorts": [
{
"Value": 20802,
"Label": "db"
}
],
"ReservedPorts": null,
"MBits": 10,
"IP": "",
"CIDR": "",
"Device": ""
}
],
"IOPS": 0,
"DiskMB": 0,
"MemoryMB": 256,
"CPU": 500
},
"TaskGroup": "cache",
"Job": {
"ModifyIndex": 5,
"CreateIndex": 5,
"StatusDescription": "",
"Status": "",
"Meta": null,
"Update": {
"MaxParallel": 1,
"Stagger": 1e+10
},
"TaskGroups": [
{
"Meta": null,
"Tasks": [
{
"Meta": null,
"Resources": {
"Networks": [
{
"DynamicPorts": [
{
"Value": 20802,
"Label": "db"
}
],
"ReservedPorts": null,
"MBits": 0,
"IP": "127.0.0.1",
"CIDR": "",
"Device": "lo"
}
],
"IOPS": 0,
"DiskMB": 0,
"MemoryMB": 256,
"CPU": 500
},
"Constraints": null,
"Services": [
{
"Checks": [
{
"Timeout": 2e+09,
"Interval": 1e+10,
"Protocol": "",
"Http": "",
"Script": "",
"Type": "tcp",
"Name": "alive",
"Id": ""
}
],
"PortLabel": "db",
"Tags": [
"global",
"cache"
],
"Name": "example-cache-redis",
"Id": ""
}
],
"Env": null,
"Config": {
"port_map": [
{
"db": 6379
}
],
"image": "redis:latest"
},
"Driver": "docker",
"Name": "redis"
}
],
"RestartPolicy": {
"Delay": 2.5e+10,
"Interval": 3e+11,
"Attempts": 10
},
"Constraints": null,
"Count": 1,
"Name": "cache"
}
],
"Region": "global",
"ID": "example",
"Name": "example",
"Type": "service",
"Priority": 50,
"AllAtOnce": false,
"Datacenters": [
"dc1"
],
"Constraints": [
{
"Operand": "=",
"RTarget": "linux",
"LTarget": "${attr.kernel.name}"
}
]
},
"TaskResources": {
"redis": {
"Networks": [
{
"DynamicPorts": [
{
"Value": 20802,
"Label": "db"
}
],
"ReservedPorts": null,
"MBits": 0,
"IP": "127.0.0.1",
"CIDR": "",
"Device": "lo"
}
],
"IOPS": 0,
"DiskMB": 0,
"MemoryMB": 256,
"CPU": 500
}
},
"Metrics": {
"CoalescedFailures": 0,
"AllocationTime": 1590406,
"NodesEvaluated": 1,
"NodesFiltered": 0,
"ClassFiltered": null,
"ConstraintFiltered": null,
"NodesExhausted": 0,
"ClassExhausted": null,
"DimensionExhausted": null,
"Scores": {
"e02b6169-83bd-9df6-69bd-832765f333eb.binpack": 6.133651487695705
}
},
"DesiredStatus": "run",
"DesiredDescription": "",
"ClientStatus": "running",
"ClientDescription": "",
"TaskStates": {
"redis": {
"Events": [
{
"KillError": "",
"Message": "",
"Signal": 0,
"ExitCode": 0,
"DriverError": "",
"Time": 1447806038427841000,
"Type": "Started"
}
],
"State": "running"
}
},
"CreateIndex": 7
},
...
]
```
</dd>
</dl>
## PUT / POST
<dl>
<dt>Description</dt>
<dd>
Creates a new evaluation for the given node. This can be used to force
run the scheduling logic if necessary.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/node/<ID>/evaluate`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"EvalIDs": ["d092fdc0-e1fd-2536-67d8-43af8ca798ac"],
"EvalCreateIndex": 35,
"NodeModifyIndex": 34
}
```
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Toggle the drain mode of the node. When enabled, no further
allocations will be assigned and existing allocations will be
migrated.
</dd>
<dt>Method</dt>
<dd>PUT or POST</dd>
<dt>URL</dt>
<dd>`/v1/node/<ID>/drain`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">enable</span>
<span class="param-flags">required</span>
Boolean value provided as a query parameter to either set
enabled to true or false.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"EvalID": "d092fdc0-e1fd-2536-67d8-43af8ca798ac",
"EvalCreateIndex": 35,
"NodeModifyIndex": 34
}
```
</dd>
</dl>

66
website/source/docs/http/nodes.html.md
View File

@@ -1,66 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/nodes"
sidebar_current: "docs-http-nodes"
description: |-
The '/1/nodes' endpoint is used to list the client nodes.
---
# /v1/nodes
The `nodes` endpoint is used to query the status of client nodes.
By default, the agent's local region is used; another region can
be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Lists all the client nodes registered with Nomad.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/nodes`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">prefix</span>
<span class="param-flags">optional</span>
Filter nodes based on an identifier prefix.
</li>
</ul>
</dd>
<dt>Blocking Queries</dt>
<dd>
[Supported](/docs/http/index.html#blocking-queries)
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
{
"ID": "c9972143-861d-46e6-df73-1d8287bc3e66",
"Datacenter": "dc1",
"Name": "web-8e40e308",
"NodeClass": "",
"Drain": false,
"Status": "ready",
"StatusDescription": "",
"CreateIndex": 3,
"ModifyIndex": 4
},
...
]
```
</dd>
</dl>

166
website/source/docs/http/operator.html.md
View File

@@ -1,166 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/operator/"
sidebar_current: "docs-http-operator"
description: >
The '/v1/operator/' endpoints provides cluster-level tools for Nomad
operators.
---
# /v1/operator
The Operator endpoint provides cluster-level tools for Nomad operators, such
as interacting with the Raft subsystem. This was added in Nomad 0.5.5
~> Use this interface with extreme caution, as improper use could lead to a
Nomad outage and even loss of data.
See the [Outage Recovery](/guides/outage.html) guide for some examples of how
these capabilities are used. For a CLI to perform these operations manually, please
see the documentation for the [`nomad operator`](/docs/commands/operator-index.html)
command.
By default, the agent's local region is used; another region can be specified
using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Query the status of a client node registered with Nomad.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/operator/raft/configuration`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">stale</span>
<span class="param-flags">optional</span>
If the cluster doesn't currently have a leader an error will be
returned. You can use the `?stale` query parameter to read the Raft
configuration from any of the Nomad servers.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"Servers": [
{
"ID": "127.0.0.1:4647",
"Node": "alice",
"Address": "127.0.0.1:4647",
"Leader": true,
"Voter": true
},
{
"ID": "127.0.0.2:4647",
"Node": "bob",
"Address": "127.0.0.2:4647",
"Leader": false,
"Voter": true
},
{
"ID": "127.0.0.3:4647",
"Node": "carol",
"Address": "127.0.0.3:4647",
"Leader": false,
"Voter": true
}
],
"Index": 22
}
```
</dd>
<dt>Field Reference</dt>
<dd>
<ul>
<li>
<span class="param">Servers</span>
The returned `Servers` array has information about the servers in the Raft
peer configuration. See the `Server` block for a description of its fields:
</li>
<li>
<span class="param">Index</span>
The `Index` value is the Raft corresponding to this configuration. The
latest configuration may not yet be committed if changes are in flight.
</li>
</ul>
`Server` Fields:
<ul>
<li>
<span class="param">ID</span>
`ID` is the ID of the server. This is the same as the `Address` but may
be upgraded to a GUID in a future version of Nomad.
</li>
<li>
<span class="param">Node</span>
`Node` is the node name of the server, as known to Nomad, or "(unknown)" if
the node is stale and not known.
</li>
<li>
<span class="param">Address</span>
`Address` is the IP:port for the server.
</li>
<li>
<span class="param">Leader</span>
`Leader` is either "true" or "false" depending on the server's role in the
Raft configuration.
</li>
<li>
<span class="param">Voter</span>
`Voter` is "true" or "false", indicating if the server has a vote in the Raft
configuration. Future versions of Nomad may add support for non-voting servers.
</li>
</ul>
</dd>
</dl>
## DELETE
<dl>
<dt>Description</dt>
<dd>
Remove the Nomad server with given address from the Raft configuration. The
return code signifies success or failure.
</dd>
<dt>Method</dt>
<dd>DELETE</dd>
<dt>URL</dt>
<dd>`/v1/operator/raft/peer`</dd>
<dt>Parameters</dt>
<dd>
<ul>
<li>
<span class="param">address</span>
<span class="param-flags">required</span>
The address specifies the server to remove and is given as an `IP:port`.
The port number is usually 4647, unless configured otherwise. Nothing is
required in the body of the request.
</li>
</ul>
</dd>
<dt>Returns</dt>
<dd>None</dd>
</dl>

38
website/source/docs/http/regions.html.md
View File

@@ -1,38 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/regions"
sidebar_current: "docs-http-regions"
description: >
The '/v1/regions' endpoint lists the known cluster regions.
---
# /v1/regions
## GET
<dl>
<dt>Description</dt>
<dd>
Returns the known region names.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/regions`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
["region1","region2"]
```
</dd>
</dl>

77
website/source/docs/http/status.html.md
View File

@@ -1,77 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/status/"
sidebar_current: "docs-http-status"
description: |-
The '/1/status/' endpoints are used to query the system status.
---
# /v1/status/leader
By default, the agent's local region is used; another region can
be specified using the `?region=` query parameter.
## GET
<dl>
<dt>Description</dt>
<dd>
Returns the address of the current leader in the region.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/status/leader`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
"127.0.0.1:4647"
```
</dd>
</dl>
# /v1/status/peers
## GET
<dl>
<dt>Description</dt>
<dd>
Returns the set of raft peers in the region.
</dd>
<dt>Method</dt>
<dd>GET</dd>
<dt>URL</dt>
<dd>`/v1/status/peers`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
```javascript
[
"127.0.0.1:4647",
...
]
```
</dd>
</dl>

62
website/source/docs/http/system.html.md
View File

@@ -1,62 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/system/"
sidebar_current: "docs-http-system"
description: |-
The '/1/system/' endpoints are used to for system maintenance.
---
# /v1/system
The `system` endpoint is used to for system maintenance and should not be
necessary for most users. By default, the agent's local region is used; another
region can be specified using the `?region=` query parameter.
## PUT
<dl>
<dt>Description</dt>
<dd>
Initiate garbage collection of jobs, evals, allocations and nodes.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/v1/system/gc`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
None
</dd>
</dl>
<dl>
<dt>Description</dt>
<dd>
Reconcile the summaries of all the registered jobs based.
</dd>
<dt>Method</dt>
<dd>PUT</dd>
<dt>URL</dt>
<dd>`/v1/system/reconcile/summaries`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Returns</dt>
<dd>
None
</dd>
</dl>

209
website/source/docs/http/validate.html.md
View File

@@ -1,209 +0,0 @@
---
layout: "http"
page_title: "HTTP API: /v1/validate/"
sidebar_current: "docs-http-validate"
description: |-
The '/1/validate/' endpoints are used to for validation of objects.
---
# /v1/validate/job
The `/validate/job` endpoint is to validate a Nomad job file. The local Nomad
agent forwards the request to a server. In the event a server can't be
reached the agent verifies the job file locally but skips validating driver
configurations.
## POST
<dl>
<dt>Description</dt>
<dd>
Validates a Nomad job file
</dd>
<dt>Method</dt>
<dd>POST</dd>
<dt>URL</dt>
<dd>`/v1/validate/job`</dd>
<dt>Parameters</dt>
<dd>
None
</dd>
<dt>Body</dt>
<dd>
```javascript
{
"Job": {
"Region": "global",
"ID": "example",
"ParentID": null,
"Name": "example",
"Type": "service",
"Priority": 50,
"AllAtOnce": null,
"Datacenters": [
"dc1"
],
"Constraints": null,
"TaskGroups": [
{
"Name": "cache",
"Count": 1,
"Constraints": null,
"Tasks": [
{
"Name": "mongo",
"Driver": "exec",
"User": "",
"Config": {
"args": [
"-l",
"127.0.0.1",
"0"
],
"command": "/bin/nc"
},
"Constraints": null,
"Env": null,
"Services": null,
"Resources": {
"CPU": 1,
"MemoryMB": 10,
"DiskMB": null,
"IOPS": 0,
"Networks": [
{
"Public": false,
"CIDR": "",
"ReservedPorts": null,
"DynamicPorts": [
{
"Label": "db111",
"Value": 0
},
{
"Label": "http111",
"Value": 0
}
],
"IP": "",
"MBits": 10
}
]
},
"Meta": null,
"KillTimeout": null,
"LogConfig": {
"MaxFiles": 10,
"MaxFileSizeMB": 10
},
"Artifacts": null,
"Vault": null,
"Templates": null,
"DispatchPayload": null
},
{
"Name": "redis",
"Driver": "raw_exec",
"User": "",
"Config": {
"args": [
"-l",
"127.0.0.1",
"0"
],
"command": "/usr/bin/nc"
},
"Constraints": null,
"Env": null,
"Services": null,
"Resources": {
"CPU": 1,
"MemoryMB": 10,
"DiskMB": null,
"IOPS": 0,
"Networks": [
{
"Public": false,
"CIDR": "",
"ReservedPorts": null,
"DynamicPorts": [
{
"Label": "db",
"Value": 0
},
{
"Label": "http",
"Value": 0
}
],
"IP": "",
"MBits": 10
}
]
},
"Meta": null,
"KillTimeout": null,
"LogConfig": {
"MaxFiles": 10,
"MaxFileSizeMB": 10
},
"Artifacts": null,
"Vault": null,
"Templates": null,
"DispatchPayload": null
}
],
"RestartPolicy": {
"Interval": 300000000000,
"Attempts": 10,
"Delay": 25000000000,
"Mode": "delay"
},
"EphemeralDisk": {
"Sticky": null,
"Migrate": null,
"SizeMB": 300
},
"Meta": null
}
],
"Update": {
"Stagger": 10000000000,
"MaxParallel": 0
},
"Periodic": null,
"ParameterizedJob": null,
"Payload": null,
"Meta": null,
"VaultToken": null,
"Status": null,
"StatusDescription": null,
"CreateIndex": null,
"ModifyIndex": null,
"JobModifyIndex": null
}
}
```
</dd>
<dt>Returns</dt>
<dd>
```javascript
{
"DriverConfigValidated": true,
"ValidationErrors": [
"Task group cache validation failed: 1 error(s) occurred:\n\n* Task redis validation failed: 1 error(s) occurred:\n\n* 1 error(s) occurred:\n\n* minimum CPU value is 20; got 1"
],
"Error": "1 error(s) occurred:\n\n* Task group cache validation failed: 1 error(s) occurred:\n\n* Task redis validation failed: 1 error(s) occurred:\n\n* 1 error(s) occurred:\n\n* minimum CPU value is 20; got 1"
}
```
</dd>
</dl>

2
website/source/docs/job-specification/template.html.md
View File

@@ -203,7 +203,7 @@ the key name, the second part is the key's value.
## Client Configuration
The `template` block has the following [client configuration
options](/docs/agent/config.html#options):
options](/docs/agent/configuration/client.html#options):
* `template.allow_host_source` - Allows templates to specify their source
template as an absolute path referencing host directories. Defaults to `true`.

2
website/source/docs/operating-a-job/accessing-logs.html.md
View File

@@ -16,7 +16,7 @@ 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)
- API for programatic [log access](/docs/http/client-fs.html#logs)
- API for programatic [log access](/api/client.html#stream-logs)
This section will utilize the job named "docs" from the [previous
sections](/docs/operating-a-job/submitting-jobs.html), but these operations

2
website/source/docs/operating-a-job/resource-utilization.html.md
View File

@@ -94,4 +94,4 @@ documentation](/docs/agent/telemetry.html).
For more advanced use cases, the resource usage data is also accessible via the
client's HTTP API. See the documentation of the Client's [allocation HTTP
API](/docs/http/client-allocation-stats.html).
API](/api/client.html).