Determining Volumes for Poetry and Sphinx files in Python from Dockerfile

Question

I'm working on containerizing my project using Docker, and I want to create volumes for certain files to ensure they are persistent and can be easily accessed. Specifically, I need to determine which files should be created as volumes in my Dockerfile.

For my project managed by Poetry, I want to create volumes for the following files: poetry.lock, pyproject.toml, the /tests directory (used for pytest), and the /src directory (containing my Python files).

Additionally, I'm using Sphinx for documentation, and I would like to create volumes for the following Sphinx files: conf.py, index.rst, and index.html.

My directory structure looks like this:

project
├── poetry.lock
├── pyproject.toml
├── tests/
│   ├── test_file1.py
│   ├── test_file2.py
│   └── ...
├── src/
│   ├── main.py
│   ├── module1.py
│   ├── module2.py
│   └── ...
└── docs/
    ├── conf.py
    ├── index.rst
    └── index.html

What would be the best approach to identify these files and include them as volumes in my Dockerfile? Any guidance or example syntax would be greatly appreciated. Thank you!

This question is aimed at seeking guidance on identifying the files that should be created as volumes in the Dockerfile, specifically for Poetry and Sphinx projects, and requesting examples or advice on how to include them as volumes in the Dockerfile.

Answer 1

Don't use the Dockerfile VOLUME directive at all. It mostly has confusing side effects; the easiest way to read it is that no future changes to the referenced directories should be persisted in the image. At a technical level, it causes Docker to mount an anonymous volume on those directories if nothing else is mounted there. You rarely if ever want this. Even if you're using Compose volumes: or docker run -v to mount content into a container, you can mount files over any directory whether it's declared as a VOLUME or not.

The files you mention are all either part of your application source, or developer-only artifacts. None of these should be in volumes or bind mounts either. The code should be in your Docker image, and the documentation and test output should be in your host development environment.

Given the directory layout, I might include tests and docs in your .dockerignore file so that they don't get included in the Docker image. You can run pytest and sphinx in a non-Docker virtual environment to run tests and generate documentation, even if you're deploying the application using Docker.