DOU Labs: як в EPAM зробили opensource-інструмент для розгортання serverless-додатків

У рубриці DOU Labs ми запрошуємо IT-компанії ділитися досвідом власних цікавих розробок і внутрішніх технологічних ініціатив. Питання і заявки на участь надсилайте на [email protected] .

Привіт, мене звуть Владислав Терещенко, я співпрацюю з EPAM як Software Engineer. Цю статтю ми готували разом із колегами Олександром Оньшой та Олександрою Романенко. Розповімо вам, як зробили Syndicate Deployment Framework для AWS .

Ця стаття, напевно, буде небайдужа тим, хто пробує працювати або вже щільно працює з serverless-додатками. Ми з ними б'ємося вже третій рік. Так вийшло, що ми почали робити свій фреймворк для їх деплоймента, коли на ринку були одиниці подібних рішень. Сьогодні їх значно більше. Але ми все ж завершили проект. І будемо раді подискутувати, чому не віддали перевагу аналогам, а заморочилися самі.

А для тих, хто тільки придивляється до serverless, ми розповімо про перешкоди, які можуть чекати і вас.

Основна ідея, або від локальної проблеми до окремого тули

Якщо коротко, наш Syndicate — це фреймворк для Amazon Web Services, який дозволяє легко розгортати serverless-додатки, використовуючи метаописания ресурсів. За основу взяли те, що інструмент повинен:

Бути простим.
Працювати швидко.
Зменшувати ймовірність помилки в комунікації між розробником і девопсом.

Як це часто буває, спочатку ця штука не була самостійною. В 2016 році, під час роботи над великим SaaS-проектом, ми вирішили спробувати хайповый serverless. Взяли одне з маленьких додатків проекту і переписали його, використовуючи AWS Lambda (далі просто лямбда). В процесі переписування ми дотримувалися принципу single responsibility: кожна функція повинна виконувати логічно неподільних частину роботи, не зберігаючи при цьому стан.

Основний профіт serverless в тому, що в такому разі ми не платимо за простій інфраструктури. Поки що немає користувача, ресурси програми не потрібні. Зручно та економно.

Але тут же й зворотна сторона медалі. Проблема будь-якого девелопера — інструмент потрібно тестувати. У традиційному підході ми пишемо код, запускаємо його локально, дебажим — і все добре.

У serverless з лямбдами так не вийде. Amazon розгортає код в контейнері, до якого немає доступу. Весь дебаг, по суті, йде в голові. Ніхто не відкидає можливість написання unit - і integration-тестів. Але, як зазвичай, прорахувати всі помилки заздалегідь неможливо.

Спочатку нам потрібно було деплоить невелика кількість ресурсів: кілька DynamoDB-таблиць і близько 5 AWS Lambda і ролей для них. Настав момент, коли конфігурувати цей «зоопарк» стало довше, ніж писати нову лямбду. Так з'явився Python-script на кілька десятків рядків, який деплоил це за нас. По мірі використання нових сервісів наша тула зростала: ми розширювали її, додаючи можливість створювати нові типи ресурсів.

У підсумку скриптики доросли до того, що ми побачили можливість оформити їх в окремий CLI tool. За задумом, Syndicate повинен був допомогти не тільки нам у світлі цього проекту, але і іншим розробникам в різних схожих кейсах. Результат ви можете бачити на GitHub . Так, написано все на Python.

Наш фреймворк підходить для розробки будь-якого serverless-проекту, який ви хочете розгортати на Amazon з використанням AWS Lambda, і ресурсів, найбільш популярні при serverless-розробки: SQS, DynamoDB, Step Functions, API Gateway і т. д.

Зараз Syndicate використовується в тому великому переписаному проекті SaaS-рішення. Розробка з Syndicate ведеться протягом 3 років, і сам продукт вже підходить до фази релізу.

Як користуватися «Синдикат»

За посиланням на GitHub ви побачите проект і простий гайд. Тут — докладний опис, як фреймворк працює під капотом, що потрібно написати в темплейте, щоб задеплоить якусь специфічну річ, а також використовувані концепції.

Робота складається з трьох кроків.

Перший — створення configuration-файлу. У ньому описані всі атрибути, необхідні Syndicate для взаємодії з інфраструктурою: AWS Account ID; роль, яку буде використовувати фреймворк; регіон, де буде розгорнуто програму; шляху до модулів, які потрібно пакувати в лямбды (про це далі) і т. д.

Другий крок — використання Syndicate у проекті. Якщо це Java-проект, необхідно додати Syndicate maven plugin в pom.xml модулів, які містять в собі lambda handlers. Це потрібно для генерації метаописаний лямбд з анотаціями, які надає Syndicate. Таким чином, Syndicate дає можливість описувати лямбда-функції in Java way.

Якщо це Python-проект, потрібно створити метаописание лямбд, перерахувати external - і internal-залежно функції — і все злетить.

В нашому випадку, крім лямбд, є ще безліч ресурсів, з якими лямбды взаємодіють. Всі вони повинні бути описані у файлі deployment_resources.json. Цих файлів може бути трохи і вони можуть лежати по всьому проекту: всі будуть зібрані в один великий файл-темплейт, який буде процессить Syndicate. Зазвичай ми створюємо ці темплейти біля тих лямбд, які використовують описані в них ресурси.

Завершується крок складанням так званого bundle — набору упакованих deployment packages-лямбд — і файлу-темплейта з описом інфраструктури.

Третій крок — це створення ресурсів. Досить викликати одну CLI-команду, і Syndicate почне створення ресурсів в AWS-акаунті.

А як же аналоги? У чому відмінності? У чому профіт?

Це, напевно, найбільш незрозуміла частина. Навіщо взагалі було витрачати час на розробку чогось, що і так вже давно є?

Дійсно, вже у 2015 році можна було використовувати рідне рішення від Amazon — CloudFormation,яке почало підтримувати AWS Lambda. Але на той момент воно не підтримувало частина сервісів, яка була нам потрібна в розробці SaaS-рішення.

Інша тула — Terraform. Вона теж в якомусь форматі описує інфраструктуру і деплоит її. До того ж у Terraform можна описати інфраструктуру для AWS, Microsoft, Google і багатьох інших вендорів.

Ми ж дивилися не на сам інструмент, а на концепт.

Основною ідеєю Syndicate було зробити взаємодію розробника і девопса (або будь-якого, хто відповідальний за інфраструктуру на проекті) більш продуктивним. Не допустити miscommunication при поясненні необхідного сету ресурсів для роботи середовища або звичайних typo в темплейтах.

Тому Syndicate генерує метаописание для лямбды сам. А опис тих ресурсів, мета яких не генерується, лягає на плечі розробника. Але ми і далі працюємо над тим, щоб все більше ресурсів можна було описати з допомогою коштів, звичних для розробників (зразок анотацій).

Так у нашого інструменту з'явилося невелике, але дуже важливе доповнення — Maven plugin, який генерує з анотаціями опис інфраструктури. Це типовий підхід джавистов. Тобто ми пишемо над якимось класом анотацію @LambdaHandler, описуємо всі необхідні параметри і у нас з'являється JSON, який скаже Syndicate, як правильно розгорнути цю лямбду в AWS. У цьому і був сенс: щоб не описувати інфраструктуру в двох місцях і щоб описував її один і той же чоловік.

Переваги очевидні:

Так швидше.
Ми не витрачаємо час на комунікацію двох або декількох осіб.
Зменшується ймовірність помилки: я вказав що-то в анотації і можу в коді на це посилатися, а в темплейте воно відразу проросте.

Ще у Syndicate спрощена схема метаописаний ресурсів. Вам потрібно буде написати менше інформації в темплейте, але ви отримаєте той же результат, як якщо б ви описували інфраструктуру в CloudFormation.

Щодо використання AWS-акаунтів. Syndicate управляє ресурсами на рівні бандла. Бандл може бути задеплоен в аккаунт, де вже можуть бути створені якісь ресурси.

Після деплоя Syndicate описує всі створені ресурси і зберігає опис у себе. Це потрібно для того, щоб видаляти лише ті ресурси, які деплоили, а також для модифікації інфраструктури.

Наостанок про швидкості . SaaS-рішення, про яке ми вже згадували, зараз складається приблизно з 270 лямбд, 150 IAM policies, 170 IAM roles, 60 DynamoDB tables, 3 SQS queues, 60 SNS topics, 70 CloudWatch rules, 1 API Gateway з 300 ресурсами, 8 State machines. Все це сумарно деплоится близько 40 хвилин.

Якщо порівнювати з Terraform або CloudFormation, це хороший показник. Захоти ми перевести проект на той самий CloudFormation, розжилися б багато проблем. У нас дуже велика інфраструктура, а у CloudFormation обмеження в 200 ресурсів на 1 темплейт — не дуже зручно. Адже ми хочемо, щоб ці темплейти у нас були відв'язані один від одного, але в той же час збиралися в щось єдине.

Складності і факапи

Тут, на жаль (або на щастя), нічого нового. Всі закрадалися помилки через неуважність і втоми.

Бувало, правда, й таке: Amazon раптом тимчасово почав повертати щось недокументовану. Наш SaaS-проект використовує Syndicate мінімум 2 рази в день для DEV-энва. Інфраструктура деплоится вранці. А ввечері він викликається, коли інфраструктура чиститься для економії костов. Неприємно, коли вранці це працює, а очищення зробити не виходить, тому що, наприклад, з боку Amazon прилітає якась помилка або виявляється помилка у коді. Так що іноді доводилося вивертатися.

Апдейти і плани: методологія з serverless і (тс-с-с) дебагер

Syndicate спочатку планувався просто як Infrastructure-as-Code-інструмент. Але на момент, коли ми вийшли в open source, аналогів вже було явно не два. Всі переваги нашого варіанту ми описали вище. Але на цьому не зупиняємося.

На початку ми говорили, що у нас було багато незручностей, пов'язаних з розробкою під serverless. Ми не можемо дебажити і моніторити весь проект. Що можемо, перевіряємо локально. Решта просто деплоим і дивимося, як воно себе веде. Звичайно, було б добре, щоб були інструменти та стандарти, які допомагають розробляти такі програми.

Зараз ми працюємо над тим, щоб перетворити Syndicate в платформу для розробки serverless-систем. Дати набір інструментів і підходів. Ми в процесі інтеграції з JetBrains IntelliJ IDEA: було б зручно інтегруватися в саму середовище розробки, щоб допомагати моніторити environment.

Далі — комунікація девелопера і девопса. Під serverless потрібні певні специфічні знання, пов'язані саме з AWS. Девопс зазвичай вимагає від розробника якихось понять: скільки лямбда буде вимагати пам'яті, наскільки її потрібно розпаралелити та іншу специфіку. Одне з наших завдань — передбачити всі моменти, які вимагають від розробника специфічного знання.

Швидше за все, буде поставлено мінімально необхідний оптимальний сет, при якому буде працювати більшість проектів. Налаштування потрібно зробити інтуїтивно зрозумілими, щоб не копатися в тисячі параметрів AWS і не сидіти над цим годинами разом з девопсами. Для девелопера менше конфігурацій — менше головного болю. Максимально просто і зручно.

А ще у нас є смілива мета — замахнутися на те, щоб допомогти розробникам дебажити serverless-додатки, встановлені в AWS-акаунті. Це допоможе виграти багато часу. Ми, наприклад, його втрачали як раз на тому, що припускали, що воно буде працювати правильно.

Тут можна заперечити, що за 3 роки з'явилися рішення, які дозволяють дебажити лямбду локально: SAM Local, Local Stack і т. п. Для однієї — відмінно. А тепер уявіть: ви розробляєте якусь розподілену систему з безліччю компонентів. Вона спроектована з Event Sourcing-підходом. Наприклад, є лямбда, яка пише в DynamoDB таблицю, а на цю запис викликається інша лямбда. Як таке емулювати локально? Потрібен дебаг, який буде працювати з реальним середовищем, коли івент буде від AWS.

Ймовірно, AWS і сам рухається до створення такого дебагера. Але ми розвиваємося паралельно і можемо стати гідною альтернативою.

Поконтрибьютим разом?

Зараз наша микрокоманда складається з трьох чоловік: мене, Олександра Оньши і Владислава Кулика, який також співпрацює з EPAM як Software Engineer. Ми адаптуємося до того, що пропонує ринок. Пробуємо зробити рішення, яке буде випереджати його потреби.

Зліва направо: Владислав Кулик, Олександр Оньша, Владислав Терещенко

Ми самі пишемо цю систему і використовуємо її. І хоча спочатку робили Syndicate під конкретний великий проект, намагалися враховувати думки різних технічних сторін: знайомих, друзів, архітекторів, зовнішніх клієнтів. Чим більше буде співтовариство, яке буде бачити, що враховуються побажання, тим більше буде ідей. І тим більше різних проблем ми зможемо вирішити.

Ми спочатку не хотіли робити фреймворк закритим: нам цікаво зробити продукт, яким будуть користуватися. Тому якщо у вас з'являться побажання та/або зауваження, ми завжди відкриті. Хочете самі зробити реалізацію? Welcome, ми додамо ваш шматочок в Syndicate, а ви приєднаєтеся до числа контриб'юторів. Нагадуємо: подивитися на фреймворк можна тут .

Всім fearless, careless і serverless!

Опубліковано: 29/05/19 @ 10:00
Розділ Різне

SEO Блог