Основи Serverless додатків в середовищі Amazon Web Services

Serverlessдобрий День, дорогі Хабра-користувачі!
Сьогодні хотілося б поговорити про активно набирає обертів технології в світі ІТ — про одну з хмарних технологій, а саме – про бессерверной архітектури додатків (БСА – Serverless). Останнім часом хмарні технології набирають все більшу популярність. Це відбувається з простої причини – легкої доступності, відносної дешевизни і відсутності початкового капіталу – як знань для підтримки і розгортання інфраструктури, так і грошового характеру.
Технологія Serverless стає все більш і більш популярна, але чомусь дуже мало висвітлюється в ІТ індустрії, на відміну від інших хмарних технологій, таких як IaaS, DBaaS, PaaS.

Для написання статті я використовував AWS (Amazon Web Services) як, безперечно, найбільший і продуманий сервіс (виходячи з аналізу gartner's за 2015 рік).

gartner's cloud solutions chart
На сьогодні нам знадобиться:

  • AWS аккаунт (для тестів і мінімальної розробки вистачить і Free — tier);

  • Платформа для розробки (я віддаю перевагу Linux Fedora, але можна використовувати будь-яку дистрибуцію, підтримуючу Node не менш 4.3 і NPM);

  • Serverless Framework 1.* Beta — Про це фреймворку я розповім докладніше в окремому розділі (https://github.com/serverless/serverless)
Ну, що — почнемо з азів.

Serverless — у чому основа популярності

Serverless – бессерверная архітектура додатків. Насправді, не така вже вона і бессерверная. Основу архітектури складають микросервисы, або функції (lambda), що виконують певне завдання і запускаються на логічних контейнерах, заховані від сторонніх очей. Тобто кінцевому користувачеві дано тільки інтерфейс завантаження коду функції (сервісу) і можливість підключення до цієї функції джерел подій (events).
Розглядаючи на прикладі сервісу Амазона, джерелом подій може бути безліч тих же сервісів Амазона:

  1. S3 сховище може генерувати безліч подій на практично будь-яких операціях, таких як додавання, видалення і редагування файлів в бакетах.

  2. RDS і DynamoDB – більш того, Dynamo дозволяє генерувати події на додавання або зміни даних в таблиці.


  3. Cloudwatch – система на подобі cron.

  4. І, саме для нас цікаве – API Gateways. Це програмний емулятор HTTP протоколу, що дозволяє абстрагувати запити до одиничного події микросервиса.

Схематично роботу микросервиса можна представити таким чином:
Принцип роботи лямбда функціїУ дійсності ж, як тільки ви завантажуєте код функції в Амазон, він зберігається в якості пакету на внутрішньому файловому сервері (зразок S3). В момент отримання першого події, Амазон автоматично запускає міні-контейнер з певним інтерпретатором (або віртуальною машиною, у разі JAVA) і запускає отриманий код, підставляючи сформоване тіло події в якості аргументу. Як зрозуміло з принципу микросервисов, кожна така функція не може мати стану (stateless), так як доступу до контейнера немає, і час його існування нічим не визначено. Завдяки цій якості микросервисы можуть безперешкодно горизонтально зростати в залежності від кількості запитів і навантаження. Насправді, виходячи з практики, балансування ресурсів в Амазоні виконано досить-таки непогано і функція досить швидко «плодитися» навіть при стрибкоподібних підвищення навантаження.
З іншого боку, ще одна перевага такого stateless запуску полягає в тому, що оплату за використання сервісу, як правило, можна здійснювати, ґрунтуючись на час виконання конкретної функції. Настільки зручний спосіб оплати – в англомовній літературі Pay-as-you-go – дає можливість запускати стартапи або інші проекти без початкового капіталу. Адже необхідності викуповувати хостинг для розміщення коду – ні. Оплату можна здійснювати пропорційно використанню сервісу (що так же гнучко дозволяє розрахувати необхідну монетизацію вашого сервісу).

Таким чином, плюси подібної архітектури – це:

  1. Відсутність апаратної частини – серверів;
  2. Відсутність прямого контактування і адміністрування серверної частини;
  3. Практично безмежний горизонтальний ріст вашого проекту;
  4. Оплата за використане час ЦПУ.

мінусів можна віднести:

  1. Відсутність чіткого контролю контейнера (ви ніколи не знаєте, де і як вони запускаються, хто має доступ) – що нерідко може викликати параною.

  2. Відсутність «цілісності» додатка: кожна функція – це незалежний об'єкт, що часто призводить до якоїсь розкиданості програми та ускладнень скласти все докупи.

  3. Холодний старт контейнера залишає бажати кращого (як мінімум, в Амазоні). Перший запуск контейнера з лямбда функцією частенько може пригальмувати на 2-3 секунди, що не завжди добре сприймається користувачами.

загалом і В цілому у технології є свій сегмент попиту і свій ринок споживачів. Я ж знаходжу технологію вельми придатною для початкового етапу стартапів, починаючи від найпростіших блогів, закінчуючи онлайн іграми і не тільки. Особливий наголос в даному випадку ставиться на незалежність від серверної інфраструктури і безмежний приріст продуктивності в автоматичному режимі.

Serverless Framework

Як було згадано вище, одним з мінусів БСА є розрізненість програми і досить важкий контроль всіх необхідних компонентів – таких, як події, код, ролі та політики безпеки. Повинен сказати, що в проектах трохи складніше, ніж Hello World, регламентування всіх перерахованих компонентів – величезний головний біль. І не рідко призводить до відмови сервісів при черговому оновленні.
Щоб уникнути цієї проблеми, добрі люди написали дуже корисну утиліту з однойменною назвою – Serverless. Даний фреймворк заточений суто для використання в AWS інфраструктурі (і, хоча 0.5 гілка версій була повністю заточена під NodeJS, великим плюсом стало перенаправлення гілки 1.* у бік всіх підтримуваних AWS мов). Надалі мова піде про гілці 1.*, так як, на мій погляд, її структура більш логічною і гнучка у використанні. Більш того, у версії 1 було вичищено більшість сміття і додана підтримка Java і Python.
У чому ж корисність даного рішення? Відповідь дуже проста — Serverless Framework концентрує в собі всю необхідну інфраструктуру проекту, а саме: контроль коду, тестування, створення та контролювання ресурсів, ролей і політик безпеки. І так все це в одному місці, і може бути запросто додано в git для контролю версій.
Прочитавши базові інструкції з встановлення фреймворку та його налаштування, вам, напевно, вже вдалося встановити, але щоб зберегти корисність статті для початківців, дозвольте мені перерахувати необхідні етапи. Дочитавши до цього местя я сподіваюся у вас під рукою вже консоль з Centos, так що почнемо наше знайомство з установки NPM/Node (т. к. пакет serverless, все ж, написаний на NodeJS).
перший Етап
Я віддаю перевагу NVM для контролю версій ноди:

curl https://raw.githubusercontent.com/creationix/nvm/v0.31.6/install.sh | bash

другий Етап
Перевантажуємо профіль, як зазначено в кінці інсталяції:

. ~/.bashrc

третій Етап
Тепер встановлюємо збірку Node/NPM — (у прикладі я використовую 4.4.5, так як просто вона була під рукою)

nvm install v4.4.5

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

export AWS_ACCESS_KEY_ID=<key>
export AWS_SECRET_ACCESS_KEY=<secret>

Етап шостий
Припустимо, що обліковий запис встановлений і налаштований (Прошу звернути увагу, що для SLS фреймворку необхідний рівень доступу до AWS ресурсів – в іншому випадку, можна годинами намагатися розібратися, чому все працює не так, як хотілося).
Етап сьомий
Встановлюємо Serverless в глобальному режимі:

npm install -g serverless@beta

Прошу звернути увагу, що без вказівки beta версії, ви напевно встановили б 0.5 гілку. На сьогоднішній день 0.5 і 1.0 різні, як небо і земля, тому інструкції для версії 1.0 0.5 працювати просто не буде.
Етап восьмий
Створюємо директорію проекту. І, на даному етапі – невеликий відступ про архітектуру проекту.
Архітектура Serverless проекту
Давайте перейдемо тепер до того, яким чином лямбда функцію можна завантажити в Амазон. А саме, способів цих два:

  • Через веб консоль – простим копі-пастом. Спосіб дуже простий і зручний для односкладною функції з простим кодом. На жаль, таким способом у функції можна включити сторонніх бібліотек (списку бібліотек, підтримуваних лямбда функціями, можна прочитати в документації Амазона, але, як правило, це мовний пакет з коробки і AWS SKD – не більше, не менше).


  • Через AWS SKD можна залити пакет функції. Це звичайний zip архів, що має в собі всі необхідні файли і бібліотеки (в даному випадку, існує обмеження на максимальний розмір архіву в 50Мб). Не варто забувати, що лямбда – це Микросервис, і заливати весь програмний пакет в одну функцію не має ніякого сенсу. Так як оплата за функцію йде по часу виконання коду, так що не забувайте оптимізувати.

У нашому випадку, Serverless використовують другий спосіб – тобто він готує існуючий проект і створює з нього необхідний zip пакет. Нижче я наведу приклад проекту для NodeJS, в іншому цю ж логіку не важко буде застосувати і для інших мов.

Функція
|__ lib // Внутрішні бібліотеки
|__ handler.js // Точка входу в функцію
|__ serverless.env.yaml // Змінні оточення
|__ serverless.yml // Центральна конфігурація проекту
|__ node_modules // Сторонні модулі
|__ package.json

Дуже не хотілося б перевантажувати статтю, але, на жаль, документація по конфігурації фреймворку вельми неповна і розрізнена, тому я б хотів привести приклад з своєї практики по налаштуванню. Вся конфігурація сервісу знаходиться в serverless.yml файлі з такою структурою:
Зміст файлу конфігурації serverless.yml
service: Назва сервісу
 

 
provider:
 
name: aws
 
runtime: nodejs4.3
 
iamRoleStatement:
 
$ref: ../custom_iam_role.json #JSON файл, що описує IAM роль для наших функцій. http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_policy-examples.html. В даному JSON файлі потрібно залишити тільки масив Statements
 
vpc: #Дефолтні налаштування VPC (на випадок, якщо вам необхідно організувати доступ лямбда функції у вашу VPC мережа)
 
securityGroupIds:
 
- securityGroupId1
 
subnetIds:
 
- subnetId1
 
stage: dev #Назва етапу (по суті, довільна рядок, що має для вас якесь значення)
 
region: us-west-2 # Регіон Амазона
 

 
package: #Опис пакета
 
includee: #Важливий момент – фреймворк, за замовчуванням, включає в пакет тільки один файл, а саме – центральну точку доступу (handler). У разі, якщо ви хочете включити додаткові каталоги, їх необхідно вказати нижче.
 
- lib
 
- node_module # І так, як я писав раніше, Амазон не надає жодних можливостей довантажити сторонні модулі автоматично, так що їх необхідно включати в пакет.
 
exclude: # В разі, якщо вказані тільки винятки, фреймворк включить всі, окрім цього списку.
 
- tmp
 
- .git
 
functions: #В цій частині йде перерахування функцій. Нехай вас не бентежить подвійність понять – у даному випадку функція передбачає лямбда функцію в Амазоні. В той час, як весь проект називається Сервісом. Цікаво те, що кожна нова функція, по суті, буде створювати свій окремий пакет і абсолютно окрему lambda функцію в Амазоні.
 
hello:
 
name: hello #Назва лямбда функції
 
handler: handler.hello # Шлях до точки входу
 
MemorySize: 512 # Об'єм пам'яті
 
timeout: 10 # Таймаут
 
events: # Нижче перераховані події, на які програма буде реагувати
 
- s3: bucketName
 
- schedule: rate(10 хвилин)
 
- http:
 
path: users/create
 
method: get
 
cors: true
 
- sns: topic-name
 
vpc: # Кастомний налаштування VPC для конкретної функції
 
securityGroupIds:
 
- securityGroupId1
 
- securityGroupId2
 
subnetIds:
 
- subnetId1
 
- subnetId2
 

 
resources:
 
Resources:
 
$ref: ../custom_resources.json # JSON файл, що перераховує ресурси.
 


По більшій частині даний файл конфігурації дуже сильно нагадує конфігурацію CloudFormation Сервісу Амазона – про це я напишу, можливо, в наступній статті. Але коротко – це сервіс контролю всіх ресурсів у вашому акаунті Амазона. Serverless повністю покладається на цей сервіс, і, звичайно, якщо під час інсталяції функції виникає незрозуміла помилка, то можна знайти детальну інформацію про помилку на сторінці консолі CloudFormation.

Я хотів би відмітити одну важливу деталь з приводу проекту Serverless – ви не можете включити директорії і файли, що знаходяться вище по дереву каталогів, ніж директорія проекту. А точніше – ../lib зробити не вийде.

Тепер у нас є конфігурація, перейдемо до самої функції.
дев'ятий Етап
Створюємо проект з дефолтної конфігурацією

sls create —template aws-nodejs

Після цієї команди ви побачите структуру проекту — схожу на описану вище.

десятий Етап
Сама функція знаходиться у файлі handler.js. Принципи написання функції можна почитати в документації Амазона. Але в загальних рисах, точка доступу – це функція з трьома аргументами:

  1. event — об'єкт події. Цей об'єкт містить всі дані про подію, що викликала функцію. У випадку з AWS API Gateway цей об'єкт буде містити HTTP запит (насправді, Serverless встановлює дефолтний маппер HTTP запиту в API Gateway, тому користувачеві немає необхідності, як би те ні було, налаштовувати його самому, що дуже зручно для більшості проектів).

  2. Context — об'єкт, що містить поточний стан оточення – таку інформацію, як АРН поточної функції і, іноді, інформацію про авторизацію. Хочу нагадати, що для нової версії NodeJS 4.3 Amazon Lambda результат функції повинен бути повернутий callBack, ніж context (e.g. {done,succeed,fail})

  3. Callback — функція формату callback(Error, Data), що повертає результат події.

Для прикладу спробуємо створити найпростішу Hello World функцію:

exports.hello = function(event, context, callback) {
callback({'Hello':'World', 'event': event});
}

одинадцятий Етап
Завантаження!

sls deploy

Зазвичай, ця команда займе час на запаковку проекту, підготовку функцій і оточення в самому AWS. Але, по закінченню, Serverless поверне ARN і Endpoint, за якими можна буде побачити результат.

висновки

Незважаючи на те, що в статті були висвітлені лише ази використання Serverless технології, на практиці ж спектр застосування цієї технології практично безмежний. Від простих порталів (виконаних, як статична сторінка за допомогою React або Angular) c бекендом і логікою на лямбда функціях – до процесингу архівів або файлів через S3 сховище і досить складних математичних операцій з розподілом навантаження. На мій погляд, технологія ще на самому початку її зародження, і напевно буде розвиватися і далі. Так що, беремо клавіатуру в руки і йдемо пробувати і тестувати (благо Amazon Free Tier дозволяє це зробити абсолютно безкоштовно на перших порах).

Дякую всім за увагу, прошу поділитися своїми враженнями та зауваженнями в коментарях! І, сподіваюся, стаття вам сподобається — в такому разі, продовжу цикл поглиблення в технологію.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.