Mentionsy

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...

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.

Dobrze, teraz Helm.

Helm natomiast jest takim engine'em template'owym do Jamla, czyli mamy Jamla, a tam elementalnie mamy jakieś while, ify i tak dalej, i tak dalej, i na koniec tego Jamla wygenerujemy i całość przedstawiamy jako paczkę i masz, instaluj sobie.

Bo ja helmem nie gardzę, gardzę sposobem użycia i to jest bardzo istotna różnica.

Dobra, i helm pierwotnie, to też jest bardzo ważne, jest package managerem i tego jego pierwsze takie przeznaczenie, takie bardzo szerokie, to jest packet manager i mamy coś, co nazywamy artifact hub.

Weźmy owianego słowom Prometeusza, jakieś operatory, third-party softy, teraz przychodzą enterprise'owe w postaci helma, więc jest to sposób dystrybucji manifestów do Kubernetesa, żeby zrobić produkt do instalacji.

Helm jest świetny do dystrybucji produktów.

Tak, i tu damy małą gwiazdkę, że mówimy oczywiście o Helm w wersji 3 i wyżej.

I teraz słuchajcie, jakie są problemy z Helmem, takie moje.

Całą tą opcję, żeby jednak mimo wszystko ten helm był rozszerzalny.

Dobra i teraz jeżeli popatrzymy o pisaniu dobrego helma, jak mówimy, bo zobacz, że sytuacja, kiedy dostarczamy i kiedy dostarczamy coś już w ten sposób, jeżeli będziemy używać właśnie patrząc na te problemy, to pod tym względem

Helm, tak jak powiedziałeś, one powinny być jawnie deklarowane.

Dla mnie kolejna siła, to ja może dam mój główny argument, czemu ja jestem znowu wywolnikiem Helma.

A przy Helmie mówimy na opcję.

Tu się zgodzisz, że Helm fajnie buduje abstrakcje.

Mało kto poprawnie używa wersjonowania w Helmie.

Jeżeli zmieniamy coś w Helm'ie, powinniśmy podbijać chart version.

Przeglądając coraz więcej rep odnośnie właśnie instalacji helma, to już stało się standardem, że naprawdę dobre praktyki w helmie weszły i już zagościły i są.

To tak, z mojej perspektywy, czy będziemy używać helma z Kubernetesem?

Uważam, że to, co przychodzi z open source'u, weźmy te Argo, Prometeusze, jakieś ingresy, inne rzeczy, to wszystko powinno być instalowane helmem.

Jeżeli dostarczasz swój software jako produkt i ktoś będzie go instalował na klastrze i to jest zupełnie poza tobą, tutaj również jest to helm w stu procentach.

Helm jest jak najbardziej świetny.

config mojej aplikacji, to on w deployu podmieni tę nazwę tej config mapy, czyli to będzie config mojej aplikacji i numerki i hash i tak samo będzie się nazywała config mapa i przykładowo zrobi pierdołę, z którą jest, jak wiesz, zawsze problem, czyli jeżeli nie zmieniamy deploymentu, to helm go nie będzie w żaden sposób...

Tak samo jak z Helmem.

Choć to samo można by było zrobić też w Helmie, że po prostu podmieniamy tylko imię.

Natomiast jeżeli podchodzimy, że zespoły są niezależne i nie wnikamy w to, jak to wygląda, i od siebie mogą się różnić, i to mniej lub bardziej znacząco, to dla mnie wybór jest prosty Helm.

Ja 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ą.

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.

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.

Kiedyś te helmy były ograniczone, teraz mamy te wszystkie możliwości rozszerzenia i labeli, obrazów, podmiany, zmiany i tak dalej.

Jest jedna rzecz, która w Helmie potrafi być bardzo dobra i bardzo zła.

I żeby teraz tylko wprowadzić o co chodzi, helm ma raz, dwa, trzy, cztery, pięć, sześć, siedem, osiem, dziewięć huków.

Mamy akcje pre-post install, pre-post delete, pre-post upgrade i pre-rollback, post-rollback oraz taki ostatni, który też jest pod komendą helm test, czyli zrobienie testu.

kontrolę nad tym, co się dzieje na moim klasie produkcyjnym, mam ja, ten helm powinien mi tylko zainstalować soft i odczepić się ode mnie.

Tak jak powiedziałem, rzeczy, które instalujemy z zewnątrz, z open source'u, tutaj helm jest super i tu nie kombinujcie, o tak.

O tak, chyba, że zespół nie będzie latał z brzytwą, to i prosty helm też jest spoko w tym miejscu.

Dobrze, to ja odnośnie helma powiem tak, jak jest, powiedziano, a ja jestem zdaniem, że teamy są od siebie niezależne i tak mówię, ogarnijcie się.

To jednak jest helm prosty, bardzo prosty.

Żeby ten helm nie był ten, nie był pisany solidem, jak w C-Sharpie.

Wyszedł Helm 4.0.

Stary, po zgresę odpalisz z web assembly w ramach Helma.