AWS lambda вызывает не вызов другой лямбда-функции - Node.js

После предоставления всех прав на вызов функции. Моя функция Lambda не может вызвать другую функцию. Каждый раз, когда я получаю тайм-аут с проблемой 30 seconds timeout. Похоже, что лямбда не может получить другую лямбда-функцию.

Мои лямбды находятся в одном регионе, в той же политике, в той же группе безопасности. Также VPC одинаковы в обоих лямбдах. Теперь единственное отличие - это лямбда-функции

Вот роли прав

1) создал AWSLambdaExecute и AWSLambdaBasicExecutionRole

2) Создала одну лямбда-функцию, которая должна называться Lambda_TEST

exports.handler = function(event, context) {
  console.log('Lambda TEST Received event:', JSON.stringify(event, null, 2));
  context.succeed(event);
};

3) Вот еще одна функция, из которой она вызывается.

var AWS = require('aws-sdk');
AWS.config.region = 'us-east-1';
var lambda = new AWS.Lambda();

exports.handler = function(event, context) {
 var params = {
   FunctionName: 'Lambda_TEST', // the lambda function we are going to invoke
   InvocationType: 'RequestResponse',
   LogType: 'Tail',
   Payload: '{ "name" : "Arpit" }'
 };

  lambda.invoke(params, function(err, data) {
   if (err) {
    context.fail(err);
   } else {
   context.succeed('Lambda_TEST said '+ data.Payload);
  }
 })
};

Ссылка взята из: Эта ссылка

Ответы

Ответ 1

Примечание

Я буду обозначать исполнителем lambda, который выполняет второй lambda.

Почему тайм-аут?

Поскольку исполнитель "заблокирован" за VPC, блокируются все интернет-коммуникации.

Это приводит к тому, что любые вызовы http(s) должны быть отключены, так как они запрашивают, чтобы пакет никогда не попадал в пункт назначения.

Вот почему все действия, выполняемые aws-sdk, приводят к таймауту.

Простое решение

Если исполнитель не имеет имеет в VPC - просто вытащил его из него, lambda может работать без VPC.

Поиск lambda в VPC требуется, когда lambda вызывает ресурсы внутри VPC.

Реальное решение

Из вышесказанного следует, что любой ресурс, расположенный внутри a VPC, не может получить доступ к Интернету - , что неверно. - нужно всего несколько конфигураций.

  • Создайте VPC.
  • Создайте 2 подсети, пусть их можно обозначить как закрытые и второй публичные (эти термины объясняются впереди, продолжайте читать).
  • Создайте интернет-шлюз - это виртуальный маршрутизатор, который подключает VPC к Интернету.
  • Создайте NAT-шлюз - выберите подсеть public и создайте для него новый elastic IP (этот IP-адрес является локальным для вашего VPC) - этот компонент будет передавать сообщения в internet-gateway.

  • Создайте 2 таблицы маршрутизации - один из них называется public и второй private.

    • В общедоступной таблице маршрутизации перейдите на Маршруты и добавьте новый маршрут:

    Назначение: 0.0.0.0/0

    Цель: идентификатор internet-gateway

    1. В приватной таблице маршрутизации перейдите в "Маршруты" и добавьте новый маршрут:

Назначение: 0.0.0.0/0

Цель: идентификатор nat-gateway

  • Частная подсеть - это подсеть, которая в своей таблице маршрутизации - там нет маршрута к internet-gateway.

  • Публичная подсеть - это подсеть, которая в своей таблице маршрутизации - там существует маршрут к internet-gateway

Что у нас было?

Мы создали что-то вроде этого:

VPC с NAT и IGW

Это, что позволяет ресурсам в частных подсетях вызывать Интернет. Вы можете найти дополнительную документацию здесь.

Ответ 2

У меня возникла такая же проблема, когда Lambdas, "привязанные" к VPC, не могут ссылаться на другие Lambdas. Я занимаюсь этой проблемой, не используя NAT, путем реорганизации структуры моего решения.

Скажем, у меня есть несколько lambdas, A, B, C, D,... и я бы хотел, чтобы эти Lambdas имели доступ к базе данных RDS. Чтобы иметь этот доступ к БД, мне нужно поставить лямбда в том же VPC, что и база данных. Но мне также нравятся различные лямбды среди A, B, C, D,... для вызова друг друга. Поэтому я столкнулся с проблемой, которую описывает Арпит.

Я занимаюсь этой проблемой, разбивая каждую Лямбду на два Lambdas: тот, который фокусируется на потоке процесса (т.е. вызывает другие lambdas и вызывается другой лямбдой); а другой сосредоточен на выполнении "реальной" работы, например, при запросе базы данных. Итак, теперь у меня есть функции A_flow, B_flow, C_flow, D_flow,...; и функции A_worker, B_worker, C_worker, D_worker,... Различные течения lambdas не привязаны к определенному VPC, и поэтому могут ссылаться на другие lambdas. Различные рабочие Lambdas находятся в том же VPC, что и база данных, и могут запрашивать БД.

Каждый поток лямбда "делегирует" работу по взаимодействию с БД соответствующей рабочей лямбде. Он делает эту делегацию, выполняя синхронный вызов рабочего лямбда. Рабочие лямбды не призывают других лямбдов. (В терминах графика потока процессов рабочие лямбды являются конечными узлами.) В моей собственной системе вызовы потока Lambdas другими лямбдами потока обычно были асинхронными; но я полагаю, что они могут быть синхронными, если это необходимо.

Несмотря на то, что я разработал этот подход в качестве обходного пути, у него есть хорошая особенность: чистое разделение высокоуровневой функциональной структуры на (а) поток процессов и (б) выполнение более детальной работы, включая взаимодействие с ресурсами БД.