Рекомендуемый способ предоставления файлов конфигурации контейнерам Docker

Я перемещаю наше веб-приложение в развертывание с созданием докеров (Django, DRF, AngularJS).

Теперь Docker выглядит солидно, и дела идут хорошо.

Я хочу:

  • подтвердить с вами, что я следую лучшим практикам в отношении файлов конфигурации приложений
  • узнайте, действительно ли «файлы томов» являются привязанными монтированиями, которые не рекомендуются

Мне удалось использовать переменные среды и секреты создания докеров, прочитанные из файла Django settings.py, и это работает. Недостатком является то, что переменные среды ограничены простыми строками и могут создавать некоторые проблемы с уходом при отправке списков Python, словарей и т. д. Мы также должны определять и поддерживать множество переменных среды, поскольку наше веб-приложение установлено во многих местах и ​​имеет широкие возможности настройки. .

На стороне внешнего интерфейса (AngularJS) у нас есть два файла constants.js и файл конфигурации nginx. Я использовал CMD ["/start.sh"] в Dockerfile и имею несколько команд sed. Но это выглядит очень хакерским, и это также означает, что мы должны определить и поддерживать довольно много переменных среды.

  1. Хорошо ли использовать тома Docker для этих файлов конфигурации?

  2. Существует ли на самом деле такое понятие, как "файл тома" (упомянутый здесь) или это на самом деле привязка? А монтирование с привязкой менее рекомендуется, поскольку оно зависит от файловой системы и пути к файлу на хосте.

документация Volumes кратко упоминает files: «путь, по которому файл или каталог монтируются в контейнере», но не вдается в подробности.

Наше веб-приложение теперь имеет простые файлы конфигурации:

  • settings.py
  • site\contants.js
  • admin\constants.js

и:

  1. Я хочу избежать перемещения этих файлов в выделенные каталоги, которые можно смонтировать.

  2. Можете ли вы показать мне образец файла docker-compose.yml с томами из одного файла (без привязки).

Спасибо


django docker docker-compose volumes
person waverider    schedule 14.04.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Если вы не можете использовать переменные среды, вам следует использовать привязку. Если вы используете именованный том, вы не можете получить доступ к отдельным файлам и не можете напрямую редактировать файлы конфигурации.

Именованный том всегда является целым каталогом, и к нему нельзя получить прямой доступ с хоста. Не существует такого понятия, как «файл тома» (ваш связанный вопрос полностью касается монтирования привязки, некоторые из которых используют синтаксис именованного тома), и нет способа смонтировать один файл из именованного тома.

Более новый Docker имеет несколько различных синтаксисов для монтирования привязки (в Compose короткая и длинная volumes: конфигурация службы , или создание именованного тома type: bind). Все они в основном эквивалентны, и многие ответы на вопрос, на который вы ссылаетесь, включают создание именованного тома, имитирующего привязку монтирования.

Docker Compose поддерживает относительные пути, поэтому гораздо меньше беспокойства по поводу того, что пути хоста для монтирования привязки не переносимы между системами. Базовый фрагмент файла docker-compose.yml может включать:

services:
  app:
    build: django
    volumes:
      - ./config/django-settings.py:/app/settings.py

В этом примере я бы предложил каталог config (время развертывания), содержащий файлы конфигурации, но это произвольный выбор; если вы хотите привязать ./django/settings.py из исходного дерева приложения к тому, что находится в образе, чтобы иметь возможность напрямую редактировать его, это тоже правильный выбор. Вы можете зарегистрировать это дерево в системе управления версиями, и оно все равно будет работать независимо от того, где оно извлечено.

Если вы используете базовый образ с полным набором инструментов GNU (Ubuntu, а не Alpine), то ваш скрипт точки входа в контейнер также может использовать envsubst в качестве очень легкого инструмента для создания шаблонов (он заменяет $VARIABLE ссылок на эквивалентную переменную среды), который поможет вам поддерживать случай "много вариантов", но не случай «опций типа dict».

В общем, я бы порекомендовал привязать монтирование в двух случаях и, возможно, в третьем: для файлов конфигурации (где оператору нужно их напрямую редактировать), для файлов журнала (где оператору нужно их напрямую читать) и, возможно, для постоянного хранения данных ( где ваше существующее решение для резервного копирования будет работать без изменений, но не в MacOS, где оно очень медленное). Именованные тома могут хорошо подходить для случая с постоянными данными и лучше соответствовать тому, что вы будете использовать в кластерной среде (Swarm, Kubernetes), но к ним нельзя получить прямой доступ.

person David Maze    schedule 14.04.2020