Ask HN: Do you use Vagrant or Docker for active development?
I think I understand the use case of Docker for deployment, but does Docker hold its sway at the moment for active development. Data persistence support is not out-of-the-box. Vagrant with its own isolated and shared volume support seems like something that would be very good in active development of software artifacts. What is the view of the HN mass, and what would you recommend?
Apart from these two, are there any others that looks promising?
68 comments
[ 3.5 ms ] story [ 120 ms ] threadIt was significantly easier to tell my co-workers to install docker and type `make local` for local binaries and `make igep` to produce a igep armv7 binary by running a docker container.
We then use our production docker image(s) with some more development appropriate configuration options. Vagrant mounts the user's home directory at /Users/<username>/ inside the CoreOS machines. Then we mount the appropriate folder inside the docker container at where the container would normally expect to find the app's code. This way the developers have live updates without having to rebuild the docker image or anything.
The downside is it feels like a lot of layers of abstraction. And I haven't quite figured out the right way to hook up e.g. the PyCharm debugger to a python interpreter running in a container that's running inside a VM.
I am already on Linux, so, my question is why create extra abstraction to it? Is not the function of docker to provide isolation as Vagrant but without the extra overhead of VM. As far as I could gather, one prominent use cases of Docker is the cheapness. Would not doing Docker on top of Vagrant beat that purpose?
As a solo coder, I love vagrant - the whole nature that you can use a configuration file with a script or two to build out an entire VM has so many benefits. Less time to build the VM, easily destroy the entire VM, easily rebuild the entire VM, save drive space by destroying the VM when you don't need it, keep the VM configuration in a git repo, distribute the configuration to someone else to use, and the best is having all the steps used to configure the VM are documented in the config file and scripts.
I check back in about once every two months to see if there have been any breakthroughs.
I wish the Docker team hadn't more or less given up with boot2docker, since it completely abandons the vagrant advantage of a folder shared with the OS. People do wierd shit like trying to mount their OSX home dir over NFS and, well, Vagrant solved this a long time ago.
It isn't a VM though, and there are some isolation issues, but primarily as a target for security, not something that results in different versions or tools being a issue.
VMs are great when you want to test cross-platform or cross-architecture or legacy compatibility all on one machine (there's more to the world than Ubuntu).
While right now, it's a linux only thing, with the incoming support of Windows, things will start to change dramatically.
If what you say is true, Docker would be a great way to do development through SSH on a VPS with minimal RAM and resources. I'll definitely take a look at it.
A lot of people us both http://docs.vagrantup.com/v2/provisioning/docker.html
That's actually the only thing that got me to hold off on Docker the last 2 times I've evaluated it. I was able to get everything running for a 1 monolith + 7 microservice system that I work with but the local developer workflow felt very clunky even with Fig. That was 6 months ago and it's my understanding there have been a lot of improvements.
That project was for a Ruby team and there are so many Ruby based tools that make the local development workflow a smooth operation that shoehorning Docker in locally would have been a step back, so we held off on it.
It's an area that I think will see major improvement though. Heroku's even gotten in on it.
https://devcenter.heroku.com/articles/introduction-local-dev...
Which is really impressive to me. If anybody in the space can polish out the user experience, it's Heroku.
In terms of using docker, IMO it's the best development experience I've come across once you get everything set up. It can be confusing to get your workflow set up at first, and it seems like everyone does it a little differently, I'm hoping that best practices will standardize a bit as docker continues to mature.
I love having every part of an app (app code, split into a few microservices if you wish, postgres, redis, rabbitmq, etc.) completely isolated, and docker-compose is a great system for linking things together. I also currently don't have any puppet/chef/etc code and love not having to maintain that, in my mind a large part of the need for configuration management tools is dealing with the complexity of diffing two arbitrary states of infrastructure, and with the immuatable approach of docker containers all that complexity disappears.
So you change a file on the host computer, and it reflects automatically inside the guest VM which is the docker host, and automatically inside the containers since that same location is mounted by the containers.
I just checked the Vagrantfile, and the Ansible playbook we use to launch the docker containers, and I don't see any special magic required to get the syncing working with the Vagrant filesystem, it just works out of the box.
And by the way this setup is bidirectional. If code inside my container, or an SSH session running inside my container makes a disk change, that change is also reflected on the version of the folder that runs on the host.
So if you don't want to go through the effort of doing the port forwarding, you can run live reload on your host machine, and reload the browser automatically in response to changes that were made by the container.
Events should work just fine when they are on the same host (although currently overlayfs does not support inotify, so...)
I actually did something simple with both Vagrant and Docker, I'm hoping to bundle it into a self-executable and have it as an alternative to boot2docker.
Right now, it works only on OSX & Linux, but what it does is it uses Vagrant and builds a "docker-host" vm that you spin up manually (or you can just use a launchd script to spin it up on startup). Since Vagrant has great support for setting up a network bridge, I basically created a virtual private network between the host vm and my os. I set up the docker client running locally (brew install docker) and through the network bridge, it creates a pretty seamless experience.
The beauty of Vagrant here is that I can customize the mem, cpu, etc. Vagrant also has rsync support (and rsync-auto!) and of course, great shared folder support with the docker image. I have experimental support to also create this experience on AWS, including spot instance support
You can check it out here: https://github.com/mahmoudimus/docker-host-osx.
Previously all devs had their own environment (some MAMP/WAMP, some homebrew, some remote, etc) which led to onboarding and support issues. Setting up a standardized recommended dev environment has helped with that a lot - both in terms of reducing project onboarding and getting junior developers up and running.
Would love a day where we can build projects as Docker containers and hand them off to our clients' IT teams, but that seems to be a way off.
SO thread where the authors of Vagrant and Docker weigh in: http://stackoverflow.com/questions/16647069/should-i-use-vag...
https://github.com/czettnersandor/vagrant-docker-lamp
Much faster than the Virtualbox provisioner, so it's not an "or" decision, the two thing works well together :)
I love the fact that once I configured the dev environment on my PC and I hit the road on the next day I can have exactly same environment on my laptop by running single line - "vagrant up". Not to mention that any dev working on the same project saves himself ton of time but not having to configure everything from scratch.
I have not taken the leap of faith yet and I am not using the docker in production but hopefully this will happen soon.
At my last job we used Docker extensively for developing our main software product, based on a Django + PostgreSQL + RabbitMQ + Celery stack. It's definitely a bit tricky to get your head around at first, but after that, it's very nice being able to just type "docker-compose start" and have a working application with consistent configuration ten seconds later.
And, I agree that docker way of doing things is a bit tricky at first, since we are not used to doing things that way
This is actually not the case. Although containers do not share any persistent volumes with the host by default, you can use the --volume option[0] to do so.
To answer your question, I've used Docker for local development to run MySQL, Postgres, and Redis inside of containers. Using the aforementioned --volume option, you can share the unix socket opened by either of these services from the container to the host. Otherwise, you can use the --port option[1] to share ports between the container and the host.
I've had a generally pleasant experience using Docker for this use case and would recommend it. It's nice being able to start using a new service by pulling and running an image. Similarly, it's nice to have the ability to clear the state by removing the container, assuming you choose not to mount volumes between the container and the host.
The only frustration I've run into is running out of disk because I have too many images, but it takes a while to get to that point and those can easily be deleted.
[0] https://docs.docker.com/reference/run/#volume-shared-filesys... [1] https://docs.docker.com/reference/run/#expose-incoming-ports
The vm environment was also as close as possible to the production env, with the same os version, etc.
It also greatly streamlined onboarding of new devs. The dev environment setup was a couple of hours instead of a day or two.
Don't use any kind of provisioning on vagrant just straight bootstrap.sh as honestly I don't like them.
When I write code inside docker, I always submit to a git repo like Bitbucket. Data persistency is easy. Besides you can always use --volume, which works out of box in Linux.
Vagrant requires some basic shared environment, which is not realistic in my case. For example, I use Archlinux myself and am forced to use old Scientific Linux at work, while many other FEniCS developers use Ubuntu, Fedora, or Mac stuff. It is too painful to write and maintain a Vagrant script for all these (different compiler, boost, blas, lapack and some other 10+ numerical specific stuff). I even tried Vagrant+docker. But in the end, with docker maturing, I switched to docker+bash script instead. It is just more convenient and needs less dependency.
So I'd endorse a docker only approach if you mostly use Linux and your project has a diverse group of people.
Vagrant is a great technology, but I recommend taking a look at Docker compose (https://docs.docker.com/compose/) previously known as FIG. One of the great advantages of compose is that combine it with Swarm (https://github.com/docker/swarm) and you have a very robust distributed deployment system. Docker-machine is the direct competitor to vagrant, but to be honest, I don't use it. I spin up my docker containers via some build in service API's we already built for proprietary reasons.
If you want to get really robust, you can also look at Kubernetes (and their zero-downtime deployment) and Mesos. These both add a huge amount of complexity t the deployment, but also grant a robust distributed system for managing downtime and deployment. Redhat also has Openshift.
What I'm looking for is a robust and systematic zero-downtime approach to update some of the containers (say in a loadBalancer → web servers → db architecture).
I also like to use it to create test deployments for debugging or evaluating things, for example it's a lot easier to run Hadoop in pseudo-distributed mode inside a Docker container with host networking, than it is to fiddle with running it in a VM and either getting NAT or DNS working just right, or installing it locally. With the Docker container, if anything goes awry, it's just so easy to get back to initial state by killing the container and starting again.
As for Vagrant, I like it a lot too, but for different reasons. You can define a set of actions that is a lot closer to installing whatever it is you are developing, instead of baking everything together like you do with Docker, which can be desirable. I have used it in the past for creating virtualized cluster environments for integration testing of distributed systems. I think so far I use the VirtualBox provider, but I'm thinking of re-working some of my past uses of it that don't strictly require a VM to use the Docker provider.