Do czego tak właściwie służy #helm w #kubernetes?
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
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
@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.
Przydaje się jak robisz sobie na przykład środowiska testowe ob demand pet build albo dla każdego deva.
@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.
docker run --rm -it -v $(pwd):/dupa -w /dupa builder makeMam wrażenie, że istnieje jakieś "the right way to do it".
#docker #programowanie
/app. Ale polecam używaniedocker-compose. W kontenerze zawsze uruchamiasz jeden proces, logiczne by trzymac to w/app.