🥇Narzędzia dla programistów aplikacji działających w Kubernetes

Nowoczesne podejście do eksploatacji rozwiązuje wiele bieżących problemów biznesowych. Kontenery i orkiestratory umożliwiają łatwe skalowanie projektów o różnym stopniu skomplikowania, upraszczają wydania nowych wersji, czynią je bardziej niezawodnymi, ale jednocześnie stwarzają dodatkowe problemy dla programistów. Programistę przede wszystkim obchodzi jego kod: architektura, jakość, wydajność, elegancja — a nie to, jak będzie działać w Kubernetes i jak go testować oraz debugować po wprowadzeniu nawet minimalnych poprawek. Dlatego zrozumiałe jest, że aktywnie rozwijają się narzędzia do Kubernetes, które pomagają rozwiązywać problemy z nawet najbardziej „archaicznymi” programistami i pozwalają im skupić się na głównym.

W tej recenzji przedstawiamy krótkie informacje o niektórych narzędziach, które ułatwiają życie programiście, którego kod działa w podach klastra Kubernetes.

Proste pomocniki

Kubectl-debug

Istota: dodaj swoje kontener do pod’a i zobacz, co się w nim dzieje.
GitHub.
Krótka statystyka GH: 715 gwiazdek, 54 commity, 9 współtwórców.
Język: Go.
Licencja: Apache License 2.0.

Ten wtyczka dla kubectl pozwala stworzyć wewnątrz interesującego pod’a dodatkowy kontener, który będzie dzielił przestrzeń nazw procesów z innymi kontenerami. Można w nim debugować działanie pod’a: sprawdzić działanie sieci, nasłuchiwać ruch sieciowy, wykonać strace na interesującym procesie itp.

Można również przełączyć się do kontenera procesu, wykonując chroot /proc/PID/root — jest to bardzo przydatne, gdy trzeba uzyskać shell roota w kontenerze, dla którego w manifeście ustawiono securityContext.runAs.

Narzędzie jest proste i skuteczne, więc może się przydać każdemu programiście. Więcej o nim napiszemy w osobnym artykule.

Telepresence

Istota: przenieś aplikację na swój komputer. Projektuj i debuguj lokalnie.
Strona; GitHub.
Krótka statystyka GH: 2131 gwiazda, 2712 commitów, 33 współtwórców.
Język: Python.
Licencja: Apache License 2.0.

Pomysł tego narzędzia polega na uruchomieniu kontenera z aplikacją na lokalnym komputerze użytkownika i przekierowaniu całego ruchu z klastra do niego i z powrotem. Takie podejście pozwala na rozwijanie lokalnie, po prostu zmieniając pliki w ulubionym IDE: wyniki będą dostępne od razu.

Zalety lokalnego uruchamiania to wygoda edycji i natychmiastowy wynik, możliwość debugowania aplikacji w znany sposób. Wady to wymagania dotyczące szybkości połączenia, co jest szczególnie zauważalne przy pracy z aplikacjami o wysokim RPS i ruchu. Ponadto, Telepresence ma problemy z volume mounts w Windows, co może stać się decydującym ograniczeniem dla programistów przyzwyczajonych do tego systemu operacyjnego.

Już dzieliliśmy się naszym doświadczeniem z używaniem Telepresence tutaj.

Ksync

Istota: prawie natychmiastowa synchronizacja kodu z kontenerem w klastrze.
GitHub.
Krótka statystyka GH: 555 gwiazdek, 362 commitów, 11 współautorów.
Język: Go.
Licencja: Apache License 2.0.

Narzędzie umożliwia synchronizację zawartości lokalnego katalogu z katalogiem kontenera uruchomionego w klastrze. Tego rodzaju narzędzie idealnie nadaje się dla programistów pracujących w językach skryptowych, dla których głównym problemem jest dostarczenie kodu do działającego kontenera. Ksync ma na celu rozwiązanie tego problemu.

Przy jednokrotnej inicjalizacji poleceniem ksync init w klastrze tworzy się DaemonSet, który jest używany do monitorowania stanu systemu plików wybranego kontenera. Na swoim lokalnym komputerze programista uruchamia polecenie ksync watch, które monitoruje konfiguracje i uruchamia syncthing, które realizuje bezpośrednią synchronizację plików z klastrem.

Należy tylko poinstruować ksync, co i z czym synchronizować. Na przykład, takie polecenie:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

… stworzy watcher o nazwie myproject, który będzie szukał poda z etykieta app=backend i spróbuje synchronizować lokalny katalog /home/user/myproject/ z katalogiem /var/www/myproject/ w kontenerze nazwanym php.

Problemy i uwagi dotyczące ksync z naszego doświadczenia:

Na węzłach klastra Kubernetes należy używać overlay2 jako kierowcy pamięci dla Dockera. Żadne inne narzędzie nie będzie działać.
Przy użyciu Windows jako klienta mogą wystąpić problemy z poprawnym działaniem watchera systemu plików. Tego buga zauważono przy pracy z dużymi katalogami — z dużą ilością zagnieżdżonych plików i katalogów. Stworzyliśmy odpowiednie zgłoszenie w projekcie syncthing, ale od początku lipca nie ma postępu.
Użyj pliku .stignore Aby wskazać ścieżki lub wzory plików, które nie powinny być synchronizowane (na przykład katalogi app/cache i .git).
Domyślnie ksync będzie restartować kontener przy każdej zmianie plików. Dla Node.js jest to wygodne, a dla PHP zupełnie zbędne. Lepiej wyłączyć opcache i użyć flagi --reload=false.
Konfigurację można zawsze poprawić w $HOME/.ksync/ksync.yaml.

Squash

Istota: debuguj procesy bezpośrednio w klastrze.
GitHub.
Krótka statystyka GH: 1154 gwiazdki, 279 commitów, 23 współtwórców.
Język: Go.
Licencja: Apache License 2.0.

To narzędzie jest przeznaczone do debugowania procesów bezpośrednio w pod’ach. Użyteczność jest prosta i w trybie interaktywnym pozwala na wybranie odpowiedniego debuggera (patrz poniżej) i namespace + pod, w proces który należy ingerować. W tej chwili wspierane są:

delve — dla aplikacji w Go;
GDB — przez target remote + przekierowanie portu;
przekierowanie portu JDWP do debugowania aplikacji Java.

Ze strony IDE wsparcie jest jedynie w VScode (z pomocą dla JavaScript, takie jak typy BigInt i BigFloat, a także), jednak w planach na obecny (2019) rok są Eclipse i Intellij.

Do debugowania procesów Squash uruchamia na węzłach klastra uprzywilejowany kontener, dlatego należy najpierw zapoznać się z możliwościami trybu bezpiecznego aby uniknąć problemów z bezpieczeństwem.

Rozwiązania kompleksowe

Przechodzimy do ciężkiej artylerii — bardziej „skalowalnych” projektów, mających na celu zaspokojenie wielu potrzeb programistów.

NB: W tej liście zdecydowanie jest miejsce na nasze narzędzie open source werf (wcześniej znane jako dapp). Jednakże już nie raz pisaliśmy i mówiliśmy o nim, dlatego postanowiliśmy nie uwzględniać go w przeglądzie. Dla chętnych do bliższego zapoznania się z jego możliwościami polecamy przeczytać/posłuchać wykład „werf — nasze narzędzie do CI/CD w Kubernetes».

DevSpace

Istota: dla tych, którzy chcą zacząć pracować w Kubernetes, ale nie chcą zbytnio zagłębiać się w jego zawiłości.
GitHub.
Krótka statystyka GH: 630 gwiazd, 1912 commitów, 13 współtwórców.
Język: Go.
Licencja: Apache License 2.0.

Rozwiązanie od tej samej firmy, oferującej zarządzane klastry z Kubernetes dla zespołowego programowania. Narzędzie zostało stworzone dla komercyjnych klastrów, ale doskonale działa również z innymi.

Podczas uruchamiania polecenia devspace init w katalogu z projektem zostaniesz poproszony (w trybie interaktywnym):

wybrać roboczy klaster Kubernetes,
użyć istniejącego Dockerfile (lub wygenerować nowy) do stworzenia kontenera na jego bazie,
wybrać repozytorium do przechowywania obrazów kontenerów itd.

Po wszystkich tych wstępnych działaniach możesz rozpocząć rozwój, wykonując polecenie devspace dev. To zbierze kontener, załaduje go do repozytorium, wdroży deployment w klastrze i uruchomi przekierowanie portów oraz synchronizację kontenera z lokalnym katalogiem.

Opcjonalnie zostanie zaproponowane przejście do kontenera w terminalu. Nie warto odmawiać, ponieważ w rzeczywistości kontener startuje z poleceniem sleep, a do rzeczywistego testowania aplikację należy uruchomić ręcznie.

W końcu polecenie devspace deploy wdroży aplikację i powiązaną z nią infrastrukturę w klastrze, po czym wszystko zacznie funkcjonować w trybie produkcyjnym.

Cała konfiguracja projektu jest przechowywana w pliku devspace.yaml. Oprócz ustawień środowiska do rozwoju można w nim znaleźć opis infrastruktury, podobny do standardowych manifestów Kubernetes, tylko znacznie uproszczony.

Architektura i główne etapy pracy z DevSpace

Dodatkowo, do projektu łatwo można dodać predefiniowany komponent (na przykład bazę danych MySQL) lub chart Helm. Szczegóły znajdziesz w dokumentacji — jest to proste.

Skaffold

Strona; GitHub.
Krótka statystyka GH: 7423 gwiazdki, 4173 commity, 136 współautorów.
Język: Go.
Licencja: Apache License 2.0.

To narzędzie od Google ma na celu zaspokojenie wszystkich potrzeb dewelopera, którego kod w jakiś sposób będzie uruchamiany w klastrze Kubernetes. Zaczęcie korzystania z niego nie jest tak proste, jak z devspace’em: brak interaktywności, określania języka i automatycznego tworzenia Dockerfile tutaj nie zostanie ci zaproponowane.

Jednak jeśli cię to nie przeraża — oto, co umożliwia Skaffold:

Śledzenie zmian w kodzie źródłowym.
Synchronizowanie go z kontenerem pod’a, jeśli nie wymaga budowy.
Budowanie kontenerów z kodem, jeśli język programowania to język interpretowany, lub kompilowanie artefaktów i pakowanie ich w kontenery.
Uzyskane obrazy automatycznie sprawdzane są za pomocą container-structure-test.
Tagowanie i ładowanie obrazów do Docker Registry.
Wdrażanie aplikacji w klastrze, używając kubectl, Helm lub kustomize.
Robienie przekierowania portów.
Debugowanie aplikacji napisanych w Java, Node.js, Python.

Workflow w różnych wariacjach deklaratywnie opisuje się w pliku skaffold.yaml. Można również określić kilka profili projektu, w których częściowo lub całkowicie zmienia się etapy budowy i wdrażania. Na przykład, dla pracy dewelopera można wskazać odpowiedni obraz bazowy, a dla stagingu i produkcji – minimalny (+ użyć securityContext kontenerów lub nadpisać klaster, w którym aplikacja będzie wdrażana).

Budowa kontenerów Docker może odbywać się lokalnie lub zdalnie: w Google Cloud Build lub w klastrze za pomocą Kaniko. Wsparcie oferują również Bazel i Jib Maven/Gradle. Dla tagowania Skaffold wspiera wiele strategii: według hasha commit git, daty/czasu, sumy sha256 źródeł itd.

Osobno warto wspomnieć o możliwości testowania kontenerów. Już wspomniany framework container-structure-test oferuje następujące metody weryfikacji:

Wykonywanie poleceń w kontekście kontenera z monitorowaniem statusów wyjścia i sprawdzaniem tekstowego „wyniku” polecenia.
Sprawdzanie obecności plików w kontenerze oraz zgodności atrybutów z określonymi.
Kontrola zawartości plików za pomocą wyrażeń regularnych.
Porównanie metadanych obrazu (ENV, PUNKCIE WEJŚCIA, VOLUMES itd.).
Sprawdzanie zgodności licencji.

Synchronizacja plików z kontenerem odbywa się w mniej optymalny sposób: Skaffold po prostu tworzy archiwum z kodem źródłowym, kopiuje je i rozpakowuje w kontenerze (musisz mieć zainstalowane tar). Dlatego, jeśli twoim głównym celem jest synchronizacja kodu, lepiej przyjrzyj się specjalistycznemu rozwiązaniu (ksync).

Podstawowe etapy pracy Skaffold

Ogólnie rzecz biorąc, narzędzie nie pozwala zbytnio abstrahować się od manifestów Kubernetes i nie ma żadnej interaktywności, dlatego może się wydawać trudne do opanowania. Ale w tym tkwi jego zaleta – większa swoboda działania.

Garden

Strona; GitHub.
Krótka statystyka GH: 1063 gwiazdki, 1927 commitów, 17 współtwórców.
Język: TypeScript (planowane jest podzielenie projektu na kilka komponentów, z których niektóre będą na Go, a także stworzenie SDK do tworzenia dodatków na TypeScript/JavaScript i Go).
Licencja: Apache License 2.0.

Podobnie jak Skaffold, Garden ma na celu automatyzację procesów dostarczania kodu aplikacji do klastra K8s. W tym celu najpierw należy opisać strukturę projektu w pliku YAML, a następnie uruchomić polecenie garden dev. To zrobi całą magię:

Zbiera kontenery z różnymi częściami projektu.
Przeprowadzi testy integracyjne i jednostkowe, jeśli takie zostały opisane.
Wyświetli wszystkie komponenty projektu w klastrze.
W przypadku zmiany kodu źródłowego ponownie uruchomi cały pipeline.

Główny nacisk w korzystaniu z tego narzędzia kładzie się na wspólne korzystanie zdalnego klastra przez zespół programistów. W takim przypadku, jeśli niektóre etapy budowy i testowania zostały już wykonane, znacznie przyspieszy to cały proces, ponieważ Garden będzie mogło wykorzystać zbuforowane wyniki.

Modułem projektu może być kontener, kontener Maven, chart Helm, manifest dla kubectl apply lub nawet funkcja OpenFaaS. Każdy z modułów można zaciągnąć z zdalnego repozytorium Git. Moduł może określać (a może i nie) usługi, zadania i testy. Usługi i zadania mogą mieć zależności, co pozwala określić sekwencję wdrożenia danej usługi, uporządkować uruchamianie zadań i testów.

Garden oferuje użytkownikowi piękny dashboard (na razie w stadium eksperymentalnym), w którym wyświetlany jest diagram projektu: komponenty, sekwencja budowy, wykonania zadań i testów, ich powiązania i zależności. Bezpośrednio w przeglądarce można przeglądać logi wszystkich komponentów projektu, sprawdzić, co zwraca dany komponent po HTTP (jeśli oczywiście dla niego zadeklarowano zasób ingress).

Panel dla Garden

Narzędzie to posiada także tryb hot-reload, który po prostu synchronizuje zmiany w skryptach z kontenerem w klastrze, wielokrotnie przyspieszając proces debugowania aplikacji. Garden ma dobre 文档 i niezłe zestaw przykładów, które pozwalają szybko się zaznajomić i zacząć korzystać. Zresztą, całkiem niedawno opublikowaliśmy tłumaczenie artykułu od jego autorów.

Podsumowanie

Oczywiście, ten wykaz narzędzi do tworzenia i debugowania aplikacji w Kubernetes nie wyczerpuje tematu. Istnieje wiele innych bardzo przydatnych i praktycznych narzędzi, które zasługują na to, aby przynajmniej je wspomnieć. Podzielcie się, z jakich narzędzi korzystacie, z jakimi problemami się mierzyliście i jak je rozwiązaliście!

P.S.

Przeczytaj także na naszym blogu:

Źródło: habr.com