Docker jest najpopularniejszym na świecie system, który służy do konteneryzacji aplikacji. Konteneryzacja to izolowanie procesów od procesów hosta, co pozwala na duże bezpieczeństwo i wygodę pracy.
Jeśli jesteś wiernym czytelnikiem mojego bloga, na pewno kojarzysz artykuł „LXC, czy Docker: Jaka jest różnica?”. Jeśli nie kojarzysz, zalecam pierw nadrobić, bo teraz skupimy się na mięsie technologi.
Historia kontenerów w pigułce i bardzo zwięźle
Niczym biblijne początki, na początku był baremetal, czyli aplikacje i wszystko inne instalowaliśmy na fizycznym serwerze, gdzie był system operacyjny, itd. Jednak to ograniczało możliwości rozwoju, a także było marnotrawstwem zasobów. Następnie nastały maszyny wirtualne, gdzie wydzielaliśmy fragment fizycznych zasobów i takich serwerów VPS mogło być dziesiątki i setki. Każdy z innym system, bibliotekami i aplikacjami. Jednak to było ciężkie rozwiązanie, bo wiązało się z narzutem technologii (np.: wirtualizacja zasobów, kernel osobny, itd). Powstały w końcu kontenery, czyli „lekkie wirtualne maszyny”. Po drodze były Jaile z FreeBSD, czy chroot, ale to pominę.
W kontenerach korzystamy głównie z dwóch technologii, dostępnych w systemie Linux. Pierwszym są namespace. Ta funkcja w kernelu pozwala na oddzielanie (izolowanie) procesów. Dzięki temu jedna grupa (kolekcja) procesów mogła nie widzieć (i tym samym wpływać) na inne procesy. Takie rozwiązanie wykorzystuje np.: Google Chrome do zwiększenia bezpieczeństwa. Drugą ważną kwestią są cgroups, czyli grupy kontrolne. Pozwala to limitować zasoby dla kolekcji procesów, np.: RAM, czy miejsce na dysku.
Z połączenia tych dwóch świetnych rozwiązań (namespace powstał w 2002, cgroups w 2007), powstały technologie takie jak OpenVZ, LXC (i LXD), a także tytułowy Docker.
Docker pierw bazował na swojej implementacji konteneryzacji, jednak z czasem, gdy się rozpowszechnił, a chmura opanowała świat IT, powstała otwarta implementacja, czyli CRI-O (containerd). Dzięki temu kontenery Dockera są kompatybilne z podmanem, rkt i innymi rozwiązaniami. Co to oznacza? Docker aktualnie to tylko interfejs to zarządzania containerd.
Trudne? Moim zdaniem tak, a jeśli ktoś nie pilnował tematu, tak jak ja, próg wejścia w te niskopoziomowe tematy są dosyć wysokie. Na szczęście to koniec trudnych tematów.
Docker — jak z niego się korzysta?
Docker (jak i inne rozwiązania aktualnie bazujące na containerd) tworzą na podstawie pliku gotowy obraz w postaci warstw. Celem oszczędności miejsca na dysku, warstwy mogą być współdzielone. Co też przyspiesza budowanie obrazów. Przykładem, co to rozwiązuje, jest np.: uruchomienie WordPressa (np.: bloga CzarnaOwca), a także obok sklepu internetowego z wełną (taki żarcik). System może być ten sam, interpreter też, więc zmienia się tylko aplikacja, prawda? Więc współdzielimy warstwę systemu, interpretera, a jedynie została warstwa aplikacji inna. Oszczędzamy przynajmniej kilkaset megabajtów, a aplikacje są od siebie odizolowane lepiej niż na jakimkolwiek hostingu.
Docker posiada dwa sposoby zarządzania zasobami. Poprzez CLI oraz REST API. W sumie to CLI łączy się do API.
API korzysta się w kilku sytuacjach, np.: tworzenia rozwiązań dla stricte Dockera (np.: dodatkowe narzędzia typu watchtower) lub do monitoringu (a to też nie jest zbytnio konieczne).
A w 99% korzystamy z Docker CLI oraz jego rozszerzenia: Docker Compose.
Kontener, obraz, rejestr obrazów — ale o co chodzi? Słownik pojęć.
Od początku artykułu użyłem sporo nowych słów, które jeszcze nie tak dawno w informatyce raczej nie występowały lub miały zbliżone znaczenie, jednak nie były dla nas jako użytkowników tożsame.
Pierw kwestie, co nie ulegają zmianie już po powstaniu
Zacznijmy od elementarnej części konteneryzacji, czyli obrazu. Obraz jest zbudowanym, gotowym do uruchomienia systemem. Porównam go do LiveCD Linuxa lub klonowanego dysku z systemem. Bierzemy taki obraz i uruchamiamy — a pojawi nam się gotowy system operacyjny, który możemy już używać i na nim pracować. Tak samo jak LiveCD, po wyłączeniu systemu tracimy dane, gdyż nasz obraz nie można „nadpisać”.
Obraz jest budowany przy pomocy specjalnych reguł w pliku Dockerfile. Np.: instalujemy potrzebne pakiety, czy umieszczamy w obrazie naszą aplikację.
Rejestr obrazów jest biblioteką takich gotowych do pracy obrazów. Znajdziemy tam podstawowe systemy jak Debian, Ubuntu czy Alpine, ale również już wyspecjalizowane obrazy takie jak Apache, MySQL, czy Nginx. Rejestr możemy posiadać swój prywatny, np.: przy pomocy Gitlab, obrazu registry:2, czy projektowi Harbour, albo korzystać z dostępnych ogólnie takie jak Docker Hub, Github Container Registry, czy Quay.io
W końcu dynamiczniej, czyli kontenery
Po uruchomieniu obrazu tworzony jest kontener i w nim są uruchamiane aplikacje. Możemy uruchomić naszą aplikację lub coś innego. Jednak jak wspomniałem, kontenery nie utrzymują danych, więc po jego usunięciu (a to będziemy robić regularnie, o czym wspomnę również w innym czasie), dane nasze utracimy.
Z tego powodu korzystamy z wolumenów. Wolumeny mogą być różnego rodzaju filesystemem, ale najczęściej montujemy wolumen do kontenera z naszego systemu. Dzięki temu, np.: po usunięciu kontenera z bazą danych, nie utracimy danych i w każdym momencie możemy utworzyć nowy kontener i podmontować te dane. Podobnie w sytuacji, gdy potrzebujemy korzystać z tych samych danych w kilku kontenerach. Montujemy je i problem z głowy.
Tematy sieciowe kontenerów to temat na osobną książkę, ale w dużym skrócie. Kontenery są odizolowane, więc są „za siecią NAT”. Mają dostęp do internetu, ale nie mają dostępu do hosta (izolacja) oraz nie mają dostępu do innych kontenerów. By np.: WordPress w kontenerze mógł się połączyć do bazy MySQL w innym kontenerze — musimy je spiąć w sieci lub bezpośrednio łączyć ze sobą.
Staramy się też, by kontenery tak jak funkcje w programowaniu — wykonywały określone czynności. Dlatego nie stawiamy tradycyjną metodą nginx, php-fpm oraz bazę danych MySQL na jednym kontenerze/vps. By uruchomić WordPressa, to osobno uruchamiamy nginx. W innym kontenerze jest WordPress z php-fpm. W kolejnym jest MySQL. Te kontenery spinamy w jedną sieć lub kilka sieci (odpowiednio izolując, bo w sumie, po co nginx ma mieć dostęp do MySQL).
Docker – Podsumowanie
Jak widać, sporo jest tematów do poznania i zrozumienia. Skoro dotarłeś drogi czytelniku lub droga czytelniczko do tego etapu, to zapraszam do instalacji i przetestowania samodzielnie rozwiązania 🙂
A teraz zapraszam na drugi etap nauki 🙂
