🥇Інструменты для распрацоўшчыкаў прыкладанняў, якія запускаюцца ў Kubernetes

Сучасны падыход да эксплуатацыі вырашае мноства надзённых праблем бізнэсу. Кантэйнеры і аркестратары дазваляюць лёгка маштабаваць праекты любой складанасці, спрашчаюць рэлізы новых версій, робяць іх больш надзейнымі, але разам з тым ствараюць і дадатковыя праблемы для распрацоўшчыкаў. Праграміста, у першую чаргу, клапоціць яго код: архітэктура, якасць, прадукцыйнасць, элегантнасць, - а не тое, як ён паедзе ў Kubernetes і як яго тэставаць і адладжваць пасля ўнясення нават мінімальных правак. Таму вельмі заканамерна і тое, што актыўна развіваюцца прылады для Kubernetes, якія дапамагаюць вырашаць праблемы нават самых "архаічных" распрацоўшчыкаў і дазваляючы ім засяродзіцца на галоўным.

У гэтым аглядзе прадстаўлена кароткая інфармацыя аб некаторых інструментах, якія спрашчаюць жыццё праграмісту, чый код круціцца ў pod'ax Kubernetes-кластара.

Простыя памочнікі

Kubectl-debug

сутнасць: дадай свой кантэйнер у Pod і паглядзі, што ў ім адбываецца.
GitHub.
Кароткая статыстыка GH: 715 зорак, 54 комiты, 9 кантрыб'ютараў.
Мова: Go.
Ліцэнзія: Apache License 2.0.

Гэты убудова для kubectl дазваляе стварыць усярэдзіне які цікавіць pod'a дадатковы кантэйнер, які будзе дзяліць прастору імёнаў працэсаў з астатнімі кантэйнерамі. У ім можна вырабляць адладку працы pod'а: праверыць працу сеткі, паслухаць сеткавы трафік, зрабіць strace які цікавіць працэсу і да т.п.

Таксама можна пераключыцца ў кантэйнер працэсу, выканаўшы chroot /proc/PID/root - гэта бывае вельмі зручна, калі трэба атрымаць root shell у кантэйнеры, для якога ў маніфесце выстаўлены securityContext.runAs.

Інструмент просты і эфектыўны, так што можа спатрэбіцца кожнаму распрацоўшчыку. Больш падрабязна пра яго мы пісалі ў асобным артыкуле.

Тэлепрысутнасць

сутнасць: перанясі дадатак на свой кампутар. Распрацоўвай і адладжвай лакальна.
Сайт; GitHub.
Кароткая статыстыка GH: 2131 зорка, 2712 комітаў, 33 кантрыб'ютара.
Мова: Python.
Ліцэнзія: Apache License 2.0.

Ідэя гэтага абсталявання заключаецца ў запуску кантэйнера з дадаткам на лакальным карыстацкім кампутары і праксіраванні за ўсё трафіку з кластара ў яго і назад. Такі падыход дазваляе весці распрацоўку лакальна, проста змяняючы файлы ў сваёй каханай IDE: вынікі будуць даступныя адразу ж.

Плюсы лакальнага запуску - зручнасць правак і маментальны вынік, магчымасць адладжваць прыкладанне звыклым спосабам. З мінусаў - патрабавальнасць да хуткасці злучэння, што асабліва прыкметна, калі даводзіцца працаваць з дадаткам з дастаткова высокім RPS і трафікам. Акрамя таго, у Telepresence ёсць праблемы з volume mounts у Windows, што можа стаць вырашальным абмежавальнікам для распрацоўшчыкаў, якія звыкнуліся да гэтай АС.

Мы ўжо дзяліліся сваім досведам выкарыстання Telepresence тут.

Ksync

сутнасць: амаль імгненная сінхранізацыя кода з кантэйнерам у кластары.
GitHub.
Кароткая статыстыка GH: 555 зорак, 362 комiты, 11 кантрыб'ютараў.
Мова: Go.
Ліцэнзія: Apache License 2.0.

Утыліта дазваляе сінхранізаваць змесціва лакальнай дырэкторыі з каталогам кантэйнера, запушчанага ў кластары. Такая прылада выдатна падыдзе для распрацоўнікаў на скрыптовых мовах праграмавання, асноўная праблема ў якіх - даставіць код у які працуе кантэйнер. Ksync закліканы зняць гэты галаўны боль.

Пры аднаразовай ініцыялізацыі камандай ksync init у кластары ствараецца DaemonSet, які выкарыстоўваецца для адсочвання стану файлавай сістэмы абранага кантэйнера. На сваім лакальным кампутары распрацоўшчык запускае каманду ksync watch, якая сочыць за канфігурацыямі і запускае сінхранізацыя, якая ажыццяўляе непасрэдную сінхранізацыю файлаў з кластарам.

Застаецца праінструктаваць ksync, што і з чым сінхранізаваць. Напрыклад, такая каманда:

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

… створыць watcher з імем myproject, які будзе шукаць pod з пазнакай app=backend і спрабаваць сінхранізаваць лакальную дырэкторыю /home/user/myproject/ з каталогам /var/www/myproject/ у кантэйнера пад назвай php.

Праблемы і нататкі па ksync з нашага вопыту:

На вузлах Kubernetes-кластара павінна выкарыстоўвацца overlay2 у якасці storage driver для Docker. Ні з якімі іншымі ўтыліта працаваць не будзе.
Пры выкарыстанні Windows у якасці АС кліента магчымая некарэктная праца watcher'а файлавай сістэмы. Дадзены баг заўважаны пры працы з буйнымі каталогамі - з вялікай колькасцю укладзеных файлаў і дырэкторый. Мы стварылі адпаведны issue у праекце syncthing, але прагрэсу па ім пакуль (з пачатку ліпеня) не.
Выкарыстоўвайце файл .stignore для таго, каб паказаць шляхі ці шаблоны файлаў, якія не трэба сінхранізаваць (напрыклад, каталогі app/cache и .git).
Па змаўчанні ksync будзе перазагружаць кантэйнер пры кожнай змене файлаў. Для Node.js гэта зручна, а для PHP – зусім залішне. Лепш выключыць opcache і выкарыстоўваць сцяг --reload=false.
Канфігурацыю можна заўсёды выправіць у $HOME/.ksync/ksync.yaml.

сквош

сутнасць: адладжвай працэсы прама ў кластары.
GitHub.
Кароткая статыстыка GH: 1154 зорак, 279 комітаў, 23 кантрыб'ютара.
Мова: Go.
Ліцэнзія: Apache License 2.0.

Дадзеная прылада прызначаны для адладкі працэсаў непасрэдна ў pod'ах. Утыліта простая і ў інтэрактыўным рэжыме дазваляе абраць патрэбны адладчык. (гл. ніжэй) і namespace + pod, у працэс якога трэба ўмяшацца. У цяперашні час падтрымліваюцца:

delve - для прыкладанняў на Go;
GDB - праз target remote + пракід порта;
пракід порта JDWP для адладкі Java-прыкладанняў.

З боку IDE падтрымка ёсць толькі ў VScode (з дапамогай пашырэння), аднак у планах на бягучы (2019) год значацца Eclipse і Intellij.

Для адладкі працэсаў Squash запускае на вузлах кластара прывілеяваны кантэйнер, таму неабходна спачатку азнаёміцца з магчымасцямі бяспечнага рэжыму у пазбяганне праблем з бяспекай.

Комплексныя рашэнні

Пераходзім да цяжкай артылерыі - больш «маштабным» праектам, закліканым адразу зачыніць шматлікія запатрабаванні распрацоўнікаў.

NB: У гэтым спісе, безумоўна, ёсць месца і нашай Open Source-утыліце werf (раней вядомай як dapp). Аднак мы ўжо не раз пісалі і расказвалі пра яе, а таму вырашылі не ўключаць у агляд. Для жадаючых азнаёміцца з яе магчымасцямі бліжэй рэкамендуем прачытаць/паслухаць дакладwerf – наш інструмент для CI/CD у Kubernetes.

DevSpace

сутнасць: для тых, хто хоча пачаць працаваць у Kubernetes, але не хоча глыбока залазіць у яго нетры.
GitHub.
Кароткая статыстыка GH: 630 зорак, 1912 коммітаў, 13 кантрыб'ютараў.
Мова: Go.
Ліцэнзія: Apache License 2.0.

Рашэнне ад аднайменнай кампаніі, якая прадстаўляе managed-кластары з Kubernetes для каманднай распрацоўкі. Утыліта была створана для камерцыйных кластараў, аднак выдатна працуе і з любымі іншымі.

Пры запуску каманды devspace init у каталогу з праектам вам прапануюць (у інтэрактыўным рэжыме):

абраць працоўны Kubernetes-кластар,
выкарыстоўваць наяўны Dockerfile (або згенераваць новы) для стварэння кантэйнера на яго базе,
выбраць рэпазітар для захоўвання вобразаў кантэйнераў і г.д.

Пасля ўсіх гэтых падрыхтоўчых дзеянняў можна пачынаць распрацоўку, выканаўшы каманду devspace dev. Яна збярэ кантэйнер, загрузіць яго ў рэпазітар, выкоціць deployment у кластар і запусціць пракід партоў і сінхранізацыю кантэйнера з лакальным каталогам.

Апцыянальна будзе прапанавана перайсці тэрміналам у кантэйнер. Адмаўляцца не варта, таму як у рэальнасці кантэйнер стартуе з камандай sleep, а для рэальнага тэсціравання прыкладанне патрабуецца запускаць уручную.

Нарэшце, каманда devspace deploy выкочвае прыкладанне і звязаную з ім інфраструктуру ў кластар, пасля чаго ўсё пачынае функцыянаваць у баявым рэжыме.

Уся канфігурацыя праекта захоўваецца ў файле devspace.yaml. Апроч налад асяроддзя для распрацоўкі ў ім жа можна знайсці апісанне інфраструктуры, падобнае на стандартныя маніфесты Kubernetes, толькі моцна спрошчаныя.

Архітэктура і асноўныя этапы працы з DevSpace

Акрамя таго, у праект лёгка дадаць наканаваны кампанент (напрыклад, СКБД MySQL) або Helm-чарт. Больш падрабязна чытайце ў дакументацыі - Яна нескладаная.

Скафот

Сайт; GitHub.
Кароткая статыстыка GH: 7423 зоркі, 4173 коміты, 136 кантрыб'ютараў.
Мова: Go.
Ліцэнзія: Apache License 2.0.

Гэтая ўтыліта ад Google прэтэндуе на тое, каб пакрыць усе запатрабаванні распрацоўніка, чый код так ці інакш будзе запускацца ў кластары Kubernetes. Пачаць карыстацца ім не так проста, як devspace'ам: ніякай інтэрактыўнасці, азначэнні мовы і аўтастварэнні Dockerfile тут вам не прапануюць.

Зрэшты, калі гэта не палохае вось што дазваляе рабіць Skaffold:

Адсочваць змены зыходнага кода.
Сінхранізаваць яго з кантэйнерам pod'а, калі ён не патрабуе зборкі.
Збіраць кантэйнеры з кодам, калі ЯП - інтэрпрэтаваны, ці ж кампіляваць артэфакты і пакаваць іх у кантэйнеры.
Атрыманыя выявы аўтаматычна правяраць з дапамогай container-structure-test.
Тэгіраваць і загружаць вобразы ў Docker Registry.
Разгортваць прыкладанне ў кластары, выкарыстоўваючы kubectl, Helm ці kustomize.
Рабіць пракід партоў.
Адладжваць прыкладанні, напісаныя на Java, Node.js, Python.

Workflow у розных варыяцыях дэкларатыўна апісваецца ў файле skaffold.yaml. Для праекту можна таксама вызначыць некалькі профіляў, у якіх часткова ці цалкам змяняць стадыі зборкі і дэплою. Напрыклад, для распрацоўкі паказаць зручную для распрацоўніка базавую выяву, а для staging і production - мінімальны (+ выкарыстоўваць securityContext у кантэйнераў ці ж перавызначыць кластар, у якім прыкладанне будзе разгорнута).

Зборка Docker-кантэйнераў можа ажыццяўляцца лакальна або выдалена: у Google Cloud Build або ў кластары з дапамогай Kaniko. Таксама падтрымліваюцца Bazel і Jib Maven/Gradle. Для тэгавання Skaffold падтрымлівае мноства стратэгій: па git commit hash, даце/часу, sha256-суме зыходнікаў і да т.п.

Асобна варта адзначыць магчымасць тэставання кантэйнераў. Ужо згаданы фрэймворк container-structure-test прапануе наступныя метады праверкі:

Выкананне каманд у кантэксце кантэйнера з адсочваннем exit-статусаў і праверкай тэкставага "выхлапу" каманды.
Праверка наяўнасці файлаў у кантэйнеры і адпаведнасці атрыбутаў паказаным.
Кантроль змесціва файлаў па рэгулярных выразах.
Зверка метададзеных выявы (ENV, ENTRYPOINT, VOLUMES і да т.п.).
Праверка сумяшчальнасці ліцэнзій.

Сінхранізацыя файлаў з кантэйнерам ажыццяўляецца не самым аптымальным спосабам: Skaffold проста стварае архіў з зыходнікамі, капіюе яго і распакоўвае ў кантэйнеры (павінен быць усталяваны tar). Таму, калі ваша асноўная задача - у сінхранізацыі кода, лепш паглядзець у бок спецыялізаванага рашэння (ksync).

Асноўныя этапы працы Skaffold

У цэлым жа прылада не дазваляе абстрагавацца ад Kubernetes-маніфестаў і не мае які-небудзь інтэрактыўнасці, таму можа здацца складаным для засваення. Але ў гэтым жа і яго плюс - вялікая свабода дзеянняў.

Сад

Сайт; GitHub.
Кароткая статыстыка GH: 1063 зоркі, 1927 комітаў, 17 кантрыб'ютараў.
Мова: TypeScript (плануецца разбіць праект на некалькі кампанентаў, некаторыя з якіх будуць на Go, а таксама зрабіць SDK для стварэння дадаткаў на TypeScript/JavaScript і Go).
Ліцэнзія: Apache License 2.0.

Як і Skaffold, Garden накіраваны на аўтаматызацыю працэсаў дастаўкі кода прыкладання ў K8s-кластар. Для гэтага спачатку неабходна апісаць структуру праекту ў YAML-файле, пасля чаго запусціць каманду garden dev. Яна зробіць усю магію:

Збярэ кантэйнеры з рознымі часткамі праекту.
Правядзе інтэграцыйныя і unit-тэсты, калі такія былі апісаны.
Выкаціць усе кампаненты праекта ў кластар.
У выпадку змены зыходнага кода - зноўку запусціць увесь пайплайн.

Асноўны ўпор пры выкарыстанні гэтай прылады робіцца на сумеснае выкарыстанне выдаленага кластара камандай распрацоўнікаў. У гэтым выпадку, калі нейкія стадыі зборкі і тэсціравання ўжо былі зроблены, гэта значна паскорыць увесь працэс, паколькі Garden зможа выкарыстоўваць закэшаваныя вынікі.

Модулем праекта можа быць кантэйнер, Maven-кантэйнер, Helm-чарт, маніфест для kubectl apply ці нават OpenFaaS-функцыя. Прычым любы з модуляў можна падцягнуць з выдаленага Git-рэпазітара. Модуль можа вызначаць (а можа і не) сэрвісы, задачы і тэсты. Сэрвісы і задачы могуць мець залежнасці, дзякуючы чаму можна вызначыць паслядоўнасць дэплою таго ці іншага сэрвісу, упарадкаваць запуск заданняў і тэстаў.

Garden дае карыстальніку прыгожы dashboard (пакуль у эксперыментальным стане), у якім адлюстроўваецца граф праекта: кампаненты, паслядоўнасць зборкі, выканання задач і тэстаў, іх сувязі і залежнасці. Прама ў браўзэры можна прагледзець і логі ўсіх кампанентаў праекту, праверыць, што выдае той ці іншы кампанент па HTTP (калі, вядома, для яго абвешчаны рэсурс ingress).

Панэль для Garden

Ёсць у гэтай прылады і рэжым hot-reload, які проста сінхранізуе змены скрыптоў з кантэйнерам у кластары, шматкроць паскараючы працэс адладкі прыкладання. У Garden добрая дакументацыя і нядрэнны набор прыкладаў, якія дазваляюць хутка асвоіцца і пачаць карыстацца. Дарэчы, зусім нядаўна мы публікавалі пераклад артыкула ад яго аўтараў.

Заключэнне

Зразумела, дадзеным спісам інструментар для распрацоўкі і адладкі прыкладанняў у Kubernetes не абмяжоўваецца. Існуе яшчэ шмат вельмі карысных і практычных утыліт, годных калі не асобнага артыкула, то - як мінімум - згадванні. Раскажыце, чым карыстаецеся вы, з якімі праблемамі даводзілася сутыкацца і як вы іх вырашалі!

PS

Чытайце таксама ў нашым блогу:

Крыніца: habr.com

Інструменты для распрацоўшчыкаў прыкладанняў, якія запускаюцца ў Kubernetes