Ускоряем холодный старт облачного Mac mini через зеркала Homebrew и кэш зависимостей

Два часа ночи, вы только что арендовали за 9 долларов Mac mini M4 в гонконгском дата-центре, SSH-ключ прилетел на почту через пять минут. С энтузиазмом подключаетесь и первым делом вводите brew install node — и видите, как прогресс-бар замирает на скачивании bottle. Обновляете терминал, curl сообщает о таймауте, пробует переподключиться снова, проходит двадцать минут, а вы всё ещё ждёте tarball, который должен был скачаться за три секунды. Это не сбой сети — это обычная задержка при обращении к официальному CDN Homebrew из зарубежного дата-центра. И эта задержка повторяется каждый раз, когда вы поднимаете новый инстанс.

Сценарий: свежая машина в руках, а установка зависимостей съедает половину срока аренды

Плюс посуточной оплаты облачного Mac mini — включай и работай сразу; минус в том, что каждый новый инстанс — это чистый лист. Устанавливаете Xcode Command Line Tools, прогоняете командный setup.sh: обычный процесс включает установку кучи пакетов через brew install, кучи зависимостей через npm install, ещё раз подтягивание индекса CocoaPods через pod install — и все официальные источники смотрят на зарубежные серверы. Одна только скорость загрузки способна съесть время, эквивалентное дневной аренде всей машины. Если вы арендуете всего на день для разовой задачи, эти издержки особенно болезненны.

Почему официальные источники настолько медленны в облачных нодах

Bottle-пакеты (предкомпилированные бинарники) Homebrew по умолчанию хранятся в GitHub Packages, официальный реестр npm и репозиторий спецификаций CocoaPods также размещены на зарубежной инфраструктуре. У облачных провайдеров обычно достаточная международная полоса пропускания, но качество маршрутизации до конкретных узлов CDN сильно варьируется, особенно при первом установлении соединения — TLS-хэндшейк плюс DNS-резолвинг суммарно дают от десятков до сотен миллисекунд задержки. Умножьте это на несколько сотен пакетов зависимостей — получите ожидание на минуты, а иногда и на часы. Дело не в медленности вашей машины, а в медленности канала.

Три шага для построения переиспользуемого канала ускорения

Шаг первый: переключить репозиторий Homebrew и домен bottle

Сначала проверьте, уже ли текущий Homebrew указывает на доступное зеркало, затем единообразно измените переменные окружения — изменения вступят в силу после перезапуска сессии терминала:

git -C "$(brew --repo)" remote set-url origin \
  https://mirrors.example-mirror.net/homebrew-core.git
export HOMEBREW_API_DOMAIN="https://mirrors.example-mirror.net/homebrew-bottles/api"
export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.example-mirror.net/homebrew-bottles"
brew update

Впишите эти три строки в ~/.zprofile, чтобы не настраивать их повторно при следующей загрузке.

Шаг второй: зафиксировать список зависимостей через Brewfile

Не набирайте brew install по одной команде — впишите пакеты, которые использует команда, в Brewfile и установите всё одной командой bundle, сохраняя единообразие версий между разными нодами:

tap "homebrew/cask"
brew "node@20"
brew "cocoapods"
brew "watchman"
brew "git-lfs"
cask "visual-studio-code"

brew bundle --file=~/Brewfile

Brewfile сам занимает всего несколько десятков строк — храните его в репозитории кода, и на новой машине достаточно сделать git clone проекта и снова прогнать bundle. Это намного быстрее, чем искать команды установки по одной, и исключает риск пропустить какую-нибудь скрытую зависимость.

Шаг третий: настроить те же зеркала для языковых пакетных менеджеров

Ускорение Homebrew решает только часть проблемы — у npm, pip, CocoaPods свои источники по умолчанию, их нужно настраивать по отдельности:

npm config set registry https://registry.example-npm-mirror.com
pip config set global.index-url https://pypi.example-mirror.com/simple
pod repo-art add master https://cdn.example-cocoapods-mirror.com/master.git

После замены всех четырёх каналов разница во времени от распаковки зависимостей до первой успешной сборки на совершенно новом Mac mini выглядит наглядно:

Переход на зеркала — не бесплатный обед: зеркальные серверы синхронизируются с официальными репозиториями с задержкой от нескольких минут до нескольких часов. После обновления критичных версий рекомендуется сначала прогнать самодиагностику brew doctor, а затем проверить хэши ключевых bottle-пакетов через shasum -a 256, убедившись, что они совпадают с официальным релизом, прежде чем переходить в продакшен.

Сохраняем прогретое окружение как снапшот для повторного использования

Если вы планируете повторно арендовать ту же ноду по неделям или месяцам, канал ускорения можно улучшить ещё на шаг: после установки зависимостей и успешной сборки заархивируйте ~/Library/Caches/Homebrew, общие директории кэша node_modules и ~/.cocoapods в один архив и загрузите в своё объектное хранилище — либо создайте снапшот текущего инстанса в панели управления OnceMini. При следующем продлении или переустановке системы просто восстановите состояние диска из снапшота — можно даже не повторять настройку зеркал. По замерам, такой архив кэша пользовательской директории занимает от 8 до 15 ГБ — на тарифах OnceMini с SSD от 256 ГБ этого места вполне достаточно и без ущерба для квоты хранения обычных файлов проекта.

Чек-лист

Пройдитесь по пунктам перед запуском, чтобы не обнаружить пропущенный шаг только после провала сборки:

• Записаны ли три переменные окружения Homebrew в ~/.zprofile (а не только через export в текущей сессии)
• Закоммитен ли Brewfile в репозиторий проекта, а не остался в истории терминала кого-то одного
• Переключены ли все три зеркала — npm/pip/CocoaPods, а не только Homebrew
• Проверены ли ключевые bottle-пакеты через shasum
• Если планируется повторная аренда той же ноды — создан ли уже снапшот окружения

Часто задаваемые вопросы