Apple Silicon, облачный Mac и Docker: arm64/amd64, bind mount, кеш сборки и лимиты тарифов

Ключевые выводы

Используйте docker buildx imagetools inspect и явный --platform, чтобы «pull» и «run» совпадали — без скрытых сюрпризов с amd64.
Bind mount на macOS ведёт себя иначе, чем на Linux: смотрите пути на хосте, пользователя по умолчанию и I/O при большом числе мелких файлов.
Кеш BuildKit и «висячие» образы конкурируют за SSD в рамках тарифа; включайте prune в runbook дежурства и оставляйте запас под macOS и логи.
Те же принципы бюджета памяти и диска применимы к параллельным CI-конвейерам: параллелизм и длина очереди должны укладываться в ту же модель, что и контейнеры.

Ноутбук с кодом на экране — метафора облачной сборки и контейнеров — Иллюстрация носит ориентировочный характер; устраняйте неполадки по реальным выводам `docker info`, манифестам образов и занятости диска.

1. Архитектура: arm64 по умолчанию и вкрапления amd64

На Apple Silicon Docker Desktop (или совместимая среда) часто разрешает не квалифицированные образы сначала к варианту arm64. Если в Dockerfile, Helm или compose по-прежнему закреплено FROM --platform=linux/amd64, либо upstream публикует только amd64, на рантайме вы получите exec format error — или обрыв производительности под эмуляцией QEMU. Производственная практика: фиксировать тройку платформы (например linux/arm64) в CI и compose, проверять манифесты сторонних образов и явно решать, допустимы ли зависимости только под x86 в эмуляции или их нужно пересобрать нативно в многоэтапном пайплайне arm64.

Если CI выпускает артефакты и arm64, и amd64, маркируйте их различимо и не вешайте один тег :latest на две архитектуры без ясной политики manifest list — откат становится двусмысленным, когда по истории не видно, какой digest был в проде.

2. Bind mount: пути, права и I/O

Монтирование каталогов хоста в контейнеры на облачных Mac даёт три знакомых класса сбоев, которые стоит дословно внести в плейбуки дежурства: отсутствующие пути или неверно разрешённые относительные пути под launchd; uid/gid внутри контейнера не совпадают с владельцем файлов на хосте — отсюда read-only или нестабильная запись; и огромные деревья мелких файлов (например node_modules или индексы LSP), усиливающие I/O через mount. Для долгоживущих сервисов отделяйте «логи, которые нужно grep» от «эфемерных деревьев сборки», фиксируйте абсолютные пути хоста в тикетах изменений и по возможности используйте именованные тома для состояния, которое нельзя потерять из-за ошибочного bind path.

Если контейнер поднимает launchd или cron на хосте, явно задайте WorkingDirectory и переменные среды в plist: иначе относительные пути в compose и в скриптах entrypoint разойдутся с тем, что вы проверяли в интерактивной оболочке. Для тяжёлых синхронизаций каталогов сравните задержку bind mount к домашнему каталогу и к отдельному тому под данные — в проде это часто окупается предсказуемым временем сборки.

3. Кеш сборки и границы SSD тарифа

Слои кеша BuildKit, накопление до docker builder prune и параллельные мультиархитектурные сборки расходуют локальный SSD. Публичные тарифы kvmboot ориентируются на 16 ГБ унифицированной памяти + 256 ГБ SSD и 24 ГБ + 512 ГБ (см. тарифы и характеристики). Операционно держите образы плюс кеш в бюджете, который после macOS, приложений и пары недель ротационных логов оставляет порядка 15–20% свободного места — при почти полном диске Docker часто даёт странные таймауты. Подключите docker system df -v и алерты диска хоста к тому же каналу, что и health сервисов.

Унифицированная память означает, что пики от перекрывающихся docker build, JVM или ML-сайдкаров делят один пул с кешем страниц ядра. На тарифе 16 ГБ ограничивайте параллелизм сборок в окнах релизов или смещайте тяжёлые сборки, чтобы интерактивные сессии и агенты мониторинга сохраняли запас.

# Примеры производственных проверок (на хосте)
docker buildx du
docker system df
df -h /

4. Симптом — причина — действие (краткий справочник)

Симптом	Вероятная причина	Предпочтительное действие
`exec format error`	Архитектура образа или бинарника не совпадает с траекторией на хосте	Проверить манифест; задать `platform:` в compose; не использовать случайно только amd64-базы
Пустой mount или permission denied	Неверный путь, владение или неинициализированный именованный том	Проверить путь хоста и uid; для долговременного состояния — именованные тома
Медленные сборки, алерты диска	Раздутый кеш, устаревшие образы	`docker builder prune` и дисциплина тегов; внешний диск только если это разрешено договором

5. Заключение

Считать облачный Mac с Docker «Linux с другой наклейкой» — дорого по времени: держите семантику платформы, поведение mount и дисковый бюджет на той же странице runbook, что и тарифные ОЗУ и SSD. После того как зафиксировали архитектуру и политику кеша, один раз проверьте холодную полную сборку — время холодного старта и пик памяти — до того, как понадобится экстренное увеличение ресурсов.