Live data from Hacker News

Vagrant 2.0

hashicorp.com

61–70 of 120 posts

Re: Vagrant 2.0

#61
post #6

In the change log, I’m happy to see “improved the resilience of some Virtualbox commands.” At Airbnb, we used to use Vagrant with Virtualbox and the Chef provisioner to create our dev environments, but we migrated totally away from Vagrant after struggling with Virtualbox bugs, and strangeness with Vagrant’s internal state and locking. Seems like this issue is finally addressed: https://github.com/mitchellh/vagrant/i…

Vagrant's really falls short of its promise of "the exact same dev environment for everyone" in my experience, especially because of VirtualBox issues such as, for example, relative symlinks breaking if done in a shared folder on a mismatched guest/host OS.

It's been such a source of frustration that there is no better shared folder alternative. VirtualBox is the only usable cross-platform backend, and vbox shared folders are the only way to have two-way syncing between guest and host. I don't understand why it's so poorly supported :/

Re: Vagrant 2.0

#62
post #58

Does anyone find Vagrant useful for personal projects? Or is it only useful for team settings?

I actually use it quite a lot for personal projects, at least those that I intend on deploying to a server. It's nice to work in the exact environment the application will end up in, not to mention that certain tools only exist/work properly in a particular environment. To me, it only enhances the development process.

Re: Vagrant 2.0

#63
There are still times I look to Vagrant instead of, and alongside, Docker.

The reason being Docker for Mac uses a VM anyway (an xhvye machine) - it does try to hide/abstract this away, but inevitably this leaks. The xhyve VM has the usual parameters memory, diskspace, CPUs, and not least a kernel. There are limited options to fiddle with these parameters, though you can log into it and poke around there. I thus find it easier to just have setup Vagrant machines with Docker - then I have better control over those things.

If I were on a Linux distro though, I'd probably use Vagrant a lot less.

Re: Vagrant 2.0

#64
post #6

In the change log, I’m happy to see “improved the resilience of some Virtualbox commands.” At Airbnb, we used to use Vagrant with Virtualbox and the Chef provisioner to create our dev environments, but we migrated totally away from Vagrant after struggling with Virtualbox bugs, and strangeness with Vagrant’s internal state and locking. Seems like this issue is finally addressed: https://github.com/mitchellh/vagrant/i…

Vagrant's really falls short of its promise of "the exact same dev environment for everyone" in my experience, especially because of VirtualBox issues such as, for example, relative symlinks breaking if done in a shared folder on a mismatched guest/host OS. It's been such a source of frustration that there is no better shared folder alternative. VirtualBox is the only usable cross-platform backend, and vbox shared fo…

Vbox shared folders isn't the only way. You can use any tech that you can with "real" devices too if both guest and host has a support.

For example, when I started with vagrant, after few days of just getting bored with slow thoughput of vbox shared folders, I added nfs sharing. But cifs works as well.

Re: Vagrant 2.0

#65
post #33

Earlier quoted context omitted.

What did you end up using instead of Vagrant?

We re-implemented Vagrant's Chef provisioning feature on top of OpenSSH with ControlMaster. This cut about 3 mystery seconds mystery time from our provision process. Instead of targeting local Virtualbox VMs, we use AWS boxes created by the internal tool we use to manage our production fleet.

[deleted]

Re: Vagrant 2.0

#66
post #42

Earlier quoted context omitted.

> It makes life hard in companies where binary whitelisting is used. The application would still have to be audited, signed or not, prior to whitelisting.

In practise it's much easier to just trust well-known developers by whitelisting their code-signing certificates. You could still get owned, of course, but the benefit here is that you're excluding everything not explicitly whitelisted, including drive-by downloads, crap on portable devices or random programs downloaded off the internet that someone thinks will solve their problem of the day. When people do not code-…

Does santa work with brew? If not, how do you even function?

Re: Vagrant 2.0

#67
post #49

Earlier quoted context omitted.

The actual nature of the product itself is what ultimately matters, of course, and I hear your's is outstanding, so good work. It's a less-important issue and just a convention, not a law, but normally v1.36.12 tells me "focused on stability and just working--boring but rock-solid", while 2.0.0 tells me "first release of great, new features--amazing but don't put too much weight on it yet". I wouldn't ordinarily thin…

I would think the opposite can often be the case. Usually a major version is where you get to remove a load of unused features since you can make breaking changes.

Removing features could itself cause issues, and when you put that with adding new features/backwards 2.0.0 releases are almost never as "rock solid" as a 1.0.0 with a bunch of minor/patch versions as long as you're using semver.

Re: Vagrant 2.0

#68
post #10

How does Vagrant work with Docker? Why do you need Vagrant if you're using Docker?

Vagrant lets you provision in a codified manner full-fledge VMs. This code can be pulled down by your developers to deploy a development environment on their machines. Inside of this you can choose to run containers of your apps with proper tooling built around it.

This is the best definition I saw posted. The best sales pitch I've seen for Vagrant is that it lets you create a config ("Vagrantfile") from which you can build a virtual machine. Now you, or someone else, can take that vagrant config and recreate the same vm (on multiple platforms btw - virtualbox, kvm, etc) for testing and development.

Re: Vagrant 2.0

#69

Since many people are still not too familiar with Vagrant (it doesn't seem to have the cachet of Docker for local dev environments), here are a few example Vagrant configurations that I use to build different servers for local testing/debugging: https://github.com/geerlingguy/ansible-vagrant-examples There are plenty of other great examples of Vagrant usage around the web, too, from Laravel's Homestead to (disclosure…

> Since many people are still not too familiar with Vagrant (it doesn't seem to have the cachet of Docker for local dev environments) That's only a recent trend. Up until Docker became the standard a couple years ago (or whenever Docker for Mac was made stable), Vagrant was the standard for dev environments. The primary reason Docker succeeded Vagrant for dev environments is speed. Docker can have my dev environment…

Also the early reliance on virtualbox was a performance issue for some build environments even once they were up. I have at least one C++ project that (for windows) takes 8x as long to build on vbox vs. a real machine.

Re: Vagrant 2.0

#70

Earlier quoted context omitted.

Vagrant lets you provision in a codified manner full-fledge VMs. This code can be pulled down by your developers to deploy a development environment on their machines. Inside of this you can choose to run containers of your apps with proper tooling built around it.

Can't you do the same thing with docker, docker compose?

You can get close but as someone else said, they are mean't to be processes. You can get more control with Vagrant for a lot of things and have actual VMs.
Post reply on HN