Wprowadzenie do konteneryzacji #1

Od pewnego czasu podczas niemal każdej rozmowy o infrastrukturze IT pada słowo kontener, konteneryzacja itd. Temat jest zaiste gorący, więc postanowiłem zebrać moje notatki związane z tą tematyką, które od ponad dwóch lat walają się po szufladach i różnych zakamarkach mieszkania. Oczywiście nie uda mi się opisać wszystkiego, co jest związane z kontenerami, ale myślę, że ci, którzy zaczynają przygodę z Dockerem, bo o nim głównie będzie ten tekst, na pewno znajdą coś interesującego.

Zacznijmy od tego, co oznacza samo słowo Docker – jest ono zbitką wyrazową dwóch słów Dock (port) i Worker (pracownik) złączenie tych słów daje skrótową nazwę pracownika portowego. Pod tym hasłem kryją się dwie rzeczy. Pierwszą z nich jest firma Docker Inc., która stoi za rozwojem platformy konteneryzacyjnej o tożsamej nazwie… Mamy firmę i mamy produkt o tej samej nazwie, produkt który nie jest jednolity, a składa się z elementów tworzących The Docker Platform, w skrócie nazywaną Docker.

Zatem Docker odpowiedzialny jest za dostawę kontenerów przy użyciu dostępnej mu platformy. Składowe platformy Docker pochodzącej od firmy Docker Inc. to między innymi Docker Engine (silnik), czyli coś, co pozwoli nam uruchamiać kontenery, Docker Swarm (Rój), czyli system klastrowania i orkiestracji silników, Docker Registry (Rejestr), czyli swoista baza danych zawierająca obrazy kontenerów, Docker Universal Control Plane (tylko w wersji płatnej) będący naszym oknem do graficznego zarządzania platformą. Istnieje jeszcze kilka mechanizmów w samej platformie, ale na początek wystarczy te kilka. Generalnie Platforma Docker występuje w dwóch wariantach – darmowym, gdzie możecie znaleźć wsparcie w społeczności, nazywa się ona Docker Community Edition (CE), oraz w płatnym, czyli Docker Enteprise Edition (EE), gdzie otrzymujemy wsparcie na produkty od samego Docker Inc. i nieco bogatsze wersje Docker Engine wyposażony w m.in. wspomniany Docker Universal Control Plane. Platforma Docker jest fragmentem ogromnego ekosystemu, który wyrósł wokół konteneryzacji.

Ogrom narzędzi może na początku przerażać, ale nie ma co panikować nie wszystkich z nich musimy używać. Wiele z nich spełnia bardzo konkretne funkcje, które są zupełnie niepotrzebne na początku przygody z Dockerem, a jedynie mydlą oczy i rodzą pewną dozę niepewności. Niema się co jednak martwić i warto wystartować z możliwie jak najprostszym stosem technologicznym i w czasie go rozbudowywać o niezbędne funkcje i oprogramowanie, które będzie je realizować. Tymczasem kto używa Dockera? Wielu z Was może to zaskoczyć, ale lista jest sroga: Netflix, General Electric, BBC, Lyft, Spotify, Ebay, Yelp, Box, Expedia, New York Times, Business Insider, PayPal, Shopify i Uber. To tylko wycinek, ale pokazujący, że nie jest to tylko produkt przeznaczony dla StartUp’ów, a duże organizacje również go wdrażają. Warto tutaj również wspomnieć, że Docker może być uruchamiany natywnie w chmurze – dostawcy Cloud tacy jak AWS, Azure czy Google mają dedykowane do tego serwisy. Więc posiadając już lokalną instalację Docker można bez problemu migrować się do Chmury, gdy przyjdzie taki czas lub chęć w organizacji. Nie zamyka się żadnych drzwi. Można startować u sobie na laptopie, w serwerowni na gołych blachach, w maszynach wirtualnych lub w chmurze. Ważne jest również to, że Docker działa zarówno na platformie Linux, jak i Windows. Jednak należy dokładnie zapoznać się z różnicami, jakie są pomiędzy tymi wydaniami Dockera, bo są i czasami mogą być zaskakująco duże. Niemniej jednak Docker na platformę Windows jest i działa, więc należy zdementować plotkę, że kontenery są tylko dla użytkowników Linux.

Docker, docker, docker… to jednak nie wszystko! Tak jak już sobie wspomnieliśmy o szaleńczo wielkim ekosystemie aplikacji dookoła konteneryzacji to wydaje się, że dobrze aby wybrzmiało iż istnieją również inne platformy np. RKT, czyli Rocket stworzony przez firmę CoreOS. Myślę, że wielu z Was wzdrygnęło się od razu, że istnieje alternatywa. Z jednej strony to dobrze – konkurencja jest dla nas, konsumentów technologii, zawsze plusem, bo jak to mówi staropolskie przysłowie: gdzie dwóch się bije, tam trzeci korzysta. Jednak to nagłe zniesmaczenie może wynikać z tego, że jak jest dwóch dostawców to, pewnie istnieją dwa standardy… Otóż nie! Świat konteneryzacji nie popełnił tego samego błędu co równi poprzednicy w IT – jak tylko pojawiły się dwa standardy za chwilę dostawcy usiedli do stołu i powołali organizację The Open Container Initiative, która to jest odpowiedzialna za nadzorowanie jednego standardu, tak aby developer mógł dostarczyć aplikację w jednym formacie, a dział IT mógł ją uruchomić na wybranej przez siebie platformie bez potrzeby konwersji. Warto dodać, że organizacja ta działa pod The Linux Fundation.

Wszytko dla aplikacji! Zacznijmy od tego hasła, ponieważ w zasadzie ono jest katalizatorem zmiany w IT, której jesteśmy świadkiem. Dawno temu w czasach gdy świat był prosty, a kasa się nie liczyła, brano jeden fizyczny serwer i pakowano na niego system operacyjny i jedną aplikację. Przyszli księgowi i stwierdzili, że „hajs się musi zgadzać” i rozpoczęto poszukiwanie rozwiązania, w którym dałoby się na jedynym serwerze uruchomić więcej aplikacji. Stwierdzono, że wirtualizacja będzie rozwiązaniem. Przez kilka lat to wystarczało. Następnie stwierdzono, że nie było to niestety przy każdym rozwiązaniu perfekcyjne wyjście. Otóż pamiętajmy, że wszystko dla aplikacji natomiast w modelu VM skupiamy się bardzo mocno na systemach operacyjnych – jedna VM jeden OS… Czasami jest to wymagane, ale czasami jednak im lżejszy system, tym lepiej. Operując dalej na analogii dotyczącej wirtualizacji, można przyjąć, że posiadając serwer fizyczny instalujemy hypervisor, może to być VMware vSphere, Microsoft, Hyper-V, KVM, XEN itd. niema to większego znaczenia. Zwyczajnie warstwę fizyczną „smarujemy” warstwą wirtualizacyjną i jaka by ona nie była pozwala nam na dzielenie zasobów fizycznego serwera na maszyny wirtualne. Następnie w każdej maszynie wirtualnej instalujemy system operacyjny Windows lub Linux. Kolejną warstwą są serwisy, które umożliwiają nam uruchomienie naszych aplikacji, ogólnie wygląda to mniej więcej tak:

Nie trzeba być geniuszem, żeby stwierdzić, że mamy tutaj całkiem dużo powielonych elementów, a hypervisor wydaje się międźymordziem, które nie do końca jest w pewnych scenariuszach potrzebne. Nie mówię tutaj, że idea wirtualizacji jest zła, proszę tego tak nie zrozumieć. Wirtualizacja dała nam bardzo dużo i niema co z tym dyskutować, aczkolwiek jak popatrzymy na ten powyższy rysunek to aż korci, aby warstwę hypervisora, VM i OS w jakiś sposób zoptymalizować… W skrócie – najlepiej jakby ich nie było, ale pozostały wszystkie zalety ich istnienia. Takie rozwiązanie w stylu mieć ciasteczko i zjeść ciasteczko. Tu właśnie pojawiają się idea kontenerów, która jest swoistym kompromisem w optymalizacji – nie likwidują wszystkiego, ale ograniczają ilość elementów. Zatem czym są kontenery? Ujmijmy to tak, bardzo ogólnie można je przyrównać do swoistych VM, czyli środowiska do uruchamiania aplikacji, w którym to ograniczono system operacyjny do niezbędnego minimum. Jeżeli pamiętacie jeszcze czasy jaila albo chroota… wiem, że to przełom jury/ordowika IT, ale może ktoś tam jeszcze jest 😉 To poniekąd wiecie, co to są kontenery. Dobrze, ale skończmy z ta geriatrią i weźmy powyższy schemat i zmodyfikujmy go tak, aby pokazywał ramową architekturę środowiska konteneryzacyjnego:

Już na pierwszy rzut oka widać zasadniczą różnicę – brak hypervisora i pojawienie się małych kontenerów. Zatem co się wydarza? Otóż warstwa hypervisora nie jest wymagana, a warstwa systemu operacyjnego jest zunifikowana dla wszystkich aplikacji. Wprowadźmy zatem pewne nazewnictwo, system operacyjny w kontekście konteneryzacji nazywany jest „Hardware Land” i uruchamiany w nim jest program nazywany „Docker Engine” silnik ten umożliwia uruchamianie „Docker Image” – obrazów zawierających aplikację. Obracając się w naszej analogii do wirtualizacji, Docker Engine jest swoistym serwisem uruchamiającym na Hardware Land będącym hypervisorem Docker Image, czyli maszyny wirtualne.

Artykuł został opublikowany na łamach IT Professional.

• Wprowadzenie do konteneryzacji #2
• Wprowadzenie do konteneryzacji #3