@pda In your Problem I think that is totally valid. If you want to override the command on your run you can. This is how CMD has worked forever.

As a side note, that's how RUN works - RUN doesn't overwrite CMD.

@pda why are you passing a CMD on docker run when you don't want it?

Argh, I accidentally deleted my comment. You probably got it via email. Feel free to paste it as a quote, I've lost it completely.

I was going to add:

This is how CMD has worked forever.

Worth noting this change would only effect a behavior that is brand new in Docker 0.9.1.

Here's an example of a docker run that specified a one-off command which I don't want to land in a subsequent image. It's part of a build pipeline that injects the current codebase and runs necessary build tasks.

# Copy and build codebase.
docker run \
  --cidfile=$CID_FILE \
  --volume $(pwd):/codebase-volume \
  --env MAKE_PROFILE=1 \
  $BASE_IMAGE \
  bash -c "mkdir -p /codebase && cd /codebase && \
    git clone /codebase-volume/.git . && \
    rm -r .git && \
    make setup-toolchain build"

docker commit $(cat $CID_FILE) $BUILD_IMAGE

@pda why would you commit that if you don't want the results? Just trying to understand how you are using it.

We absolutely want the resulting container/image filesystem that came from that docker run. It's introduced the built codebase into the base image which didn't have it before.

What we don't want is for that one-off command to become part of the image metadata / config.

To outline the build pipeline:

• Dockerfile builds a developer-friendly image, no codebase, ready for it to be volume-mounted in.
• Build/release pipeline takes that image, adds the codebase, runs make, commits the result as a "build image".
• That "build image" should retain the CMD from the original Dockerfile. But it needed that one-off command run against it.

As a side note, that's how RUN works - RUN doesn't overwrite CMD. — @tianon

Interesting… so Dockerfile RUN <one-off command> does not overwrite config.Cmd but docker run $image <one-off command> does. It'd be nice if they matched, and I think the former is correct.

So this could be addressed as per this PR, or by changing how docker run works. The latter sounds nice, but would probably be a breaking change? The former (this PR) only changes behavior introduced in the current Docker 0.9.1.

+1, I thought the image's CMD would be remembered after docker run and docker commit and was surprised that it wasn't and had to google for a while to understand what was happening.

@crosbymichael Re why would I commit when I don't want the results: I'm new to Docker, but thus far I've sometimes run /bin/bash and modified my dev container, e.g. logged into PostgreSQL and configured it, and since I want to keep the changes, I commit. But I don't want to change the CMD command, only keep the changes I made in the container.

ping @vieux I believe this as been discussed in another issue. Should we close?

I'm pretty sure it's not relevent anymore. We changed the way we merged the config.

Please say something if I'm wrong

@vieux It looks like this issue is still present in 1.4.1. Here is an example of CMD getting clobbered:

With this base Dockerfile

From busybox

RUN echo "foo" > /foo

CMD cat /foo

I do:

$ docker build .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon 
Step 0 : FROM busybox
 ---> 4986bf8c1536
Step 1 : RUN echo "foo" > /foo
 ---> Running in 7b566904f416
 ---> 76d9809edb1c
Removing intermediate container 7b566904f416
Step 2 : CMD cat /foo
 ---> Running in b61d93f8359a
 ---> 492f5228fd2e
Removing intermediate container b61d93f8359a
Successfully built 492f5228fd2e

$ docker run 492f5228fd2e
foo

Now I want to modify the file system by running some commands (real example could be updating source, building assets, changing config)

$ docker run 492f5228fd2e sh -c 'echo "bar" > /foo'
$ docker ps -a | head
CONTAINER ID        IMAGE                                       COMMAND                CREATED              STATUS                      PORTS                      NAMES
01591b73f3c5        492f5228fd2e                                "\"sh -c 'echo \"bar   17 seconds ago       Exited (0) 16 seconds ago                              elated_galileo             
05d5273d2bc2        492f5228fd2e                                "/bin/sh -c 'cat /fo   About a minute ago   Exited (0) 59 seconds ago                              goofy_pasteur4             

$ docker commit 01591b73f3c5 
c266702eca21aadec2b2a58677be416cb4bb766eaae53515ab6f643b157a9f28

$ docker run c266702eca21aadec2b2a58677be416cb4bb766eaae53515ab6f643b157a9f28

# WHAAAT??

$ docker inspect --format '{{js .Config.Cmd}}' c266702eca21aadec2b2a58677be416cb4bb766eaae53515ab6f643b157a9f28
[sh -c echo \"bar\" \x3E /foo]

I would have expected the output of that last run to be bar, but as you can see the CMD of the new container is echo.

Yes, this makes docker somewhat useless for a fairly simple build process.

It seemed easy enough: Build a base image. Run a command in a container to update the sources. Commit that container to a deployable image, and push it to your repository as the latest version of the production container.

Only - when you commit, you get the command that was passed in as part of your build process, not the command in the base image that was missing sources.

Example:

# Dockerfile
FROM nginx

ADD ./nginx/nginx.conf /etc/nginx/
ADD ./nginx/sites-enabled /etc/nginx/sites-enabled/     

#build-script
... setting variables... 
container_name="build-$RANDOM-"`date +%s`
docker run --name $container_name -v $built_sources_dir:/mnt/app $base_runtime_image mkdir -p /app && cp -R /mnt/app/* /app

docker commit $container_name $built_image_name

docker rm -f $container_name

When I run the image with $built_image_name, it runs "mkdir -p /app" and exits.

It doesn't really make sense to create a new Dockerfile with an ADD statement here, since I want to be able to build images from multiple base images (i.e. staging/server, stable/server, etc) and have the rest of the process be the same - so we can test out upgrades before pushing to our production images.