Proces migracji nazwanych woluminów Dockera między dwoma serwerami domowymi

Bezpieczne podejście polega na traktowaniu archiwum zatrzymanego w spójnym stanie lub zsynchronizowanej kopii w jednoznacznie zidentyfikowanym woluminie docelowym, a następnie weryfikacji sum kontrolnych i aplikacji, jako sekwencji obserwowalnych etapów, a nie pojedynczego polecenia.

W przypadku dwóch domowych serwerów z systemem Linux i uruchomionym Docker Compose praktyczne ryzyko polega na konieczności przeniesienia kontenera stanowego na inny host bez kopiowania aktywnego lub nieprawidłowo nazwanego woluminu. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego rozróżnienia, interpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz przerwij, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia byłaby narażona. Poniższy proces kończy się dopiero po pomyślnym uruchomieniu pierwotnego obciążenia albo po osiągnięciu granicy eskalacji wynikającej z zebranych dowodów.

Zidentyfikuj umowy dotyczące woluminów źródłowego i docelowego

Zapisz skrót obrazu kontenera źródłowego, nazwę projektu Compose, nazwę usługi, klucz woluminu, rzeczywistą nazwę woluminu Docker, miejsce montowania, sterownik woluminu oraz wersję aplikacji. Użyj docker inspect i docker volume inspect; nie wnioskuj o ścieżce fizycznej wyłącznie na podstawie etykiety YAML.

Compose zwykle dodaje nazwę projektu jako prefiks do nazwanych woluminów, chyba że użyto jawnej nazwy lub woluminu zewnętrznego. Na hoście docelowym wyrenderuj konfigurację Compose i jawnie utwórz zamierzony pusty wolumin, aby migracja nie trafiła do jednego woluminu, podczas gdy usługa uruchomi inny.

Jeśli wolumin zawiera bazę danych, użyj jej natywnego zrzutu lub obsługiwanej kopii zapasowej jako głównej przenośnej ścieżki odzyskiwania, a kopię woluminu traktuj jako punkt odzyskiwania dla tej samej wersji. Przerwij, jeśli sterownik jest zdalny, pamięć źródłowa jest niestabilna lub stan aplikacji obejmuje dodatkowe woluminy poza zakresem.

Zatrzymaj procesy zapisujące i utwórz kopię zachowującą metadane

Przełącz aplikację w tryb konserwacji, zatrzymaj zadania w tle, a następnie prawidłowo zatrzymaj aplikację i bazę danych. Potwierdź, że żaden kontener nie montuje woluminu z prawem zapisu. Utwórz archiwum za pośrednictwem tymczasowego kontenera albo użyj kontrolowanej kopii systemu plików, która zachowuje numeryczne właścicielstwo, uprawnienia, dowiązania symboliczne, rozszerzone atrybuty, gdy są potrzebne, oraz pliki rzadkie.

Niezależny poradnik migracji woluminów Docker za pomocą rsync pokazuje, jak przenosić dane woluminu Docker przy użyciu rsync. Istotna granica polega na tym, że źródło musi być w stanie zatrzymanym, a polecenie kopiowania musi działać na zawartości zidentyfikowanego woluminu, a nie bezmyślnie modyfikować wewnętrzny katalog Dockera, gdy demon z niego korzysta.

Wygeneruj manifest zawierający liczbę plików, łączną liczbę bajtów, reprezentatywne skróty oraz sumę kontrolną archiwum. Pozostaw wolumin źródłowy i natywną kopię zapasową nietknięte; etap kopiowania kończy się pomyślnie tylko wtedy, gdy artefakt transferu można odczytać na hoście docelowym.

Przywróć dane do jawnie wskazanego woluminu docelowego

Sprawdź pojemność systemu plików na hoście docelowym, dostępność i-węzłów, oczekiwane identyfikatory UID i GID oraz tę samą wersję obrazu aplikacji. Przywróć archiwum do pustego woluminu docelowego bez spłaszczania struktury jego katalogu najwyższego poziomu, a następnie porównaj właścicielstwo, liczbę plików, rozmiary i wybrane skróty.

Dyskusja społeczności dotycząca przypadku nieudanej migracji nazwanego woluminu pokazuje, dlaczego bezpośrednia wymiana plików wewnątrz mechanizmów woluminów Dockera może zakończyć się niepowodzeniem lub pozostawić mylący stan. Użyj środowiska uruchomieniowego, aby zamontować wolumin w pomocniczym kontenerze, i wykonaj przywracanie za pośrednictwem tego kontrolowanego interfejsu.

Najpierw podłącz wyłącznie jednorazową kopię usługi, używając alternatywnych portów i bez dostępu do produkcyjnych systemów równorzędnych. Jeśli aplikacja zgłosi aktualizację schematu lub uszkodzony stan, przerwij i ponownie przywróć wolumin z niezmienionego artefaktu po rozwiązaniu problemu zgodności wersji.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Przełącz ruch i zachowaj hosta do wycofania zmian

Uruchom zależności przed aplikacją, sprawdź logi, logowanie, najnowsze rekordy, załączniki, zaplanowane zadania oraz jednorazowy zapis testowy. Uruchom ponownie stos docelowy i potwierdź, że ponownie podłącza ten sam nazwany wolumin. Aktualizuj proxy lub DNS dopiero po pomyślnym przejściu tych kontroli.

Powiązany artykuł ZimaSpace dotyczący spójnej kopii zapasowej danych kontenera może pomóc, jeśli cel uruchamia się jako pusty mimo pomyślnego kopiowania. Porównaj źródło montowania w środowisku uruchomieniowym z zamierzonym woluminem przed ponownym kopiowaniem danych; powtarzanie kopii do niewłaściwego celu tylko zwiększa niejasność.

Pozostaw aplikację źródłową zatrzymaną, a stary wolumin tylko do odczytu, dopóki na hoście docelowym nie powiedzie się nowa kopia zapasowa i test przywracania. Wycofaj zmiany, kierując ruch z powrotem do niezmienionego źródła, tylko jeśli na hoście docelowym nie zaakceptowano żadnych nowych zapisów; w przeciwnym razie zatrzymaj proces i celowo uzgodnij dane.