Читать книгу Docker w praktyce - Ian Miell - Страница 20

Warstwy Dockera pomagają radzić sobie z problemami, które pojawiają się podczas używania kontenerów na dużą skalę. Wyobraźmy sobie, co by się stało, gdybyśmy uruchomili setki, a nawet tysiące aplikacji to-do, a każda z nich wymagałaby, aby kopie plików były gdzieś ­przechowywane.

Jak można sobie wyobrazić, miejsce na dysku skończyłoby się dość szybko! Domyślnie Docker wewnętrznie korzysta z mechanizmu kopiowania przy zapisie, aby zmniejszyć ilość wymaganego miejsca na dysku (patrz rys. 1.9). Za każdym razem, gdy działający kontener musi zapisać coś do pliku, jest rejestrowana zmiana, przez skopiowanie elementu do nowego obszaru dysku. Gdy wykonywane jest dockerowe zatwierdzenie, ten nowy obszar dysku jest zamrażany i zapisywany jako warstwa z własnym identyfikatorem.

Rysunek 1.9. Warstwy systemu plików Dockera

To częściowo wyjaśnia, w jaki sposób kontenery Dockera mogą się uruchamiać tak szybko – nie mają nic do skopiowania, ponieważ wszystkie dane zostały już zapisane jako obraz.

WSKAZÓWKA Kopiowanie przy zapisie to standardowa strategia optymalizacji wykorzystywana w komputerach. Kiedy tworzymy nowy obiekt (dowolnego typu) z szablonu, zamiast kopiować cały wymagany zestaw danych, kopiujemy dane tylko wtedy, gdy ulegają zmianie. W zależności od przypadku użycia może to zaoszczędzić znaczne zasoby.

Rysunek 1.10 pokazuje, że zbudowana aplikacja to-do ma trzy warstwy, które nas interesują. Warstwy są statyczne, zatem jeśli chcemy zmienić cokolwiek w wyższej warstwie, możemy po ­prostu to zbudować na górze obrazu, który przyjęliśmy za punkt odniesienia. Aplikację to-do zbudowaliśmy na bazie publicznie dostępnego obrazu node i warstw ze zmianami powyżej.

Rysunek 1.10. Warstwowy system plików todoapp w Dockerze

Wszystkie trzy warstwy mogą być współużytkowane przez wiele działających kontenerów, podobnie jak wspólna biblioteka może być współdzielona w pamięci przez wiele działających procesów. Jest to istotna cecha sposobu działania, pozwalająca na uruchamianie wielu kontenerów opartych na różnych obrazach na maszynach hostów, przy zmniejszeniu ryzyka wyczerpania miejsca na dysku.

Wyobraźmy sobie, że uruchamiamy aplikację to-do jako rzeczywistą dla opłacających usługę klientów. Możemy skalować naszą ofertę dla dużej liczby użytkowników. Jeśli jesteśmy w trakcie tworzenia, możemy jednocześnie uruchomić wiele różnych środowisk na komputerze lokalnym. Jeśli przeprowadzamy testy, możemy uruchomić ich jednocześnie o wiele więcej i znacznie ­szybciej niż do tej pory. Wszystkie te czynności są możliwe dzięki warstwowaniu.

Budując i uruchamiając aplikację za pomocą Dockera, zaczęliśmy dostrzegać siłę, jaką może on wnieść do naszego przepływu pracy. Reprodukcja i udostępnianie specyficznych środowisk oraz możliwość umieszczania ich w różnych miejscach daje zarówno elastyczność, jak i kontrolę nad rozwojem.

Podsumowanie

 Docker to próba zrobienia dla oprogramowania tego, co konteneryzacja zrobiła dla branży żeglugowej: zredukowanie kosztów lokalnych różnic przez standaryzację.

 Niektóre z zastosowań Dockera obejmują prototypowanie oprogramowania, pakowanie oprogramowania, redukowanie kosztów środowisk testowania i debugowania oraz umożliwienie praktyk DevOps, takich jak ciągłe dostarczanie.

 Aplikację Dockera na podstawie Dockerfile możemy zbudować i uruchomić za pomocą poleceń docker build oraz docker run.

 Dockerowy obraz jest szablonem do uruchamiania kontenerów. Jest to podobne do różnicy między wykonywalnym programem a uruchomionym procesem.

 Zmiany w uruchomionych kontenerach można zatwierdzać i tagować jako nowe obrazy.

 Obrazy są tworzone z warstwowego systemu plików, co zmniejsza przestrzeń używaną przez dockerowe obrazy na naszym hoście.