open-nomad/website/source/docs/operating-a-job/configuring-tasks.html.md

layout	page_title	sidebar_current	description
docs	Configuring Tasks - Operating a Job	docs-operating-a-job-configuring-tasks	Most applications require some kind of configuration. Whether the configuration is provided via the command line, environment variables, or a configuration file, Nomad has built-in functionality for configuration. This section details three common patterns for configuring tasks.

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:

• -listen - the address:port to 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" {
    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 env stanza
• Templated in the a template stanza

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.