В этом материале
Read-only root filesystem может выявить скрытую запись в /tmp, cache, PID file или домашний каталог. Найдите конкретный путь и владельца операции. Разрешайте запись отдельным ограниченным mount, сохраняя основной root filesystem неизменяемым, вместо снятия ограничения целиком.
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 несовместимости, пока не выясните точную системную операцию и область файловой системы.
Разделите типы данных
Для временных файлов подходит ограниченный writable tmpfs или emptyDir с нужной политикой. Для долговечных артефактов требуется соответствующий persistent storage lifecycle. Секреты и доверенные входные файлы должны оставаться read-only, если программа не должна их менять. Docker tmpfs хранит временные данные и имеет свои ограничения, включая возможное взаимодействие с host swap. Memory-backed mounts расходуют системную память; размер writable area не заменяет общий memory budget процесса.
Разберите минимальный старт
В учебном контейнере 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 | Должен ли процесс менять содержимое |
Задайте минимальные права
Разрешите запись только в необходимые каталоги, учитывая 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; hardware security.