Docker и место на диске Mac: что на самом деле его съедает

Docker на Mac редко занимает много места сразу. Он растёт слоями.

Сначала один образ, один проект, один том с базой данных, один остановленный контейнер, один кэш сборки, который вы собирались почистить «позже». Потом место заканчивается, Docker Desktop выглядит подозрительно, и стандартный вывод расплывчат, но эмоционально убедителен: «Docker съедает мой диск».

Направление верное, но слишком неточное, чтобы быть полезным. Реальная проблема обычно не «Docker в целом». Это накопление образов, слоёв, кэша сборки, остановленных контейнеров, томов и данных времени выполнения, которые никто не рассматривал как единую систему.

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

Почему Docker незаметно разрастается на Mac

Docker устроен так, чтобы сохранять полезное состояние, пока вы явно не скажете ему иначе. Документация Docker описывает очистку как консервативную: неиспользуемые образы, контейнеры, тома и сети обычно не удаляются, пока вы не попросите.

Это удобно для рабочих процессов разработчика и именно поэтому место на диске постепенно уходит.

На Mac картина кажется ещё менее очевидной, потому что Docker Desktop хранит Linux-контейнеры и образы в одном большом файле дискового образа. Хост может показывать один большой след Docker, а реальные причины скрыты внутри нескольких слоёв данных времени выполнения.

Паттерн роста обычно представляет собой комбинацию:

• загруженных и пересобранных образов из нескольких проектов;
• общих слоёв, используемых разными тегами и версиями;
• остановленных контейнеров, которые всё ещё хранят записываемые слои;
• томов с базами данных, загруженными файлами или локальным состоянием сервисов;
• кэша сборки, который ускоряет сборки, пока не становится слишком дорогим;
• висячих объектов, оставшихся после пересборок и перетегирований.

Результат — след, который растёт незаметно, потому что каждое отдельное добавление кажется нормальным.

Где Docker хранит данные на Mac?

На Mac Docker не разбрасывает файлы по диску, как это делает нативное приложение. Docker Desktop запускает Linux в виртуальной машине и держит почти всё — образы, контейнеры и тома — внутри одного большого файла образа диска.

По умолчанию этот файл лежит примерно здесь:

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Точный путь может меняться от версии к версии Docker Desktop, но идея постоянна: один управляемый файл держит весь Linux-след. Поэтому один Docker.raw показывается в Finder как десятки гигабайт, даже когда большая часть этого объёма возвращаема или отражает лишь максимальный размер, до которого образу разрешено расти.

Из такого устройства следуют две вещи:

• Размер в Finder вводит в заблуждение. Инструменты хоста часто показывают максимальный размер образа диска, а не место, которое Docker реально занимает внутри.
• Не трогайте Docker.raw напрямую. Собственная документация Docker для Mac предупреждает: не перемещайте и не удаляйте образ диска через Finder, иначе Docker Desktop может потерять его из виду. Место возвращают через Docker, а не через файловую систему.

Что на самом деле занимает место Docker на Mac

Если нужен полезный план очистки, разделите след Docker на категории, а не рассматривайте его как один большой чёрный ящик.

Вот почему универсальный подход «самая большая папка» слабо работает для Docker. Один и тот же общий размер может означать совершенно разные решения по очистке в зависимости от того, является ли пространство в основном кэшем сборки или реальными данными томов.

Образы Docker и общие слои

Образы — часто первое, о чём думают разработчики, но более глубокая история в слоях. Машина с несколькими языковыми средами, локальными CI-подобными сборками и множеством микросервисов может быстро накопить много общих и уникальных слоёв.

Поэтому использование диска не всегда точно соответствует списку образов, которые вы помните.

Кэш сборки Docker

Кэш сборки — одна из самых распространённых скрытых причин на активных машинах разработчиков. Он существует, чтобы ускорить будущие сборки, а значит, остаётся, пока вы его не очистите. Это также означает, что его удаление — компромисс производительности, а не бесплатный выигрыш.

Остановленные контейнеры Docker

Разработчики постоянно недооценивают этот пункт. Контейнер, который не запущен, всё равно является объектом хранилища. Если он существует, он может занимать место.

Тома Docker

Тома — где риск возрастает. Они могут содержать данные, которые вам действительно важны: базы данных, зеркала пакетов, загрузки, поисковые индексы, содержимое локальных реестров или состояние сервисов.

В этом разница между очисткой Docker и обычной очисткой кэша. Часть хранилища Docker можно пересоздать. Часть — это ваше окружение.

Висячие образы и объекты Docker

Висячие объекты — часто самые безопасные кандидаты на очистку. Документация Docker определяет висячие образы как образы без тега, на которые не ссылается ни один контейнер. Это именно тот тип накопления, который растёт при обычной итеративной работе.

Как проверить использование диска Docker на Mac

Лучший первый шаг — не Finder. Нужно посмотреть, что сам демон Docker считает потребляющим пространство.

Рекомендация Docker для Mac начинается с docker system df -v, который показывает использование образов, контейнеров, локальных томов и освобождаемого пространства. Это самый быстрый способ перестать угадывать.

Используйте такой порядок:

1. Начните с docker system df -v

Это лучшая первая сводка, потому что она показывает:

• общее и освобождаемое использование образов;
• использование контейнерами;
• использование локальных томов;
• более подробную разбивку при использовании флага verbose.

Если освобождаемое пространство невелико, массовая очистка вряд ли сильно поможет.

2. Проверьте остановленные контейнеры перед очисткой

Проверьте, есть ли много завершённых контейнеров, которые уже никому не нужны. Они часто безопаснее для очистки, чем тома или активное состояние среды выполнения.

3. Проверьте образы отдельно от кэша сборки

Образы и кэш сборки решают разные задачи. Если кэш — главный нарушитель, целевая очистка кэша обычно лучше, чем полный сброс всего, чем владеет Docker.

4. Проверьте тома перед чем-либо, что использует --volumes

Именно этот шаг пропускают и потом жалеют. Том может выглядеть отсоединённым от работающего контейнера, но всё равно содержать реальные локальные данные проекта, который вы планируете запустить завтра.

5. Проверьте дисковый образ Docker Desktop на стороне Mac

FAQ Docker для Mac отмечает, что Docker Desktop хранит Linux-контейнеры и образы в одном файле дискового образа и что некоторые инструменты показывают максимальный размер файла, а не реальный потреблённый размер. Это важно, потому что пугающее число на стороне хоста — не всегда то же самое, что сразу освобождаемый мусор.

Перед тем как что-то чистить

Быстрые команды для проверки Docker

Эти команды полезны перед любым удалением:

docker system df -v
docker ps -a --size
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'
docker volume ls

Используйте их, чтобы подтвердить, что реально можно освободить, прежде чем выбирать масштаб очистки.

Как освободить место Docker на Mac

Когда docker system df -v показал, что действительно возвращаемо, освобождайте место самым узким способом, который решает задачу, а не одним широким проходом:

# удалить остановленные контейнеры
docker container prune

# удалить кэш сборки (BuildKit)
docker builder prune

# удалить висячие (без тегов) образы
docker image prune

# удалить неиспользуемые тома - только после проверки, что нужных данных в них нет
docker volume prune

Если нужно, чтобы Docker убрал несколько типов объектов сразу, docker system prune за один шаг разбирается с остановленными контейнерами, неиспользуемыми сетями, висячими образами и неиспользуемым кэшем сборки. Флаг -a добавит образы, не используемые ни одним контейнером, а --volumes — только когда вы уверены, что ни в одном томе нет настоящих данных.

Место возвращает и сам Docker Desktop: в Settings → Resources можно изменить или уменьшить размер виртуального диска, а Troubleshoot → Clean / Purge data — более тяжёлый сброс. Оба пути остаются внутри рабочего процесса Docker, что безопаснее, чем трогать Docker.raw руками.

Размен всегда один и тот же: очистка кэша и образов стоит вам более медленных следующих сборок и повторных загрузок, но не исходного кода, а очистка томов может унести настоящие локальные данные — с этой областью нужно больше всего осторожности.

Почему удалять папки Docker напрямую — рискованно

Прямое удаление кажется привлекательным, потому что выглядит решительно. Это также способ превратить очистку Docker в рулетку.

Две причины.

Во-первых, Docker отслеживает состояние и метаданные. Когда вы удаляете файлы вне рабочего процесса Docker, вы рискуете нарушить связь между тем, что среда выполнения считает существующим, и тем, что реально на диске.

Во-вторых, на Mac след Docker привязан к дисковому образу и хранилищу Docker Desktop. Документация Docker для Mac прямо предупреждает не перемещать дисковый образ напрямую в Finder, потому что Docker Desktop может потерять его. Тот же урок применяется к удалению файлов внутри хранилища Docker: действия через Docker безопаснее, чем угадывание на уровне файловой системы.

Это также причина, по которой удаление файлов внутри работающего контейнера — не то же самое, что освобождение места на хосте. Документация Docker для Mac отмечает, что место на хосте освобождается при удалении образов, а не автоматически при исчезновении файлов внутри работающих контейнеров.

Когда prune помогает

prune полезен, когда вы уже понимаете след и хотите, чтобы Docker удалил объекты, которые считает неиспользуемыми.

Основные случаи:

• docker system prune — когда накопились остановленные контейнеры, неиспользуемые сети, висячие образы и неиспользованный кэш сборки;
• docker builder prune — когда кэш сборки — реальная проблема;
• docker volume prune — когда вы убедились, что неиспользуемые тома действительно одноразовые;
• очистка с фильтром по времени или меткам — когда нужно сузить масштаб, а не подчищать всё.

Здесь очистка через Docker явно лучше прямого удаления файлов. Среда выполнения понимает типы объектов. Finder — нет.

Когда docker system prune опасен

Опасность не в том, что prune плох. Опасность в том, что «неиспользуемый» в Docker всё ещё может означать «важный для моего рабочего процесса».

Будьте осторожны, когда:

• остановленный контейнер является частью локального окружения, которое вы планируете возобновить;
• следующая сборка требует кэша, который вы собираетесь удалить;
• локальные тома содержат данные базы данных или сервисов, которые вам ещё нужны;
• docker system prune -a удалит образы, которые не запущены сейчас, но всё ещё являются частью активной работы;
• вы собираетесь добавить очистку томов без предварительной проверки, что эти тома содержат.

Документация Docker прямо указывает, что тома не удаляются автоматически, потому что это может уничтожить данные. Это правильная ментальная модель: к томам нужно относиться с большим подозрением, чем к образам или висячему кэшу.

Как понять последствия до очистки

Перед любой очисткой ответьте на вопрос простым языком:

Что мне придётся пересобрать, перезагрузить, восстановить или пересоздать после этого?

Этот вопрос полезнее, чем «Сколько я могу удалить?»

Для Docker практическая проверка обычно выглядит так:

1. Основной след — это образы, кэш сборки, остановленные контейнеры или тома?
2. Являются ли работающие контейнеры частью плана, или для очистки их нужно остановить?
3. Если я очищу кэш, меня устраивает более медленная пересборка или перезагрузка образов?
4. Если я очищу тома, какие данные сервисов исчезнут вместе с ними?
5. Я использую очистку Docker для решения реальной проблемы с освобождаемым пространством или реагирую на один большой непрозрачный дисковый образ?

Это разница между контролируемой очисткой разработчика и случайной паникой из-за хранилища.

Почему очистка для разработчиков отличается от обычной очистки файлов

Обычная очистка файлов спрашивает: «Какая папка большая?»

Очистка Docker требует других вопросов:

• это перестраиваемый кэш или постоянные данные сервисов;
• среда выполнения помечает это как освобождаемое;
• должна ли очистка происходить через команды Docker, а не удаление файлов;
• являются ли работающие, остановленные контейнеры или тома частью модели последствий;
• нужен ли мне управляемый обзор до применения рискованного пути очистки?

Вот почему Docker принадлежит к процессу, учитывающему контейнеры, а не к той же категории, что и удаление загрузок или очистка обычной папки кэша.

Где StorageRadar помогает

Это важно, потому что Docker — не просто «одна большая папка». Это экосистема типов объектов с разными последствиями очистки.

Если проблема в кэше сборки, ваши действия отличаются от машины с тяжёлыми томами. Если работающие контейнеры нужно сначала остановить, это должно быть видно до очистки. Если профиль рискованный, процесс должен намеренно замедлить вас.

Чего не следует делать

Избегайте этих распространённых ошибок:

• не относитесь к каждому большому следу Docker как к одной проблеме с одним решением;
• не запускайте прямой rm -rf внутри директорий Docker только потому, что они выглядят большими;
• не предполагайте, что большой дисковый образ Docker Desktop означает, что всё это пространство можно безопасно освободить прямо сейчас;
• не добавляйте очистку томов случайно, если не проверили, что они содержат;
• не используйте массовый prune прямо перед демо, релизом или пересборкой локального окружения, которую вы не можете себе позволить.

Если Docker — лишь часть более широкой проблемы хранилища на машине разработчика, сопутствующее руководство Xcode DerivedData занимает слишком много места на Mac будет полезным следующим чтением.

Заключение

Использование диска Docker на Mac обычно перестаёт быть загадочным, как только вы разделите его на правильные категории. Крупнейшие источники — образы, слои, кэш сборки, остановленные контейнеры, тома, висячие объекты и хранилище Docker Desktop.

Безопасный подход — сначала проверить след, разделить перестраиваемые артефакты от постоянных данных и использовать очистку через Docker только после понимания последствий.