Docker - czym jest i czemu warto go używać?

Narodziny Dockera

Do chwili tej prezentacji jedynie około 40 osób spoza dotCloud miało możliwość wypróbowania Dockera.

W ciągu kilku tygodni od tej prezentacji pojawiło się zaskakujące zainteresowanie projektem. Szybko został on udostępniony w modelu open source w serwisie GitHub (https://github.com/docker/docker), gdzie każdy mógł go pobrać i rozwijać. Kilka kolejnych miesięcy to okres, w którym coraz więcej osób z branży dowiedziało się o Dockerze i o tym, jak zamierza się za jego pomocą zrewolucjonizować sposób tworzenia, dostarczania i wdrażania oprogramowania. W ciągu roku prawie wszyscy w branży wiedzieli już, co to jest Docker, choć wiele osób nie było jeszcze do końca świadomych, czym on dokładnie jest i dlaczego ludzie tak się nim ekscytują.

Docker to narzędzie, które ma za zadanie uprościć tworzenie łatwego do dystrybucji artefaktu dowolnej aplikacji, wdrażanie go na dużą skalę w dowolnym środowisku oraz usprawnianie przepływu pracy i zwiększanie szybkości reagowania w organizacjach pracujących nad oprogramowaniem w modelu agile.  

 

Co obiecuje Docker

 

Choć Docker pozornie może wyglądać jak platforma do wirtualizacji, to daleko wykracza poza te granice. Mechanizmy dostarczane przez Dockera zazwyczaj kwalifikowane są do kilku różnych, silnie obsadzonych segmentów branży, wśród których znajdują się takie technologie, jak: KVM, Xen, OpenStack, Mesos, Capistrano, Fabric, Ansible, Chef, Puppet czy SaltStack. Może zwróciłeś już uwagę na to, że w liście produktów, z którymi konkuruje Docker, jest coś niezmiernie wymownego. Na przykład większość inżynierów nie powiedziałaby, że produkty służące do wirtualizacji konkurują z narzędziami do zarządzania konfiguracją, ale w obu tych dziedzinach Docker wprowadza przełomowe rozwiązania. Technologie z powyższej listy zazwyczaj doceniane są za możliwość zwiększenia produktywności i głównie to napędza zainteresowanie nimi. Docker znajduje się pomiędzy niektórymi z najbardziej przełomowych technologii ostatniej dekady.

 

Gdybyś porównał dokładnie cechy Dockera z cechami jego najlepszego konkurenta, to w każdej z tych dziedzin Docker okazałby się najprawdopodobniej średnim przeciwnikiem. W niektórych dziedzinach jest lepszy niż w innych, ale mocną stroną Dockera jest to, że jego mechanizmy obejmują szeroki zakres wyzwań napotykanych w czasie pracy. Łącząc prostotę narzędzi do wdrażania aplikacji, takich jak Capistrano czy Fabric, z prostotą administrowania, spotykaną w systemach wirtualizacji, i udostępniając narzędzia upraszczające implementację automatyzacji przepływu pracy i zarządzania, Docker oferuje bardzo użyteczny zestaw możliwości.

 

Wiele nowych technologii pojawia się i znika, dlatego pewna doza sceptycyzmu wobec najnowszych trendów jest zawsze zdrowym odruchem. Bez zagłębiania się w szczegóły łatwo byłoby zignorować Dockera jako kolejną technologię rozwiązującą kilka bardzo specyficznych problemów programistów lub zespołów utrzymania. Jeśli popatrzysz na Dockera jedynie jak na narzędzie do wirtualizacji lub wdrażania, może nie wydać się tak interesujący. Jednak Docker to dużo więcej, niż można zobaczyć na pierwszy rzut oka.

 

Dość trudnym i często kosztownym wyzwaniem jest zorganizowanie przepływu informacji i procesów pomiędzy zespołami nawet w mniejszych organizacjach. Żyjemy jednak w świecie, w którym przepływ szczegółowych informacji pomiędzy zespołami jest coraz bardziej potrzebny do osiągnięcia sukcesu. Narzędzie, które ułatwia komunikację i prowadzi do tworzenia lepszego oprogramowania, jest czymś bardzo istotnym. Dlatego właśnie warto dokładniej przyjrzeć się Dockerowi. Nie jest to panaceum na wszystko i stosowanie Dockera wymaga również rozwagi, ale stanowi on dobrą podstawę do rozwiązywania niektórych rzeczywistych problemów organizacji i pomaga firmom dostarczać lepsze oprogramowanie w krótszym czasie. Wdrożenie dobrze zaprojektowanego przepływu pracy z Dockerem może dawać większą satysfakcję zespołom technicznym, a w efekcie może przełożyć się na rzeczywiste pieniądze.

 

A więc jakie są największe bolączki firm? Trudno jest dostarczać dobre oprogramowanie w tempie wymaganym w dzisiejszym świecie, a gdy firmy zatrudniające jednego lub dwóch programistów rozwijają się i tworzą wiele zespołów deweloperów, wtedy problemy z komunikacją podczas dostarczania kolejnych wersji stają się coraz większe i trudniejsze do rozwiązania. Programiści muszą zrozumieć wiele złożonych zagadnień związanych ze środowiskiem, dla którego dostarczają oprogramowanie, a zespoły odpowiedzialne za utrzymanie muszą w coraz większym stopniu rozumieć sposób działania dostarczanego oprogramowania. Nad tym zawsze warto popracować, ponieważ prowadzi to do lepszego zrozumienia całego środowiska i tym samym wspomaga projektowanie lepszego oprogramowania. Umiejętności te jednak bardzo trudno efektywnie zwiększać, gdy tempo rozwoju organizacji rośnie.

 

Dopracowanie środowiska wykorzystywanego w każdej z firm wymaga często intensywnej komunikacji, która nie musi stanowić bezpośrednio żadnej wartości dla zaangażowanych w nią zespołów. Na przykład gdy programiści muszą prosić zespół odpowiedzialny za utrzymanie o wersję 1.2.1 pewnej biblioteki, zmniejsza to tempo ich pracy i nie wnosi bezpośrednio żadnej wartości biznesowej do firmy. Gdyby programiści mogli w prosty sposób zaktualizować wersję wykorzystywanej biblioteki, napisać kod, przetestować w nowej wersji i dostarczyć, to czas potrzebny na dostarczenie nowej wersji uległby zauważalnemu skróceniu. Gdyby osoby odpowiedzialne za utrzymanie mogły aktualizować oprogramowanie w systemie bez konieczności koordynowania tego z wieloma zespołami programistów, mogłyby robić to szybciej. Docker pomaga wprowadzić warstwę izolującą oprogramowanie, która zmniejsza problemy z komunikacją w świecie ludzi.

 

Poza pomocą w problemach z komunikacją Docker wymusza stosowanie takiej architektury oprogramowania, która wspomaga tworzenie bardziej dopracowanych aplikacji. Wprowadzana przez niego filozofia architektury skupia się na jednolitych i jednorazowych kontenerach. Podczas wdrażania całe działające środowisko starej aplikacji jest usuwane razem z nią. Żaden element środowiska aplikacji nie będzie żył dłużej niż sama aplikacja i ta prosta zasada ma duże konsekwencje. Oznacza ona, że aplikacje nie będą narażone na kontakt z przypadkowymi artefaktami pozostawionymi przez poprzednie wersje. Oznacza to także, że minimalne modyfikacje wprowadzane podczas debugowania nie będą wpływały na działanie kolejnych wersji tylko dlatego, że pozostały w lokalnym systemie plików. Oznacza to też, że aplikacje można łatwo przenosić pomiędzy serwerami, ponieważ wszystkie informacje dotyczące ich stanu muszą być zawarte bezpośrednio we wdrażanym artefakcie i pozostawać niezmienne lub być przesyłane na zewnątrz na przykład do bazy danych, pamięci podręcznej lub serwera plików.

 

Prowadzi to do tworzenia aplikacji, które nie tylko są bardziej skalowalne, ale też bardziej niezawodne. Instancje kontenerów aplikacji mogą się pojawiać i znikać, wywierając mały wpływ na działanie obsługiwanego interfejsu. Są to dobre wzorce architektoniczne, sprawdzone w aplikacjach niekorzystających z Dockera, ale budowa Dockera wymusza, by używające go aplikacje przestrzegały tych najlepszych praktyk, co jest jego zaletą.  

 

Korzyści płynące ze stosowania procesów proponowanych przez Dockera

 

Trudno jednoznacznie skategoryzować wszystko, co wprowadza Docker. Dobrze zaimplementowany przynosi korzyści na wiele sposobów organizacjom, zespołom, deweloperom i inżynierom odpowiedzialnym za utrzymanie. Upraszcza podejmowanie decyzji dotyczących architektury, ponieważ wszystkie aplikacje z punktu widzenia systemu operacyjnego, w którym są uruchomione, wyglądają dokładnie tak samo. Ułatwia to tworzenie narzędzi pomocniczych i ich wykorzystanie w różnych aplikacjach. Niestety nic na tym świecie nie przynosi samych korzyści bez stawiania nowych wyzwań, jednak w Dockerze korzyści są w zaskakującej przewadze. Oto niektóre rzeczy, jakie dostajesz razem z Dockerem:

 

Oprogramowanie do obsługi pakietów, które wykorzystuje umiejętności posiadane już przez programistów.

 

Wiele firm musiało utworzyć dodatkowe stanowiska inżynierów odpowiedzialnych za tworzenie nowych wersji i kompilacji, aby zarządzać wiedzą i narzędziami niezbędnymi do przygotowania pakietów oprogramowania dla wspieranych platform. Narzędzia takie jak rpm, mock, dpkg czy pbuilder mogą być trudne w użyciu i każdego z nich trzeba się uczyć niezależnie. Docker obejmuje wszystkie wymagania w ramach jednego pakietu definiowanego w pojedynczym pliku.

 

Połączenie kodu aplikacji z niezbędnym systemem plików systemu operacyjnego w jednym obrazie o ustandaryzowanym formacie.

 

W przeszłości zazwyczaj musiałeś tworzyć pakiet nie tylko ze swoją aplikacją, ale też z wieloma niezbędnymi do jej działania zależnościami, takimi jak biblioteki czy demony. Nigdy jednak nie byłeś w stanie zapewnić, żeby środowisko działania było w stu procentach identyczne. Wszystko to utrudniało opanowanie tworzenia pakietów i stąd wiele firm miało problem z ich poprawnością. Często ktoś mający zainstalowany system Scientific Linux mógł próbować uruchomić pakiet przetestowany w Red Hat Linux, żywiąc nadzieję, że będzie on wystarczająco zbliżony do tego, czego potrzebuje. Z Dockerem dostarczasz aplikację wraz ze wszystkimi plikami niezbędnymi do jej uruchomienia. Wielowarstwowe obrazy Dockera sprawiają, że jest to wydajny proces zapewniający, że Twoja aplikacja działa w środowisku zgodnym z oczekiwaniami.

 

Wykorzystanie pakietów do testowania i wdrażania dokładnie tego samego artefaktu we wszystkich systemach i wszystkich środowiskach.

 

Gdy programiści wprowadzą zmiany do systemu kontroli wersji, można utworzyć nowy obraz Dockera, który przejdzie przez cały proces testowania i zostanie wdrożony w środowisku produkcyjnym bez potrzeby ponownego kompilowania czy przepakowywania na jakimkolwiek etapie.

 

Oddzielenie oprogramowania od sprzętu bez poświęcania zasobów.

 

Tradycyjne rozwiązania do wirtualizacji klasy enterprise, takie jak VMware, są zazwyczaj wykorzystywane, gdy konieczne jest utworzenie warstwy abstrakcji pomiędzy fizycznym sprzętem a działającym na nim oprogramowaniem kosztem zasobów. Procesy hipernadzorcy zarządzające maszynami wirtualnymi oraz każde jądro działającej maszyny wirtualnej wykorzystują pewną część zasobów sprzętowych systemu, które nie mogą być już wykorzystane przez obsługiwane aplikacje. Z drugiej strony kontener to po prostu kolejny proces komunikujący się bezpośrednio z jądrem systemu Linux, dzięki czemu może wykorzystać więcej przydzielonych przez system zasobów.

 

W chwili udostępnienia Dockera kontenery linuksowe istniały już od kilku lat i wiele technologii, na których się on opiera, nie jest zupełnie nowych. Jednak unikalne połączenie wymuszanych przez Dockera rozwiązań architektonicznych i procesowych składa się na coś o wiele bardziej potężnego niż suma części składowych. Docker ostatecznie sprawia, że kontenery linuksowe, które są dostępne od ponad dekady, stają się dostępne dla przeciętnego użytkownika. Pozwala on stosunkowo łatwo dopasować kontenery do istniejących przepływów pracy i procesów wykorzystywanych w firmach. Omówione wyżej problemy odczuwało tak wiele osób, że zainteresowanie projektem Docker zwiększało się w tempie szybszym, niż ktokolwiek mógł oczekiwać.

 

W pierwszym roku nowicjusze w projekcie byli zaskoczeni, dowiadując się, że Docker nie jest jeszcze gotowy do zastosowań produkcyjnych, ale stały strumień modyfikacji płynący ze strony społeczności open source Dockera popychał projekt do przodu w bardzo szybkim tempie. Tempo to zdaje się zwiększać wraz z upływem czasu. Ponieważ Docker przeszedł już do fazy rozwoju 1.x, jest stabilny i ma już wdrożenia produkcyjne, to wiele firm patrzy nań jak na rozwiązanie niektórych poważnych problemów związanych ze złożonością, jakie napotyka podczas dostarczania aplikacji.  

 

Czym Docker nie jest

 

Dzięki Dockerowi można sprostać wielu wyzwaniom, dla których tradycyjnie stosowało się narzędzia innych kategorii, jednak szeroki zestaw możliwości często oznacza, że nie są dostępne bardzo specyficzne możliwości funkcjonalne. Na przykład niektóre organizacje z pewnością zauważą, że po migracji do Dockera mogą zupełnie zrezygnować z narzędzi do zarządzania konfiguracją. Prawdziwa moc Dockera jednak leży w tym, że choć może on zastąpić w niektórych aspektach bardziej tradycyjne narzędzia, to jest zazwyczaj kompatybilny z nimi lub nawet może być przez nie rozszerzany. Poniżej znajduje się lista kilku kategorii narzędzi, których Docker bezpośrednio nie zastępuje, ale które często można z nim łączyć z dobrym rezultatem.

 

Platformy do wirtualizacji (VMware, KVM itd.)

 

Kontener nie jest wirtualną maszyną w tradycyjnym sensie. Maszyny wirtualne zawierają pełen system operacyjny działający odrębnie od głównego systemu operacyjnego komputera. Największą zaletą takiego rozwiązania jest to, że pozwala ono w łatwy sposób uruchomić wiele maszyn wirtualnych ze skrajnie różnymi systemami operacyjnymi na tym samym komputerze. To oznacza, że zarówno główny system operacyjny, jak i kontenery korzystają z tego samego jądra. Tak więc kontenery wykorzystują mniejszą ilość zasobów systemowych, ale muszą być oparte na tym samym systemie operacyjnym (np. Linuksie).

 

Chmura (Openstack, CloudStack itd.)

 

Tak jak w przypadku wirtualizacji, wykorzystanie kontenerów wykazuje wiele podobieństw do korzystania z platform chmurowych. Oba te mechanizmy są tradycyjnie wykorzystywane, by umożliwić horyzontalne skalowanie aplikacji w przypadku zmieniających się wymagań. Docker nie jest jednak platformą chmurową. Obsługuje jedynie wdrażanie, uruchamianie kontenerów i zarządzanie nimi na istniejących już komputerach z Dockerem. Nie pozwala na tworzenie nowych systemów (instancji), magazynów obiektów, urządzeń blokowych do przechowywania danych i wielu innych zasobów, jakie zazwyczaj powiązane są z platformą chmurową.

 

Zarządzanie konfiguracją (Puppet, Chef itd.)

 

Choć Docker może znacząco usprawnić zarządzanie aplikacjami i ich zależnościami w organizacji, nie zastępuje bezpośrednio bardziej tradycyjnych systemów do zarządzania konfiguracją. W plikach Dockera definiuje się, jak kontener powinien wyglądać przy kompilacji, ale nie służą one do zarządzania późniejszym stanem kontenera i nie mogą być wykorzystywane do zarządzania systemem operacyjnym, na którym działa Docker.

 

Framework do wdrażania (Capistrano, Fabric itd.)

 

Docker upraszcza wiele aspektów wdrażania aplikacji dzięki tworzeniu samowystarczalnych obrazów kontenerów, które zawierają wszystkie zależności aplikacji i mogą być wdrożone w każdym środowisku bez modyfikacji. Docker nie może być jednak wykorzystany do automatyzacji złożonych procesów wdrażania. Zazwyczaj potrzebne są nadal inne narzędzia pozwalające połączyć i zautomatyzować większe procesy.

 

Systemy do zarządzania obciążeniem (Mesos, Fleet itp.)

 

Docker nie ma wbudowanej obsługi klastra. Dodatkowe narzędzia (takie jak narzędzie Swarm z Dockera) muszą być wykorzystane do inteligentnego skoordynowania pracy większych grup systemów z Dockerem i śledzenia stanu wszystkich systemów oraz ich zasobów, a także rejestrowania działających kontenerów.

 

Środowisko programistyczne (Vagrant itp.)

 

Vagrant to narzędzie do zarządzania maszynami wirtualnymi dla deweloperów, często wykorzystywane do symulowania zestawu serwerów przypominającego środowisko produkcyjne, w którym aplikacja ostatecznie ma zostać wdrożona. Vagrant między innymi ułatwia uruchamianie oprogramowania Linux na stacjach roboczych z systemami Mac OS X i Windows. Ponieważ serwer Dockera działa tylko w systemie Linux, Docker dostarcza narzędzie o nazwie Boot2Docker, które umożliwia programistom szybkie uruchomienie maszyny linuksowej obsługującej Dockera na wielu platformach. Boot2Docker wystarcza w wielu standardowych konfiguracjach Dockera, ale nie zapewnia wszystkich możliwości, jakie można znaleźć w Docker Machine i Vagrancie.

 

Zrozumienie Dockera bez solidnych podstaw mogłoby być trudne. W kolejnym rozdziale dokładnie omówimy Dockera — powiemy, czym on jest, jak powinien być wykorzystywany i jakie korzyści przynosi, gdy zostanie zaimplementowany zgodnie z tymi wskazówkami.    

 

---

Fragment pochodzi z książki "Docker. Praktyczne zastosowania. Wydanie II" (Wydawnictwo Helion 2019).

Książka >>

Ebook >>