? I'm looking to inject my set of vars at container start time, without fully relying on a populated
failed (111: Connection refused) while resolving, resolver: 127.0.0.11:53
I tried changing the resolver in the nginx conf and various other suggestions on SO but to no avail.
app1 could not be resolved (110: Operation timed out)
and an array out of bounds (in thread)
Provider lucee.runtime.script.LuceeScriptEngineFactory could not be instantiated
As opposed to just:
CMD export SOME_ENV_VAR=some_value
In our Dockerfile we're chaining that
with a call to start the actual process, eg:
But pretty sure that doesn't make any difference to anything. I guess the question is whether there's any difference in how an env variable gets set between
CMD export SOME_ENV_VAR=some_value && supervisord -c /etc/supervisor/supervisord.conf
from the shell.
the env var will only be available during the build process of the intermediate container that is created while building, it does not persist and will not be available when you run a container from that image. With
it will persist. See https://stackoverflow.com/questions/33379393/docker-env-vs-run-export
... the container ends up with the correct value being set. Just wondering if I'm missing some idiosyncrasy.
? since my container image build-time warmup needs to query the admin (with a temporary password) but then needs a different password at container run-time, i've had trouble getting it to pick up that runtime admin password. IIRC, once lucee does the
thing, it won't do it again.