In my experience Vagrant over-promises and under-delivers. Granted, this was a few years ago.
First, there's the whole "VM" part. You are constantly reminded of the border between your machine and the VM: having to explicitly start/stop the VM, SSH into it, set up port forwarding, figure out a core count & RAM size which is large enough to be useful yet small enough to work on everyone's machine, having to set up rsync wrappers because the NFS host mount is unusably slow...
Second, it doesn't really deal well with change. When you're working in a team, you want everyone to have an identical environment. Vagrant is great for setting it up, but it doesn't really have a solution to changing it. Want to add a package? Nuke the VMs, start from scratch, and hope nobody runs into install issues.
Docker, especially with docker-compose, provides pretty much the same but better. It was a no-no when Vagrant first started due to poor Windows support, but I understand that WSL has significantly changed that. You'd have to pay me to go back to Vagrant.
> having to explicitly start/stop the VM, SSH into it, set up port forwarding, figure out a core count & RAM size which is large enough to be useful yet small enough to work on everyone's machine, having to set up rsync wrappers because the NFS host mount is unusably slow...
All this is still kind of true for Docker on any other platform than Linux. There’s still a VM behind the scenes, and you still have to configure and manage it.
However, I personally do avoid that — when I use Docker “on” macOS, I skip the hassle of actually running the Docker daemon locally, by instead having a little headless Linux mini-PC that exposes the Docker control socket over Tailscale to me, and configuring my local Docker client to connect to it. This not only gets `docker run` streaming to a local PTY, but even streams input files for `docker build` to the Docker daemon, entirely transparently. It’s really nice, as I never have to worry about whether Docker Desktop is running, has enough memory, is taking up my local disk space, etc.
Surely there’s a way to do something like this but for vagrant? A Vagrant “thin client” that runs all the VMs on an IaaS service or in-office hypervisor cluster?
> Vagrant is great for setting it up, but it doesn't really have a solution to changing it. Want to add a package? Nuke the VMs, start from scratch, and hope nobody runs into install issues.
Option 1 (centrally managed Vagrant VMs via MDM): Keep the VM’s rootfs volume separate from its /home + /var volume, and push updates to the rootfs volumes via MDM (ideally using a binary diff system like Courgette.)
Option 2: build a chroot under /opt with versions of everything you care about, using e.g. Nix. Then create an apt/RPM package that in turn uses chef/puppet/etc to update this chroot within the VMs. (This is basically what Gitlab does for their self-hosted installable.)
Still not as good as just pulling a new Docker image… but possible.
> First, there's the whole "VM" part. You are constantly reminded of the border between your machine and the VM: having to explicitly start/stop the VM, SSH into it, set up port forwarding, figure out a core count & RAM size which is large enough to be useful yet small enough to work on everyone's machine, having to set up rsync wrappers because the NFS host mount is unusably slow...
What are you talking about? I used to do all that you're mentioning in the Vagrantfile, via code. Granted, ruby code (which doesn't help), but still in code.
> Second, it doesn't really deal well with change. When you're working in a team, you want everyone to have an identical environment. Vagrant is great for setting it up, but it doesn't really have a solution to changing it. Want to add a package? Nuke the VMs, start from scratch, and hope nobody runs into install issues.
Uh, adding the vagrant file to the code repository, maybe? So that maybe you can decide if a package goes into the vm via a code review? Maybe using the provisioning methods, so that changes can both be reviewed and git-tracked.
Like, have you actually read the Vagrant's documentation ? Or are you one of those people that criticize stuff just because the getting started one-page tutorial doesn't solve 100% of their use-case ?
I've used Vagrant in a team in the past, and it feels like either you have no idea what you're talking about or you have used it only briefly without actually reading any documentation.
> Docker, especially with docker-compose, provides pretty much the same but better.
There are some things docker cannot do, and some things vagrant cannot do.
They're completely different pieces of technology that happen to be able to do similar things (and happen to be used for similar purposes).
First, there's the whole "VM" part. You are constantly reminded of the border between your machine and the VM: having to explicitly start/stop the VM, SSH into it, set up port forwarding, figure out a core count & RAM size which is large enough to be useful yet small enough to work on everyone's machine, having to set up rsync wrappers because the NFS host mount is unusably slow...
Second, it doesn't really deal well with change. When you're working in a team, you want everyone to have an identical environment. Vagrant is great for setting it up, but it doesn't really have a solution to changing it. Want to add a package? Nuke the VMs, start from scratch, and hope nobody runs into install issues.
Docker, especially with docker-compose, provides pretty much the same but better. It was a no-no when Vagrant first started due to poor Windows support, but I understand that WSL has significantly changed that. You'd have to pay me to go back to Vagrant.