A RetroSearch Logo

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

Search Query:

Showing content from https://developer.hashicorp.com/nomad/docs/configuration/client below:

client Block in Agent Configuration | Nomad

client Block in Agent Configuration

This page provides reference information for configuring a Nomad client in the client block of a Nomad agent configuration. Enable a client, configure allocation directories, artifact and template behavior, networking, node pools, servers to join, garbage collection, workload behavior, client resources, chroot, host volumes, host network, and driver-specific behavior.

Refer to the Set Server and Client Nodes and Nomad Agent pages to learn about the Nomad agent process and how to configure the server and client nodes in your cluster.

client {
  enabled = true
  servers = ["1.2.3.4:4647", "5.6.7.8:4647"]
}
chroot_env Parameters

On Linux, drivers based on isolated fork/exec implement file system isolation using chroot. The chroot_env map lets you configure the chroot environment using source paths on the host operating system.

The mapping format is:

The following example specifies a chroot which contains just enough to run the ls utility:

client {
  chroot_env {
    "/bin/ls"           = "/bin/ls"
    "/etc/ld.so.cache"  = "/etc/ld.so.cache"
    "/etc/ld.so.conf"   = "/etc/ld.so.conf"
    "/etc/ld.so.conf.d" = "/etc/ld.so.conf.d"
    "/etc/passwd"       = "/etc/passwd"
    "/lib"              = "/lib"
    "/lib64"            = "/lib64"
  }
}

Warning chroot limitations: Nomad by default doesn't copy the ephemeral runtime files in the /run directory. For exampe, on Ubuntu, /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, so Nomad doesn't copy resolv.conf to the chroot environment.

In these cases, configure your job's network block for each chroot task.

When chroot_env is unspecified, the exec driver uses a default chroot environment with the most commonly used parts of the operating system. Refer to the Nomad exec driver documentation for the full list.

Nomad never attempts to embed the alloc_dir in the chroot as doing so would cause infinite recursion.

options Parameters

The following is not an exhaustive list of options for only the Nomad client. To find the options supported by each individual Nomad driver, refer to the drivers documentation.

reserved Parameters artifact Parameters template Parameters host_volume Block

The host_volume block is used to make volumes available to jobs. You can also configure dynamic host volumes via the volume create or volume register commands.

The key of the block corresponds to the name of the volume for use in the source parameter of a "host" type volume and ACLs. A host volume in the configuration cannot have the same name as a dynamic host volume on the same node.

client {
  host_volume "ca-certificates" {
    path      = "/etc/ssl/certs"
    read_only = true
  }
}
host_volume Parameters host_network Block

The host_network block is used to register additional host networks with the node that can be used when port mapping.

The key of the block corresponds to the name of the network used in the host_network.

client {
  host_network "public" {
    cidr           = "203.0.113.0/24"
    reserved_ports = "22,80"
  }
}
host_network Parameters drain_on_shutdown Block

The drain_on_shutdown block controls the behavior of the client when leave_on_interrupt or leave_on_terminate are set. By default drain_on_shutdown is not configured and clients will not drain on any signal.

If drain_on_shutdown is configured, the node will drain itself when receiving the appropriate signal (SIGINT for leave_on_interrupt or SIGTERM on leave_on_terminate). By default this acts similarly to running nomad node drain -self -no-deadline

Note that even if no deadline is set, your init system may send SIGKILL to Nomad if the drain takes longer than allowed by the service shutdown. For example, when running under Linux with systemd, you should adjust the TimeoutStopSec value in the nomad.service unit file to account for enough time for the client to drain.

client {
  # Either leave_on_interrupt or leave_on_terminate must be set
  # for this to take effect.
  drain_on_shutdown {
    deadline           = "1h"
    force              = false
    ignore_system_jobs = false
  }
}
users Block

The users block controls aspects of Nomad client's use of operating system users.

client {
  users {
    dynamic_user_min = 80000
    dynamic_user_max = 89999
  }
}
Common Setup

This example shows the most basic configuration for a Nomad client joined to a cluster.

client {
  enabled = true
  server_join {
    retry_join     = [ "1.1.1.1", "2.2.2.2" ]
    retry_max      = 3
    retry_interval = "15s"
  }
}
Reserved Resources

This example shows a sample configuration for reserving resources to the client. This is useful if you want to allocate only a portion of the client's resources to jobs.

client {
  enabled = true

  reserved {
    cpu            = 500
    memory         = 512
    disk           = 1024
    reserved_ports = "22,80,8500-8600"
  }
}
Custom Metadata and Node Class

This example shows a client configuration which customizes the metadata and node class. The scheduler can use this information while processing constraints. The metadata is completely user configurable; the values in the example are for illustrative purposes only.

client {
  enabled       = true
  node_class    = "prod"

  meta {
    owner           = "ops"
    cached_binaries = "redis,apache,nginx,jq,cypress,nodejs"
    rack            = "rack-12-1"
  }
}

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