This question already has answers here:
Use environment variables in CMD
(4 answers)
Closed 3 months ago.
I'm trying to use args in Dockerfile CMD. I know that we should use ENV in CMD so I've tried to do this but nothing happened in my case.
kvs is a bynary file built from Golang application.
My Dockerfile:
FROM alpine
ARG HOST
ENV HOST_NAME=$HOST
COPY kvs /
COPY *.crt /
COPY *.key /
EXPOSE 8080
CMD ["/kvs", "-host", $HOST_NAME]
I've tryied:
CMD ["/kvs", "-host", ${HOST_NAME}]
CMD ["/kvs", "-host", $HOST_NAME]
CMD ["/kvs", "-host", "${HOST_NAME}"]
CMD ["/kvs", "-host", "$HOST_NAME"]
CMD ["/kvs", "-host", "echo $HOST_NAME"]
CMD ["/kvs", "-host", "echo ${HOST_NAME}"]
Nothing from above is working!
Error is:
/bin/sh: [/kvs,: not found
Any ideas?
The answer is:
CMD /kvs -host=$HOST_NAME
Any other ways is not working. I hope that it will help someone.
This is not working:
CMD ["/kvs", "-host=$HOST_NAME"]
Related
I'm trying to start an app based on arg passed at build time
cmd:
docker build --build-arg profile=live . -t app
Dockerfile:
FROM openjdk:11.0.7-jre-slim-buster
WORKDIR /app
ARG JAR_FILE=target/*.jar
ARG profile
ENV profile ${profile:-dev}
EXPOSE 8080
COPY ${JAR_FILE} /app/app.jar
# ENTRYPOINT ["java", "-jar", "app.jar", "--spring.profiles.active=${profile}"] --- not working
RUN echo $profile <--- here I got the value
#CMD java -jar app.jar --spring.profiles.active=${profile} --- not working
#CMD java -jar app.jar --spring.profiles.active=$profile --- not working
CMD ["sh", "-c", "node server.js ${profile}"] --- not working
when I inspect the docker image I got
"Cmd": [
"sh",
"-c",
"node server.js ${profile}"
],
What i'm missing?
Thanks
update:
works with CMD java -jar app.jar --spring.profiles.active=$profile and the $profile will have the desired value at runtime
Environment replacement doesn't happen in CMD. Instead it happens in the shell running inside the container (in your case sh, though it's not clear why you've used the json/exec syntax to call a sh command).
Documentation on environment replacement is available from: https://docs.docker.com/engine/reference/builder/#environment-replacement
Try this Dockerfile: docker build --build-arg PROFILE=uat -t app .
FROM alpine
ARG PROFILE
ENV PROFILE ${PROFILE:-dev}
CMD ["ash", "-c", "while :; do echo $PROFILE; sleep 1; done"]
Run it and it prints uat every second: docker run -it --rm app
You didn't mention what exactly is the outcome when you said "not working". Presumed you got empty string or other unexpected value, the environment variable could be in used by the base image. Try another name for your environment variable, or use non-slim version of openjdk image.
i have question when i run docker command docker container is up but its shows on Command column below image.
i think it must be show in command column like this 'node /app/server.js'
docker container run -e TZ=Asia/Karachi -d -p 9135:9135 myapi:2.4
FROM node:10.16.0
WORKDIR /app
COPY package.json /app
ENV NODE_ENV=production
RUN npm install
COPY . /app
VOLUME ["/app/logs"]
CMD ["node", "/app/server.js"]
EXPOSE 9135
Container main process is entrypoint + command.
So, what you are getting is the first part of the process (i.e: the entrypoint).
Your expectation is right but the reason is the offical image has entrypoint and the CMD you are overiding in your Dockerfile is just an argument for the entrypoint that i.e CMD ["node", "/app/server.js"]
So, if you change your Dockerfile to
FROM node:alpine
WORKDIR /app
COPY . /app
entrypoint ["node", "/app/app.js"]
and then run docker ps
The CMD will be "node /app/app.js"
An example
I have a Dockerfile which starts with:
FROM puppet/puppetserver
When I look at the source container it is built from another:
FROM puppet/puppetserver-standalone:5.0.0
The second contains a CMD command:
ENTRYPOINT ["dumb-init", "/docker-entrypoint.sh"]
CMD ["foreground" ]
In my own container I end with:
COPY start.sh /
CMD /start.sh
The CMD run but with unexpected results:
puppetserver: '/bin/sh' is not a puppetserver command. See 'puppetserver --help'.
I know that I have bash availible because I'm using RUN commands.sh before CMD in the same Dockerfile.
How do CMD commands stack when inheriting from base images?
Is my CMD not run as a normal bash command and instead run in conjunction with the CMD of the base image?
You need to reset the ENTRYPOINT from the parent image
COPY start.sh /
ENTRYPOINT []
CMD /start.sh
See https://docs.docker.com/engine/reference/builder/#understand-how-cmd-and-entrypoint-interact
CMD should be used as a way of defining default arguments for an ENTRYPOINT command or for executing an ad-hoc command in a container.
and https://docs.docker.com/engine/reference/builder/#cmd
There can only be one CMD instruction in a Dockerfile. If you list more than one CMD then only the last CMD will take effect.
I'm trying to build a image using mysql 5.6 from here as a base image. I need to do some initialization before the database starts up, so I need to override the entrypoint:
# Stuff in my Dockerfile
...
COPY my-entrypoint.sh /usr/local/bin/
ENTRYPOINT ["my-entrypoint.sh"]
My entrypoint is fairly simple, too:
#!/bin/bash
echo "Running my-entrypoint.sh"
# My initialization stuff here
...
# Call mysql entrypoint
/usr/local/bin/docker-entrypoint.sh mysqld
This seems to work, but I'd rather not have to hard-code the mysql entrypoint in my script (or my Dockerfile). Is there a way to reference the overridden entrypoint in my Dockerfile, so that it is available to my entrypoint script? Something like this, perhaps?
COPY my-entrypoint.sh /usr/local/bin/
ENTRYPOINT ["my-entrypoint.sh", BASE_ENTRYPOINT, BASE_CMD]
It has to appear in somewhere in someway, otherwise you can't get such information.
Option 1: use an ENV for previous entrypoint in Dockerfile, and then refer to it in your own entrypoint.sh:
Dockerfile:
FROM alpine:3.3
ENV MYSQL_ENTRYPOINT "/usr/bin/mysql mysqld"
ADD entrypoint.sh /
ENTRYPOINT ["/entrypoint.sh"]
Entrypoint.sh:
#!/bin/sh
echo $MYSQL_ENTRYPOINT
Option 2: just pass previous entrypoint command as parameter to your entrypoint:
Dockerfile:
FROM alpine:3.3
ADD entrypoint.sh /
ENTRYPOINT ["/entrypoint.sh"]
CMD ["/usr/bin/mysql mysqld"]
Entrypoint.sh:
#!/bin/sh
echo $1
Personally I prefer option #1.
2 ways:
Just pass it in after you specify your image, everything after that becomes the CMD and appended to your ENTRYPOINT. So...
# Stuff in my Dockerfile
...
COPY my-entrypoint.sh /usr/local/bin/
ENTRYPOINT ["my-entrypoint.sh"]
Then docker run ... image <your-entrypoint-etc> then just have your custom entrypoint pick up the 1st arg to it and use that however you need.
Second way, just pass it as an environment variable at runtime.
docker run ... -e MYSQL_ENTRYPOINT=<something> ...
And in your entrypoint script refer to the env variable ... $MYSQL_ENTRYPOINT ...
Here's a simple Dockerfile
FROM centos:6.6
ENTRYPOINT ["/bin/bash", "-l", "-c"]
CMD ["echo", "foo"]
Unfortunately it doesn't work. Nothing is echo'd when you run the resulting container that's built.
If you comment out the ENTRYPOINT then it works. However, if you set the ENTRYPOINT to /bin/sh -c, then it fails again
FROM centos:6.6
ENTRYPOINT ["/bin/sh", "-c"]
CMD ["echo", "foo"]
I thought that was the default ENTRYPOINT for an container that didn't have one defined, why didn't that work?
Finally, this also works
FROM centos:6.6
ENTRYPOINT ["/bin/bash", "-l", "-c"]
CMD ["echo foo"]
Before I submit an issue, I wanted to see if I'm doing something obviously wrong?
I'm using rvm inside my container which sort of needs a login shell to work right.
Note that the default entry point/cmd for an official centos 6 image is:
no entrypoint
only CMD ["/bin/bash"]
If you are using the -c command, you need to pass one argument (which is the full command): "echo foo".
Not a series of arguments (CMD ["echo", "foo"]).
As stated in dockerfile CMD section:
If you use the shell form of the CMD, then the <command> will execute in /bin/sh -c:
FROM ubuntu
CMD echo "This is a test." | wc -
If you want to run your <command> without a shell then you must express the command as a JSON array and give the full path to the executable
Since echo is a built-in command in the bash and C shells, the shell form here is preferable.