Hacker News Reader

Comment by geerlingguy | Hacker News Reader

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, I maintain it) Drupal VM.

It seems a lot of older applications / communities migrate towards Vagrant as some of the things they do are harder (or at least not as straightforward yet) to implement in containers.

View on HN

> 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 up from scratch in seconds, but with Vagrant it took minutes.

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.

Wow, it doesn't rely on VirtualBox anymore? I remember using it before for the development environment of an old company, and that being a small nuisance.

Nowadays, Docker is really miles ahead in terms of usage in development environments. Vagrant was pretty easy to set-up and use back then, but now Docker is much, much easier.

I need to get into this Docker malarkey for dev machines.

Running on Windows, how do you share files between the Docker image and the host machine? With Vagrant I use NFS.

You basically create a mount point inside the VM to a place on your host disk.

To expand on the other commentor, check out volumes: https://docs.docker.com/engine/admin/volumes/volumes/.

Vagrant calls the backends "providers." It ships with 4 providers IIRC (VirtualBox, Hyper-V, VMWare, Docker), and there are plugins for dozens of others (it's so large a list because there's one provider each for pretty much every cloud service out there, even ones I've never heard of).

I think that VirtualBox and VMWare are the only two providers that work everywhere, unless docker runs on windows now.

I've just started using vagrant with vmware fusion. Whilst not cheap the fans on my computer are much happier these days.

I once worked on a project which used Vagrant as its officially recommended local dev environment.

Every time I had to set it up from scratch, it took me -- and I was not a novice, and knew the stack well -- a day or more and many, many failures to get running. Thankfully, I think the project has since abandoned Vagrant.

(and Docker isn't much better in my experience)

you, and they, were doing it wrong.

The point of vagrant is that you type 'vagrant up' and you have a working environment.

All of my projects use vagrant to ensure compatibility. You can 'git clone' and 'vagrant up' and have a working environment as soon as the provisioning task completes.

Thanks for the help.

I trust that the people who provided whatever configuration it used knew what they were doing, but it was still incredibly flaky.

> I trust that the people who provided whatever configuration it used knew what they were doing

You should never trust that people know what they are doing in this industry.

I don't think I've ever encountered a Vagrant setup that was flaky and wasn't just down to the Devs not actually understanding how to write a vagrantfile. In my experience, those who have hate for vagrant are folks who either didn't know how to use it, or were burned by others who didn't. It's a real shame as well, vagrant's a really good tool.

Not my experience.

Vagrant encounter 1: it would always exit immediately after barfing some garbage that messed up the line discipline. It wouldn't even print help menus. Reinstalling, 32 vs 64 bit, slightly different binary versions etc didn't seem to affect this behavior.

Vagrant encounter 2: on a nearly virgin Windows box, "vagrant up" on a bog standard centos image stalled out for an entire work day. No stdout, no stderr, no logs, no exit status, it just sat there.

On a scale of 0 to 'flake', it's at full flake.

That screams badly written vagrant file to me.

Vagrant updates can wreak havoc too.

Vagrant is very bare-bones, so you need plugins, but those are ... picky.

Also, handling Linux / Windows / OSX with the same Vagrantfile results in interesting things. (Let's say you want to use NFS for Linux, so you put there an if, and you want to set up bridging for a local interface, you have to guess the interface name - or do shell and cmd.exe wizardy .)

The problem with Vagrant was always that the other backends besides VirtualBox were second class citizens because of image and config file incompatibility between backends. And VB is pretty bad, the driver side was always crashy on Linux and it conflicts with the native virtualization drivers on Mac, Windows and Linux.

So there were good reasons to avoid it before Docker too.

i used vagrant with libvirt/qemu at my last job and it worked just fine though...

the only problem i had was updating base boxes, but that was self inflicted because it was easier to make a function to delete them from the libvirt cache than maintaining proper versioning.

/edit: i just realized from your other comments that you're probably constraining yourself to prebuild baseboxes. you really shouldn't. its trivial to built them with packer [1] and there are lots of config files on github[2] to do just that. This makes it possible to really tweak them for full integration right after 'vagrant up'

[1] https://www.packer.io/intro/index.html

[2] https://github.com/chef/bento

When I started learning Ansible, I kept running into your stuff on the Ansible Galaxy [0]. Such a peculiar name, it stuck with me. Thanks very much for your contributions!

Vagrant is probably the best way to go about learning automated configuration management with ansible, and especially Puppet. And I've never tried it myself, but I hear people setting up local OpenStacks with Vagrant, too. Not a bad way to get your feet wet.

[0] https://galaxy.ansible.com/

We use Vagrant with docker containers inside running our web apps. Vagrant functions as a disposable virtual dev environment (on Mac) to do our docker development in linux and know everyone's machines are identical when developing for production. A new dev can just download our latest vagrant repo, vagrant up and it'll provision their development environment to be exactly as it should be.

It doesn't have to be one or the other.

Homestead is wonderful! I've been using it for years for Laravel development. Thanks!

He meant Drupal VM :)

I'll still add that Homestead and Laravel are amazing.

For Go-users wanting a quick way to get a basic Vim setup with Fatih's awesome vim-go plugin [1], you might want to checkout https://github.com/samuell/devbox-golang (Just updated to Go 1.9).

It is a little different from some other vagrant boxes in that it uses Ansible for provisioning. This means you can reasonable easy re-use the ansible roles (perhaps with some minor modifications) elsewhere too, like locally, or on some cloud image.

[1] https://github.com/fatih/vim-go

I am the maintainer for a dev env for our team. We are on Mac OS X but we develop for RHEL so the vagrant image is centos. Building an image takes a few minutes but we love it.

We will probably research docker in 2018.

Amazing, I was just using your templates for Packer PoC stuff at work today. Your Ansible, Packer, and Vagrant stuff is topnotch and a great cliffnotes for quick experimentation. Keep up the good work!

Thanks for all your hard work on DrupalVM, Jeff :)

Just wanted to drop a note to say thanks for your nicely done ansible recipes.

Reply on news.ycombinator.com