Dockerfile Naming Convention and Organization

Docker files are used to create docker images. When you are building image using Dockerfile, by default it would search for a file named Dockerfile with no file extension in the current directory context. Now normally an application have multiple environments like Dev, QA, Production etc. Few things like application settings and environmental variables will generally differ from one environment to another environment. To account for these changes and for image to work properly in these different environments, it needs to be either generic in nature (which is a very rare case and puts lots of un-necessary modification in the application code itself to account for these changes at runtime) or images needs to built for each environment separately.

Sometimes application needs to be a different in accordance with the architecture like x64 or amd etc. Or may be application is multi cloud in nature like aws, azure etc. To account for all of these changes, the general practice that we follow is to have separate Dockerfile for each separate environment and build the image accordingly. Also we name the Dockerfile appropriately.

For example, Dockerfile can be named like:

myapp.azure.dev.Dockerfile
myapp.gcp.dev.Dockerfile
myapp.aws.dev.Dockerfile

or something like below:

Dockerfile.myapp.azure.dev
Dockerfile.myapp.i386.azure.dev
Dockerfile.myapp.amd.azure.Dev

Fortunately, Docker build can use these Dockerfiles using -f or –file extension. Do note that naming Dockerfiles like above may break compatibility with certain tools as they require specific naming convention. However, we have a strong belief that filename should be pretty descriptive in itself and able to do justification with the utility of the file. This is specially more important if you are having 15-20 files with almost same naming in the same directory. So if certain tools are unable to support this format, we can better switch to batch/bash scripts running docker build commands.

There was also one problem of grouping these files. So if you had 15 or 20 different dockerfiles, there was no way to group them together under a single directory as well. But Source code had always been required in the context of the Dockefile itself. So while all of the source code was grouped together in one single directory (having its own hierarchy of directories and files), dockerfiles were just lying around. However, Starting with Docker 18.03 or plus, source code is not required to be the context of dockerfile anymore. So what this basically means in a nutshell, we can group together docker files in a directory say docker and then use that in our docker build process:

docker build –file docker/Dockerfile.myapp.azure.dev

I would like to know how you are managing Dockerfiles for multiple environments in your case. Do share the if its different than mine.

Leave a comment