Trochę minęło czasu od ostatniego wpisu, ale czasy były niepewne i wiele zmienia się w życiu zawodowym, co z koleji przełożyło się na chroniczny brak czasu. Teraz zaczynam nowy rozdział swojej kariery, i jak to często bywa chciałbym zacząć też tutaj pewien cykl wpisów opisujący moje doświadczenia, wzloty i upadki w pracy...
Któż z nas programistów, nie spotkał się z słowami "U mnie działa?!", często tak mówimy, prawda? I jest w tym prawda, w nas działa. Dlaczego? Ponieważ nasze środowiko, które stworzyliśmy sobie na swoim fantastycznym komputerze jest bardzo subtelne i niereplikowalne na inne maszyny. Ale co jeśli gdyby zreplikować nasze środowsko albo lepiej, gdyby udało nam się zrobić coś aby środowisko na którym na być uruchomiony nasz kod było takie samo jak środowisko na którym pracujemy na codzień? Tak da się tak i po to właśnie wymyślono Dockera.
Co to jest ten Docker?
Jak to zwykle bywa nalepsza definicja jest w Wikipedii:
Docker – otwarte oprogramowanie służące jako "platforma dla programistów i administratorów do tworzenia, wdrażania i uruchamiania aplikacji rozproszonych".
Docker jest określany jako narzędzie, które pozwala umieścić program oraz jego zależności w lekkim, przenośnym, wirtualnym kontenerze, który można uruchomić na prawie każdym serwerze.
Wszystko fajnie, no ale po co mi to? Przecież kiedy "dostaję" nowy projekt to tworzę sobie nowego vhosta w Apachu i wszystko działa! Tak działa, ale są wyjątki, najczęsciej spotykane to wersje PHP, tak wiem wszyscy pracujemy na wersji 7.3 (aktuala wersja na czas pisania tego wspiu). Ostatnio trafił do mnie projekt z czasó nie tak dawnych, gdy najnowszą wersją PHP była 5.6, a klient był tak zauroczony tym kodem, że ani nie myśli zmienić/przepisać kodu do wyższej wersji, a na dodatek ustrojstwo krzysta tylko z PEARa. Pewnie dalej uważasz, że Twoje idealne środowisko jest do tego dobre? Najczęstsza odpowiedź to:
"Oczywiście, przecież mogę zmienić konfigurację Apacha tak aby obsługiwał więcej niż jedną wersję PHP!"
I też jest to prawda. Mnie jednak wydaję się, że jest to zgubne nieprawda? I tutaj z pomocą może przyjść nam właśnie Docker. Dlaczego? Poniważ Docker daje nam dla każdej aplikacji wyizolowane środowisko, w którym po prostu możemy ją uruchamić w nim. Nie ma obaw przed tym, że jakieś zależności się nam pomylą, albo będziemy zmuszeni do tzw. StackOverflow Driven Development, bo coś grubszego nam nie zadziałą. Poza tym, jeśli chcemy taką aplikację pokazać światu albo chociaż klientowi, to fajnie jakby działała.
Trochę teorii
Już wiemy po co Docker, ale trochę wiedzy nigdy nie zaszkodzi :)
Najważniejszym pojęciem związanym z Dockerem jest magiczne słowo kontener. Jaka w nim magia? A no taka, że to właśnie takie pudełko, w którym jest sobie system operacyjny i wszystkie potrzebne nam do działania naszego oprogrmowania aplikacje i biblioteki. Taki kontener korzysta z ogólnych zasobów Twojego komputera i bierze tylko tyle, ile potrzebuje (często to tak jak z Chromem)
Źródło:https://techlog360.com/limit-memory-usage-in-google-chrome/
Pewnie odrazu powiesz, ale przecież mogę postawić sobie osobną wirtulaną maszynę w VM Virtual Host. Tak też można, a czymyś się to różni przecież.
Konteneryzacja vs. Wirtualizacja
Aby ogarną ten temat trzeba najpierw wyjaśnić sobie czym te dwa podejścia się różnią.
Wirtualizacja
W klasycznym podejści w wirtualizacji w mamy kompletny system operacyjnym, który działa na bazie systemu operacyjnego komputeraz czy serwera (posiada to ładnąe nazwę host). Ogromną zaletą takiego rozwiązania jest możliwość uruchomienia wielu taki maszyn z różnymi systemami operacyjnymi na jednym hoście. Niestety takie podejście też ma swoje wady, maszyny wirtualne zazwyczaj są ciężkie i zużywają dużo zasobów. Bardzo często musimy tam zrobić pełną instalacje systemu operacyjnego i odpowiednio go skonfigurować, na dodatek nacze maszyny wirtualne zużywają więcej zasobów na własne potrzeby.
Konteneryzacja
Kontener działa w izolowanym środowisku. Obrazy, które możemy instalować w konterze często bazują na jądrze systemu hosta (w przypadku Windowsa i Dockera jest trochę inaczej ale o tym kiedy indziej...), z tego względu kontenery zużywają mniej zasobów systemowych. Każdy z kontenerów ma własne zmienne środowskowe i system plików. Nasze zasoby nie są konsumowane tak szybko, ponieważ nie tworzymy dodatkowego obciążenia związanego z wirtualizacją. Różnicę często widać gdy uruchamiamy aplikację, która korzysta z kontenera, poprostu jej czas startu jest znacząco dużo krótszy, a wynika to z mniejszego obciążenia powodowanego przez kontenery.
Zakończenie
Jak można zauważyć, kontener dość mocno różni się od tradycyjnej wirtualizacji. Niemniej należy pamiętać, że kontenery nie mogą zastąpić tradycyjnej wirtualizacji we wszystkich zastosowaniach. Oba z rozwiązań mają swoje wady i zalety.
W wirtualizacji mamy do dyspozycji w pełni izolowaną i bezpieczną maszynę wirtualną, choć jej wydajności pozostawia czasami wiele do życzenia. W przypadku konteneryzacji mam na pewno bardzo wydajne i szybkie kontenery, które mogą zostać szybko wdrożone w środowisku docelowym.
Które lepiej użyć? Jak to zawsze w życiu bywa zależy. Wszystko zależy od projektu i jego złożoności, od celu biznesowego, indywidulanych potrzeb itp.
Napewno kontenery pozwalają szybciej wdrożyć się w pracę osobą, które albo przejmują projekt po nas, albo dołączają do naszego zespołu, nietracimy czasu na "instalację" takiej osoby, tylko otrzymuje ona gotowe działające środowisko i po "chwili" jest ona gotowa do pracy.
Zapraszam do kolejnych części tego cyklu, które będą pojawiać się co jakiś czas, a będą to między innymi:
- Docker - pierwsza instalacja, cz. II
- Docker - budujemy kontenery, cz. III