Accélérer le démarrage à froid d'un Mac mini cloud avec les miroirs Homebrew et le cache de dépendances

Il est deux heures du matin, tu viens de louer pour 9 dollars un Mac mini M4 dans un datacenter de Hong Kong, et la clé SSH atterrit dans ta boîte mail cinq minutes plus tard. Tout excité, tu te connectes et tapes immédiatement brew install node — puis tu regardes la barre de progression se figer au téléchargement du bottle. Tu rafraîchis le terminal, curl signale un timeout et retente la connexion, vingt minutes s'écoulent et tu attends toujours une archive tarball qui devrait normalement se télécharger en trois secondes. Ce n'est pas une panne réseau, c'est la latence habituelle des datacenters à l'étranger lorsqu'ils accèdent au CDN officiel de Homebrew — et cette latence, tu la subis à nouveau chaque fois que tu redémarres une nouvelle instance.

Scénario : machine toute neuve, mais l'installation des dépendances engloutit la moitié de la location

L'avantage d'un Mac mini cloud facturé à la journée, c'est qu'on peut le démarrer et l'arrêter à volonté ; l'inconvénient, c'est que chaque nouvelle instance repart d'une page blanche. Après avoir installé les Xcode Command Line Tools et exécuté le setup.sh de l'équipe, le déroulé classique s'enchaîne : une pile de paquets via brew install, une pile de dépendances via npm install, puis un pod install qui retélécharge tout l'index de specs CocoaPods. Comme toutes les sources officielles pointent vers des serveurs à l'étranger, le seul temps de téléchargement peut engloutir autant de temps de travail que le coût de location journalier de la machine entière. Si tu ne loues que pour une journée afin de faire une tâche ponctuelle, ce coût est particulièrement douloureux.

Pourquoi les sources officielles sont si lentes sur les nœuds cloud

Les bottles (paquets précompilés) de Homebrew résident par défaut sur GitHub Packages, et le registre officiel de npm ainsi que le dépôt de specs de CocoaPods sont également hébergés sur des infrastructures à l'étranger. La bande passante de sortie internationale des fournisseurs cloud est généralement suffisante, mais la qualité du routage vers les nœuds CDN précis varie fortement — la poignée de main TLS lors du premier établissement de connexion, cumulée à la résolution DNS, ajoute rapidement quelques dizaines à quelques centaines de millisecondes de latence. Multiplié par plusieurs centaines de paquets de dépendances, cela se traduit par une attente de plusieurs minutes, voire plusieurs heures. Ce n'est pas ta machine qui est lente, c'est la liaison réseau.

Trois étapes pour mettre en place une chaîne d'accélération réutilisable

Étape 1 : basculer le dépôt Homebrew et le domaine des bottles

Vérifie d'abord si ton installation Homebrew pointe déjà vers un miroir accessible, puis unifie les variables d'environnement — un redémarrage de la session terminal suffit à les activer :

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

Ajoute ces trois lignes dans ~/.zprofile : plus besoin de les redéfinir au prochain démarrage.

Étape 2 : figer la liste des dépendances avec un Brewfile

Ne tape pas chaque brew install un par un : consigne les paquets couramment utilisés par l'équipe dans un Brewfile, installe-les tous en une seule commande bundle, et garde ainsi les mêmes versions sur tous tes nœuds :

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

brew bundle --file=~/Brewfile

Le Brewfile lui-même ne fait que quelques dizaines de lignes ; range-le dans le dépôt de code, et sur une machine neuve il suffit de faire un git clone du projet puis de relancer bundle. C'est bien plus rapide que de chercher chaque commande d'installation une par une, et cela évite d'oublier une dépendance cachée.

Étape 3 : configurer les mêmes miroirs pour les gestionnaires de paquets des langages

L'accélération de Homebrew ne résout qu'une partie du problème — npm, pip et CocoaPods ont chacun leur propre source par défaut, qu'il faut configurer une par une :

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

Une fois les quatre liaisons basculées, la comparaison des temps sur un Mac mini flambant neuf, de l'extraction des dépendances jusqu'au premier build réussi, est sans appel :

Basculer vers des miroirs n'est pas gratuit : les serveurs miroirs synchronisent les dépôts officiels avec un décalage de quelques minutes à plusieurs heures. Après une mise à jour de version importante, lance d'abord brew doctor en autodiagnostic, puis vérifie le hash shasum -a 256 des bottles critiques pour t'assurer qu'il correspond bien à la publication officielle avant de passer en production.

Enregistrer l'environnement préchauffé en snapshot pour le réutiliser directement au prochain démarrage

Si tu comptes relouer le même nœud à la semaine ou au mois, tu peux aller encore plus loin dans cette chaîne d'accélération : une fois les dépendances installées et un premier build validé, compresse ~/Library/Caches/Homebrew, les répertoires de cache partagés de node_modules et ~/.cocoapods dans une archive à uploader sur ton propre stockage objet, ou déclenche directement un snapshot de l'instance en cours depuis la console OnceMini. Au prochain renouvellement ou à la prochaine réinstallation du système, tu restaures directement l'état du disque depuis le snapshot — jusqu'à l'étape de configuration des miroirs qui devient inutile. En pratique, cette archive de cache de répertoire utilisateur pèse entre 8 et 15 Go ; avec les tiers SSD de OnceMini qui démarrent à 256 Go, cet espace passe sans problème, sans empiéter sur le quota de stockage réservé aux fichiers de projet.

Liste de vérification

Passe chaque point en revue avant de passer en production, plutôt que d'attendre un échec de build pour découvrir une étape manquante :

• Les trois variables d'environnement Homebrew sont-elles bien écrites dans ~/.zprofile (et pas seulement définies via export dans la session en cours) ?
• Le Brewfile est-il versionné dans le dépôt du projet, plutôt que de rester dans l'historique de terminal local d'une seule personne ?
• Les miroirs npm, pip et CocoaPods ont-ils tous les trois été basculés, et pas seulement celui de Homebrew ?
• Une vérification shasum a-t-elle été effectuée sur les bottles critiques ?
• Si tu prévois de relouer le même nœud, un snapshot d'environnement a-t-il déjà été déclenché ?

Questions fréquentes