Hacker News new | ask | show | jobs
by duskwuff 1376 days ago
What turned me off from Vagrant was that Vagrant machines were never fully reproducible.

Docker took the approach of specifying images in terms of how to create them from scratch. Vagrant, on the other hand, took the approach of specifying certain details about a machine, then trying to apply changes to an existing machine to get it into the desired state. Since the Vagrantfile didn't (and couldn't) specify everything about that state, you'd inevitably end up with some drift as you applied changes to a machine over time -- a development team using Vagrant could often end up in situations where code behaved differently on two developers' machines because their respective Vagrant machines had gotten into different states.

It helped that Docker images can be used in production. Vagrant was only ever pitched as a solution for development; you'd be crazy to try to use it in production.

1 comments

Docker is not fully reproducible either. Try building a Docker image from two different machines and then pushing it to a registry. It will always overwrite.
Ooooh, “it will always overwrite.”: this is like saying an indirect way of saying that your executable will behave exactly the same if it got overwritten (by a same set of bytes).

Good one.

Dockerfiles pervasively use things like `apt-update` and that makes them not reproducible.

Even of your image pins apt or yum, images you depend on likely don't.

Docker is repeatable, not reproducible.

I’ve read bug threads in the moby GitHub where they reject a feature because it’s not repeatable, while people point out that Docker files start with apt-get so they aren’t repeatable from layer 2 anyway. The team members don’t seem to hear them and it’s frustrating to watch.

Images are repeatable. We like repeatable images. That’s enough for most of us. Don’t break that and we’re good. Just fix build time bullshit please.

Yep