Використання С++ в AWS Lambda

У цій статті я планую описати процес створення і деплоя в AWS лямбда-функції, яка буде викликати нативний код З с++ аддона. Як ви зможете побачити, цей процес не сильно відрізняється від створення звичайної AWS Lambda функції на Node.js — вам лише потрібно налаштувати своє оточення у відповідності з вимогами AWS.

Що таке AWS Lambda?



Цитуючи документацію:

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

  • Як подієво-орієнтований обчислювальний сервіс, коли AWS Lambda запускає ваш код при виникненні певних подій, таких як зміна даних у Amazon S3 або таблиці Amazon DynamoDB.
  • Як обчислювальний сервіс, який буде запускати ваш код у відповідь на HTTP-запит до Amazon API Gateway або запитами AWS SDK.



AWS Lambda — дуже крута платформа, але підтримує лише кілька мов: Java, Node.js і Python. Що ж робити, якщо ми хочемо виконати певний код на С++? Ну, ви безумовно можете слинковать код на С++, Java-кодом, так і Python вміє це робити. Але ми подивимося, як це зробити на Node.js. В світі Node.js інтеграція з кодом на С++ традиційно відбувається через аддони. Аддон на С++ до Node.js являє собою скомпільований (нативний) модуль Node.js, який може бути викликаний з JavaScript або будь-якого іншого Node.js-модуля.


Аддони до Node.js це велика тема — якщо ви їх раніше не писали, можливо, варто почитати щось на зразок цій серії постів або більше узкоспециализировано про інтеграцію З++ і Node.js у веб-проектах. Є і хороша книга на цю тему.

Аддони в AWS Lambda



Чому ж використання аддонов в AWS Lambda відрізняється від класичного сценарію їх використання? Найбільша проблема полягає в тому, що AWS Lambda не збирається викликати node-gyp або будь-який інший інструмент збірки перед запуском вашої функції — ви повинні зібрати повністю функціональний бінарний пакет. Це означає, як мінімум, те, що ви повинні зібрати ваш аддон на Linux перед деплоем в AWS Lambda. А якщо у вас є які-небудь залежності, то збирати потрібно не просто на Linux, а на Amazon Linux. Є й інші нюанси, про які я розповім далі.

Ця стаття не про побудову складних змішаних додатків на Node.js + C++ в інфраструктурі Amazon, вона лише описує базові техніки складання і деплоя таких програм. По іншим темам можна звернутися до документації Amazon — там є купа прикладів.

Я збираюся написати С++ аддон, який буде містити функцію, що приймає три числа і повертає їх середнє значення. Так, я знаю, ось це якраз те, що можна написати тільки на З++. Ми виставимо дану функцію в якості доступною для використання через AWS Lambda і протестуємо її роботу через AWS CLI.

Налаштування робочого середовища

Є причина, по якій Java з її слоганом "напиши одного разу, запускай скрізь" стала популярною — і ця причина складності поширення скомпільованого бінарного коду між різними платформами. Java не вирішила всі ці проблеми ідеально («напиши одного разу, отлаживай скрізь»), але з тих пір ми пройшли довгий шлях. Найчастіше ми блаженно забуваємо про платформно-специфічних проблемах, коли пишемо код Node.js — адже Javascript це платформно-незалежний мову. І навіть у випадках, коли Node.js додатки залежать від нативних аддонов, це легко вирішується на різних платформах завдяки npm та node-gyp.

Багато з цих зручностей, однак, губляться при використанні Amazon Lambda — нам необхідно повністю зібрати нашу Node.js-програму (і її залежності). Якщо ми використовуємо нативний аддон, це означає, що збирати все необхідне нам доведеться на тій же архітектурі і платформі, де працює AWS Lambda (64-бітний Linux), а крім того потрібно буде використовувати ту ж саму версію рантайма Node.js, який використовується в AWS Lambda.

Вимога №1: Linux


Ми, звісно, можемо розробляти / тестувати / налагоджувати лямбда-функції з аддонами на OS X або Windows, але коли ми дійдемо до етапу деплоя в AWS Lambda — нам знадобиться zip-файл з усім вмістом модуля Node.js — включаючи всі його залежності. Нативний код, що входить до складу цього zip-файлу, повинен запускатися в інфраструктурі AWS Lambda. А це означає, що збирати його нам потрібно буде тільки під Linux. Зверніть увагу, що в цьому прикладі я не використовую ніяких додаткових бібліотек — мій код на С++ повністю незалежний. Як я поясню детальніше далі — якщо вам потрібні залежності від зовнішніх бібліотек, потрібно піти трохи глибше.

Я буду робити все мої експерименти в цій статті на Linux Mint.

Вимога 2: 64-bit


Це, можливо, слід було назвати вимогою №1… З тих же самих причин, про які розказано вище — вам потрібно створити для деплоя zip-файл з бинарниками під архітектуру x64. Так що ваш старенький запорошений 32-бітний Linux на виртуалке не підійде.

Вимогу 3: Node.js версії 4.3


На момент написання даної статті AWS Lambda підтримує Node.js 0.10 та 4.3. Вам абсолютно точно краще вибрати 4.3. В майбутньому актуальна версія може змінитися, слідкуйте за цим. Я люблю використовувати nvm для установки і зручного перемикання між версіями Node.js. Якщо у вас ще немає цього інструменту — підіть і встановіть його прямо зараз:

curl https://raw.githubusercontent.com/creationix/nvm/master/install.sh | bash
source ~/.profile


А тепер установіть Node.js 4.3 та node-gyp

nvm install 4.3
npm install -g node-gyp


Вимога 4: інструменти для складання C++ коду (з підтримкою С++11)


Коли ви розробляєте аддон для Node.js v4+, ви повинні використовувати компілятор з підтримкою С++11. Останні версії Visual Studio (Windows) і XCode (Mac OS X) підійдуть для розробки і тестування, але, оскільки нам потрібно буде зібрати всі під Linux, нам знадобитися g++ 4.7 (або свіжий). Ось як встановити g++ 4.9 на Mint/Ubuntu:

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install g++-4.9
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.9 20


Створюємо аддон (локально)



Нам знадобитися створити два Node.js-проекту. Один буде нашим С++ аддоном, який взагалі не буде містити в собі нічого відноситься до AWS Lambda — просто класичний нативний аддон. Другий проект буде лямбда-функцій у термінах AWS Lambda — тобто модулем Node.js, який буде імпортувати нативний аддон і брати на себе виклик його функціоналу. Якщо ви хочете спробувати на своїй машині — весь код тут, а конкретно цей приклад — в папці lambda-cpp.

Давайте почнемо з аддона.

mkdir lambda-cpp
mkdir lambda-cpp/addon
cd lambda-cpp/addon


Для створення аддона нам знадобляться три файлу — код на С++, package.json щоб сказати Node.js як поводитися з цим аддоном і binding.gyp для процесу складання. Давайте почнемо з самого простого — binding.gyp

{
"targets": [
{
"target_name": "average",
"джерела": [ "average.cpp" ]
}
]
}


Це, мабуть, найпростіший варіант файлу binding.gyp, який тільки можливо створити — ми задаємо ім'я цілі і вихідні коди для компіляції. При необхідності тут можна накрутити складні речі, що відображають опції компілятора, шляху до зовнішніх каталогів, бібліотек і т. д. Просто пам'ятайте, що все, на що ви посилаєтеся повинно бути статично слинковано в бінарники і зібрано під архітектуру x64.

Тепер давайте створимо package.json, який повинен визначати точку входу цього аддона:

{
"name":"average",
"version": "1.0.0",
"main": "./build/Release/average",
"gypfile": true,
"author": "Scott Frees <scott.frees@gmail.com> (http://scottfrees.com/)",
"license": "ISC" 
}


Ключовий момент тут — це властивість «main», яке пояснює Node.js, що ось цей конкретний бінарники є точкою входу даного модуля і саме він повинен бути завантажений кожен раз, коли хтось робить require('average').

Тепер вихідний код. Давайте відкриємо average.cpp і створимо простий аддон з функцією, яка повертає середнє значення всіх переданих їй параметрів (не будемо обмежуватися лише трьома!).

#include <node.h>

using namespace v8;

void Average(const FunctionCallbackInfo<Value>& args) {
Isolate * isolate = args.GetIsolate();
double sum = 0;
int count = 0;

for (int i = 0; i < args.Length(); i++){
if ( args[i]->IsNumber()) {
sum += args[i]->NumberValue();
count++;
}
}

Local<Number> retval = Number::New(isolate, sum / count);
args.GetReturnValue().Set(retval);
}


void init(Local<Object> exports) {
NODE_SET_METHOD(exports, "average", Average);
}

NODE_MODULE(average, init)


Якщо ви не знайомі з використанням V8, будь ласка, почитайте про це які-небудь статті або книги — даний пост не про це. Коротенько, макрос NODE_MODULE в кінці файлу вказує, яка функція повинна бути викликана, коли даний модуль буде завантажений. Функція init додає нову функцію до списку експортованих даним модулем — асоціюючи З++ функцію Average з викликається з Javascript функцією average.

Ми можемо зібрати все це за допомогою node-gyp configure build. Якщо все пройшло добре, то ви побачите gyp info ok в кінці висновку. В якості простого тесту давайте створимо файл test.js і зробимо з нього кілька викликів:

// test.js
const addon = require('./build/Release/average');

console.log(addon.average(1, 2, 3, 4));
console.log(addon.average(1, "привіт", "world", 42));


Запустіть цей код допомогою команди node test.js і ви побачите в консолі відповіді 2.5 та 21.5. Зверніть увагу, що рядки "hello" і "world" не вплинули на результати розрахунків, оскільки аддон перевірив вхідні параметри і використав у розрахунках лише числа.

Тепер потрібно видалити test.js — він не буде частиною нашого аддона, який ми збираємося задеплоить в AWS Lambda.

Створюємо лямбда-функцію



А тепер давайте створимо, власне, лямбда-функцію для AWS Lambda. Як ви можливо вже знаєте, для AWS Lambda нам необхідно створити обробник, який буде викликатися кожен раз, коли відбудеться певна подія. Цей обробник отримає опис цієї події (яка може бути, наприклад, операцією зміни даних в S3 або DynamoDB) у вигляді JS-об'єкта. Для цього тесту ми використовуємо проста подія, що описується наступним JSON:

{
op1: 4,
op2: 15, 
op3: 2
}


Ми можемо зробити це прямо в папці аддона, але я віддаю перевагу створити окремий модуль Node.js і підтягнути локальний аддон як npm-залежність. Давайте створимо нову папку де-то поряд з lambda-cpp/addon, нехай вона буде називатися lambda-cpp/lambda.

cd ..
mkdir lambda
cd lambda


Тепер створимо файл index.js і напишемо в нього наступний код:

exports.averageHandler = function(event, context, callback) {
const addon = require('average');
var result = addon.average(event.op1, event.op2, event.op3)
callback(null, result);
}


Зауважте, що ми послалися на зовнішню залежність "average". Давайте створимо файл package.json, в якому опишемо посилання на локальний аддон:

{
"name": "lambda-demo",
"version": "1.0.0",
"main": "index.js",
"author": "Scott Frees <scott.frees@gmail.com> (http://scottfrees.com/)",
"license": "ISC", 
"dependencies": {
"average": "file:../addon"
}
}


Коли ви виконаєте команду npm install, npm витягне ваш локальний аддон і копіює його в папку node_modules, а також викличе node-gyp для його складання. Структура папок і файлів після цього буде виглядати ось так:

/lambda-cpp
— /addon
— average.cpp
— binding.gyp
— package.json
— /lambda
— index.js
— package.json
— node_modules/
— average/ (contains the binary addon)

Локальне тестування



Тепер у нас є файл index.js, що експортує обробник викликів AWS Lambda і ми можемо спробувати завантажити його туди. Але давайте спочатку протестуємо його локально. Є відмінний модуль, який називається lambda-local — він може допомогти нам з тестуванням.

npm install -g lambda-local


Після його установки ми можемо викликати нашу лямбда-функцію по імені обробника "averageHandler" і передати йому наше тестове подія. Давайте створимо файл sample.js і напишемо в нього:

module.exports = {
op1: 4,
op2: 15, 
op3: 2
};


Тепер ми можемо виконати нашу лямбду командою:

lambda-local -l index.js -h averageHandler -e sample.js
Logs
------
START RequestId: 33711c24-01b6-fb59-803d-b96070ccdda5
END


Message
------
7


Як і очікувалося, результат дорівнює 7 (середнє значення чисел 4, 15 і 2).

Деплой з допомогою AWS CLI



Є два способи деплоя коду в AWS Lambda — через веб-інтерфейс і через утиліти командного рядка (CLI). Я планую використовувати CLI, оскільки даний підхід здається мені більш універсальним. Однак, все описане далі при бажанні можна зробити і через веб-інтерфейс.

Якщо у вас ще немає AWS-аккаунта — зараз саме час його створити. Далі потрібно створити Адміністратора. Повна інструкція є документації Амазона. Не забудьте додати створеному Адміністратору роль AWSLambdaBasicExecutionRole.

Тепер, коли у вас є користувач з правами Адміністратора, потрібно отримати ключ для конфігурації AWS CLI. Ви можете зробити це через IAM-консоль. Як завантажити свій ключ у вигляді файлу csv розповідається ось в цієї інструкції.

Як тільки у вас буде ключ, можна встановлювати CLI. Є кілька способів зробити це, і для установки нам у будь-якому випадку знадобиться Python. Найбільш простий спосіб, на мій погляд, це скористатися установником:

curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
unzip awscli-bundle.zip
sudo ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws


Далі потрібно налаштувати CLI. Запустіть команду aws configure і введіть ваш ключ і секретний код. Ви також можете вибрати регіон за замовчуванням і формат виведення. Ви, швидше за все, захочете приєднати профіль до даної конфігурації (оскільки він знадобиться далі) за допомогою аргументу --profile.

aws configure --profile lambdaProfile
AWS Access Key ID [None]: XXXXXXXXX
AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXX
Default region name [None]: us-west-2
Default output format [None]: 


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

aws lambda list-functions
{
"Functions": []
}


Оскільки ми тільки почали роботу — ніяких функцій поки немає. Але принаймні ми не побачили ніяких повідомлень про помилки — це добре.

Упаковка лямбда-функції і аддона



Найбільш важливий (і часто обговорюється в інтернеті) крок у всьому цьому процесі — це переконатися в тому, що весь ваш модуль буде упакований в zip-файл коректно. Ось найбільш важливі речі, які потрібно перевірити:

  1. Файл index.js повинен бути в кореневій папці zip-файлу. Ви не повинні упаковувати саму папку /lambda-addon/lambda — тільки її вміст. Іншими словами — якщо ви распакуете створений zip файл в поточну папку файл index.js повинен опинитися в цій же папці, а не в папці.
  2. Папка node_modules і всі її содерижмое повинно бути упаковано в zip-файл.
  3. Ви повинні зібрати аддон і упакувати його в zip-файл на правильній платформі (див. вище вимоги — Linux, x64 і т. д.)


У папці, де знаходиться index.js, упакуйте всі файли, які повинні бути задеплоены. Я створю zip-файл до батьківської папки.

zip -r ../average.zip node_modules/ average.cpp index.js binding.gyp package.json 


*Зверніть увагу на ключ "-r" — нам потрібно запакувати весь вміст папки node_modules. Перевірте отриманий файл командою less, має вийти щось таке:

less ../average.zip

Архів: ../average.zip
Length Method Size Cmpr Date Time CRC-32 Name
-------- ------ ------- ---- ---------- ----- -------- ----
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/
1 Stored 1 0% 2016-08-17 17:39 6abf4a82 node_modules/average/output.txt
478 Defl:N 285 40% 2016-08-17 19:02 e1d45ac4 node_modules/average/package.json
102 Defl:N 70 31% 2016-08-17 15:03 1f1fa0b3 node_modules/average/binding.gyp
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/
115 Defl:N 110 4% 2016-08-17 19:02 c79d3594 node_modules/average/build/binding.Makefile
3243 Defl:N 990 70% 2016-08-17 19:02 d3905d6b node_modules/average/build/average.target.mk
3805 Defl:N 1294 66% 2016-08-17 19:02 654f090c node_modules/average/build/config.gypi
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/Release/
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/Release/.deps/
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/Release/.deps/Release/
125 Defl:N 67 46% 2016-08-17 19:02 daf7c95b node_modules/average/build/Release/.deps/Release/average.node.d
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/Release/.deps/Release/obj.target/
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/Release/.deps/Release/obj.target/average/
1213 Defl:N 386 68% 2016-08-17 19:02 b5e711d9 node_modules/average/build/Release/.deps/Release/obj.target/average/average.o.d
208 Defl:N 118 43% 2016-08-17 19:02 c8a1d92a node_modules/average/build/Release/.deps/Release/obj.target/average.node.d
13416 Defl:N 3279 76% 2016-08-17 19:02 d18dc3d5 node_modules/average/build/Release/average.node
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/Release/obj.target/
0 Stored 0 0% 2016-08-17 19:02 00000000 node_modules/average/build/Release/obj.target/average/
5080 Defl:N 1587 69% 2016-08-17 19:02 6aae9857 node_modules/average/build/Release/obj.target/average/average.o
13416 Defl:N 3279 76% 2016-08-17 19:02 d18dc3d5 node_modules/average/build/Release/obj.target/average.node
12824 Defl:N 4759 63% 2016-08-17 19:02 f8435fef node_modules/average/build/Makefile
554 Defl:N 331 40% 2016-08-17 15:38 18255a6e node_modules/average/average.cpp
237 Defl:N 141 41% 2016-08-17 19:02 7942bb01 index.js
224 Defl:N 159 29% 2016-08-17 18:53 d3d59efb package.json
-------- ------- --- -------
55041 16856 69% 26 files
(type 'q' to exit less)


Якщо ви не бачите вмісту папки node_modules всередині zip-файлу або якщо файли мають додатковий рівень вкладеності в ієрархії папок — ще раз перечитайте все, що написано вище!

Завантаження в AWS Lambda



Тепер ми можемо створити лямбда-функцію за допомогою команди «lambda create-function».

aws lambda create-function \
--region us-west-2 \
--function-name average \
--zip-file fileb://../average.zip \
--handler index.averageHandler \
--runtime nodejs4.3 \
--role arn:aws:iam::729041145942:role/lambda_execute


Більшість параметрів говорять самі за себе — але якщо ви не знайомі з AWS Lambda, то параметр "role" може для вас виглядати дещо загадково. Як говорилося вище, для роботи з AWS Lambda вам необхідно було створити роль, яка має дозвіл AWSLambdaBasicExecutionRole. Ви можете отримати рядок, що починається з "arn:" для цієї ролі через веб-інтерфейс IAM (клікнувши на цю роль).

Якщо все пройде добре, ви повинні отримати JSON з відповіддю, що містить деяку додаткову інформацію про тільки що задеплоеной лямбда-функції.

Тестування за допомогою AWS CLI



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

aws lambda invoke \
--invocation-type RequestResponse \
--function-name average \
--region us-west-2 \
--log-type Tail \
--payload '{"op1":4, "op2":15, "op3":2}' \
--profile lambdaProfile \
output.txt


Ви отримаєте відповідь ось в такій формі:

{
"LogResult": "U1RBUlQgUmVxdWVzdElkOiAxM2UxNTk4zc02ngmxltexztytodq0ny0wzdzjmjjjmtrhzwygvmvyc2lvbjogjexbvevtvapftkqgumvxdwvzdelkoiaxm2uxntk4zc02ngmxltexztytodq0ny0wzdzjmjjjmtrhzwykukvqt1juifjlcxvlc3rjzdogmtnlmtu5ogqtnjrjms0xmwu2ltg0ndctmgq2yziyyze0ywvmcur1cmf0aw9uoiawljuxig1zcujpbgxlzcbedxjhdglvbjogmtawig1zialnzw1vcnkgu2l6ztogmti4ie1ccu1hecbnzw1vcnkgvxnlzdogmzugtuijcg==", 
"StatusCode": 200
}


Не дуже поки що зрозуміло, але це легко виправити. Параметр "LogResult" закодовано у base64, так що ми можемо розкодувати його:

echo U1RBUlQgUmVxdWVzdElkOiAxM2UxNTk4zc02ngmxltexztytodq0ny0wzdzjmjjjmtrhzwygvmvyc2lvbjogjexbvevtvapftkqgumvxdwvzdelkoiaxm2uxntk4zc02ngmxltexztytodq0ny0wzdzjmjjjmtrhzwykukvqt1juifjlcxvlc3rjzdogmtnlmtu5ogqtnjrjms0xmwu2ltg0ndctmgq2yziyyze0ywvmcur1cmf0aw9uoiawljuxig1zcujpbgxlzcbedxjhdglvbjogmtawig1zialnzw1vcnkgu2l6ztogmti4ie1ccu1hecbnzw1vcnkgvxnlzdogmzugtuijcg== | base64 --decode 

START RequestId: 13e1598d-64c1-11e6-8447-0d6c22c14aef Version: $LATEST
END RequestId: 13e1598d-64c1-11e6-8447-0d6c22c14aef
REPORT RequestId: 13e1598d-64c1-11e6-8447-0d6c22c14aef Duration: 0.51 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 35 MB 


Стало трохи більш читабельно, але все ж дало нам не дуже багато розуміння про те, що сталося. Це тому, що наша лямбда-функція не написала нічого в лог-файл. Якщо ви хочете побачити результат — то можете протестувати функцію через веб-інтерфейс, де легше побачити вхідні та вихідні параметри. А поки ви можете змінити свій файл index.js, перепакувати zip-файл, передеплоить його і викликати свою функцію знову:

exports.averageHandler = function(event, context, callback) {
const addon = require('./build/Release/average');
console.log(event);
var result = addon.average(event.op1, event.op2, event.op3)
console.log(result);
callback(null, result);
}


Після декодування відповіді ви побачите щось на зразок цього:

START RequestId: 1081efc9-64c3-11e6-ac21-43355c8afb1e Version: $LATEST
2016-08-17T21:39:24.013 Z 1081efc9-64c3-11e6-ac21-43355c8afb1e { op1: 4, op2: 15, op3: 2 }
2016-08-17T21:39:24.013 Z 1081efc9-64c3-11e6-ac21-43355c8afb1e 7
END RequestId: 1081efc9-64c3-11e6-ac21-43355c8afb1e
REPORT RequestId: 1081efc9-64c3-11e6-ac21-43355c8afb1e Duration: 1.75 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 17 MB 


Подальші плани



Отже, на даний момент у нас є на 100% робоча AWS Lambda-функція, яка викликає С++ код з аддона. Ми, звичайно, поки не зробили чогось реально корисного. Оскільки наша лямбда-функція робить деякі розрахунки, наступним логічним кроком буде прив'язати її до Gateway API, щоб вхідні параметри можна було брати з HTTP-запитів. Про те, як це зробити, ви можете почитати в Getting Started — секцію про виклик лямбда-функцій.

Я сподіваюся, ви тепер переконались, що деплой С++ коду в AWS Lambda можливий і навіть не надто складний — досить дотримуватися наведених на початку статті вимоги щодо складання, і все буде добре. Решта кроки досить тривіальні і повністю аналогічні деплою будь-лямбда-функції в AWS. Як я вже говорив, якщо ваш аддон вимагає якихось залежностей, їх доведеться статично слинковать в його бінарники.

Весь код з цієї статті доступний тут.
Джерело: Хабрахабр

0 коментарів

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