[Improvement] Source environment variables from consul-template

[samber]

Hi guys,

I wonder how do you manage environment variables from consul k/v ?
We would like to use your implementation of consul-template with the template stanza, but there is no way to “source” the generated file.

What do you think about developing an env_file stanza in config or task ? Like the following:

task “redis” {
   driver = "docker"
   config {
        image = “redis:3.2”
   }

    env_file {
        source = “local/.env”
    }
    env {
        other_key = "other_value"
    }

    template {
	source = “local/.env.dist”
        destination = “local/.env”
    }
}

or

task “redis” {
   driver = "docker"
   config {
        image = “redis:3.2”
        dot_env = “local/.env”
   }

    env {
        other_key = "other_value"
    }

    template {
	source = “local/.env.dist”
        destination = “local/.env”
    }
}

[dadgar]

Hey,

This is a duplicate of this issue: #1765

Hopefully be able to have this functionality soon 👍

[nanoz]

Hi @dadgar,

I think there is still a usage to include the env_file option, at least for the Docker driver. You might want to download this env file from an artefact, or use advanced consul-template options in order to generate your env file.

Would you refuse a PR implementing that change ?
If so, where do you think the env_file parameter should be placed ? In the Docker driver config {} or in something more generic ?

[dadgar]

@nanoz Can you explain a case where you would need an env_file given that the job file allows you to specify environment variables and env_consul support?

Generally avoid having many ways to do one thing.

[rokka-n]

@dadgar This a general problem with development workflow: when nomad is ready to fire - there is already the whole bunch of settings for an application:
in docker compose
in .env files
exports for a shell
terraform outputs
and the list can go on and on

All that should be stored in consul, but nomad can't read yet from consul kv yet. Sometimes it won't be able to, when the job is triggered from managed CI server.
This creates quite a large gap in your definition of the application lifecycle: build, test, package, provision, secure and then suddenly deploy step is on its own.

Nomad should get a first class support of making deploy step as easy as possible.

Amazon provided an elegant solution for lambda for a very similar problem.
http://docs.aws.amazon.com/lambda/latest/dg/env_variables.html

[dadgar]

@rokka-n Reading from Consul would happen at the clients not on the machine that submits the job so the CI example wouldn't be a problem. Further we support adding environment variables natively: https://www.nomadproject.io/docs/job-specification/env.html.

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.