Запуск без фреймворка

Одна из самых больших ошибок при создании бессерверной архитектуры с использованием AWS Lambda — написание функций без фреймворка. Существует несколько фреймворков, доступных для развертывания и подключения функций Lambda к событиям, которые будут их запускать. Эти платформы управляют развертыванием отдельных функций Lambda, настройкой шлюза API для прохождения через события HTTP или запланированным событием Cloudwatch для запуска Lambda в задании cron.

Лично мне больше всего нравится бессерверная структура, которая позволяет быстро создавать бессерверную архитектуру на многих различных платформах FaaS, таких как AWS Lambda, Azure Functions и Google Cloud Functions. С ним легко и быстро начать работу, так же просто, как:

npx serverless create -t aws-nodejs

логирование

По умолчанию AWS Lambda ведет журнал в AWS Cloudwatch. К сожалению, многие люди считают Cloudwatch одним из самых слабых инструментов в репозитории AWS, и из-за этого он может сделать регистрацию в бессерверной архитектуре настоящей проблемой.

Используя библиотеку ведения журналов, такую ​​как Bunyan, вы можете регистрировать выходные данные JSON, отображающие входные события и отправленные ответы, что позволяет легко интегрировать AWS Lambda в стек ELK или другое стороннее решение для ведения журнала.

Настройка Bunyan может быть выполнена всего за 8 LOC.

import { createLogger } from 'bunyan'
const log = createLogger({
 name: process.env.SERVICE_NAME,
 src: process.env.IS_OFFLINE
})
export default log

Большие размеры пакетов

Когда вы начинаете работу с AWS Lambda, большие размеры пакетов обычно не являются проблемой, однако, когда ваша архитектура растет и вы начинаете накапливать большое количество функций Lambda, максимальный размер пакета становится проблемой. По умолчанию размер развертывания ограничен 50 МБ.

Чтобы обойти это, вы можете использовать webpack для объединения каждой точки входа/лямбды в отдельный файл. Еще одним дополнительным преимуществом индивидуального объединения является более быстрое развертывание и развертывание отдельных функций, что означает, что вы можете обновлять и развертывать только одну функцию, а не всю архитектуру.

Вы можете включить это в бессерверной среде с помощью плагина serverless-webpack следующим образом:

# serverless.yml
…
package:
 individually: true
…

Шлюз API отклоняет ваш ответ

Шлюз API может возвращать ошибку 502 Bad Gateway, в которой говорится, что ответ, полученный шлюзом от вашего Lambda, имеет неверный формат. Самая большая причина этого, с которой я столкнулся при начале работы с AWS Lambda, — это требование возвращать строку в качестве тела запроса. Рекомендуется создать вспомогательные функции для форматирования ваших ответов и добавления любых дополнительных подходящих заголовков, таких как CORS.

const handler = (
  callback,
  status = 200,
  headers = {},
  body = ''
) => {
  callback({
    statusCode: status,
    headers: {
      'Access-Control-Allow-Origin': '*',
      ...headers
    },
    body: typeof body !== 'string' ? JSON.stringify(body) : body
  })
}

Приведенная выше вспомогательная функция просто добавляет заголовок управления доступом CORS и упорядочивает полезную нагрузку.

Местное развитие

Многие из упомянутых выше фреймворков, а также собственный AWS SAM Local от AWS позволяют выполнять ваше бессерверное приложение в автономном режиме, что помогает воспроизводить и исследовать проблемы, возникающие при запуске вашего бессерверного приложения на AWS Lambda со шлюзом API.

Используя бессерверную структуру, существует плагин под названием serverless-offline, который эмулирует AWS Lambda и API Gateway для локальной разработки. Начать работу так же просто, как добавить плагин и запустить:

sls offline start

Это означает, что вы можете легко подключить отладчик для просмотра выполнения событий в реальном времени.

AWS SAM Local предлагает более полную эмуляцию событий, позволяющую эмулировать события из S3, API Gateway, DynamoDB и т. д. Однако он также требует такой же конфигурации, как и безсерверная, с файлом yaml для перечисления всех функций Lambda с указанием используемой ими среды выполнения и событий, которые они получают.

Если вас увлекает работа с функциями с использованием фреймворка, такого как serverless, и вы хотели бы заниматься этим чаще, мы будем рады услышать от вас [email protected]