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.
Related
Suppose we have a Dockerfile with some CMD and we produced and image from it. Now suppose that we write a docker-compose and one of the services is built from that image.
What I want to do is running the same command but concatenating my own new parameters.
As an example, suppose the original CMD is
java -jar app.jar --argumentA=valA
I want the command to be
java -jar app.jar --argumentA=valA --argumentB=valB
Is it possible?
I'm not entirely sure if this is what you would want to accomplish, but...
Dockerfile exposes both ENTRYPOINT and CMD for being able to execute commands. These also can be used in conjunction, but in this case the ENTRYPOINT will be the command what we want to execute and the CMD will represent some default arguments for the ENTRYPOINT (docs).
For example:
FROM openjdk:11
COPY . /target/app.jar
ENTRYPOINT ["java", "-jar", "app.jar", "--argumentA=valA"]
CMD ["--argumentB=valB"]
The --argumentB=valB will be appended to the java -jar app.jar --argumentA=valA, if we run the image like this:
docker build -t app .
docker run app # # the command executed will be java -jar app.jar --argumentA=valA --argumentB=valB
But the CMD part will be overridden if we provide other arguments when we run the docker image:
docker build -t app .
docker run app --argumentA=valC # the command executed will be java -jar app.jar --argumentA=valA --argumentB=valC
Also, we can commit the CMD and have the ENTRYPOINT only, if we don't require some defaults to be appended to the ENTRYPOINT.
Using this command to start and run my docker container passing in argument ./target/myapp-SNAPSHOT.jar where ./target/myapp-SNAPSHOT.jar is the Spring boot app I wish to run :
docker build -t foo . && docker run -it foo -e J_FILE=./target/myapp-SNAPSHOT.jar
I receive error :
standard_init_linux.go:211: exec user process caused "exec format error"
Dockerfile:
FROM adoptopenjdk/openjdk8:alpine-jre
LABEL app.name="test"
LABEL app.type="test"
ARG J_FILE
ADD ${J_FILE} /myapp.jar
COPY J_FILE /myapp.jar
COPY startup.sh /
RUN chmod +x startup.sh;
ENTRYPOINT ["/startup.sh"]
EXPOSE 8080
startup.sh :
#!/bin/sh
JAVA_HEAP_INITIAL=384m
JAVA_HEAP_MAX=768m
JAVA_METASPACE_MAX=128m
java -jar /app.jar
If I change Dockerfile to explicitly copy the jar file :
FROM adoptopenjdk/openjdk8:alpine-jre
LABEL app.name="test"
LABEL app.type="test"
COPY ./target/myapp-SNAPSHOT.jar /myapp.jar
COPY startup.sh /
RUN chmod +x startup.sh;
ENTRYPOINT ["/startup.sh"]
EXPOSE 8080
The app starts as expected.
The ARG flag in Dockerfile is meant for configuration when building a docker image. It will not have any effect when you run the container.
Therefore, you should update your command to be like this:
docker build --build-arg J_FILE=./target/myapp-SNAPSHOT.jar -t foo . && docker run -it foo
You can also update your Dockerfile to be like this:
FROM adoptopenjdk/openjdk8:alpine-jre
LABEL app.name="test"
LABEL app.type="test"
ARG J_FILE=./target/myapp-SNAPSHOT.jar
COPY ${J_FILE} /myapp.jar
COPY startup.sh /
RUN chmod +x startup.sh;
ENTRYPOINT ["/startup.sh"]
EXPOSE 8080
Note 2 changes in the file above:
Use COPY instead of ADD
Set the default value for J_FILE as ./target/myapp-SNAPSHOT.jar in case the --build-arg is not passed with the docker build command.
There is no such file by name entrypoint.sh in my workspace.
But below instruction in docker-compose.yml is referring it:
builder:
build: ../../
dockerfile: docker/dev/Dockerfile
volumes:
- ../../target:/wheelhouse
volumes_from:
- cache
entrypoint: "entrypoint.sh"
command: ["pip", "wheel", "--non-index", "-f /build", "."]
where ../docker/dev/Dockerfile has
# Set defaults for entrypoint and command string
ENTRYPOINT ["test.sh"]
CMD ["python", "manage.py", "test", "--noinput"]
What does entrypoint: "entrypoint.sh" actually do?
entrypoint: "entrypoint.sh" overrides ENTRYPOINT ["test.sh"] from Dockerfile.
From the docs:
Setting entrypoint both overrides any default entrypoint set on the
service’s image with the ENTRYPOINT Dockerfile instruction, and clears
out any default command on the image - meaning that if there’s a CMD
instruction in the Dockerfile, it is ignored.
ENTRYPOINT ["test.sh"] is set in Dockerfile describing docker image
entrypoint: "entrypoint.sh" is set in docker-compose file which describes multicontainer environment while referencing the Dockerfile.
docker-compose build builder will build image and set entrypoint to ENTRYPOINT ["test.sh"] set in Dockerfile.
docker-compose up builder will start container with entrypoint entrypoint.sh pip wheel --no-index '-f /build' . set in docker-compose file
ENTRYPOINT is a command or script that is executed when you run the docker container.
If you specify entrypoint in the docker-compose.yaml, it overrides ENTRYPOINT from specified Dockerfile.
CMD is something that is passed as the parameters to the ENTRYPOINT
So if you just run the dev/Dockerfile, it would execute
test.sh python manage.py test --noinput
If you overrided CMD in docker-compose.yaml as you did, it would execute
test.sh pip wheel --non-index -f /build .
But because you also overrided ENTRYPOINT in your docker-compose.yaml, it is going to execute
entrypoint.sh pip wheel --non-index -f /build .
So basically, entrypoint.sh is a script that will run inside your container builder when you execute docker-compose up command.
Also you can check this answer for more info What is the difference between CMD and ENTRYPOINT in a Dockerfile?
Update:
If the base image has entrypoint.sh, it will run that, but if you override with your own entrypoint then the container will run the override entrypoint.
If you to override the default behaviour of base image then you can change, ohterwise you do not need to override it from docker-compose.
What does entrypoint: "entrypoint.sh" actually do?
It totally depend on the script or command inside entrypoint.sh, but few things can be considered.
ENTRYPOINT instruction allows you to configure a container that will
run as an executable. It looks similar to CMD, because it also allows
you to specify a command with parameters. The difference is ENTRYPOINT
command and parameters are not ignored when Docker container runs with
command line parameters. (There is a way to ignore ENTTRYPOINT, but it
is unlikely that you will do it.)
In simple word, entrypoint can be a complex bash script, for example in case of mysql entrypoint which is more then 200 LOC which does the following task.
start MySQL server
wait for MySQL server to up
Create DB
Can perform DB migration or DB initlization
So much complex task is not possible with CMD, as in CMD you can run the bash but it will be more headache to make it work. Also it make Dockerfile simple and put the complex task to entrypoint.
When there is entrypoint, anything that is passed to CMD will be consider as a argument for entrypoint.
In your case, CMD is CMD ["python", "manage.py", "test", "--noinput"] it will be passed as an argument and the best to run this is to use use
# set of command
#start long running process at the end that is passed from CMD
exec "$#"
Finally, the exec shell construct is invoked, so that the final
command given becomes the container's PID 1. $# is a shell variable
that means "all the arguments",
use-a-script-to-initialize-stateful-container-data
cmd-vs-entrypoint
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
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.