Nomad
Configure job tasks
Most applications require some kind of local configuration. While command line arguments are the simplest method, many applications require more complex configurations provided via environment variables or configuration files. This section explores how to configure Nomad jobs to support many common configuration use cases.
Define application arguments
Many tasks accept configuration via command-line arguments. For example, consider the http-echo server which is a small go binary that renders the provided text as a webpage. The binary accepts two parameters:
- The
-listenflag contains theaddress:portto listen on -text- the text to render as the HTML page
Outside of Nomad, the server is started like this:
$ http-echo -listen=":5678" -text="hello world"
The Nomad equivalent job file might look something like this:
job "docs" {
datacenters = ["dc1"]
group "example" {
network {
port "http" {
static = "5678"
}
}
task "server" {
driver = "exec"
config {
command = "/bin/http-echo"
args = [
"-listen",
":5678",
"-text",
"hello world",
]
}
}
}
}
Note
For this job specification, you must install the http-echo in
the /bin folder on each of your clients. Nomad can
also optionally fetch the binary using the artifact resource.
Nomad has many drivers, and most support passing arguments to their tasks via
the args parameter. This parameter also supports Nomad variable
interpolation. For example, if you wanted Nomad to dynamically allocate a high
port to bind the service on instead of relying on a static port for the previous
job:
job "docs" {
datacenters = ["dc1"]
group "example" {
network {
port "http" {
static = "5678"
}
}
task "server" {
driver = "exec"
config {
command = "/bin/http-echo"
args = [
"-listen",
":${NOMAD_PORT_http}",
"-text",
"hello world",
]
}
}
}
}
Set environment variables
Some applications can be configured via environment variables. The Twelve-Factor App document suggests configuring applications through environment variables. Nomad supports custom environment variables in two ways:
- Interpolation in an
envstanza - Templated in the a
templatestanza
env stanza
Each task may have an env stanza which specifies environment variables:
task "server" {
env {
my_key = "my-value"
}
}
The env stanza also supports interpolation:
task "server" {
env {
LISTEN_PORT = "${NOMAD_PORT_http}"
}
}
Consult the env stanza documentation for details.
Build environment variables with templates
Nomad's template stanza can be used to generate environment variables.
Environment variables may be templated with Node attributes and
metadata, the contents of files on disk, Consul keys, or secrets from
Vault:
template {
data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.key}}{{end}}"
CERT={{ file "path/to/cert.pem" | to JSON }}
NODE_ID="{{ env "node.unique.id" }}"
EOH
destination = "secrets/config.env"
env = true
}
The template will be written to disk and then read as environment variables before your task is launched.
Load external configuration files
Many applications use files for configuration. Nomad supports downloading files
using the artifact stanza and templating them prior to
launching tasks. This allows shipping of configuration files and other assets
that the task needs to run properly.
Here is an example job which pulls down a configuration file as an artifact and templates it:
job "docs" {
datacenters = ["dc1"]
group "example" {
task "server" {
driver = "exec"
artifact {
source = "http://example.com/config.hcl.tmpl"
destination = "local/config.hcl.tmpl"
}
template {
source = "local/config.hcl.tmpl"
destination = "local/config.hcl"
}
config {
command = "my-app"
args = [
"-config", "local/config.hcl",
]
}
}
}
}
For more information on the artifact resource, please consult the artifact
stanza documentation.