Co to jest Helm?
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: Helm to menedżer pakietów dla Kubernetes, czyli narzędzie ułatwiające instalowanie, konfigurowanie i aktualizowanie aplikacji w klastrze. Zamiast zarządzać osobno wieloma plikami opisującymi aplikację, używasz pakietu nazywanego chartem i przekazujesz mu własne ustawienia. Helm pomaga również śledzić kolejne wdrożenia, ale nie zastępuje Kubernetes ani nie gwarantuje, że aktualizacja będzie bezpieczna.
Jaki problem rozwiązuje Helm?
Kubernetes to system uruchamiający i zarządzający aplikacjami w kontenerach. Klaster, czyli środowisko złożone z maszyn obsługiwanych przez Kubernetes, potrzebuje opisu tego, co ma uruchomić. Taki opis zapisuje się najczęściej w manifestach — plikach YAML definiujących zasoby, na przykład Deployment zarządzający instancjami aplikacji czy Service udostępniający do nich połączenie.
Jedna aplikacja może wymagać kilku lub kilkunastu takich zasobów. Jeśli uruchamiasz ją osobno w środowisku testowym i produkcyjnym, część ustawień będzie wspólna, a część inna: liczba instancji, adres domeny, wersja obrazu kontenera czy limity pamięci. Ręczne kopiowanie manifestów utrudnia utrzymanie spójności.
Helm pozwala połączyć szablony tych zasobów w jeden pakiet. Na podstawie szablonów i konfiguracji generuje manifesty, a następnie przekazuje je do Kubernetes. To podobna idea do menedżera pakietów w systemie operacyjnym, choć Helm zarządza zasobami klastra, a nie programami instalowanymi na laptopie.
Chart, release i values — trzy podstawowe pojęcia
Chart to pakiet Helma zawierający szablony zasobów Kubernetes, domyślne ustawienia i informacje o pakiecie. Może opisywać pojedynczą aplikację lub zestaw powiązanych komponentów. Chart może też mieć zależności, czyli korzystać z innych chartów.
Release to konkretna instalacja chartu w klastrze, mająca własną nazwę. Ten sam chart możesz zainstalować wielokrotnie: na przykład jako sklep-test i sklep-prod, z różnymi ustawieniami. Release nie oznacza więc wyłącznie wersji aplikacji — identyfikuje wdrożenie zarządzane przez Helm.
Values to wartości konfiguracyjne podstawiane do szablonów. Chart zwykle zawiera domyślny plik values.yaml, a użytkownik może przekazać dodatkowy plik z własnymi ustawieniami. Nazwy dostępnych parametrów zależą od konkretnego chartu; Helm nie narzuca uniwersalnego pola do konfiguracji każdej aplikacji.
Przykładowa struktura prostego chartu wygląda tak:
moja-aplikacja/
├── Chart.yaml
├── values.yaml
└── templates/
├── deployment.yaml
└── service.yaml
Plik Chart.yaml opisuje pakiet, values.yaml zawiera konfigurację domyślną, a katalog templates przechowuje szablony. Wersja chartu i wersja aplikacji to różne rzeczy: zmiana sposobu wdrażania nie musi oznaczać zmiany samego programu.
Jak wygląda wdrożenie z Helmem?
Załóżmy, że zespół utrzymuje aplikację sklepu. W środowisku testowym potrzebuje jednej instancji, a w produkcyjnym trzech. Może wykorzystać jeden chart i dwa pliki konfiguracji, zamiast tworzyć dwie niezależne kopie manifestów.
Jeśli chart udostępnia parametr replicaCount, plik values-test.yaml może zawierać:
replicaCount: 1
Poniższy przykład zakłada, że masz zainstalowany Helm, dostęp do klastra oraz lokalny chart w katalogu moja-aplikacja. Najpierw możesz wygenerować manifesty bez instalowania aplikacji:
helm template sklep-test ./moja-aplikacja -f values-test.yaml
To pozwala sprawdzić wynik działania szablonów, ale nie potwierdza jeszcze, że klaster zaakceptuje wszystkie zasoby ani że aplikacja będzie działać. Instalację lub aktualizację release wykonasz poleceniem:
helm upgrade --install sklep-test ./moja-aplikacja \
-f values-test.yaml --namespace test --create-namespace
Namespace to logicznie wydzielona przestrzeń na zasoby w klastrze. Opcja --install umożliwia instalację, jeśli release jeszcze nie istnieje; w przeciwnym razie polecenie go aktualizuje. Przed uruchomieniem sprawdź bieżący kontekst Kubernetes, aby nie wdrożyć aplikacji przypadkowo do produkcji.
Aktualizacje i ograniczenia cofania zmian
Helm zapisuje historię kolejnych rewizji release, czyli zmian jego wdrożenia. Polecenie helm history sklep-test -n test pokazuje tę historię, a helm rollback umożliwia powrót do wcześniejszej rewizji.
Rollback nie jest kopią zapasową aplikacji ani jej danych. Cofnięcie konfiguracji zasobów nie odwróci automatycznie migracji bazy danych, zmian wykonanych w zewnętrznej usłudze czy skutków działania programu. Aktualizacje aplikacji przechowujących dane wymagają osobnego planu kopii zapasowych i zgodności wersji.
Helm nie usuwa też potrzeby rozumienia Kubernetes. Błędne limity zasobów, brak wymaganych uprawnień lub niepoprawny obraz kontenera mogą uniemożliwić uruchomienie aplikacji niezależnie od tego, czy manifesty powstały ręcznie, czy z chartu.
Kiedy wybrać Helm i jak ocenić gotowy chart?
Helm jest użyteczny, gdy powtarzasz wdrożenia, utrzymujesz kilka środowisk lub instalujesz aplikację składającą się z wielu zasobów. Przy kilku prostych, rzadko zmienianych manifestach może wprowadzać zbędną warstwę szablonów. Alternatywą bywa Kustomize, które dostosowuje istniejące manifesty zamiast korzystać z szablonów Helma.
Przed użyciem gotowego chartu sprawdź jego pochodzenie, dokumentację, wymagane wersje Kubernetes, uprawnienia oraz sposób obsługi danych trwałych. Przejrzyj wygenerowane manifesty, szczególnie zasoby nadające uprawnienia i usługi udostępniające aplikację poza klastrem. Hasła wpisane do pliku values nie stają się bezpieczne tylko dlatego, że używasz Helma — nie zapisuj ich w zwykłym repozytorium kodu.
Na początek wybierz środowisko testowe i jeden chart. W dokumentacji jego konkretnej wersji potwierdź dostępne parametry, a następnie sprawdź instalację, aktualizację i zachowanie danych podczas cofania zmian.
Zobacz też: Co to jest Brave?
Przeczytaj także
