[sd8dgf8ds8g8dsg]

Using docker can greatly improve your development situation. For example, you can use docker to define the full environment needed to run your web app, meaning you can have another dev running it with "docker run", and not needing to install any local dependencies, as everything (web server, node etc) is contained inside the docker container. This turns out also be useful for your future self, when you in 2 years from now are having troubles re-creating the environment needed for running your service.

Docker orchestrate can further improve your development situation, in which you can use it to define and test out multiple virtual servers on your laptop, such as the database, the file server and the web server.

[stephenr]

Quite honestly Vagrant will do all of that for development.

[mickeyp]

Yes, with the caveat that if you already use a hypervisor for your main dev environment then running another inside it with Vagrant's default VBox setup is likely to either be very slow or not work at all.

Docker will also layer and cache each command greatly speeding up the "build&test" cycle of writing and running Docker containers. With Vagrant you're re-running everything every time.

Furthermore, you can actually use Docker with Vagrant also nowadays.

[stephenr]

This sounds like a rare scenario, much more common these days I believe would be a non-Linux host, with a Linux "guest" server environment.

If you want to use Docker, you're then automatically using a hypervisor anyway.

> With Vagrant you're re-running everything every time.

Are you talking about the time to provision a non-created environment?

On a clean install, sure, that might take a while if your base-box doesn't have the dependencies you require - but most developers wouldn't often need to re-build their Vagrant environment for a project from scratch (i.e. vagrant destroy is not likely to be a common task). And that whole situation is moot if you use or build a more appropriate base box.

[mickeyp]

Is it that uncommon? Mac users using a hypervisor? Windows using running Linux in a Virtualbox? That's pretty common in corporate environments...

I am talking about rebuilding the Vagrant image every time you change it - as you are wont to do during the initial step of creating it. Sure, once it's written (by someone who has to spend a fair amount of elapsed time doing trial-and-error tweaks) then you don't have to re-cycle the image. On the other hand, that too can result in people using stale images over time as the configuration drifts.

[stephenr]

> Mac users using a hypervisor? Windows using running Linux in a Virtualbox?

Vagrant works natively on Macs and Windows, unlike Docker. There is zero reason to run it inside an already virtualised environment on those machines.

> I am talking about rebuilding the Vagrant image every time you change it

You know you don't need to destroy the vagrant environment to re-run the provisioning scripts, if something changes.. right?

> Sure, once it's written (by someone who has to spend a fair amount of elapsed time doing trial-and-error tweaks)

With the minor exception of a few Vagrant specific optimisations (a `vagrant` user with the predefined SSH key & passwordless sudo, for example) during base-box building, literally nothing in a Vagrant provisioning environment needs to be specific to Vagrant.

Also - if you're building base-boxes, it's probably worthwhile forking an existing project that targets your Distro/OS of choice and customising from there.

> On the other hand, that too can result in people using stale images over time as the configuration drifts.

Why? If it's a small change, just set the provisioner to `run: "always"` and it will run on every up. Assuming the changes (i.e. new/updated deps, or config files being copied) are small, it'll be almost instantaneous.

From everything you've said, I'm very curious how you use Vagrant (if at all). It isn't intended to be used like Docker, where you package up an entire image completely ready to use with 0 cycles needed to configure anything, and an update means a new image.

[sumedh]

Setting up containers is ridiculously fast compared to VMs.

[stephenr]

What do you mean by "setting up". Are you talking about the work to provision a working target environment (i.e. what the VM/Container runs) or are you talking about the literal time for the environment to start?

[viraptor]

Containers help with both. No full-system boot delay helps. Cached layers help. Not dealing with vm-specific kernel modules helps. Fast non-nfs volumes shared with the host help.

There are speed benefits for containers all over the place - both in time spent dealing with the environment and in actual execution.

[stephenr]

> No full-system boot delay helps

I just cold-booted a Vagrant VM, which is configured to check for new base-box versions (i.e. a network delay that can be disabled).

    time vagrant up
    ...
    real    0m39.698s
    user    0m11.989s
    sys     0m5.490s

If your argument about tooling is around performance and the "slow" one takes just 40 seconds to start, I think you need to clarify how often you expect to be starting this tool in a day.

> Cached layers help.

Helps what, exactly?

> Not dealing with vm-specific kernel modules helps.

I don't even know what you're talking about here. Do you mean you need to have a hypervisor kernel module? What exactly do you need to "deal with"?

> Fast non-nfs volumes shared with the host help.

I've never once used an NFS volume in a Vagrant guest. In case you weren't aware, Vagrant is not limited to using VirtualBox.

> There are speed benefits for containers all over the place - both in time spent dealing with the environment and in actual execution.

You haven't actually identify any environment issues you need to "deal with", just said "X helps".

[viraptor]

Some context then. The happy path startup cost (environment is already prepared) matters to devs who never deal with the environment itself. If you're dealing with frontend only - maybe that's you most of the time, and you only see the 40s maybe once a day.

But there are other costs. Someone deals with updates, with adding new functionality, with debugging issues. I spend most of my day recently waiting for puppet runs in vagrant/vbox. It's 10+ min for a full run. Then I make more changes - sometimes an incremental provision is enough, sometimes I need a full rebuild. On the other hand, if the environment was built with docker layers, I'd have much less waiting to do, because the caching of partial build/layer is integrated. Over a whole day, that's not insignificant time saving.

And sure, vagrant has multiple backend. I'm using vbox, and so does almost every developer using vagrant. It's the only free one. (Apart from the docker backend)