1 00:00:05,810 --> 00:00:10,720 ‫Ta sekcja będzie pełna wykładów i zadań wokół trwałych danych. 2 00:00:11,230 --> 00:00:16,490 ‫Najpierw omówimy problemy dotyczące trwałych danych i jak to w ogóle 3 00:00:16,490 --> 00:00:18,280 ‫stało się problemem. 4 00:00:18,290 --> 00:00:23,640 ‫Kluczowe pojęcia, które musisz zrozumieć, to idea niezmiennej infrastruktury. 5 00:00:23,810 --> 00:00:28,580 ‫A pomysł wokół kontenerów jest naturalnie efemeryczny w projektowaniu. 6 00:00:28,880 --> 00:00:36,680 ‫Omówimy te z pierwszego wykładu. Następnie zanurkujemy na objętości danych i jak te rozwiązania 7 00:00:36,680 --> 00:00:44,270 ‫rozwiązują niektóre z naszych problemów dotyczących trwałych danych. Następnie przekopamy się na mocowanie bindów i rozwiążemy 8 00:00:44,360 --> 00:00:50,660 ‫różne problemy z trwałymi danymi. Następnie przejdziemy do tej sekcji z kilkoma zadaniami dotyczącymi 9 00:00:50,720 --> 00:00:57,530 ‫sposobu zachowania danych bazy danych podczas zastępowania kontenerów dla baz danych. A potem także wokół montowania 10 00:00:57,740 --> 00:01:03,320 ‫kodu do kontenera od hosta podczas jego edycji, aby można 11 00:01:03,320 --> 00:01:11,560 ‫było uruchomić ten kod wewnątrz kontenera na żywo. Wymagania dotyczące tego pierwszego wykładu to po prostu zrozumienie, 12 00:01:11,560 --> 00:01:16,970 ‫jak uruchamiać kontenery oraz koncepcje kontenerów i obrazów, które omówiliśmy do tej pory. 13 00:01:17,050 --> 00:01:23,230 ‫Do tej pory martwiłeś się tylko tym, co jest potrzebne do uruchomienia kontenera, a nie unikatowych danych, które mogą 14 00:01:23,230 --> 00:01:24,920 ‫zostać utworzone po uruchomieniu kontenera. 15 00:01:25,840 --> 00:01:29,200 ‫Pojemniki mają być niezmienne i efemeryczne. 16 00:01:29,320 --> 00:01:34,220 ‫To są tylko wymyślne, niezrozumiałe hasła do niezmiennego, tymczasowego lub jednorazowego użytku. 17 00:01:34,480 --> 00:01:40,180 ‫Chodzi o to, że możemy po prostu wyrzucić pojemnik i stworzyć nowy z obrazu, 18 00:01:40,180 --> 00:01:40,770 ‫prawda? 19 00:01:41,790 --> 00:01:47,820 ‫Nie mówimy tu o rzeczywistym ograniczeniu pojemników, ale raczej o celu projektowym lub 20 00:01:47,820 --> 00:01:49,070 ‫najlepszej praktyce. 21 00:01:49,080 --> 00:01:54,690 ‫Jest to idea niezmiennej infrastruktury, w której nie zmieniamy rzeczy po uruchomieniu. 22 00:01:54,840 --> 00:02:00,330 ‫Jeśli zajdzie potrzeba zmiany konfiguracji, lub może zajdzie konieczność aktualizacji wersji kontenera, wówczas 23 00:02:00,330 --> 00:02:02,420 ‫ponownie wdrożymy nowy kontener. 24 00:02:02,490 --> 00:02:08,370 ‫Daje nam to ogromne korzyści w zakresie niezawodności i spójności oraz umożliwia powtarzalność zmian. 25 00:02:08,490 --> 00:02:10,350 ‫Ale jest kompromis. 26 00:02:10,350 --> 00:02:16,140 ‫Co z unikalnymi danymi, które wygeneruje Twoja aplikacja? Te bazy danych lub kluczowa wartość przechowuje, czy cokolwiek 27 00:02:16,140 --> 00:02:18,150 ‫innego, co aplikacja wypluwa w pliku? 28 00:02:18,330 --> 00:02:24,810 ‫W idealnych warunkach pojemniki nie powinny zawierać unikatowych danych zmieszanych z plikami binarnymi aplikacji. Jest to znane jako "separacja 29 00:02:24,810 --> 00:02:30,340 ‫obaw", a Docker daje nam tutaj naprawdę dużą korzyść. 30 00:02:30,450 --> 00:02:36,780 ‫Możemy zaktualizować naszą aplikację, odtwarzając nowy kontener, ze zaktualizowaną wersją naszej aplikacji, i idealnie, nasze unikalne dane są nadal 31 00:02:36,990 --> 00:02:42,530 ‫tam, gdzie muszą być i zostały zachowane dla nas, gdy nasz pojemnik został poddany recyklingowi. 32 00:02:42,540 --> 00:02:48,510 ‫Jeśli dotąd nie zauważyłeś, kontenery, z których korzystaliśmy, domyślnie były trwałe. 33 00:02:48,510 --> 00:02:53,880 ‫Wszelkie zmiany w nich faktycznie były przechowywane od nowa i restartuje dopóki nie usunęliśmy kontenera. 34 00:02:54,240 --> 00:02:57,160 ‫Tylko dlatego, że zatrzymaliśmy kontener lub zrestartowaliśmy hosta, nie 35 00:02:57,300 --> 00:03:00,030 ‫oznacza to, że zmiany w pliku kontenera znikną. 36 00:03:00,210 --> 00:03:05,910 ‫Dopiero gdy usuniemy kontener, że jego warstwa UFS zniknie, ale chcemy to zrobić w 37 00:03:05,910 --> 00:03:07,160 ‫dowolnym momencie. 38 00:03:07,170 --> 00:03:13,320 ‫Ten problem unikalnych danych jest znany w branży jako "trwałe dane", a do czasu kontenerów 39 00:03:13,320 --> 00:03:19,230 ‫tak naprawdę nie mieliśmy na to nazwy. Ponieważ, cóż, większość rzeczy, które stworzyliśmy, była trwała, tak 40 00:03:19,230 --> 00:03:24,090 ‫jak znasz te stare serwery, które używają tej starej aplikacji przez pięć, dziesięć lat lub dłużej. 41 00:03:24,270 --> 00:03:26,850 ‫Wszystko było domyślnie trwałe. 42 00:03:26,850 --> 00:03:32,400 ‫Teraz, w nowym świecie pojemników i automatycznych skalowań aplikacji, trwałe dane stwarzają wyjątkowy 43 00:03:32,400 --> 00:03:33,280 ‫problem. 44 00:03:33,420 --> 00:03:36,640 ‫Docker ma dwa rozwiązania tego problemu, znane 45 00:03:36,720 --> 00:03:42,450 ‫jako "woluminy danych" i "mocowania bindów". "Woluminy Docker to opcja konfiguracyjna 46 00:03:42,450 --> 00:03:46,620 ‫dla kontenera, który tworzy specjalne miejsce poza unijnym 47 00:03:46,620 --> 00:03:50,130 ‫systemem plików kontenera do przechowywania unikatowych danych. 48 00:03:50,210 --> 00:03:55,470 ‫Zachowuje to w przypadku usuwania kontenerów i pozwala nam dołączyć je do dowolnego kontenera, który chcemy. 49 00:03:55,940 --> 00:03:58,210 ‫A kontener widzi go po prostu jako lokalną ścieżkę do pliku. 50 00:03:58,440 --> 00:04:05,670 ‫Następnie mamy bind mounty, które po prostu dzielimy się lub montujemy katalog hosta lub plik do kontenera. 51 00:04:05,970 --> 00:04:10,470 ‫Znowu będzie wyglądać jak lokalna ścieżka do pliku lub ścieżka katalogu do kontenera. 52 00:04:10,470 --> 00:04:12,590 ‫W rzeczywistości nie będzie wiedział, że pochodzi od hosta.