Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cheap Docker images with Nix

lethalman.blogspot.com

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Cheap Docker images with Nix

#31

Post by shykes »

zenlikethat wrote: post #29
xienze wrote: post #18

Earlier quoted context omitted.

Or you could remove the tools at the end of your Dockerfile... Edit: am I missing something? This is a legitimate solution to the problem. Install the tools, compile, and remove them. The parent is suggesting a very clumsy approach (build on the host and pass the binary to the container as it's being built).

There's also another workaround to the ones mentioned by other posters: You could install your compilers, do your build, and clean up all your build tools within just one shell script invoked by a RUN line in Dockerfile. It's not pretty but it works.

Yes that is a common workaround as well.

By the way: there is an open request for contributions to help improve this. The core Docker team very much wants to improve squashing in build, but it's a matter of time and resources.

If somebody cares enough to take the time to carry a design proposal then a patch, we would be happy to support that effort!

Re: Cheap Docker images with Nix

#32

Post by _0w8t »

xienze wrote: post #18
_0w8t wrote: post #14

A common problem with Docker is after running a compiler/preprocessor during an image build one ends up with the bulid tools inside the image. A workaround is to use a shell script that first gets the image with the compiler, run it and then pass the output to the Docker build. But this is non-standard and encourages running random scripts on the build host defeating the advantages of using Docker during development…

Or you could remove the tools at the end of your Dockerfile... Edit: am I missing something? This is a legitimate solution to the problem. Install the tools, compile, and remove them. The parent is suggesting a very clumsy approach (build on the host and pass the binary to the container as it's being built).

The idea is not to build anything on the host. Rather it is more like a staged build initiated through a shell script. First pull/build image with the compiler, then docker run it to compile the application and finally build the final image with the application.

Re: Cheap Docker images with Nix

#33

Post by xienze »

shykes wrote: post #21
xienze wrote: post #18

Earlier quoted context omitted.

Or you could remove the tools at the end of your Dockerfile... Edit: am I missing something? This is a legitimate solution to the problem. Install the tools, compile, and remove them. The parent is suggesting a very clumsy approach (build on the host and pass the binary to the container as it's being built).

(I didn't downvote you) Disclaimer: I work at Docker. Your approach is the logical one... But Docker currently has a limitation in how it handles removing files in a build. After each build step, the intermediary state is committed as a layer, just like a git commit. So removing files in a docker build is like removing files in git: they are still taking up space in the history. The long-term solution is to support i…

> But Docker currently has a limitation in how it handles removing files in a build. After each build step, the intermediary state is committed as a layer, just like a git commit. So removing files in a docker build is like removing files in git: they are still taking up space in the history.

That's true unless you do the "everything in a single RUN statement" trick that is very popular.

Re: Cheap Docker images with Nix

#34

Post by xienze »

mayank wrote: post #22
xienze wrote: post #18

Earlier quoted context omitted.

Or you could remove the tools at the end of your Dockerfile... Edit: am I missing something? This is a legitimate solution to the problem. Install the tools, compile, and remove them. The parent is suggesting a very clumsy approach (build on the host and pass the binary to the container as it's being built).

The layered fs that Docker uses is based on additive snapshots, so removing tools at the end will paradoxically increase your image size with a useless snapshot.

You can do everything within a single RUN statement to avoid that.

Re: Cheap Docker images with Nix

#35

Post by mmerickel »

_0w8t wrote: post #14

A common problem with Docker is after running a compiler/preprocessor during an image build one ends up with the bulid tools inside the image. A workaround is to use a shell script that first gets the image with the compiler, run it and then pass the output to the Docker build. But this is non-standard and encourages running random scripts on the build host defeating the advantages of using Docker during development…

The idea is actually to do something similar to a heroku buildpack where you have a container with build tools that generates binary assets. You then inject the built binary into a new image that has only runtime dependencies installed.

I've experimented (and use) a variant of this workflow myself built around my marina tool [1]. The basic idea is to define a file that uses a dev/builder image to build, then exports a tarball into a runner image.

[1] https://pypi.python.org/pypi/marina

Re: Cheap Docker images with Nix

#36

Post by mayank »

xienze wrote: post #34
mayank wrote: post #22

Earlier quoted context omitted.

The layered fs that Docker uses is based on additive snapshots, so removing tools at the end will paradoxically increase your image size with a useless snapshot.

You can do everything within a single RUN statement to avoid that.

Yes, but at the expense of readability, development speed, and incremental updates to images (where typically the dependencies layer changes slower than your target code).

Re: Cheap Docker images with Nix

#37

Post by lisivka »

shykes wrote: post #21
xienze wrote: post #18

Earlier quoted context omitted.

Or you could remove the tools at the end of your Dockerfile... Edit: am I missing something? This is a legitimate solution to the problem. Install the tools, compile, and remove them. The parent is suggesting a very clumsy approach (build on the host and pass the binary to the container as it's being built).

(I didn't downvote you) Disclaimer: I work at Docker. Your approach is the logical one... But Docker currently has a limitation in how it handles removing files in a build. After each build step, the intermediary state is committed as a layer, just like a git commit. So removing files in a docker build is like removing files in git: they are still taking up space in the history. The long-term solution is to support i…

Proper solution is to build packages first using build environment, then install built binary packages in container, like any other package.

Re: Cheap Docker images with Nix

#38

Post by lisivka »

mmerickel wrote: post #35
_0w8t wrote: post #14

A common problem with Docker is after running a compiler/preprocessor during an image build one ends up with the bulid tools inside the image. A workaround is to use a shell script that first gets the image with the compiler, run it and then pass the output to the Docker build. But this is non-standard and encourages running random scripts on the build host defeating the advantages of using Docker during development…

The idea is actually to do something similar to a heroku buildpack where you have a container with build tools that generates binary assets. You then inject the built binary into a new image that has only runtime dependencies installed. I've experimented (and use) a variant of this workflow myself built around my marina tool [1]. The basic idea is to define a file that uses a dev/builder image to build, then exports…

It is much easier to just use standard package format (rpm/deb/apk/etc.) and standard installer (yum/dnf/apt/apk/etc.). Of course, you can invent your own build and installation system, it will work too.

Re: Cheap Docker images with Nix

#39

Post by stevvooe »

_0w8t wrote: post #14

A common problem with Docker is after running a compiler/preprocessor during an image build one ends up with the bulid tools inside the image. A workaround is to use a shell script that first gets the image with the compiler, run it and then pass the output to the Docker build. But this is non-standard and encourages running random scripts on the build host defeating the advantages of using Docker during development…

Nix has been a very cool project to watch over the years.

You can address part of the problem of picking up extra data in final images by declaring temporary build locations, such as `/var/lib/cache`, as a volume. Anything written to a volume won't be included in the final image.

Re: Cheap Docker images with Nix

#40

Post by fapjacks »

xienze wrote: post #33
shykes wrote: post #21

Earlier quoted context omitted.

(I didn't downvote you) Disclaimer: I work at Docker. Your approach is the logical one... But Docker currently has a limitation in how it handles removing files in a build. After each build step, the intermediary state is committed as a layer, just like a git commit. So removing files in a docker build is like removing files in git: they are still taking up space in the history. The long-term solution is to support i…

> But Docker currently has a limitation in how it handles removing files in a build. After each build step, the intermediary state is committed as a layer, just like a git commit. So removing files in a docker build is like removing files in git: they are still taking up space in the history. That's true unless you do the "everything in a single RUN statement" trick that is very popular.

"Very popular" for the one case of installing things via package manager.
Post reply on HN