Lista kontrolna przeglądu zmian w Docker Compose dotyczących woluminów, sieci i sekretów

Bezpieczne podejście polega na traktowaniu przeglądu wyrenderowanej konfiguracji i kontroli odwracalnego wdrożenia, która chroni ścieżki danych, dostępność sieciową i sekrety, jako sekwencji obserwowalnych bramek, a nie pojedynczego polecenia.

W stosie aplikacji Docker Compose na serwerze domowym praktyczne ryzyko polega na tym, że edycja Compose może odtworzyć kontenery z inną pamięcią trwałą, łącznością lub sposobem dostarczania sekretów. Zapisz bieżącą tożsamość i punkt odzyskiwania, zacznij od najmniej inwazyjnego rozróżnienia, interpretuj wyniki pozytywne i negatywne przed zmianą kolejnej zmiennej oraz zatrzymaj się, gdy pamięć masowa stanie się niestabilna lub jedyna możliwa do odzyskania kopia zostałaby ujawniona. Poniższy proces kończy się dopiero wtedy, gdy pierwotne obciążenie działa poprawnie albo dowody prowadzą do granicy eskalacji.

Wyrenderuj obowiązującą konfigurację przed przeglądem

Ustal zestaw plików Compose, nazwę projektu, katalog roboczy, pliki środowiskowe, profile i tagi obrazów używane przez działające wdrożenie. Uruchom docker compose config za pośrednictwem ścieżki, która nie ujawnia wartości sekretów, bezpiecznie zapisz wyrenderowany model i porównaj go z ostatnim wdrożeniem, o którym wiadomo, że działało poprawnie.

Zachowanie Compose zależy od interpolacji i scalania plików, dlatego przegląd tylko edytowanego YAML-a może pominąć rzeczywistą zmianę. Artykuł przeglądania wyrenderowanej konfiguracji Compose zaleca weryfikację rozwiązanej konfiguracji i sprawdzenie planu wdrożenia, co zmienia przegląd z ćwiczenia formatowania w porównanie środowiska uruchomieniowego.

Zatrzymaj się, jeśli zmienne nie są ustawione, nazwa projektu nieoczekiwanie się zmieniła, tagi obrazów są zmienne i nie mają zarejestrowanego skrótu, albo wyrenderowany plik zawiera dane uwierzytelniające. Usuń te problemy przed wykonaniem jakiegokolwiek polecenia pull, build lub up.

Prześledź każdy trwały wolumen i każde dowiązanie do katalogu

Dla każdej usługi przypisz docelowy katalog w kontenerze do nazwanego wolumenu lub ścieżki na hoście, określ, czy zawiera konfigurację, pliki bazy danych, przesłane pliki czy pamięć podręczną, i potwierdź, że źródło istnieje oraz ma oczekiwanego właściciela. Zwróć szczególną uwagę na ścieżki względne, ponieważ zmieniony katalog roboczy może po cichu wskazać nowy, pusty folder.

Porównaj jawne nazwy wolumenów i flagi zewnętrzne z bieżącym wykazem wolumenów Dockera. Zmiana nazwy projektu może utworzyć nowy wolumen z odpowiednim prefiksem, pozostawiając stare dane nietknięte, przez co aplikacja będzie wyglądać na zresetowaną. Wykonaj kopię zapasową danych stanowych i zapisz bieżące wyniki inspekcji wolumenów przed zezwoleniem na ich odtworzenie.

Powiązany artykuł ZimaSpace dotyczący ochrony trwałej konfiguracji aplikacji podczas aktualizacji opisuje utratę konfiguracji podczas aktualizacji aplikacji. Skorzystaj z niego, gdy przegląd wykaże, że trwały stan aplikacji nigdy nie został prawidłowo oddzielony; nie maskuj problemu, kopiując nieznane pliki do nowo utworzonego wolumenu.

Przejrzyj sieci, porty i dostarczanie sekretów

Porównaj nazwy sieci, aliasy, rodziny adresów IP, publikowane porty, powiązania z hostem i cele odwrotnego proxy. Potwierdź, że bazy danych nadal pozostają prywatne, proxy może nadal rozwiązać nazwę usługi aplikacji oraz że po zmianie żaden port administracyjny nie zostanie wystawiony na wszystkich interfejsach.

Dla każdego sekretu zapisz jego źródło, odbiorcę, ścieżkę montowania lub klucz środowiskowy, tryb pliku i osobę odpowiedzialną za rotację, ale nie zapisuj wartości. Upewnij się, że nowa konfiguracja odwołuje się do istniejącego chronionego pliku lub zewnętrznego sekretu oraz że logi, argumenty kompilacji, etykiety i wyrenderowane porównanie nie ujawniają sekretu.

Zmiana sieci lub sekretu przechodzi przegląd tylko wtedy, gdy zamierzony odbiorca może uzyskać do niego dostęp lub go odczytać, a niezamierzeni użytkownicy równorzędni nie mogą tego zrobić. Jeśli zmiana wymaga jednoczesnej rotacji danych uwierzytelniających, podziel wdrożenie na fazę nakładania i fazę unieważnienia zamiast łączyć obie w jednym nieodwracalnym restarcie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Przygotuj odtworzenie i sprawdź wycofanie

Pobierz obrazy i przeanalizuj proponowane zmiany usług przed uruchomieniem stosu. Wdróż je w oknie umożliwiającym odzyskanie, najpierw odtwórz jedną zależność o niskim ryzyku, jeśli architektura na to pozwala, i obserwuj kontrole kondycji, logi, montowania, rozwiązywanie nazw DNS oraz nasłuchujące gniazda przed przejściem dalej.

Przetestuj logowanie, jeden odczyt danych, jeden zapis do usunięcia, zadania w tle i dostęp przez odwrotne proxy. Uruchom stos ponownie, aby sprawdzić, czy odwołania do wolumenów i sekretów przetrwają odtworzenie procesu. Nie uznawaj zmiany za udaną tylko dlatego, że kontenery mają stan uruchomiony.

Zachowaj poprzednie pliki Compose, odwołania do środowiska, skróty obrazów i kopię zapasową danych do czasu pomyślnego przejścia kontroli akceptacyjnych. Natychmiast wycofaj zmianę, jeśli aplikacja uruchomi się bez danych, baza danych nieoczekiwanie wykona migrację, brakuje sekretu lub port administracyjny jest wystawiony; przeprowadź analizę na podstawie zapisanego wyrenderowanego porównania.