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

Will Nix Overtake Docker?

blog.replit.com

Post reply on HN
Print view View original

31–40 of 259 posts

Re: Will Nix Overtake Docker?

#31

Post by taeric »

exdsq wrote: post #29

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get…

Funny, because I feel that simple tasks that would take minutes in my machine are now a dev adventure with docker.

And I mean funny. I suspect it is different mindsets. And I personally like that both seem to be thriving.

Re: Will Nix Overtake Docker?

#32

Post by Volundr »

throwaway9870 wrote: post #25
lilyball wrote: post #19

Earlier quoted context omitted.

Probably because of non-deterministic builds. Especially if the dependency pulls info from the network at build time.

I guess that would not fit my definition of "fully". Do people really build images this way? It sounds completely insane to pull packages like that randomly from the Internet.

Both my professional experience, and public examples would seem to suggest that's the norm. Example, here's the official postgres Dockerfile: https://github.com/docker-library/postgres/blob/3bb48045b4dc....

Do you work in an environment that maintains custom copies of every dependency in company managed repos? If so, my experience suggests your the outlier, not the people running apt, npm, etc inside their Dockerfiles.

Re: Will Nix Overtake Docker?

#33

Post by lvass »

exdsq wrote: post #29

Oh god I hope not. Having worked in > 100kloc nix environments I am completely turned off of the idea. I really really tried, I installed NixOS as my main OS and used Nix whenever I could to try and pick it up, but it's such a complex beast I felt it slowed everything down. Simple tasks that would take 10 minutes in Docker suddenly became DevOps tickets. I suddenly had to write bindings for tools rather than apt-get…

I've always kept my usage of Nix language to a minimum and found it to be a joy every time. But it's no wonder you'd have trouble on something that humongous. Why did it get so large?

Re: Will Nix Overtake Docker?

#34

Post by dreyfan »

What's the easiest way to deploy a docker container to a VM? Preferably without ten layers of cloud provider interconnected services or expensive and complex kubernetes layers? I just want to send a container and get back an IP address I can send some traffic to the exposed port(s).

Re: Will Nix Overtake Docker?

#35

Post by throwaway9870 »

cbrewster wrote: post #28
throwaway9870 wrote: post #15

> If you run docker build twice with the same Dockerfile you might get 2 images that behave in different ways. For example, a third-party package could silently be updated and cause breakage. Aggressively pinning dependency versions helps, but doesn't completely prevent this issue. If "aggressive" means fully, then why doesn't that fix the issue?

Author here. In our case, we had a large base Docker image called Polygott ( https://github.com/replit/polygott ) it pulls in dependencies for 50+ different languages from various repositories. We would pin things where possible, but its still very difficult to ensure reproducible builds. Additionally, docker builds have free access to the network to do anything it would like. Nix goes to great lengths to sandbox bui…

That makes sense. I think the real issue isn't Docker vs Nix, it is that some package managers are almost impossible to use to build reproducible images. I worked with debootstrap 10+ years ago trying to script reproducible builds and found it exceeding hard. Gentoo made it almost trivial (Google used it for ChromeOS so perhaps they felt similar). I will look into Nix.

It appears that with the proper package manager support, Docker would be fine?

I come from a hardware background and seem to be a lot more paranoid than most software folks. I would struggle to trust a build where so much is not pinned.

Re: Will Nix Overtake Docker?

#36

Post by oddlama »

zamadatix wrote: post #27

Somewhat not related and likely dumb question but I figure folks looking at this article can help steer me in the right direction: if I want containers to act like Linux VMs what's the best option? Like Docker minus the assumption that I only want a few specific directories to persist or the idea I'm interested in layering containers in a way that lets me reproduce building them. Like if I just want another separate…

You might want to have a look at systemd-nspawn [1], which is basically containerized chroot based on linux namespaces.

[1] https://www.freedesktop.org/software/systemd/man/systemd-nsp...

Re: Will Nix Overtake Docker?

#37

Post by throwaway9870 »

Volundr wrote: post #30
throwaway9870 wrote: post #23

Earlier quoted context omitted.

I can't imagine using a package system for building images that doesn't allow a full local cache of exactly the packages I want installed.

I mean sure, you can absolutely retain your own docker repository, your own NPM repository, etc and then configure them in your Dockerfile before installing packages. Pretty much every technical problem has a technical solution, but it's more effort that "just" fully pinning your versions.

If there are too many packages to pin, then I assume there are too many package to audit changes in for each image build you do? If that is true, how do you have any confidence that the image is going to function correct?

Re: Will Nix Overtake Docker?

#38

Post by xyzzy_plugh »

xxpor wrote: post #20
awinter-py wrote: post #11

IMO initial value of docker for local development is enabling me to run two copies of postgres without them shitting on each other. I get that nix is supposed to be hermetic, but does it enable two of something? nix being really good at package management is something docker needs to imitate -- out of order apt-get without requiring a re-downloading all the packages, for example, seems like it would shrink most cloud…

Nix supports this quite well. https://nixos.org/manual/nix/stable/#multiple-versions The Nix and container mindset are very similar in that they refer to all of their dependencies, including down to glibc.

Not quite. This is true for dependencies such as libraries but for services it's significantly trickier.

Postgres, for example, would require configuring each version to use a distinct space for storage and configuration if you want to run them concurrently. It's still pretty easy with NixOS, but not as simple as you make it seem.

Re: Will Nix Overtake Docker?

#39

Post by umvi »

dreyfan wrote: post #34

What's the easiest way to deploy a docker container to a VM? Preferably without ten layers of cloud provider interconnected services or expensive and complex kubernetes layers? I just want to send a container and get back an IP address I can send some traffic to the exposed port(s).

Docker save the container image to a zip file, ftp it over to the VM, then docker load it?

Re: Will Nix Overtake Docker?

#40

Post by throwaway9870 »

Volundr wrote: post #32
throwaway9870 wrote: post #25

Earlier quoted context omitted.

I guess that would not fit my definition of "fully". Do people really build images this way? It sounds completely insane to pull packages like that randomly from the Internet.

Both my professional experience, and public examples would seem to suggest that's the norm. Example, here's the official postgres Dockerfile: https://github.com/docker-library/postgres/blob/3bb48045b4dc... . Do you work in an environment that maintains custom copies of every dependency in company managed repos? If so, my experience suggests your the outlier, not the people running apt, npm, etc inside their Dockerfil…

Not custom copies, but a locked down cache of packages. For Gentoo you can do this by locking the portage tree you use and keeping a copy of the distfiles from the first run, for Python it was a requirements.txt file with a cache of the tar files from PyPi, for go it was including 3rd party code in repo. I don't know what the team did for npm.

It was really nice doing a full image rebuild and knowing the only thing that changed it was you explicitly changed.

Post reply on HN