Ўсім прывітанне! Мяне клічуць Павел Агалецкі. Я працую тымлідам у камандзе, якая распрацоўвае сістэму дастаўкі Lamoda. У 2018 годзе я выступаў на канферэнцыі HighLoad++, а сёння хачу прадставіць расшыфроўку свайго даклада.

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

Дэплой прыкладанняў на VM

Пачнём з таго, што 3 гады назад усе сістэмы і сэрвісы кампаніі дэпляваліся на звычайныя віртуальныя серверы. Тэхнічна было арганізавана так, што ўвесь код нашых сістэм ляжаў і збіраўся за рахунак сродкаў аўтаматычнай зборкі, з дапамогай jenkins. Пры дапамозе Ansible ён з нашай сістэмы кантролю версій раскочваўся ўжо на віртуальныя серверы. Пры гэтым кожная сістэма, якая была ў нашай кампаніі, дэплаіравалася, як мінімум, на 2 сервера: адна з іх – на head, другая – на tail. Гэтыя дзве сістэмы былі абсалютна ідэнтычныя паміж сабой па ўсіх сваіх налад, магутнасці, канфігурацыі і іншаму. Адрозненне паміж імі было толькі ў тым, што head атрымліваў карыстацкі трафік, а tail ніколі трафік карыстальнікаў на сябе не атрымліваў.

Навошта гэта было зроблена?

Калі мы дэплоілі новыя рэлізы нашага прыкладання, то жадалі забяспечыць магчымасць бясшвоўнай раскочвання, гэта значыць без прыкметных наступстваў для карыстачоў. Дасягалася гэта за рахунак таго, што чарговы сабраны рэліз з дапамогай Ansible выкочваўся на tail. Там людзі, якія займаліся дэплоем, маглі праверыць і пераканацца, што ўсё добра: усе метрыкі, раздзелы і прыкладанні працуюць; запускаюцца патрэбныя скрыпты. Толькі пасля таго, як яны пераконваліся, што ўсё ок, трафік перамыкаўся. Ён пачынаў ісці на той сервер, які да гэтага быў tail. А той, які да гэтага быў head-ом, заставаўся без карыстацкага трафіку, пры гэтым з наяўнай на ім папярэдняй версіяй нашага прыкладання.

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

Якія мы бачылі ва ўсім гэтым добрыя якасці?

1. Перш за ўсё, гэта дастаткова проста працуе. Усім зразумела, як функцыянуе падобная схема дэплою, таму што большасць людзей калі-небудзь дэплоілі на звычайныя віртуальныя серверы.
2. Гэта дастаткова надзейна, бо тэхналогія дэплою простая, апрабаваная тысячамі кампаній. Мільёны сэрвераў дэплояцца менавіта так. Складана нешта зламаць.
3. І нарэшце, мы маглі атрымаць атамарныя дэплоі. Дэплоі, якія для карыстачоў адбываюцца аднамомантна, без прыкметнага этапу пераключэння паміж старой версіяй і новай.

Але ў гэтым усім мы таксама бачылі некалькі недахопаў:

1. Акрамя прадакшн-асяроддзя, асяроддзя распрацоўкі, ёсць і іншыя асяроддзі. Напрыклад, qa і preproduction. На той момант у нас было шмат сэрвэраў і каля 60 сэрвісаў. Па гэтай прычыне даводзілася для кожнага сэрвісу падтрымліваць актуальную для яго версію віртуальнай машыны. Прычым, калі вы хочаце абнавіць бібліятэкі ці паставіць новыя залежнасці, вам неабходна гэта зрабіць ва ўсіх асяроддзях. Таксама трэба было сінхранізаваць час, калі вы збіраецеся дэплоіць чарговую новую версію вашага прыкладання, з часам, калі devops выканае неабходныя налады асяроддзя. У такім выпадку лёгка патрапіць у сітуацыю, калі асяроддзе ў нас будзе некалькі адрознівацца адразу ва ўсіх асяроддзях запар. Напрыклад, у QA-асяроддзі будуць адны версіі бібліятэк, а ў прадакшн – іншыя, што прывядзе да праблем.
2. Складанасць у абнаўленні залежнасцяў вашага дадатку. Гэта залежыць не ад вас, а ад іншай каманды. У прыватнасці, ад каманды devops, якая падтрымлівае сервера. Вы павінны паставіць для іх адпаведную задачу і даць апісанне таго, што жадаеце зрабіць.
3. У той час мы таксама хацелі падзяліць вялікія маналіты, якія былі ў нас, на асобныя маленькія сэрвісы, бо разумелі, што іх будзе станавіцца ўсё больш і больш. На той момант у нас ужо было іх больш за 100. Неабходна было для кожнага новага сэрвісу ствараць асобную новую віртуальную машыну, якую таксама трэба абслугоўваць і дэплоіць. Акрамя гэтага, патрэбна не адна машына, а, прынамсі, дзве. Да гэтага ўсяго яшчэ дадаецца QA-асяроддзе. Гэта выклікае праблемы і робіць для вас стварэнне і запуск новых сістэм больш складаным, дарагім і доўгім працэсам.

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

Мы доўга разважалі над тым, якую з іх можна ўзяць. Справа ў тым, што на той момант гэты стэк дэплою на звычайныя віртуальныя серверы быў у нас некалькі састарэлым, бо тамака былі не самыя свежыя версіі аперацыйных сістэм. У нейкі момант тамака нават FreeBSD стаяла, якую было не вельмі зручна падтрымліваць. Мы разумелі, што трэба як мага хутчэй міграваць у docker. Нашы дэвопс паглядзелі на свой наяўны досвед працы з рознымі рашэннямі і абралі такую ​​сістэму як Nomad.

Пераход на Nomad

Nomad - гэта прадукт кампаніі "HashiCorp". Таксама яны вядомыя іншымі сваімі рашэннямі:

«Consul» — гэта сродак для сэрвіс-дыскаверынгу.

"Terraform" - сістэма для кіравання серверамі, якая дазваляе вам наладжваць іх праз канфігурацыю, так званую infrastructure-as-a-code.

"Vagrant" дазваляе вам разгортваць віртуальныя машыны лакальна ці ў воблаку шляхам пэўных файлаў канфігурацыі.

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

Што трэба для таго, каб наогул задэплоіць вашу сістэму ў Nomad?

1. Першым чынам патрэбен вобраз докера вашага дадатку. Неабходна сабраць яго і змясціць у сховішча выяваў docker. У нашым выпадку гэта artifactory - такая сістэма, якая дазваляе пушыць у яе розныя артэфакты рознага тыпу. Яна ўмее захоўваць архівы, выявы docker, пакеты composer РНР, NРМ-пакеты і гэтак далей.
2. Таксама неабходны канфігурацыйны файл, Які скажа Nomad, што, куды і ў якой колькасці вы хочаце задэплоіць.

Калі мы гаворым пра Nomad, то ў якасці фармату інфармацыйнага файла ён выкарыстоўвае мову HСL, што расшыфроўваецца як HashiCorp Configuration Language. Гэта такое надмноства над Yaml, якое дазваляе вам апісаць ваш сэрвіс у тэрмінах Nomad.

Ён дазваляе сказаць, колькі кантэйнераў жадаеце задэплоіць, з якіх images перадаць ім розныя параметры пры дэплоі. Такім чынам, вы скормліваеце гэты файл Nomad, а ён запускае ў адпаведнасці з ім кантэйнеры ў прадакшн.

У нашым выпадку мы зразумелі, што проста пісаць пад кожны сэрвіс абсалютна аднолькавыя, ідэнтычныя HСL-файлы будзе не вельмі зручна, таму што сэрвісаў шмат і часам жадаецца іх абнавіць. Бывае такое, што адзін сэрвіс задэплоен не ў адным асобніку, а ў самых розных. Напрыклад, адна з сістэм, якая ў нас знаходзіцца ў прадакшн, мае больш за 100 інстансаў у продзе. Яны запускаюцца з адных і тых жа выяў, але адрозніваюцца канфігурацыйнымі наладамі і канфігурацыйнымі файламі.

Таму мы вырашылі, што нам будзе зручна захоўваць усе нашы канфігурацыйныя файлы для дэплою ў адным агульным рэпазітары. Такім чынам, яны станавіліся аглядаемымі: іх было лёгка падтрымліваць і можна было ўбачыць, якія сістэмы ў нас ёсць. У выпадку неабходнасці таксама нескладана нешта абнавіць ці памяняць. Дадаць новую сістэму таксама не складзе працы - досыць проста завесці канфігурацыйны файл усярэдзіне новай дырэкторыі. Усярэдзіне яе ляжаць файлы: service.hcl, які ўтрымоўвае апісанне нашага сэрвісу, і некаторыя env-файлы, якія дазваляюць гэты самы сэрвіс, быўшы задэплоеным у прадакшн, наладзіць.

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

Акрамя гэтага, мы змясцілі ў рэпазітар агульны для ўсіх праектаў скрыпт-дэплой, які дазваляе запусціць і задэплоіць ваш сэрвіс у прадакшн, у патрэбны environment, у патрэбны таргет. У выпадку, калі мы ператварылі наш HCL-канфіг у шаблон, то той HСL-файл, які да гэтага быў звычайным канфігам Nomad, у гэтым выпадку стаў выглядаць некалькі інакш.

Гэта значыць, мы замянілі нейкія зменныя месцы канфігу на ўстаўкі зменных, якія бяруцца з env-файлаў або з іншых крыніц. Апроч гэтага, мы атрымалі магчымасць збіраць HСL-файлы дынамічна, гэта значыць мы можам ужываць не толькі звычайныя ўстаўкі зменных. Бо jinja падтрымлівае цыклы і ўмовы, туды ж можна рабіць канфігурацыйныя файлы, якія змяняюцца ў залежнасці ад таго, куды менавіта вы дэплоіце свае прыкладанні.

Напрыклад, вы хочаце дэплоіць ваш сэрвіс у препродакшн і ў прадакшн. Дапушчальны, што ў препродакшн вы не жадаеце запускаць крон-cкрыпты, а проста жадаеце бачыць сэрвіс на асобным дамене, каб пераканацца, што ён функцыянуе. Для любога, хто дэплоіты сэрвіс, працэс выглядае вельмі проста і празрыста. Досыць выканаць файл deploy.sh, паказаць, які сэрвіс вы жадаеце задэплоіць і ў які таргет. Напрыклад, вы хочаце задэплоіць некаторую сістэму ў Расію, у Беларусь або Казахстан. Для гэтага дастаткова проста памяняць адзін з параметраў, і ў вас збярэцца правільны канфігурацыйны файл.

Калі сэрвіс Nomad ужо апыняецца ў вас задэплоеным у кластар, ён выглядае наступным чынам.

Для пачатку вам патрэбен некаторы балансавальнік звонку, які будзе прымаць увесь карыстацкі трафік у сябе. Ён будзе працаваць разам з Consul і пазнаваць у яго, дзе, на якой нодзе, па якім IP-адрасу знаходзіцца пэўны сэрвіс, які адпавядае таму ці іншаму даменнаму імені. Сэрвісы ў Consul з'яўляюцца з самага Nomad. Паколькі гэта прадукты адной і той жа кампаніі, яны нядрэнна злучаны паміж сабой. Можна сказаць, што Nomad са скрынкі ўмее рэгістраваць усе якія запускаюцца ў ім сэрвісы ўсярэдзіне Consul.

Пасля таго як ваш знешні балансавальнік даведаецца аб тым, у які сэрвіс неабходна адправіць трафік, ён перанакіроўвае яго ў адпаведны кантэйнер або ў некалькі кантэйнераў, якія адпавядаюць вашаму з дадаткам. Натуральна, што пры гэтым неабходна думаць і аб бяспецы. Нават нягледзячы на ​​тое, што ўсе сэрвісы запускаюцца на адных і тых жа віртуальных машынах у кантэйнерах, звычайна для гэтага патрабуецца забараніць вольны доступ з любога сэрвісу да любога іншага. Мы дасягалі гэтага за кошт сегментацыі. Кожны сэрвіс запускаўся ў сваёй віртуальнай сетцы, на якой былі прапісаныя правілы маршрутызацыі і правілы дазволу/забароны доступу да іншых сістэмаў і сэрвісаў. Яны маглі знаходзіцца як унутры гэтага кластара, так і па-за ім. Напрыклад, калі вы жадаеце забараніць сэрвісу канэкціцца да пэўнай базы дадзеных, гэта можна зрабіць шляхам сегментацыі на ўзроўні сеткі. Гэта значыць нават па памылцы вы не можаце выпадкова падлучацца з тэставага асяроддзя да вашай прадакшн базы.

У што нам абышоўся працэс пераходу ў плане чалавечых рэсурсаў?

Прыкладна 5-6 месяцаў заняў пераход усёй кампаніі ў Nomad. Мы пераходзілі пасервісна, але ў дастаткова хуткім тэмпе. Кожная каманда павінна была стварыць свае ўласныя кантэйнеры для сервісаў.

У нас прыняты такі падыход, што кожная каманда адказвае за docker images сваіх сістэм самастойна. Дэвопс ж падаюць агульную інфраструктуру, неабходную для дэплою, гэта значыць падтрымку самога кластара, падтрымку CI-сістэмы і гэтак далей. І на той момант у нас больш за 60 сістэм пераехалі ў Nomad, атрымалася каля 2 тысяч кантэйнераў.

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

Прычыны адмовы ад Nomad

Якія добрыя якасці мы атрымалі, перайшоўшы на дэплой з дапамогай Nomad і docker у тым ліку?

1. Мы забяспечылі аднолькавыя ўмовы для ўсіх асяроддзяў. У дэвелампенты, QA-асяроддзі, препродакшне, прадакшне выкарыстоўваюцца адны і тыя ж выявы кантэйнераў, з аднымі і тымі ж залежнасцямі. Адпаведна ў вас практычна адсутнічае шанец таго, што ў прадакшн апынецца не тое, што вы да гэтага пратэставалі ў сябе лакальна ці на тэставым асяроддзі.
2. Таксама мы высветлілі, што дастаткова лёгка дадаць новы сэрвіс. Любыя новыя сістэмы з пункту гледжання дэплою запускаюцца вельмі проста. Дастаткова пайсці ў рэпазітар, які захоўвае канфігі, дадаць туды чарговы канфіг для вашай сістэмы, і ў вас усё гатова. Вы можаце дэплоіць вашу сістэму ў прадакшн без дадатковых намаганняў ад дэвопс.
3. Усе канфігурацыйныя файлы у адным агульным рэпазітары аказаліся агляданыя. У той момант, калі мы дэплоілі нашы сістэмы з дапамогай віртуальных сервераў, мы выкарыстоўвалі Ansible, у якім канфігі ляжалі ў адным і тым жа рэпазітары. Аднак для большасці распрацоўшчыкаў працаваць было з гэтым некалькі складаней. Тут аб'ём канфігаў і кода, які вам трэба дадаць, каб задэплоіць сэрвіс, стаў нашмат менш. Плюс для дэвопс вельмі лёгка паправіць яго ці памяняць. У выпадку пераходаў, напрыклад, на новай версіі Nomad, яны могуць узяць і масава абнавіць усе аперацыйныя файлы, якія ляжаць у адным і тым жа месцы.

Але мы таксама сутыкнуліся і з некалькімі недахопамі:

Аказалася, што мы не змаглі дасягнуць бясшвоўнасці дэплояў у выпадку Nomad. Пры выкатцы кантэйнераў з розных умоў магло атрымацца так, што ён апыняўся запушчаным, і Nomad успрымаў яго як гатовы да прыняцця трафіку кантэйнер. Гэта адбывалася яшчэ да таго, як дадатак унутры яго паспела запусціцца. Па гэтай прычыне сістэма на нядоўгі тэрмін пачынала выдаваць 500-я памылкі, таму што трафік пачынаў ісці на кантэйнер, які яшчэ не гатовы яго прыняць.

Мы сутыкнуліся з некаторымі па балотах. Самы істотны баг заключаецца ў тым, што Nomad не вельмі добра ўспрымае вялікі кластар, калі ў вас шмат сістэм і кантэйнераў. Калі вы хочаце вывезці ў абслугоўванне адзін з сервераў, які ўключаны ў кластар Nomad, ёсць дастаткова вялікая верагоднасць таго, што кластар адчуе сябе не вельмі добра і разваліцца на часткі. Частка кантэйнераў можа, напрыклад, зваліцца і не падняцца гэта вам пасля вельмі дорага абыйдзецца, калі ўсе вашы сістэмы ў прадакшн знаходзяцца менавіта ў кластары, кіраваным Nomad.

Таму мы вырашылі падумаць, куды нам ісьці далей. На той момант мы сталі нашмат лепш усведамляць, чаго жадаем дамагчыся. А менавіта: жадаем надзейнасці, трошкі больш функцый, чым дае Nomad, і больш спелую, больш стабільную сістэму.

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

Пераход у Kubernetes

Крыху раскажу пра тое, якія ёсць асноўныя паняцці Kubernetes і чым яны адрозніваюцца ад Nomad.

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

Дапусцім, што ў вас ёсць РНР-дадатак, якое складаецца з nginx і php-fpm - класічная схема. Хутчэй за ўсё, вы захочаце, каб і nginx і php-fpm кантэйнеры былі заўседы разам. Kubernetes дазваляе гэтага дамагчыся, апісаўшы іх як адзін агульны pod. Якраз гэтага мы і не маглі атрымаць пры дапамозе Nomad.

Другім паняццем з'яўляецца разгортванне. Справа ў тым, што pod сам па сабе - гэта эфемерная рэч, яна запускаецца і знікае. Ці хочаце вы спачатку забіваць усе вашыя папярэднія кантэйнеры, а потым запускаць адразу новыя версіі ці ж вы хочаце выкочваць іх паступова - вось менавіта за гэты працэс адказвае паняцце deployment. Ён апісвае тое, як вы дэплоіце вашыя podы, у якой колькасці і, як іх абнаўляць.

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

І чацвёртае асноўнае паняцце - Уваход. Гэта сэрвіс, які запускаецца ў кластары Kubernetes. Ён выступае як вонкавы балансавальнік нагрузкі, які прымае на сябе ўсе запыты. За рахунак API Kubernetes Ingress можа вызначаць, куды гэтыя запыты трэба адправіць. Прычым робіць ён гэта вельмі гнутка. Вы можаце сказаць, што ўсе запыты на гэты хост і вось такой URL адпраўляем на гэты сэрвіс. А гэтыя запыты, якія прыходзяць на гэты хост і на іншы URL адпраўляем на іншы сэрвіс.

Самае крутое з пункту гледжання таго, хто распрацоўвае дадатак - гэта тое, што вы здольныя гэтым усім кіраваць самастойна. Задаўшы канфіг Ingress, можаце ўвесь трафік, які прыходзіць на вось такой API, адпраўляць на асобныя кантэйнеры, прапісаныя, напрыклад, на Go. А вось гэты трафік, які прыходзіць на той жа дамен, але на іншы URL, адпраўляць на кантэйнеры, напісаныя на РНР, дзе шмат логікі, але яны не вельмі хуткасныя.

Калі параўнаць усе гэтыя паняцці з Nomad, то можна сказаць, што першыя тры паняцці - гэта ўсё разам Service. А апошняе паняцце ў самім Nomad адсутнічае. Мы ў якасці яго выкарыстоўвалі вонкавы балансавальнік: гэта можа быць haproxy, nginx, nginx+ і гэтак далей. У выпадку з кубам вам не трэба ўводзіць гэтае дадатковае паняцце асобна. Аднак, калі паглядзець на Ingress усярэдзіне, то гэта або nginx, або haproxy, або traefik, але як бы ўбудаваны ў Kubernetes.

Усе апісаныя мною паняцці - гэта, па сутнасці, рэсурсы, якія існуюць усярэдзіне кластара Kubernetes. Для іх апісання ў кубе выкарыстоўваецца yaml-фармат, больш чытэльны і звыклы, чым НСL-файлы ў выпадку з Nomad. Але структурна яны апісваюць у выпадку, напрыклад, podа тое ж самае. Яны кажуць - хачу задэплоіць такія-то podы туды-то, з вось такімі имаджи, у такой-то колькасці.

Апроч гэтага, мы зразумелі, што не жадаем рукамі ствараць кожны асобны рэсурс: deployment, сэрвісы, Ingress і іншае. Замест гэтага мы хацелі пры дэплоі апісваць нашу кожную сістэму, наяўную ў тэрмінах Kubernetes, каб не даводзілася ўручную пераствараць у патрэбным парадку ўсе неабходныя залежнасці рэсурсаў. У якасці такой сістэмы, якая дазволіла нам гэта зрабіць, быў абраны Helm.

Асноўныя паняцці ў Helm

Helm - гэта пакетны менеджэр для Kubernetes. Ён вельмі падобны да таго, як працуюць пакетныя менеджэры ў мовах праграмавання. Яны дазваляюць вам захоўваць сэрвіс, які складаецца з, напрыклад, deployment nginx, deployment php-fpm, канфіга для Ingress, configmaps (гэта сутнасць, якая дазваляе вам задаць env і іншыя параметры для вашай сістэмы) у выглядзе так званых чартаў. Пры гэтым Helm працуе над Kubernetes. Гэта значыць гэта не нейкая сістэма, стаялая ўбаку, а проста яшчэ адзін сэрвіс, які запускаецца ўсярэдзіне куба. Вы ўзаемадзейнічаеце з ім па ім API праз кансольную каманду. Яго зручнасць і хараство ў тым, што нават калі helm зламаецца ці вы яго выдаліце ​​з кластара, то вашы сэрвісы не знікнуць, бо helm служыць у сутнасці толькі для запуску сістэмы. За працаздольнасць і стан сэрвісаў далей адказвае сам Kubernetes.

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

Helm дадае нам яшчэ некалькі дадатковых паняццяў.

Графік - гэта апісанне вашага сэрвісу. У іншых пакетных мэнэджэрах яго назвалі б пакет, bundle ці нешта падобнае. Тут гэта называецца chart.

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

Адпусціце. Кожны раз сэрвіс, які дэплоіцца з дапамогай helm, атрымлівае інкрыментальную версію рэлізу. Helm памятае, які быў канфіг сэрвісу пры папярэднім, пазамінулым рэлізе і гэтак далей. Таму, калі трэба адкаціцца, дастаткова выканаць каманду helm callback, паказаўшы яму папярэднюю версію рэлізу. Нават калі ў момант адкату адпаведная канфігурацыя ў вашым рэпазітары не будзе даступная, helm усё роўна памятае, які яна была, і адкоціць вашу сістэму на той стан, у якім яна была ў папярэднім рэлізе.

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

На практыцы мы вырашылі паступіць крыху інакш, чым мы рабілі ў выпадку з Nomad. Калі ў Nomad у адным рэпазітары захоўваліся і канфігі для дэплою, і n-зменныя, якія патрэбныя для таго, каб задэплоіць наш сэрвіс, то тут мы вырашылі іх падзяліць на два асобных рэпазітара. У рэпазітары "deploy" захоўваюцца толькі n-зменныя, патрэбныя для дэплою, а ў рэпазітары "helm" захоўваюцца канфігі або чарты.

Што гэта нам дало?

Нягледзячы на ​​тое, што ў саміх канфігурацыйных файлах мы не захоўваем нейкія сапраўды адчувальныя дадзеныя. Напрыклад, паролі да баз дадзеных. Яны захоўваюцца ў выглядзе secrets у Kubernetes, але тым не менш, там усё роўна ёсць асобныя рэчы, да якіх мы не жадаем даваць доступ усім запар. Таму доступ да рэпазітара «deploy» больш абмежаваны, а рэпазітар «helm» утрымоўвае проста апісанне сэрвісу. Па гэтай прычыне ў яго можна даць доступ бяспечна большаму колу асоб.

Паколькі ў нас ёсць не толькі прадакшн, але і іншыя асяроддзі, то дзякуючы такому падзелу мы можам перавыкарыстоўваць нашы helm-чарты, каб дэплоіць сэрвісы не толькі ў прадакшн, але і, напрыклад, у QA-асяроддзе. Нават для таго, каб разгортваць іх лакальна, выкарыстоўваючы Мінікубе - Гэта такая штука для лакальнага запуску Kubernetes.

Унутры кожнага рэпазітара мы пакінулі падзел на асобныя дырэкторыі для кожнага сэрвісу. Гэта значыць усярэдзіне кожнай дырэкторыі знаходзяцца шаблоны, якія адносяцца да які адпавядае чарта і што апісваюць тыя рэсурсы, якія неабходна задэплоіць для запуску нашай сістэмы. У рэпазітары "deploy" мы пакінулі толькі энвы. У гэтым выпадку мы не сталі выкарыстоўваць шаблонізацыю з дапамогай jinja, таму што helm сам дае шаблонизацию з скрынкі – гэта адна з яго асноўных функцый.

Мы пакінулі скрыпт для дэплою - deploy.sh, які спрашчае і стандартуе запуск для дэплою з дапамогай helm. Такім чынам, для любога, хто жадае задэплоіць, інтэрфейс дэплою выглядае сапраўды гэтак жа, як ён быў у выпадку дэплою праз Nomad. Такі ж deploy.sh, назва вашага сэрвісу, і тое, куды вы хочаце яго задэплоіць. Гэта прыводзіць да таго, што ўсярэдзіне запускаецца helm. Ён у сваю чаргу збірае канфігі з шаблонаў, падстаўляе ў іх неабходныя values-файлы, затым дэплоіты, пускаючы іх у Kubernetes.

Высновы

Сэрвіс Kubernetes выглядае больш складаным, чым Nomad.

Тут выходны трафік прыходзіць у Ingress. Гэта як раз фронт-кантролер, які прымае на сябе ўсе запыты і пасля адпраўляе іх у адпаведныя дадзеным запыту сэрвісы. Вызначае ён іх на аснове канфігаў, якія з'яўляюцца часткай апісання вашага прыкладання ў helm і якія распрацоўшчыкі задаюць самастойна. Сэрвіс жа адпраўляе запыты на свае podы, гэта значыць пэўныя кантэйнеры, балансуючы ўваходны трафік паміж усімі кантэйнерамі, якія адносяцца да дадзенага сэрвісу. Ну і, вядома, не варта забываць пра тое, што ад бяспекі на ўзроўні сеткі мы нікуды не павінны сыходзіць. Таму ў кластары Kubernetes працуе сегментацыя, якая заснавана на тэгаванні. Усе сэрвісы маюць вызначаныя тэгі, да якіх прывязаныя правы доступаў сэрвісаў да тых ці іншых вонкавых/унутраных рэсурсаў усярэдзіне ці па-за кластарам.

Выконваючы пераход, мы ўбачылі, што Kubernetes валодае ўсімі магчымасцямі Nomad, які да гэтага мы выкарыстоўвалі, а таксама дадае шмат новага. Яго можна пашыраць праз убудовы, а па факце праз кастамныя тыпы рэсурсаў. Гэта значыць, у вас ёсць магчымасць не проста выкарыстоўваць нешта, што ідзе ў Kubernetes са скрынкі, а стварыць свой уласны рэсурс і сэрвіс, які будзе ваш рэсурс чытаць. Гэта дае дадатковыя магчымасці пашырэння вашай сістэмы без неабходнасці пераўсталёўкі Kubernetes і без неабходнасці змен.

Прыкладам такога выкарыстання з'яўляецца Prometheus, які запускаецца ў нас усярэдзіне кластара Kubernetes. Для таго каб ён пачаў збіраць метрыкі з таго ці іншага сэрвісу, нам трэба дадаць у апісанне сэрвісу дадатковы тып рэсурсу, так званы сэрвіс-манітор. Prometheus за кошт таго, што ўмее вычытваць, быўшы запушчаным у Kubernetes, кастамны тып рэсурсаў, аўтаматычна пачынае збіраць метрыкі з новай сістэмы. Гэта дастаткова зручна.

Першы дэплой, які мы зрабілі ў Kubernetes быў у сакавіку 2018 года. І за гэты час мы ніколі не адчувалі з ім ніякіх праблем. Ён дастаткова стабільна працуе без істотных багаў. Да таго ж, мы можам яго далей пашыраць. На сённяшні дзень нам хапае тых магчымасцей, якія ў ім ёсць, а тэмпы развіцця Kubernetes нам вельмі падабаюцца. На дадзены момант больш за 3000 кантэйнераў знаходзяцца ў Kubernetes. Кластар займае некалькі Node. Пры гэтым ён абслугоўваецца, стабільны і вельмі кантраляваны.

Крыніца: habr.com