Розробка API на Python із Serverless
У попередній статті я показав, як можна взаємодіяти з безсерверною платформою AWS Lambda лише засобами, наданими Amazon. Це був корисний експеримент — раджу так робити з будь-якою новою технологією чи системою, яку бажаєте вивчити. Починайте з найпростішого і спробуйте збудувати проект, не застосовуючи надто багато додаткових інструментів чи абстракцій, — так ви ліпше зрозумієте як працює базова система і з якими неприємностями, труднощами чи випадками, що вимагатимуть шаблонного коду, ви стикнетеся. Щойно побачите, як все працює, ви значно глибше зрозумієте абстракції, які лежать на поверхні, оскільки матимете уявлення про те, як вони влаштовані, які проблеми розв’язують і яких складнощів дозволяють уникнути.
AWS має потужні служби, які, втім, потрібно відповідним чином поєднувати, щоб досягти потрібного результату. По суті, вони є модулями, які мають певну функціональність, але мають бути якось об’єднані в єдине ціле, щоб ними було дійсно зручно користуватися. На щастя, платформа підтримує скрипти, і вже з’являється додатковий софт і шари абстракцій, що спрощують для програмістів самостійне керування налаштуваннями, не вдаючись до посередництва додаткових апаратних засобів чи людей. CloudFormation (CF) дає змогу описувати інфраструктуру за допомогою JSON або YAML.
Завдяки шаблонам CF на зразок serverless і трансформаціям CodeStar, вам знадобиться значно менше коду, щоб описати безсерверну конфігурацію у CloudFormation. А такі інструменти як Serverless додають іще один рівень автоматизації, полегшуючи роботу розробникам. Amazon тут не пасе задніх, пропонуючи інструментарій навіть вищого рівня, який має назву Amplify (про нього розповім у наступних дописах) і дає змогу іще більше автоматизувати роботу із залученням апаратних і програмних засобів.
Інструментарій Serverless
Погравшись трохи з AWS SAM і трансформацією serverless для CF, я швидко відчув певні недоліки відмови від складнішої системи для автоматизації:
- Перегляд логів. Переглядати логи CloudWatch в консолі AWS — не найліпший спосіб стежити в реальному часі (та й узагалі) за тим, що ваш додаток видає на виході.
- Було незрозуміло, як зберегти деякі складники архітектури безсерверного додатку для повторного використання в інших проектах. Я поцікавився у розсилці Flask і на його IRC-каналі, як реалізувати це в розширенні — і жодної путньої відповіді не отримав.
- Визначення речей на зразок шлюзів API, сховищ S3 для коду і доменів засобами CF — марудна праця. Її можна автоматизувати більшою мірою.
- Було б чудово отримувати одразу якусь інформацію щодо розгорнутого додатку, як-от його URL-адресу.
- Розгортання, включно з розгортаннями до різних стадій.
- Сповіщення про закінчення розгортання, особливо в разі використання CodeStar.
- Виклик функцій для тестування і засобами автоматизації.
- Керування залежностями.
І деякі інші аспекти, наприклад відстежування коректності профілю налаштування AWS й регіону.
Як часто трапляється у сфері інформаційних технологій, я не перший, хто стикнувся з цими проблемами, і дехто вже потурбувався про їх розв’язання.
Є такий інструментарій Serverless — не сказати, що назва додає ясності в обговорення недавньої тенденції використовувати безсерверні архітектури додатків, де вже маємо, наприклад, прикметник serverless, безсерверну модель додатку (Serverless Application Model (SAM)) і CF-трансформацією serverless для AWS.
Serverless допоможе впоратися з усіма переліченими вище проблемами. З огляду на мій недавній досвід, гадаю, продовжувати розробку безсерверних додатків без нього було б марною тратою часу й зусиль. Звісно, якщо ви не початківець і не маєте на меті опанувати основи.
Не буду описувати тут як починати роботу з Serverless, про це можна почитати його сайті. Тут нічого складного немає, особливо якщо у вас вже налаштовані реквізити AWS. Роздивімося краще переваги, які він надає:
Логування
Тут усе просто. Продивитися всі чи кілька останніх записів у файлах логів можна так:
sls logs -f myfunction -t
Повторне використання коду
# Створити Flask-додаток на основі шаблону sls install --url https://github.com/revmischa/serverless-flask --name myapp
Дехто ще пішов шляхом Create-React-App і створив шаблони Serverless-проектів, до яких можна отримати доступ за допомогою команди «sls install». З одного боку, це значно спрощує створення й розповсюдження готових рішень і залишає можливість для розгалуження упродовж розвитку шаблонів. Але з іншого — додавати нові поліпшення до проектів на основі старих шаблонів стає значно складніше. Оскільки йдеться про Flask і Python, навряд самих лише шаблонів вистачить, щоб розв’язати цю проблему. Потрібен іще якийсь модуль для Python, який буде розвиватися паралельно. Було б чудово, якщо б це було щось аналогічне до пакета react-scripts, який співіснує з Create-React-App.
Налаштування і CloudFormation
Тепер оголошувати ресурси й функції можна у файлі налаштувань serverless.yml. Туди ж можна додати ще купу корисного.
Майже весь шаблонний код, який потрібен CF для налаштування всіх аспектів безсерверного додатку (сховища S3 для коду, IAM-дозволів для виклику і CloudWatch, API Gateway тощо) від вас схований — ним більше не треба перейматися. Від вас потрібні лише мінімальна конфігурація та CF, щоб описати те, що потрібно саме для вашого випадку. За шкалою зручності від sendmail.conf до .emacs, serverless.yml є доволі близьким до останнього.
Інформація
Тут усе просто. Де я там запаркував свій домен?
$ sls info
Service Information
service: myapp
stage: dev
region: eu-central-1
stack: myapp-dev
api keys:
None
endpoints:
ANY - https://di1baaanvc.execute-api.eu-central-1.amazonaws.com/dev
ANY - https://di1baaanvc.execute-api.eu-central-1.amazonaws.com/dev/{proxy+}
GET - https://di1baaanvc.execute-api.eu-central-1.amazonaws.com/dev/openapi
functions:
app: myapp-dev-app
openapi: myapp-dev-openapi
Serverless Domain Manager Summary
Domain Name
myappmyapp.net
Distribution Domain Name
dcwyw3gslhqw1.cloudfront.net
Розгортання
Тут теж все просто, навіть занадто просто!
$ sls deploy $ sls deploy -s prod # specify stage
Ця команда збирає залежності, створює пакет служби, завантажує його у сховище S3 і запускає оновлення стеку CloudFormation.
Бачите розділ «Serverless Domain Manager Summary» (Короткі відомості для диспетчера доменів для безсерверних додатків)? Це налаштування плагіну serverless-domain-manager. Якщо вам потрібно розгорнути кінцеві точки під доменним ім’ям у зоні Route53 (сподіваюся, ви вже маєте ACM-сертифікат для регіону us-west-1), Serverless може автоматично прикріпити домен або піддомен, створити дистрибутив CloudFront і виконати зіставлення домену з API Gateway.
Плагін обирає ACM-certificate для вашого домену випадково з переліку збігів серед доменних імен, і це призвело до однієї проблеми: він обирав сертифікат з вичерпаним терміном дії. Тому довелося дещо виправити, щоб відфільтрувати проблемні сертифікати. І мій запит на внесення виправлень до коду плагіну одразу задовольнили. Приємно, коли так трапляється.
Очікування / Сповіщення
Після виконання згаданої вище команди розгортання ви отримаєте сповіщення. Потім одразу можна переходити до тестування. Щоб прискорити процес, можна розгорнути лише певну функцію, або скористатися опцією пришвидшення передачі даних (Transfer Acceleration) сховища S3, щоб пришвидшити завантаження ваших кунштиків. І ніякого марнування часу, розгортаючи непотрібні вам речі або роздивляючись веб-інтерфейс CodeStar.
Виклик функцій
Як і в AWS SAM, у Serverless немає нічого складного. Якщо ви пишете веб-додаток з використанням плагіну serverless-wsgi, його можна також обслуговувати локально.
Керування залежностями
(Ця частина стосується Python)
Як керувати залежностями вашої «лямбди» з кодом на Python? Просто записати їх у файл requirements.txt. Очевидно, еге ж? У всякому разі, із Serverless це більш-менш так. Також не забувайте, що всі залежності мають міститися у zip-файлі вашої «лямбди». Треба скомпілювати залежності в бінарники, а поряд немає
Зверніть увагу: якщо вам треба викликати функцію локально або запустити WSGI-сервер, доведеться створити локальне віртуальне оточення. Якось мені трапився дивний шаблон — він не мав стосунку до Serverless, — в якому керування локальними залежностями й залежностями «лямбди» було реалізовано за допомогою pipenv. Не найкращий варіант, не раджу так робити.
Розширення функціональності Serverless
Я користуюся AWS Lambda здебільшого коли пишу невеличкі Web API-служби на Python з використанням мікрофреймворка Flask. Serverless надає мені потрібні інструменти, але хочу мати вже готові підвалини для свого додатку, щоб додатково спростити створення нових проектів.
Отже, я зробив форк шаблону serverless-flask і дещо його переробив. Зробив так, щоб він більше не питав, чи у вас Python 2 або 3 (чому б краще не питати хочу я UTF-8 або EBCDIC?) і усталено вимкнув докерування pip.
Створюючи API-сервер на основі Flask, можна полегшити собі життя, додавши marshmallow для виконання серіалізації та десеріалізації запитів, flask-apispec для інтеграції marshmallow з OpenAPI (Swagger) і Flask, а також CORS. У моїй версії шаблону це все потрібно, щоб спростити наскільки можливо створення документованого REST API засобами Python і Serverless найменшими зусиллями та з мінімумом написання коду. У якості бонусу він генерує клієнтські бібліотеки для вашого API на основі визначення OpenAPI будь-якою зручною для вас мовою програмування.
Інструкції з використання шаблону й швидкого початку роботи з ним шукайте тут.
Serverless? Чому б і ні
Цей допис — друга віха в нашій подорожі. Поліпшення процесу написання додатків та служб — це тривалий процес. Минулого разу ми розглядали служби AWS окремо, а у цьому дописі зосередитися на допоміжному інструментарії. Логічним наступним кроком могли б стати AWS Amplify та GraphQL. А може й ні. Стежте за оновленнями.
Читати першу частину статті
