#23 Docker A.D. 2020

2020, Feb 28
Posłuchaj "" na Spreaker

Kontenery… kontenery… kontenery…, czyli co słychać w Docker na 2020!

Ciekawe linki i inne znaleziska z tego odcinka:

Transkrypcja

Łukasz: Cześć! Słuchacie Pato Architektów. Prowadzą Łukasz Kałużny

Szymon: i Szymon Warda. Wszystkie linki do tego odcinka znajdziecie na patoarchitektci.io/23. Oczywiście teraz też na Facebooku, Twitterze.

Ł: Tak. Mamy profil również na Facebooku oprócz Twittera, gdzie będziecie mogli znaleźć nasze wrzuty.

S: Dobrze. To w takim razie linki. Łukaszu – co u Ciebie?

Ł: Trolling albo…

S: O dziwo.

Ł: Albo coś dla świadomego podejścia, czyli czemu każdy element Solida jest zły.

S: Tak. Słynna prezentacja Dana North’a.

Ł: Tak, jest dość stara, ma już parę lat, ale ostatnio znowu wypłynęła.

S: Na Twitterze chyba.

Ł: Tak. Znowu, że mamy zbyt skomplikowane przykłady i komplikujemy kody w Dotnecie. W Dotnet Core. Jeżeli sobie popatrzymy na to, to ja się z nią w bardzo wielu miejscach zgadzam, z bardzo prostego powodu. Dla mnie Solid jest idealny do tworzenia frameworków i bibliotek, które mają być re-używalne.

S: A ja się nie zgadzam z tym bardzo. Zgadzam się z prezentacją Dana North’a, faktycznie ma sens, bo mówi „Pisz prostszy kod”. I tu się zgadzam.

Ł: Tak. I to jest w ogóle kwintesencja tego.

S: Problem polega na tym, że Dan North mówi to z poziomu seniora. Osoba, która rozumie, czym jest prostszy kod. Jeżeli zaczynamy od juniora, czyli kogoś kto zaczyna, to ta informacja „co jest prostszym kodem”, jest bardzo trudna. Więc Solid to jest taki zestaw reguł, które przydają się na starcie, a potem jak każdy zestaw reguł ewoluują wraz z rozwojem osobistym.

Ł: Wiesz co, tak. Tylko jest taki problem, że przez to jak są te osoby wprowadzane (to jest przykład właśnie z Dotnet Core’a, który właśnie wypłynął), za trudnych rzeczy, to Solid i Dry są takim kultem cargo, dowożenia tego sztucznie.

S: Zgodzę się z tym. Jak najbardziej tak. Nie wolno tego zaprzeczać i właśnie w tej prezentacji North’a bardzo brakuje mi tego kontekstu kto to mówi i kto ocenia tego Solida. I jak ja faktycznie oceniam go teraz to faktycznie – nie wszystkie reguły są super plikowalne i gdzieś jest ta granica między „warto to robić” a „już przeginamy totalnie” i jest to po prostu onanizm kodowy. Tak to trzeba nazwać właściwie. Robimy coś tylko po to, żeby było, żeby to zrobić.

Ł: Dobra. To zależy od doświadczenia. Dla mnie Solid będzie dobry zawsze by design przy bibliotekach, przy frameworkach, bo tam pewne reguły mają sens. W przypadku oprogramowania biznesowego piszmy to prościej. I tak, żeby ten kod był łatwo usuwalny, a nie re-faktoryzowalny.

S: Tak, zgadza się. I to jest faktycznie ten główny motyw, żeby łatwo się go dało zmieniać ewolucyjnie, bo często Solid prowadzi do tego, że próbujemy roz magnum w kodzie, a potem nikt nie może tego ruszyć.

Ł: Zamiast go po prostu tylko wysprzątać. Dobra, a co Ty Szymonie wykopałeś?

S: Proste, ale przydatne. „An illustrated guide to oauth and open id connect.” Czemu? Bo naprawdę dość często widuję ludzi, którzy mówią „korzystamy z oauth’a, korzystamy z open id connect’a”, ale ludzie w ogóle nie mają pojęcia jak to działa pod spodem, jak to wygląda. Co więcej, często widzimy, na przykład w rozmowach z biznesem, że „O, to użyjmy tutaj oauth’a, użyjmy sso, itd.”, a biznes w ogóle nie ma pojęcia, co to jest i jak to wygląda. Wpis jest ładny, ma ładnie obrysowane całe flow, ma ładne grafiki. Można dać go zarówno developerom jak i takim bardziej technicznym Product Ownerom, łącznie z nagraniem na YouTubie, gdyby ktoś był leniwy i nie chciał czytać.

Ł: He he he

S: Taka prawda. Czasami treść mówiona jest łatwiejsza w konsumpcji. Bardzo fajny opis, flow, nie tylko dla juniorów czy ludzi nie-technicznych, dla odświeżenia i uporządkowania. Naprawdę ma to sens. Uporządkowanie, fajna, pełna wiedza. Po prostu.

Ł: Ilustracje robią robotę.

S: Robią, bo fajnie się na nie patrzy. To jest takie pro-fajne. To w takim razie zaczynamy właściwie temat naszego odcinka.

Ł: Dzisiaj rozmawiamy o Dockerze. Odcinek inspirowany UserVoice’em przez Łukasza na naszym GitHubie. Porozmawiamy o kontenerach. Jak sobie popatrzymy, to dochodząc w myśli, jest to taki zip lat 2010-2019 poprzedniej dekady.

S: Tak. W ogóle zacznijmy od tego, że to się zaczęło od samego tematu distroless’a, ale jak zaczęliśmy na ten temat rozmawiać, to okazało się, że distroless jest trochę małym obszarem, ale nagle nam się dyskusja rozwinęła w kierunku w „Co z Dockerem będzie się w ogóle działo w tym roku?” Bo końcówka zeszłego roku była bardzo ciekawa dla Dockera. To, co fajnie się działo, jak przechodziliśmy przez Technology Radar od ThoughtWorks’a to też okazało się wtedy jak popatrzyliśmy na to, że „o! ciekawe spojrzenie”. Ale to się już zaczęło materializować tak naprawdę w świecie.

Ł: Było: „Skąd xxx tyle konteneryzacji w tym Technolgy Radar?”.

S: Tak. I faktycznie widać generalnie, że to de facto dojrzewa i pokazuje czym się to staje i gdzie to będzie za parę miesięcy. I oto nagle się okazało, że to już się zaczęło dziać.

Ł: No i teraz trzeba powiedzieć: kontenery to nie tylko Kubernetes, ale mają bardzo dużo wspólnych problemów, ich używanie.

S: Tak, ale Kubernetes mocno napędza to, co się dzieje w kontenerach. Ewidentnie to jest taka seria bolączek, nagle wypłynęła z dużą prędkością.

Ł: Trzeba mieć świadomość tego, gdzie jeszcze można znaleźć kontenery oprócz samego Kubernetesa. To w AWSie to będzie w AWS App Mesh, Fargate w Google Servers, Cloud Run; w Azurze jest to ACI Functions, App Service. Do tego jeszcze podejścia do jakiś ciężkich bramek IoT/EDGE, przetwarzania EDGE’a więc jest sporo tego.

S: Ustalmy generalnie, że kontenery stały się de facto standardem pakowania aplikacji. To nie jest tylko tak, że tylko vendorzy dostarczają swoje bazy danych, na przykład typu Elastic. To też był taki dość spory ruch. Tylko, że to jest po prostu normalne pakowanie aplikacji, pakowanie kodu w kontenery stało się de facto standardem. No więc teraz przelecimy parę obszarów głównych. Pierwszym sugerowanym był distroless. O co chodzi?

Ł: Wiesz co? Zacznijmy od problemu, który w teorii Docker rozwiązywał pierwotnie.

S: Tak.

Ł: Bo odeszliśmy od niego.

S: Lat temu dziesięć.

Ł: No, niecałe osiem, nie wchodząc już w daty. I pierwotnie on miał rozwiązywać zarządzanie zmianą i konfiguracją. Miał rozwiązywać problem, bo nie oszukujmy się, IT jest jednym wielkim pierdolnikiem, jeżeli chodzi o zarządzanie zmianą i konfiguracją. My tylko na papierze mówimy, że to umiemy. Nigdzie więcej. Więc całą ideą było zarządzanie, schowanie, zarządzanie zmianą i konfiguracją, uproszczenie tego albo pozbycie się powiedzenia „u mnie na komputerze to działa” albo „na moim środowisku developerskim to działa”.

S: I ja bym tu dodał, bo to wszystko wypłynęło, to wszystko działało. Kontenerów było tam pięć, dziesięć, dwadzieścia, a wypłynęło w skali, po prostu ruszyło strasznie, jak weszliśmy w Kubernetesa i nagle okazało się, że ok, taką ilością obrazów tego nie ogarniemy. Tak naprawdę.

Ł: Jest coś w tym. Patrząc się dalej z tym zarządzaniem, jak była pierwotnie na prezentacjach przedstawiana konteneryzacja Docker. To zawsze były biblioteki potrzebne dla naszej aplikacji i nasza aplikacja.

S: Tak.

Ł: Tak, dokładnie. I nigdzie nie było pokazywanych zależności od OS-u, że potrzebujemy kawałka OS-u pod spodem. W kontenerze.

S: Tak, bo to wypłynęło z tego, że „dobra, przydałoby się pobrać, o! nie mam tych narzędzi. No to dam bazowy obraz narzędzi i one już będą, już jakoś się pojawią”.

Ł: Dokładnie. Więc pierwotnie Docker nie posiadał pod spodem żadnego distroll, tylko należało pakować potrzebne nam biblioteki. Ale ze względu na lenistwo i wygodę ludzi, pojawiły się warstwy na bazie Deviana, Ubuntu, Alpine’a, dużo różnych, ciężkich dystrybucji. Zaczynając od Alpine’a, który ma 4 MB i ciekawe problemy w niektórych miejscach, po jakieś krowy po 300MB lub 400MB, gdzie mogliśmy wpisać bardzo ładnie APT install, w zależności co wydaliśmy, czy uppercut, żeby zainstalować potrzebne pakiety.

S: W ogóle według mnie niestety bardzo wielką bolączką było to, że jak tłumaczyliśmy Dockera, tłumaczyliśmy, że to jest niby maszyna wirtualna, podczas gdy to nie jest maszyna wirtualna. Jak dalej ludzie myśleli „ok, jak maszyna to…”

Ł: …zrobię to standardowo”

S: APT cool będzie, a jeśli nie ma, to dam obraz bazowy.

Ł: Tak. I distrolles jest tak naprawdę powrotem do korzeni i w przypadku… to jest cały trend a urodził się też taki projekt Google’owy w Google Container Tools’ach, że są po prostu gotowe obrazy, na przykład z Nodem, z Dotnet Corem, które niby zawierają pod spodem żadnych zależności od OSu, żadnej bazy OS-owej, tylko mają wpakowane wszystkie potrzebne biblioteki, więc APT czy innego Package Manager’a tam nie znajdziemy, tylko wkopiowane są na żywca. Same biblioteki.

S: Oczywiście. Skoro i tak wirtualizujemy, więc generalnie to będzie wszystko ładnie działało.

Ł: Tak. No i pierwotnie było zawsze from-scratch, czyli ta warstwa bazowa. I dzisiaj połowa Kubernetesa pod spodem tak lata. Bo Golang czy inne rzeczy statycznie kompilowane, czy FatBinary, radzą sobie w takim środowisku, gdzie mają 5-6 potrzebnych bibliotek w systemie, i nic więcej.

S: Tak, bo to są obrazy, na których ktoś poświęcił czas i znowu skonfigurował co jest dokładnie potrzebne, jakie są zależności.

Ł: Golanga możesz skompilować i wrzucić po prostu.

S: To jest skrajnością tutaj generalnie. Jedna fat binarka i lecimy z tym.

Ł: Tak. Ale to właśnie jest podejście. Więc distrolless to jest pozbycie się tak naprawdę, że mamy warstwę bazową na jakimś OS-ie.

S: Tak. Albo cały łańcuch warstw bazowych, bo to z reguły tak wygląda.

Ł: Tak. Wrócenie do korzeni.

S: Dobra. To w takim razie kierunek jest dobry, na pewno i to się będzie działo, bo po pierwsze odchudzi te wszystkie obrazy i oczywiście będzie się działo. Jeżeli już w tym momencie ruszamy generalnie o Dockerze, to przydałoby się ruszyć cały temat tego, co się wydarzyło w kontekście samego Dockera jako firmy, bo tam się zadziały dość ciekawe rzeczy.

Ł: Tak. To nawet w którymś podcaście w linkach dawałem.

S: Tak.

Ł: Docker jako firma, Docker Inc. sprzedał swój kawałek enterpriseowej platformy do Rentisu, czyli Docker by Edition została sprzedana na zewnątrz, taki niby jeden z klejnotów koronnych, który miał przynosić ten główny biznes. Został wyprzedany.

S: Tak. Czyli kasę de facto. Jeżeli mówimy w takim razie, że sprzedał część swoich klejnotów koronnych, no to powiedzmy sobie generalnie, co zostało i ułóżmy to w takim flow generalnie, jak przepływa kod.

Ł: Tak. Co zostało? Został Docker Hub, Trusted Registry, Docker for Desktop i Docker Community Edition.

S: Tak.

Ł: Mają się skupić na developer experience, jak to ładnie zostało określone. Taka jest ponoć idea. Zobaczymy. Ciągle mają jakieś kryzysy tożsamości jako firma, w którym kierunku idą, ale to jest może wyraźne, kiedy sprzedali taką enterpiseową platformę.

S: Tak. Ciekawe, skąd będą mieli kasę, ale zobaczymy jak to się będzie rozwijało. Dobrze. Czyli generalnie tak naprawdę jak już mówimy o runtime’ach, to powiedziałeś o Docker CE,

Ł: Tak.

S: Czyli Community Edition, a mamy też coś już wcześniej.

Ł: Tak I teraz bardzo ważne: Docker rozwija się tak jak inne open-source’owe projekty, czyli mamy wersje down-streamowe, które są stabilne, czyli Community Edition, potem Enterprise Edition, a cały rozwój dzieje się w up-streamowym projekcie, czyli takim głównym open-sourcowym. I mimo, że Commity Edition jest open-source’owe, to tak naprawdę pod spodem cały rozwój dzieje się w Moby.

S: Ok. Moby to jest zbiór wielu rzeczy, zbiór kilku technologii, które są wykorzystywane, kilku inicjatyw, i omówienie wszystkiego po kolei by nam zajęło dużo czasu. To nie w tym odcinku na pewno, ale wyróżnimy kilka takich najważniejszych.

Ł: Patrząc się na Moby’ego, tam stoi, jak powiedziałeś, szereg rzeczy za nim. Trzy najważniejsze rzeczy z mojej perspektywy to jest containerd, open-sourceowy, utworzony projekt open-sourceowy przez Dockera.

S: Dobra, wtrącę się. Co robi containerd?

Ł: Uruchamia nam kontenery. To jest po prostu środowisko uruchomieniowe. I pod spodem Moby jak i Docker Community Edition korzystają z tej biblioteki do uruchomienia kontenerów.

S: Kubernetes też bardzo ładnie.

Ł: Tak.

S: Dobrze, czyli mamy containerd.

Ł: Następnie jest runc.

S: Wyjaśnienie?

Ł: Uruchamianie kontenerów z command-line’a. Czyli mogę sobie zrobić runc, run-container. Czyli tak naprawdę jeden z interfejsów do manipulacji między innymi containerd.

S:Dobrze! Idziemy dalej.

Ł: I ostatni komponent, który jest istotny z całości, to jest linuxkit. Linuxkit to jest taki wycięty kawałek kernela linuxowego, bardzo mały, który służy tylko i wyłącznie do uruchamiania kontenerów. Czyli możemy sobie w takiej specjalizowanej vm-ce odpalić bardzo lekki kernel, który zajmuje bardzo mało zasobów i na tym posadzić konteneryzację.

S: Ale to fajne, właśnie te ruchy pokazują, gdzie jest koncentracja, zaczynamy traktować kontenery jako totalne commodity, że po prostu abstrahujemy, robimy abstrakcji, common interface, i minimalizujemy tą warstwę bazową, która jest nam potrzebna do uruchomienia.

Ł: Dokładnie. I trzeba zapamiętać, że tak naprawdę Docker, o którym mówimy, to jest Moby ze zbiorem projektów open-sourceowych. A my instalujemy u siebie stabilną wersję w postaci Docker Community Edition. Z ciekawostek, na Azure lata Moby, na AKSie, na płatnej usłudze Microsoftu (które jest świadczone jako Manage service), lata Moby. Tam, gdzie wykorzystujemy Azure Kubernetes Service.

S: I tam Microsoft bierze za to odpowiedzialność.

Ł: I daje support.

S: Dokładnie. SLA i wszystkie inne rzeczy. Fajnie. Czyli mamy tak naprawdę całe warstwy abstrakcji. Tworzony właściwie został CRI-O. [L] Tak. Zacznijmy może…wprowadziłeś to trochę za wcześnie. Zacznijmy od OCI – Open Container Initiative. Jest to rok 2015, założone przez Dockera i parę innych firm. Jest to otwarta specyfikacja runtime’u i obrazów. Czyli mamy dwie rzeczy: jak ma wyglądać nasz obraz z kontenerem, który chcemy uruchomić i w jaki sposób go uruchomić. Więc jest na to otwarta specyfikacja, dwie specyfikacje tak naprawdę. OCI zawiera dwie specyfikacje.

S: Obrazu i runtime’u.

Ł: Tak. W jaki sposób mam odpalić to. I cały rynek zaczyna z tego tak naprawdę już w jakiś sposób korzystać albo zaraz będzie korzystał. Jest to otwarte. Przykładowo jest taki mindfuck w Microsofcie. Znowu do niego wrócę, bo mnie dotknął ostatnio. AKS jakoś za 3-4 tygodnie będzie wspierał już OCI i normalne odpalanie OCI, a Container Registry Microsoftu już w pełni wspiera OCI do przechowywania obrazu.

S: To ładnie.

Ł: Taki drobny mindfuck, że jeden komponent wspiera, a na drugi trzeba poczekać. Więc jest sobie OCI, które jest standardem. I tak jak powiedzieliśmy, są inne runtime’y. Containerd już powiedzieliśmy.

S: Tak.

Ł: Jest to taki goły kawałek, który można wziąć. Idąc dalej, takim największym dla mnie wyróżnikiem, który też jest komercyjny jest podman.

S: Red Hat.

Ł: Dokładnie. Podman jest od Red Hata. Jest to ich alternatywa, bo wcześniej utrzymywali jakiegoś Forka Dockera, gdzie backpartowali security i inne rzeczy.

S: Ale znowu, czemu mają coś własnego? Bo mają swojego Open Shifta oczywiście.

Ł: Tak.

S: Czyli z problemu wynikło, ze skali i ilości tych obrazów, które mają, i co z tym chcieliby zrobić.

Ł: Dokładnie. Więc podman jest ich narzędziem, ich runtimem i zestawem narzędzi do konteneryzacji i pod spodem jest między innymi domyślny dla Red Hat Enterprise, Linuxa 8 czy Open Shifta 4. Podman jest naturalnym środowiskiem uruchomieniowym. Nie znajdziemy Dockera. Jest nawet dowcip, który jest pokazywany na wszystkich prezentacjach Red Hata, kiedy pokazują podmana właśnie, to robi się alias do Dockera, czyli wskazujący na podmana, bo większość poleceń jest kompatybilna. Po prostu.

S: No bo mamy uspójniony interfejs, generalnie co się zachowuje. W sumie przestaje nas interesować, co dokładnie nam odpala te kontenery.

Ł: I z całości, kiedy robimy to poza cloudem, podman ma jedną genialną rzecz. Jest suport na niego w ramach subskrypcji na tego Red Hata.

S: Wiadomo. Red Hat się z czegoś utrzymuje.

Ł: Więc w środowiskach korporacyjnych naprawdę tutaj suport robi robotę. Do tego stopnia, że taki Dotnet Core ma dual suport, od Microsoftu i Red Hat. Więc jak coś będzie nie tak, możemy założyć ticket albo w Red Hacie albo w Microsofcie. I oni się odzywają do siebie nawzajem bez naszego udziału. Więc to jest dość ciekawa rzecz, jeżeli komuś się zdarzyło przy dużych systemach, powinien wiedzieć, że takie są problemy.

S: Nie oszukujmy się, Red Hat od bardzo wielu lat siedzi w enterprise i doskonale wie, jak zaadresować problemy i bolączki, które występują. Support kosztuje, ale jest potrzebny. Większość firm decyduje się na duży projekt bez supportu. Dobrze. To teraz CRI-O?

Ł: Tak. Albo CRI-O, w zależności od tego, jak to kto odczytuje.

S: To wyjaśniaj.

Ł: Tak. To jest taki lekki runtime konteneryzacyjny dla Kubernetesa. Jest to prowadzone w ramach CNCFU. Jest tam cały zestaw narzędzi i tak naprawdę jest to container runtime interface, czyli sposób jak to odpalić. Pod spodem też korzysta z OCI, więc może wykorzystywać run-container, runc, bo tak naprawdę do kraju można podłączyć dowolny runtime, który jest kompatybilny z OCI. I tak naprawdę z całym tulingiem OCI. I tyle. I on jest w Kubernetesie. Tylko tam, jeżeli popatrzymy, bo to ma być warstwa abstrakcji do komunikacji pomiędzy Kubernetesem, a naszym środowiskiem uruchomieniowym naszego kontenera.

S: Ok. I teraz przechodzimy na kolejny temat, który jest bardzo ważny. Ja, jak go widzę, to się zawsze uśmiecham generalnie, bo tak to jest idea, którą Microsoft bardzo mocno promował. A problem, który istniał od startu Dockera tak naprawdę. To jest to, że niestety wiele firm mówi to, na przykład, i tak było w pierwszych wersjach chmurowych, że zgadali się, żeby ich kontenery chodziły obok obcych kontenerów. No bo jakby się ktoś wydostał z konteneru, to w tym momencie ma root’a.

Ł: Tak albo ma problem third-party kontenerów, third-party kodu na naszym klastrze, na naszych środowiskach. Tak. No i odpowiedzią na to Microsoftu był pomysł już dawno, dawno temu, żeby kontenery uruchamiać jako malutkie VM-ki. One faktycznie już teraz są VM-ką.

S: I tak są w ogóle odpalane kontenery Windowsowe. To jest jeden z dwóch sposobów tak naprawdę.

Ł: Tak. Jeden z dwóch sposobów. No więc, mamy tak naprawdę wykorzystanie funkcji wirtualizacyjnych procesora, czyli jawnie wirtualizacji bądź net set virtualisation, do tego, żeby izolować. Bo Docker z definicji nie izoluje swoich workloadów. Od strony bezpieczeństwa nie izoluje. Pozwala na jakąś tam ucieczkę. Więc mamy parę rozwiązań na rynku. Dwa się tak wybijają mocno i używają, mają trochę wspólny mianownik, bo używają KVM’a, czyli Linuxowego modułu do wirtualizacji w kernelu. I czym to jest? Tak naprawdę to są mikro-vmki, które są uruchamiane. Czyli powołujemy sobie taki byt, to jest mikro-vmka lub mikro-vmka z kilkoma kontenerami w środku. Czyli odpowiednik pola Kubernetesowego. Pod spodem, jeżeli chodzi o kernell w tej mikro-vmce, to może być na przykład linuxkit, o którym wspomnieliśmy wcześniej.

S: Tak

Ł: I co tam się znajduje? Oprócz tego, że mamy izolację, to są dwa produkty do tego. Pierwszy jest taki open-sourceowy, który nazywa się Kata Container. Kiedyś był między innymi przez Intela rozwijany, jest w CNCFie. I pozwala nam po prostu podnieść to jako vm-kę, zamiast kontenera pod spodem na takim wirtualizatorze. Druga ciekawa rzecz to jest AWS Firecracker. I FireCracker jest o tyle ciekawy, że został produkcyjnie przetestowany przez AWS-a na Lambdzie. Czyli pod spodem Firecracker, wszystkie landy są uruchamiane na Firecrackerze. Oni to upublicznili i zrobili do tego interfejs zgodny z OCI, żeby można było to sobie wpiąć.

S: Ok. To jest jedno z podejść do problemu, jak zarządzać bezpieczeństwem z poziomu dla imag-y i kontenerów.

Ł: Wiesz co, jeszcze bym Ci przeszkodził, zanim przejdziemy dalej, bo sobie przypomniałem, że jest jeszcze Vmware ze swoją zabawką. Tam to się będzie nazywało Native Pots w VMware I jest taki projekt – pacifica, który jakoś w tym roku powinien już ujrzeć światło dzienno-produkcyjne. I dorzucę do tego, że z mojej perspektywy to nie wygląda aż tak dobrze, jak wejdziemy w takie detale techniczne. Ich kolejny Vmware’a podejść do kontenerów za późno skoczyli na to i kombinują, jak zrobić tą konteneryzację bardziej infrastrukturalną niż aplikacyjną.

S: Tak, tu mam takie wrażenie, że ile razy Vmware wyskakuje z czymś w kontekście kontenerów, to śmierdzi to taką starością, takim podejściem. To znaczy chłopaki, bardzo są wielkie te Vm-ki, nauczyli się włączać kontenery i to nie do końca działa.

Ł: Adresują to do obsuw.

S: Tak. Oni cały czas myślą, że jest to obsuw cały czas na temat wirtualek myślą, a to już się trochę pozmieniało.

Ł: Jest tam w pacifice, będzie dużo ciekawych problemów, między innymi właśnie z izolacją workloadu, więc zobaczymy, co im z tego wyjście.

S: Dobrze, ale mówiliśmy właśnie o wirtualizacji. Drugim rozwiązaniem jest Rootless.

Ł: Tak.

S: Też bardzo temat wypłynął na footworksowym TechRadarze.

Ł: Tak. Pojawił się na footworksowym Radarze, żeby zacząć się tym interesować i oceniać. Rootless ma prostą ideę. Domyślnie, tak jak środowiska runtimeowe latają sobie po prostu jako deamony na uprawnieniach roota.

S: Co w sumie jest niebezpieczne, bo jeżeli ktoś wyjdzie z tego kontenera, to uprawnień ma dość dużo, powiedzmy, może wszystko robić.

Ł: Tak i założenie rootlessu jest bardzo proste. To to, że fakeujemy sobie w środku, robimy sobie remapowanie i odpalamy to sobie w kontekście zwykłego użytkownika. Cały ten runtime i możemy właśnie z nieuprzywilejowanego użytkownika tworzyć kontenery i nimi zarządzać. Wyrzucamy to wszystko z rootowej części systemu. To jest prosta idea.

S: Tak i powoli już realizowana. Nie jest to bardzo łatwe na chwilę obecną.

Ł: Tak, jest tam jeszcze trochę problemów, eksperymentalnie jest to zainicjowane w Dockerze Community Edition już wleciało. Podman coś tam potrafi, ja nie nazwę jeszcze tego wygranym. Sam się nie czuję i pod tym się nie podpiszę. Na przykład, jest klasyczna problematyka. W szczególności, że one znajdują się w user space, ale jeszcze kombinują jak to bezpiecznie zrobić. Jest parę rzeczy, które można zastosować. No ale to jeszcze nie ten moment.

S: Dokładnie. I gorący temat, który znowu też był takim motywem, który był na footoworksowym Radarze i już jest realizowany, to jest bezpieczeństwo. I tu widać przede wszystkim to, że w końcu jest czas, żeby się temu przyjrzeć i jest to realizowane, i nie ma pomysłu jak go ugryźć. Bo dwa lata temu to było generalnie na zasadzie „Róbmy to”. A teraz faktycznie powstały przede wszystkim narzędzia, powstały podejścia i powstała automatyzacja do tego wszystkiego, bezpieczeństwa, w kontekście kontenerów i w kontekście spojrzenia całościowego na naszą aplikację jako kod i obrazy bazowe, i co budujemy.

Ł: Wiesz co, tak. Tylko teraz zaczynamy się. Jeżeli chodzi o narzędzia i best practises, one istnieją tak z trzy lata, więc to nie jest tak, że są standardy od trzech lat dla Dockera jak i dla samego Kubernetesa. Jest coś takiego, co się nazywa na części bezpieczeństwa, jest standard określony w CIS Benchmark. Istnieją takie benchmarki, czyli zestaw wytycznych, jak to wszystko bezpiecznie konfigurować. Dla Dockera i Kubernetesa one istnieją już trzy lata, więc best practises istnieją.

S: Tylko teraz się nimi przejmujemy bardzo mocno.

Ł: Tak.

S: Widać generalnie, że to wyszło na tapetę, bo jak to wyszło od enterprise’u to ktoś powiedział, ok fajnie, że umiemy to szybko, ale teraz jak to działa wewnętrznie. Narzekania na bezpieczeństwo w Dockerze jest od dawna, nie oszukujmy się.

Ł: Tak.

S: Teraz przyszedł ktoś i powiedział” Sorry, póki tego nie ogarniecie, nie wejdziemy z tym na produkcję”.

Ł: Tak, dokładnie. Więc są standardy. Drugie: są best practises. Docker ma bardzo fajny, długi dokument, jak zrobić bezpiecznie Docker Community Edition, Enterprise Edition. W jaki sposób zrobić bezpiecznie. Więc best practises posiadamy. Więc jest już się na czym wzorować. Zalecam zdrowy rozsądek, bo niektóre są troszeczkę już przesadzone dla większości aplikacji. W szczególności dla tych wewnętrznych. Ale są, więc można się do nich odwołać. Linki znajdziecie w materiałach, właśnie do tych best practises.

S: I są też narzędzia.

Ł: Tak, narzędzia. Może zacznijmy jeszcze od problemu z bezpieczeństwem, o którym zaczynamy myśleć. To znaczy, o którym zawsze się mówiło na szkoleniach, prezentacjach. To są bazowe, z których korzystamy. I masz dwa problemy, takie z mojego punktu widzenia security. Pierwszym jest to, że powinniśmy korzystać z oficjalnych obrazów. Nadal jest problem, że ludzie próbują korzystać z rzeczy, które są zrobione na przykład LukaszKaluzny/xxxx na Docker Hubie.

S: Z takich nigdy nie korzystam.

Ł: Ty nigdy nie, ale ludzie biorą, bo „jest coś gotowego na mój problem”.

S: Raczej piję do tego, że „od Łukasza Kałuznego”, ale tak ;) Zgodzę się, że faktycznie generalnie na Docker Hubie jest od groma obrazów, które są robione, zaciągane z jakiegoś tam Repo GitHubowego. Plus, że widzimy faktycznego Docker Compose’a tam.

Ł: Docker File’a.

S: Tak. Ale to się może zmienić tak naprawdę i takie poleganie na tym jest dość śliskie. Sam się raz przejechałem.

Ł: Tak. Więc tak naprawdę dobrą praktyką, o której przydałoby się pamiętać w organizacji, to jest tak naprawdę korzystanie z oficjalnych obrazów dostawców i teraz to jest totalny mindfuck, bo Red Hat ma swoje Repo, Microsoft ma swoje Repo. Elastici też się gdzieś wyniosły.

S: Wszyscy są gdzieś indziej, jest masakra.

Ł: Jest to porozwalane, więc trzeba wychodzić od „co mam użyć”, od tego co wskazuje dostawca.

S: Tak.

Ł: Runtime’u, innych rzeczy, rozwiązania, w zależności od tego, czego używamy, czy framework’a. To, co wam wskazuje dostawca. Druga rzecz odnośnie problemu z obrazami, to że potrafią zniknąć.

S: To jest problem, który był swojego czasu w MPMie, że nagle zniknął jeden obraz i wywaliło się kilkadziesiąt tysięcy innych bibliotek zależnych. To będzie występowało.

Ł: Tak. I rozwiązanie jest tu proste i brutalne. Należy utrzymywać swoją kopię.

S: Brutalne, bardzo, ale na tym to się skończy.

Ł: Tak Albo niektóre virtual tak naprawdę mamy w Artifactory i w paru innych mamy te virtual, które cachują i trzymają nam po pobraniu.

S: Tak. Jeszcze pozostaje pytanie generalnie, czy te, które zniknęły, czemu zniknęły, czy są na tyle stare, że w ogóle powinniśmy się im przyjrzeć, że może z nich już nie korzystajmy.

Ł: Ale wiesz, jakie jest z legacy w dużych organizacjach.

S: Wiem, szczególnie, kiedy przychodzi czas na migrację lub upgrade. To nie jest takie proste.

Ł: Albo biznesowo to nie jest opłacalne.

S: Zgadzam się w zupełności. Więc tam stoi za całą serią Firewall-i. [L] Chciałbym pozdrowić parę aplikacji w PHP56, które widziałem, że latają produkcyjnie gdzieś.

S: Tak. Będzie takich od groma, dokładnie.

Ł: Dobra. Więc trzeba je skopiować, zbudować listę dozwolonych. W pewnym momencie będzie trzeba jakieś procesy nadzorcze, bardzo ładnie nazywane governance-owymi, tak naprawdę, obudować te bazowe rzeczy, z których korzystamy.

S: Tak. I mieć świadomość, co te bazowe obrazy, jakie mają problemy, bo będą miały problemy. One będą wypływały. I wchodzimy teraz na całą automatyzację tego wszystkiego. Czyli skanowanie naszej aplikacji w formie całości, czyli skanowni, mamy całe CI, mamy Repo, runtime. To wszystko tworzy naszą aplikację i to automatyzujemy nagle, bo nagle potencjalnych dziur mamy dość dużo.

Ł: Tak. Trzeba pamiętać, że przez to, że korzystamy z jakiejś bazy zależności pod spodem na bazie jakiegoś sytemu, to łapiemy z nimi podatności, tak naprawdę, bo jest tego więcej.

S: One będą występowały. Trzeba się z tym pogodzić.

Ł: Tak, jest to standard. Obrazy potrafią mieć naprawdę sporo. Więc, tak jak Szymon powiedział, trzeba to zautomatyzować, więc o co chodzi. Tak naprawdę powinniśmy przeskanować nasz kontener pod względem (tak jak skanujemy system operacyjny) podatności, czy aplikacja zawiera jakieś podatności.

S: Ja bym doprecyzował. Nasz kontener, czyli nasz bazowy image i ten wpis, który my stworzyliśmy, bo dziury mogą być w obydwu miejscach.

Ł: Tak. Czyli mówimy o całości. Czyli tym, co wypluwa, więc taką podstawową rzeczą jest skanowanie i robimy to w trzech miejscach. Ja to zawsze określam poziomami paranoi. Takim przynajmniej podstawowym będzie robienie tego w ramach continuous integration, czyli albo na pull request czy na głównym buildzie zawsze to powinno być skanowane. Potem kolejne to jest regularne skanowanie Repo czy obrazów, które tam leżą, czy nie są za stare. I na koniec skanowanie runtime, czy obrazy, których używamy tam, też nie mają jakiejś podatności. Więc są te trzy miejsca. I teraz ważne: jest masa narzędzi do tego.

S: Właśnie chciałem Cię ciągnąć za język, bo właśnie mówisz, że trzeba, a generalnie tego jest trochę na rynku. Lecisz, co tam mamy?

Ł: Dobra. Jeżeli sobie wyróżnimy, jest tego masa. Ja wybrałem kilka, z którymi mam styczność, które można użyć. Pierwszym to będzie Anchore do skanowania w Repo, do integracji z CIM. Posiada też w wersję komercyjną, więc jest jako open source jako komercja, więc możemy sobie wpiąć w CI Repo, ma tez jakąś integrację z Kubernetesem, jeżeli chodzi o runtime. Więc, możemy to wpiąć. Potem kolejne to będzie Aqua microscaner i trivy. To są wersje komercyjne. Dobrze skanują CI, mogą skanować obraz z Repo. Niestety musimy sobie to wszystko oscryptować samodzielnie, cały ten proces, ale da się je włączyć w szczególności trivy bardzo łatwo się włącza w proces Ci, bo to jest po prostu następny krok, w którym mówimy: „przeskanuj mi ten obraz i wypluj z tego raport”. Jeżeli wyjdę z kodem niezerowym, to albo wywala, albo zrób warning, że trzeba się temu przyjrzeć, w zależności od podejścia.

S: W konfiguracji bit serwera, jak do tego dochodzimy. Oczywiście. [L] Tak. Kolejną rzeczą to będzie Clair. Pod spodem działa on w różnych miejscach, m.in. w QI-u, teraz należy do Red Hata, tam pod spodem. Był zapoczątkowany ten projekt przez Core RS. Więc tak to wygląda, jeżeli chodzi o skanowanie. Dodatkowo, jeżeli chodzi o Repo, w szczególności, bo cloudowe zaczynają się dorabiać wbudowanego skanowania regularnego. Docker Hub na przykład je posiada. A teraz z platform, które możemy użyć do skanowania lokalnie, jest to projekt w ramach CNCFU, jakim jest Harbor. I jest to repozytorium kontenerów, ale również posiada wbudowany skaner, który pozwala nam to robić regularnie. Wspominałem wcześniej o regularnej przebudowie.

S: Tak.

Ł: Kontenerów. Też powiedziałeś o tym. Chodzi o to, żebyśmy spróbowali zautomatyzować ten proces, że jeżeli wykryjemy jakieś podatności, to, że automat tak naprawdę zaciąga nową bazę i przebudowuje nasze wszystkie aplikacje i automatycznie je gdzieś deplojuje.

S: Dokładnie tak się robi w aplikacjach Dotnet Coreowych, updatey na zależnościach i sprawdzamy czy to w ogóle działa. Określamy czy robimy na minor major i automatyzujemy sprawdzenie,w jaki sposób to się dzieje.

Ł: Dependency Bot Manager, jak to ktoś ostatnio określił, że czuje się jak manager bota, który tylko wypluwa pull requesty.

S: Coraz więcej narzędzi do Ci ma to w formie przełącznika, że „przeskaluj zależności, zrób upgrade, jak są nowe rzeczy to zrób PR’a, itd.. To było już w linkach, w których odcinkach, że de facto boty ogarnęły całkowicie temat i wypuściły na produkcję.

Ł: Tak, porozmawiały ze sobą i puściły.

S: I pochwaliły PR’a.

Ł: Tak. I tu bym dorzucił, że to jest ten proces całej automatyzacji, czyli CI Repo Runtime. Jeżeli mamy budżet albo dużą organizację, możemy tym zarządzić bardziej centralnie. Jest tego trochę na rynku, ja wyróżniam dwie platformy, które dają radę, które można śmiało użyć. Są to Twistlock i Aquasecurity. One tak naprawdę pozwalają nam się wpiąć w cały cykl życia, czyli w CI, Repo Runtime, wyświetlić to w jednym miejscu, zobaczyć w centralnym miejscu, mieć centralne miejsce do zaraportowania, zdania tego. Z drugiej strony mają masę dodatkowych rzeczy, które znajdują się w Runtime. Tak jak na przykład zarządzanie już bardziej w środku, w bebechach, tym jakie wywołania w kernelu wykonują, jakie capatibilities wykorzystują, czy jakieś Cloud Native Firewall’e wbudowane w kontener. Więc jest tego tam naprawdę sporo i jeżeli mamy budżet, warto się tymi platformami zainteresować, bo one podchodzą do tematu holistycznie. Dają nam to z jednego miejsca.

S: Jeżeli mamy dużą organizację, to bezpieczniki będą od nas tego wymagały, takiego holistycznego podejścia.

Ł: Albo sami z tym przyjdą.

S: Dokładnie. Wymagania, które sobie określimy albo określi dział bezpieczeństwa doskonale wymusi narzędzie. Dobrze. Teraz podsumujmy, bo nam się trochę przedłuża. To co mi się nasuwa, to w jakim tempie przewidywania, o których rozmawialiśmy w kontekście technology footworksa, się nagle zaczęły ziszczać. Tempo jest niesamowite, bo to co mówiliśmy, że będzie się działo już się dzieje obecnie tak naprawdę. Jest spore ciśnienie na bezpieczeństwo i na wszystkie inicjatywy.

Ł: Tak. Footworks to pokazuje. Trzeba powiedzieć, że te kontenery, przestańmy je nazywać new VM, parafrazując różne podejścia. Nie. To jest już commodity.

S: To jest totalne commodity. Jak jest używane, jak często, jaki pęd dał temu wszystkiemu Kubernetes, to pokazuje, że nie ma już wyjścia, to nie jest zadanie czy powinniśmy, tylko jak powinniśmy go wykorzystywać.

Ł: Dobra. Żeby coś mieć z tego odcinka, to dwie rzeczy. Po pierwsze: warto wrócić do korzeni, czyli zobaczyć czym jest distrolles i wiedzieć, o co w tym chodzi. Żeby mieć świadomość, jak bardzo zboczyliśmy.

S: Tak

Ł: Nie mówimy, że trzeba teraz wrócić i zaraz wdrażać from scratch. Nie, ale zobaczyć o co w tym chodziło.

S: I wchodzi to, że będziemy do tego zmuszeni i jest to temat, który wydaje się być ugrzany, nie jest to coś, przez co będziemy musieli się przebijać, tylko zbieramy narzędzia i używamy ich, i integrujemy je w CI. I to w większości sytuacji działa.

Ł: Więc porada, jeżeli chodzi o bezpieczeństwo: zestaw proces zarzadzania obrazami i zacznij używać narzędzi open-sourceowych, które wymieniliśmy w swoim procesie CI oraz skanowaniu Repo. Zestaw ten proces.