Docker umożliwia uruchamianie procesów w odizolowanym środowisku nazywanym kontenerem. Kontener dostarcza procesowi wszystkich zależności, czyniąc z niego autonomiczną jednostkę wykonującą określoną funkcję.
W tym wpisie zostały opisane: zastosowanie Dockera, jego podstawy działania i różnice pomiędzy wirtualną maszyną.
* Zachęcamy również do zapoznania się z odświeżonymi w grudniu 2021 i styczniu 2022 artykułami nt. Dockera, które znajdziecie pod tym wpisem.
Zastosowanie
Docker to zbiór narzędzi, które umożliwiają:
- Podział systemów informatycznych na niezależne komponenty, nazywane kontenerami.
- Zarządzanie kontenerami.
- Automatyzację procesów związanych z wdrażaniem skonteneryzowanego oprogramowania.
Kontener to centralne pojęcie Dockera. Jego pełne zrozumienie wymaga czasu. Na tym etapie kontener można pojmować jako komponent systemu informatycznego, który pełni pojedynczą funkcję w jego architekturze, czy serwer bazy danych, serwer http.
Z racji swojej lekkości i specjalizacji kontenery naturalnie sprawdzają się w tworzeniu systemów o architekturze zorientowanej na mikrousługi [1]. Kontenery nie redukują złożoności systemów, a jedynie przenoszą ją w inne miejsce. Ponadto dekompozycja systemu na mikrousługi może wiązać się ze zwiększonymi nakładami na utrzymanie i testowanie. W porównaniu z systemami o architekturze monolitycznej lub zorientowanej na usługi zastosowanie kontenerów pozwala uzyskać większą elastyczność, wydajność i łatwość skalowania.
Kontenery działają tak samo niezależne od oprogramowania (ang. platform agnostic) jak i urządzenia (ang. hardware agnostic), na którym są uruchomione. Skonfigurowane środowisko komunikujących się ze sobą komponentów może zostać uruchomione za pomocą jednego polecenia. Dzięki temu rozpoczęcie pracy ze skonteneryzowanym projektem odbywa się bez dodatkowych nakładów pracy ze strony nowych członków zespołów projektowych.
Powiązane technologie
Warunkiem korzystania z Dockera jest posiadanie 64-bitowego systemu z rodziny Linux z jądrem w wersji co najmniej 3.10.
Docker w dużej mierze wykorzystuje już istniejące rozwiązania stosowane w systemach z rodziny Linux:
- Grupy kontrolne i przestrzenie nazw.
- Kontenery Linuxa.
- Ujednolicony system plików.
Przestrzenie nazw (ang. namespaces) i grupy kontrolne (ang. cgroups) pozwalają na zarządzenie dostępem do zasobów systemowych (procesor, pamięć, sieć itd.) przez poszczególne procesy.
Kontenery linuxa (LXC, ang. Linux Containers) pozwalają na uruchomienie wielu systemów gości w obrębie jednego systemu gospodarza, zarządzanie ich zasobami (cgroups) i odizolowanie ich od systemu operacyjnego (namespaces). Docker wprowadził nowy format kontenerów: runC, który implementuje standard OCF (ang. Open Container Format) [1, 2, 3, 4].
Ujednolicony system plików (UFS, ang. Union File System) umożliwia zarządzanie plikami i katalogami pochodzącymi z różnych systemów plików tak jakby stanowiły jeden system plików. Ujednolicony system plików jest budowany warstwowo. Jeżeli dwa składowe systemy plików zawierają zasób o takiej samej ścieżce, wtedy zasób z systemu zamontowanego później przykrywa zasób z systemu zamontowanego wcześniej.
Architektura
Podstawowymi komponentami Dockera są: demon Dockera, komunikujący się z nim klient i repozytorium obrazów.
Demon Dockera jest odpowiedzialny za zarządzanie obrazami i kontenerami, np.: pobiera obrazy z repozytorium, buduje obrazy, uruchamia kontenery.
Klient Dockera umożliwia wydawanie poleceń demonowi. Komunikacja pomiędzy klientem a demonem odbywa się za pomocą protokołu HTTP. W przypadku komunikacji lokalnej wykorzystywane są do tego gniazda UNIX, a w przypadku komunikacji zdalnej gniazda TCP.
Repozytorium obrazów przechowuje obrazy kontenerów Dockera. W ekosystemie Dockera znajduje się jedno oficjalne repozytorium (docker hub). Zawiera ono oficjalne obrazy oraz obrazy udostępnione przez innych użytkowników. Istnieje również możliwość uruchomienia prywatnego repozytorium.
Kontener a wirtualna maszyna
Kontenery Dockera, w porównaniu z wirtualnymi maszynami, pozwalają osiągnąć istotnie niższe zużycie pamięci dyskowej i niższe czasy uruchomienia. Obie te zalety zostały osiągnięte kosztem zmniejszenia izolacji pomiędzy kontenerami i systemem gospodarza.
Niższe zużycie pamięci dyskowej jest możliwe dzięki współdzieleniu warstw UFS pomiędzy kontenerami. Załóżmy, że mamy obraz kontenera zajmujący 1 GB oraz obraz wirtualnej maszyny o takim samym rozmiarze. Jeżeli chcielibyśmy za ich pomocą stworzyć n wirtualnych maszyn i n kontenerów to w przypadku wirtualnych maszyn potrzebowalibyśmy n GB, a w przypadku kontenerów 1 GB. Kontenery są w stanie współdzielić warstwy UFS obrazów (warstwy tylko do odczytu). Jedyny narzut pamięci dyskowej, jaki niesie ze sobą kontener jest związany ze zmianami, jakie wprowadza do obrazu, na podstawie którego został stworzony. Zmiany te zapisywane są w warstwie kontenera (warstwa do odczytu i do zapisu) i w większości przypadków są to dane generowane przez proces uruchomiony w kontenerze lub zależności potrzebne do jego uruchomienia.
Niższe czasy uruchomienia są możliwe poprzez współdzielenie jądra systemu pomiędzy kontenerami, a systemem gospodarza. Dzięki temu rozwiązaniu kontenery nie są obarczone narzutem czasowym związanym z uruchomieniem wirtualnej maszyny i działaniem hipernadzorcy. Wszystkie operacje wykonywane w kontenerze są niemal tak samo wydajnie jakby były wykonywane w systemie gospodarza. Współdzielenie jądra systemu jest przyczyną, przez którą kontenery mogą działać tylko w oparciu o dystrybucje systemów z rodziny Linux.
* Zaktualizowane w 2021 i 2022 artykuły nt. Dockera
- Docker dla programistów: co to jest?
- Docker dla programistów – budowa pierwszego środowiska. Część I
- Docker dla programistów – budowa środowiska rozwojowego. Część II
- Docker dla programistów – dystrybucja aplikacji
Co dalej?
Kolejna seria postów dostępna od 10.02.2016
Zostaw komentarz