Exactly. First thing I do when setting up a new project now is to set up a Dockerfile for the container I will build things in. For scripting languages etc. it's also easy enough to just mount your working directory anyway, so the Docker container provides the environment but you don't need to rebuild the container for every change.
E.g. for my Ruby web projects I'll often have things like this in a Makefile:
With a Dockerfile that might be as simple as this:
FROM ruby:2.3.1-onbuild
EXPOSE 80
CMD bundle exec puma --port 80
Gives me a predictable environment where I "only" rebuild the Docker container when I add/remove dependencies, and when I run it in development, shotgun will hot-reload the Ruby code from the mounted host directory.
Saves me from polluting my hosts with whatever version of code I need for different projects.
At this point there's very little code I'm willing to run outside of containers, not for security reasons but because they prevent my laptop from getting full of cruft.
I couldn't imagine going back to developing outside of containers.
E.g. for my Ruby web projects I'll often have things like this in a Makefile:
With a Dockerfile that might be as simple as this: Gives me a predictable environment where I "only" rebuild the Docker container when I add/remove dependencies, and when I run it in development, shotgun will hot-reload the Ruby code from the mounted host directory.Saves me from polluting my hosts with whatever version of code I need for different projects.
At this point there's very little code I'm willing to run outside of containers, not for security reasons but because they prevent my laptop from getting full of cruft.
I couldn't imagine going back to developing outside of containers.