Lorsque vous louez de la capacité Mac mini M4 à Singapour, Tokyo, Séoul, Hong Kong ou sur la côte ouest des États-Unis, le choix entre Colima (VM Lima, approche CLI) et Docker Desktop (curseurs ressources, Kubernetes embarqué) n’est pas anodin : il conditionne les plafonds CPU et mémoire, la charge IO NVMe, le parallélisme des téléchargements d’images et les délais des files de build. Ce guide n’est pas la matrice Docker et Podman sur les caches de couches, qui reste agnostique moteur ; ici il s’agit de décider quelle pile desktop macOS porte l’hyperviseur et le budget disque de la VM Linux. Pour les orages Kind ou minikube imbriqués, voir la matrice pulls imbriqués ; pour le TCO régional, latence batch et nœuds. Les pages Tarifs et Achat restent consultables sans compte.
Trois frictions qui cassent les workflows Docker transverses
Sur Apple Silicon loué, trois schémas récurrents faussent le diagnostic :
- Mirage des quotas. Le Moniteur d’activité affiche du GHz disponible alors que la mémoire unifiée sert déjà le cache disque de la VM, les snapshotters containerd et les couches temporaires BuildKit — les curseurs CPU semblent généreux jusqu’à ce que l’OOM touche la VM Linux.
- Empilement IO. Colima en vz et Docker Desktop virtualisent tous deux le stockage, mais la croissance de l’image disque, les bascules VirtioFS et l’emplacement du graph root décident si des pulls parallèles deviennent une profondeur de file plutôt qu’un débit utile sur NVMe interne.
- Timeout unique. Augmenter seulement
COMPOSE_HTTP_TIMEOUTmasque une RTT registre élevée ; fusionner attente de pull, extraction et bake buildx dans un seul délai empêche de savoir s’il faut rapprocher le miroir ou réduire la concurrence de couches.
Matrice Colima versus Docker Desktop
Utilisez le tableau comme bande de départ pour des opérateurs en 2026 ; validez avec votre fournisseur de registre et la RTT mesurée depuis le nœud loué.
| Dimension | Colima (typique) | Docker Desktop (typique) |
|---|---|---|
| CPU et mémoire | Plafonds explicites via colima start ou YAML ; reproductibles en SSH sur chaque région |
Curseurs Réglages ; mode économie de ressources optionnel ; confort pour équipes GUI |
| Stockage IO | Profil disque Lima et --disk ; surveiller le chemin virtio, garder le graphe sur NVMe interne |
Taille d’image disque et compromis VirtioFS / osxfs ; invitations de compactage à anticiper |
| Pulls concurrents (couches) | daemon.json dans la VM ; les miroirs suivent l’article couches et cache mais la largeur VM passe avant tout |
Même idée max-concurrent-downloads ; diagnostics UI lorsque les pulls se figent |
| Files de build et timeouts | Compose et CLI héritent des variables hôte (DOCKER_CLIENT_TIMEOUT) ; le parallélisme BuildKit limite la frénésie CPU |
Mêmes variables client ; Kubernetes intégré ajoute des délais kubelet si vous activez le cluster local |
| Signal coût | Pile open source ; le coût se déplace vers le temps ingénieur (mises à jour Lima, scripts) | Licence par politique d’entreprise ; support éditeur souvent plus rapide sur bugs Desktop-only |
Règle pratique : choisissez Colima lorsque votre automatisation vit déjà dans le shell et que vous voulez un colima.yaml identique dans chaque métropole. Retenez Docker Desktop lorsque la politique impose le bundle éditeur, les Extensions ou un tableau de bord graphique pour expliquer les blocages IO aux parties prenantes.
Cinq étapes opérables avant d’augmenter la concurrence
- Tracer la VM. Avec Colima sur Apple Silicon, fixez des plafonds explicites, par exemple
colima start --vm-type vz --cpu 4 --memory 8 --disk 100, puisdocker infopour confirmer les plafonds cgroup. - Aligner les curseurs Desktop. Dans Docker Desktop, section Ressources, placez CPU et mémoire quelques gigaoctets sous le palier hôte afin de laisser macOS et une session VNC réactives pendant les builds.
- Freiner les pulls avant les CPU. Dans la VM Linux, éditez
/etc/docker/daemon.jsonavec une concurrence bornée, par exemple :
{
"max-concurrent-downloads": 3,
"max-concurrent-uploads": 5
}- Séparer les timeouts. Exportez
export COMPOSE_HTTP_TIMEOUT=240etexport DOCKER_CLIENT_TIMEOUT=300pour les résolutions longues ; n’augmentez les journaux BuildKit qu’après avoir vérifié la marge disque. - Observer les files. Si
docker buildx dugrossit sans charge CPU, réduisez les cibles Bake parallèles ou les jobsdocker pullavant de toucher aux curseurs processeur.
Repères citables
- Conservez au moins quatre gigaoctets de mémoire unifiée hors VM Linux sur hôte 16 Go lorsque navigateurs et IDE tournent en parallèle des builds.
- Essayez trois comme première valeur
max-concurrent-downloadssur chemins registre à RTT élevée ; montez vers six seulement après miroir ou colocalisation. - Un COMPOSE_HTTP_TIMEOUT au-delà de trois cents secondes doit signaler un problème de localité registre, pas un besoin de multiplier les services parallèles.
FAQ
Podman compte-t-il ici ? Les piles Podman suivent la matrice couches et cache ; cette page reste sur Colima versus Docker Desktop parce que toutes deux ciblent la même ergonomie CLI Docker sur macOS loué.
Kubernetes imbriqué ? Si vous empilez Kind ou minikube, budgétisez les pulls containerd imbriqués à part — voir la matrice Kind et minikube.
Changer de pile en cours de projet ? Prévoyez une fenêtre de maintenance, réappliquez daemon.json, refaites un pull à froid des digest de base avant d’augmenter le parallélisme CI.
Achat
Louez de l’Apple Silicon lorsque vos files de build exigent un NVMe stable et une métropole proche du registre. Ouvrez Singapour, Japon, Corée du Sud, Hong Kong ou États-Unis (Ouest) pour le contexte régional, puis finalisez sur Achat. Fichier : 2026-remote-mac-m4-colima-docker-desktop-quota-matrix.html. Choisissez un forfait calcul aligné sur votre palier mémoire et votre profil de pulls inter-régions : Tarifs, Aide et pages régionales restent lisibles sans connexion jusqu’au passage en caisse.