Toward Vagrant 3.0

I've used both extensively. At least in my case, my uses are slightly different:

* Docker is nice for consistent development and deployment environments, particularly when I'm on a macOS host and I'm doing userspace programming.

* Vagrant is nice for creating a completely hermetic development environment, both on macOS and Linux hosts. My particular use case has been kernelspace programming: it's nice to not have to worry about accidentally taking my host down. Docker can't provide that kind of isolation, since it's still running on the host (or host VM) kernel at the end of the day.

The way I see it, Vagrant does for VMs what Docker does for containers: provides a way to build, deploy, manage, and teardown VMs consistently and without much manual effort. For example, I used Vagrant when learning to use Kubernetes, because I could quickly spin up a 3 node cluster on my laptop and destroy it if I messed up.

If you can use containers for local dev, great, but not everyone can or wants to migrate to containers. Vagrant still solves a very important use case.

A VM can still use systemd as init rather than an entrypoint script, so if you're developing systemd units, you need a VM. There is also the issue of running your application in a container in the first place. Docker in Docker is possible, but cumbersome. Redhat has certainly made it easier with Podman, but Docker still dominates developer mindshare. It's also quite a bit easier to persist changes in a VM, so rather than rearchitecting the OS or toolchain secrets management, user-specific configuration in a VM can just be done by the user after first launch and it sticks around. Simpler to do that than providing instructions and capability to mount git credentials store and gpg trust dbs into a container, then worrying about making sure you have the same UID in the container and out of it, so you don't mess up permissions.

Containers are largely just not a great medium for interactive work, i.e. development. They're great for resident applications that use a single process run via a service account.

I used to run Vagrant for python development back in 2015 it "worked" but was extremally slow and would break at least once a month. Not to mention Ubuntu suddenly removing the Vagrant user breaking more things. How much was VirtualBox or Vagrant fault, I'm not sure but it wasn't a happy experience. It took like an hour minimum to even setup an environment and everyone dreaded the day when they need to recreate their machine.

Once WSL came into being we moved everything to docker containers and never looked back.

Docker is much faster than Vagrant and allows reproducible envs.

I've been using VS Code + its Remote-Containers extension + docker-compose (when needed) and it's absolutely brilliant compared to other options.

I will use Vagrant when I want to avoid Docker in Docker, but I try to stay away from it as much as I can (for local app development).

That said Vagrant is really useful for testing infra, stuff like clusters etc.

The VMWare plugin for Vagrant is now OSS and free as well.

I used Vagrant extensively when I managed infrastructure at a company that was almost entirely private cloud based. I would create Linux VMs in Vagrant to test our infrastructure automation. The automation would then be deployed into VMware to create the platform used by the developers.

I've found Vagrant very useful to test (or develop) GUI-based applications, especially on platforms which Docker cannot run as container, such as macOS. I've also collected further thoughts on when to choose which (and how they can be combined) here: https://www.augmentedmind.de/2020/08/02/vagrant-vs-docker/

Conversely, that's only when technology starts to become interesting to me. When it's lived long enough to be useful, and hasn't fallen out of favor for something else. Thank you for building such an excellent tool.

I want other people to prove those things for me. I want to spend as little time and effort possible acquiring scars and would rather learn from others.

Good technology lasts.

Thanks for all the tools. You guys have well-deserved success.

Are there plans to somehow harmonize the concepts here with packer (and whatever the new packer cloud will be?). Vagrant for the most part feels like a vm-only version of packer (even though Vagrant came first).

I can easily see a self-hosted cloud-based "one-click dev machine" paired with VS Code Remote, provisioned by packer (or vagrant), with the configs stored in git. We'd love to roll out something like that for our devs so sensitive data then never leaves our sandbox or even gets into the dev laptops.

Not really any questions (other than my one in the comment thread about the best way forward for providers on Apple Silicon), but definitely a hat tip in your direction. I’ve had a good 8 years of plain sailing out of Vagrant and I appreciate the work you’ve done.

Glad to hear there is still development on this project. I've been using Vagrant a lot in the past, with great pleasure, but since most of the projects I manage nowadays are containers, I sadly have less and less use for this tool.

For the few projects that don't use containers however is still shines. One feature I'm missing though, which would make Vagrant a complete solution for me, is testing as a first class citizen. I've been using Test Kitchen[0] for this in this past which works well as a solution, but it would be really nice to have something like this built into and supported conceptually by Vagrant itself.

[0] https://docs.chef.io/workstation/kitchen/

I like Vagrant, but I don't know how I'm going to keep using it when I switch to Apple Silicon (M1 Macs). Vagrant wraps around Oracle VirtualBox; VirtualBox doesn't support M1 Macs, and Oracle has given no indication that they plan to start supporting Apple Silicon at all.

Is there any working version of Vagrant that "just works" on M1 out of the box without paying for a VM provider?

If not, would I have to pay for VMWare and then use Vagrant to wrap that? Would I use Vagrant to wrap Docker? (Why would I bother to use Vagrant if I'm using Docker?)

Hi Mitchell, what would it take to build an official firecracker plugin for Vagrant? Would there be any interest?

Thanks for Vagrant. I've used it quite a bit. I think it's underestimated how many large businesses there are that still manage their servers like "pets", rather than "cattle".

In my career, Vagrant has provided a good solution to move towards more automated deployment, where Docker would have been too big a paradigm shift, and/or not really greatly justify its use.

I love Vagrant, it was my secret weapon for years! However, I question the decision to release a complete new implementation under the 2.x version. The Go-based variant should be 3.0 from the start.

>why are we rewriting Vagrant in Go?

From [1] I dont think Ruby would ever be able to compete in that space. Even Hashicorp, the company that was born out of vagrant left Ruby and Chose Go. I am thinking someday Crystal post 1.0 would be able to put up a fight in that space.

I still remember I wrote somewhere, that one day Vagrant will be rewritten from Ruby to Go and got some very negative feedback from someone. ( It was in the Parker era.... )

Vagrant, and the whole HashiCorp products are all infrastructure product it makes sense to be running on Go rather than Ruby.

Nothing to say or ask really. But Thank You and congratulation. At some point I thought you have abandoned Vagrant. Its nice to see Hashicorp continue to update and take care of their first product. And honestly all the HashiCorp product are so much better or simpler than their competitors ( cough K8s cough ). Really wish you and your company continue to move forward with great products and services.

[1] https://news.ycombinator.com/item?id=23457496

Mitch, thanks for vagrant. I use it daily. I like long running processes. And nothing yet, gives me the simple configuration that I can get with Vagrant. And with Vagrant switching to Go, I can only bet performance will get better. For some of us, docker is pure overhead.

Client server architecture sounds like a good move forward.

It'd potentially open up having remote stuff be hosted in HashiCorp Cloud (HashiCloud?) directly. ;)

That could be pretty lucrative over time...

I really like Vagrant. However, it is extremely(!) slow, and every command takes 3-30 seconds (including commands that should take 50 ms). You also know about this, and chose not to act on it :( [0]. Would the transition to Go remove this impediment?

[0] https://github.com/hashicorp/vagrant/issues/11853

This is exactly what we do. It is like having a locally run staging environment, and is really great. Can exactly test things like http server configuration, cron jobs, multiple nodes (vagrant vms) coordinating with each other, etc.

been using https://www.parallels.com/ with https://kb.parallels.com/en/122843

Not everyone is building Javascript websites... ehm... I mean Apps

Docker isn't virtualization, and AFAIK has never really made any moves in that direction outside of small, local dev (eg running a local VM on a non-Linux host to get a local dockerd-on-Linux available).