# Docker на Mac — проблема с диском и сборкой образов

_Последнее обновление: 2026-06-30_

## Сетап

| Параметр | Значение |
|----------|----------|
| Движок | Colima (не Docker Desktop!) |
| Гипервизор | macOS Virtualization.Framework |
| Архитектура | arm64 |
| CPU | **8 ядер** |
| RAM | **24 GiB** |
| Диск VM | **100 GiB** (sparse) |
| Mount type | virtiofs |

## Проблема: контейнеры (особенно Zulip) зависают во время сборки Docker образов для Валеры

**Симптом:** Zulip перестаёт отвечать на вебхуки, RabbitMQ паникует, PostgreSQL тормозит.

## 🔴 Реальный корень — переполнение диска VM (не CPU, не bind mount)

### Структура диска Colima VM

`/dev/vdb1` (98 GiB, data disk) хранит `/var/lib/docker`:

```
17 GB — /var/lib/docker (Colima data)
├── 8.2 GB — rootfs/overlayfs        ← слои всех образов
├── 8.9 GB — volumes
│   ├── 8.4 GB — buildx_buildkit_arm64builder0_state   ← 🔴 build cache volume
│   ├── 341 MB — zulip_zulip-pgdata
│   ├── 85 MB — dangling volume
│   ├── 46 MB — openclaw_postgres-data
│   └── 38 MB — zulip_zulip-data
└── остальное — containers, buildkit metadata
```

### Build cache volume — 8.4 GB и не чистится сам

Docker BuildKit при использовании `buildx` хранит кеш слоёв в **Docker volume**, а не в overlayfs. Это volume `buildx_buildkit_arm64builder0_state`.

**Почему не чистится:**
- `docker system prune` чистит только build cache records (метаданные), НЕ volume
- BuildKit контейнер (`moby/buildkit:buildx-stable-1`) всегда running — volume считается активным
- BuildKit GC policy не видит этот volume как «своё» хранилище (это Docker volume, не `/var/lib/buildkit`)
- Без ручной очистки volume растёт с каждой сборкой и не уменьшается

**Почему аффектит контейнеры:**
1. Каждая сборка Валеры добавляет новые слои в этот volume
2. Volume растёт (8.4 GB и выше)
3. Когда `/dev/vdb1` заполняется >85-90%:
   - Docker overlayfs + containerd snapshotter начинают тормозить
   - Запись новых слоёв фейлится или идёт в разы медленнее
   - PostgreSQL и RabbitMQ WAL не могут закоммититься
   - RabbitMQ Khepri (Raft) при проблемах с WAL сбрасывает состояние (пользователи пропадают)
   - Zulip отдаёт 500 на `/api/v1/register`
   - Контейнеры тупят или падают в restart loop

### Чистка build cache (безопасно — не трогает образы, контейнеры, volumes)

**`docker builder prune --all --force`** — удаляет только временный build cache (промежуточные слои сборок). Не затрагивает:
- Образы (SDK, libs, рантаймы) — `docker images` не меняется
- Контейнеры (запущенные и остановленные)
- Volumes (включая БД)
- Networks

```bash
# Полная очистка build cache
docker builder prune --all --force
```

При следующей сборке: если образ уже собран и его слои есть в overlayfs, BuildKit пересоберёт только то, что изменилось в Dockerfile. Базовые `apt-get install` / `pip install` придётся перевыполнить, если их слой был закэширован.

**Щадящая чистка** (оставляет свежий кэш <24h):
```bash
docker builder prune --filter 'until=24h' --force
```
Не полностью решает проблему — volume фрагментирован, место не reclaim-ится.

### Чистка build cache volume (агрессивно — перекачка с нуля)


```bash
# Остановить buildkit контейнер, удалить volume, BuildKit пересоздаст при следующем билде
docker rm -f buildx_buildkit_arm64builder0
docker volume rm buildx_buildkit_arm64builder0_state
```

Мониторинг заполненности диска VM:

```bash
colima ssh -- df -h /dev/vdb1
```

### Связанные документы
- [[tech/docker_colima_setup]] — установка и автостарт Colima
- [[projects/balda/setup]] — Balda агенты (Валера, Клавдий)
- [[how-to/hermes-eagle-mac]] — Hermes на Mac, Zulip Docker стек (RabbitMQ pitfall про Khepri)
- [[how-to/openmediavault-rpi5]] — build cache на RPi (та же проблема ENOSPC)

## Apple Container — потенциальная замена Colima

Apple Container (`apple/container`, Apache 2.0, v1.0.0, Jun 9 2026) — нативная Swift-утилита для Linux контейнеров на macOS 26. **VM-per-container** через Virtualization.framework (не shared-kernel). OCI-совместима, pull/push с любых registry.

**Не заменяет Colima сейчас** — нет compose, нет buildx. При появлении compose-аналога может решить проблему build cache принципиально (архитектура VM-per-container не имеет одного volume, где всё гниёт).

Пока — следить за релизами. [[personal/documents/deferred-tasks]]