-
I've always just fired up a VM if I've wanted isolation.
I used docker once, to run a few lines of python that someone had packaged as a docker container, and it ended up eating all 5GB of spare space on my AWS instance and I never bothered to figure out why.
Anyway, what you describe sounds good. Especially for CI and deployment.
Not sure how well it would work for local development. Would you include the container config in your repo, and rebuild the container every time you pull from master?
cyclotron3k-
The config is normally under source control. You could snapshot the container at the end of the build and discard it if the config changes. Not sure how you actually do this, I was too busy writing code when Docker became a thing here.
-
Would you include the container config in your repo, and rebuild the container every time you pull from master?
Depends on the size of the project.
For small projects that are to be shared to a wide audience... yes. This is what people do.
For large projects inside companies comprised of many components... no. In this scenario one typically has a "dockerfiles" repo containing all Docker files. This is no different to how companies have a repo for their Puppet/Chef/SaltStack or something. Except in the Docker files example one typically will publish you compiled or packaged code to a package server of some kind (maybe you push a .deb file somehere) and then the Dockerfile is simply a small container describing an
apt-get install mycode=this_version.But for local dev and small projects, yes... docker files go into the repo.
For large corp dev, docker files are managed along the lines of config management and are in other repos (though local repos may still have a docker file for local dev work).
Emyr
Velocio
Because then you have your temporary piece of work leaving permanent files on your OS.
Over time this cruft is messy, and when you're working with multiple web apps it's hard to divine which left what where.
Docker is fantastic for local development in the same way virtualenv is. It can namespace and contain all of the files, processes and configuration for an app.
When you're done with it... just blow it away.
Then if you're deploying it can be a dream there too. Maintain your own company image repo and have your CI push docker images into it. Later... just deploy a pushed image to whatever container cluster you happen to run in prod, be it Kubernetes, Mesos, etc.
The experience remains consistent from dev through to prod, and the only thing we really gained is better management.
But that's ace, better management is what was missing.