A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://developer.hashicorp.com/nomad/docs/deploy/task-driver/docker below:

Configure the Docker task driver | Nomad

Configure the Docker task driver

Name: docker

The docker driver provides a first-class Docker workflow on Nomad. The Docker driver handles downloading containers, mapping ports, and starting, watching, and cleaning up after containers.

Note: If you are using Docker Desktop for Windows or MacOS, check the FAQ.

The docker driver implements the following capabilities:

Feature Implementation nomad alloc signal true nomad alloc exec true filesystem isolation image network isolation host, group, task volume mounting all

Nomad requires Docker to be installed and running on the host alongside the Nomad agent.

By default Nomad communicates with the Docker daemon using the daemon's Unix socket. Nomad will need to be able to read/write to this socket. If you do not run Nomad as root, make sure you add the Nomad user to the Docker group so Nomad can communicate with the Docker daemon.

For example, on Ubuntu you can use the usermod command to add the nomad user to the docker group so you can run Nomad without root:

$ sudo usermod -G docker -a nomad

Nomad clients manage a cpuset cgroup for each task to reserve or share CPU cores. In order for Nomad to be compatible with Docker's own cgroups management, it must write to cgroups owned by Docker, which requires running as root. If Nomad is not running as root, CPU isolation and NUMA-aware scheduling will not function correctly for workloads with resources.cores, including workloads using task drivers other than docker on the same host.

For the best performance and security features you should use recent versions of the Linux Kernel and Docker daemon.

If you would like to change any of the options related to the docker driver on a Nomad client, you can modify them with the plugin block syntax. Below is an example of a configuration (many of the values are the default). See the next section for more information on the options.

plugin "docker" {
  config {
    endpoint = "unix:///var/run/docker.sock"

    auth {
      config = "/etc/docker-auth.json"
      helper = "ecr-login"
    }

    tls {
      cert = "/etc/nomad/nomad.pub"
      key  = "/etc/nomad/nomad.pem"
      ca   = "/etc/nomad/nomad.cert"
    }

    extra_labels = ["job_name", "job_id", "task_group_name", "task_name", "namespace", "node_name", "node_id"]

    gc {
      image       = true
      image_delay = "3m"
      container   = true

      dangling_containers {
        enabled        = true
        dry_run        = false
        period         = "5m"
        creation_grace = "5m"
      }
    }

    volumes {
      enabled      = true
      selinuxlabel = "z"
    }

    allow_privileged = false
    allow_caps       = ["chown", "net_raw"]
  }
}

["audit_write", "chown", "dac_override", "fowner", "fsetid", "kill", "mknod",
 "net_bind_service", "setfcap", "setgid", "setpcap", "setuid", "sys_chroot"]

which is the same list of capabilities allowed by docker by default (without NET_RAW). Allows the operator to control which capabilities can be obtained by tasks using cap_add and cap_drop options. Supports the value "all" as a shortcut for allow-listing all capabilities supported by the operating system. Note that due to a limitation in Docker, tasks running as non-root users cannot expand the capabilities set beyond the default. They can only have their capabilities reduced.

Warning: Allowing more capabilities beyond the default may lead to undesirable consequences, including untrusted tasks being able to compromise the host system.

Note: client configuration options will soon be deprecated. Please use plugin options instead. See the plugin block documentation for more information.

The docker driver has the following client configuration options:

Note: When testing or using the -dev flag you can use DOCKER_HOST, DOCKER_TLS_VERIFY, and DOCKER_CERT_PATH to customize Nomad's behavior. If docker.endpoint is set Nomad will only read client configuration from the config file.

An example is given below:

client {
  options {
    "docker.cleanup.image" = "false"
  }
}

The docker driver will set the following client attributes:

Here is an example of using these properties in a job file:

job "docs" {
  # Require docker version higher than 1.2.
  constraint {
    attribute = "${attr.driver.docker.version}"
    operator  = ">"
    version   = "1.2"
  }
}
CPU

Nomad limits containers' CPU based on CPU shares. CPU shares allow containers to burst past their CPU limits. CPU limits will only be imposed when there is contention for resources. When the host is under load your process may be throttled to stabilize QoS depending on how many shares it has. You can see how many CPU shares are available to your process by reading NOMAD_CPU_LIMIT. 1000 shares are approximately equal to 1 GHz.

Please keep the implications of CPU shares in mind when you load test workloads on Nomad.

If resources cores is set, the task is given an isolated reserved set of CPU cores to make use of. The total set of cores the task may run on is the private set combined with the variable set of unreserved cores. The private set of CPU cores is available to your process by reading NOMAD_CPU_CORES.

Memory

Nomad limits containers' memory usage based on total virtual memory. This means that containers scheduled by Nomad cannot use swap. This is to ensure that a swappy process does not degrade performance for other workloads on the same host.

Since memory is not an elastic resource, you will need to make sure your container does not exceed the amount of memory allocated to it, or it will be terminated or crash when it tries to malloc. A process can inspect its memory limit by reading NOMAD_MEMORY_LIMIT, but will need to track its own memory usage. Memory limit is expressed in megabytes so 1024 = 1 GB.

IO

Nomad's Docker integration does not currently provide QoS around network or filesystem IO. These will be added in a later release.

Security

Docker provides resource isolation by way of cgroups and namespaces. Containers essentially have a virtual file system all to themselves. If you need a higher degree of isolation between processes for security or other reasons, it is recommended to use full virtualization like QEMU.

Dangling Containers

Nomad has a detector and a reaper for dangling Docker containers, containers that Nomad starts yet does not manage or track. Though rare, they lead to unexpectedly running services, potentially with stale versions.

When Docker daemon becomes unavailable as Nomad starts a task, it is possible for Docker to successfully start the container but return a 500 error code from the API call. In such cases, Nomad retries and eventually aims to kill such containers. However, if the Docker Engine remains unhealthy, subsequent retries and stop attempts may still fail, and the started container becomes a dangling container that Nomad no longer manages.

The newly added reaper periodically scans for such containers. It only targets containers with a com.hashicorp.nomad.allocation_id label, or match Nomad's conventions for naming and bind-mounts (i.e. /alloc, /secrets, local). Containers that don't match Nomad container patterns are left untouched.

Operators can run the reaper in a dry-run mode, where it only logs dangling container ids without killing them, or disable it by setting the gc.dangling_containers config block.

Docker for Windows

Docker for Windows only supports running Windows containers. Because Docker for Windows is relatively new and rapidly evolving you may want to consult the list of relevant issues on GitHub.

Use the Docker task driver in a job.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4