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.

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.

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.

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.

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

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

> 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".

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)

Build your own base box with whatever prerequisites you have baked in. It's still a 10 minute puppet run if that's how long your provisioning takes, but that happens once, and then you distribute the box. While you can just use a base distro box, for large/complex setups it's not always the best approach.

Most of the Packer builders (e.g. virtualbox, parallels, VMware) support building from scratch (i.e. start with ISO install media and a blank VM disk) OR building from an existing VM.

So you could have a multi-stage Packer build pipeline that iterates step by step.

But I'm still not really sure what your workflow is. My company builds a series of Debian (and for a client, Ubuntu) base boxes. When debugging issues, 99% of time required is checking/fixing inside a running box. Once a solution is found, applying that back to the base box provisioning scripts (or preseed or even the packer config) and testing a build doesn't take that long.

What is the command/process to do that?

Personally I'd just put the call to `apt-get` and then `psql` into a shell script.

Either way, set the provisioner. Either do it in vagrant provisioning, or if that takes to long, build a base box with Packer and put the provisioner there.

Edit: or for a simpler use, look on Vagrantcloud.com and find a base box that has what you want, and run that.

  version: "2"
  services:
    database:
      image: postgres
      environment:
        - POSTGRES_PASSWORD=123456
      ports:
        - "5432:5432"

And restarting it takes < 1 second.

You're relying on an existing image. That concept works in Vagrant too.

And if you want quick startup and are already on a Linux host, use vagrant-lxc.

You dont need to mess with a config management tool when you have docker.

That's what you're relying on with a '1 line command' in docker to give you Postgres: an image that someone else has created.

Whether a Postgres-only box exists in Vagrantcloud is irrelevant, unless your argument is purely on the merits of the pre-made boxes/images third parties have contributed.

If your entire decision making process is "I only run things that take two seconds" then I don't think we can have a conversation because honestly I don't even think about the time vagrant takes to start.

My computer does multiple things all at once. It takes longer for my IDE to start and be usable than it does for Vagrant, and funnily enough computers can run multiple processes at once, so this whole "omg 30 seconds is too long to wait" argument doesn't fly for me.

Once you have a running Linux Kernel. I don't use a Linux host OS, so I would still have a delay starting a VM to run Linux, and running a Hypervisor to run containers for a dev environment is too many levels of abstraction for my liking.

> you might not appreciate the quick boot up time but lot of others care about that. If you are happy with slow boot up

Is Docker quicker? Sure. Does that make Vagrant slow? No. Slower does not mean slow.

> but if you want something quick and easy then consider docker.

I prefer things I actually have control over rather than just "quick and easy".

I rest my case, feel free to yell at kids to get off your lawn.

> Slower does not mean slow.

Whatever makes you happy. If you are happy with vagrant stick to it, nobody is forcing you to use something better.