Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vagrant 2.0

hashicorp.com

Post reply on HN
Print view View original

91–100 of 120 posts

Re: Vagrant 2.0

#91

Post by joshribakoff »

kayoone wrote: post #16

since i am using docker-compose locally, i have little use for vagrant nowadays. For staging and production the docker containers run inside a Kubernetes environment which i don't want to replicate locally. Am i missing something ?

I think you're correct. There's no reason to use vagrant. It's self titled as a way to do dev environments. You don't want dev environments. You just want config management. Like ansible or salt. I don't see why you don't want a dev environment tho. It's nice being able to code while on a train or a flight.

Re: Vagrant 2.0

#92

Post by jjoonathan »

hallman76 wrote: post #87
ubernostrum wrote: post #85

Earlier quoted context omitted.

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.

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.

Re: Vagrant 2.0

#93

Post by 616c »

geerlingguy wrote: post #29

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…

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!

Re: Vagrant 2.0

#94

Post by digitalzombie »

Sweet. I love vagrant.

I recently got to program again and set up a box and was pleasantly suprise that it does self provisioning too.

I wrote up ansible script and self provision my box.

Re: Vagrant 2.0

#95

Post by fulafel »

ArlenBales wrote: post #55
geerlingguy wrote: post #29

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…

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.

Re: Vagrant 2.0

#96

Post by fulafel »

alinspired wrote: post #81
marcosscriven wrote: post #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…

Vagrant with KVM/libvirt works great on Linux and doesn't stop you from using docker. VirtualBox is inconvenience on Linux, not Vagrant

The community is built on Vagrant-VB configs and images, so you don't really get the main benefit of Vagrant if you want to use it with something else than VirtualBox.

Re: Vagrant 2.0

#97

Post by y4mi »

fulafel wrote: post #95
ArlenBales wrote: post #55

Earlier quoted context omitted.

> 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…

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

Re: Vagrant 2.0

#98

Post by gaius »

I like Vagrant as a concept but on Azure at least, it's pretty bad at clearing up after "vagrant destroy", and people I know report similar with VirtualBox. To the point at which you might as well just bake an image and clone it, which is very easy.

Re: Vagrant 2.0

#99

Post by gaius »

jitl wrote: post #74
scrollaway wrote: post #61

Earlier quoted context omitted.

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…

Shared filesystems of any sort are too slow for most application development purposes, especially if you've got a process like NPM on one of the sides trying to read and write 2.5gb of Javascript files. We saw a 30% speedup in one of our apps by switching from NFS to two-way syncing between "native" filesystems using Unison. See mitchellh's blog post on the subject: http://mitchellh.com/comparing-filesystem-performan…

trying to read and write 2.5gb of Javascript files

The technical term for this is "doing it wrong"

Re: Vagrant 2.0

#100

Post by [deleted] »

jjoonathan wrote: post #92
hallman76 wrote: post #87

Earlier quoted context omitted.

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.

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, n…

[deleted]
Post reply on HN