Gdy czytam artykuły o Kubernetesie to czasem odnoszę wrażenie, że to narzędzie to niejako must-have przy pracy z Kubernetesem. Ja natomiast nie widzę żadnej realnej wartości jaką miałoby to narzędzie wnosić. Autorzy opisują Helma tak coś w rodzaju Docker Huba tylko zbudowanego w oparciu o konfiguracje Kubernetesa. Idee chyba łapię tylko o ile takie repozytorium Dockera jest niezbędne bo nie zbudujemy sobie kontenera w 10 minut tak Heml wydaje się być ogromnym narzędziem które rozwiązuje problem który nie istnieje. Dlaczego miałbym chcieć używać gotowych konfiguracji z Helma skoro sam napiszę taką w 5 minut?
@MDobak: Helm to taki manager pakietów. Od postaw mi WordPress z baza i stojące do postaw mi moja aplikacje składająca się z 50 mikroserwisow. Tego nie wyklepiesz w 5 minut. :) Przydaje się jak robisz sobie na przykład środowiska testowe ob demand pet build albo dla każdego deva.
@yggdrasil: Teraz mam trochę pliczków Yaml z konfiguracją kilkudziesięciu podów i kilka linijek w bashu które odpalają to u devów i stagingu. W jaki sposób Helm uprościłby mi tę konfigurację?
Obecnie flow wygląda tak, że mam inne configmapy na różnych środowiskach i w praktyce robie tylko kubectl apply -f . i mam postawione środowisko.
Tego nie wyklepiesz w 5 minut. :)
Trochę tego argumentu nie łapię. Przecież i tak musisz
@MDobak: Tylko, ze yamle masz statyczne. Helma możesz sobie sparametryzowac podczas deploymentu bez tworzenia ConfigMap. Zreszta przez configmap tez nie załatwisz wszystkiego, np. domeny w ingresie. Musisz zmodyfikować yaml i dopiero odpalasz. W helmie podajesz po prostu parametry. Potem jak po 15 minutach nie potrzebujesz to usuwasz to co stworzył, nie zostają ci żadne yamle.
Wtedy z kolei masz deployment, który nie ma yamla i musisz ręcznie usuwać. :)
@yggdrasil: Nie chciałbym aby to brzmiało tak jakbym się czepiał ale po prostu dalej nie łapie :P Przecież za pomocą envsubst mogę sobie wygenerować yaml'e i aktualizować je za pomocą kubectl apply --prune -f . co bez problemu usunie mi stare deploymenty. Mam cały czas trochę wrażenie, że heml to taki troszkę overkill do tak prostego
@MDobak: Ułatwia współpracę, kiedy wiele różnych osób pracuje nad wieloma pakietami helm równocześnie. Poza tym z tego co pamiętam jest dość przyjazny pracy w stylu CI/CD.
Halo @Moderacja kiedy weźmiecie się za użytkowników, którzy szerzą rosyjską propagandę? Tak chętnie banujecie polskich patriotów gardzących rossyjskimi terrorystami, a pozwalacie na miękką propagandę serwowaną dzień w dzień. Pomogę wam udostępniając nicki tych ancymonków: @Grooveer @
Gdy czytam artykuły o Kubernetesie to czasem odnoszę wrażenie, że to narzędzie to niejako must-have przy pracy z Kubernetesem. Ja natomiast nie widzę żadnej realnej wartości jaką miałoby to narzędzie wnosić. Autorzy opisują Helma tak coś w rodzaju Docker Huba tylko zbudowanego w oparciu o konfiguracje Kubernetesa. Idee chyba łapię tylko o ile takie repozytorium Dockera jest niezbędne bo nie zbudujemy sobie kontenera w 10 minut tak Heml wydaje się być ogromnym narzędziem które rozwiązuje problem który nie istnieje. Dlaczego miałbym chcieć używać gotowych konfiguracji z Helma skoro sam napiszę taką w 5 minut?
#docker #programowanie
Przydaje się jak robisz sobie na przykład środowiska testowe ob demand pet build albo dla każdego deva.
Obecnie flow wygląda tak, że mam inne
configmapyna różnych środowiskach i w praktyce robie tylkokubectl apply -f .i mam postawione środowisko.Trochę tego argumentu nie łapię. Przecież i tak musisz
envsubst.Komentarz usunięty przez autora
@yggdrasil: Nie chciałbym aby to brzmiało tak jakbym się czepiał ale po prostu dalej nie łapie :P Przecież za pomocą
envsubstmogę sobie wygenerować yaml'e i aktualizować je za pomocąkubectl apply --prune -f .co bez problemu usunie mi stare deploymenty. Mam cały czas trochę wrażenie, że heml to taki troszkę overkill do tak prostego