Почему данные в контейнере эфемерны

Куда деваются данные после удаления контейнера и почему это так работает.

Эфемерность — записываемый слой контейнера существует только пока существует контейнер; вместе с docker rm данные пропадают.

Где контейнер хранит изменения

Образ — только для чтения. Когда вы запускаете контейнер, поверх образа добавляется тонкий записываемый слой: всё, что приложение создаёт во время работы (файлы, записи в БД), попадает в него. Этот слой принадлежит конкретному контейнеру.

Проблема: контейнер удалён — данные исчезли

Поскольку записываемый слой живёт вместе с контейнером, при docker rm он удаляется, и все изменения теряются. Проверим на примере с PostgreSQL:

# Запустили базу, создали таблицы, налили данные
docker run -d --name db -e POSTGRES_PASSWORD=secret postgres:16

# ...поработали, потом удалили контейнер
docker rm -f db

# Запустили снова — база абсолютно пустая
docker run -d --name db -e POSTGRES_PASSWORD=secret postgres:16

Все таблицы и записи исчезли вместе со старым контейнером. Для базы данных это, очевидно, неприемлемо.

Когда эфемерность — это хорошо

Не всегда исчезновение данных — проблема. Для stateless-сервисов (например, веб-сервер, который не хранит состояние) эфемерность — преимущество: контейнер можно в любой момент пересоздать из образа, и он будет чистым и предсказуемым. Именно на этом строится масштабирование и обновление сервисов.

Решение: выносить данные наружу

Данные, которые должны пережить контейнер, выносят за его пределы — в тома (volumes) или через монтирование папок хоста (bind mounts). Тогда контейнер можно удалять и пересоздавать, а данные останутся на месте.

Итог

• Изменения контейнера живут в записываемом слое, который исчезает вместе с контейнером.
• Для stateless-сервисов эфемерность удобна, для баз данных — недопустима.
• Долгоживущие данные выносят в тома или монтируют с хоста.