Mentionsy

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.

I jeżeli w deployu na przykład odwołujecie się do config mapy, weźmy tam

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

redeployował w tym wypadku, jeżeli zmienisz samą config mapę, a tutaj fajnie wywoła cały rolling update, inne takie elementy i też widzimy, co się zmienia, jak wygląda.

Zgodzę się, że generatory są fajne.

Tutaj nie ma większej dyskusji, chociaż też jak mówisz, że generatory dotyczą się sekretów, to Łukasz, nie trzymasz swojej sekretówki, wolcie?

Słuchaj, na zawsze to mieliśmy sugerował odcinek właśnie o tym, jak ja bardzo nienawidzę secretów.

Dobra, to jest to dla mnie, okej, zgodzę się, generatory są super fajne.

robisz produkt, tam niestety będzie logika warunkowa, weźmy na przykład czy zainstalować Reddisa, czy użyjesz zewnętrznego i podasz connection stringa, czy zainstalować na przykład Postgresa z operatorem, to co mamy u jednego klienta w pewnym produkcie, którego przychodzi z rynku, to tam na przykład to jest software, którego używają setki klientów, więc on musi mieć IFA, zainstaluj mi Postgresa, podaj Postgresa, connection string do Postgresa na przykład, czy secret, w którym będzie connection string