Пошук уроків, статей та іншого контенту
Чому файлова система контейнера тимчасова — і як зробити дані, що переживають видалення контейнера.
Як розібрано в уроці про images та containers, зміни, зроблені контейнером у власному змінюваному шарі, зникають при видаленні контейнера. Для бази даних це критично: якщо PostgreSQL, що працює в контейнері, зберігає файли даних у звичайному змінюваному шарі контейнера, видалення чи перестворення цього контейнера (типова операція під час оновлення образу) знищить усі накопичені дані.
Volume — область зберігання даних, керована Docker окремо від файлової системи конкретного контейнера. Дані у volume переживають видалення контейнера, який ним користувався, і можуть бути підключені до нового контейнера замість утраченого:
docker volume create pgdata
docker run -d --name my-postgres -v pgdata:/var/lib/postgresql/data postgres:16
# Навіть після:
docker rm -f my-postgres
# Дані все ще існують у volume "pgdata" і доступні наступному контейнеру:
docker run -d --name my-postgres-2 -v pgdata:/var/lib/postgresql/data postgres:16Named volume (-v pgdata:/шлях) — Docker сам керує фізичним розташуванням даних на диску хоста; практично завжди правильний вибір для даних застосунку (бази даних, завантажені файли).
Bind mount (-v /конкретний/шлях/на/хості:/шлях/у/контейнері) — прямо підключає конкретну папку хоста всередину контейнера; типовий випадок використання — підключити вихідний код проєкту в контейнер під час локальної розробки, щоб зміни файлів на хості одразу відображались усередині контейнера без пересборки образу.
# Named volume — для персистентних даних застосунку
docker run -v pgdata:/var/lib/postgresql/data postgres:16
# Bind mount — для локальної розробки, живе відображення коду з хоста
docker run -v $(pwd)/src:/app/src my-dev-imageБез жодного volume дані контейнера з базою даних живуть лише всередині тимчасового шару контейнера — на практиці це означає, що вони зникають при найближчому docker rm чи навіть перезапуску контейнера з новим образом. Для будь-яких даних, що мають пережити конкретний запущений контейнер, volume не опціональний — обов'язковий.
Запускати контейнер бази даних без volume — усі накопичені дані втрачаються при видаленні чи заміні контейнера.
Плутати named volume з bind mount там, де потрібна саме персистентність даних застосунку (а не живе відображення коду хоста), — bind mount прив'язаний до конкретного шляху на конкретній машині, що менш переносно між середовищами.
Видаляти volume (docker volume rm) не усвідомлюючи, що це остаточно знищує всі дані в ньому, — на відміну від видалення самого контейнера, який лишає volume недоторканим.
Файлова система контейнера тимчасова й зникає разом із контейнером — volume дає окреме, незалежне від життєвого циклу контейнера сховище даних. Named volumes (керовані Docker) — типовий вибір для персистентних даних застосунку (бази даних); bind mounts (пряме підключення папки хоста) — типово для локальної розробки, коли потрібне живе відображення коду.