10 ms·
I was a long-time Vagrant user but recently switched almost completely to Docker (Compose). What features does Docker miss that make people keep using Vagrant?
by bauerd 9y ago
I was a long-time Vagrant user but recently switched almost completely to Docker (Compose). What features does Docker miss that make people keep using Vagrant?
- Willson50 9y agoSnapshots are pretty useful, I miss those.
- cosarara97 9y agoVagrant gives you a full VM with a traditional init system. Docker is usually used without an init (or a very dumb init), so you'll have different containers for each service. It's a very different way of working, and I'd argue vagrant's is simpler and easier to understand, but less scalable.
- bauerd 9y agoYeah I understand the difference between the two but I was wondering why people prefer Vagrant over Docker for development environments.
- mitchty 9y agoFor me, because docker doesn't do jack to help with developing in the kernel.
- dominotw 9y agoI think this is one of the edge cases where vagrant is useful over docker. Most ppl here don't do kernel dev though.
- pizza234 9y agoAt my company we need to have virtual machines as close as possible (software wise) to our production environment, including the kernel version.
- dasil003 9y agoIf I'm deploying to VMs then I prefer Vagrant, if I'm deploying containers then I prefer Docker. It's all about dev/prod parity, at least at the 30,000' view, once you get into specific use cases there may be reason to mix and match.
- stephenr 9y agoBecause we want a full VM, to very closely mimic production.
- deleted 9y ago[deleted]
- cytzol 9y agoI'm far more familiar with Vagrant than Docker, so there may be Docker solutions for these problems. But I use Vagrant to: - Test my software on a "fresh" Linux installation, to ensure it doesn't have any hidden dependencies - Test my software with different filesystem layouts and (soon) different filesystems, without having to pollute my own filesystem with hundreds of test files - Automatically install a set of global commands in the VM (such as "b" to do a complete build) and display help text as soon as a user runs "vagrant ssh", so a new developer can quickly get up to speed It's been pretty good!
- djsumdog 9y agoIt seems like the author was using Vagrant to set up their base Docker machine. So yes, the author could have run everything on Docker locally, but this was to setup those Docker clusters (Kubernetes and OpenShift). I did the same thing when experimenting with DC/OS. Running a small cluster on my developer box with 32GB of ram was cheap. Running the same cluster on DigitalOcean gets very expensive: http://penguindreams.org/blog/installing-mesosphere-dcos-on-small-digital-ocean-droplets/ http://penguindreams.org/blog/installing-mesosphere-dcos-on-...
- recursive 9y agoI'm not super familiar with Vagrant or docker. But I've used vagrant before to do linux development on a windows machine. AFAIK that's not even related to anything docker claims to be able to do.
- dominotw 9y agoMe too. I use docker4mac now. Never had to use vagrant again. I know docker gets a lot of hate here but docker4mac is one one the best pieces of software i've used in a my 10 yr career. It totally changed the way i set my dev environments, think about software development/deployment. I am so glad they are going to support kubernetes now so I can do local-> staging-> prod seamlessly .
- RussianCow 9y agoTo give a counter-point to all the praise here, Docker for Mac has been one of the most frustrating pieces of software I've had to use for work. It has improved significantly over the first time I used it (almost immediately after public beta), but I still occasionally run into various bugs, such as inotify events ceasing to work arbitrarily. Any kind of networking that makes your containers visible to the host/on the local network is also a PITA to set up through the VM that Docker for Mac uses. It's also supposed to abstract away the fact that it's actually running in a VM, but I have had to tweak the VM's CPU/memory settings multiple times, and it's not obvious when you have to do this. On top of that, last I checked, Docker for Windows is still missing some features like inotify events, and requires you to enable Hyper-V, which of course removes your ability to have other VMs running simultaneously. The other side of it is that Vagrant is just easier. Docker requires everything to fit into a "one container per service, one process per container" model, which is a really good idea in production, but makes setting up background services (such as the Flow server) in development way harder than it needs to be. I'm not a devops person, so the extra overhead of trying to figure this all out is significant. Vagrant isn't without its own technical problems, but it mostly Just Works™, and I can do anything to the VM that I'd do on a regular Linux machine. As someone who really doesn't care how these things work under the hood, Vagrant has been a significantly smaller source of friction for me.
- mschuster91 9y ago> Docker requires everything to fit into a "one container per service, one process per container" model, which is a really good idea in production, but makes setting up background services (such as the Flow server) in development way harder than it needs to be. No, it does not. I use Docker as vagrant replacement too, and use a self-written bash script as "init script" that: 1) launches all services required (e.g. apache, mysql, sshd, elasticsearch) by running "service XYZ start" 2) records the pidfiles of each service (/var/run/xyz.pid) 3) sleeps 10 seconds, waits for all the pids having exited - if yes, exit the initscripts, if not, go back to #3 4) on SIGTERM/SIGINT, gracefully shut down the services in the correct order (e.g. apache/php first, then elasticsearch, then mysql); the watcher loop of #3 will detect all services having shut down and exit cleanly This way I have exact reproduction of a real target server and don't have to deal with the myriad of issues that arise with docker-compose and "custom networks". Also, the documentation on how to set up a production server, especially the required OS packages, is embedded right in the Dockerfile (or, as I put the setup script in its own file, in this one). Build time for an image with identical functionality is approximately equal to what it was with Vagrant. In contrast to vagrant, once you build that image initially it starts up way faster (10s for a LAMP+es stack), and provisioning it is a breeze compared to puphpet or whatever is the trend now. And you don't have to update your setup script unless the base OS changes, as compared to puphpet+vagrant - in fact I can use nearly the same setup and init script across stuff as old as Debian 6 (some ancient proprietary software I had to dockerize) over Ubuntu 16.04 and as brand new as Debian nightly.
- octalmage 9y agoSame here, been using docker-compose for development and testing and it's been great. Spinning up 4 servers with docker uses much less space and memory than 4 vagrants. It's also much quicker to provision and get started.
- scaryclam 9y agoI use both Vagrant and docker for local Dev work. I've found that we have far less problems with the vagrant box (we link a bunch of projects into a single box to save RAM) than the docker compose setup. We're now looking into a minikube + rkt option, since it's docker daemon itself, not the compose part that makes it painful. Hopefully we can find that sweet spot between working nicely and resource preservation that we want.