Best practice for config files in containerized apps

Question

The suggested file structure for docker container is something like

root
├── app/
| ├── ...
| └── Dockerfile
| 
├── db/
| ├── ...
| └── Dockerfile
...
└── docker-compose.yaml

So where do you put configuration files? If there is any overlap, and the app and the db need access to the same configuration, you immediately run into build context problems, since COPY in Dockerfiles is restricted to the build context, which would be the app/db/... sub-directories by default. And also should be those sub-directories to avoid sending tons of superfluous files to the docker daemon.

---

My current idea is to do something like this:

root
├── app/
| ├── ...
| ├── Dockerfile-app.dockerignore
| └── Dockerfile-app
| 
├── db/
| ├── ...
| ├── Dockerfile-db.dockerignore
| └── Dockerfile-db
...
├── config/
| ├── common
| ├── app
| ├── db
| ├── ...
└── docker-compose.yaml

Then I set the build context to root for every dockerfile, with the Dockerfile-app.dockerignore looking like this:

*
!app/*
!config/common/*
!config/app/*
...

this approach is heavily reliant on the relatively new Dockerfile.dockerignore feature which is referenced as largely "undocumented" in this issue: Add support for specifying .dockerignore file with -i/--ignore and not universally supported (e.g. tilt), which makes me quite uneasy about it.

At the same time a failure to recognize the dockerignore files only causes a slowdown and does not stop this method from working. So in that sense it is relatively stable. And the grouping as a config folder likely enables it to become a submodule and be version controlled separately which seems neat.

Or using the 'default/override' pattern there could be a config_default and config folder, where the config_default is tracked and the config folder is put into .gitignore. If you then init a git repository in the config folder you can probably use the two repositories independently, avoiding the infamous submodule complexity of git which I have not looked at yet.

Any different approaches, suggestions, comments?

• Thorbjørn Ravn Andersen: Put them in a volume.

Answer 1

Configuration files should not go into the build process but can be mounted into the containers when they are started.

Many people instead pass config data as environment variables which works and is very light-weight but may be a slight security risk. At least for credentials, using a credential store is advisable.

• Felix Benning: Hm mounting has the added benefit that you can switch configuration without rebuilding the container. How expensive is mounting? Why is source code itself usually not mounted in production settings? Is worrying about performance warranted?
• Hans-Martin Mosner: No, there is no performance hit. In experimental settings (for example, a minimal python app) I often use a standard image from Docker hub and mount my source into it. However, for stable apps you want everything except config data to be in the image.