Czy można przywrócić wcześniejszą wersję obrazu kontenera bez utraty danych aplikacji?

Tak, możesz przywrócić wcześniejszą wersję obrazu kontenera bez utraty danych aplikacji, jeśli trwały stan znajduje się poza kontenerem i pozostaje zgodny ze starszą wersją.

W domowym serwerze NAS wymiana obrazu zwykle odtwarza tylko środowisko uruchomieniowe aplikacji, podczas gdy nazwane wolumeny lub montowania bind zachowują bazy danych, ustawienia i pliki użytkowników. Niebezpieczną granicą są zmiany schematu: nowszy obraz może przeprowadzić migrację bazy danych lub zmienić konfigurację w sposób, którego starsza wersja nie będzie w stanie odczytać. Przed przywróceniem wcześniejszej wersji zapisz bieżące montowania, identyfikator obrazu, konfigurację, sekrety oraz spójną kopię zapasową danych.

Zamroź bieżący stan przed zmianą obrazu

Wyłącz automatyczne aktualizacje obrazów i zapisz bieżący tag obrazu, niezmienny skrót, konfigurację kontenera, zmienne środowiskowe, sieci, porty, montowania, zasadę ponownego uruchamiania oraz test sprawności. Zapisz plik compose lub wyeksportowaną konfigurację oddzielnie od kontenera.

Procedura przywracania wcześniejszej wersji kontenera na serwerze NAS zaleca przechowywanie znanej poprzedniej wersji obrazu zamiast polegania na zmiennym tagu latest. Użyteczny punkt odzyskiwania to konkretna poprzednia wersja obrazu wraz z konfiguracją, w której działała.

Przed zatrzymaniem nowszej wersji wykonaj spójną kopię zapasową bazy danych aplikacji lub utwórz migawkę. Nie zakładaj, że istniejący wolumen jest kopią umożliwiającą przywrócenie wcześniejszej wersji, ponieważ może już zawierać zmiany schematu lub danych wprowadzone przez aktualizację.

Potwierdź, że dane aplikacji znajdują się poza zapisywalną warstwą

Przypisz każdy nazwany wolumen i każde montowanie bind, a następnie sprawdź, czy jakakolwiek baza danych, przesłane pliki, wtyczki, certyfikaty, pamięć podręczna lub konfiguracja nie są przechowywane wyłącznie w zapisywalnej warstwie kontenera.

Trwałe dane przetrwają wymianę kontenera tylko wtedy, gdy nowy kontener ponownie połączy się z tą samą zewnętrzną lokalizacją danych. Procedura zmiany wersji obrazu opisana przez SynoForum wyraźnie sprawdza, czy dane wolumenu pozostają na pamięci NAS przed odtworzeniem kontenera z innego obrazu.

Jeśli krytyczne dane znajdują się wyłącznie w zapisywalnej warstwie, skopiuj je lub wyeksportuj przed usunięciem bieżącego kontenera. Potraktuj to wydobycie danych jako krok odzyskiwania, a nie powód do bezterminowego utrzymywania kontenera bez określonej wersji.

Przypnij dokładną starszą wersję obrazu zamiast ponownie używać tagu latest

Pobierz lub znajdź ostatni znany działający tag albo skrót i zmień wyłącznie odwołanie do obrazu. Przed odtworzeniem usługi sprawdź architekturę, edycję aplikacji oraz wymagane zmienne środowiskowe.

Użytkownicy przywracający wcześniejszą wersję usług zarządzanych przez Compose zwykle wracają do poprzedniej, jawnie określonej wersji obrazu, zamiast oczekiwać, że Docker cofnie działający kontener w miejscu. Praktyczna procedura przywracania koncentruje się na zmianie przypiętego tagu obrazu Compose i odtworzeniu usługi.

Nie używaj starego obrazu z pamięci podręcznej, którego tożsamość jest nieznana. Po pobraniu zapisz skrót, aby kolejne odtworzenie nie wybrało po cichu innego pliku binarnego pod tym samym zmiennym tagiem.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź, czy nowsza wersja zmieniła bazę danych

Przeczytaj informacje o wydaniach aplikacji i dzienniki migracji dla wersji pomiędzy celem przywracania a bieżącym obrazem. Poszukaj nieodwracalnych zmian schematu, przepisanej konfiguracji, zmian kluczy szyfrowania lub aktualizacji wtyczek.

Przywrócenie wcześniejszej wersji bazy danych jest trudniejsze niż przywrócenie wcześniejszej wersji obrazu, ponieważ kod aplikacji i schemat muszą pozostać zgodne. Octopus opisuje migracje kompatybilne wstecz jako wymaganie w sytuacji, gdy starsze i nowsze wersje aplikacji mogą działać jednocześnie lub zostać odwrócone, dlatego zgodność schematu między wersjami wyznacza granicę bezpiecznego przywracania.

Jeśli starszy obraz nie może odczytać zmigrowanej bazy danych, przywróć kopię bazy sprzed aktualizacji zamiast kierować starszy kod do nowszego stanu. Zachowaj bieżącą bazę danych oddzielnie na wypadek konieczności cofnięcia samego przywrócenia.

Odtwórz usługę z tymi samymi trwałymi ścieżkami

Zatrzymaj i odtwórz kontener aplikacji ze starszym obrazem, zachowując te same zweryfikowane nazwane wolumeny lub montowania bind. Nie używaj poleceń ani opcji interfejsu, które usuwają wolumeny.

Zachowaj nazwy sieci, aliasy usług, opublikowane porty, mapowania UID/GID, sekrety i cele odwrotnego proxy, chyba że starsza wersja wymaga udokumentowanej różnicy. Pomyślne uruchomienie kontenera z nieprawidłowymi montowaniami może utworzyć nową, pustą aplikację i sprawiać wrażenie utraty danych.

Przed zalogowaniem lub zezwoleniem na wykonywanie zadań w tle sprawdź listę montowań i dzienniki aplikacji. Jeśli aplikacja inicjalizuje nową bazę danych, natychmiast ją zatrzymaj i popraw ścieżkę danych zamiast importować dane do niewłaściwej lokalizacji.

Zweryfikuj przywrócenie i zachowaj możliwość ponownego przejścia do nowszej wersji

Przetestuj logowanie, odczyt i zapis w bazie danych, przesyłanie plików, zaplanowane zadania, integracje oraz jeden kontrolowany restart. Porównaj wybrane rekordy i pliki ze spisem wykonanym przed przywróceniem.

Procedura ZimaSpace dotycząca migawek danych aplikacji przed aktualizacją zapewnia bezpieczniejszy sposób przygotowania do przyszłych aktualizacji.

Przywrócenie jest zakończone dopiero wtedy, gdy starszy obraz korzysta z właściwych trwałych danych, schemat jest zgodny lub został przywrócony, a usługa przetrwa kolejne odtworzenie. Zachowaj nowszy obraz, jego kopię zapasową danych oraz notatki dotyczące przywrócenia, dopóki starsza wersja nie będzie stabilnie działać przez zwykły okres obciążenia.