Pulling environment variables at runtime?

[stuartpb]

I see the specification states that environment variables can be specified in container.json. Is there a way to have runc pass along inherited environment variables from the execution context (as is needed to associate services provided in the fashion of Heroku 12-Factor Apps)?

[wking]

On Fri, Aug 14, 2015 at 09:31:31AM -0700, Stuart P. Bentley wrote:

I see the specification states that environment variables can be
specified in container.json. Is there a way to have runc pass
along inherited environment variables from the execution context (as
is needed to associate services provided in the fashion of Heroku
12-Factor Apps)?

I'd recommend a pre-processing step that injects the current
environment variables (or a whitelisted subset of them) into the
config before launching runC.

[stuartpb]

Well, to my point from #202, not all use cases work in a way where it makes sense to hit the filesystem before launching a container. It'd really be better if there were some CLI arguments to runc that could replace specifying fields in the JSON, so the parts of the container that vary on each run can be provided at runtime, and only the parts of the container that remain static (if any) are stored in the JSON manifest file.

[wking]

On Fri, Aug 14, 2015 at 03:15:40PM -0700, Stuart P. Bentley wrote:

Well, to my point from #202, not all use cases work in a way where
it makes sense to hit the filesystem before launching a container.

Addressing #202 should handle the “I don't want to touch the
filesystem” issue, which seems to split off cleanly from this issue.

It'd really be better if there were some CLI arguments to runc that
could replace specifying fields in the JSON, so the parts of the
container that vary on each run can be provided at runtime, and only
the parts of the container that remain static (if any) are stored in
the JSON manifest file.

I think it would be simpler if the JSON-editing tool was completely
separate, and not built into runc. That lets us use an off-the-shelf
editor, and lets us avoid worrying about splitting the config into
static and dynamic sections. For example (assuming #202 was fixed),
using envsubst 1:

export REDIS_PORT='tcp://172.17.0.8:6379'

envsubst '${REDIS_PORT}' <config.json | runc /dev/stdin

or the less-restricted:

envsubst <config.json | runc /dev/stdin

would let you replace ‘${REDIS_PORT}’ in config.json with the
environment variable's value.

[stuartpb]

using envsubst

Actually, envsubst is a really bad solution for this kind of thing, most importantly because it has no escape character (making it impossible to have variables handled by further levels, such as a Bash command, in your template). I wrote a Perl one-liner here that is better suited to this kind of operation.

[wking]

On Fri, Aug 14, 2015 at 04:06:56PM -0700, Stuart P. Bentley wrote:

using envsubst

Actually, envsubst is a really bad solution for this kind of thing,
most importantly because it has no escape character. I wrote a Perl
one-liner here that is
better suited to this kind of operation.

You can use any tool you like to customize your config. A whitelisted
envsubst works for me. Folks who need an escape character can use
your Perl one-liner. Other folks can use jq, or write their own tool.
But we can all agree that runC doesn't have to care about it ;).

[stuartpb]

I'm not talking about having a complete generalized robust JSON editing facility like jq vendored into runc - I'm just talking about making the standard fields defineable by CLI arguments like --env or --command, which would be specific to the type of field being defined. (These definitions would override any existing fields in the JSON configuration, if present.)

While I appreciate the flexibility of taking a configuration in on STDIN, that's not a be-all end-all solution. It still requires a lot of tooling to construct the JSON, and to rewrite existing files' JSON - and it encourages leaky, slapdash solutions (like outputting literal strings without regard for escaping unsafe characters) instead of specifying the strings by the (relatively) safe and simple mechanism Unix has used for configuring run parameters for 40+ years.

[wking]

On Fri, Aug 14, 2015 at 04:18:43PM -0700, Stuart P. Bentley wrote:

I'm not talking about having a complete generalized robust JSON
editing facility like jq vendored
into runc - I'm just talking about making the standard fields
defineable by CLI arguments like --env or --command, which
would be specific to the type of field being defined. (These
definitions would override any existing fields in the JSON
configuration, if present.)

But then you have to figure out which subset of fields need these
arguments, and for each field lookup the semantics for the associated
option (e.g. I expect --command would override, but --env would
append?).

While I appreciate the flexibility of taking a configuration in on
STDIN, that's not a be-all end-all solution. It still requires a lot
of tooling to construct the JSON, and to rewrite existing files'
JSON - and it encourages leaky, slapdash solutions (like outputting
literal strings without regard for escaping unsafe characters)
instead of specifying the strings by the (relatively) safe and
simple mechanism Unix has had to accomplish this for 40+ years.

It allows you to setup leaky, slapdash solutions if you want, but also
lets you setup safe, polished solutions. Basically, it gets out of
the way and lets you do whatever you want. That could include
spinning off your --env and --command replacers into an external
script, if that UI is more convenient to you than something generic
like envsubst or jq. But I don't see why runC needs to care about
the UI for manipulating a config file, when it's so easy to split that
into an independent step.

[crosbymichael]

I can see the usecases for this but it is a very hard thing to solve. I would probably do what @wking suggested with a preprocess step to add these to the spec because we really cannot tell the correct env vars to pass down since the runc process will have things like HOME and PATH, do we overwrite those for the container? How do we know what env vars we should pass down and what ones that we should not?

[cyphar]

Since this issue hasn't had any activity in the past year, I'm closing it. Please feel free to re-open it.

As for the actual issue, the runtime-spec specifically defines environment variables so that runtimes don't need to have custom ways of passing environment variables. You could probably script something with jq or (as you mentioned) a script that execs the program you actually want to run -- after mutating the environment variables.

[ghost]

the oci runtime tools is the cli friendly way
OTOH containerpilot has builtin support with text/template template rendering