Зі зростанням стажу роботи в ІТ починаєш помічати, що системи мають свій характер. Вони можуть бути поступливими, мовчазними, химерними, суворими. Можуть розташовувати до себе або відштовхувати. Так чи інакше, доводиться «домовлятися» з ними, лавірувати між «підводним камінням» і вибудовувати ланцюжки їхньої взаємодії.
Ось і нам випала честь побудувати хмарну платформу, а для цього потрібно «вмовити» пару підсистем працювати з нами. Благо, у нас є «мова 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 не може бути preparad node for application use». Але це зовсім інша історія.
Нещодавно ми запустили сервіс.
Всі подробиці ви можете дізнатися на нашому .
Команда розробки CLO
Корисні посилання
OpenStack
Вольфрамова тканина
Джерело: habr.com