docker tworzenie obrazow banner

Kurs Docker #01: Wstęp i Architektura

Podziel się z innymi!

Jak wiadomo świat IT od zawsze dąży do optymalizacji kosztów. Przykładem miejsca gdzie szukamy optymalizacji, jest infrastruktura IT, którą wykorzystuje się do utrzymywania systemów. Przede wszystkim znamy wirtualizacje, która uruchamia „wiele systemów operacyjnych” na jednym komputerze/serwerze. Takie podejście przyczynia się do ograniczenia potrzebnych zasobów dla systemów IT i ułatwia zarządzanie nimi. Jak już wspomniałem proces poszukiwania bardziej optymalnych metod zarządzania infrastrukturą IT jest ciągły. Kolejnym krokiem po wirtualizacji jest konteneryzacja. Główną technologią kontenerową którą każdy powinien bezsprzecznie znać jest Docker.

Post ten zaczyna cykl w którym omówię główne zagadnienia związane z Docker’em – wszystko w formie ogólnodostępnych wpisów na blogu. Aktualnie jestem świeżo po zdaniu egzaminu Docker Certified Associate (DCA). Jeżeli chcesz nauczyć się Docker’a, cykl ten napewno okażę się pomocny. Jeżeli masz jakieś pytania co do samego egzaminu, możesz dać znać poprzez guzik „Kontakt Email” znajdujący się u góry po prawej stronie 🙂 Aby być na bieżąco z nowymi wpisami zapisz się na Newsletter!

Maszyna wirtualna vs kontener

Wirtualizacja mimo że tak pomocna, ma pewne wady względem konteneryzacji, które łatwo zauważyć już na powyższym rysunku. Każda maszyna wirtualna musi posiadać oddzielny system operacyjny. W przypadku używania tego samego systemu operacyjnego w maszynach wirtualnych, komponenty tego systemu są uruchomione wielokrotnie na hoście, to poważne marnotrastwo zasobów! Gdy mamy np. 8 maszyn wirtualnych, mamy 8 systemów operacyjnych pracujących na podzespołach naszej maszyny. Zastosowanie wirtualizacji ma sens kiedy, aplikacja którą uruchamiasz jest silnie zależna od jądra systemu operacyjnego, wtedy oddzielne maszyny wirtualne pozwalają odpalać aplikacje na różnych systemach operacyjnych i różnych jądrach, w obrębie jednego hosta fizycznego.

Konteneryzacja podchodzi do zagadnienia inaczej. Zamiast hipervisor’a obsługującego proces wirtualizacji, mamy zwykły sytem operacyjny z doinstalowanym silnikiem konteneryzacji. Silnik ten obsługuje wszystko co robią kontenery, które w konteneryzacji są odpowiednikiem maszyn wirtualnych. Wszystkie kontenery na danym hoście korzystają z wspólnego jądra, dokładnie tego samego z którego korzysta system operacyjny hosta. W przypadku systemów z rodziny Linux, konkretna dystrybucja systemu jest de facto strukturą katalogów systemu plików, dlatego nie ma problemu z tym aby każdy kontener w obrębie hosta pracował na swojej dystrybucji linux’a wykorzystując swoje pliki binarne i biblioteki. Konteneryzacja wprowadza ogromną oszczędność zasobów. Można powiedzieć, że kontener konsumuje dokładnie tyle zasobów ile aplikacja w nim uruchomiona.

Różnicą na minus kontenerów jest potencjalnie gorsza separacja procesów aplikacji, niż w przypadku maszyn wirtualnych. W przypadku linux’a obsługiwana jest przez funkcję jądra takie jak: namespace’y, control groups i union filesystems, omówię je szerzej nieco później.

Docker

Docker wywodzi się z platformy PaaS nazywanej dotCloud. W obrębie tej usługi zbudowano całe zaplecze do powoływania kontenerów, mechanizmy w nim zawarte dostały przydomek Docker. Z powodu perturbacji finansowych organizacja zmieniła nazwę na Docker Inc., postanawiając jednocześnie ustanowić Docker’a swoim nowym głównym produktem 🙂

Aktualnie firma Docker Inc. świetnie sobie radzi, do tego stopnia że co roku organizuje konferencje DockerCon. Zbiera ona wszystkich pasjonatów tej technologii. Jeżeli chcesz być na bieżąco z zmianami w Docker, myślę że warto zapoznawać się nawet online z tym, co w danym roku było prezentowane na DockerCon’ie.

Sam Docker występuje w dwóch wersjach:

  • Enterprise Edition (EE)
  • Community Edition (CE)

Każda z wersji dostaje poprawki co kwartał. Community Edition ma 4 miesięczny okres wsparcia, Enterprise Edition 12 miesięczny.

Oznaczenia wersji Docker, zachowują format YY.MM-xx na przykład:

  • 19.03.0-ce dla Community Edition wydanej w marcu 2019 i nie posiadającej narazie dodatkowych patchy
  • 19.03.0-ee dla Enterprise Edition Edition wydanej w marcu 2019 i nie posiadającej narazie dodatkowych patchy

Docker ma budowę modułową, składa się z komponentów OpenSource. Założenia co do budowy tychże komponentów opisane są w standardzie stworzonym przez Open Container Initiative (OCI).

Wersja Enterprise(płatna) dodaje:

  • wsparcie producenta w przypadku użycia certyfikowanych systemów, operacyjnych takich jak RHEL czy Windows Server
  • konsole graficzną Universal Control Plane (UCP)
  • dostęp do registry również z panelem graficznym – Docker Trusted Registry(DTR)
  • rozszerzenie opcje bezpieczeństwa takie jak konta użytkowników i RBAC
  • zintegrowanego Kubernetes’a(K8s) którym możemy zarządzać z poziomu UCP

Architektura Docker

Docker Inc. dąży do jak największej modularności Docker‚a. Stopniowo wydzielane kolejne funkcjonalności tak by główny proces Docker Daemon zajmował się tylko organizacją pracy pozostałych komponentów. Z powodu takiego podejścia aktualna architektura Docker’a, gdzie całe środowisko uruchomieniowe kontenera jest wydzielone do oddzielnych komponentów, prezentuje się następująco:

docker architektura
KomponentFunkcja
Klient DockerPobieranie komend od użytkownika – CLI
Docker DaemonWystawianie API
containerdZarządzanie cyklem życia kontenerów
shimUmożliwia uruchamianie kontenerów headless
runcRuntime kontenerów – komunikacja z jądrem systemu hosta
KontenerWykonuje kod aplikacji
Komponenty Docker

runc

runc jest implementacja środowiska uruchomieniowego dla kontenerów, zgodnego z OCI. Komponent ten to nic innego jak kawałek CLI który obsługuje działania biblioteki libcontainer. Oficjalna strona projektu znajduję się na –> GitHub.

Jedynym i najważniejszym zadaniem runc jest powoływanie nowych zgodnych z OCI kontenerów do życia. Narzędzie to jest samowystarczalne, istnieje możliwość używania go bez całej otoczki związanej z Docker.

containerd

containerd jest komponentem w którym zawarta jest logika cyklu życia kontenerów. Co w chodzi w skład tejże logiki? Na przykład operacje takie jak: start, stop, pauza czy usunięcie kontenera.

shim

shim dodaje do stosu funkcjonalność pozwalająca na prace kontenerów bez porozumiewania się z runc. Z tego powodu można wykonywać upgrade Docker’a bez potrzeby zatrzymywania działających kontenerów 😀

Od strony systemu operacyjnego Linux, wyżej wymienione komponenty występują jako procesy:

  • dockred
  • docker-containerd
  • docker-containerd-shim
  • docer-runc

Docker daemon

Funkcjonalności które nadal pozostają w samym Docker Daemon’ie to:

  • zarządzanie obrazami(pomimo że aktualna implementacja containerd posiada tą funkcjonalność)
  • budowanie obrazów
  • obsługa REST API
  • autentykacja
  • bezpieczeństwo
  • obsługa sieci

Obrazy Docker

Każdy kontener jest uruchamiany z obrazu. Obraz taki przechowuje strukturę plików, która będzie widoczna w kontenerze po uruchomieniu go z danego obrazu. W plikach tych występują zarówno pliki systemu operacyjnego jak i te specyficzne dla konkretnej skonteneryzowanej aplikacji. Temat obrazów Docker z czego się składają, jak je budować i jak nimi zarządzać zostanie poruszony w kolejnej części kursu.

Registry Docker’a

Obrazy trzeba gdzieś przechowywać, od tego właśnie jest Docker Registry. Registry jest lokalizacją zdalną z której i do której możemy wysyłać nasze obrazy. To rodzaj magazynu w którym obrazy „leżą” w sposób uporządkowany, czekając na pobranie. Najbardziej znanym publicznym registry jest –> Docker Hub, lecz nic nie stoi na przeszkodzie aby skonfigurować sobie własne registry, co ciekawe uruchamiane jest ono również w postaci kontenera.

Izolacja kontenerów

Namespace’y

Podstawą izolacji w konteneryzacji jest technologia namespace. Gdy tworzymy nowy kontener, tworzymy de facto zestaw namespace’ów. Każda przestrzeń nazw ogranicza widoczność komponentów tylko do jej zawartości. Typy namespace używane w Docker to:

  • pid – process ID – izolacja procesów PID
  • net – Networking – izolacja stosu sieciowego
  • ipc – InterProcess Communication – izolacja socketów
  • mnt – Mount – izolacja punktów montowania
  • uts – Unix Timesharing System – izolacja hostname

Podsumowując, tworzysz kontener, dostaje on własne namespace’y w każdej z wyżej wymienionych kategorii. Co za tym idzie, dla przykładu, kontener:

  • pid – ma własny zestaw pid’ów procesów – dlatego też główna aplikacja odpalona w kontenerze dostaje pid 1
  • net – ma własny stos sieciowy – dlatego miedzy innymi – localhost na kontenerze, nie jest tym samym, co localhost na hoście na którym znajduje się ten kontener
  • mnt – ma własne punkty montowania – dlatego też możesz w kontenerze zamontować zasób pod /mnt/backup, nawet jeżeli taki punkt montowania nie istnieje na hoście na którym znajduje się ten kontener

Cgroups

Control grup‚y odpowiedzialne są ze ograniczenie zużycia zasobów przez kontenery. Możesz powiedzieć na przykład, że dany kontener nie może zużyć więcej niż 1GB RAM.

Union File System

Inaczej nazywany UnionFS’em, jest systemem plików pozwalającym obsługiwać warstwy. Jest on stosunkowo lekki i szybki. Będę jeszcze o nim mówił w kolejnych częściach kursu.


Podziel się z innymi!

docker mockupNewsletter!

Co zyskujesz?

Dostajesz zupełnie za darmo ściągę z poleceniami Docker!

Jesteś na bieżąco z nowymi artykułami!

Dowiesz się pierwszy kiedy pojawi się nowy kurs!