Docker Build Cache зайняв майже 30 GB: як я знайшла, що з'їло диск

Я просто хотіла локально запустити AVN Documentation AI, але замість звичайного Docker troubleshooting побачила значно цікавішу проблему: на диску майже не залишилося місця.

Filesystem дійшов до 99-100% використання, а в окремих замірах залишалося лише приблизно 1.4-3.5 GB вільного простору.

Коли я відкрила Docker statistics, найбільше мене здивував Build Cache: майже 29 GB.

Проблема проявилася не як Docker error про cache.

Я побачила звичайний системний симптом: filesystem майже повний.

Тому перша перевірка була не prune, а вимірювання.

Пізніше під час роботи available space падав ще нижче - приблизно до 1.4 GB, а filesystem показував 100% usage.

У такому стані вже немає сенсу навмання видаляти project files. Спочатку потрібно зрозуміти, хто саме займає місце.

Цей output одразу змінив напрямок troubleshooting.

Volumes займали близько 1 GB, тобто вони явно не були головною причиною.

Images займали понад 31 GB, але найбільш неочікуваним для мене був Build Cache майже 29 GB.

До цього моменту я сприймала Docker build cache як щось тимчасове і відносно невелике.

Насправді BuildKit може зберігати layers і build records між великою кількістю builds, щоб наступні збірки були швидшими.

Якщо Docker використовується щодня в кількох проєктах, cache може непомітно вирости до десятків гігабайтів.

Я не хотіла одразу використовувати максимально агресивне очищення.

Спочатку спробувала звичайне очищення unused build cache.

Але результат виявився значно меншим, ніж я очікувала.

Після цього Build Cache все ще залишався приблизно на рівні 28.33 GB, з яких близько 16.85 GB Docker продовжував показувати reclaimable.

docker builder prune за замовчуванням працює консервативніше і прибирає dangling build cache.

Але значна частина unused cache може все ще залишатися доступною для повторного використання.

Тому команда може відпрацювати успішно, а десятки гігабайтів усе одно залишаться на диску.

Перед наступним очищенням стан був уже критичним.

У зафіксованому snapshot було близько 1.4 GB available, а Build Cache виріс приблизно до 29.22 GB.

Тому я використала -a, але не хотіла бездумно знищувати весь cache.

Build Cache зменшився приблизно з 29.22 GB до 11.59 GB.

Це близько 17.6 GB build cache, які більше не займали диск.

А filesystem замість критичних 1.4 GB available вже показував приблизно 24 GB вільного місця.

• Кожен Docker build може створювати нові reusable layers.
• Зміни в Dockerfile або build context можуть invalidувати попередні layers.
• Dependency installation часто створює великі cached build stages.
• Робота з кількома проєктами накопичує cache незалежно для різних build graphs.
• Multi-stage builds можуть залишати cache для intermediate stages.
• BuildKit спеціально зберігає reusable data, тому швидкість build отримується ціною disk space.

Сам cache не є проблемою. Він існує саме для того, щоб Docker не повторював однакову роботу на кожному build.

Проблема починається тоді, коли вартість кешу на диску стає більшою за користь від прискорення build.

Я помітила проблему під час запуску AVN Documentation AI, але було б неправильно сказати, що саме цей проєкт сам створив усі 29 GB.

На машині вже існували інші Docker і Laradock environments, PHP versions, images та попередні builds.

Новий AI workflow просто довів disk usage до точки, де накопичення стало видимим.

Саме тому я не починала з docker system prune.

Коли docker system df уже показує, що головний кандидат - Build Cache, краще чистити конкретний resource type, а не все підряд.

• Не запускала б docker system prune -a автоматично, не подивившись docker system df.
• Не видаляла б volumes без перевірки їх content.
• Не припускала б, що найбільше місця завжди займають images.
• Не вважала б successful builder prune доказом, що cache тепер маленький.
• Не очищала б cache перед важливим build, якщо немає часу повторно завантажувати dependencies.
• Не плутала б Docker build cache з model cache або application cache.

Звільнені 17+ GB виглядають як безкоштовний виграш, але Docker cache існував не просто так.

Після aggressive prune наступний build може знову виконати dependency installation, compilation або download layers.

Я обміняла disk space на потенційно довший наступний build. У ситуації з filesystem на 100% це був правильний trade-off.

Docker був не єдиним cache на машині.

Для локального AI environment окремий model cache займав приблизно 2.3 GB.

Це ще раз показало, що Docker cache, model cache і project data потрібно вимірювати окремо, а не називати все просто "Docker займає диск".

До цього я вже багато працювала з Docker через Laradock, кількома PHP runtimes і private Composer dependencies.

Наприклад, окремо описувала multi-PHP workflow у Laradock та кейс із Composer, GitLab і Docker SSH agent.

Але саме цей випадок змусив мене додати до Docker workflow ще одну регулярну перевірку - disk usage.

• Спочатку перевірити filesystem через df -h.
• Подивитися Docker breakdown через docker system df.
• Визначити, що саме росте: images, build cache чи volumes.
• Починати з найбільш вузького cleanup command.
• Використовувати -a тільки коли розумію його scope.
• За можливості обмежувати aggressive cleanup filter за часом.
• Після cleanup повторити і df -h, і docker system df.
• Пам'ятати, що очищений cache може зробити наступний build повільнішим.

• Не чекати 99% disk usage, щоб подивитися docker system df.
• Вважати Build Cache повноцінним споживачем disk space.
• Не плутати reclaimable із автоматично safe-to-delete.
• Чистити конкретний Docker resource, якщо причина вже відома.
• Не торкатися volumes без окремої перевірки.
• Після aggressive prune очікувати повільніший cold build.
• Окремо контролювати AI model caches та інші non-Docker caches.

Docker Build Cache цілком реально може вирости до десятків гігабайтів.

У моєму випадку він наблизився до 30 GB, поки filesystem уже стояв на межі 100% usage.

docker system df допоміг відділити build cache від images і volumes, а контрольований docker builder prune -a --filter "until=168h" прибрав приблизно 17.6 GB старого unused cache.

Найважливіший урок для мене - не починати Docker cleanup із видалення. Спочатку виміряти, потім зрозуміти resource type, і тільки після цього чистити саме те, що справді створює проблему.