n1ro°
RU

Текст и данные · Инструкция

Как посмотреть размер контейнера Docker через inspect --size

Размер контейнера Docker через inspect --size состоит из двух показателей, которые легко перепутать. SizeRw — объём файлов, созданных или изменённых в writable layer относительно образа; SizeRootFs — суммарный размер файлов root filesystem контейнера. Эти поля не заменяют измерение named volumes и bind mounts, потому что внешние mount-данные живут отдельно.

Редакция N1RO · Проверено

Короткий ответ

Запустите docker inspect --size <container>. Docker добавит SizeRw — размер изменяемого слоя контейнера — и SizeRootFs — общий размер файлов его root filesystem; volumes в эти числа нужно оценивать отдельно.

Docker inspect --size: ключевой принцип

Флаг --size работает для контейнеров и поддерживает как запущенные, так и остановленные экземпляры. SizeRootFs показывает общий размер файлов root filesystem контейнера в байтах. SizeRw отражает изменения в writable layer конкретного контейнера поверх образа.

Важно: Флаг --size работает для контейнеров и поддерживает как запущенные, так и остановленные экземпляры.

Sizerw docker: ограничения и ошибки

Named volumes и bind mounts являются отдельными mount-источниками, поэтому их место нельзя корректно оценивать только по SizeRw. Большой SizeRw часто означает, что приложение пишет логи, кэш, загрузки или базу прямо в writable layer вместо отдельного volume. Для общего анализа места полезно сопоставлять inspect --size с docker system df и inspect Mounts. В связанных материалах и настройках встречаются также термины: размер writable layer, docker container disk usage.

Предупреждение: Для общего анализа места полезно сопоставлять inspect --size с docker system df и inspect Mounts.

Порядок действий

  1. Выполните docker inspect --size <container> и найдите SizeRw и SizeRootFs.
  2. Сравните SizeRw у контейнеров одного сервиса, чтобы заметить аномальный рост.
  3. Через docker inspect проверьте Mounts и выясните, какие данные вынесены в volumes или bind mounts.
  4. Найдите внутри контейнера каталоги, которые растут, и решите, должны ли они быть persistent или временными.
  5. После изменения архитектуры повторите измерение и убедитесь, что writable layer больше не растёт бесконтрольно.

Совет: Выполните docker inspect --size <container> и найдите SizeRw и SizeRootFs.

Контроль перед завершением

  • Команда запущена с --size для container.
  • SizeRw интерпретируется как writable layer.
  • Volumes и bind mounts измеряются отдельно.

Практический нюанс

Опция --size работает и для остановленных контейнеров, но только для типа container. Для image или volume используйте соответствующие команды и метрики, а не ждите полей SizeRw/SizeRootFs.

Что проверить в реальном сценарии

Для оценки диска проекта сложите картину из нескольких источников: writable layer контейнера, image layers и отдельных volumes. `SizeRw` полезен для поиска разросшегося слоя, но не заменяет `docker system df` или отдельный анализ томов.

Как убедиться, что задача решена

Снимите docker inspect --size до и после создания тестового файла внутри writable layer: SizeRw должен увеличиться. Затем запишите тот же объём в mounted volume и сравните — это покажет, почему поле не является размером всех данных приложения. Для оценки дискового потребления проекта отдельно смотрят images, writable layers и volumes; смешивать их в один SizeRootFs нельзя.

Важно: После исправления есть повторное измерение

Что учитывать

Named volumes и bind mounts являются отдельными mount-источниками, поэтому их место нельзя корректно оценивать только по SizeRw. Большой SizeRw часто означает, что приложение пишет логи, кэш, загрузки или базу прямо в writable layer вместо отдельного volume. Для общего анализа места полезно сопоставлять inspect --size с docker system df и inspect Mounts. В связанных материалах и настройках встречаются также термины: размер writable layer, docker container disk usage.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. docker inspect). Пример и формулировки — редакция N1RO на 2026-09-23.