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

41–50 of 51 posts

Re: Cheap Docker images with Nix

#41

Post by mmerickel »

lisivka wrote: post #38
mmerickel wrote: post #35

Earlier quoted context omitted.

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.

That depends on a lot of factors. The advantage of an approach like this is that every package is built in a clean-room container independent of the host. For example my host is os x and I'm building binary tarballs to run on ubuntu. If you have a build server obviously this is less of an issue.

Re: Cheap Docker images with Nix

#43

Post by akbar501 »

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…

Our approach is to view Docker as part of our overall development process and then develop stage specific containers.

For example, we have development containers, build containers and runtime containers. Runtime containers are further segmented into product demo containers, testing containers and production containers.

I just published a new article on Docker this morning: http://www.dynomitedb.com/blog/2016/04/13/docker-containers/

An important point is that the build containers produce binaries that are used in both native package managers (ex. apt) and in Docker containers.

If you're interested in seeing this in action then checkout our source on GH: https://github.com/DynomiteDB

IMHO, a well designed approach to UnionFS layers is vital to high quality container architecture.

While we're focused on container use for databases (both in-memory and on-disk), much of our approach applies equally well to application layer containers.

Re: Cheap Docker images with Nix

#44

Post by _0w8t »

akbar501 wrote: post #43
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…

Our approach is to view Docker as part of our overall development process and then develop stage specific containers. For example, we have development containers, build containers and runtime containers. Runtime containers are further segmented into product demo containers, testing containers and production containers. I just published a new article on Docker this morning: http://www.dynomitedb.com/blog/2016/04/13/do…

Nice reference about https://www.projectcalico.org . At some point insanity of using ethernet on top of UDP to carry IP traffic between containers must stop.

Re: Cheap Docker images with Nix

#45

Post by bogomipz »

I really like the Nix package manager, however is there an upside to using Nix to build a Docker image over just writing a regular Dockerfile? Is this an odd use case? Maybe it just for demo purposes? Is there a benefit I'm overlooking?

Re: Cheap Docker images with Nix

#46

Post by bogomipz »

jasonjei wrote: post #25
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…

Straight from the horse's mouth--admire your product, Mr. Hykes! I love how you can run docker inside of a container. What I've done sometimes is run docker inside my build environment container. I use Docker Machine (OSX), so I just send the same machine environmental variables over to the container, but on Linux you could just link the socket file. In fact, I have a container just for Google Cloud that maintains my…

Could you elaborate on this process of deploying your container from inside docker via socket linking? I'm not sure I follow.

Re: Cheap Docker images with Nix

#47

Post by bogomipz »

fishnchips wrote: post #17

I'm wondering what would be the advantage of using Nix versus building on Alpine Linux with good understanding how Docker layers work. My main reason to be skeptical about Nix is the need to learn a new single-purpose language as opposed to just using Shell like you do in Dockerfiles.

This is the same thing I was asking. As much as I like the idea of declarative functional package manager what value does it provide if you are just building docker images?

Re: Cheap Docker images with Nix

#48

Post by cstrahan »

bogomipz wrote: post #47
fishnchips wrote: post #17

I'm wondering what would be the advantage of using Nix versus building on Alpine Linux with good understanding how Docker layers work. My main reason to be skeptical about Nix is the need to learn a new single-purpose language as opposed to just using Shell like you do in Dockerfiles.

This is the same thing I was asking. As much as I like the idea of declarative functional package manager what value does it provide if you are just building docker images?

Here's a copy of a comment I left on the post:

1. Better abstraction (e.g. the example of a function that produces docker images).

2. The Hydra build/CI server obviates the need for paying for (or administering a self hosted) docker registry, and avoids the imperative push and pull model. Because a docker image is just another Nix package, you get distributed building, caching and signing for free.

3. Because Nix caches intermediate packages builds, building a Docker image via Nix will likely be faster than letting Docker do it.

4. Determinism. With Docker, you're not guaranteed that you'll build the same image across two machines (imagine the state of package repositories changing -- it's trivial to find different versions of packages across two builds of the same Dockerfile). With Nix, you're guaranteed that you have the same determinism that any other Nix package has (e.g. everything builds in a chroot without network access (unless you provide a hash of the result, for e.g. tarball downloads))

Re: Cheap Docker images with Nix

#49

Post by cstrahan »

bogomipz wrote: post #45

I really like the Nix package manager, however is there an upside to using Nix to build a Docker image over just writing a regular Dockerfile? Is this an odd use case? Maybe it just for demo purposes? Is there a benefit I'm overlooking?

For reference, I left a comment further down:

https://news.ycombinator.com/item?id=11509065

Re: Cheap Docker images with Nix

#50

Post by yhodique »

Lethalman wrote: post #13
nickjj wrote: post #8

Why isn't he using the Alpine based Redis image when comparing final image sizes? It's unfair to say the official Redis image is 177mb because the Alpine version is available on the Docker Hub[1] and it's only 15.95mb. Alpine is pretty awesome if your main goal is to shrink images without any effort[2]. [1] https://hub.docker.com/_/redis/ [2] http://nickjanetakis.com/blog/alpine-based-docker-images-mak...

You are right. It's unfair, I'm going to modify the post to mention alpine. The post is both about tiny images AND how to build docker images with nix. I think it was an interesting tooling to make for our community. Some Nix people are already using it for obvious reasons.

I commented on the original post, but actually I believe the strength of the Nix-based approach is to provide package management capabilities outside of the target image. In other words, it makes the "scratch" image actually usable.

So now, if you take an Alpine-like approach to the problem (musl, no extra stuff) in Nix, you can get much smaller images. And the reason is you don't have to pay for the limitations of the Dockerfile-based approach.

As a proof of concept, here's an extension of the Nix recipe to produce a 1.2MB redis image: https://gist.github.com/sigma/9887c299da60955734f0fff6e2faee...

Now, the numbers start getting a little bit meaningless (although that's still an order of magnitude...), but the point is that regardless of how great Alpine is (and it is definitely great), as a base image for a Dockerfile it'll always contain way too much stuff compared to what's really needed for the application itself.

Post reply on HN