Если вы не можете использовать переменные окружения, вам следует использовать привязку. Если вы используете именованный том, вы не можете получить доступ к отдельным файлам и не можете напрямую редактировать файлы конфигурации.
Именованный том - это всегда целый каталог, и к нему нельзя получить прямой доступ с хоста. Не существует такого понятия, как «файл тома» (ваш связанный вопрос полностью посвящен монтированию bind, некоторые используют синтаксис именованных томов), и нет способа монтировать один файл из именованного тома.
Более новые Docker имеют несколько различных синтаксисов для монтирования привязки (в Compose, конфигурация службы short и long volumes: или создание именованного тома type: bind). Все они в основном эквивалентны, и многие ответы в вопросе, на который вы ссылаетесь, включают в себя создание именованного тома, имитирующего привязку.
Docker Compose поддерживает относительные пути, так что вокруг меньше беспокойства пути хоста для монтирования привязки являются непереносимыми в разных системах. Фрагмент базового c файла docker-compose.yml может включать в себя:
services:
app:
build: django
volumes:
- ./config/django-settings.py:/app/settings.py
В этом примере я бы предложил (1012) каталог (deploy-time), содержащий файлы конфигурации, но это произвольный выбор; если вы хотите привязать монтирование ./django/settings.py из дерева исходных текстов приложения к тому, что находится на изображении, чтобы иметь возможность редактировать его напрямую, это тоже правильный выбор. Вы можете проверить это дерево в управлении исходным кодом, и оно будет работать независимо от того, где оно было извлечено.
Если вы используете базовое изображение с полным набором инструментов GNU (Ubuntu, а не Alpine), тогда ваш контейнер Сценарий entrypoint также может использовать envsubst в качестве очень легкого инструмента для создания шаблонов (он заменяет ссылки $VARIABLE эквивалентной переменной среды), который поможет вам поддерживать вариант «много параметров», но не «тип dict» Варианты "case.
В общем, я бы рекомендовал bind mounts для двух случаев и, возможно, для третьего: для файлов конфигурации (где оператор должен их непосредственно редактировать), для файлов журнала (где оператор должен напрямую прочитайте их) и, возможно, для постоянного хранения данных (где существующее решение для резервного копирования будет работать без изменений; но не в MacOS, где оно работает очень медленно). Именованные тома могут хорошо соответствовать случаю постоянных данных и лучше соответствовать тому, что вы использовали бы в кластерной среде (Swarm, Kubernetes), но к ним нельзя получить прямой доступ.