Łukasz Kałużny: Cześć, słuchacie Patoarchitektów, prowadzą Łukasz Kałużny.

Szymon Warda: I Szymon Warda. Wszystkie linki oczywiście patoarchitekci.io/60. Lecimy z tematem tego odcinka. A co będziemy dzisiaj omawiali, obgadywali?

Łukasz Kałużny: Dzisiaj - świnkę morską albo jej odłam czyli GitOps, czyli siądziemy sobie do definicji czym jest GitOps, nasze wrażenia i czy to hit czy kit, jak to w ogóle wygląda.

Szymon Warda: I też co jest na rynku de facto z GitOpsa.

Łukasz Kałużny: To co, jak Ty rozumiesz, Szymon, GitOpsa?

Szymon Warda: Zarządzamy aplikacją i procedurą z kodu, czyli wszystko co mamy zdeployowane, de facto w pewien sposób znajduje się w kodzie. I to jest nasze główne źródło definicji - z prawdy, właściwie co ma się dziać.

Łukasz Kałużny: I wiesz co? Jak tutaj byśmy to sobie rozwinęli? Bo w tym miejscu się niestety zgadzamy, więc jeszcze się nie kłócimy. Tak, dla mnie tak samo. GitOps, mimo tego co jest na rynku, to co stoi za tym hasłem… To zostaje przy pierwotnej definicji, czyli tak naprawdę jest to ta część prowadzenia praktyk developerskich do zarządzania i deploymentu, czyli właśnie dodanie pull requestów, repozytoriów, samego tytułowego Gita i zarządzanie tam konfiguracją i wypychanie tego przez Infrastructure as a Code i CI/CD i toole orkiestracyjne.

Szymon Warda: Tak, Przy czym mam wrażenie, że branding wokół całego tematu jest trochę inny, bo często branding jest taki de facto jednak tego tool’a CI/CD jest bardzo mocno ukryte. Tak, dorzucę swoje 3 grosze. Tutaj możemy się za chwilę rozbić. Ale zgadza się, to jest… Po raz kolejny nadaliśmy nazwę dobrym praktykom i tyle. Nic tu się nie zmieniło. Za bardzo.

Łukasz Kałużny: Dobra. I to jest taka pierwsza tradycyjna definicja, o której mówiliśmy, czyli mamy de facto DevOpsów, SysOpsów wrzucono na stack CI/CD i wklejono ich narzędzia tam, bo też nie ma co się oszukiwać, te narzędzia już wcześniej istniały w większości przypadków, które wykorzystujemy i patrząc się rynkowo, dając przykłady takich narzędzi, mamy np. Ansible’a, którego odpalało się ręcznie z palca, a tak naprawdę można było przenieść jego całą konfigurację, całą zawartość i trzymało się w Gicie i przenosiło się wykonanie np. tych playbooków, czyli flowów, które ma wykonać - były wywoływane z CD. W CI’u możemy np. sprawdzić je jakimś linterem czy kod jest ok, odpalić jakieś wstępne testy, które daje Ansible, żeby sprawdzić czy ten playbook jest działający. Więc dostawaliśmy cały zestaw narzędzi już wcześniej.

Szymon Warda: Nadać jeszcze standardy, to jest bardzo ważne, bo jeżeli mamy wszystko w kodzie to możemy politykę nazewnictwa wymusić, możemy kodowanie, możemy wymusić sprawdzenia i wszystko inne. To jest cała potęga tego, że trzymamy tylko w repo mamy jakiegoś toola, który weryfikuje jakość tego tekstu. To jest super ważne i to nam daje dobry GitOps.

Łukasz Kałużny: Tak. Ja bym na sekundkę przeszedł na drugą rzecz, która się troszeczkę pojawiła z boku razem z kontenerami i Kubernetesem. Bo z jednej strony teraz powiedzieliśmy sobie, że mamy… Po prostu zarządzamy narzędziami, orkiestracją z poziomu kodu, który trzymamy gdzieś w repozytorium, zazwyczaj w gicie. Stąd ta nazwa Git Operations. Ale pojawiła się też rzecz, z którą Ty, Szymon miałeś też sporo wspólnego, czyli wykorzystanie rzeczy wokół Kubernetesa, gdzie Kubernetes trzyma wstępny docelowy, ja to nazwę wstępny docelowy stan - naszej konfiguracji. I te praktyki GitOpsowe zostały zaimplementowane w dwóch narzędziach jest to flux i Argo CD.

Szymon Warda: O tak, tak, tak, tak. No bo jeżeli chodzi o infrastrukturę, powiedzmy załóżmy, że azure’ową, czy jakąś chmurową, czy jakąkolwiek, to tutaj za bardzo nie ma dyskusji, rynek się ustandaryzował. Natomiast jeśli chodzi o Kubernetesa, to właśnie jest dość dużo dyskusji. Mamy dwa narzędzia i one mają diametralnie inne podejście. Jedno jest pullowe, drugie jest typowo pushowe. Mamy fluxa, który jest pullowy, czyli flux pracuje sobie ładnie na klasterku i on zaciąga danego repo, stan i aplikuje ten stan. Czyli raz na jakiś czas robi sobie pulla, weryfikuje i stara się stan zaaplikować. Tyle - w sensie flux nie ma za bardzo klienta na którymś serwerze zewnętrznym Argo działa w drugą stronę, po prostu to bardziej model starszy, może bardziej dojrzalszy, gdzie on pushuje de facto konfigurację na klaster.

Łukasz Kałużny: Przy czym ważne: nadal w sync’u jest Twój stan z repozytorium źródłowego.

Szymon Warda: Oczywiście to jest pytanie po prostu… Ale syncuje serwer naszego CD i gdzie on się znajduje tak naprawdę… W kontekście flux znajduje się w klastrze i nie ma UI’a nazwijmy to, w którym ładnie zobaczymy co się zadziało. Tak i jest to relacja tak… Miłości/nienawiści.

Łukasz Kałużny: Tak, a w przypadku Argo tak jak Szymon wspomniał filozofia narzędzia nawet pewne części pod spodem komponentów ze sobą żebyście mieli świadomość współpracują na zasadzie właśnie samego codebase’u. Były pewne unifikacje w silniku do syncowania, na przykład z Gita. I założenie jest takie, że Argo jest zainstalowane na Kubernetesie, pobiera sobie te definicje z repozytoriów, ale tak jak Szymon powiedział, on pushuje. Tak naprawdę pushuje na klaster, na którym jest zainstalowany, bądź na inne klastry kubernetesowe.

Szymon Warda: To ja mam pytanie - a czy nazwałbyś dalej GitOpsem sytuację gdzie pushujemy z pipeline’ów np. Nieważne czy githubowych, azure’owych…

Łukasz Kałużny: Dla mnie to jest… Inaczej - w moim rozumieniu - tak, to jest tradycyjny GitOps.

Szymon Warda: Okej, to się zgadzamy jak najbardziej. Ja bym powiedział tak: najmniej problemowy GitOps.

Łukasz Kałużny: No dobrze - i teraz, jeżeli sobie pójdziemy teraz na całość, pójdźmy sobie do praktyki. Na początku tego odcinka zastanawiałem się czy to nagrywać w ogóle czy nie, bo GitOps, jeżeli popatrzymy… Pewnie u Was w firmach również - jest szeroko wykorzystywany Infrastrucure as a Code, czyli terraformy, ARMy, bicepy, inne wszystkie DSLe do obsługi np. chmur czy tool’e, które odpalamy z Continuous Deployment’u do Kubernetesa istnieją szeroko i są szeroko wykorzystywane.

Szymon Warda: Ja bym się zgodził z tym, że istnieją. Nie zgodziłbym się z tym, że są wykorzystane szeroko albo są w podzbiorach pewnych części organizacji, że pewien zespół korzysta. Ale dalej moje zastrzeżenie jest takie, że spora część organizacji wyklikuje z portalu. Dlatego bym się tutaj pokłócił z “szeroko”. Niestety, ku mojej rozpaczy, ale tak się po prostu dzieje.

Łukasz Kałużny: W State of DevOps było podobnie to ujęte, że continuous deployment nie jest aż tak szeroką praktyką, IaaS nie jest aż tak szeroką praktyką. Ale większość nowych projektów tak startuje teraz.

Szymon Warda: Tak - i sporo organizacji dojrzewa do tego, żeby zacząć. Problem bardzo duży pojawia się… Może to będzie na inny odcinek, ale problem pojawia się: jak istniejące środowisko, które nie było wyklikane, jak je teraz przemigrować do IaaS’a.

Łukasz Kałużny: Tą część IaaS’a zostawmy. Dobra, ale tak, czyli praktyki pipeline’owe na rynku istnieją. I tak naprawdę podsumowując, żebyście mieli świadomość jak powinien wyglądać dobry pipeline GitOpsowy, w tej tradycyjnej formie, tak naprawdę powinniśmy podchodzić do tego jak do kodu, bo praktyki deweloperskie, z dbania o jakość powinny mieć przełożenie też na takie flow właśnie DevOpsowe, GitOpsowe, czyli po pierwsze repozytorium i sposób zarządzania. Pastwiliśmy się nad tym, czy też przy mikroserwisach tak naprawdę czy jest to gitflow, czy będzie to zamiast gitflow’a, korzystanie po prostu z monorepo i szybkich krótkich pull requestów. Decyzja należy do Was. Ja idę w tym zawsze w kierunku Monorepo akurat przy intrze.

Szymon Warda: Jeszcze masz oczywiście trunk based development, który też bardzo teraz nabrał wiatru w żagle.

Łukasz Kałużny: Tak, rumieńców. Więc to jest jedna część. Jeżeli potem chodzi o runnery, możecie mieć git laby, bitbucketowe, Bamboo, Azure, DevOps, GitHub Actions, whatever - co wybierzecie. Wszystkie z tym są tak naprawdę zgodne i rynek wykorzystuje wszystko. I to wszystko ze wszystkim się łączy, ale trzeba się skupić na tym, że w CI’u - i to jest praktyka akurat cholernie pomijana - że Continuous Integration w GitOpsie i w ogóle w IaaS, też powinien mieć miejsce, czyli sprawdzanie, robienie linterów, być może częściowo skanowanie pod względem bezpieczeństwa takiego kodu, który produkujemy. Jeżeli robicie terraforma. Więc takie rzeczy warto sobie w ramach Continuous Integration sprawdzić. Jeżeli robicie w terraformie, najbardziej przyjemne do zaimplementowania.

Szymon Warda: Tak, to muszę powiedzieć, że faktycznie Terraform, jeżeli chodzi o zbiór tooli dookoła automatyzacji, dużo ma i faktyczne, te tool’e są niezłe. A to mam pytanie w takim razie generalnie. Jakie są podejścia? Mówimy o linterach. Załóżmy, że niech będzie pull request niepoprawnego lintowania. Lintujesz i poprawiasz na serwerze, czy odrzucasz PR’a? Mówisz, że jest zły? Bo są często dyskusje o to.

Łukasz Kałużny: Inaczej, w przypadku Infrastructure as a Code: niestety dużo z tych narzędzi i ich konfiguracji jest sterowana wcięciami, więc odrzucam.

Szymon Warda: Zgadzam się: dokładnie ta sama polityka mimo wszystko.

Łukasz Kałużny: Jest problem to, że możemy rozjechać… Poza tym fixowanie… Nie widziałem jeszcze automatu, który by potrafił zafixować YAML’a.

Szymon Warda: YAML’a nie, ale np. takiego terraforma, generalnie gdzie wcięcia nie są tak krytyczne.

Łukasz Kałużny: To inaczej: tam gdzie nie jest to krytyczne bym sobie pozwolił właśnie wrzucić forma terra w CI’a i zrobić commit do tego pull request’u automatem. To jest spoko sprawa, odmóżdża. Ewentualnie zostawiłbym ślad, że znowu zapomniałeś zrobić FMT przed wrzuceniem kodu.

Szymon Warda: Ja bym dalej nie robił mimo wszystko. To jest bardzo upierdliwe i za każdym razem wiadomo co robię pod nosem, ale mimo wszystko generalnie robienie commita przez taki automat po drodze, gdzie jeszcze inne commity, to się prosi aż o jakiś konflikt.

Łukasz Kałużny: No, będziesz miał, to jest standard… Jak zapomnisz zrobić fetch’a przed tym.

Szymon Warda: Ale taki z życia wzięty problem, który faktycznie występuje i to są dyskusje, które zawsze się pojawiają de facto jak tylko jakiegokolwiek lintera włączymy.

Łukasz Kałużny: Dobra, czyli tak mamy CI. Co do CD to tak naprawdę jedyna praktyka, która jest, bo to jest tak naprawdę puszczenie tego co chcemy wdrożyć… Jedyna praktyka, którą widzę jest troszeczkę omijana, czyli tak jak zresztą przy infrze. To też jest jedna rzecz przy pull requestach, której nie wspomniałem, a brakuje tego, że brakuje zazwyczaj akceptacji. Ludzie rzadko robią w przypadku infry, robią pull requesty, które ktoś… Druga osoba sprawdzi i zaakceptuje. To jest pierwsza taka rzecz, a na continuous deploymencie rzadko ktoś klika akcepta. Tylko jedna osoba ręcznie wywołuje sobie te pipeline’y, żeby zdeployować na właściwe środowisko.

Szymon Warda: Powiem Ci, że mam trochę inne doświadczenia, z reguły jest tak, że jak widzę to jak jakaś organizacja ma nazwijmy to GitOpsa w tej wersji teoretycznej myślę generalnie, że jest to po prostu kod i deployment, to z reguły już te PR’y jakoś śmigają. Nie ma bardzo szerokiej adopcji, ale z reguły jest grupa zapaleńców, którzy pewnie to wdrożyli. Którzy faktycznie z tego korzystają.

Łukasz Kałużny: Wiesz co, to może moje spaczenie? Poza finansówką tego nie widzę.

Szymon Warda: Tylko, że ja ogólnie w finansówce siedzę.

Łukasz Kałużny: Bo zazwyczaj jest potem, że w projekcie zazwyczaj na tych 10 deweloperów siedzi ten jeden DevOps i nie ma komu chętnemu zreview’ować. To jest też taki problem organizacyjny, że mimo że DevOps miałby polegać na holistyczności zespołu i running your own shit, to takiej rzeczy nie ma rynkowo. Nie stosujemy takiego podziału, więc ten DevOps robi sztuka dla sztuki pull request’y, żeby co najwyżej coś przypilnować i zobaczyć.

Szymon Warda: Czyli ten podział będzie coraz większy. Łącznej wiedzy jedna osoba nie pojmie odnośnie Kubernetesa, infrastruktury, kodu i jeszcze paru innych rzeczy. Nie ma szans.

Łukasz Kałużny: Czyli w CD to jest po prostu deployment. Dobrze sobie zrobić flagi po prostu do akceptacji. Jest jedna rzecz, z którą zawsze będę się kłócił, ale to jest zawsze dojrzałość zespołu, projektu, rozwiązania. Czy mamy jakieś chociażby smoke testy po wgraniu? Jeżeli podchodzimy do GitOps’a to jest taki element, którego nie zobaczycie w tych configach i raczej nie zobaczycie w opisie tego. Ale tak naprawdę jeżeli robimy continuous deployment. Albo jak to sobie do tego podchodzimy, to trzeba pamiętać, że dobrą praktyką byłoby na koniec pipeline’u zrobienie tak naprawdę chociażby smoke testa. Czy to, co postawiliśmy, w jakikolwiek sposób działa, w szczególności jeżeli kończy się deploymentem aplikacji.

Szymon Warda: Ja się tu zacząłem uśmiechać bardzo mocno, bo tu wchodzi moja miłość i nienawiść do fluxa. Niestety we flux’ie zrobienie takich smoke testów jest wręcz absurdalnie trudne, a może jeszcze bardzo upierdliwe.

Łukasz Kałużny: Wiesz co? Za sekundkę przejdziemy sobie do fluxa, skończmy tylko temat klasycznego GitOpsa.

Szymon Warda: Przez klasyczny rozumiesz pipeline’y? Dobrze.

Łukasz Kałużny: Rozdzielmy: klasyczny to jest ten pierwotny; flux, Argo, to jest nowoczesność w domu i zagrodzie z CN/CF’u.

Łukasz Kałużny: I na poważnie na koniec testy i dlatego mówię nie całe testy akceptacyjne i inne bo to są… włóżmy to sobie to między bajki. Mało który projekt ma na to budżet i utrzymuje to w dobrym stanie. Ale smoke test - wywołaj 10, 15 restów, sprawdź status aplikacji, endpointów, czy ona w ogóle przeżyła to, co zrobiłeś.

Szymon Warda: I ja to rozszerzę de facto. Jak już mówimy o aplikacji, bo smoke testy są po. A jeżeli jeszcze mamy migrację baz danych, które są przed deploymentem najczęściej i to jest kolejny kawałek, który też powinien być i który też jest fazą de facto przygotowawczą w tym wszystkim. I to też musi być, żeby nie było tej opcji generalnie, że wszystko wdrażamy, ale na przykład jak widać, że jak mamy bazę danych, robimy jakoś semi ręcznie albo wgrywamy boczkiem… To też jest element naszego schematu i też ten element musi być zdeployowany. Tak, tylko upewniając się.

Łukasz Kałużny: Dobra, przejdźmy sobie do CNCF’owej części świata, czyli Argo i flux. Wprowadzenie: Te dwa projekty w zeszłym roku zostały… Są w statusie już graduate, czyli uznane są za stabilne, dowiezione; oba jednocześnie. W ramach tego, więc są gotowe do pracy. Jak to można powiedzieć, dużo elementów rynkowych z nich korzysta. Gdzieś pod spodem Argo CD znajdziemy na przykład w CubeML’u, flux znajdziemy w komercyjnych produktach, biorąc z naszej działki cloudowo-azure’owej. Leży on sobie w Azure Arcu i w Azure AKS’ie, żeby syncować stan, jeżeli gdzieś tam dogrywamy. Więc takie rzeczy są szeroko używane. O tak powiem.

Szymon Warda: Więc z czego korzystasz?

Łukasz Kałużny: Z mojej praktyki, bo tak jak powiedzieliśmy, flux syncuje sobie stan do klastra jak idiota, to tak nazwijmy w sposób mniej lub bardziej…

Szymon Warda: To jest aplikacyjka, dokładnie.

Łukasz Kałużny: Tak. A Argo CD syncuje sobie stan i go wpycha. Tak stara się go wepchnąć, ma UI’a. Wiesz co, tak od siebie: Argo… Nie wiem, nie mogę się z nim pokochać i staram się unikać jak ognia. To jest moja osobista preferencja. Przy czym nie podoba mi się poziom skomplikowania logiki, który tam występuje. Zrobiło się za dużo warstw abstrakcji. Moim zdaniem duży plus, który tam jest pod spodem to jest ten UI, który jest wbrew pozorom bardzo przyjemny. UI w Argo jest jedyną rzeczą, która mnie zachęca do tego, żeby go nie odrzucać tak naprawdę.

Szymon Warda: To ja bym wtrącił się na UI’u. Nie jest przyjemny - jest konieczny de facto. I to jest spory ból np. fluxa, że tego UI’a nie ma. Finalnie jak nawet tworzymy platformę, bo to z reguły są narzędzia, które są platformowe, przyjdzie jakiś developer i chce wiedzieć, co jest na klastrze - we fluxie będzie mu ciężko to sprawdzić.

Łukasz Kałużny: I teraz co do fluxa: tak, kocham. I teraz jest jedna ważna uwaga, poza małymi projektami na zasadzie jakaś popierdółka, aplikacja czy coś, nie wykorzystuję go do aplikacji, czyli ja fluxa np. ze względu na jego sposób działania… Odrzucam go de facto dla większych aplikacji. Jeżeli mam 10, 15 modułów, to nie będę się kochał z fluxem i go nie używam w tym miejscu; wolę klasyczne podejście. To gdzie flux moim zdaniem bije na głowę wszystko… To jest ta część infrastrukturalna, w szczególności kiedy zrobimy z Kubernetesa usługę i zespół właśnie taki platformowy, administratorski, może szeroko wpychać tak naprawdę różne definicje, czyli przykładowo np. syncować do Kubernetesa jakieś polityki automatycznie ze wspólnego repo. I takie rzeczy można sobie pięknie wykorzystywać w chmurze. Czy dość fajnie mówi o tym Mariusz z mBanku na sesji, którą Wam podlinkuję, gdzie zrobiliśmy tak, że każdy klaster, który jest… i mają 150 klastrów… I każdy z klastrów zaciąga sobie dedykowaną konfigurację, którą oni zarządzają, żeby wymusić zgodność i jednorodność.

Szymon Warda: Użyłeś magicznego określenia, że nie do aplikacji. I jeżeli do samej infrastruktury: pytanie jest teraz takie: Kto w tej konfiguracji kontrybuuje tę infrastrukturę? Czy zespoły deweloperskie kontrybuują?

Łukasz Kałużny: Mogą kontrybuować, o - zróbmy sobie to w gwiazdkę. Mogą zrobić pull request.

Szymon Warda: OK. A kto merguje?

Łukasz Kałużny: Zespół platformowy.

Szymon Warda: To w tej wersji bym się jeszcze może zgodził. Dla mnie to nie jest kwestia, czy to jest aplikacja, czy zespół platformowy. Ale generalnie: czy osoba, która robiła pull requesta, czy ona go merguje? Bo jeżeli osoba, która robiła pull requesta, i ona go merguje i umie sprawdzić czy deployment poszedł, poprawnie, to flux się jeszcze nada. Może, ale musimy mieć cały flow i cały dashboard, który będzie mówił, co się właściwie tam dzieje. Bo magiczność fluxa i to, że np. czasami może wejść jakiś release, który się wywali albo będzie jakiś lock, albo będziecie cokolwiek się działo. Problemów tu jest de facto od groma, albo będziemy korzystali z jakiegoś customize’a, który coś nie zaaplikuje, albo będzie gdziekolwiek błąd. Trochę listuję tych problemów, bo ich dość dużo napotkaliśmy już. Sorry, to w tym momencie staje się to obce, że wszyscy muszą mieć dostęp de facto do KubeCTL’a i muszą umieć debugować, i pamiętać, jak debugować. I tutaj flux pada totalnie na twarz. I dlatego o ile z fluxa dość dużo korzystam. Ja bym się skłaniał zdecydowanie w ogóle do tego standardowego procesu. Jak nazwać klasycznym? Jest dużo bardziej przejrzysty, ma inny problem. Że GitOps spotyka takiego GitOpsa w formie fluxa albo Argo - jest taka, że łatwiej jest ludziom zrobić commita na repo.

Szymon Warda: Mniej się tego boją. Robić commita na repo i robić merga danego pull requesta i to się automatycznie zdeployuje, ale już zrobienie tego samego de facto, czyli kliknięcia. Albo generalnie w jakimś narzędziu do CD deploymentu to już jest dużo większa obawa, że o Jezu, Jezu, coś się stanie, bo mogę coś wywalić. Jeżeli zaczniemy tą automatyzację. Poprawną, że pipeline się odpala sam i po prostu śmiga. Nie widzę wartości czy widzę małą bardzo wartość. Nawet na infrastrukturze. Usuwamy magię, ale wiemy co się w jakiej kolejności dzieje.

Łukasz Kałużny: Wiesz, to zależy od skali. To ja np. fluxa w takiej dużej skali platformowej… Dla mnie jest ok, jeżeli dostarczysz platformę gdzie masz dużo różnych komponentów. To jest tak naprawdę jedyna możliwość autoscale deployowania tego i patrzenia w stan dogrywania komponentów, zmiany konfiguracji szeroko. Biorąc na przykład prostą rzecz jaką są rego policy, które mówią Ci jakie rzeczy możesz na klastrze deployować i karmienie tymi definicjami gatekeepera np.

Szymon Warda: Tu problem mają taki de facto. Żeby dowiedzieć się - bo w teorii: tak, jak najbardziej. To w ogóle pomysł brzmi idealnie. Problem jest taki jak się na fluxie zaczną jakieś problemy, albo - w sensie na deploymencie fluxa - jak się zaczną problemy to potem zakładamy, że na danym klastrze jest ta polityka, ona się już zadziała generalnie, jest skonfigurowana. Okazuje się, że się coś wywaliła przy deploymencie i nagle wchodzi, że ona na klastrze jednak nie zadziałała, a nie wiemy tego do końca.

Łukasz Kałużny: Od tego są stagingi, wchodzenie po kolei na środowiska i inne rzeczy. To nie jest tak, że commit do repo na twarz i lecimy na całą infrę. Więc trzeba pamiętać, że reszta praktyk nadal obowiązuje.

Szymon Warda: Zgadzam się, ale mieliśmy sytuację, np. że kubernetes się blokował na jakimś zasobie, nie mogą usunąć i przez to nagle cały helm release stawał i tak dalej. Takie małe problemy gdzie nie oszukujmy się, te klastry często już mają tyle zależności i tyle konfiguracji, tyle zasobów, że tego po prostu jest dużo. I tak, jeżeli chodzi o jakość tego kodu, jeżeli chodzi o to, żeby stagingować same zmiany, czy błąd wynika z samego naszego kodu. Zgodzę się jak najbardziej, można zmniejszyć skalę. I słuszna uwaga, staging obowiązuje. Problem jest taki na tych zasobach.

Łukasz Kałużny: Druga rzecz, którą powiedziałeś, tutaj się z Tobą mocno nie zgodzę. Jeżeli robisz platformę to te zależności - np. z takim fluxem - to wpychasz tak naprawdę cały config infrastrukturalny to jest jedna część. Druga rzecz lecisz z szablonu. Tak naprawdę kod infrastrukturalny nie powinien się spotykać w mojej opinii z tą częścią, która jest aplikacyjna. Czyli one powinny być od siebie na zasadzie część aplikacyjna nie może trafić do namespace’ów, gdzie są rzeczy systemowe. Jeżeli coś Ci się rozjedzie w takim codebasie, to zazwyczaj dałeś dupy na wcześniejszych środowiskach.

Szymon Warda: Tu się zgodzę. Nawet na samym kodzie platformowym dużo rzadziej to jest bez dwóch zdań; zdarzają się jakieś rozjazdy, zdarzają się… Na przykład mieliśmy swego czasu case, że z jakiegoś powodu robiliśmy rename namespace’ów nie przenoszenie między namespace’ami, mały refaktoring - z jakiegoś powodu zablokował się, że tego namespace’a nie może usunąć i on sobie wisiał 3 dni. Generalnie powiedział, że już go za 3 dni usunie. No i flux deployment się udał. Wszystko szło ładnie, kolorowo, dopiero stan udało się odpalić na samym klastrze, gdzie to, że nie masz tej pętli zwrotnej, że potwierdzenia. Tak, udał się - to sobie sprawdź. No nie, ok. Tylko, że de facto flux jako taki nie daje tego narzędzia de facto. On zaciąga konfigurację - ciężko jest zrobić coś, o czym powiedziałeś, te smoke testy na koniec; że nie wiemy kiedy flux skończył to deployować, kiedy to się udało, że możemy odpalić jakieś smoke testy. Obejścia jakie wokół tego są to jest deployment jakiegoś poda, który zacznie to wykonywać de facto i on nam wróci. Ale de facto w tym momencie zaczynamy budować własnego UI’a.

Szymon Warda: To ogarnia strukturę tego klastra. Tu nie widzę zwrotu z tej inwestycji po prostu.

Łukasz Kałużny: Ewentualnie drugą rzeczą jest wysyłanie sobie - tylko to jest już kombinacja - wysyłanie wiebhooków i cała ich obsługa. I widzę Twoją… Żałujcie, że nie możecie zobaczyć miny Szymona. Mówi ona, że próbował i się nie zabił.

Szymon Warda: Można robić. Tylko ja się zapytam po co, skoro de facto to samo uzyskamy pipeline’ym, zwykłym githubowym, devOpsowym itd. Będziemy mieli dokładnie ten sam flow. Czyli mając fajne narzędzie pod tytułem flux - właśnie na fluxa wylewam czarę goryczy, bo on jest najbardziej taki skrajny pod tym względem. Redeployujemy i reodtwarzamy normalnego pipeline’a w CD tylko po to, żeby móc powiedzieć, że używamy fluxa. Nie ma to większego sensu, a co więcej będziemy też mieli takie sytuacje, że nagle… Ponieważ mamy fluxa, to nagle musimy cały software maturity lifecycle, czyli ten cykl dojrzałości o której powiedziałeś, że powinna być, bo powinna jak najbardziej być. Odtworzyć jak najbardziej na repo bitowym, zamiast odtworzyć na pipeline’ach, że jeden się odpala, akceptacja; potem możesz odpalić kolejny i kolejny, kolejny. I nagle w Gicie jak ktoś, kto się decyduje na trunk based development. Musimy kombinować jak mieć… Odzwierciedlenie nie tylko środowisk, ale też dojrzałości tego środowiska. Jak je zrobić? I tu mamy taki… tworzy nam się macierz katalogów, branży, tagów i kombinujemy jak to w ogóle zaimplementować.

Szymon Warda: I nam śmieci to strasznie w gicie. Nie ma tu wartości dla mnie, po prostu, używamy narzędzia, żeby tylko go używać, bo jest fajne i błyszczy.

Łukasz Kałużny: Dobra, to przejdźmy sobie do zrobienia, właśnie czy hit czy kit, bo częściowo to wydałeś. Dobra, ja pójdę taki klasyczny gitops w rozumieniu pipeline’ów. W rozumieniu mamy: repo, mamy CI/CD. Korzystamy z IaaS’a czy innych tool’i. Super sprawa raczej czy hit - nie, to powinna być normalność.

Szymon Warda: To też chciałem powiedzieć. Generalnie to jest standard, bez tego się nie da funkcjonować.

Łukasz Kałużny: Dobra co do rzeczywistości by CNCF. Ogólnie moje pierwsze wrażenie jest jak jest z service meshami, czyli to jest kit. To jest tak, czyli na papierze wszystko fajnie. Przechodząc do praktyki, być może tego nie potrzebujesz i podejście takie, jeżeli z mojej perspektywy: jeżeli ktoś Ci tego Argo utrzymuje na zasadzie daję Ci z setupem, że musisz tylko setup do niego wepchnąć, nie musisz go utrzymywać. Jest nawet spoko.

Szymon Warda: Czyli jeżeli nie jesteś tym zespołem, który to utrzymuje, z Łukaszowego na ludzkie.

Łukasz Kałużny: Dokładnie tak, popatrzmy, bo może ktoś już Ci da z dobrodziejstwem inwentarza gotowe Argo. Tak jak chociażby w CubeML’u. Że już przychodzi zsetupowane, upgrade’uje się się w ramach upgrade’ów i innych zabawek. Jeżeli chodzi o fluxa. Jeżeli masz popierdółkę. To nie jest to złe, jeżeli masz popierdółkę.

Szymon Warda: Ale to w tym momencie powiedziałeś, że jeżeli masz mały system to użyj fajnego narzędzia, które Ci to skomplikuje. Powiedziałeś, że masz popierdółkę… Jaki będzie czas teraz czas do skonfigurowania pipeline’a, który będzie to robił? VS skonfigurowanie fluxa, który będzie to robił. Pipeline będzie szybszy po prostu.

Łukasz Kałużny: Wiesz co… inaczej. Jeżeli umiesz, to czy to, to jest czas taki sam.

Szymon Warda: Będziesz miał trochę zabawy z konfiguracją flux’a.

Łukasz Kałużny: Dobra jest jedna rzecz… Słuchajcie, to w ogóle na oddzielny odcinek - o której zapomnieliśmy - I to jest kit akurat GitOpsa, obydwu podejść, co z secretami. Dlatego ja świadomie nie wyciągałem tego, bo jest trochę w tym wszystkim zabawy. Luk security, które są i czy klasyczne podejście, o którym mówiliśmy na początku, czy te CNCF’owe, Kubernetesowe. Każde ma ciekawe dziury po drodze. Jeżeli chodzi o poświadczenia.

Szymon Warda: Tu się nie zgodzimy może nawet. Chodzi Ci o to, że trzymanie sekretów w repo jest problematyczne.

Łukasz Kałużny: Inaczej, sposób w jaki je dostarczamy, gdzie je trzymamy, jak je potem przekazujemy.

Szymon Warda: To o ile… już chyba nawet nad tym wylewaliśmy czarę goryczy swego czasu… secrety, absolutnie nigdy w życiu z tego nigdy nie korzystać. To jest jedna wielka porażka. To mogę powiedzieć, że po ponad roku z życia z Mozilla SOPS’em. Nie zauważam ich praktycznie w ogóle. Naprawdę. W tej wersji możemy to otrzymać i to jest w porządku. Problem zaczyna się generalnie, gdybyśmy musieli te secrety trzymać całkowicie w jakimś Key Vaulcie, wtedy synchronizacja tych deploymentów robi się upierdliwa. Dalej… Daję radę z tym żyć jak najbardziej.

Łukasz Kałużny: Dobra, to zrobimy sobie oddzielny odcinek. Jak zarządzać secretami? Czyli tak. Czyli podsumowując - klasyczny GitOps. OK, stosujcie. A do fluxa i ArgoCD podejdźcie na początek jak do kitu, mając świadomość.

Szymon Warda: Jedna bardzo ważna uwaga żebyśmy dorzucili, bo my cały czas mówiliśmy o części platformowej, a w podsumowaniu tego nie mówimy, to jest w platformowej. Natomiast w części aplikacyjnej absolutnie zwykły Pipeline, nic więcej tam musi być… Czemu? Bo mamy migrację baz danych, mamy healthchecki, mamy interesy testów i mamy masę rzeczy, które się dzieje po. Mamy np. Wybór baz danych, jak to wygląda przed, które będą deployowane itd. Z czego będziemy odtwarzali. Więc w tym flow aplikacyjnym? Nie. Żaden flux, żadne Argo, sorry Gregory, to po prostu się nie sprawdza. U Ciebie, jakie zdanie?

Łukasz Kałużny: Klasyczne. Tutaj tak: wolę zrobić klasycznego. Z fluxem można rzeźbić, ale robisz… Czy ArgoCD, nagle robisz logikę np. w helmie, gdzie ja nienawidzę robić tak naprawdę czegokolwiek pod tym względem i używać helma do rzeczy in-house jeżeli nie są produktem i naprawdę powtarzalne.

Szymon Warda: To jednak mimo wszystko zgoda na sam koniec. Dobrze.

Łukasz Kałużny: To trzymajcie się!

Szymon Warda: Na razie, Hej.

Łukasz Kałużny: Hej!