I posit that people who use and love docker have larger teams with proper full-time admins and not just 1-3 people wearing all the hats. This is fine. I just have to be super judicious with my time.
I've also heard that many of the benefits come if you have a lot of servers running that are talking to each other. I'm not really doing that. There's also supposedly some lower overhead costs in using it but 32GB of ram which is nothing special these days has been more than sufficient for my virtualbox needs; heck I usually have 28 or so left over.
Vagrant+virtualbox I use all the time (here's the vagrantfile I am currently using: http://9ol.es/Vagrantfile - no chef or puppet stuff I just do it manually) . It doesn't do much and that's perfect, just what I'm looking for.
We switched from a Vagrant based workflow, to a docker-compose one, and we are a team of 2 developers. That said, I identified use cases for Docker that offered very compelling advantages. For a typical web app, this may not be the case. In our situation, we run a load that is very background-job intensive, with multiple clusters of external resources used by the background jobs, so it's definitely a different story than the typical 2-3 tier web stack.
I don't know what the current situation is on Windows or MacOSX. Back when I used them for my own work, the only choice was to run a VirtualBox instance running Linux and then run Docker on top of that. Clearly that solution is more of a lateral move from Vagrant.
The problem seems to be that there are no good "overview" tutorials out there that I could find. I'll end up writing one.
You could just as easily and much more portably put those “manual steps” into a shell script and run it as a Vagrant provisioning script. If you pick the right base box you will have portability across Mac, Linux, Windows hosts, using any number of available hypervisor/ish layers (vbox, parallels, VMWare, hyperv, lxc, etc)
You can execute a Shell script when the box is first provisioned. Just add something like this:
config.vm.provision :shell, path: "provision.sh"
This might help save doing some manual steps if you have to rebuild the VM for whatever reason.> I posit that people who use and love docker have larger teams with proper full-time admins and not just 1-3 people wearing all the hats.
I’m not aware of what your use cases are, but I found Docker pretty simple to use and less of a headache than Vagrant. What work is it requiring you to do? I also use it for many projects that I am the sole dev for.
Docker Compose can configure volumes via relative paths, e.g. './' and '../'
However, there are still cases that I think Vagrant is far superior. I recently had a security-related use-case that wanted me to very precisely replicate a common production environement (LAMP w/ exim4 MTA). On docker this is complicated. On Vagrant it's very simple.
So I don't think it's dead or dated, even though Docker has replaced it for a large range of my own use cases.
My company maintains a series of Debian base boxes (forked from the box cutter project) but our bread and butter is infra projects, and packer makes it a pretty quick process to rebuild once you identify what to change for a given fix/feature.
Also, I build a Debian repository at https://vagrant-deb.linestarve.com which serves the .deb files so you don't have to update them manually whenever a new version of Vagrant is released.
At least for our usage, it was pretty simple to switch our JS dev environment to support Windows (the primary development platform of our developers) without much hassle.
For now, If I need a VM, I'll stick to virtual box and maintain a persistent development environment, rather than something configurable and replicatable.
In the future I'd love to see someone take something like Docker and turn it into a development environment platform.
Another gripe is we have to edit the Vagrantfile & adjust the CPU / memory usage for each developer. There's no way to have a local override AFAIK.
We also have another Vagrant box that emulates our IOT devices, which runs X server. That's been a huge productivity gain in that we can just change code live, instead of having to rsync code to a physical device to test it. .
So, you're right there is no "built in" support for Overrides on a per-project basis in Vagrant. There is some built in support - it will source local Vagrantfile files and wrap them around the project specific one (so e.g. my $VAGRANT_HOME/Vagrantfile is setup to tweak the defaults for the Vagrant-Hostmanager and Vagrant-Parallels plugins, and this then applies to all Vagrant machines that don't otherwise change those settings).
Probably what you really want though is the ability to override per-project, per-dev.
This is where it helps (a lot) if you know ruby, or if you're willing to learn a little (which was my case for this problem).
I've put the basics of this concept into a gist here: https://gist.github.com/stephenreay/2afd4205e76836f20e176722...
Having Vagrant with shell script provisioning makes it super simple to create reproducible dev environments that works for everyone on the team.
Also when I say dead I mean “not sexy conference talk anymore”, so whatever that’s worth,
It still has its use-cases and Docker can't cover some of those special test cases since it shares the kernel with the host system.
I use Vagrant daily. I mostly work on operating systems other than Linux (SmartOS, FreeBSD), so Docker is not a replacement for me.
In general it works well enough with VMWare - Virtualbox doesn’t support the features I need. The closed source nature of the Fusion plugin is annoying, given that there are (basically) show-stoppin bugs which have not been resolved in months. However, Vagrant or some derivative has a long future ahead, at least for those of us not on Linux.
Docker is probably better for larger and longer term use.
Either is pretty damn good for development machines, with Vagrant being slightly easier to hack on.
So I'd say no to "Is it dead?" Is it dated? Well I stopped using it once I found Docker (years ago), but can't say much for others. I'd be using it if I targeted other hosting platforms than Linux.
That said, Vagrant has a lot of nice tooling for simple development workflows (e.g. Vagrantfile)
We are using Kubernetes in the dev environment, and Docker Native simply doesn't work for what we want to do. Back then, about 9 months ago when I put this together, Minkube did not support native Linux, so I ended up creating the Packer scripts that baked in a customized Nanokube and loaded it with the tooling.
The current team has a mixed bag of people on Windows and a few people on Mac. Bash for Windows wasn't mature enough at the time -- and even if it were, we'd still have to create some sort configuration management to get it installed for people.
Our team is small and we've since been swamped with writing new features. I'll probably do a refresh of the dev environment in the "dead" months in Nov and Dec -- signing up for a Vagrant Enterprise account, ditching Nanokube for Minikube, fix a bunch of bugs.
Depending on what you need, any one of those may be a valid option for standing up a box.
I could use a shell script to essentially do everything to prepare a box.
If it's a stateless server, then creating an AMI is simple and the image can be used to drive auto-scaling groups etc.
If my local development scenario is more complicated or I'm doing it a lot, maybe vagrant is the better choice. Because then it can setup the box as well as provision a vm with virtualbox.
But if you're doing something in the cloud or something beyond an auto-scaling group, I would look to docker for inspiration.
That's where I'm at.
They gave me a good computer so I didn't have problems with the spinning up of the vms but I'm pretty sure that that load would slow my own computer to a crawl. I also can't say I'm a fan of the syntax of the Vagrantfile but that might be because I'm too used to docker-compose.
All in all, I think it's a good tool, but I think I'd use docker for most use cases, including the one I'm working on, but it's too late to change vagrant there.
Today I have a Java system which composes bash scripts out of fragments and puts them in the cloud-init data for virtual machines. The machine does whatever it is going to do, then it drops a message to a message queue to say it is done and trigger a pleasant chime if successful, otherwise a painful scream if failed. The Java program automatically downloads the cloud-init logs and can usually point out where the failure happened if there was a failure.
One of these days, I'd like to do a deep dive into Nix. I'm not sure it can really be compared to Vagrant or Docker, but the idea of purely functional provisioning appeals to me.
The same code and constructs can be used in Vagrant as with other elements or phases of deployment; scripts, runbooks, playbooks, recipies - all can be used locally the same way they might be at cloud scale.
It's a major win for me, I hope Vagrant has a long and fruitful life.
Apparently it has been succeeded (2015) by Otto (https://www.hashicorp.com/blog/otto/), though I'd never heard of Otto until just now.
Vagrant OTOH, is still being maintained.
Terraform also started as a happy path abstraction, then the nitty gritty reality kicked in and suddenly you are no longer abstracted from the platform but forced to code on another platform for another platform. I'm even surprised it took off this much.
If we are deploying to docker, I use docker. Otherwise, I use vagrant.
I try to shift my env to docker but faced alot issues in configuring and running some scripts on docker-compose up.