Док радите у ИТ-у, почињете да примећујете да системи имају свој карактер. Могу бити флексибилни, тихи, ексцентрични и строги. Могу да привлаче или одбијају. На овај или онај начин, са њима морате „преговарати“, маневрисати између „замки“ и градити ланце њихове интеракције.
Тако смо имали част да изградимо платформу у облаку, а за ово смо морали да „убедимо“ неколико подсистема да раде са нама. На срећу, имамо „АПИ језик“, директне руке и пуно ентузијазма.
Овај чланак неће бити технички тежак, али ће описати проблеме на које смо наишли приликом изградње облака. Одлучио сам да опишем наш пут у облику лаке техничке фантазије о томе како смо тражили заједнички језик са системима и шта је из тога произашло.
Добродошли у мачку.
Почетак путовање
Пре извесног времена, наш тим је добио задатак да покрене клауд платформу за наше клијенте. Имали смо подршку менаџмента, ресурсе, хардверски стог и слободу у избору технологија за имплементацију софтверског дела услуге.
Постојао је и низ захтева:
- за услугу је потребан згодан лични налог;
- платформа мора бити интегрисана у постојећи систем наплате;
- софтвер и хардвер: ОпенСтацк + Тунгстен Фабриц (Опен Цонтраил), који су наши инжењери научили да "кувају" прилично добро.
Рећи ћемо вам други пут о томе како је тим састављен, развијен интерфејс личног налога и донете одлуке о дизајну, ако је Хабра заједница заинтересована.
Алати које смо одлучили да користимо:
- Питхон + Фласк + Сваггер + СКЛАлцхеми - потпуно стандардни Питхон сет;
- Вуе.јс за фронтенд;
- Одлучили смо да направимо интеракцију између компоненти и услуга користећи Целери преко АМКП-а.
Очекујући питања о избору Питхона, објаснићу. Језик је нашао своју нишу у нашем друштву и око њега се развила мала, али ипак култура. Стога је одлучено да се на њему почне градити сервис. Штавише, брзина развоја таквих проблема је често одлучујућа.
Дакле, почнимо наше познанство.
Тихи рачун - наплата
Познајемо овог момка дуго времена. Увек је седео поред мене и немо нешто бројао. Понекад нам је прослеђивао корисничке захтеве, издавао рачуне клијентима и управљао услугама. Обичан вредан момак. Истина, било је потешкоћа. Ћути, понекад замишљен и често самосталан.
Наплата је први систем са којим смо покушали да се спријатељимо. А прва потешкоћа на коју смо наишли била је приликом обраде услуга.
На пример, када се креира или избрише, задатак иде у интерни ред за обрачун. Тако је имплементиран систем асинхроног рада са сервисима. Да бисмо обрадили наше типове услуга, морали смо да „ставимо“ своје задатке у овај ред. И ту смо наишли на проблем: недостатак документације.
Судећи по опису софтверског АПИ-ја, још увек је могуће решити овај проблем, али нисмо имали времена да урадимо обрнути инжењеринг, па смо изнели логику напоље и организовали ред задатака на врху РаббитМК-а. Операцију на сервису покреће клијент са свог личног налога, претвара се у Целери „задатак“ на бацкенд-у и обавља се на страни наплате и ОпенСтацк-а. Целер чини прилично погодним за управљање задацима, организовање понављања и праћење статуса. Можете прочитати више о "целеру", нпр. .
Такође, наплата није зауставила пројекат који је остао без новца. У комуникацији са програмерима, открили смо да приликом израчунавања статистике (а треба да применимо управо овакву логику) постоји сложена међусобна повезаност правила заустављања. Али ови модели се не уклапају добро у нашу стварност. Такође смо га имплементирали кроз задатке на Целери-у, одводећи логику управљања услугама на позадину.
Оба горе наведена проблема довела су до тога да је код постао мало надуван и у будућности ћемо морати да рефакторишемо како бисмо логику за рад са задацима преместили у посебан сервис. Такође морамо да ускладиштимо неке информације о корисницима и њиховим услугама у нашим табелама да бисмо подржали ову логику.
Други проблем је тишина.
Били тихо одговара „У реду“ на неке АПИ захтеве. То је био случај, на пример, када смо извршили исплате обећаних плаћања током теста (више о томе касније). Захтеви су исправно извршени и нисмо видели грешке.
Морао сам да проучавам евиденције док сам радио са системом преко корисничког интерфејса. Испоставило се да сама наплата извршава сличне захтеве, мењајући опсег на одређеног корисника, на пример, администратора, прослеђујући га у параметру су.
Генерално, упркос празнинама у документацији и мањим недостацима АПИ-ја, све је прошло прилично добро. Дневници се могу читати чак и под великим оптерећењем ако разумете како су структурирани и шта да тражите. Структура базе података је китњаста, али сасвим логична и на неки начин чак и атрактивна.
Дакле, да резимирамо, главни проблеми на које смо наишли у фази интеракције односе се на карактеристике имплементације одређеног система:
- недокументоване „карактеристике“ које су утицале на нас на овај или онај начин;
- затвореног кода (наплата је написана у Ц++), као резултат - немогуће је решити проблем 1 на било који други начин осим „покушајем и грешком“.
На срећу, производ има прилично обиман АПИ и интегрисали смо следеће подсистеме у наш лични налог:
- модул техничке подршке - захтеви са вашег личног налога су „прокси“ за транспарентно наплату за клијенте услуге;
- финансијски модул - омогућава вам да испостављате рачуне тренутним клијентима, вршите отписе и генеришете документе за плаћање;
- сервисни контролни модул - за ово смо морали да имплементирамо сопствени руковалац. Проширивост система нам је ишла на руку и „научили“ смо Билија новој врсти услуге.
Било је то мало муке, али на овај или онај начин, мислим да ћемо се Били и ја слагати.
Шетња по пољима волфрама - Тунгстен Фабриц
Поља волфрама прошарана стотинама жица, пролазећи кроз њих хиљаде битова информација. Информације се прикупљају у „пакете“, рашчлањују, граде сложене руте, као магијом.
Ово је домен другог система са којим смо морали да се спријатељимо - Тунгстен Фабриц (ТФ), раније ОпенЦонтраил. Његов задатак је да управља мрежном опремом, пружајући апстракцију софтвера нама као корисницима. ТФ - СДН, обухвата сложену логику рада са мрежном опремом. Постоји добар чланак о самој технологији, нпр. .
Систем је интегрисан са ОпенСтацк-ом (о коме се говори у наставку) преко Неутрон додатка.
Интеракција ОпенСтацк сервиса.
Са овим системом су нас упознали момци из оперативног одељења. Користимо системски АПИ за управљање мрежним стеком наших услуга. То нам још није изазвало озбиљне проблеме или непријатности (не могу да говорим у име момака из ОЕ), али је било неких необичности у интеракцији.
Први је изгледао овако: команде које су захтевале излаз велике количине података на конзолу инстанце при повезивању преко ССХ-а једноставно су „опустиле” везу, док је преко ВНЦ-а све функционисало како треба.
За оне који нису упознати са проблемом, то изгледа прилично смешно: лс /роот ради исправно, док се, на пример, врх потпуно „замрзава“. Срећом, већ смо се сусрели са сличним проблемима. Одлучено је подешавањем МТУ-а на рути од рачунарских чворова до рутера. Узгред, ово није ТФ проблем.
Следећи проблем је био иза угла. У једном „лепом“ тренутку, магија рутирања је нестала, тек тако. ТФ је престао да управља рутирањем на опреми.
Са Опенстацк-ом смо радили од администраторског нивоа и након тога прешли на потребан кориснички ниво. Чини се да СДН „отима“ опсег корисника који извршавају радње. Чињеница је да се исти администраторски налог користи за повезивање ТФ-а и ОпенСтацк-а. У кораку преласка на корисника, „магија“ је нестала. Одлучено је да се направи посебан налог за рад са системом. Ово нам је омогућило да радимо без нарушавања функционалности интеграције.
Силиконски облици живота - ОпенСтацк
Силиконско створење бизарног облика живи у близини волфрамових поља. Највише личи на прерасло дете које може да нас згњечи једним замахом, али од њега нема очигледне агресије. Не изазива страх, али његова величина изазива страх. Као и сложеност онога што се дешава около.
ОпенСтацк је срж наше платформе.
ОпенСтацк има неколико подсистема, од којих тренутно најактивније користимо Нова, Гланце и Циндер. Сваки од њих има свој АПИ. Нова је одговорна за рачунарске ресурсе и креирање инстанци, Циндер је одговоран за управљање волуменима и њиховим снимцима, Гланце је услуга слика која управља ОС шаблонима и метаинформацијама о њима.
Свака услуга ради у контејнеру, а посредник порука је „бели зец“ - РаббитМК.
Овај систем нам је задао најнеочекиваније невоље.
И први проблем није дуго чекао када смо покушали да повежемо додатни волумен на сервер. Циндер АПИ је глатко одбио да изврши овај задатак. Тачније, ако верујете самом ОпенСтацк-у, веза је успостављена, али нема диск уређаја унутар виртуелног сервера.
Одлучили смо да скренемо и затражили исту акцију од Нова АПИ-ја. Резултат је да се уређај исправно повезује и да је доступан унутар сервера. Чини се да се проблем јавља када блоцк-стораге не реагује на Циндер.
При раду са дисковима чекала нас је још једна потешкоћа. Системски волумен није могао да се искључи са сервера.
Опет, сам ОпенСтацк се „куне“ да је уништио везу и сада можете исправно радити са волуменом одвојено. Али АПИ категорички није желео да обавља операције на диску.
Овде смо одлучили да се не свађамо посебно, већ да променимо поглед на логику сервиса. Ако постоји инстанца, мора постојати и системски волумен. Стога, корисник још не може уклонити или онемогућити системски „диск“ без брисања „сервера“.
ОпенСтацк је прилично сложен скуп система са сопственом логиком интеракције и украшеним АПИ-јем. Помаже нам прилично детаљна документација и, наравно, покушаји и грешке (где бисмо били без тога).
Тест рун
Извели смо пробно лансирање у децембру прошле године. Главни задатак је био да тестирамо наш пројекат у борбеном режиму са техничке стране и са стране УКС. Публика је позвана селективно и тестирање је затворено. Међутим, такође смо оставили опцију да затражимо приступ тестирању на нашој веб страници.
Сам тест, наравно, није прошао без смешних момената, јер ту наше авантуре тек почињу.
Прво, донекле смо погрешно проценили интересовање за пројекат и морали смо брзо да додамо рачунарске чворове управо током теста. Уобичајен случај за кластер, али и овде је било неких нијанси. Документација за одређену верзију ТФ-а указује на конкретну верзију кернела на којој је тестиран рад са вРоутером. Одлучили смо да покренемо чворове са новијим језгром. Као резултат тога, ТФ није примио руте од чворова. Морао сам хитно да вратим језгра.
Још једна занимљивост је везана за функционалност дугмета „промени лозинку“ на вашем личном налогу.
Одлучили смо да користимо ЈВТ да организујемо приступ нашем личном налогу како не бисмо радили са сесијама. Пошто су системи разноврсни и широко расути, ми управљамо сопственим токеном, у који „премотавамо“ сесије од наплате и токена из ОпенСтацк-а. Када се лозинка промени, токен се, наравно, „поквари“, пошто кориснички подаци више не важе и треба их поново издати.
Изгубили смо из вида ову тачку и једноставно није било довољно ресурса да брзо завршимо овај комад. Морали смо да искључимо функционалност непосредно пре покретања теста.
Тренутно одјављујемо корисника ако је лозинка промењена.
Упркос овим нијансама, тестирање је прошло добро. За пар недеља свратило је око 300 људи. Успели смо да погледамо производ очима корисника, тестирамо га на делу и прикупимо висококвалитетне повратне информације.
Наставиће се
За многе од нас ово је први пројекат оваквог обима. Научили смо низ вредних лекција о томе како радити као тим и доносити архитектонске и дизајнерске одлуке. Како интегрисати сложене системе са мало ресурса и увести их у производњу.
Наравно, има на чему да се ради и у погледу кода и на интерфејсима системске интеграције. Пројекат је прилично млад, али смо пуни амбиција да га прерасте у поуздан и практичан сервис.
Већ смо успели да убедимо системе. Бил у свом ормару савесно управља бројањем, наплатом и захтевима корисника. „Магија“ волфрамових поља нам омогућава стабилну комуникацију. И само ОпенСтацк понекад постане хировит, вичући нешто попут „'ВСРЕП још увек није припремио чвор за употребу у апликацији. Али то је сасвим друга прича...
Недавно смо покренули услугу.
Све детаље можете сазнати на нашој .
ЦЛО развојни тим
Корисни линкови
ОпенСтацк
Тунгстен Фабриц
Извор: ввв.хабр.цом