mirror of
https://github.com/kemko/nomad.git
synced 2026-01-04 01:15:43 +03:00
986f3c727a
* action page * change all page_title fields * update title * constraint through migrate pages * update page title and heading to use sentence case * fix front matter description * Apply suggestions from code review Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com> --------- Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>
63 lines
2.7 KiB
Plaintext
63 lines
2.7 KiB
Plaintext
---
|
|
layout: docs
|
|
page_title: ephemeral_disk block in the job specification
|
|
description: |-
|
|
Describe a group's ephemeral disk requirements in the `ephemeral_disk` block of the Nomad job specification. Turn on data migration and allocation placement. Specify disk size.
|
|
---
|
|
|
|
# `ephemeral_disk` block in the job specification
|
|
|
|
<Placement groups={['job', 'group', 'ephemeral_disk']} />
|
|
|
|
The `ephemeral_disk` block describes the ephemeral disk requirements of the
|
|
group. Ephemeral disks can be marked as sticky and support live data migrations.
|
|
All tasks in this group will share the same ephemeral disk.
|
|
|
|
```hcl
|
|
job "docs" {
|
|
group "example" {
|
|
ephemeral_disk {
|
|
migrate = true
|
|
size = 500
|
|
sticky = true
|
|
}
|
|
}
|
|
}
|
|
```
|
|
|
|
The ephemeral disk can be referenced under `alloc/data/`. More information can
|
|
be found in the [filesystem internals][].
|
|
|
|
Each job's logs will be written to ephemeral disk space. See the [logs
|
|
documentation][] for more information.
|
|
|
|
## Parameters
|
|
|
|
- `migrate` `(bool: false)` - This specifies that the Nomad client should make a
|
|
best-effort attempt to migrate the data from the previous allocation, even if
|
|
the previous allocation was on another client. Enabling `migrate`
|
|
automatically enables `sticky` as well. During data migration, the task will
|
|
block starting until the data migration has completed.
|
|
|
|
Successful migration requires that the clients can reach each other directly
|
|
over the Nomad HTTP port. Any failure of the transfer will result in data
|
|
loss, so this feature is only suitable for data that can be recreated at the
|
|
destination (for example, cache data). Migration is atomic and any partially
|
|
migrated data will be removed from the destination if an error is
|
|
encountered. Note that data migration will not take place if a client garbage
|
|
collects a failed allocation or if the allocation has been intentionally
|
|
stopped via `nomad alloc stop`, because the original allocation has already
|
|
been removed.
|
|
|
|
- `size` `(int: 300)` - Specifies the size of the ephemeral disk in MB. The
|
|
current Nomad ephemeral storage implementation does not enforce this limit;
|
|
however, it is used during job placement.
|
|
|
|
- `sticky` `(bool: false)` - 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.
|
|
|
|
[resources]: /nomad/docs/job-specification/resources 'Nomad resources Job Specification'
|
|
[filesystem internals]: /nomad/docs/concepts/filesystem#templates-artifacts-and-dispatch-payloads 'Filesystem internals documentation'
|
|
[logs documentation]: /nomad/docs/job-specification/logs 'Nomad logs Job Specification'
|