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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разходки из волфрамовите полета — 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.

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

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

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

Следващата трудност ни чакаше при работа с дисковете. Не успявахме да откъснем системния volume от сървъра.

Отново, самият OpenStack „кълне“, че свързаността е прекратена и сега можем да работим с volume-a независимо. Но API-то категорично не желаеше да извърши операции с диска.

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

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

Тестово стартиране

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

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

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

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

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

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

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

Продължение следва

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

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

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

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

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