Helm vs Kustomize

dawanie tego ludziom to jak dawanie dziecku brzytwy, żeby popiegało sobie po placu zabaw. Tylko to jest takie podejście na zasadzie, że a, jak damy, to ktoś popsuje. Oczywiście, że popsuje. Widzieliśmy przykład customiza, z którym ja walczyłem i zgodzisz się, że tam też było na dzierganę, jak tylko można było. Jeszcze dodam jedną straszną rzecz, którą kurde ileś razy widziałem i zawsze widzę ją z problemami, to jeżeli ktoś próbuje zrobić master helma... który zainstaluje całe środowisko z logiką warunkową. I potem prowadzi do tego, że całą logikę aktywna serwis mamy gdzie? Mamy tam nadpisywaną, potem w sumie nikomu nie zależy na tym, żeby to przemigrować do głównego, bo rozwali wszystkim innym.

Szczegóły możecie znaleźć sobie na stronie. Dobra, jak jesteśmy przy Hardwayu, to dzisiaj rzecz, po której ja się z Tobą totalnie nie zgadzam. bo dawanie tego ludziom to jak dawanie dziecku brzytwy, żeby popiegało sobie po placu zabaw, czyli helm versus customize, czyli odwieczny problem, czego powinniśmy użyć do templatingu, przygotowania deploymentów na Kubernetesa. bo tak to można określić. Dobrze, to może małe wprowadzenie, co jest czym. Customize umożliwia nam zmiany jamla, mówiąc bardzo prosto, i modyfikację przez tam wiele poziomów. Mamy bazowy obraz i go tam modyfikujemy różnymi overlayami. Inaczej trzeba powiedzieć po prostu robimy, inaczej, robimy patche...

Tak. I to jest jedna rzecz, a Customize powstał po to, żeby de facto bez narzędzi, bo jest wbudowany w Cube CTL-a już w tym momencie w pełnej kompatybilnej wersji, więc musisz odświeżyć wiedzę o ostatnich update'ach, jak to wygląda. Ale ja tutaj nie stwierdziłem nic innego. to pozwala wam w prosty sposób po prostu zmienić manifest w jakiś sposób. Albo dodać do niego element, podmienić po prostu pisząc kawałek Jamla, bądź wpisując komendę JSON patcha, którego Szymon nienawidzi. Dobra. I to są takie elementy, które posiadamy. Jak popatrzymy ze strony wsparcia narzędziowego, czy od strony tego, jak to robimy z pipeline'ów, czy jak to robimy z GitOps'a typu Argo,

Czyli tam zaczynają tworzyć własne, reużywalne funkcje i inne rzeczy, wyrzucać je, współdzielić i zaczyna tworzyć się małe piekło, które nie wiemy, dlaczego tak się dzieje. Dobrze. I Szymon, pewnie spotkałeś się z tym, że deweloper zaczyna wymyślać, jak się pokaleczyć, bo na tym środowisku powinna być jakaś specyficzna rzecz, która nie jest jawnie deklarowana. Zgodzę się. Tylko to jest takie podejście na zasadzie, że a, jak damy, to ktoś popsuje. Oczywiście, że popsuje. Widzieliśmy przykład Customizer, z którym ja walczyłem i zgodzisz się, że tam też było na dzierganę, jak tylko można było. Ale odpowiadając, czy ifologia tam może być? Tak, ifologia może być. Drugim podejściem, które jest dużo lepsze w tej sytuacji, to jest po prostu jawne dawanie obszarów, które można rozszerzać.

Bym się z tym zgodził. Dla mnie kolejna siła, to ja może dam mój główny argument, czemu ja jestem znowu wywolnikiem Helma. Customize powoduje to, że jak mamy, bo to jest taki koronny argument, jak mamy mikroserwisy, to używamy customiza. Ja powiem właśnie nie, bo w tym momencie mówimy, że każdy ten mikroserwis jest do siebie w miarę podobny i tylko będziemy to modyfikować. A przy Helmie mówimy na opcję. Drogi zespole, twoją odpowiedzialnością jest dostarczenie pakietu, dostarczenie sposobu instalacji i mnie w sumie nie interesuje. Jak chcę inny zespół użyć, to też po prostu dostaję plik values i ma go użyć. Więc to jest jawne budowanie pewnego zbioru abstrakcji. Tu się zgodzisz, że Helm fajnie buduje abstrakcje. Buduje proste wersjonowanie i mówi, to jest twoja bajka, masz się tym zająć i to ma działać dobrze.

Zupełnie wypychasz to od siebie. Jeżeli coś pakujesz i ktoś ma fetyszek produktowy na to patrzeć, to się zgadzamy. Helm jest jak najbardziej świetny. Tak. I teraz wlatujemy w rzecz, w której ja preferuję, czyli nasze wewnętrzne aplikacje, które zespół ownuje jakoś, dostarcza w zależności jak patrzymy wewnątrz firmy, czyli gdzieś, gdzie mamy na to w teorii wpływ. Słowo w teorii jest tutaj kluczowe. Dlaczego preferuję tutaj w tym miejscu, dlaczego w tym miejscu preferuję... Customizer. Customizer. Ponieważ w większości przypadków tam samo to, w jaki sposób aktualnie działa Customize i co tutaj mam na myśli, to w jaki sposób podchodzi do wrzucania i robienia sobie nakładek na przykład preśrodowiska oddefiniowania tego.

I dla mnie, Szymon, na przykład bardzo ważną zaletą Customize'a są dwie pierdoły, które działają bardzo dobrze. w postaci generatorów. Mamy config map generator i secret map generator, które w locie generują ci, czy z sopsów innych rzeczy, generują ci config mapy i secrety. I teraz ważna funkcjonalność, która się w środku znajduje, to dla Was, jeżeli to będziecie robić, to Secret Map Generator i Config Map Generator potrafi wziąć te pliki, dotenwy, inne takie, czy jasony, whatever, w czym trzymacie te konfigi, wylicza sobie z zawartości hasza i generuje z tego, teraz to jest istotne, wylicza sobie hash i dokleja go do nazwy obiektu.

Problem, jaki ja mam z customizem największym, to jest fakt, że niestety to prowadzi do overarchitektury na poziomie overlay. Mamy overlay, który jest overlayem, który ma overlay i overlay, czekaj, i potem prowadzi do tego, że całą logikę, jak wygląda serwis, mamy gdzie? mamy tam nadpisywaną, potem w sumie nikomu nie zależy nad tym, żeby to przemigrować do głównego, bo rozwali wszystkim innym. Znaczy wiesz co, dlatego ja podchodzę, że jeżeli chodzi o nakładki, może być tylko base, który zawiera w całą rzecz podstawową, tylko base i jedna nakładka per środowisko i to będzie inaczej. Czy można w customizie się skrzywdzić? O Boże, jak... Inaczej, jak zaczynamy hakowanie, jak zaczynamy hakowanie... Nie hakowanie, to jest po prostu nadużywanie overlayi, które jest bardzo łatwe do zrobienia.

Tak, dlatego ja podchodzę, Szymon, bardzo prosto. Deployujemy tylko jeden overlay nad środowisko i koniec, nie ma więcej, bo jeżeli zacznie powstawać overlay do overlaya, to się inaczej... Dobra, nazwijmy to prosto, już mamy tyle czasu, przepraszamy przedszkolaki, zajebiemy się. Tak samo jak z Helmem. Wracamy do naszego głównego tematu, czyli jeżeli w każdym z tych narzędzi możesz się pociąć. Ja bym tak, żeby to nie było na zasadzie, że zostaniemy przy swoich zdaniach. Ja bym to zrobił w ten sposób. Jeżeli podchodzimy do tego, że te nasze mikroserwisy, bo o tym głównie mówimy, no nie? Są takie same i my kontrolujemy, bo siła customiza. Łatwo jest zrobić konwencję.

Więc to są w tym. Ta ifologia się znajdzie przy produkcie. Tylko tam ona jest potrzebna. Ta cała zabawa z lojką będzie potrzebna. Tylko... Po Diablo... Po Diablo tam nie ma dużo, bo to jest albo mam dependencję podane, albo mam kodekszestringa po prostu, albo instaluję sam, albo śmigam. Tak, tylko że to jest, tylko zobacz, to jest właśnie prosta IFA, a widzieliśmy, jak ludzie próbują zbawić problemy, których nie będzie. Zgodzimy się z tym, jeżeli nagle widzimy, że ktoś ma cały zbiór funkcji w Go, które generują różne rzeczy, to zgodzimy się, że to już jest złe. To tak. Bardziej niż... Zaczyna się robić wesoło. I zgodzimy się z tym, że trzymanie jednego i drugiego systemu jest dobre, póki jest proste. Teraz zostaje pytanie trzecie tak naprawdę, bo to nie jest czy helm customize, tylko pytanie jest takie połączenie jednego i drugiego.

Czyli ta standardowa opcja, że mamy helma, który nam wszystko generuje, a potem jeszcze customizem zmieniamy pewne fragmenty. Nie, ja... Naprawdę to jest... widziałem jedną tylko polecajkę na takie, inaczej, spotkałem się tylko raz z taką jawnym wskazaniem tego i to było w tym, ponieważ Helm był do, kiedyś do konsula był bardzo mocno ograniczony od HashiCorpu. I rekomendowali, że jak chcesz sobie pozmieniać, to zrób builda i przeleć go dopiero customizem. I jeszcze ja ci powiem tak, dla mnie to jest już piek, to zaczyna robić, piecze. Dla mnie to jest tak samo, jak dostawanie się do prywatnych funkcji w kodzie przez refleksję i inne rzeczy, że polegamy na tym, że ten kawałek będzie wyglądał i prosimy się o to, żeby to się za chwilę rozwaliło.

Niezależność bym, czy Customize, ja jednak mimo wszystko nie zbyt się spożyłem na Customize. Także nie. No, tyle. Faktycznie i z tą uwagą, żeby plinowanie, żeby jasne ustalenie, kiedy jest wersja i jak to wygląda, kiedy wersjonujemy, żeby to było znajome wszystkim i wszędzie, zawsze. To jest ważna uwaga. I zwracanie też uwagi na to, co można rozszerzać i żeby te rozszerzenia były. Szymon, zażartuję, żeby nie wyglądało to jak pulumi. Żeby ten helm nie był ten, nie był pisany solidem, jak w C-Sharpie. Tak, dokładnie tak. Żeby nie było nawet potrzeby myślenia o solidzie i dry i tak dalej.

Nie jest dobry rozwój. Stary, po zgresę odpalisz z web assembly w ramach Helma. Ja się boję tych prezentacji. Przysięgam. Teraz widzicie Szminę Szymona już. Wiesz co, dlaczego... Jeszcze za rok się przeprosisz z customizem, jak ktoś cię skrzywdzi. Customize jedną overlayę może, ale dalej pisanie tych pafów nie. Okej. Raczej tam pafów. Mówisz Sonetowi, że ma ci dopisać w Compilocie i jest dobrze. Kończymy. To co? Kończymy. Trzymajcie się. Na razie.