Hacker News Reader

Comment by pulse7 | Hacker News Reader

Dockerfile = docker run + docker commit + MANY unneeded limitations

Please don't downvote parent. This is true.

It is a fact that everything that happens in a Dockerfile execution via `docker build` can be done with a `docker run` and executing commands and ending with `docker commit`. Even the caching mechanism can be replicated. (Except with more control in my opinion.) It is also a fact that `docker run` has more capabilities than `docker build`, such as being able to mount things in.

Thanks as an occasional docker user this wouldn’t have occurred to me.

Could you elaborate?

One example: With Dockerfile you almost can not create your own slim Docker image in an isolated environment (without internet connection) if you need to install some packages from a mounted volume where you have downloaded cached dependencies - because docker build does not allow you to temporarily mount the cached dependencies. With docker run + docker commit combination you can do that without limitations. Latest experimental BuildKit has the option to make a temporal mount, BUT it can not work without internet connection...

You can do that with a multi-stage build with the cached packages in your context, or you can spin up an http server with the files and ADD the URLs, or set an http proxy environment variable for apt in the container, or add your mirror to the image's apt repositories list. You could do all that with a docker compose file, too.

If you do it with multi-stage build (where you would copy cached packages in the intermediate stage and remove it after being done) and copy over the whole root (/) from intermediate to the final stage then docker will make a new layer with the completely the same content and your image size will double -> this is a no go.

And yes, you can spin up an http server and serve the cached packages and setup up all this before using docker build, but hey I can do it with docker run + docker commit much quicker... (I wrote "you almost can not create" and not "you can not create" - so it is possible with Dockerfile, but is not trivial.)

> and copy over the whole root (/)

Why on earth would anyone do that? That's simply wrong on so many levels, and is far from being standard practice.

> because docker build does not allow you to temporarily mount the cached dependencies.

Why do you believe this point is relevant? If you can mount a drive then you can access its contents on the host, and if you can access files on the host then those contents are also accessible in a Docker build.

You CAN NOT mount a drive with "docker build". You CAN however mount a drive with "docker run". So therefore: Dockerfile = docker run + docker commit + MANY unneeded limitations

> You CAN NOT mount a drive with "docker build".

No one said that. I stated the fact that you can access files from the host during a docker build, thus it's irrelevant if you can mount drives or not. Just copy the files into your build stage and that's it.

docker = bash script + unshare + MANY unneeded limitations

But the nicer packaging and simpler model make that new layer of abstraction useful.

Reply on news.ycombinator.com