podcast TECHCHATTER
Odcinek 4

ALEKSANDRA: Cześć Marcin. Cieszę się, że chciałeś ze mną porozmawiać. Mam kilka takich pytań jako, że teraz pełnię funkcję katalog menadżera, współpracuję ściśle z zespołami projektowymi. No i właśnie pojawił się temat ostatnio konteneryzacji, gdzie dla mnie jest to dosyć stosunkowo nowa technologia. W związku z tym nie mam za wiele wiedzy na ten temat, a chciałabym jak najlepiej skonsultować.  Chodzi o to, że przyszli do nas i poprosili, żeby w katalogu była możliwość zamawiania przez użytkowników kontenera. I wydaje mi się na pierwszy rzut oka, że brakuje tam kilku rzeczy i nawet takich podstaw do zamawiania kontenerów. Chciałam to zweryfikować z Tobą. W związku z tym najpierw chciałabym się dowiedzieć na sam początek, jak wygląda sprawa z konteneryzacją i może dobrze byłoby zacząć, gdybyś najpierw powiedział mi, czym tak właściwie jest konteneryzacja i co możemy rozumieć przez kontener?
MARCIN: Jasne. Konteneryzacja to przede wszystkim proces, który polega na pakowaniu aplikacji, a nawet całych systemów operacyjnych w kontenery i tu jest od razu pytanie, co to jest kontener? Kontener to jest, tak zwyczajnie, zespół procesów na komputerze, na jakimś serwerze, który jest odizolowany od całej reszty przez specjalne mechanizmy, które są wbudowane w system operacyjny. To jest taka pewnego rodzaju bańka, w której żyją procesy i przetwarzają dane, wysyłają je gdziekolwiek, niezależnie od tego co się dzieje na hoście czy tam serwerze i niezależnie od tego jakie inne procesy działają na tym systemie. Tak w skrócie można powiedzieć. 
ALEKSANDRA: Okej, rozumiem. Trochę mi się to kojarzy z wirtualną maszyną, ale rozumiem, że nie jest to wirtualna maszyna. 
MARCIN: No nie jest to…
ALEKSANDRA: Czy mógłbyś w takim wypadku powiedzieć, jaka jest różnica pomiędzy kontenerem a wirtualną maszyną?  
MARCIN: Pewnie, pewnie. Jest dużo podobieństw między wirtualizacją a konteneryzacją i niektórzy nawet twierdzą, że konteneryzacja to jest jakby krok dalej, czyli kolejny etap ewolucji od maszyny fizycznej do czegoś zupełnie wirtualnego, żyjącego gdzieś tam w chmurze. I jeśli chodzi o takie podstawowe różnice, to przede wszystkim wielkość i sprawność. Co się za tym kryje? Ponieważ kontenery zawierają tylko i wyłącznie to co dana aplikacja potrzebuje do życia. Maszyna wirtualna to jest cały komputer ze wszystkim co niezbędne do działania każdego komputera, czyli system operacyjny w pełnej wersji musi mieć zarówno jądro jak i tą górną warstwę, musi mieć interfejsy, dyski, przydzielone CPU, czyli procesor, pamięć, wszystko, wszystko co sobie wyobrazimy w normalnym komputerze. A kontenery to są takie bardzo, bardzo odchudzone systemy operacyjne, które rzeczywiście nie zawierają niczego niepotrzebnego. Kiedy ktoś projektuje taki kontener, a właściwie obraz takiego kontenera, bo to są jakby dwie odrębne rzeczy, to stara się zawsze usuwać tyle, ile się da. Cała logika konteneryzacji polega na przeskalowaniu tej aplikacji, jej zależności rzeczywiście do minimum, takiego minimum, którym da się zarządzać. Są takie przypadki, że rzeczywiście tam jest tak mało, że nawet do takiego kontenera nie da się logicznie zalogować, bo nie ma żadnej powłoki. Nawet ta najmniejsza powłoka została usunięta i ten kontener ma tylko robić daną operację i nic więcej. Zawiera wszystkie dane, jakie potrzebuje i ani bajta więcej. Tak że, na przykład dla porównania ostatnio sobie ściągałem do testów ze strony Red Hata najnowszy obraz Red Hata 9 i takie ISO, nawet trochę się zaskoczyłem, to było, żeby nie skłamać w granicach 10 GB, a dla porównania kontener Linux Alpine, który jest takim wyznacznikiem jak bardzo można odchudzić kontener linuxowy, to jest w granicach 5 MB. To są różnice wprost niewyobrażalne z tym, że oczywiście obraz Red Hata zawiera wszystko, łącznie z graficznym interfejsem, a kontener Alpina czy obraz Alpina zawiera kilka komend i tyle. A resztę sobie dodajemy w ramach potrzeb i na przykład instalujemy aplikację, jej zależności, jakieś podstawowe pliki konfiguracyjne, jeśli potrzebujemy i koniec. Taka jest różnica i ten kontener jak restartujesz komputer w domu czy inżynierowie startują serwery w data center, to taki restart trwa od kilku minut do nawet, widziałem przypadki, godziny, półtorej godziny w przypadku wielkich maszyn, natomiast kontener wstaje w kilka sekund. Bywa, że dłużej, wiadomo, bo bywają ciężkie kontenery z ciężkimi aplikacjami, ale taki kontener potrafi sobie zrestartować się w przeciągu… Rzeczywiście nawet czasem jest trudno zauważyć, że się zrestartowało. Po prostu to mignęło i kontener znowu działa.  
ALEKSANDRA: To co mówisz, brzmi, jakby kontener był łatwiejszy i lepszy w utrzymaniu od wirtualnej maszyny.  Czy tak faktycznie jest? 
MARCIN: Łatwiejszy i lepszy, to jest bardzo względne. Tutaj ja nie chciałbym powiedzieć, że kontenery są lepsze od maszyn wirtualnych, bo może się zdarzyć, że są zastosowania, których kontenery nie są najlepsze. Dla przykładu wiele baz danych niespecjalnie nadaje się do uruchomienia w kontenerach. Wszystko będzie zależało od tego, jak dobrze dany obraz został przygotowany przez deweloperów i do jakich celów dany kontener czy dana aplikacja czy dana maszyna wirtualna, jeśli porównujemy, służy. Bo jeśli potrzebujemy środowiska graficznego, no to kontener tego nie zaoferuje. Jeśli potrzebujemy maszyny bardzo rozbudowanej, czy mamy bardzo rozbudowane aplikacje z wieloma pluginami, no to tutaj się sprawa komplikuje, bo zaprojektowanie tego w tak zwanym systemie mikroserwisów jest trudne. Wykonalne oczywiście i są naprawdę aplikacje, które przeszły z takiej wersji typowo serwerowej na typowo kontenerową, ale to trwa i rzeczywiście trzeba się nad tym napracować. Efekt końcowy jest naprawdę nieraz zaskakujący, bo aplikacja może na przykład zostać odchudzona kilka razy i działać o wiele sprawniej albo może być bardziej problematyczna, bo jeśli ktoś nie do końca przemyślał architekturę, no to może natrafić na bardzo niespotykane i zaskakujące problemy w trakcie już deploymentu do produkcji. Tutaj będziemy musieli uważać na tak zwane use cases, czyli to do czego dana aplikacja służy. I od tego też zacząłbym wdrażanie konteneryzacji w firmie. Pytanie dla Project Teamu.
ALEKSANDRA: Chciałam właśnie troszeczkę do tego nawiązać, ponieważ Project Team w momencie kiedy do nas przyszedł, miał kilka takich punktów, które opisywały jakie kroki będą potrzebne do stworzenia takiego kontenera. Dalej, na moje oko jako osoby, która nie zajmuje się kontenerami, wydawało mi się, że mimo wszystko było za mało tych kroków i nie wszystko pokrywały. I dlatego najpierw chciałam Ciebie zapytać, jakie jest must have, żeby kontener stworzyć? Co potrzebujemy do stworzenia kontenera? 
MARCIN: Zasadniczo bardzo niewiele. Jeśli mamy środowisko deweloperskie, takie środowisko, w którym może się coś zepsuć i sobie bardzo szybko to naprawimy i nie mamy dwóch tysięcy użytkowników, którzy tam czekają na linii i złoszczą się, bo coś przestało działać, to wystarczy dowolny komputer, czy to jest Linux, czy to jest Windows nieważne, bo generalnie konteneryzacja działa obecnie na wszystkich ważnych systemach operacyjnych, czyli potrzebujemy oprogramowanie typu Docker. Powiedzmy Docker, bo to jest najpopularniejsza platforma czy najpopularniejszy silnik do zarządzania kontenerami i potrzebujemy obrazu, z którego będziemy korzystać. Ja tu już wspomniałem o tych obrazach, bo to jest chyba najważniejsza rzecz tego całego zestawu. Potrzebujemy coś, co moglibyśmy uruchomić, bo kontener to jest tylko pusta bańka. Jeśli nie będziemy mieli czegoś, co w tej bańce sobie uruchomimy, no to właściwie nie ma o czym mówić. Tak jakbyśmy mieli komputer bez oprogramowania, który ma jakieś dyski, ma jakieś rzeczy, ale generalnie po prostu stoi i szumi. Nic więcej się z nim nie dzieje. Także jakiś obraz możemy go sami stworzyć, możemy go ściągnąć czy z Docker Hub czy z jakiegokolwiek innego rejestru i uruchomić go lokalnie używając lokalnie zainstalowanego tak zwanego container runtime, czyli właśnie oprogramowania, które uruchamia kontenery i nimi zarządza lokalnie, restartuje, usuwa, dodaje, ściąga obrazy, wypycha obrazy i tak dalej. Także to są takie dwie najbardziej podstawowe rzeczy, ale jak mówimy o produkcji, no to tutaj już się sprawa komplikuje, ponieważ musimy myśleć o automatyzacji, o orkiestracji. Musimy myśleć o wysokiej dostępności i tym podobnych rzeczach. Więc tutaj już będziemy musieli zbudować całą infrastrukturę, a najlepiej w takich sytuacjach jest po prostu skorzystanie z gotowej platformy, która jest budowana na podstawie oprogramowania dostarczonego przez firmę, która się w tym specjalizuje, czy to będzie Red Hat, czy to będzie Mirantis dość popularny ze względu na przejęcie oprogramowania Docker Enterprise, czy na przykład coś takiego jak Rancher, który też ostatnio zyskuje na popularności w niektórych środowiskach. No i jeśli mamy już coś takiego, mamy licencję na takie oprogramowanie, to możemy zacząć budować tą infrastrukturę i rzeczywiście ja bym powiedział, że należy budować infrastrukturę, a nie tworzyć kontenery. To są jakby dwie rzeczy, które są powiązane ze sobą, ale bez infrastruktury typu produkcyjnego klasy Enterprise właściwie nie mamy co myśleć o takim wdrożeniu w firmie.  
ALEKSANDRA: Okej, czyli tworząc taką infrastrukturę musimy myśleć o tym, żeby kontener móc na czymś postawić. Project Team przyszedł do nas, żeby najpierw stworzyć wirtualną maszynę, ale czy faktycznie konieczne jest, aby każdorazowo do kontenera tworzyć nową wirtualną maszynę, czy może jednak możemy wykorzystać zasoby na już istniejącej VM-ce?  
MARCIN: Jasne, nie ma żadnej takiej potrzeby. Tutaj, tak jak wspomniałem, musimy mieć platformę i ta platforma jest w tym momencie naszą uniwersalną infrastrukturą, z której możemy korzystać uruchamiając setki jeśli nie tysiące kontenerów. Możemy te kontenery tworzyć, usuwać, dodawać. Możemy na przykład umożliwić użytkownikom uruchamianie kontenerów adhocowych zupełnie, gdzie na przykład jest operacja do wykonania, jakieś obliczenia czy cokolwiek innego. Kontener się uruchamia, robi swoje, zamyka się, klient idzie do domu. Taka chmura, którą możemy uruchomić w naszym centrum danych, w naszej serwerowni. Wcale nie potrzebujemy tutaj takich rozwiązań, które oferuje czy Amazon czy Microsoft czy jeszcze Google w swojej chmurze. I w momencie, w którym my tą infrastrukturę mamy, powiedzmy, że mamy rozwiązanie o nazwie Mirantis Kubernetes Engine albo Red Hat OpenShift i to rozwiązanie instalujemy raz. Mamy ileś tam maszyn wirtualnych, to mogą też być na przykład maszyny fizyczne. Nikt nam nie zabrania używać maszyn fizycznych. Może to nie jest już takie popularne rozwiązanie jak kiedyś, ale jeśli mamy na przykład nieużywane fizyki, które się nam kurzą w serwerowni, to czemu nie? Można skorzystać, połączyć te serwery w klaster, zainstalować oprogramowanie do zarządzania kontenerami, właśnie OpenShift czy MKE i w momencie, kiedy my to zintegrujemy z jakimś systemem do zarządzania kontenerami, mogą to być  po prostu skrypty, może to być serwis nao, może to być kilka innych rozwiązań, które jakby stanowią interfejs między platformą a użytkownikami i wtedy przy oczywiście odpowiednim oskryptowaniu i obudowaniu tego modułami automatyzacyjnymi po prostu zaczynamy udostępniać użytkownikom aplikacje, które działają w kontenerach. I tutaj taka drobna uwaga, cała zabawa, jeżeli chodzi o konteneryzację, polega w dużej mierze na abstrakcji. My staramy się odsunąć użytkowników czy nawet deweloperów od infrastruktury, żeby oni się nie martwili o sieci, o storage, o CPU, pamięć i tak dalej czy nawet jak to wszystko działa i gdzie to działa, bo normalnie na serwerze musimy zainstalować aplikacje, musimy się tam zalogować, ściągnąć pliki, zainstalować, uruchomić usługę, skonfigurować i tak dalej. W przypadku kontenerów to idzie na platformę i platforma się martwi, na którym serwerze ten kontener się uruchomi, jak on będzie działał, co się stanie, jak ten kontener nagle ulegnie awarii na przykład, bo proces się zamknął w niespodziewany sposób i trzeba go uruchomić jeszcze raz. To jest kompletnie ukryte przed użytkownikiem, ukryte przed nawet administratorami aplikacji, bo na przykład pracuję z administratorami aplikacji, którzy kompletnie nie wiedzą, gdzie te kontenery są. Oni się w ogóle tym nie interesują. Oni się interesują tym, żeby się zalogować do swojej aplikacji, na panel admina, coś tam poklikać, wgrać nowy konfig i tyle. Dla nich ważne, żeby ta aplikacja działała.  
ALEKSANDRA: Rozumiem. Dobrze, natomiast tutaj jeszcze nie wspomniałeś, a wydaje mi się, że przynajmniej w tym moim przypadku jest to dość istotne, ponieważ pojawił nam się jeden z takich punkcików, że musimy zadbać o storage. I teraz jak to wygląda z tym storagem? Czy najpierw musimy stworzyć tą wirtualną maszynę,  a później storage, żeby ten kontener móc gdzieś tam tworzyć, czy jak to wygląda? Co trzeba zaopiekować najpierw? 
MARCIN: Właściwie to nie ma znaczenia, co jest pierwsze. Tak czy inaczej wszystko musi być. I storage jest jednym z tych elementów układanki. Mamy na przykład istniejącą infrastrukturę opartą na SAN-ach albo na NAS-ach albo serwerach NFS. Z reguły jest tak, że zespół, który taką platformę instaluje i konfiguruje, wykorzystuje to, co jest dostępne w danym środowisku. Czyli na przykład jeśli firma zainwestowała w jakieś duże serwery typu NAS, wypadałoby z tego skorzystać. Jeśli mamy na przykład infrastrukturę wirtualizacyjną Nutanix, która umożliwia udostępnianie całych woluminów poprzez protokoła i skazi, to czemu by nie skorzystać z tego rozwiązania? To są rzeczy, które konfiguruje się w trakcie tworzenia platformy, a następnie udostępnia się je tak samo jak każdy inny rodzaj storage, ponieważ w świecie konteneryzacji, właśnie to co ja wspominałem wcześniej, jest najważniejsza abstrakcja, czyli my dokonujemy takiego oddzielenia tego backendu od tego, co widzimy.  
ALEKSANDRA: Czyli frontend.  
MARCIN: Czyli też myślę o użytkownikach albo o administratorach aplikacji. Oni chcą storage. Jeśli tworzymy manifesty dla danej aplikacji, no to mamy taki rodzaj manifestu, który się nazywa albo percent volume albo percent volume claim, w zależności od tego, jak taki storage tworzymy i dla tego administratora tej aplikacji ważne jest, żeby dostał tyle a tyle tego storage o takiej klasie, bo możemy mieć na przykład szybki storage, wolny storage i tak dalej, jakieś parametry typu czy ten storage ma być dostępny do zapisu czy tylko do odczytu czy na przykład potrzebujemy mieć storage, który będzie dostępny dla wielu kontenerów jednocześnie, czy tylko dla jednego i tym podobne rzeczy takie bardzo, bardzo podstawowe, a całą resztą zajmuje się już wtedy platforma. Po prostu udostępnia ten storage, tworzy go gdzieś tam sobie automatycznie na backendzie, tworzy nowe woluminy, a aplikacja  z nich korzysta. Zapisuje sobie jakieś dane w jakichś folderach, ewentualnie może montować je sobie. Czy na przykład bardzo popularne jest rozwiązanie, w którym kontener łączy się nie tyle do storage co do zewnętrznej bazy danych, bo można przechowywać dane w ten sposób i mamy aplikację typu frontend, jakiś webserwer czy coś podobnego i ta aplikacja na znanym porcie łączy się do zewnętrznej bazy, wysyła te dane i w momencie jak operacja została wykorzystana, to po prostu kończy  połączenie do bazy i wykonuje jakieś operacje. I to też jest rodzaj storage, można tak to nazwać, działa to dokładnie tak samo, jakbyśmy mieli aplikację na serwerze. Czyli tak samo mamy gdzieś bazę z tyłu, która zbiera dane i mamy aplikację, która dane przetwarza na bieżąco, kontaktuje się,  komunikuje się z użytkownikiem. Najważniejsze jest to, że dla użytkownika to jest przezroczyste, kompletnie nie wie, co się dzieje z tyłu. Jego to zupełnie nie interesuje. Także nie ma specjalnego storage, tak reasumując, nie ma specjalnych wymagań, jeśli chodzi o storage. Obecnie stosowane rozwiązania w konteneryzacji są bardzo uniwersalne. Jest mnóstwo pluginów i właściwie każdy producent takiego rozwiązania storage-owego wydaje takie pluginy w postaci kontenerów albo w postaci sterowników do Kubernetesa czy do Kera, czy właściwie na system operacyjny, które są używane.  
ALEKSANDRA: Czyli istnieje tutaj spora dowolność, właściwie ograniczają nas tylko zobowiązania kontraktowe z klientem.
MARCIN: Poniekąd.
ALEKSANDRA: I właściwie to co jest zawarte w kontrakcie. Natomiast mówiąc o storage przychodzi mi jeszcze do głowy backup. Czy backup jest konieczny, czy jest wykorzystywany często przy kontenerach? Czy raczej nie jest to konieczne rozwiązanie, jak to wygląda?  
MARCIN: Z backupem jest taka sprawa, że tu będzie dużo zależało od tego, co chcemy rzeczywiście backupować i po co. No bo ja sobie wyobrażam backup na przykład maszyny wirtualnej, na której są uruchomione kontenery, który to backup ma taki średni sens. No bo kontenery są, powiedzmy, bardzo takie efemeryczne. One powstają, umierają, tworzą się na nowo, nie zatrzymują tych danych na stałe lokalnie. Bo wspominaliśmy o storage, mamy storage backend, który trzyma wszystkie dane, które my potrzebujemy przechować na dłużej. Kontener przechowuje dane tymczasowe, dane, które są potrzebne w danym momencie do działania aplikacji, a wszystko co chcielibyśmy rzeczywiście przechowywać przez dłuższy czas, zostaje gdzie indziej. Jest przesyłane gdzie indziej i to właśnie jest ten element, który powinniśmy backupować. Czyli na przykład jeśli przesyłamy dane na serwer plików,  no to ten serwer plików wypadałoby jakoś tam zbackupować i to już jest zadanie dla ludzi, którzy zarządzają tym serwerem plików. Bo na pewno są jakieś rozwiązania, które zostały wdrożone.  Backup to jest jedna z pierwszych rzeczy, którą się konfiguruje w danej infrastrukturze, bo bez tego właściwie ciężko sobie wyobrazić nowoczesną infrastrukturę i pracę w dłuższym okresie. No tak na przykład na dwa tygodnie można, prawda, ale jeśli na przykład po dwóch tygodniach coś się zepsuje  i stracimy dane, no to cała praca na marne. Także zawsze są jakieś rozwiązania. Jeśli na przykład korzystamy z baz danych albo uruchamiamy bazę danych w kontenerze, to ta baza danych najczęściej ma swoje własne mechanizmy backupowe i tym się zajmują już administratorzy baz danych. Jedną z tych czynności, którą muszą regularnie wykonywać, to są backupy baz. I też przywracanie tych baz to nie jest coś, co robi się z poziomu zarządzania kontenerami, tylko z poziomu bazy danych. Z poziomu platformy konteneryzacji możemy taką bazę przywrócić jako kontener, czyli taka pusta aplikacja, która nie ma danych. Natomiast już zespół zarządzający bazą sobie przywraca dane do swojego własnego backupu, no i dane są już gotowe. A na przykład jeśli chodzi o backup samej platformy,  to to już jest też backup na poziomie aplikacji. Dana platforma powinna, z reguły tak jest, w przypadku tych już klasy Enterprise, są dostępne specjalne polecenia, które backupują bazę konfiguracji tej platformy, na przykład bazę użytkowników i tym podobne rzeczy, bo jeśli na przykład ta platforma uległaby awarii na przykład w trakcie jakiegoś upgrade’u albo w trakcie patchowania albo w trakcie jakiegoś outage’u infrastruktury, która jest pod spodem, pod platformą, na przykład mamy maszyny wirtualne, które są hostowane na jakimś klastrze wiejomworowym i ten klaster  wiejomworowy może ulec awarii. No to wtedy można to przywrócić z backupu, ale to jest backup już innego rodzaju, czyli backup aplikacji typu OpenShift albo Mirantis, Kubernetes Engine. Zajmuje się wtedy tym zespół, który obsługuje daną platformę.  
ALEKSANDRA: Dobra czyli tak, do stworzenia kontenera mamy już VM-kę, mamy storage, mamy backup, natomiast tam jeszcze, w tym request’cie z Project Teamu pojawiła się informacja o masternodach i workernodach i co mnie zaciekawiło, przy masternodach była taka informacja, że można wybrać 3, 5,  nie widziałam tam parzystych liczb, a przy workernodach były to większe nawet wartości, bo nawet można było 15 wybrać. Czy mógłbyś mi wytłumaczyć te zależności, czym są masternody, czym są workernody, dlaczego takie liczby mogą być wybierane przez użytkowników?  
MARCIN: Jasne, każda platforma musi się składać z części, która zarządza  i z części, która wykonuje pracę, czyli tutaj w tym wypadku uruchamia aplikacje, uruchamia kontenery. Oczywiście, ważne, żeby ilość tych serwerów, które zarządzają, nie była większa od ilości tych, które rzeczywiście wykonują pracę.  W związku z czym mamy tutaj dość dużą rozbieżność pomiędzy tymi liczbami, a te liczby typu 3, 5, to jest kwestia zarządzania bazami danych, które są sercem danej platformy i z reguły te bazy danych wymagają nieparzystej liczby nodów, żeby zachować wysoką dostępność. Na przykład jeśli używamy bazy typu etcd albo ratingdb, te bazy w przypadku parzystej liczby nodów nie dają nam wysokiej dostępności. Wyobraźmy sobie, że mamy dwa serwery takie zarządzające typu masternode  albo managernod i jeden z tych serwerów ulega awarii. W tym momencie niestety baza danych traci kworum i nie jest w stanie działać dalej. To się wiąże z tak zwanym pojęciem split brain, czyli takiego rozkawałkowania klastra, w którym połowa klastra nie wie, czy druga połowa żyje czy nie. W związku z tym każda z tych połówek stara się zarządzać klastrem. No i mamy gotowy problem, bo jeśli mamy dwa ośrodki zarządzania jednego klastra, no to właściwie nie wiemy, kto wydaje polecenia, kto jest tutaj szefem, a kto powinien wykonywać te polecenia. To jest już bardzo krótka droga do katastrofy. I dzięki temu, że w te bazy danych został wbudowany mechanizm zarządzania kworum, nie mamy możliwości, żeby dana część klastra stwierdziła, że ona jest tutaj jedyna i wyłącznie ona powinna zarządzać, podczas gdy druga tak samo myśli i tak samo działa. Mamy na przykład trzy nody i jeśli jeden z tych nodów ulegnie awarii albo rozłączy się w jakiś sposób od reszty, no to działa tylko ta część, która ma większość. Niestety ten, który się odłączył w tym momencie, przestaje być słuchany przez całą resztę, jest uważany za nod, który jest niezdrowy albo po prostu nod, który uległ awarii, nie działa i nie powinien być w ogóle brany pod uwagę. Jeśli mamy na przykład dwa nody, no to jest to niemożliwe. Jeśli mamy cztery nody, no to możemy mieć sytuację, w której nie ma jednego managera. Da się z tym żyć, będziemy mieli wtedy trzy, ale jeśli ulegnie awarii jeszcze jeden, no to znowu mamy sytuację, w której dwa działają, dwa nie działają no i klaster nie jest w stanie powiedzieć, czy rzeczywiście jedna połowa klastra jest ta właściwa, czy ta druga. Także po prostu można używać parzystych liczb, tylko to nie ma kompletnie sensu z punktu widzenia zarządzania klastrem. Jeśli dodamy czwartego noda, no to niczego nie zyskujemy, a nawet tracimy, bo w porównaniu z sytuacją, w której mamy trzy nody, ryzyko awarii jest większe po prostu. Mamy o jeden więcej serwer, który może się zepsuć, w związku z tym jest to większe ryzyko, że dany klaster zostanie położony. A jeśli dołożymy jeszcze jednego noda, no to mamy pięć, no i wtedy już dwa mogą ulec awarii i wtedy trzy działają, i klaster jest zdrowy. Jeśli chodzi o workery, no to są te woły robocze. One mogą być naprawdę wielkimi maszynami. Mogą mieć po kilkanaście, kilkadziesiąt rdzeni. Mogą mieć po kilkaset gigabajtów RAM-u i może być ich wiele. To są takie dwie różne filozofie, czy budujemy mało dużych maszyn, czy budujemy dużo małych maszyn. Różne są zdania na ten temat. To już jest też kwestia tego, jakie aplikacje mamy, jak lubimy zarządzać infrastrukturą, ile osób jest w zespole i na przykład jak łatwo jest nam zarządzać pojedynczą maszyną, bo czasami jest tak, że mamy mało ludzi, którzy zarządzają systemami operacyjnymi, no i głupio byłoby tworzyć 70 maszyn i obciążać te osoby dodatkową pracą, czuwaniem i tak dalej. Więc tutaj jest różnie. No ale właśnie te workery to są maszyny, które uruchamiają kontenery i one odpowiadają rzeczywiście za to, że te aplikacje dla użytkownika są dostępne, że działają, że użytkownicy mogą korzystać z różnych funkcjonalności.  Możemy te workery dodawać, usuwać i tak naprawdę, jeśli mamy na przykład 20 workerów i nagle 3 nam się zepsują, możemy spokojnie siedzieć dalej, naprawić te workery w swoim czasie, bo kontenery w tym momencie będą migrowane na hosty, które działają, które nie mają żadnych problemów i one po prostu przejmują ich funkcję. Workery są bardzo łatwe do zastąpienia, możemy je dodawać, jak powiedziałem usuwać, restartować, tylko trzeba uważać czy na przykład na danym serwerze w danym momencie nie ma jakiegoś ważnego kontenera z jakąś aplikacją, żeby na przykład użytkownicy, którzy z niej korzystali, nie mieli choćby krótkiej, ale za to awarii. Bo wiadomo, że jeśli mamy aplikację, która wykonuje jakieś obliczenia, które są bardzo ważne, czasami długotrwałe, to każdy restart takiego kontenera powoduje przerwanie operacji, może utratę niewielkiej liczby danych i tak dalej. Więc to nie jest wskazane, ale jeśli mamy na przykład aplikacje typu webserwer, które stanowią tylko taki frontend dla jakiejś większej aplikacji, to możemy je często restartować, skalować, zmieniać liczbę replik i robić te podobne rzeczy i to jest dla użytkowników końcowych praktycznie niewidoczne, bo gdzieś tam jeszcze między nimi a aplikacją jest low balancer, który dynamicznie przerzuca ruch sieciowy z kontenera na kontener i możemy spokojnie sobie te kontenery uruchamiać i zamykać. 
ALEKSANDRA: To już wszystko dla mnie jasne, jeżeli chodzi o te takie podstawy do tworzenia kontenera, ale zwróciłam uwagę na to, kiedy mówiłeś na początku o tworzeniu kontenerów, wspominałeś o rozwiązaniu chmurowym, natomiast do nas Project Team przyszedł, że to mają być kontenery tworzone on-prem, czyli rozumiem, że może być to rozwiązanie i chmurowe i on-premise.
MARCIN: Tak, tutaj w sumie tak naprawdę ważne jest, żeby określić jak my rozumiemy pojęcie chmury, bo mamy chmury publiczne, mamy chmury prywatne i tak naprawdę stosując jakąś platformę konteneryzacji, budujemy sobie taką chmurę prywatną we własnej serwerowni i najważniejsze jest doświadczenie użytkownika końcowego. My tutaj używając własnego sprzętu, własnego oprogramowania,  symulujemy tak naprawdę to, co robi Amazon, to, co robi Microsoft, swoich data center. Oni tak samo udostępniają infrastrukturę konteneryzacyjną, tak samo mają powiedzmy orkiestrację za pomocą Kubernetesa, tak samo umożliwiają nam uruchamianie tych aplikacji, skalowanie ich i właściwie robienie wszystkiego, to co my robimy tutaj lokalnie. I też ciekawa rzecz jest taka, że właściwie wszystkie aplikacje, które są wykorzystywane w kontenerach, nazywa się tak grupowo, zbiorczo jako Cloud Native, chyba że akurat były tworzone wcześniej, więc one nie są tak naprawdę Cloud Native, ale są w środowisku, które jest tak traktowane. Projektem, który zarządza rozwojem technologii Kubernetesa jest Cloud Native Software Foundation, czyli firma, czy tam projekt, który zajmuje się aplikacjami typowo chmurowymi, ale dla kontenera nie jest ważne, czy jest uruchomiony na serwerze w chmurze czy na serwerze w serwerowni lokalnie, w jakimś prywatnym miejscu, gdzie dostęp jest bardzo ograniczony. Zresztą chmura to jest pojęcie bardzo szerokie i obecnie możemy je tworzyć właściwie wszędzie. 
[00:30:00]
ALEKSANDRA: W trakcie dzisiejszej opowieści o konteneryzacji wyłapałam kilka takich narzędzi, które podejrzewam, że służą gdzieś do zarządzania tymi kontenerami. Wspominałeś o Dockerze, wspominałeś o Kubernetesie, o OpenShift’cie. Natomiast rozumiem, że to są całkowicie różne aplikacje.  Jaka jest różnica między nimi? Które rozwiązanie jest lepsze? Jakim narzędziem się lepiej zarządza tymi kontenerami? Czy Docker, czy Kubernetes, jaka jest różnica? 
MARCIN: To jest trudne pytanie, ale może zacznijmy od takiej szczypty historii, bo tutaj pada Docker, pada Kubernetes. To są jakby dwa kluczowe pojęcia,  kluczowe nazwy i tak naprawdę wszystko zaczęło się z grubsza 10 lat temu, kiedy na rynku pojawił się Docker. Docker był rozwijany jeszcze wcześniej, ale kiedy pojawił się na rynku, konteneryzacja zaczęła być trendy, zaczęła być popularna w środowisku. Mieliśmy wcześniej do czynienia tylko i wyłącznie z takimi próbami wykorzystywania funkcjonalności kontenerów, bo sama technologia, która jest pod spodem, jest dużo starsza. Linux udostępniał te wszystkie mechanizmy dużo wcześniej, tylko one były trudne do zarządzania, trudne do wykorzystania w produkcji czy przez pojedynczych deweloperów. Natomiast Docker wystawił bardzo łatwe do wykorzystania API, dodał do tego od siebie jeszcze zestaw bardzo prostych poleceń, które umożliwiały tworzenie tych kontenerów, tworzenie obrazów,  uruchamianie, restartowanie, zarządzanie obrazami, co było cały czas rozbudowywane o kolejne funkcjonalności. I Docker nagle stał się standardem po prostu tworzenia tych kontenerów. Do dzisiaj zresztą takim standardem jest  i obrazy, które powstają w oparciu o pewne zasady, które zostały wtedy stworzone. I niedługo potem zaczęło być jasne, że kontenery są super technologią, fajną, niewielką, taką sprawną, ale w produkcji potrzebujemy czegoś takiego, co potrafiłoby samo się wyleczyć, co potrafiłoby samo się przenieść, przeskalować i robić tym podobne rzeczy. No bo trudno sobie wyobrazić, że mamy 400 kontenerów i każdy z tych kontenerów ręcznie stawiamy, przenosimy, dbamy o niego i tak dalej. I zaczęła być potrzebna orkiestracja. I pojawiło się kilka systemów, które zaczęły ze sobą konkurować. Docker sam stworzył system, który nazywał się Docker Swarm, bardzo ciekawa technologia, która zresztą działa do dzisiaj i jest wykorzystywana w takich mniej skomplikowanych sytuacjach, ale do gry bardzo szybko wszedł Google ze swoim projektem, który się nazywa Kubernetes. I kiedy Kubernetes pojawił się na rynku, właściwie cała konkurencja została zepchnięta na bok. Mieliśmy kilka naprawdę ciekawych platform na początku, zyskiwały one na popularności, natomiast Kubernetes wyprzedził wszystko. Google udostępnił to rozwiązanie jako rozwiązanie typu open source, udostępnił je społeczności i kod zaczął być dostępny dla wszystkich, każdy mógł zacząć dokładać swoje rzeczy do tego kodu, nowe funkcjonalności. Projekt Kubernetesa zaczął żyć własnym życiem i zaczął się rozwijać w takim dość kosmicznym tempie. W przeciągu kilku lat właściwie zdominował rynek na tyle, że każda szanująca się firma chmurowa, każda szanująca się firma, która tworzy systemy operacyjne,  ma swoją własną dystrybucję Kubernetesa. Konkurują między sobą właściwie tymi dodatkowymi funkcjonalnościami, dodatkowymi pluginami, bo Kubernetes ma to do siebie, że jest bardzo łatwo rozszerzalny, bardzo łatwo jest go przystosować do danych sytuacji i do danych wymagań. Są na przykład dystrybucje Kubernetesa, które są bardzo mocno zabezpieczone, które są przydatne w środowiskach, które wymagają ochrony danych, takiej bardzo, bardzo ścisłej, a są na przykład dystrybucje, które są bardzo lekkie i stosowane w miejscach, gdzie nie ma dużej mocy obliczeniowej albo na przykład są bardzo trudne warunki, jeśli chodzi o dostępność sieci. Nawet mamy dystrybucje,  które świetnie działają na Raspberry Pi, czyli tak malusieńki komputerkach, które każdy może sobie kupić za parę groszy i uruchomić w domu, mieć na przykład kilka takich małych maszynek i stworzyć z nich klaster Kubernetesowy i bawić się w taką konteneryzację w domu. Także tu jest multum rozwiązań, multum możliwości i z naszej perspektywy w sumie dla firmy najważniejsze jest to, co potrzebujemy, jaki mamy sprzęt, ile mamy pieniędzy, bo to też niestety ważne. Możemy stworzyć rozwiązania  typu open source, takiego czystego Kubernetesa, ale zarządzanie potem tym jest trudne ze względu na to, że musi to robić zespół lokalny od A do Z od instalacji przez konfigurację, po już rozwiązywanie problemów, update, upgrade i tym podobne rzeczy. Ja wspomniałem tego OpenShift,  wspominałem Mirantis, Kubernetes Engine, wspominałem też Ranchera i to są rozwiązania, które są łatwo dostępne, świetnie wspierane i to są już rozwiązania dojrzałe. Nie ma co się oszukiwać, tak 5, 6, 7 lat temu Kubernetes był jeszcze młody. Miał jeszcze dużo takich problemów wieku dziecięcego, więc trzeba było mocno uważać, kiedy się nim zarządzało, kiedy się upgrade’owało i tak dalej. API ewoluowało bardzo gwałtownie. Pojawiały się nowe funkcjonalności, a stare funkcjonalności były usuwane. Teraz to już jest środowisko bardzo dojrzałe i te platformy korzystają z tego. Na przykład możemy sobie wyobrazić sytuację, w której mamy firmę, która ma dość dużo kontaktu z Red Hatem, wykupione dużo licencji, wykupione wsparcie i tak dalej, długoletnią współpracę, no to w tym momencie logicznie się wydaje, że możemy pomyśleć o wykupieniu u nich licencji na rozwiązanie OpenShift. Jeśli na przykład współpracowaliśmy kiedyś z Dockerem, no to możemy pomyśleć na przykład o firmie Bureantis, która przejęła Docker Enterprise od Dockera. Jeśli nie mamy jakichś wielkich doświadczeń z różnymi vendorami, to możemy pokusić się o przetestowanie różnych rozwiązań i po prostu wybór tego, który najbardziej pasuje do naszego środowiska, do naszej infrastruktury. Po prostu wdrożyć, podpisać kontrakt, wykupić licencję. Tylko tutaj taka drobna uwaga, warto planować z dużym wyprzedzeniem. Proces konteneryzacji i później zarządzania tym wszystkim może być na początku trudny, a jeszcze trudniejsze może być przeniesienie się z powrotem do infrastruktury takiej tradycyjnej, czyli z kontenerów na serwery, a także migracje między platformami mogą być problematyczne. Mimo wszystko Kubernetes jest łatwiejszy do przeniesienia między platformą jedną a drugą albo między serwerownią a chmurą niż taka zwykła aplikacja, którą trzeba reinstalować, rekonfigurować i tak dalej, ale zawsze warto tak minimum 3 lata naprzód przewidzieć jak ta infrastruktura ma wyglądać, żeby się nie okazało, że powodujemy naszą taką wesołą konteneryzacją więcej problemów niż ich rozwiązujemy. 
ALEKSANDRA: Okej, czyli istnieje dowolność, natomiast dalej musimy dostosować się do klienta i do tego co klient wykupił, czyje usługi. Natomiast, zauważyłam, że chyba Twojemu sercu bliższy jest Kubernetes. Jakoś tak przychylniej się wypowiadałeś na ten temat. 
MARCIN: Tak.
ALEKSANDRA: Dobrze, myślę, że już wszystko wiem. Bardzo fajnie mi to opowiedziałeś. Wreszcie rozjaśniło mi się w głowie i już będę wiedziała z czym wrócić do zespołu projektowego, żeby pociągnąć dalej ten temat.
MARCIN: Świetnie.
ALEKSANDRA: Także wydaje mi się, że te najważniejsze rzeczy zostały tutaj już powiedziane. Także bardzo Ci dziękuję za pomoc. No i powodzenia.  
MARCIN: Nie ma sprawy. Ja również życzę powodzenia i do usłyszenia, do zobaczenia.  Cześć.  
ALEKSANDRA: Cześć. 
MARCIN: Jeśli chcielibyście się więcej dowiedzieć na temat Kubernetesa, Dockera i konteneryzacji, ja polecam ze swojej strony kurs Bretta Fischera i Nigella Poultona. Dostępne są na platformach Udemy i Pluralsight. Bardzo ciekawe kursy. Dobrze nagrane, dobrze wytłumaczona wiedza i zdecydowanie polecam część wiedzy, którą zdobyłem właśnie z tych kursów. Polecam również podcast Damiana Naprawy, który jest specjalistą z dziedziny konteneryzacji i też kolegą z Capgemini.
KONIEC