Helm po raz drugi – czyli wersjonowanie i rollbacki dla Twojej aplikacji

Hej, dzisiaj jako Innokrea kontynuujemy temat menadżera pakietów dla Kubernetes, jakim jest Helm. Spróbujemy pokazać Wam jak zaktualizować konfigurację, wykonać rollback oraz jak nadpisać wartości na własne oraz zaprezentujemy czym są szablony. Jeśli nie czytaliście naszych poprzednich artykułów w temacie konteneryzacji lub DevOps to zapraszamy do lektury https://www.innokrea.pl/blog.

MongoDB kontra zarządzanie wersjami

Spróbujmy zacząć od skonstruowania przykładu w oparciu o MongoDB, czyli bardzo popularną bazę NoSQL. Zaczniemy od wyszukania dostępnych wersji charta z użyciem komendy helm repo search <nazwa>.

Rysunek 1 – Wersje chartów dostępne w ramach repozytorium Bitnami

Możemy zauważyć, że jeśli dodamy do naszej komendy flagę –versions, to zobaczymy wszystkie dostępne wersje chartów wraz z opisem jakiej wersji aplikacji dotyczą. Istnieją trzy rodzaje wersji w Helmie, które warto rozróżniać:

• Chart version – wersja paczki Helma przygotowana przez zespół odpowiedzialny po stronie danej aplikacji. Wersja podana jest w pliku Chart.yaml.
• App version – wersja aplikacja, której używa dana paczka. Sama aplikacja przygotowywana jest przez zespół deweloperski. Jest ona podana również w pliku Chart.yaml. Wersja Charta powinna pasować do wersji aplikacji.
• Revision version – wersja kolejnego wdrożenia (release) po stronie klienta używającego Helm Chart. Jest to sekwencyjnie powstający numer wskutek wykonywania takich komend jak upgrade, install, rollback i pozwala on identyfikować kolejne wersje wdrożeń i przełączać się między nimi jeśli nowe wdrożenie jest w jakimś stopniu wadliwe.

Zainstalujmy dwie wybrane wersje chartów MongoDB – jedną najnowszą tj. 16.4.0 z wersją aplikacji 8.0.4 oraz drugą nieco starszą 16.2.2 z wersją aplikacji 8.0.3. Musimy także pamiętać o nadaniu odpowiednich nazw do naszych releasów, w naszym przypadku będzie to my-mongo-<wersja>.

Rysunek 2 – instalacja dwóch różnych wersji MongoDB 16.4 oraz 16.2

Aktualizacja konfiguracji

Aby zaktualizować konfigurację dostarczoną w pliku YAML możemy wykorzystać dwie techniki. Pierwsza z nich polega na bezpośrednim nadpisywaniu wartości poprzez flagę –set np. –set auth.rootPassword = test. Druga natomiast na napisaniu wszystkich wartości, które chcemy nadpisać w pliku values. Wartości, które nie zostaną zdefiniowanie będą domyślne, takie jak zdefiniował je autor Charta. Ale skąd właściwie wiedzieć jakie wartości można nadpisać. Otóż należy spojrzeć do definicji pliku values.yaml publikowanej przez autorów różnych chartów w takich serwisach jak GitHub.

Rysunek 3 – Plik values.yaml zdefiniowany dla MongoDB przez autorów Charta

Spróbujmy więc nadpisać hasło poprzez definicje prostego pliku values.yaml i komendy upgrade.

Rysunek 4 – Plik values.yaml wykonany na podobieństwo tego z Rysunku 3

Rysunek 5 – Prezentacja zmiany hasła z użyciem komendy upgrade i pliku values.yaml

Zwróćmy także uwagę na Revision, które zmieniło numer na 2 wskutek wykonania komendy upgrade. Zmianę możemy podejrzeć z użyciem komend kubectl get secrets (gdzie zapisywane są metadane releasów) oraz Helm history. Spróbujmy wrócić do poprzedniej wersji z użyciem komendy helm rollback.

Rysunek 6 – Proces rollbacku do poprzedniej wersji

Zwróćmy uwagę na to, że przez to, że nie zastosowaliśmy flagi –version oraz wykonaliśmy upgrade z plikiem values, który nadpisywał jedynie hasło, to nasze domyślne wartości (values.yaml) zostały pobrane z najnowszej wersji charta. Oznacza to, że chcąc zmodyfikować jedynie hasło do konta administratora nadpisaliśmy wersję charta oraz tym samym wersję aplikacji do 8.0.4. Aby uniknąć tego typu nieprzewidzianych aktualizacji należałoby podać konkretną wersję charta z użyciem flagi –version w następujący sposób:

helm upgrade my-mongo-16-2 bitnami/mongodb –values values.yaml –version 16.2.2

Szablony Helm

Wiemy już, że używając pliku values możemy nadpisać wybrane wartości, ale jak to się właściwie dzieje? Jak sprawić, by tworzona przez nas aplikacja miała możliwości dynamicznego zastąpienia kluczowych wartości w zależności od pojedynczego pliku values? W tym celu stosuje się szablony, czyli pliki YAML dla Kubernetes wzbogacone o składnię szablonowania opartą na języku Go Templates. Aby zapoznać się z tym mechanizmem spróbujmy wejść w ostatni link z naszych źródeł, czyli szablon serviceaccount.yaml dla aplikacji mongoDB.

Rysunek 7 – Plik serviceaccount.yaml od mongoDB rozszerzony o składnie szablonowania

W pliku możemy zaobserwować miejscami użycie obiektu Values, czyli zdefiniowanego pliku Values.yaml, a także prostą logikę wykorzystującą instrukcje if, czy warunki logiczne. Często w projektach wykorzystuje się także plik _helpers.tpl, czyli plik pomocniczy używany do definiowania wielokrotnie wykorzystywanych fragmentów kodu. Jest to opcjonalny, ale bardzo przydatny element Helm chartów, który pozwala na tworzenie funkcji pomocniczych i unikanie duplikacji kodu w innych plikach szablonów w katalogu templates w dużych projektach.

Rysunek 8 – Plik helpers.tpl zawierający pomocniczą logikę oraz wartości

Podsumowanie

Mamy nadzieję, że udało Wam się dzisiaj poszerzyć wiedzę na temat Helma. Pokazaliśmy Wam jak łatwe w użyciu mogą być powroty do poprzednich wersji aplikacji poprzez rollbacki, ale też, że trzeba uważać jeśli chodzi o stosowanie odpowiednich wersji. Dodatkowo udało nam się pokazać jak wyglądają szablony oraz przykładowa logika wspomagająca generowanie konfiguracji dla MongoDB. Jeśli ten wpis Was zaciekawił zachęcamy do zapoznania się z podobnymi treściami dotyczącymi Dockera oraz Kubernetes.

Do usłyszenia w kolejnych tygodniach!

Źródła:

https://github.com/bitnami/charts/blob/main/bitnami/mongodb/values.yaml

https://github.com/bitnami/charts/blob/main/bitnami/mongodb/templates/serviceaccount.yaml