Stateful OverlayFS и персистентность данных
Как устроен механизм Stateful OverlayFS в microsrv: сохранение изменений корневой файловой системы на реплицируемом NVMe-диске.
Проблема эфемерности в Kubernetes и Docker
В традиционных средах контейнеризации (Kubernetes, Docker Swarm, Nomad) корневая файловая система контейнера является эфемерной (временной):
- Контейнер запускается на базе неизменяемого OCI-образа.
- Все созданные файлы, журналы логов, изменённые конфигурации и установленные системные пакеты записываются во временный слой на локальном диске конкретного сервера.
- При перезапуске контейнера, падении процесса или перепланировании пода на другой узел этот временный слой безвозвратно удаляется.
Для сохранения состояния разработчикам приходится подключать сетевые диски (Persistent Volumes / PVC) и гарантировать, что приложение пишет данные строго в выделенные точки монтирования (например, /var/lib/data).
Архитектура Stateful OverlayFS в microsrv
В платформе microsrv контейнеры изначально функционируют как полноценные сервисы с сохранением состояния. Корневая файловая система контейнера формируется через механизм Stateful OverlayFS, подключённый к персистентному распределённому диску (Volume) на базе NVMe:
1. ЕДИНАЯ КОРНЕВАЯ СИСТЕМА MERGED (/)
[ROOTFS] Контейнер видит стандартную файловую систему POSIX в корне / • Прозрачное объединение слоёв
Механика объединения слоёв:
- Нижний слой — Lowerdir (Read-Only): Неизменяемые слои OCI-образа контейнера, предварительно загруженные в кэш вычислительного узла.
- Верхний рабочий слой — Upperdir и Workdir (Read-Write): Размещаются непосредственно на первом подключённом томе (
volume_ids[0]). Любые операции создания, перезаписи файлов и их удаления (через маркеры whiteouts) фиксируются на персистентном реплицируемом блочном диске. - Объединённая файловая система — Merged View: Прозрачный для приложения корень
/, с которым взаимодействует песочница Sentry.
Что сохраняется на диске?
Благодаря Stateful OverlayFS сохраняются все изменения файловой системы без необходимости сложной настройки отдельных томов:
- Установленные пакеты и библиотеки: Команды
apt-get update && apt-get install -y ffmpegилиpip installможно выполнять прямо в работающем контейнере — изменения останутся после перезагрузки. - Встраиваемые и локальные базы данных: Файлы SQLite, DuckDB, RocksDB, LevelDB или данные PostgreSQL (
/var/lib/postgresql/data) сохраняются в полном объёме. - Конфигурационные файлы: Правки в
/etc/nginx/,/etc/environmentили.envфайлах не сбрасываются. - Кэши и пользовательские сессии: Внутренние кэши на диске переживают любые перезапуски и миграции между хостами.
[!IMPORTANT] При создании контейнера в microsrv подключение как минимум одного тома (
Volume) является обязательным условием, так как первый том выделяется под рабочий слойUpperdirStateful OverlayFS.
Сравнение моделей сохранения данных
| Сценарий | Kubernetes Pod | Контейнеры microsrv |
|---|---|---|
| Перезапуск после сбоя процесса | Корневая ФС сбрасывается к исходному образу | Все файлы и изменения в корне сохраняются |
| Остановка и запуск (Stop/Start) | Полное пересоздание пода с очисткой диска | Контейнер стартует с тем же состоянием диска |
| Живая миграция (Live Migration) | ❌ Не поддерживается | Диск атомарно перепривязывается к новому хосту |
| Аварийное отключение сервера | Под поднимается с чистой файловой системой | Холодный перезапуск с сохранением всех данных тома |
| Установка пакетов во время работы | Теряется при первом перезапуске | Сохраняется на диске навсегда |
Подключение дополнительных томов данных
Если вашему приложению требуются дополнительные разделы для хранения больших массивов данных, к контейнеру можно привязать несколько дисков:
- Создайте дополнительный диск в разделе Консоль → Диски.
- Укажите идентификаторы дисков в массиве
volume_idsпри создании или обновлении контейнера. - Дополнительные тома монтируются в песочницу и доступны приложению как изолированные накопители.