Czy możesz przywrócić jeden kontener bez zastępowania całego stosu aplikacji?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Can You Restore One Container Without Replacing the Whole App Stack? - Zima Store Online

Tak, jeden kontener można przywrócić niezależnie, gdy jego konfiguracja, dane trwałe i granice zależności są wyraźnie oddzielone od reszty stosu.

Na domowym serwerze NAS widoczny kontener jest zwykle elementem tymczasowym, ale stan aplikacji może obejmować montowania bind, nazwane woluminy, oddzielną bazę danych, sekrety, trasy proxy i współdzielone sieci. Bezpieczne przywracanie pojedynczej usługi nie polega więc na wstawieniu z powrotem identyfikatora jednego kontenera; oznacza zamrożenie usługi, przywrócenie wyłącznie należącego do niej stanu, odtworzenie jej na podstawie znanej definicji oraz potwierdzenie, że współdzielone zależności i działające kontenery sąsiednie pozostały bez zmian.

Zdefiniuj jednostkę przywracania, zanim cokolwiek zatrzymasz

Zidentyfikuj dokładnie usługę, która uległa awarii, i wypisz wszystkie należące do niej obiekty: nazwę usługi Compose, tag lub skrót obrazu, plik środowiskowy, sekrety, montowania bind, nazwane woluminy, opublikowane porty, aliasy sieciowe, zaplanowane zadania i etykiety odwrotnego proxy.

Instrukcje przywracania woluminów Docker rozdzielają środowisko uruchomieniowe kontenera od pamięci trwałej, ponieważ wolumin z danymi można tworzyć w kopii zapasowej i przywracać niezależnie. Praktyczny poradnik pokazuje oddzielne przywracanie kontenera i woluminu, zamiast traktowania działającego kontenera jako jedynego obiektu odzyskiwania.

Jeśli aplikacja zapisuje dane we współdzielonej bazie danych lub woluminie, jednostka przywracania obejmuje tę współdzieloną zależność i może nie być już bezpiecznie odizolowana. Nie nadpisuj niczego, dopóki własność danych nie będzie jednoznaczna.

Uchwyć stan działającego stosu i uszkodzonej usługi

Wyeksportuj lub zapisz bieżący plik Compose, rozwiniętą konfigurację środowiska, skróty obrazów, listę montowań, członkostwo w sieciach, stan zdrowia i najnowsze dzienniki. Zapisz, które usługi sąsiednie działają poprawnie, aby przywracanie miało jasno określoną granicę wpływu.

Operacja na poziomie usługi Compose może wskazywać jedną nazwaną usługę zamiast ponownego uruchamiania wszystkiego. Procedura pojedynczej usługi opisana w Linux Handbook rozróżnia jedną usługę Compose od działań obejmujących cały stos, ale wskazuje również, że zmiany konfiguracji wymagają odtworzenia, a nie prostego ponownego uruchomienia.

Wyłącz automatyczne aktualizacje i pętle ponownego uruchamiania wyłącznie dla uszkodzonej usługi. Pozostaw bazy danych i współdzieloną infrastrukturę uruchomione, chyba że ich spójność wymaga skoordynowanego zatrzymania.

Najpierw przywróć dane w odizolowanej lokalizacji

Przywróć wybraną kopię zapasową do tymczasowego katalogu lub nowego woluminu, zamiast bezpośrednio nadpisywać aktywną ścieżkę. Porównaj liczbę plików, właścicieli, znaczniki czasu, metadane zrzutu bazy danych i wersję aplikacji z uszkodzonym stanem.

Projekt do tworzenia kopii zapasowych woluminów opisuje użycie tymczasowego kontenera jednorazowego do zamontowania i ponownego zapełnienia docelowego woluminu, tworząc odizolowaną ścieżkę przywracania woluminu, zanim usługa produkcyjna zacznie zapisywać dane.

W przypadku baz danych zawsze, gdy jest to możliwe, używaj zrzutu lub metody przywracania uwzględniającej aplikację. Kopia systemu plików działającej bazy danych może co najwyżej zachować spójność po awarii i może nie zadziałać po usunięciu starego kontenera.

Zweryfikuj odizolowaną kopię przed przełączeniem montowań. Jeśli kopii zapasowej nie można odczytać lub jej schemat nie pasuje do zamierzonego obrazu, zachowaj bieżący stan i wybierz inny punkt odzyskiwania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Odtwórz wyłącznie uszkodzoną usługę z zachowaniem jej pierwotnej tożsamości

Odtwórz nazwaną usługę na podstawie zapisanego pliku Compose, zachowując tę samą nazwę projektu, sieci zewnętrzne, aliasy usług, porty, sekrety, mapowanie UID/GID oraz zweryfikowane ścieżki danych trwałych.

Dostęp do montowania może nadal nie działać po prawidłowym przywróceniu danych, gdy właściciel lub etykiety bezpieczeństwa nie pasują już do użytkownika środowiska uruchomieniowego. Problem z dostępem do woluminu w kontenerze Rocky Linux rozwiązano przez sprawdzenie własności i kontekstu bezpieczeństwa, a nie przez ponowne kopiowanie danych.

Uruchom usługę bez usuwania woluminów i wykonywania poleceń prune obejmujących cały stos. Sprawdź jej aktywne montowania, zanim zezwolisz migracjom, skanom lub zadaniom w tle na modyfikowanie przywróconych danych.

Ponownie połącz zależności bez ich przywracania

Przetestuj rozwiązywanie DNS i dostęp TCP z przywróconego kontenera do jego bazy danych, pamięci podręcznej, dostawcy tożsamości, magazynu obiektowego i sieci proxy. Użyj tych samych nazw usług i danych uwierzytelniających zdefiniowanych w odzyskanej konfiguracji.

Jeśli współdzielona zależność pozostała sprawna, nie przywracaj jej ani nie zastępuj tylko dlatego, że aplikacja nie może się połączyć. Brakujący alias sieciowy, zmieniony sekret, niezgodność schematu lub nieprawidłowa nazwa bazy danych mogą sprawić, że działająca zależność będzie wyglądać na niedostępną.

Uruchamiaj migracje tylko wtedy, gdy wymaga ich przywrócona wersja aplikacji i kopia bazy danych. Przed każdą nieodwracalną migracją wykonaj kopię zależności i zatrzymaj proces, jeśli aplikacja próbuje zainicjalizować pustą bazę danych.

Zweryfikuj granicę pojedynczej usługi przed wznowieniem ruchu

Przetestuj logowanie, odczyty, zapisy, przesyłanie plików, zaplanowane zadania, wywołania API, dostęp przez proxy i jedno kontrolowane ponowne uruchomienie. Porównaj liczniki ponownych uruchomień kontenerów sąsiednich, dzienniki, porty i sumy kontrolne danych ze stanem zapisanym przed przywracaniem.

Poradnik ZimaSpace dotyczący mapowania trwałego stanu kontenera przedstawia tę samą zasadę odzyskiwania: przywracaj właściciela stanu, a nie przypuszczalną powłokę kontenera.

Przywracanie jest zakończone dopiero wtedy, gdy odzyskana usługa korzysta z zamierzonych danych i zależności, zdrowe elementy stosu pozostały nietknięte, a kolejne odtworzenie daje taki sam rezultat. Jeśli nie można odizolować współdzielonego stanu, przejdź do skoordynowanego przywracania całego stosu zamiast wymuszać częściowe wycofanie zmian.