Skoro tutaj jesteś, to pewnie w jakiś sposób jesteś uwikłany w tworzenie aplikacji lub systemów IT i zastanawiasz się, czy warto zainwestować swój czas w naukę konteneryzacji. Zanim przejdę do meritum zaproszę Cie na krótki wstęp, który pozwoli lepiej oddać sens odpowiedzi na tytułowe pytanie.
A co to w ogóle jest?
Jeżeli koncept konteneryzacji jest Ci dobrze znany możesz pominąć ten fragment.
Z punktu widzenia programisty
Gdy zaczynam pracę nad nowym serwisem lub aplikacją, to zaraz po zebraniu wymagań myślę jaka technologia (.NET, JAVA, GOLANG, Python, etc.) będzie najlepsza, żeby w najlepszy możliwy sposób zrealizować to czego się ode mnie wymaga. Tak się składa, że niezależnie od tego co wybiorę – na 99% będę w stanie moją aplikację skonteneryzować. Skonteneryzowana aplikacja to taka, która jest w stanie działać w czymś co przypomina system operacyjny i z punktu widzenia aplikacji jest systemem operacyjnym. Aplikacja, którą tworzę, w ogóle nie musi być „świadoma” tego, że jest uruchomiona w kontenerze (czyli w dużym uproszczeniu takiej mini VM – zobacz do części „Opsowej” jak to wygląda w rzeczywistości).
Aplikacja potrzebuje Dockerfile, żeby mogła stać się obrazem a dodatkowo potrzeba ten obraz uruchomić, aby stał się kontenerem.
Podkreślam jeszcze raz – w uproszczeniu, aplikacja + Dockerfile = obraz docker. Obraz docker + docker run = kontener.
Z punktu widzenia opsa
Czy rozumienie konteneryzacji i tego co kryje pod sobą jest konieczne w pracy Opsa? Będzie to subiektywna opinia – jeśli system którym się opiekujesz oparty jest o architekturę microservice i/lub wykorzystane są kontenery to zdecydowanie tak. Dobra znajomość Dockera (czy też innego silnika) będzie niezbędna, gdy niektóre serwisy będą wpadać w crash loopback czy będą konsumować więcej zasobów niż powinny.
Konteneryzacja często jest nazywana wirtualizacją systemu operacyjnego, bo tak na prawdę uruchamiając wiele aplikacji – każda w swojej piaskownicy (sandbox) czyli kontenerze, dzielimy nie tylko zasoby fizyczne jak pamieć RAM czy czas CPU, ale również funkcje systemowe. Idea konteneryzacji nie jest nowa, na Linuxie istnieje już od dawna (Namespaces) natomiast na Windowsie dopiero od Windows Server 2016 (Control Groups). Według mnie idealnym rozwiązaniem byłaby możliwość uruchamiania kontenerów bezpośrednio na maszynie – bez narzutu systemu operacyjnego… kto wie…
Konteneryzacja, dlaczego?
Zarządzanie zależnościami
Wiele tworzonych rozwiązań ma zależności systemowe – np. serwer www, czy jakaś konkretna paczka rpm/deb, gdy instalujemy aplikacje na systemie operacyjnym musimy pamiętać o tej zależności lub dbać o to, żeby nasz instalator to zrobił.
W konteneryzacji sprawa się bardzo upraszcza, ponieważ o zależnościach myślimy zaraz na początku – podczas budowania obrazu. Do tego wykorzystuje się Dockerfile, który definiuje jakie paczki, serwisy czy narzędzia powinny być zainstalowane zanim pliki naszej aplikacji w ogóle trafią do kontenera. Tak przygotowany obraz, posiada wszystko co jest potrzebne do uruchomienia aplikacji. Zaletą tego rozwiązania jest to, że na jednym systemie możemy uruchomić kontener z aplikacją napisaną w Python 2.7, drugi kontener z aplikacją Python 3.7, inne z Java 6, Java 8 i one wszystkie nie będą sobie nawzajem przeszkadzały.
Portability
Twoja aplikacja jest „spakowana” w obraz, wraz ze wszystkimi swoimi zależnościami – ten obraz już się nie zmieni (chyba, że będziesz bardzo chciał/a – docker commit, ale wtedy i tak powstanie nowy obraz), więc można powiedzieć, że jest immutable. Dzięki temu, Twoja aplikacja – kontener, może działać na dowolnym serwerze który potrafi uruchamiać kontenery. Nie jest ważne, czy Twoj obraz oparty jest o Ubuntu, Centosa, Alpine czy inne – będzie działał na RHEL’u z zainstalowanym Dockerem. Warto jednak pamiętać, że kontenery Windows działają na Windows a kontenery Linux na Linux.
Powstaje coraz więcej narzędzi typu „helper” lub „benchmark”, które są konteneryzowane – to znacząco ułatwia ich wykorzystanie, bo nie potrzeba instalacji samej aplikacji z całym dobrodziejstwem inwentarza, a wymaga tylko docker pull (pobierz obraz).
Dokumentacja
Zaniedbywany a jednak bardzo ważny temat. Idea samo-komentującego się kodu jest często weryfikowana po kilku tygodniach od jego powstania, a instalacja i lista potrzebnych zależności spędza sen z powiek, gdy zachodzi potrzeba aktualizacji zależności. Z pomocą przychodzi znowu Dockerfile, którego głównym przeznaczeniem bynajmniej nie jest dokumentowanie, ale świetnie to robi. Można dokładnie stwierdzić jakie zależności, w jakich wersjach potrzebuje aplikacja (ADD, RUN), na jakich portach nasłuchuje (EXPOSE), czy jakich zmiennych środowiskowych potrzebuje (ENV).
Skalowalność
Wisienka na torcie (lub truskawka – jak kto woli!). Oczywiście architektura naszej aplikacji może wykluczać skalowanie (np. przez sztywne przywiązanie do sesji in-memory bez możliwości wyrzucenia go na zewnątrz) i Docker tutaj cudownie nie sprawi, że będziemy mieć skalowalny system. Dla przypadków (jak sądzę większość), którym skalowanie nie przeszkadza – Docker się świetnie do tego nadaje. Z jednego obrazu, można uruchomić dowolną ilość kontenerów – czyli de facto instancji aplikacji.
Utrzymanie
Żeby nie było zbyt cukierkowo – łyżka dziegciu. To, co normalnie uważalibyśmy za zaletę – pięknie podzielony system na wiele serwisów realizujących małe części funkcjonalności, może być skomplikowane w utrzymaniu. Gdy posiadamy system składający się z dwóch/trzech serwisów jest go względnie łatwo utrzymać. Wiemy, gdzie szukać i własnymi rękami możemy go restartować, ale gdy w grę wchodzi 30 serwisów, uruchamianych sumarycznie w 300 instancjach zaczynamy dostrzegać problemy z wyciąganiem logów (centralized logging), monitorowaniem zasobów (centralized monitoring) czy orkiestracją (Kubernetes!!). Diagnozowanie problemów w tak rozbudowanym systemie może być wyzwaniem.
Wykorzystanie zasobów
Wirtualizacja znana od wielu lat moim zdaniem posiada zasadniczą wadę – narzut systemu operacyjnego. Mając mocny serwer, zwykle dzielimy go na N maszyn wirtualnych i każda maszyna wirtualna ma swój system operacyjny, który powoduje że nasze zasoby są „przepalane”. Rzecz inaczej ma się z konteneryzacja – tutaj wirtualizujemy system operacyjny, czyli zostaje więcej zasobów dla dziesiątek/setek kontenerów.
Podsumowanie
Może trochę subiektywnie, ale właśnie z powyższych pobudek na codzień korzystam z Dockera. Nie tylko jako kontener/aplikacja, która pójdzie „na produkcję”, ale jako: helper, narzędzie do analizy czy nawet agent buildowy. Spektrum zastosowań jest bardzo szerokie – od chmury (jak ACI, AWS Fargate) przez Cloud Native (Kubernetes) czy urządzenia typu Edge – tak, one też hostują kontenery! Oczywiście, konteneryzacja to nie tzw. silver bullet, nie rozwiąże wszystkich problemów – a może jeszcze kilka wprowadzi. Jednak moim zdaniem plusów jest zdecydowanie więcej niż minusów, dlatego warto mieć Dockera we własnym portfolio.