Why isn't he using the Alpine based Redis image when comparing final image sizes?<p>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.<p>Alpine is pretty awesome if your main goal is to shrink images without any effort[2].<p>[1] <a href="https://hub.docker.com/_/redis/" rel="nofollow">https://hub.docker.com/_/redis/</a><p>[2] <a href="http://nickjanetakis.com/blog/alpine-based-docker-images-make-a-difference-in-real-world-apps" rel="nofollow">http://nickjanetakis.com/blog/alpine-based-docker-images-mak...</a>
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 to isolate build system. It is nice that Nix addresses this.
If the goal is solely Docker images with a standard size in the 20-40MB range, this can be achieved without additional tooling. After switching our development and deployment flow to docker, my team quickly tired of the 200-400MB images that seemed to be accepted as commonplace. We started basing our containers on alpine (essentially, busybox with a package manager) or alpine derivatives, and dropped into that target size immediately. Spinning up 8-10 microservices locally for a full frontend development stack is a shockingly better experience when that involves a 200MB download rather than a 2GB one.<p>This is in no way a negative commentary on Nix; it looks like an interesting solution to a well-known problem.
Once <a href="https://github.com/NixOS/nixpkgs/pull/14711" rel="nofollow">https://github.com/NixOS/nixpkgs/pull/14711</a> is merged, the images might also be binary deterministic (depending on what packages you use).
@Lethalman: Can you expound on this?<p>> Be aware that things like PAM configurations, or other stuff, created to be suitable for Debian may not work with Nix programs that use a different glibc.<p>So this would not be a factor using the method which has no base? The Debian base approach seems like a non-starter if negative emergent behavior like PAM config mismatches are common.<p>Also, to be sure, I can do this "no base Docker build" using Nix on let's say CentOS 7? Meaning, I'm not required to use NixOS natively?<p>I plan to read the post closer later today, so feel free to ignore these questions if they are answered in-post, but I usually don't post to HN from work computer, so I thought I'd get my questions out here early in case the thread drops and I forget to ask. :-)<p>Nice work!
Haha, very good.<p>So Nix makes even the use of Docker better, while some Nix user here claimed that you don't even need Docker if you're using Nix(OS).
Installed emacs with nix last weekend to use with spacemacs. Three errors at startup that didn't make sense but I had a feeling that nix was the problem so rolled back and reinstalled with brew. Worked perfectly. Nix has some great ideas but when the install of emacs took 10 times as long as homebrew, then didn't work correctly it didn't leave me wanting to use it for anything work related like my docker images.<p>Hopefully with time, their planned cli improvements and binary caching it will be a contender but that feels a ways off at this point.
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?
Interesting. Not being that familiar with Nix(OS), how much of a moving target Nix is? Can you do these kinds of things with stable versions or do you need to keep up with HEAD?
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.
what docker build extensions would make it possible to do this without 'rolling your own' tarball docker layer? having access to volumes at build time?