Lokalny przewodnik odzyskiwania środowiska Docker 29 w CasaOS i Portainerze

Ten tekst opisuje kilka awarii, które wystąpiły w krótkim odstępie czasu, dlatego nie należy sprowadzać go do jednego prostego „błędu Portainera”. Na dysku systemowym było prawie zero wolnego miejsca, Docker i containerd zostały zaktualizowane przez Debiana do nowych głównych wersji, starszy test CLI Dockera został odrzucony przez demona Docker 29, Portainer utracił środowisko lokalne, CasaOS stale wyświetlał komunikat „ładowanie aplikacji”, a późniejszy problem z uruchamianiem sprawił, że panel wyglądał niemal jak po świeżej instalacji.

Żadna odpowiedź w źródle nie potwierdza jednej ostatecznej przyczyny. Najbezpieczniejsza interpretacja to warstwowy problem z odzyskiwaniem systemu: najpierw należy zabezpieczyć istniejące dane, a następnie ustalić, który dysk startowy i główny system plików są aktywne, czy katalog danych Dockera nadal istnieje, czy demon działa prawidłowo oraz czy Portainer i CasaOS są zgodne ze zaktualizowanym API Dockera.

Dysk systemowy był już poważnie obciążony brakiem miejsca

Przed czyszczeniem użytkownik miał tylko około 1 GB wolnego miejsca na głównym systemie plików o pojemności 27 GB. Dużo miejsca zajmowały dane warstwy Docker, metadane Jellyfin, dzienniki systemowe i pakiety deweloperskie.

Mała ilość wolnego miejsca może powodować nieprzewidywalne działanie operacji na obrazach i kontenerach Dockera, baz danych, dzienników oraz usług CasaOS. Zwolnienie miejsca było konieczne niezależnie od późniejszego problemu z API Dockera.

Aktualizacja hosta zmieniła Dockera z wersji 28.x na 29.0.0

Historia pakietów Debiana wykazała aktualizację następujących elementów:

docker-ce;
docker-ce-cli;
containerd.io;
dodatków Dockera do uruchamiania bez uprawnień administratora.

Aktualizacja Docker Engine do nowej głównej wersji może ujawnić problemy ze zgodnością w narzędziach zarządzających, które zawierają starszych klientów API lub negocjują starsze wersje API.

W źródle zarejestrowano rzeczywistą niezgodność wersji API Dockera

Kontener z interfejsem CLI Dockera 24.0.5 zwrócił komunikat:

client version 1.43 is too old.
Minimum supported API version is 1.44

Ten komunikat stanowi bezpośredni dowód, że co najmniej jeden starszy klient nie mógł już komunikować się ze zaktualizowanym demonem Dockera. Sam w sobie nie dowodzi, że Portainer korzystał dokładnie z tej wersji klienta, ale sprawia, że zgodność API należy sprawdzić w pierwszej kolejności.

Komunikat Portainera, że środowisko lokalne działa, a następnie że go brakuje, wskazuje na problem warstwy zarządzania

W źródle próbowano odtworzyć lokalne środowisko Dockera z użyciem /var/run/docker.sock, ale bez powodzenia. Przed usunięciem stanu Portainera należy sprawdzić:

docker info
docker ps
ls -l /var/run/docker.sock

Jeśli sam interfejs CLI Dockera działa, ale Portainer nie, należy skupić się na wersji Portainera, zgodności API i dostępie do gniazda. Jeśli Docker sam w sobie nie działa, najpierw trzeba naprawić demona.

Komunikat CasaOS „Ładowanie aplikacji” sugeruje, że problem był szerszy niż sam Portainer

CasaOS również miał problemy z wyświetlaniem aplikacji. Może się tak dziać, gdy Docker jest niedostępny, interfejs API Dockera zmienił się w sposób powodujący niezgodność, brakuje głównego katalogu danych demona albo uruchomiony system nie ma już oczekiwanego stanu.

Późniejsze zdarzenie „Wybierz właściwe urządzenie rozruchowe” zmienia priorytety odzyskiwania

Po ponownym uruchomieniu komputer przestał normalnie startować, dopóki użytkownik nie zmienił wyboru urządzenia rozruchowego. Po uruchomieniu CasaOS nie wyświetlał żadnych aplikacji, mimo że duży dysk HDD nadal był podłączony.

Może to oznaczać, że wybrano inny dysk startowy lub główny system plików albo że zmienił się stan partycji systemowej. Źródło nie pozwala jednoznacznie ustalić, która z tych możliwości zaszła.

Przed ponowną instalacją CasaOS zabezpiecz katalog AppData

Użytkownikowi najbardziej zależało na:

plikach projektów w /home/casaos;
metadanych Jellyfin w katalogu AppData;
plikach multimedialnych na dysku HDD;
konfiguracji Dockera i CasaOS, jeśli można ją odzyskać.

Przed ponowną instalacją lub resetowaniem Dockera należy skopiować te trwałe katalogi na inny dysk lub do innego systemu. Odtworzenie kontenerów jest zwykle łatwiejsze niż ponowne odtworzenie baz danych i metadanych aplikacji.

Nie usuwaj agresywnie danych Dockera, dopóki nie ustalisz, co jest nadal używane

Usuwanie nieużywanych obrazów może zwolnić miejsce, ale usunięcie woluminów lub katalogów głównych danych może skasować stan aplikacji, który próbujesz zachować. Najpierw ustal kontenery, woluminy, montowania wiązań oraz ścieżki AppData.

Traktuj aktualizacje Debiana i Dockera jako część platformy CasaOS

CasaOS działa na bazowym hoście z systemem Linux. Szerokie polecenie apt upgrade może zaktualizować Dockera, jądro, systemd, sieć i pakiety związane z pamięcią masową, od których zależy CasaOS. Duże aktualizacje hosta należy testować celowo i przed ich zastosowaniem w działającym serwerze NAS wykonywać kopię zapasową systemu oraz aplikacji.

Najczęstsze pytania dotyczące odzyskiwania Portainera i CasaOS

Czy źródło dowodzi, że sam Docker 29 spowodował wszystkie awarie?

Nie. System miał również niemal całkowicie zapełniony dysk, a później wystąpił problem z urządzeniem rozruchowym lub stanem systemu.

Czy potwierdzono niezgodność API Dockera?

Tak. Interfejs CLI Dockera 24 korzystający z API 1.43 został odrzucony, ponieważ demon Docker 29 wymagał co najmniej wersji 1.44.

Czy użytkownik powinien ponownie zainstalować CasaOS przed skopiowaniem katalogu AppData?

Nie. Jeśli dyski są nadal dostępne, najpierw należy zabezpieczyć ważne dane AppData, pliki z katalogu domowego i multimedia.