‫Ta sekcja będzie pełna wykładów i zadań wokół trwałych danych.
‫Najpierw omówimy problemy dotyczące trwałych danych i jak to w ogóle
‫stało się problemem.
‫Kluczowe pojęcia, które musisz zrozumieć, to idea niezmiennej infrastruktury.
‫A pomysł wokół kontenerów jest naturalnie efemeryczny w projektowaniu.
‫Omówimy te z pierwszego wykładu. Następnie zanurkujemy na objętości danych i jak te rozwiązania
‫rozwiązują niektóre z naszych problemów dotyczących trwałych danych. Następnie przekopamy się na mocowanie bindów i rozwiążemy
‫różne problemy z trwałymi danymi. Następnie przejdziemy do tej sekcji z kilkoma zadaniami dotyczącymi
‫sposobu zachowania danych bazy danych podczas zastępowania kontenerów dla baz danych. A potem także wokół montowania
‫kodu do kontenera od hosta podczas jego edycji, aby można
‫było uruchomić ten kod wewnątrz kontenera na żywo. Wymagania dotyczące tego pierwszego wykładu to po prostu zrozumienie,
‫jak uruchamiać kontenery oraz koncepcje kontenerów i obrazów, które omówiliśmy do tej pory.
‫Do tej pory martwiłeś się tylko tym, co jest potrzebne do uruchomienia kontenera, a nie unikatowych danych, które mogą
‫zostać utworzone po uruchomieniu kontenera.
‫Pojemniki mają być niezmienne i efemeryczne.
‫To są tylko wymyślne, niezrozumiałe hasła do niezmiennego, tymczasowego lub jednorazowego użytku.
‫Chodzi o to, że możemy po prostu wyrzucić pojemnik i stworzyć nowy z obrazu,
‫prawda?
‫Nie mówimy tu o rzeczywistym ograniczeniu pojemników, ale raczej o celu projektowym lub
‫najlepszej praktyce.
‫Jest to idea niezmiennej infrastruktury, w której nie zmieniamy rzeczy po uruchomieniu.
‫Jeśli zajdzie potrzeba zmiany konfiguracji, lub może zajdzie konieczność aktualizacji wersji kontenera, wówczas
‫ponownie wdrożymy nowy kontener.
‫Daje nam to ogromne korzyści w zakresie niezawodności i spójności oraz umożliwia powtarzalność zmian.
‫Ale jest kompromis.
‫Co z unikalnymi danymi, które wygeneruje Twoja aplikacja? Te bazy danych lub kluczowa wartość przechowuje, czy cokolwiek
‫innego, co aplikacja wypluwa w pliku?
‫W idealnych warunkach pojemniki nie powinny zawierać unikatowych danych zmieszanych z plikami binarnymi aplikacji. Jest to znane jako "separacja
‫obaw", a Docker daje nam tutaj naprawdę dużą korzyść.
‫Możemy zaktualizować naszą aplikację, odtwarzając nowy kontener, ze zaktualizowaną wersją naszej aplikacji, i idealnie, nasze unikalne dane są nadal
‫tam, gdzie muszą być i zostały zachowane dla nas, gdy nasz pojemnik został poddany recyklingowi.
‫Jeśli dotąd nie zauważyłeś, kontenery, z których korzystaliśmy, domyślnie były trwałe.
‫Wszelkie zmiany w nich faktycznie były przechowywane od nowa i restartuje dopóki nie usunęliśmy kontenera.
‫Tylko dlatego, że zatrzymaliśmy kontener lub zrestartowaliśmy hosta, nie
‫oznacza to, że zmiany w pliku kontenera znikną.
‫Dopiero gdy usuniemy kontener, że jego warstwa UFS zniknie, ale chcemy to zrobić w
‫dowolnym momencie.
‫Ten problem unikalnych danych jest znany w branży jako "trwałe dane", a do czasu kontenerów
‫tak naprawdę nie mieliśmy na to nazwy. Ponieważ, cóż, większość rzeczy, które stworzyliśmy, była trwała, tak
‫jak znasz te stare serwery, które używają tej starej aplikacji przez pięć, dziesięć lat lub dłużej.
‫Wszystko było domyślnie trwałe.
‫Teraz, w nowym świecie pojemników i automatycznych skalowań aplikacji, trwałe dane stwarzają wyjątkowy
‫problem.
‫Docker ma dwa rozwiązania tego problemu, znane
‫jako "woluminy danych" i "mocowania bindów". "Woluminy Docker to opcja konfiguracyjna
‫dla kontenera, który tworzy specjalne miejsce poza unijnym
‫systemem plików kontenera do przechowywania unikatowych danych.
‫Zachowuje to w przypadku usuwania kontenerów i pozwala nam dołączyć je do dowolnego kontenera, który chcemy.
‫A kontener widzi go po prostu jako lokalną ścieżkę do pliku.
‫Następnie mamy bind mounty, które po prostu dzielimy się lub montujemy katalog hosta lub plik do kontenera.
‫Znowu będzie wyglądać jak lokalna ścieżka do pliku lub ścieżka katalogu do kontenera.
‫W rzeczywistości nie będzie wiedział, że pochodzi od hosta.