З ростам стажу працы ў ІТ пачынаеш заўважаць, што сістэмы маюць свой характар. Яны могуць быць рахманымі, маўклівымі, шалапутнымі, суровымі. Могуць размяшчаць да сябе ці адштурхваць. Так ці інакш, даводзіцца "дамаўляцца" з імі, лавіраваць паміж "падводнымі камянямі" і выбудоўваць ланцужкі іх узаемадзеяння.
Вось і нам выпаў гонар пабудаваць хмарную платформу, а для гэтага запатрабавалася «ўгаварыць» пару падсістэм працаваць з намі. Балазе, у нас ёсць «мова API», прамыя рукі і куча запалу.
У гэтым артыкуле не будзе тэхнічнага хардкора, але будзе апісанне праблем, з якімі мы сутыкнуліся пры пабудове аблокі. Я вырашыў апісаць наш шлях у выглядзе лёгкай тэхнічнай фантазіі аб тым, як мы шукалі агульную мову з сістэмамі і што з гэтага выйшла.
Сардэчна запрашаем пад кат.
Пачатак шляху
Некаторы час таму перад нашай камандай была пастаўлена задача - запусціць хмарную платформу для нашых кліентаў. У нашым распараджэнні была падтрымка кіраўніцтва, рэсурсы, апаратны стэк і свабода ў выбары тэхналогій для рэалізацыі праграмнай часткі сэрвісу.
Быў таксама і шэраг патрабаванняў:
- сэрвісу патрэбен зручны асабісты кабінет;
- платформа павінна быць інтэграваная ў існуючую сістэму білінгу;
- праграмна-апаратная частка: OpenStack + Tungsten Fabric (Open Contrail), якія нашы інжынеры навучыліся дастаткова добра "рыхтаваць".
Пра тое, як збіралася каманда, распрацоўваўся інтэрфейс асабістага кабінета і прымаліся дызайнерскія рашэнні, раскажам у іншы раз, калі ў хабра-супольнасці будзе цікавасць.
Інструменты, якія мы вырашылі выкарыстоўваць:
- Python + Flask + Swagger + SQLAlchemy - цалкам стандартны Python набор;
- Vue.js для франтэнда;
- узаемадзеянне паміж кампанентамі і сэрвісамі вырашылі рабіць з дапамогай Celery па-над AMQP.
Апярэджваючы пытанні аб выбары ў бок Python, растлумачу. Мова заняла сваю нішу ў нашай кампаніі і вакол яго склалася невялікая, але ўсё ж культура. Таму было вырашана пачынаць будаваць сервіс менавіта на ім. Тым больш, што хуткасць распрацоўкі ў такіх задачах часта вырашае.
Такім чынам, пачнем наша знаёмства.
Маўклівы Біл - білінг
З гэтым хлопцам мы былі знаёмыя даўно. Ён заўсёды сядзеў побач і нешта моўчкі лічыў. Часам перапраўляў нам запыты карыстальнікаў, выстаўляў кліенцкія рахункі, кіраваў паслугамі. Звычайны працавіты хлопец. Праўда, былі цяжкасці. Ён маўклівы, часам задуменны і часта сабе на розуме.
Білінг - гэта першая сістэма, з якой мы паспрабавалі пасябраваць. І першая ж цяжкасць сустрэлася нам пры апрацоўцы паслуг.
Напрыклад, пры стварэнні ці выдаленні, задача пападае ва ўнутраную чаргу білінгу. Такім чынам рэалізавана сістэма асінхроннай працы з паслугамі. Для апрацоўкі сваіх тыпаў паслуг нам трэба было "складаць" свае задачы ў гэтую чаргу. І тут мы сутыкнуліся з праблемай: недахоп дакумэнтацыі.
Мяркуючы па апісанні праграмнага API, вырашыць гэтую задачу ўсё ж можна, але часу займацца рэверс-інжынірынгам у нас не было, таму мы вынеслі логіку вонкі і арганізавалі чаргу задач па-над RabbitMQ. Аперацыя над паслугай ініцыюецца кліентам з асабістага кабінета, абарочваецца ў «задачу» Celery на бэкендзе і выконваецца на баку білінгу і OpenStack'a. Celery дазваляе дастаткова зручна кіраваць задачамі, арганізоўваць паўторы і сачыць за станам. Падрабязней пра «салера» можна пачытаць, напрыклад, .
Таксама білінг не спыняў праект, на якім скончыліся грошы. Размаўляючы з распрацоўшчыкамі, мы высветлілі, што пры падліку па статыстыцы (а нам трэба рэалізаваць менавіта такую логіку) ёсць складаная ўзаемасувязь правілаў прыпынку. Але гэтыя мадэлі дрэнна кладуцца пад нашы рэаліі. Таксама рэалізавалі праз задачы на Celery, забіраючы на бок бэкенда логіку кіравання паслугамі.
Абедзве вышэйзгаданыя праблемы прывялі да таго, што код крыху надзьмуўся і нам у будучыні давядзецца заняцца рэфактарынгам, каб вынесці ў асобны сэрвіс логіку працы з задачамі. Нам таксама трэба захоўваць частку інфармацыі аб карыстальніках і іх паслугах у сваіх табліцах, каб падтрымліваць гэтую логіку.
Яшчэ адна праблема - маўклівасць.
На частку запытаў да API Білі моўчкі адказвае "Ок". Так, напрыклад, было, калі мы рабілі залічэнні абяцаных плацяжоў на час тэсту (пра яго пазней). Запыты карэктна выконваліся і мы не бачылі памылак.
Прыйшлося вывучаць логі, працуючы з сістэмай праз UI. Аказалася, што сам білінг выконвае падобныя запыты, змяняючы scope на канкрэтнага карыстальніка, напрыклад, admin, перадаючы яго ў параметры su.
У цэлым, нягледзячы на прабелы ў дакументацыі і невялікія агрэхі API, усё прайшло дастаткова нядрэнна. Логі цалкам можна чытаць нават пры вялікай нагрузцы, калі разумець, як яны ўладкованыя і што трэба шукаць. Структура базы дадзеных мудрагелістая, але цалкам лагічная і ў чымсьці нават прывабная.
Такім чынам, падводзячы вынікі, асноўныя праблемы, якія ў нас узніклі на этапе ўзаемадзеяння, звязаны з асаблівасцямі рэалізацыі канкрэтнай сістэмы:
- недакументаваныя "фічы", якія так ці інакш нас закраналі;
- зачыненыя зыходнікі (білінг напісаны на C++), як следства - немагчымасць вырашыць праблему 1 ніяк, акрамя «метаду спроб і памылак».
На шчасце, у прадукта ёсць досыць раскідзісты API і мы інтэгравалі ў свой асабісты кабінет наступныя падсістэмы:
- модуль тэхнічнай падтрымкі - запыты з асабістага кабінета «праксіруюцца» ў білінг празрыста для кліентаў сэрвісу;
- фінансавы модуль - дазваляе выстаўляць рахункі бягучым кліентам, рабіць спісанні і фарміраваць плацежныя дакументы;
- модуль кіравання паслугамі - для яго нам прыйшлося рэалізаваць свой апрацоўшчык. Пашыральнасць сістэмы згуляла нам на руку і мы "навучылі" Білі новаму тыпу паслуг.
Давялося павазіцца, але так ці інакш, думаю, з Білі мы зладзім.
Прагулкі па вальфрамавых палях - Tungsten Fabric
Вальфрамавыя палі, усеяныя сотняй правадоў, якія праганяюць праз сябе тысячы біт інфармацыі. Інфармацыя збіраецца ў "пакеты", разбіраецца, выбудоўваючы складаныя маршруты, як па чараўніцтве.
Гэта вотчына другой сістэмы, з якой нам прыйшлося пасябраваць – Tungsten Fabric (TF), былы OpenContrail. Яе задача - кіраваць сеткавым абсталяваннем, падаючы праграмную абстракцыю нам, як карыстальнікам. TF - SDN, інкапсулюе ў сабе складаную логіку працы з сеткавым абсталяваннем. Пра саму тэхналогію ёсць нядрэнны артыкул, напрыклад, .
Сістэма інтэграваная з OpenStack (пра яго гаворка пойдзе ніжэй) праз убудову Neutron'a.
Узаемадзеянне сэрвісаў OpenStack.
З гэтай сістэмай нас пазнаёмілі хлопцы з аддзела эксплуатацыі. Мы выкарыстоўваем API сістэмы для кіравання сеткавым стэкам нашых паслуг. Сур'ёзных праблем ці нязручнасцяў яна нам пакуль не дастаўляе (за рабят з ОЭ казаць не вазьмуся), аднак былі і некаторыя кур'ёзы ўзаемадзеяння.
Першы выглядаў так: каманды, патрабавальныя высновы вялікай колькасці дадзеных на кансоль інстанса пры падлучэнні па SSH проста вешалі падлучэнне, пры гэтым па VNC усё працавала карэктна.
Для тых, хто не знаёмы з праблемай, гэта выглядае досыць пацешна: ls /root адпрацоўвае карэктна, тады як, напрыклад, top завісае наглуха. На шчасце, мы ўжо сутыкаліся з такімі праблемамі. Вырашылася цюнінгам MTU на маршруце ад compute-нод да маршрутызатараў. Дарэчы сказаць, гэта і не праблема TF.
Наступная праблема чакала за паваротам. У адзін "цудоўны" момант магія маршрутызацыі знікла, вось так проста. TF перастаў кіраваць маршрутызацыяй на абсталяванні.
Мы працавалі з Openstack з узроўня admin і пасля гэтага пераходзілі на ўзровень патрэбнага карыстача. SDN, падобна, "перахапляе" скоуп карыстальніка, якім выконваюцца дзеянні. Справа ў тым, што гэты ж адмінскі акаўнт выкарыстоўваецца для сувязі TF і OpenStack. На кроку пераключэння пад карыстача "магія" знікала. Вырашана было завесці асобны акаўнт для працы з сістэмай. Гэта дазволіла працаваць, не ламаючы функцыянал інтэграцыі.
Сіліконавыя формы жыцця - OpenStack
Сіліконавая істота мудрагелістай формы насяляе недалёка ад вальфрамавых палёў. Больш за ўсё яно падобнае на дзіця пераростка, які адным узмахам можа раздушыць нас, але відавочнай агрэсіі ад яго не зыходзіць. Яно не выклікае страху, але яго памеры выклікаюць асцярогу. Як і складанасць таго, што адбываецца навокал.
OpenStack - ядро нашай платформы.
OpenStack мае некалькі падсістэм, з якіх больш актыўна мы пакуль выкарыстоўваем Nova, Glance і Cinder. Кожная з іх мае свой API. Nova адказвае за compute-рэсурсы і стварэнне instance'ов, Cinder – кіраванне volume'амі і іх здымкамі, Glance – image service, які кіруе шаблонамі АС і метаінфармацыяй па іх.
Кожны сэрвіс запускаецца ў кантэйнеры, а брокерам паведамленняў выступае «белы трусік» – RabbitMQ.
Гэтая сістэма даставіла нам больш за ўсё нечаканых клопатаў.
І першая праблема не прымусіла сябе чакаць, калі мы спрабавалі далучыць дадатковы volume да сервера. Cinder API наадрэз адмаўляўся выконваць гэтую задачу. Дакладней, калі верыць самому OpenStack'у сувязь усталёўваецца, аднак усярэдзіне віртуальнага сервера прылада дыска адсутнічае.
Мы вырашылі пайсці ў абыход і запыталі тое ж дзеянне ў Nova API. Вынік - прылада карэктна падключаецца і даступна ўнутры сервера. Падобна, што праблема ўзнікае, калі block-storage не адказвае Cinder'у.
Чарговая складанасць чакала нас пры працы з кружэлкамі. Сістэмны volume не ўдавалася адлучыць ад сервера.
Ізноў жа, сам OpenStack "бажыцца", што сувязь ён знішчыў і зараз можна карэктна працаваць з volume'ам асобна. Але API катэгарычна не жадаў рабіць аперацыі над дыскам.
Тут мы вырашылі асабліва не ваяваць, а змяніць погляд на логіку працы сервісу. Калі ёсць instance, павінен быць і сістэмны volume. Таму карыстач пакуль не можа выдаліць або адключыць сістэмны "дыск", не выдаліўшы "сервер".
OpenStack – досыць складаны комплекс сістэм са сваёй логікай узаемадзеяння і мудрагелістым API. Нас выбаўляе дастаткова падрабязная дакументацыя і, вядома, метад спроб і памылак (куды ж без яго).
Тэставы запуск
Тэставы запуск мы праводзілі ў снежні мінулага года. Асноўнай задачай ставілі праверку ў баявым рэжыме нашага праекту з тэхнічнага боку і з боку UX. Аўдыторыю запрашалі выбарачна і тэсціраванне было закрытым. Аднак мы таксама пакінулі магчымасць запытаць доступ да тэсціравання на нашым сайце.
Сам тэст, зразумела, не абышоўся без кур'ёзных момантаў, бо на гэтым нашыя прыгоды толькі пачынаюцца.
Па-першае, мы некалькі некарэктна ацанілі цікавасць да праекту і прыйшлося аператыўна дадаваць compute-ноды прама падчас тэсту. Звычайны кейс для кластара, аднак і тут былі нюансы. У дакументацыі для канкрэтнай версіі TF указана канкрэтная версія ядра, на якім тэсціравалі праца з vRouter. Мы вырашылі запускаць ноды з свежымі ядрамі. Як вынік - TF не атрымаў маршруты з нод. Прыйшлося экстрана адкочваць ядры.
Іншы кур'ёз звязаны з функцыяналам кнопкі "змяніць пароль" у асабістым кабінеце.
Мы вырашылі выкарыстоўваць JWT для арганізацыі доступу ў асабісты кабінет, каб не працаваць з сесіямі. Бо сістэмы разнапланавыя і шырока раскіданыя, мы кіруем сваім токенам, у які "заварочваем" сесіі ад білінгу і токен ад OpenStack'a. Пры змене пароля токен, зразумела, "пратухае", паколькі дадзеныя карыстальніка ўжо невалідныя і яго трэба перавыпускаць.
Мы выпусцілі гэты момант з-пад увагі, а рэсурсаў, каб хутка дапісаць гэты кавалак, банальна не хапіла. Нам прыйшлося выразаць функцыянал перад самым запускам у тэст.
На дадзены момант мы выконваем logout карыстальніка, калі пароль быў зменены.
Нягледзячы на гэтыя нюансы, тэсціраванне прайшло добра. За пару тыдняў да нас зазірнула каля 300 чалавек. Нам удалося паглядзець на прадукт вачыма карыстальнікаў, пратэставаць яго ў баі і сабраць якасны фідбэк.
Працяг варта
Для многіх з нас гэта першы праект такога маштабу. Мы вынеслі шэраг каштоўных урокаў аб тым, як працаваць у камандзе, прымаць архітэктурныя і дызайнерскія рашэнні. Як з невялікімі рэсурсамі інтэграваць складаныя сістэмы і выкочваць іх у прадакшн.
Зразумела, ёсць над чым папрацаваць і ў плане кода, і на стыках інтэграцыі сістэм. Праект дастаткова малады, але мы поўныя амбіцый вырасціць з яго надзейны і зручны сэрвіс.
Сістэмы мы ўжо змаглі ўгаварыць. Біл паслухмяна займаецца падлікам, выстаўленнем рахункаў і запытамі карыстальнікаў у сябе ў каморцы. "Чараўніцтва" вальфрамавых палёў забяспечвае нас стабільнай сувяззю. І толькі OpenStack часам капрызіць, выкрыкваючы нешта накшталт "'WSREP не мае ніякага парадкавання для application use". Але гэта зусім іншая гісторыя…
Зусім нядаўна мы запусцілі сэрвіс.
Усе падрабязнасці вы можаце даведацца на нашым .
Каманда распрацоўкі CLO
Карысныя спасылкі
OpenStack
Tungsten Fabric
Крыніца: habr.com