Теряются ли данные при остановке Docker контейнера
Что проверяют
Различаете ли вы остановку и удаление контейнера и понимаете ли, где физически живут данные. Вопрос выглядит простым, но ответ «да, теряются» сразу показывает, что человек работал с Docker только по чужим инструкциям.
Как отвечать
Нет. docker stop останавливает процесс, но сам контейнер остаётся вместе со своим записываемым слоем: docker start поднимет его, и записанные внутрь файлы будут на месте. Данные пропадают при docker rm, а также при пересоздании контейнера, что и происходит на docker compose up после смены образа или параметров.
Формулируйте через слои:
- образ это набор слоёв только для чтения, общий для всех контейнеров;
- у контейнера поверх есть тонкий записываемый слой, живущий ровно столько же, сколько сам контейнер;
- всё, что должно пережить пересоздание, выносится наружу.
Наружу это два механизма. Именованный том, docker run -v pgdata:/var/lib/postgresql/data postgres: данные лежат в области Docker, переживают удаление контейнера и удаляются отдельной командой. Bind mount, docker run -v /srv/data:/data image: каталог хоста монтируется внутрь, удобно для конфигов и разработки, но владелец и права файлов берутся с хоста, и процесс в контейнере часто упирается в отказ в доступе.
Стоит добавить, что тома тоже смертны: docker volume prune и docker system prune --volumes сносят всё, на что никто не ссылается, а compose именует тома с префиксом проекта, так что переименование каталога проекта равносильно потере базы.
Где спотыкаются
Смешивают остановку и удаление и отвечают, что данные теряются всегда. Дальше следует вопрос, почему же после docker start база на месте, и объяснения не находится.
Второе: считают, что -v это всегда том. Если слева указан путь, это bind mount с другой семантикой: именованный том при первом монтировании копирует в себя содержимое каталога из образа, а bind mount просто перекрывает его, и каталог внутри может оказаться пустым.
Третье: не думают про состояние внутри контейнера вообще. Положили дамп в /tmp и ушли, а при следующем деплое образ пересобрался, контейнер пересоздался, данных нет. Правило простое: если файл нужен завтра, ему не место в контейнере.