🥇Историята на създаването на облачния сервис, приправена с киберпанк

С нарастващия опит в IT започваш да забелязваш, че системите имат свой собствен характер. Те могат да бъдат послушни, мълчаливи, непредсказуеми, сурови. Могат да те привлекат или да те отблъснат. Както и да е, трябва да "се разбираш" с тях, да лавираш между "подводните камъни" и да изграждаш вериги от тяхното взаимодействие.

И на нас се падна честта да изградим облачна платформа, за което беше необходимо да "убедим" няколко подсистеми да работят с нас. За щастие, имаме "език API", сръчни ръце и куп ентусиазъм.

В тази статия няма да разглеждаме технически детайли, а ще опишем проблемите, с които се сблъскахме при изграждането на облака. Реших да опиша нашия път под формата на лека техническа фантазия за това как търсехме общ език със системите и какво излезе от това.

Добре дошли под кат.

Началото на пътя

Преди известно време пред нашия екип беше поставена задача – да стартираме облачна платформа за нашите клиенти. В наше разпореждане бяха подкрепата на ръководството, ресурси, хардуерен стек и свобода в избора на технологии за реализиране на софтуерната част на услугата.

Имаше и редица изисквания:

услугата трябва да има удобен личен кабинет;
платформата трябва да бъде интегрирана в съществуващата система за фактуриране;
софтуерно-апаратната част: OpenStack + Tungsten Fabric (Open Contrail), които нашите инженери се научиха да "готвят" достатъчно добре.

От това как се събра екипът, разработваше интерфейса на личния кабинет и се вземаха дизайнерски решения, ще разкажем друг път, ако хабра-общността прояви интерес.
Инструментите, които решихме да използваме:

Python + Flask + Swagger + SQLAlchemy – напълно стандартен Python набор;
Vue.js за фронтенда;
взаимодействието между компонентите и услугите решихме да направим с помощта на Celery върху AMQP.

Предварявайки въпросите относно избора в полза на Python, ще обясня. Язикът зае своята ниша в нашата компания и около него се създаде малка, но все пак култура. Затова беше решено да започнем изграждането на услугата именно на него. Тем повече, скоростта на разработване в подобни задачи често е решаваща.

И така, нека започнем нашето запознанство.

Мълчаливият Бил – фактуриране

С този човек се познаваме отдавна. Той винаги седи до нас и нещо мълчаливо брои. Понякога пренасочваше запитванията на потребителите, издаваше клиентски фактури, управляваше услугите. Обикновен работлив човек. Вярно, бяха и затруднения. Той е мълчалив, понякога дълбоко замислен и често — само в собствените си мисли.

Билингът е първата система, с която опитахме да се сприятелим. И първото предизвикателство, с което се сблъскахме, при обработката на услугите.

Например, при създаването или изтриването на задача, тя попада в вътрешната черга на билинга. По този начин е реализирана системата за асинхронна работа с услугите. За да обработим собствените си типове услуги, трябваше да "наслагваме" своите задачи в тази черга. И тук се сблъскахме с проблем: липса на документация.

Съдейки по описанието на софтуерното API, решаването на тази задача е възможно, но нямаше време за реверс инженеринг, затова изнесохме логиката навън и организирахме черга с задачи над RabbitMQ. Операцията над услугата се инициира от клиента от личния кабинет, обвива се в "задача" Celery на бекенда и се изпълнява от страна на билинга и OpenStack. Celery позволява удобно управление на задачите, организиране на повторения и следене на състоянието. По-подробно за "целери" може да се прочете, например, тук..

Също така, билинга не спря проекта, когато свършиха парите. Комуникирайки с разработчиците, установихме, че при изчисленията по статистиката (а ние трябваше да реализираме именно такава логика) има сложна взаимовръзка на правилата за спиране. Но тези модели не се вписват добре в нашите реалности. Също го реализирахме чрез задачи на Celery, прехвърляйки логиката за управление на услугите на бекенда.

Двете по-горе проблеми доведоха до това, че кодът малко се разду, и в бъдеще ще трябва да се занимаем с рефакторинг, за да изнесем логиката за работа с задачите в отделен сервис. Също така трябва да съхраняваме част от информацията за потребителите и техните услуги в наши таблици, за да поддържаме тази логика.

Още един проблем — мълчаливостта.

На част от запитванията към API, Били мълчаливо отговаря "Ок". Например, така беше, когато правихме зачисления на обещаните плащания за време на теста (за него по-късно). Запитванията се изпълняваха коректно и не видяхме грешки.

Беше необходимо да изуча логовете, работейки с системата през UI. Оказа се, че самият биллинг изпълнява подобни заявки, променяйки обхвата на конкретния потребител, например, администратор, предавайки го в параметъра su.

Като цяло, въпреки пропуските в документацията и малките несъответствия в API, всичко премина доста добре. Логовете могат да се четат дори при голямо натоварване, ако се разбира как са устроени и какво трябва да се търси. Структурата на базата данни е заплетена, но напълно логична и в определени случаи дори привлекателна.

Така че, обобщавайки, основните проблеми, които срещнахме на етапа на взаимодействие, са свързани с особеностите на реализацията на конкретната система:

недокументирани „функции“, които по един или друг начин ни засягат;
затворени изходни кодове (билингът е написан на C++), в резултат на което — невъзможност да решим проблем 1 по никакъв друг начин, освен чрез „метода на опити и грешки“.

Щастливи сме, че продуктът има достатъчно обширен API и интегрирахме следните подсистеми в нашия личен кабинет:

модул за техническа поддръжка — запитванията от личния кабинет се „проксирват“ в биллингa прозрачно за клиентите на услугата;
финансов модул — позволява изпращането на фактури на текущите клиенти, извършване на плащания и генериране на платежни документи;
модул за управление на услугите — за него трябваше да реализираме наш собствен обработчик. Разширяемостта на системата помогна на нас и „обучихме“ Били на нов тип услуги.
Пришло се наложи да се поразходим, но по един или друг начин, мисля, че ще успеем да се спогодим с Били.

Разходки из вольфрамовите полета — Tungsten Fabric

Вольфрамови полета, осеяни със стотици проводници, които пропускат през себе си хиляди битове информация. Информацията се събира в „пакети“, разглежда се, изграждайки сложни маршрути, както по чудо.

Това е територията на втората система, с която трябваше да се сближим — Tungsten Fabric (TF), носила името OpenContrail. Нейната задача е да управлява мрежовото оборудване, предоставяйки софтуерна абстракция на нас, като потребители. TF — SDN, инкапсулира сложната логика на работа с мрежовото оборудване. За самата технология има добри статии, например, тук.

Системата е интегрирана с OpenStack (за него ще говорим по-долу) чрез плъгин на Neutron.

Взаимодействие на услугите на OpenStack.

Системата беше представена на нас от екипа по експлоатация. Използваме API на системата, за да управляваме мрежовия стек на нашите услуги. Към момента не срещаме сериозни проблеми или неудобства (не мога да говоря за екипа по експлоатация), но имаше и някои куриози в взаимодействието.

Първият проблем изглеждаше така: команди, които изискват извеждане на голямо количество данни на конзолата на инстанса при свързване чрез SSH, просто „закачаха“ връзката, докато по VNC всичко работеше правилно.

За тези, които не са запознати с проблема, това изглежда доста забавно: ls /root работи правилно, докато, например, top „забива“ напълно. За щастие, вече сме се сблъсквали с подобни проблеми. Реши се с настройка на MTU по маршрута от compute нодовете до рутерите. Между другото, това не е проблем на TF.

Следващият проблем ни чакаше зад ъгъла. В един „прекрасен“ момент магията на маршрутизацията просто изчезна. TF спря да управлява маршрутизацията на оборудването.

Работихме с Openstack на административно ниво и след това преминахме на нивото на нужния потребител. SDN, изглежда, „улавя“ обхвата на потребителя, с който се извършват действията. Факт е, че същият администраторски акаунт се използва за връзка между TF и OpenStack. На етапа на превключване под потребителската сметка „магията“ изчезваше. Решението беше да създадем отделен акаунт за работа със системата. Това позволи работа, без да се нарушава функционалността на интеграцията.

Силиконови форми на живот — OpenStack

Силиконовото същество с причудлива форма обитава близо до волфрамови полета. Най-много прилича на дете гигант, което с един замах може да ни смачка, но от него не идва явна агресия. То не предизвиква страх, но размерите му внушават опасения. Както и сложността на случващото се около нас.

OpenStack е ядрото на нашата платформа.

OpenStack има няколко подсистеми, от които най-активно в момента използваме Nova, Glance и Cinder. Всяка от тях има свой API. Nova отговаря за compute ресурсите и създаването на инстанции, Cinder — управлението на томове и техните снимки, Glance — image service, който управлява шаблони на операционни системи и мета информация за тях.

Всеки сервис се стартира в контейнер, а брокерът на съобщения е „белият заек“ — RabbitMQ.

Тази система ни създаде най-много неочаквани проблеми.

Първият проблем не закъсня, когато се опитахме да свържем допълнителен обем към сървъра. Cinder API категорично отказваше да изпълни тази задача. По-скоро, ако се вярва на самия OpenStack, връзката се установява, но вътре в виртуалния сървър устройството за съхранение не е налично.

Решихме да "заобиколим" проблема и да поискате същото действие от Nova API. Резултатът — устройството се свързва коректно и е достъпно в сървъра. Изглежда, че проблемът възниква, когато block-storage не отговаря на Cinder.

Друга сложност ни очакваше при работата с дисковете. Системният обем не успявахме да отсъдим от сървъра.

Отново, самият OpenStack "кълне", че е унищожил връзката и сега може да се работи коректно с обема отделно. Но API категорично не желаеше да изпълнява операции върху диска.

Тук решихме особено да не се борим, а да променим гледната точка към логиката на работа на услугата. След като има инстанция, трябва да има и системен обем. Затова потребителят не може да изтрие или отключи системния "диск", без да изтрие "сървъра".

OpenStack е доста сложен комплекс от системи със своя логика на взаимодействие и усукани API. Спасението ни е достатъчно подробната документация и, разбира се, методът на опити и грешки (къде без него).

Тестов запуск

Тестовият запуск проведохме през декември миналата година. Основната задача беше да проверим в бойни условия нашия проект от техническа страна и от страна на UX. Публиката беше поканена селективно, а тестът беше затворен. Въпреки това оставихме възможността да поискате достъп до тестовете на нашия сайт.

Самият тест, разбира се, не мина без куриозни моменти, тъй като тук приключенията ни едва започват.

Първо, оценихме интереса към проекта малко некоректно и трябваше спешно да добавим компютърни нодове точно по време на теста. Обикновен случай за клъстера, но и тук имаше нюанси. В документацията за конкретната версия на TF е посочена конкретна версия на ядро, на което е тествана работата с vRouter. Решихме да стартираме нодове с по-свежи ядра. Какъв беше резултатът — TF не получи маршрути от нодовете. Приходи се спешно да се възстановят ядрата.

Другият куриоз е свързан с функционалността на бутона "промяна на парола" в личния кабинет.

Решихме да използваме JWT за организиране на достъпа до личния кабинет, за да не работим с сесии. Тъй като системите са различни и широко разпръснати, управляваме своя токен, в който „опаковаме“ сесиите от billing-а и токена от OpenStack. При промяна на паролата токенът, разбира се, „изтича“, тъй като данните на потребителя вече не са валидни и трябва да бъде преиздаден.

Пропуснахме този момент, а ресурсите, за да допишем този участък, банално не ни стигнаха. Наложи се да изключим функционалността точно преди тестовия пуск.
В момента извършваме logout на потребителя, ако паролата е била променена.

Въпреки тези нюанси, тестването премина добре. През последните няколко седмици около 300 души ни посетиха. Успяхме да видим продукта през очите на потребителите, да го тестваме в действие и да съберем качествена обратна връзка.

Продължава

За много от нас това е първият проект от подобен мащаб. Извлякохме редица ценни уроци за това как да работим в екип, да взимаме архитектурни и дизайнерски решения. Как с ограничени ресурси да интегрираме сложни системи и да ги пуснем в производство.

Разбира се, има с какво да се работи и по дълговете на кода, и на местата на интеграция на системите. Проектът е сравнително млад, но сме изпълнени с амбиции да го направим надежден и удобен сервис.

Системите вече успяхме да убедим. Бил послушно се занимава с изчисленията, фактурирането и заявките на потребителите в своя кабинет. „Вълшебството“ на тугстеновите полета ни осигурява стабилна свързаност. И само OpenStack понякога се държи капризно, изсикваща нещо като „'WSREP has not yet prepared node for application use“. Но това е съвсем друга история...

Тъкмо стартирахме услугата.
Можете да получите всички подробности на нашия сайта.

Екип по разработката на CLO