Replace 'commit --run' with 'commit --change'#5105
Replace 'commit --run' with 'commit --change'#5105shykes wants to merge 7 commits intomoby:masterfrom
Conversation
|
This depends on #5102 |
|
Legit! 👍 Seems like a nice clean solution to the problem IMO, and it encourages the right things. I wonder if maybe in the future we could consider a |
|
code lgtm |
|
@tianon yes this is a small first step towards a unified "instruction set" across all docker commands which involve modifying a container or image. |
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <[email protected]> (github: shykes)
This allows using the Dockerfile syntax as a common "scripting" layer to express changes to an image configuration. Docker-DCO-1.1-Signed-off-by: Solomon Hykes <[email protected]> (github: shykes)
…string Docker-DCO-1.1-Signed-off-by: Solomon Hykes <[email protected]> (github: shykes)
Docker-DCO-1.1-Signed-off-by: Solomon Hykes <[email protected]> (github: shykes)
…ns (and print a warning) This makes pkg/dockerfile usable as the reference parser for 'docker build'. Docker-DCO-1.1-Signed-off-by: Solomon Hykes <[email protected]> (github: shykes)
… in the Dockerfile syntax This allows easy conversion of a Config object to and from the Dockerfile syntax. Docker-DCO-1.1-Signed-off-by: Solomon Hykes <[email protected]> (github: shykes)
```docker commit --change``` allows specifying standard changes to be applied to the new image. It deprecates the less user-friendly and less stable *commit --run*. Changes are expressed in the Dockerfile syntax, and can be used to modify the image metadata. For example: ```docker commit --change 'WORKDIR /home/bob'``` will commit the image with */home/bob* as the default working directory. ```docker commit --change 'EXPOSE 80 53/udp'``` will commit the image with network ports *80/tcp* and *53/udp* marked as exposed. ```docker commit --change 'VOLUME /var/data'``` will commit the image with */var/data* marked as a volume. The following Dockerfile instructions can be used as a change: * ENTRYPOINT * CMD * USER * WORKDIR * ENV * VOLUME * EXPOSE * ONBUILD The syntax for these commands is identical in *--change* and in a Dockerfile. See the Dockerfile reference for a complete syntax reference. Note that some fields which could be changed directly with the deprecated ```--run``` can no longer be changed with the new ```--change```. This is by design, for 2 reasons: 1) Not every field in the underlying Config object should be automatically exposed for modification. This gives us a stable indirection to control the exact set of allowed modifications. 2) If the Dockerfile syntax does not allow a legitimate modification, we can simply enrich the syntax, fixing the problem in a unified way both in Dockerfile and *docker commit*. Docker-DCO-1.1-Signed-off-by: Solomon Hykes <[email protected]> (github: shykes)
|
Rebased. Ping @creack @crosbymichael @vieux @unclejack |
|
@shykes This disable almost all output for |
|
master: 100% cached, "old" output. |
|
The current state of the docs is not great for users that want these capabilities. Info about Is this considered a minor feature? I've heard of a few build pipelines that require it (including my own), mostly applications with dependencies managed by something like Bundler / Maven / etc. |
Yes — we use a pipeline which injects code and runs build steps using something like: docker run --volume=…:/src image/name bash -c "cp -a /src /dst && cd /dst && make"
docker commit …Currently the run/commit would clobber the original CMD specified in the Dockerfile, so we have to In #4885 I proposed |
|
Here is a data point on how something like this would want to be used: https://github.com/progrium/docker-releasetag |
|
Not an uncommon pattern: https://github.com/deis/deis/blob/deis-build/controller/registry/docker.py#L7-L55 Though ideally it would be with images not a container, which is why I proposed it for |
|
@shykes can we revisit this from scratch after I get the new Dockerfile handler working? It seems like we're in serious conflict here. :) |
|
Since I want this functionality for docker import. I have patches for COMMENT, and ENV, not to mention a separate new command META, @erikh Is this something you have looked at since August? |
|
Hi Dan, Just a little. I have been very busy adding new features to Docker and the parser took a while to shake most of the bugs out. What I’d like to do is defer to solomon (Who is on vacation, so I’m trying to avoid pinging him) on these issues -- especially dockerfile commands -- because they require us to support them indefinitely. If these features absolutely cannot wait, I will discuss them with the team and hopefully we can work something out. Work for you? -Erik |
|
Sounds good to me. I am going to have one of my people work on converting my patches to use --change |
|
Please reopen when you have time to finish this PR and have it rebased. |
11 participants
docker commit --changeallows specifying standard changes to be applied to the new image. It deprecates the less user-friendly and less stable commit --run.Changes are expressed in the Dockerfile syntax, and can be used to modify the image metadata. For example:
docker commit --change 'WORKDIR /home/bob'will commit the image with /home/bob as the default working directory.docker commit --change 'EXPOSE 80 53/udp'will commit the image with network ports 80/tcp and 53/udp marked as exposed.docker commit --change 'VOLUME /var/data'will commit the image with /var/data marked as a volume.And so on.
The following Dockerfile instructions can be used as a change:
The syntax for these commands is identical in --change and in a
Dockerfile. See the Dockerfile reference for a complete syntax reference.
Note that some fields which could be changed directly with the deprecated
--runcan no longer be changed with the new--change. This is by design, for 2 reasons:Not every field in the underlying Config object should be automatically exposed for modification. This gives us a stable indirection to control the exact set of allowed modifications.
If the Dockerfile syntax does not allow a legitimate modification, we can simply enrich the syntax, fixing the problem in a unified way both in Dockerfile and docker commit.