Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerfile CMD doesn't understand ENV variables #5509

Closed
mikea opened this Issue Apr 30, 2014 · 14 comments

Comments

Projects
None yet
@mikea
Copy link

mikea commented Apr 30, 2014

Similar to #1136.

I want to be able to say CMD [ "$CATALINA_HOME/bin/catalina.sh", "run"]

@sayden

This comment has been minimized.

Copy link

sayden commented May 1, 2014

Have you tried this way?

CMD [ "${CATALINA_HOME}/bin/catalina.sh", "run"]
@mikea

This comment has been minimized.

Copy link
Author

mikea commented May 2, 2014

Yes. It doesn't work: docker run -P -i -t tomcat gives me:

2014/04/30 17:52:12 exec: "${CATALINA_HOME}/bin/catalina.sh": stat ${CATALINA_HOME}/bin/catalina.sh: no such file or directory
@sayden

This comment has been minimized.

Copy link

sayden commented May 2, 2014

I can confirm this. Using a Dockerfile with this

ENV MY_HOME /opt
CMD ["echo", "$MY_HOME"]

And it doesn't work on the build of the image. However, it work when you enter through /bin/bash (docker run [image] /bin/bash) and type:

echo $MY_HOME

Will print:

/opt

I have also tried:

CMD ["echo", "${MY_HOME}"]
CMD ["echo", "MY_HOME"]
CMD ["echo $MY_HOME"]
CMD ["echo ${MY_HOME}"]

With no luck.

I'll keep trying to work around this issue

@tianon

This comment has been minimized.

Copy link
Member

tianon commented May 5, 2014

Try CMD echo ${MY_HOME} or CMD ["sh", "-c", "echo ${MY_HOME}"] and you should have more luck.

The explanation is that the shell is responsible for expanding environment variables, not Docker. When you use the JSON syntax, you're explicitly requesting that your command bypass the shell and be execed directly.

@sfitts

This comment has been minimized.

Copy link

sfitts commented Jun 5, 2014

Confirmed that the form CMD ["sh", "-c", "echo ${MY_HOME}"] works as expected. I'm assuming the other form will as well.

Might be nice to add a note about this to the documentation.

duglin added a commit to duglin/docker that referenced this issue Oct 2, 2014

Add note to docs about lack of shell processing in JSON form
Closes moby#5509

Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin added a commit to duglin/docker that referenced this issue Oct 2, 2014

Add note to docs about lack of shell processing in JSON form
Closes moby#5509

Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin added a commit to duglin/docker that referenced this issue Oct 3, 2014

Add note to docs about lack of shell processing in JSON form
Closes moby#5509

Signed-off-by: Doug Davis <dug@us.ibm.com>

sreinhardt pushed a commit to sreinhardt/Docker-TestingSuite that referenced this issue Oct 6, 2014

Spenser Reinhardt
mysqld - CMD doesnt like vars
According to (moby/moby#5509) cmd does not work with env vars unless entrypoint is calling shell. Due to dictionary usage instead of strings, we get raw mysqld_safe instead of /bin/sh -c ../mysqld_safe. Not a big deal, just needed to be accounted for.

nathanleclaire added a commit to nathanleclaire/docker that referenced this issue Oct 11, 2014

Add note to docs about lack of shell processing in JSON form
Closes moby#5509

Signed-off-by: Doug Davis <dug@us.ibm.com>

nathanleclaire added a commit to nathanleclaire/docker that referenced this issue Oct 12, 2014

Add note to docs about lack of shell processing in JSON form
Closes moby#5509

Signed-off-by: Doug Davis <dug@us.ibm.com>

nikolaynag added a commit to nikolaynag/docker that referenced this issue Feb 17, 2017

@andho

This comment has been minimized.

Copy link

andho commented Jul 18, 2017

And based on @sfitts logic, as CMD is passed to the ENTRYPOINT as an argument, the following is possible:

Dockerfile:

FROM ubuntu:16.04

env MY_HOME /opt
ADD start.sh /start.sh
ENTRYPOINT ["/start.sh"]
CMD ["echo", "${MY_HOME}"]

start.sh

#!/bin/bash

/bin/bash -l -c "$*"
@dejayc

This comment has been minimized.

Copy link

dejayc commented Sep 7, 2017

I'd like this issue to be reopened.

The "answer" as provided above is merely a workaround, punting the expansion of ENV variables to the shell. I can immediately think of several scenarios in which this workaround is insufficient.

EDIT: Please see issue #34772, which I just created as a correlation for ARG directives. The use cases I mention there have possible overlap with the issues with ENV.

@spanktar

This comment has been minimized.

Copy link

spanktar commented Oct 27, 2017

+1 to @dejayc

@ryanjaeb

This comment has been minimized.

Copy link

ryanjaeb commented Oct 27, 2017

I think this is a good example where shell expansion doesn't work. The container is built from scratch, so it has a single binary and no shell.

randomorder added a commit to geosolutions-it/docker-gs-base that referenced this issue Jan 10, 2018

randomorder added a commit to geosolutions-it/docker-gs-base that referenced this issue Jan 10, 2018

@abiosoft

This comment has been minimized.

Copy link

abiosoft commented Mar 27, 2018

In case this may be useful for anyone, I wrote a small Go script to achieve this. Wrapping with shell script works but does not forward OS signals to the process.

https://github.com/abiosoft/parent

@akravetz

This comment has been minimized.

Copy link

akravetz commented Jun 10, 2018

+1 many of us are using the ENTRYPOINT ["docker-entrypoint.sh"] CMD ["something", "${VARIABLE"] pattern where this fails. The last line of docker-entrypoint.sh is typically exec $@ which will not expand variables. The current proposed work-around does not handle OS signal forwarding gracefully.

@holms

This comment has been minimized.

Copy link

holms commented Jul 5, 2018

@akravetz I recall on DockerConf it was said multiple times avoid using docker-entrypoint.sh, they grow massively.

@akravetz

This comment has been minimized.

Copy link

akravetz commented Jul 5, 2018

@holms thank you, this is good info. Is there a place where best practices like that are documented for those of us who don't attend DockerConf? It's a bit confusing considering numerous high profile projects on docker hub (memcached, postgres, redis, etc) use the docker-entrypoint.sh pattern.

@holms

This comment has been minimized.

Copy link

holms commented Jul 9, 2018

@akravetz same for me actually :) Docs has some best practises: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

Also there's case studies: https://www.docker.com/products/resources/case-studies
Also success stories: https://success.docker.com
Also I'm reading a lot of Docker blog: https://blog.docker.com

Regarding entrypoint.sh I might be wrong but I clearly remember that some features appeared because of long entrypoint.sh, personally trying not to use them at all, because everything possible to do better most of the time, by using docker provided features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.