Faire tourner des conteneurs Linux sur un Mac cloud pour relier CI iOS et backend

Votre dépôt héberge à la fois une app iOS et son service backend : ce dernier démarre via docker-compose une base de données, une file de messages et plusieurs microservices, et les tests d'intégration doivent réellement se connecter à ces conteneurs pour pouvoir s'exécuter. Pour la partie iOS, vous avez loué chez HireVPS un Mac mini cloud dédié aux builds Xcode, et tout fonctionne bien — jusqu'au jour où vous voulez que la CI, sur cette même machine, enchaîne avec les tests d'intégration backend. C'est là que vous découvrez qu'Apple Silicon n'a pas de noyau Linux natif, et que docker run échoue immédiatement en indiquant qu'aucun daemon n'est trouvé. Ce n'est pas un problème de configuration, c'est un problème d'architecture : sur macOS, Docker n'a jamais tourné autrement qu'en "empruntant" une coquille.

Le scénario : pourquoi faire tourner des conteneurs Linux même sur un Mac cloud

Les monorepos sont de plus en plus courants, et une même PR modifie souvent à la fois le client iOS et l'API backend — tester uniquement le côté iOS ne révèle pas les incompatibilités de protocole. Le pipeline idéal ressemble à ceci : sur le même runner, on compile d'abord avec Xcode et on lance les tests unitaires, puis on démarre les dépendances backend définies via docker-compose, on exécute une salve de tests d'intégration bout-en-bout, et enfin on rapporte un résultat unifié. L'avantage est immédiat : pas besoin de maintenir deux environnements CI distincts, ni d'ouvrir des brèches dans la politique réseau pour la communication inter-machines. La seule condition préalable est que ce Mac cloud soit capable de faire tourner des conteneurs Linux.

Apple Silicon n'a pas de noyau Linux natif — toute solution permettant de "faire tourner Docker" démarre en réalité d'abord une VM Linux cachée. Les performances dépendent presque entièrement du CPU et de la mémoire alloués à cette VM.

Préparation : choisir une solution de virtualisation légère

Sous macOS, deux voies principales permettent de faire tourner des conteneurs : Docker Desktop et Colima (associé au CLI docker natif). Les deux s'appuient en interne sur le Virtualization.framework d'Apple pour démarrer une VM Linux allégée — la différence tient à la forme d'utilisation et au scénario visé.

Docker Desktop face à Colima

Pour une CI qui tourne sur un runner sans supervision, Colima est clairement plus adapté : il ne dépend d'aucune session graphique, peut être démarré via une seule commande dans un script shell, puis arrêté une fois les tests terminés, sans laisser de processus orphelins occuper la mémoire.

Installation et allocation des ressources

Sur le Mac mini cloud, installez d'abord la chaîne d'outils via Homebrew :

brew install colima docker docker-compose docker-buildx

colima start \
  --cpu 4 \
  --memory 12 \
  --disk 60 \
  --vm-type=vz \
  --mount-type=virtiofs

docker context use colima
docker compose -f docker-compose.ci.yml up -d --wait

--vm-type=vz utilise le backend de virtualisation natif d'Apple (nettement plus rapide que l'ancien mode QEMU), et --mount-type=virtiofs permet aux performances de lecture/écriture du répertoire de projet monté dans les conteneurs de s'approcher de celles du disque local. Sans ces deux paramètres, la vitesse de build et l'I/O fichier se dégradent sensiblement.

Il n'existe pas de formule universelle pour l'allocation des ressources, mais un bon point de départ empirique : réservez à la VM Colima 50 à 70 % de la mémoire de l'hôte, et environ la moitié des cœurs CPU pour les builds Xcode. Selon la mémoire de la machine, on peut démarrer approximativement ainsi (vérifiez les configurations réellement disponibles dans la console) :

Si le build Xcode et Colima tournent simultanément, une allocation mémoire trop généreuse d'un côté pousse les deux à se disputer les ressources et à swapper, ce qui allonge finalement le temps de build. Ce point d'équilibre mérite d'être calibré en exécutant plusieurs fois le pipeline complet avant de l'intégrer réellement à la CI.

Intégration CI : faire connaître les conteneurs Linux au runner self-hosted

Si le runner est de type self-hosted GitHub Actions, il suffit d'ajouter une étape dans le job pour démarrer Colima, exécuter les tests, puis nettoyer — aucune déclaration supplémentaire de conteneur de service n'est nécessaire :

jobs:
  hybrid-ci:
    runs-on: [self-hosted, macos, cloud-mac]
    steps:
      - uses: actions/checkout@v4
      - name: Xcode build & unit test
        run: |
          xcodebuild -scheme App -destination "platform=iOS Simulator,name=iPhone 15" test
      - name: Bring up backend containers
        run: |
          colima start --cpu 4 --memory 12 --vm-type=vz --mount-type=virtiofs
          docker compose -f docker-compose.ci.yml up -d --wait
      - name: Integration tests
        run: ./scripts/run-integration-tests.sh
      - name: Teardown
        if: always()
        run: |
          docker compose -f docker-compose.ci.yml down -v
          colima stop

L'étape if: always() est cruciale : même en cas d'échec des tests, il faut arrêter les conteneurs et la VM — sinon, sur un Mac cloud loué durablement, les VM orphelines s'accumulent, occupent la mémoire et ralentissent le build suivant.

Stratégie de cache : réutiliser les couches d'images et les dépendances

Si chaque redémarrage de la VM Colima implique de retélécharger les images et de réinstaller les dépendances, la durée de la CI s'allonge considérablement. Deux approches simples et efficaces :

1. Persister le cache des couches d'images : n'exécutez pas colima delete à chaque fois, contentez-vous de colima stop/colima start — le disque de la VM (par défaut sous ~/.colima) conserve les couches d'images déjà téléchargées, évitant un nouveau téléchargement au redémarrage.
2. Monter le cache de build via des volumes : dans le Dockerfile backend, déclarez des volumes nommés pour les répertoires de dépendances comme node_modules, vendor ou .cargo. Combiné à l'option --wait de docker compose, le premier build sera un peu plus lent, mais les builds incrémentaux suivants gagneront une bonne partie du temps.

Associé au montage virtiofs mentionné précédemment, la lecture/écriture du répertoire de projet ne constitue plus vraiment un goulot d'étranglement. Ce qui mérite une vraie attention, c'est la couche réseau — si les tests d'intégration doivent accéder à des API externes, configurez impérativement des adresses mock ou sandbox dédiées à l'environnement de test, pour que la CI ne tape pas discrètement sur les endpoints de production.

Liste des pièges et points de vérification

Les erreurs les plus fréquentes lors de l'intégration réelle, classées par priorité :

• Oublier de basculer le contexte docker : si Docker Desktop a été utilisé auparavant, la commande docker peut encore pointer vers l'ancien contexte après l'installation de Colima — l'étape docker context use colima ne doit pas être omise.
• Mauvais type de VM : les anciennes versions de Colima utilisent parfois qemu par défaut. Sur Apple Silicon, spécifiez toujours explicitement --vm-type=vz, l'écart de performance est significatif.
• Croissance illimitée du disque : sans nettoyage des couches d'images, l'espace réservé via --disk se remplit continuellement. Il est recommandé d'exécuter régulièrement docker system prune -af --volumes dans le flux CI.
• Concurrence de ressources en cas de tâches parallèles : si d'autres builds Xcode tournent en parallèle sur la même machine, réduisez en conséquence l'allocation mémoire de Colima pour éviter les situations d'OOM.
• Images incompatibles avec l'architecture : si le backend référence des images de base ne supportant que x86_64, la couche d'émulation QEMU entre en jeu sur Apple Silicon, avec une chute brutale des performances. Vérifiez autant que possible l'existence de variantes arm64 natives.

Une fois ce flux bien rodé, le même Mac mini cloud peut jouer simultanément le rôle de machine de build iOS et d'environnement de tests d'intégration backend. Plus besoin de se soucier de la coordination réseau et des identifiants entre machines — après soumission d'une PR, un seul pipeline fournit un signal complet de succès ou d'échec.

Questions fréquentes