How to name Dockerfiles

I'm unsure of how to name Dockerfiles. Many on GitHub use Dockerfile without a file extension. Do I give them a name and extension; if so what? Or do I just call them Dockerfile?

[Please read the full answer]Don't change the name of the dockerfile if you want to use the autobuilder at hub.docker.com. Don't use an extension for docker files, leave it null. File name should just be: (no extension at all)

Dockerfile

However, now you can name dockerfiles like,

test1.Dockerfile
$ docker build -f dockerfiles/test1.Dockerfile  -t test1_app .

or

Dockerfile.test1
$ docker build -f dockerfiles/Dockerfile.test1  -t test1_app .

This will also work.

If you handle multiple files that live in the same context, you could use STDIN:

test1.Dockerfile
$ docker build -t test1_app - < test1.Dockerfile

dev.Dockerfile, test.Dockerfile, build.Dockerfile etc.

On VS Code I use <purpose>.Dockerfile and it gets recognized correctly.

I know this is an old question, with quite a few answers, but I was surprised to find that no one was suggesting the naming convention used in the official documentation:

> > $ docker build -f dockerfiles/Dockerfile.debug -t myapp_debug . > $ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod . > > The above commands will build the current build context (as specified by the .) twice, once using a debug version of a Dockerfile and once using a production version.

In summary, if you have a file called Dockerfile in the root of your build context it will be automatically picked up. If you need more than one Dockerfile for the same build context, the suggested naming convention is:

Dockerfile.<purpose>

These dockerfiles could be in the root of your build context or in a subdirectory to keep your root directory more tidy.

I think you should have a directory per container with a Dockerfile (no extension) in it. For example:

  /db/Dockerfile
  /web/Dockerfile
  /api/Dockerfile

When you build just use the directory name, Docker will find the Dockerfile. e.g:

docker build -f ./db .

I have created two Dockerfiles in same directory,

# vi one.Dockerfile
# vi two.Dockerfile

to build both Dockerfiles use,

# docker build . -f one.Dockerfile
# docker build . -f two.Dockerfile

Note: you should be in present working directory..

It seems this is true but, personally, it seems to me to be poor design. Sure, have a default name (with extension) but allow other names and have a way of specifying the name of the docker file for commands.

Having an extension is also nice because it allows one to associate applications to that extension type. When I click on a Dockerfile in MacOSX it treats it as a Unix executable and tries to run it.

If Docker files had an extension I could tell the OS to start them with a particular application, e.g. my text editor application. I'm not sure but the current behaviour may also be related to the file permisssions.

> Do I give them a name and extension; if so what?

You may name your Dockerfiles however you like. The default filename is Dockerfile (without an extension), and using the default can make various tasks easier while working with containers.

Depending on your specific requirements you may wish to change the filename. If you're building for multiple architectures, for example, you may wish to add an extension indicating the architecture as the resin.io team has done for the HAProxy container their multi-container ARM example:

Dockerfile.aarch64
Dockerfile.amd64
Dockerfile.armhf
Dockerfile.armv7hf
Dockerfile.i386
Dockerfile.i386-nlp
Dockerfile.rpi

In the example provided, each Dockerfile builds from a different, architecture-specific, upstream image. The specific Dockerfile to use for the build may be specified using the --file, -f option when building your container using the command line.

If you want to use the autobuilder at hub.docker.com, it has to be Dockerfile. So there :)

Dockerfile is good if you only have one docker file (per-directory). You can use whatever standard you want if you need multiple docker files in the same directory - if you have a good reason. In a recent project there were AWS docker files and local dev environment files because the environments differed enough:

Dockerfile Dockerfile.aws

Dockerfile (custom name and folder):

   docker/app.Dockerfile
   docker/nginx.Dockerfile

Build:

   docker build  -f ./docker/app.Dockerfile .
   docker build  -f ./docker/nginx.Dockerfile .

There are 2 main Dockerfile naming conventions:

1. Using a default Dockerfile:

Keeping it simple, this approach suits simple, standalone, and well-defined projects.

$ docker build -f ./Dockerfile.Dockerfile .

2. Using a custom Dockerfile:

Keeping it custom, this approach familiarises the developer with the application context, facilitates file manipulation and, improves debugging capability, especially in the case of multiple dockerfiles.

$ docker build -t <containername> . -f <mycustomdockerfile>.Dockerfile

---

Gentle Reminder:

These conventions are equally applicable for common docker image building commands such as 'docker image build' and 'docker-compose build'.