» Configuring 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.
» Command-line 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:
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" {
task "server" {
driver = "exec"
config {
command = "/bin/http-echo"
args = [
"-listen", ":5678",
"-text", "hello world",
]
}
resources {
network {
mbits = 10
port "http" {
static = "5678"
}
}
}
}
}
}
This assumes the http-echo binary is already installed and available in the system path. 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 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" {
task "server" {
driver = "exec"
config {
command = "/bin/http-echo"
args = [
"-listen", ":${NOMAD_PORT_http}",
"-text", "hello world",
]
}
resources {
network {
mbits = 10
port "http" {}
}
}
}
}
}
» 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}"
}
}
See the env docs for details.
» Environment 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.
» Configuration Files
Sometimes applications accept their configurations using files to support complex data structures. Nomad supports downloading artifacts 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 see the artifact documentation.