Should Built Docker Images Be Used in a Development Environment? Should Dockerfiles Be Used in a Production Environment?
When getting started with using Docker, you’re very likely to run into all kinds of practical issues. It gets even less straightforward to find answers when you get out of the realm of purely technical questions, and into processes and workflows.
One of them, is whether you should be using Dockerfiles in your production environments, or make development environments rely on pulling custom images. Let’s discuss both issues and clear up the confusion by making sure we got the requirements and context straight.
Docker Image in Development
There’s nothing wrong with that. There’s no reason to make dev environments unusable without the ability to pull a certain private image, but you can specify a repo and tag to make it come up faster without having to build a fresh image.
For your development environment, you should make a comprehensive Dockerfile part of the code repo, so any developer is able to create an image themselves only having access to the codebase and public resources.
Such an image, may contain libraries which your project needs and can be used by your CI workflow to reduce startup times and make building from Dockerfiles not-strictly-necessary.
Having said that, you don’t want to use a Docker image which adds your project code to the image during build. For development purposes, mounting a code directory into the container is better, as you don’t need to rebuild the image all the time and can see the impact of changes to the code immediately
Dockerfile in Production
You can have a Dockerfile in production, and make it part of a workflow to bring your project up. There’s also nothing wrong with mounting your code into the container instead of baking it in. I’d argue that you shouldn’t though.
Resources are an issue. Depending on your machine size, building a Docker image can entail compiling components and keeping lots of stuff in memory, which may need a bunch of resources. Be sure that the build does not negatively impact your production setup.
It’s better not having to build your docker images on the fly. a continuous integration workflow which builds an image and pushes it to a private registry is preferable.
Instead of relying on a Dockerfile to bootstrap your production setup, it’s better to pull images from a registry, instead of building them. You can use something like a docker-compose.yml file for your production setup though, to pass environment variables and configurations to your services.