Данные в контейнерах
Вопрос
Как организуешь хранение данных для сервисов в Docker на одном сервере: база, загрузки пользователей, конфиги, логи?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
База: именованный том, бэкап средствами СУБД (дамп или физический бэкап), не копия файлов на ходу
Загрузки: том или внешнее объектное хранилище (S3), если сервисов несколько
Конфиги: bind mount только для чтения или переменные окружения, секреты отдельно
Логи: в stdout/stderr, драйвер логов с ротацией (`max-size`, `max-file`), а не файлы в контейнере
Права и UID: процесс не от root, владелец каталогов совпадает
Понимать, что `down -v` и `volume prune` удаляют данные, бэкапы проверять восстановлением
Что могут спросить следом
- Почему не стоит копировать файлы работающей базы?
- Как ограничить рост логов Docker?
Разбор
Базу кладу в именованный том: он переживает пересоздание контейнера и обновление образа. Бэкап делаю средствами СУБД, pg_dump по расписанию или физический бэкап с WAL, потому что копия файлов работающей базы может быть неконсистентной. И проверяю восстановление, иначе это не бэкап. Пользовательские загрузки на одном сервере можно держать в томе, но если сервисов станет несколько, лучше сразу объектное хранилище. Конфиги монтирую bind mount с :ro или передаю переменными окружения, секреты держу вне образа и репозитория. Логи приложение пишет в stdout, а у Docker настраиваю драйвер с ротацией: max-size и max-file в daemon.json, иначе json-логи съедят диск. Слежу за UID: процесс не от root, и каталоги тома принадлежат нужному пользователю. И отдельно помню, что docker compose down -v и docker volume prune удаляют данные, их нельзя запускать на проде машинально.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.