На РИТ 2019 направио је наш колега Александар Коротков о аутоматизацији развоја у ЦИАН-у: да бисмо поједноставили живот и рад, користимо сопствену Интегро платформу. Прати животни циклус задатака, ослобађа програмере од рутинских операција и значајно смањује број грешака у производњи. У овом посту ћемо допунити Алекандеров извештај и рећи вам како смо прешли од једноставних скрипти до комбиновања производа отвореног кода преко наше сопствене платформе и шта ради наш одвојени тим за аутоматизацију.
Нулти ниво
„Не постоји нулти ниво, ја то не знам“
Мајстор Шифу из филма "Кунг Фу Панда"
Аутоматизација у ЦИАН-у је почела 14 година након оснивања компаније. Тада је у развојном тиму било 35 људи. Тешко је поверовати, зар не? Наравно, аутоматизација је постојала у неком облику, али посебан правац за континуирану интеграцију и испоруку кода почео је да се обликује 2015. године.
У то време, имали смо огроман монолит Питхон-а, Ц# и ПХП-а, распоређених на Линук/Виндовс серверима. Да бисмо применили ово чудовиште, имали смо скуп скрипти које смо покренули ручно. Постојала је и монтажа монолита, која је донела бол и патњу због сукоба приликом спајања грана, исправљања недостатака и поновне изградње „са другачијим скупом задатака у изградњи“. Поједностављени процес је изгледао овако:
Нисмо били задовољни овим и желели смо да направимо поновљив, аутоматизован и управљив процес изградње и примене. За ово нам је био потребан ЦИ/ЦД систем, а ми смо бирали између бесплатне верзије Теамцити-ја и бесплатне верзије Јенкинса, пошто смо радили са њима и обе су нам одговарале по скупу функција. Изабрали смо Теамцити као новији производ. У то време још нисмо користили микросервисну архитектуру и нисмо очекивали велики број задатака и пројеката.
Долазимо до идеје о сопственом систему
Имплементација Теамцити-а уклонила је само део ручног рада: оно што је преостало је креирање захтева за повлачење, промоција проблема по статусу у Јира-и и избор издања за објављивање. Теамцити систем више није могао да се носи са овим. Требало је изабрати пут даље аутоматизације. Размотрили смо опције за рад са скриптама у Теамцити-ју или прелазак на системе аутоматизације независних произвођача. Али на крају смо одлучили да нам је потребна максимална флексибилност, коју само наше сопствено решење може да обезбеди. Тако се појавила прва верзија система интерне аутоматизације под називом Интегро.
Теамцити се бави аутоматизацијом на нивоу покретања процеса изградње и имплементације, док се Интегро фокусирао на врхунску аутоматизацију развојних процеса. Било је неопходно комбиновати рад са проблемима у Јира са обрадом повезаног изворног кода у Битбуцкет-у. У овој фази, Интегро је почео да има сопствене токове рада за рад са задацима различитих типова.
Због повећања аутоматизације у пословним процесима, повећан је број пројеката и покрета у Теамцити-ју. Тако је дошао нови проблем: једна бесплатна Теамцити инстанца није била довољна (3 агента и 100 пројеката), додали смо још једну инстанцу (још 3 агента и 100 пројеката), па још једну. Као резултат тога, добили смо систем од неколико кластера, којим је било тешко управљати:
Када се поставило питање 4. инстанце, схватили смо да не можемо да наставимо овако да живимо, јер укупни трошкови издржавања 4 инстанце више нису били у границама. Поставило се питање о куповини плаћеног Теамцити-ја или одабиру бесплатног Јенкинса. Израчунали смо инстанце и планове аутоматизације и одлучили да живимо на Џенкинсу. После неколико недеља, прешли смо на Јенкинс и елиминисали неке главобоље повезане са одржавањем више Теамцити инстанци. Стога смо били у могућности да се фокусирамо на развој Интегра и прилагођавање Јенкинса за себе.
Са растом основне аутоматизације (у облику аутоматског креирања Пулл Рекуест-а, прикупљања и објављивања покривености кода и других провера), постоји снажна жеља да се што више напусти ручна издавања и да се овај посао препусти роботима. Поред тога, компанија је почела да прелази на микросервисе унутар компаније, што је захтевало честа издања, и одвојено једна од друге. Тако смо постепено дошли до аутоматских издања наших микросервиса (тренутно пуштамо монолит ручно због сложености процеса). Али, како то обично бива, настала је нова сложеност.
Аутоматизујемо тестирање
Због аутоматизације издања, процеси развоја су убрзани, делимично због прескакања неких фаза тестирања. И то је довело до привременог губитка квалитета. Звучи тривијално, али упоредо са убрзањем издања, било је потребно променити и методологију развоја производа. Требало је размишљати о аутоматизацији тестирања, убацивању личне одговорности (овде је реч о „прихватању идеје у главу“, а не о новчаним казнама) програмера за објављени код и грешке у њему, као и одлуку да се ослободити/не ослободити задатак путем аутоматског постављања.
Отклањајући проблеме са квалитетом, дошли смо до две важне одлуке: почели смо да спроводимо тестирање канаринца и увели аутоматско праћење позадине грешке са аутоматским одговором на њен вишак. Прво решење је омогућило проналажење очигледних грешака пре него што је код у потпуности пуштен у производњу, друго је смањило време одговора на проблеме у производњи. Грешке се, наравно, дешавају, али већину времена и труда трошимо не на њихово исправљање, већ на њихово минимизирање.
Тим за аутоматизацију
Тренутно имамо особље од 130 програмера и настављамо . Тим за континуирану интеграцију и испоруку кода (у даљем тексту Деплои анд Интегратион или ДИ тим) састоји се од 7 људи и ради у 2 правца: развој платформе за аутоматизацију Интегро и ДевОпс.
ДевОпс је одговоран за Дев/Бета окружење ЦИАН сајта, Интегро окружење, помаже програмерима да реше проблеме и развија нове приступе скалирању окружења. Интегро развојни правац бави се и самим Интегром и сродним услугама, на пример, додацима за Јенкинс, Јира, Цонфлуенце, а такође развија помоћне услужне програме и апликације за развојне тимове.
ДИ тим сарађује са тимом за платформу, који интерно развија архитектуру, библиотеке и развојне приступе. У исто време, сваки програмер унутар ЦИАН-а може допринети аутоматизацији, на пример, направити микро-аутоматизацију која одговара потребама тима или поделити сјајну идеју о томе како да аутоматизацију учини још бољом.
Лаиер цаке оф аутоматион ат ЦИАН
Сви системи укључени у аутоматизацију могу се поделити у неколико слојева:
- Екстерни системи (Јира, Битбуцкет, итд.). Са њима раде развојни тимови.
- Интегро платформа. Најчешће програмери не раде са њим директно, али то је оно што одржава сву аутоматизацију.
- Услуге испоруке, оркестрације и откривања (на пример, Јекнинс, Цонсул, Номад). Уз њихову помоћ, постављамо код на сервере и осигуравамо да сервиси раде једни са другима.
- Физички слој (сервери, ОС, повезани софтвер). Наш код функционише на овом нивоу. Ово може бити физички или виртуелни сервер (ЛКСЦ, КВМ, Доцкер).
На основу овог концепта, делимо области одговорности унутар ДИ тима. Прва два нивоа су у области одговорности Интегро развојног правца, а последња два нивоа су већ у области одговорности ДевОпс-а. Ово раздвајање нам омогућава да се фокусирамо на задатке и не омета интеракцију, јер смо блиски једни другима и стално размењујемо знање и искуство.
Нетакнут
Хајде да се фокусирамо на Интегро и почнемо са технолошком стеком:
- ЦентОС 7
- Доцкер + Номад + Цонсул + Ваулт
- Јава 11 (стари Интегро монолит ће остати на Јави 8)
- Спринг Боот 2.Кс + Спринг Цлоуд Цонфиг
- ПостгреСкл 11
- РаббитМК
- Апацхе Игните
- Цамунда (уграђено)
- Графана + Графит + Прометеј + Јегер + ЕЛК
- Веб кориснички интерфејс: Реацт (ЦСР) + МобКс
- ССО: Кеицлоак
Придржавамо се принципа развоја микросервиса, иако имамо наслеђе у виду монолита ране верзије Интегра. Сваки микросервис ради у сопственом Доцкер контејнеру, а услуге комуницирају једна са другом преко ХТТП захтева и РаббитМК порука. Микросервисе проналазе једна другу преко Цонсула и упућују му захтев, пропуштајући ауторизацију преко ССО (Кеицлоак, ОАутх 2/ОпенИД Цоннецт).
Као пример из стварног живота, размотрите интеракцију са Џенкинсом, која се састоји од следећих корака:
- Микросервис за управљање токовима посла (у даљем тексту микросервис Флов) жели да покрене изградњу у Џенкинсу. Да би то урадио, он користи Цонсул да пронађе ИП:ПОРТ микросервиса за интеграцију са Џенкинсом (у даљем тексту Џенкинс микросервис) и шаље му асинхрони захтев за покретање изградње у Џенкинсу.
- Након што прими захтев, Џенкинс микросервис генерише и одговара са ИД-ом посла, који се затим може користити за идентификацију резултата рада. Истовремено, покреће изградњу у Џенкинсу преко РЕСТ АПИ позива.
- Џенкинс врши изградњу и, након завршетка, шаље веб-хук са резултатима извршења у Џенкинс микросервис.
- Јенкинс микросервис, након што је примио веб-хук, генерише поруку о завршетку обраде захтева и прилаже јој резултате извршења. Генерисана порука се шаље у ред РаббитМК.
- Преко РаббитМК-а, објављена порука стиже до микросервиса Флов, који сазнаје о резултату обраде свог задатка упарујући ИД посла из захтева и примљене поруке.
Сада имамо око 30 микросервиса, које се могу поделити у неколико група:
- Управљање конфигурацијом.
- Информације и интеракција са корисницима (месинџери, пошта).
- Рад са изворним кодом.
- Интеграција са алатима за имплементацију (јенкинс, номад, конзул, итд.).
- Надгледање (објаве, грешке, итд.).
- Веб услужни програми (УИ за управљање тест окружењима, прикупљање статистике, итд.).
- Интеграција са таск трацкерима и сличним системима.
- Управљање токовима рада за различите задатке.
Задаци тока посла
Интегро аутоматизује активности везане за животни циклус задатка. Поједностављено речено, животни циклус задатка ће се разумети као ток посла задатка у Јира. Наши развојни процеси имају неколико варијација тока посла у зависности од пројекта, типа задатка и опција изабраних у одређеном задатку.
Погледајмо ток посла који најчешће користимо:
На дијаграму, зупчаник означава да Интегро аутоматски позива прелаз, док људска фигура означава да транзицију позива особа ручно. Хајде да погледамо неколико путања којима задатак може да иде у овом току посла.
Потпуно ручно тестирање на ДЕВ+БЕТА без канаринских тестова (обично овако ослобађамо монолит):
Можда постоје и друге комбинације прелаза. Понекад се путања којом ће проблем ићи може бити изабран преко опција у Јира.
Кретање задатака
Хајде да погледамо главне кораке који се изводе када се задатак креће кроз ток посла „ДЕВ тестирање + Канарски тестови“:
1. Програмер или ПМ креира задатак.
2. Програмер преузима задатак да ради. Након завршетка, прелази у статус У ПРЕГЛЕДУ.
3. Јира шаље Вебхоок у Јира микросервис (одговоран за интеграцију са Јира).
4. Јира микросервис шаље захтев услузи Флов (одговорној за интерне токове посла у којима се рад обавља) да покрене ток посла.
5. Унутар услуге Флов:
- Рецензенти су додељени задатку (Микросервис корисника који зна све о корисницима + Јира микросервис).
- Преко изворног микросервиса (зна за спремишта и гране, али не ради са самим кодом), врши се претрага за спремиштима која садрже грану нашег издања (да бисмо поједноставили претрагу, назив гране се поклапа са издањем број у Ћира). Најчешће, задатак има само једну грану у једном спремишту; ово поједностављује управљање редом за имплементацију и смањује повезаност између спремишта.
- За сваку пронађену грану врши се следећи редослед радњи:
и) Ажурирање главне гране (Гит микросервис за рад са кодом).
ии) Грана је блокирана од промена од стране програмера (Битбуцкет микросервис).
иии) Захтев за повлачењем је креиран за ову грану (Битбуцкет микросервис).
ив) Порука о новом захтеву за повлачење се шаље у ћаскања програмера (Обавести микросервис за рад са обавештењима).
в) Задаци изградње, тестирања и примене се покрећу на ДЕВ-у (Јенкинс микросервис за рад са Џенкинсом).
ви) Ако су сви претходни кораци успешно завршени, онда Интегро ставља одобрење у захтев за повлачење (Битбуцкет микросервис). - Интегро чека одобрење у захтеву за повлачење од одређених рецензената.
- Чим добију сва потребна одобрења (укључујући и аутоматизоване тестове који су прошли позитивно), Интегро преноси задатак у статус Тест он Дев (Јира микросервис).
6. Тестери тестирају задатак. Ако нема проблема, задатак се преноси у статус Реади Фор Буилд.
7. Интегро „види“ да је задатак спреман за ослобађање и почиње да се примењује у канарском режиму (Јенкинс микросервис). Спремност за пуштање је одређена скупом правила. На пример, задатак је у траженом статусу, нема закључавања других задатака, тренутно нема активних отпремања овог микросервиса итд.
8. Задатак се преноси у статус Цанари (Јира микросервис).
9. Џенкинс покреће задатак постављања преко Номада у канарском режиму (обично 1-3 инстанце) и обавештава сервис за праћење издања (микросервис ДеплоиВатцх) о примени.
10. Микросервис ДеплоиВатцх прикупља позадину грешке и реагује на њу, ако је потребно. Ако је позадина грешке прекорачена (норма позадине се израчунава аутоматски), програмери се обавештавају преко микросервиса Нотифи. Ако програмер није одговорио након 5 минута (кликнуо на Врати или Остани), покреће се аутоматско враћање инстанци канарца. Ако позадина није прекорачена, програмер мора ручно покренути примену задатка у производњи (кликом на дугме у корисничком интерфејсу). Ако у року од 60 минута програмер није покренуо примену у продукцији, онда ће инстанце цанари такође бити враћене из безбедносних разлога.
11. Након покретања имплементације у производњу:
- Задатак се преноси у статус производње (Јира микросервис).
- Јенкинс микросервис покреће процес постављања и обавештава микросервис ДеплоиВатцх о примени.
- Микросервис ДеплоиВатцх проверава да ли су сви контејнери у продукцији ажурирани (било је случајева када нису сви ажурирани).
- Преко Нотифи микросервиса, обавештење о резултатима имплементације се шаље у производњу.
12. Програмери ће имати 30 минута да почну да враћају задатак из продукције ако се открије погрешно понашање микросервиса. Након овог времена, задатак ће се аутоматски спојити у мастер (Гит микросервис).
13. Након успешног спајања у мастер, статус задатка ће бити промењен у Затворен (Јира микросервис).
Дијаграм не претендује да буде потпуно детаљан (у стварности има још више корака), али вам омогућава да процените степен интеграције у процесе. Не сматрамо ову шему идеалном и побољшавамо процесе подршке за аутоматско ослобађање и имплементацију.
Шта је следеће
Имамо велике планове за развој аутоматизације, на пример, елиминисање ручних операција током монолитних издања, побољшање надгледања током аутоматског постављања и побољшање интеракције са програмерима.
Али хајде да се за сада зауставимо овде. Многе теме смо у прегледу аутоматизације покрили површно, неке се уопште нису дотицале, па ћемо радо одговарати на питања. Чекамо предлоге о томе шта да покријемо детаљно, напишите у коментарима.
Извор: ввв.хабр.цом