# Read-only контейнер не стартует: где разрешить запись tmp и cache

Диагностика: Read-only контейнер не стартует: где разрешить запись tmp и cache. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/read-only-container-writable-caches/
Language: ru

Read-only root filesystem может выявить скрытую запись в /tmp, cache, PID file или домашний каталог. Найдите конкретный путь и владельца операции. Разрешайте запись отдельным ограниченным mount, сохраняя основной root filesystem неизменяемым, вместо снятия ограничения целиком.

## Сохраните первую ошибку записи

Запишите path, operation, UID/GID и момент старта, когда появляется отказ. Отличите EROFS от обычного permission denied: read-only mount и неверное ownership имеют разные исправления. Проверьте effective securityContext и mounts после admission, а не только Dockerfile. Приложение может писать уже при import библиотек или подготовке кеша, до своего основного рабочего цикла. Не делайте вывод о CUDA несовместимости, пока не выясните точную системную операцию и область файловой системы.


[Официальный источник 1](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).

## Разделите типы данных

Для временных файлов подходит ограниченный writable tmpfs или emptyDir с нужной политикой. Для долговечных артефактов требуется соответствующий persistent storage lifecycle. Секреты и доверенные входные файлы должны оставаться read-only, если программа не должна их менять. Docker tmpfs хранит временные данные и имеет свои ограничения, включая возможное взаимодействие с host swap. Memory-backed mounts расходуют системную память; размер writable area не заменяет общий memory budget процесса.


[Официальный источник 2](https://docs.docker.com/engine/storage/tmpfs/).

## Разберите минимальный старт

В учебном контейнере root filesystem read-only, а приложение пытается создать /run/worker.pid и /tmp/session. Подготовьте отдельные writable mounts с подходящими UID/GID и ограниченным размером. Затем повторите старт, не меняя остальное окружение. Если библиотека дополнительно пишет cache в home, найдите documented настройку пути или отдельный mount. Пример показывает карту операций записи, а не рекомендует конкретные кеши или параметры какого-либо LLM engine.

| Путь данных | Нужный вопрос |
| --- | --- |
| PID/runtime files | Нужна ли запись только на время процесса |
| Temporary data | Каков допустимый пик и cleanup |
| Cache | Можно ли безопасно пересоздать |
| Model/artifact input | Должен ли процесс менять содержимое |


[Официальный источник 3](https://docs.docker.com/reference/cli/docker/container/run/).

## Задайте минимальные права

Разрешите запись только в необходимые каталоги, учитывая ownership после mount. Read-write mount с неверным UID не решает доступ, а широкое chmod меняет другую границу. Для tmpfs рассмотрите доступные nosuid/nodev/noexec options согласно назначению: noexec может нарушить легитимный сценарий, если приложение действительно исполняет временные файлы. Не добавляйте его без проверки. Сохраните ожидаемый режим и размер каждого mount в декларативной конфигурации, чтобы ручной каталог не стал скрытым условием успешного запуска.

## Проверьте очистку и пересоздание

После обработки тестовых данных завершите процесс, создайте новый контейнер и подтвердите корректный старт без прежнего временного состояния. Проверьте отсутствие неожиданных записей в root и допустимый пик памяти. Артефакт содержит список путей, права, mount lifecycle и результат повторения. Успех означает известные writable boundaries, а не просто исчезновение сообщения об ошибке. После обновления образа повторите инвентаризацию: новая библиотека может добавить другой cache path, не меняя внешнюю команду запуска приложения.

Связанные разборы: [gpu containers vs vms](/ru/journal/gpu-containers-vs-vms/); [hardware security](/ru/journal/hardware-security/).