Инструмент для запуска веб-приложений на AWS Lambda.
Веб-адаптер AWS Lambda позволяет разработчикам создавать веб-приложения (http API) с помощью знакомых платформ (например, Express.js, Next.js, Flask, SpringBoot, ASP.NET и Laravel, все, что поддерживает HTTP 1.1/1.0) и запускать их на AWS Lambda. . Один и тот же образ Docker может работать на AWS Lambda, Amazon EC2, AWS Fargate и локальных компьютерах.
Веб-адаптер AWS Lambda работает с функциями Lambda, упакованными как в образы Docker, так и в Zip-пакеты.
Чтобы использовать Lambda Web Adaptor с изображениями Docker, упакуйте свое веб-приложение (http API) в Dockerfile и добавьте одну строку для копирования двоичного файла Lambda Web Adaptor в /opt/extensions внутри вашего контейнера:
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.4 /lambda-adapter /opt/extensions/lambda-adapter
Можно использовать базовые образы, отличные от AWS, поскольку клиент интерфейса среды выполнения поставляется с веб-адаптером Lambda.
По умолчанию Lambda Web Adaptor предполагает, что веб-приложение прослушивает порт 8080. Если нет, вы можете указать порт через конфигурацию.
Предварительно скомпилированные двоичные файлы Lambda Web Adapter доступны в общедоступном репозитории ECR: public.ecr.aws/awsguru/aws-lambda-adapter. В этом репозитории также представлены многоархивные изображения. Он работает как на архитектуре процессора x86_64, так и на Arm64.
Ниже приведен Dockerfile для примера приложения nodejs.
FROM public.ecr.aws/docker/library/node:20-slim
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:0.8.4 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=7000
WORKDIR "/var/task"
ADD src/package.json /var/task/package.json
ADD src/package-lock.json /var/task/package-lock.json
RUN npm install --omit=dev
ADD src/ /var/task
CMD [ "node" , "index.js" ]
Это работает с любыми базовыми изображениями, кроме базовых изображений, управляемых AWS. Чтобы использовать базовые образы, управляемые AWS, вам необходимо переопределить ENTRYPOINT для запуска веб-приложения.
AWS Lambda Web Adaptor также работает со средами выполнения Lambda, управляемыми AWS. Вам нужно сделать три вещи:
прикрепите слой Lambda Web Adaptor к вашей функции.
arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerX86:23
arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerArm64:23
arn:aws-cn:lambda:cn-north-1:041581134020:layer:LambdaAdapterLayerX86:23
arn:aws-cn:lambda:cn-northwest-1:069767869989:layer:LambdaAdapterLayerX86:23
настройте переменную среды Lambda AWS_LAMBDA_EXEC_WRAPPER
на /opt/bootstrap
.
установите обработчик функции в сценарий запуска вашего веб-приложения. например, run.sh
Для получения подробной информации ознакомьтесь с примером приложения Node.js.
При запуске новой среды выполнения Lambda веб-адаптер Lambda загружается как расширение Lambda, а затем веб-приложение.
По умолчанию Lambda Web Adaptor отправляет HTTP-запросы GET веб-приложению по адресу http://127.0.0.1:8080/
. Порт и путь можно настроить с помощью двух переменных среды: AWS_LWA_READINESS_CHECK_PORT
и AWS_LWA_READINESS_CHECK_PATH
.
Lambda Web Adaptor будет повторять этот запрос каждые 10 миллисекунд, пока веб-приложение не вернет ответ HTTP ( код состояния >= 100 и < 500 ) или пока не истечет время ожидания функции.
Кроме того, вы можете настроить адаптер для предварительной проверки готовности с помощью TCP-соединения, установив для AWS_LWA_READINESS_CHECK_PROTOCOL
значение tcp
.
После прохождения проверки готовности Lambda Web Adaptor запустит среду выполнения Lambda и перенаправит вызовы в веб-приложение.
Порт/путь проверки готовности и порт трафика можно настроить с помощью переменных среды. Эти переменные среды могут быть определены либо в файле Docker, либо как конфигурация функции Lambda.
Переменная среды | Описание | По умолчанию |
---|---|---|
AWS_LWA_PORT / ПОРТ* | порт трафика | "8080" |
AWS_LWA_READINESS_CHECK_PORT / READINESS_CHECK_PORT* | Порт проверки готовности, по умолчанию порт трафика | ПОРТ |
AWS_LWA_READINESS_CHECK_PATH / READINESS_CHECK_PATH* | путь проверки готовности | "/" |
AWS_LWA_READINESS_CHECK_PROTOCOL / READINESS_CHECK_PROTOCOL* | Протокол проверки готовности: «http» или «tcp», по умолчанию «http» | "http" |
AWS_LWA_READINESS_CHECK_MIN_UNHEALTHY_STATUS | Минимальный код состояния HTTP, который считается неработоспособным. | "500" |
AWS_LWA_ASYNC_INIT/ASYNC_INIT* | включить асинхронную инициализацию для длинных функций инициализации | "ЛОЖЬ" |
AWS_LWA_REMOVE_BASE_PATH / REMOVE_BASE_PATH* | базовый путь, который нужно удалить из пути запроса | Никто |
AWS_LWA_ENABLE_COMPRESSION | включить сжатие gzip для тела ответа | "ЛОЖЬ" |
AWS_LWA_INVOKE_MODE | Режим вызова лямбда-функции: «buffered» или «response_stream», по умолчанию — «buffered». | "буферизованный" |
AWS_LWA_PASS_THROUGH_PATH | путь для получения полезных данных событий, передаваемых от триггеров, отличных от HTTP. | "/события" |
AWS_LWA_AUTHORIZATION_SOURCE | имя заголовка, которое необходимо заменить на Authorization | Никто |
Примечание. Мы используем префикс «AWS_LWA_» для пространства имен всех переменных среды, используемых Lambda Web Adaptor. Оригинальные будут поддерживаться до тех пор, пока мы не достигнем версии 1.0.
AWS_LWA_PORT/PORT — Lambda Web Adaptor будет отправлять трафик на этот порт. Это порт, который прослушивает ваше веб-приложение. Внутри среды выполнения Lambda веб-приложение запускается от имени пользователя без полномочий root, и ему не разрешено прослушивать порты ниже 1024. Также избегайте портов 9001 и 3000. API среды выполнения Lambda находится на порту 9001. Расширение CloudWatch Lambda Insight использует порт 3000. .
AWS_LWA_ASYNC_INIT/ASYNC_INIT — управляемые среды выполнения Lambda предлагают до 10 секунд для инициализации функции. В течение этого периода времени функции Lambda загружают процессор для ускорения инициализации, и это бесплатно. Если лямбда-функция не сможет завершить инициализацию в течение 10 секунд, Lambda перезапустит функцию и выставит счет за инициализацию. Чтобы помочь функциям использовать эти 10 секунд свободного времени инициализации и избежать перезапуска, Lambda Web Adaptor поддерживает асинхронную инициализацию. Когда эта функция включена, Lambda Web Adaptor выполняет проверку готовности до 9,8 секунды. Если к этому времени веб-приложение не готово, Lambda Web Adaptor сигнализирует службе Lambda о завершении инициализации и продолжает проверку готовности в обработчике. Эта функция отключена по умолчанию. Включите его, установив для переменной среды AWS_LWA_ASYNC_INIT
значение true
.
AWS_LWA_REMOVE_BASE_PATH/REMOVE_BASE_PATH — значение этой переменной среды сообщает адаптеру, выполняется ли приложение по базовому пути. Например, вы могли бы настроить свой API-шлюз так, чтобы он имел ресурсы /orders/{proxy+} и /catalog/{proxy+}. Каждый ресурс обрабатывается отдельной функцией Lambda. По этой причине приложение внутри Lambda может не знать о существовании пути /orders. Используйте REMOVE_BASE_PATH, чтобы удалить префикс /orders при маршрутизации запросов к приложению. По умолчанию пустая строка. Ознакомьтесь с примером SpringBoot.
AWS_LWA_ENABLE_COMPRESSION — Lambda Web Adaptor поддерживает сжатие gzip для тела ответа. Эта функция отключена по умолчанию. Включите его, установив для переменной среды AWS_LWA_ENABLE_COMPRESSION
значение true
. Если этот параметр включен, ответы будут сжиматься, если только это не изображение, определенное типом контента, начинающимся с image
, или если размер ответа не превышает 32 байта. Это также сожмет фрагментированный потоковый ответ HTTP/1.1.
AWS_LWA_INVOKE_MODE — режим вызова лямбда-функции, он должен соответствовать режиму вызова URL-адреса функции. По умолчанию установлено «буферизовано». При настройке «response_stream» Lambda Web Adaptor будет передавать ответ в блог службы Lambda. Пожалуйста, ознакомьтесь с примером FastAPI с потоковой передачей ответов.
AWS_LWA_READINESS_CHECK_MIN_UNHEALTHY_STATUS — позволяет настроить, какие коды состояния HTTP считаются исправными, а какие нет.
AWS_LWA_PASS_THROUGH_PATH — путь для получения полезных данных событий, передаваемых от триггеров событий, отличных от HTTP. По умолчанию используется «/events».
AWS_LWA_AUTHORIZATION_SOURCE — если этот параметр установлен, Lambda Web Adaptor заменяет указанное имя заголовка на Authorization
перед проксированием запроса. Это полезно, когда вы используете URL-адрес функции Lambda с типом аутентификации IAM, который резервирует заголовок авторизации для аутентификации IAM, но вы хотите по-прежнему использовать заголовок авторизации для своих серверных приложений. Эта функция отключена по умолчанию.
Контекст запроса — это метаданные, которые API-шлюз отправляет в Lambda для запроса. Обычно он содержит requestId, requestTime, APIId, идентификатор и авторизатор. Идентификатор и авторизатор полезны для получения идентификатора клиента для авторизации. Руководство разработчика API Gateway содержит более подробную информацию здесь.
Lambda Web Adaptor пересылает эту информацию веб-приложению в HTTP-заголовке с именем «x-amzn-request-context». В веб-приложении вы можете получить значение этого HTTP-заголовка и десериализовать его в объект JSON. Ознакомьтесь с Express.js в Zip, чтобы узнать, как его использовать.
Lambda Context — это объект, который Lambda передает обработчику функции. Этот объект предоставляет информацию о вызове, функции и среде выполнения. Полный список свойств, доступных через контекст Lambda, можно найти здесь.
Lambda Web Adaptor пересылает эту информацию веб-приложению в HTTP-заголовке с именем «x-amzn-lambda-context». В веб-приложении вы можете получить значение этого HTTP-заголовка и десериализовать его в объект JSON. Ознакомьтесь с Express.js в Zip, чтобы узнать, как его использовать.
Для функции с зарегистрированными расширениями Lambda Lambda включает фазу завершения функции. Когда служба Lambda собирается завершить работу среды выполнения Lambda, она отправляет сигнал SIGTERM в среду выполнения, а затем событие SHUTDOWN каждому зарегистрированному внешнему расширению. Разработчики могли перехватывать сигнал SIGTERM в лямбда-функциях и корректно выполнять задачи завершения работы. Express.js дает простой пример. Более подробная информация в этом репо.
Lambda Web Adaptor позволяет разработчикам разрабатывать веб-приложения локально с помощью знакомых инструментов и отладчиков: просто запустите веб-приложение локально и протестируйте его. Если вы хотите локально смоделировать среду выполнения Lambda, вы можете использовать AWS SAM CLI. Следующая команда запускает локальную конечную точку шлюза API и моделирует среду выполнения Lambda.
sam local start-api
Обратите внимание, что sam local
запускает эмулятор интерфейса времени выполнения Lambda на порту 8080. Поэтому ваше веб-приложение должно избегать порта 8080
если вы планируете использовать sam local
.
Веб-адаптер Lambda также поддерживает все триггеры событий, отличные от HTTP, такие как SQS, SNS, S3, DynamoDB, Kinesis, Kafka, EventBridge и агенты Bedrock. Адаптер пересылает полезную нагрузку события в веб-приложение через HTTP-сообщение по пути, определенному переменной среды AWS_LWA_PASS_THROUGH_PATH
. По умолчанию этот путь установлен как /events
. Получив полезные данные события из тела запроса, веб-приложение должно обработать их и вернуть результаты в виде ответа JSON. Пожалуйста, ознакомьтесь с примерами SQS Express.js и Bedrock Agent FastAPI в Zip.
Этот проект был вдохновлен несколькими общественными проектами.
Некоторые проекты также предоставляют аналогичные возможности в виде пакетов/фреймворков для конкретного языка.
См. ВКЛАД для получения дополнительной информации.
Этот проект распространяется по лицензии Apache-2.0.