Понимание юзабилити томов

Question

Я пришел из старого мира монолитных приложений, которые записывают свои данные в базу данных или иногда используют некоторые файлы. Обычно при использовании файлов они хранятся в подкаталоге каталога приложения, например app / data.

Теперь в Docker существует понятие томов.

Я пытаюсь понять:

1. Когда мне следует использовать тома?
2. Зачем хранить мои файлы на томе, а не в подкаталоге каталога приложения, например app / data?
3. Нужно ли менять код приложения, чтобы записывать на том вместо приложения / данных, или если приложение размещено в Docker, тогда все файлы относительных путей будут автоматически сохраняться на подключенном томе?

Answer 1

Вы монтируете том в контейнер при запуске. Программа внутри контейнера не знает, использует ли она том или нет. Все, что вы читаете или пишете по пути тома, автоматически использует том.

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

Хорошее использование томов включает хранение локальных постоянных данных, которые необходимо хранить при перезапуске контейнера. Крепления хост-привязки очень похожи (ИМХО ими легче управлять, но на некоторых платформах есть проблемы с разрешениями и производительностью), и они также могут удовлетворить этот сценарий использования; Крепления host bind также хороши для внедрения файлов конфигурации в приложения и чтения файлов журнала обратно.

(По причинам, не связанным с Docker, может быть удобно хранить данные вне каталога вашего приложения, например, /var/lib/myapp. Это менее актуально в Docker, где вы обновляете свой код, создавая новый образ, начиная с новый контейнер, а затем монтирование тома поверх файловой системы. Не имеет значения, находятся ли ваши данные в каталоге вашего приложения или нет.)

---

Также вы пометили это как "Kubernetes". Все вышеперечисленное применимо и здесь (когда я говорю «увеличить», я довольно конкретно думаю о Kubernetes). Постоянные тома Kubernetes могут быть немного хитрее в использовании, чем именованные тома Docker; избегайте томов типа hostPath (они не будут одинаковыми для нескольких узлов). Возможно, вам придется использовать StatefulSets вместо Deployments, чтобы дать каждому Pod свой собственный PersistentVolume. Получить прямой доступ к содержимому PV еще сложнее, чем в Docker. И наоборот, существуют другие механизмы, такие как ConfigMaps для некоторых задач, таких как внедрение файлов конфигурации. Держитесь подальше от ориентированных на разработчиков шаблонов, которые пытаются связать код приложения в контейнеры, это гораздо сложнее, чем просто перестроить ваш образ, когда это необходимо.

Answer 2

1. Вам нужны тома для приложений с сохранением состояния, то есть для сохранения данных / состояния.

2. Вы по-прежнему можете использовать тот же путь к приложению / данным, ноубедитесь, что путь смонтирован на постоянном томе, чтобы данные сохранялись при исчезновении контейнера.Таким образом, вам не нужно много менять.

3. Нет, вам не нужно ничего менять, если вы монтируете приложение / данные как том.Приложение не должно знать об этом.Просто убедитесь, что приложение / данные - это том.