Docker version 1.12.0, build 8eab29e (on RHEL 7.2)
My Dockerfile looks like this:
FROM centos:7
COPY ./configureservice.sh /tmp
RUN /tmp/configureservice.sh
ENTRYPOINT [ “/usr/sbin/init” ]
Inside, configureservice.sh, I am editing /etc/systemd/system.conf (and /etc/systemd/system.conf.d/system.conf) and setting certain environment variables (using DefaultEnvironment=VAR=value syntax). But these environments are not getting passed to /usr/sbin/init (process 1) although they are available for other processes (like journald). I also tried setting these in various other files in different formats but nothing works.
What am I missing ? How can I pass environment to /usr/sbin/init without using ENV option of Dockerfile or -e option of run command ?
…the docker run -e option and the Dockerfile ENV statement are the normal way to pass environment variables into your application. Why don’t you want to use them?
It is also typical to set up Docker images to run applications directly: instead of trying to run some sort of init system, end your Dockerfile with CMD ["/usr/local/bin/myapp"]. If you must run an init system, running a “do one thing well” process manager like supervisord will probably be much easier than trying to configure Docker to allow systemd to manage everything it wants to.
Finally, for debugging purposes, you almost always want to run your application as a CMD, not as an ENTRYPOINT.
In summary, I’d recommend a Dockerfile that looks like the following:
FROM centos:7
COPY ./configureservice.sh /tmp
RUN /tmp/configureservice.sh
ENV ???
CMD ["/usr/local/bin/myapp"]
Inside the Dockerfile, we run lot of scripts for setup, and we need to generate certain environment variables dynamically (through these scripts). That is why I was looking for a way to simply add those dynamically generated environment variables to any file (like system.conf) that init is expected to process for environment. Of course, I can try to work around by using multiple Docker files and generating at least one of the Dockerfile itself dynamically with the generated environment values in ENV option. But I was trying to avoid that.
Yes, I generally agree on your comments about myapp vs. init. However, I am attempting to make changes to an existing product and making changes at that level will involve lots of changes (which we may still do in future, but not in the short term).
Just to add…, I am reluctant to use --env or --env_file during ‘run’ as we didn’t want our end users to get env file from us or add too many extra options to add (and instead keep everything contained and handled within the container as much as possible).
That’s the idea so far. However, I am still at a loss why I am unable to update any file (or may be which file is the key) that gets processed by init to pass environment variables.