Могу ли я настроить историю в памяти и использовать ее в AWS Lambda

#amazon-web-services #aws-lambda

#amazon-web-services #aws-lambda

Вопрос:

У меня есть функция lambda, которая прослушивает поток dynamo и обрабатывает записи для любого обновления или вставки в dynamo.

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

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

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

Могу ли я это сделать?

Комментарии:

1. используйте службу elasticache

2. Лучше всего хранить вне Lambda (в DynamoDB или где-либо еще), но вы также можете сохранить конфигурацию, если она небольшая, в качестве переменных среды лямбда-функции. Всякий раз, когда конфигурация изменяется, просто обновляйте эти переменные среды, и таким образом, Lambda всегда будет выполняться с последней конфигурацией, и ей не нужно будет ничего читать.

Ответ №1:

У меня есть мои лямбда-функции (nodejs), считывающие статические файлы конфигурации из файла yaml. При необходимости вы можете сделать то же самое с файлом json. Приложение также считывает динамические данные из S3 во время выполнения, отмечая, что это не то, что вы хотите сделать.

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

Единственным недостатком является то, что конфигурация должна быть загружена с функцией lamda при ее развертывании, чтобы она была доступна с другими ресурсами lambda во время выполнения. AFAIK, вы не можете выполнить обратную запись в конфигурацию во время выполнения.

Вы можете увидеть в папке проекта, которая у меня есть config.yml . Я использую модуль nodejs node-yaml-config для загрузки в память файла конфигурации каждый раз, когда создается экземпляр lambda. Для этого также не требуется никакого сетевого вызова.

файлы в проекте

В файле конфигурации у меня есть все необходимые параметры:

 # Handler runtime config set
default:
  sourceRssUri: http://www.sourcerss.com/rss.php?key=abcd1234
  bucket: myappbucket
  region: us-east-1
  dataKey: data/rssdata
  dataOutKey: data/rssdata
  rssKey: myrss.xml
 

Я загружаю конфигурацию во время выполнения, а затем могу ссылаться на любые элементы конфигурации в моем коде по имени ключа. Я просто так получилось, что я использую его для операций s3 здесь, вы можете делать все, что угодно.

 const yaml_config = require("node-yaml-config");
const config = yaml_config.load(__dirname   "/config.yml");

const aws = require("aws-sdk");
const bbpromise = require("bluebird");
const s3 = bbpromise.promisifyAll(new aws.S3({}));

var params = {
    Bucket: config.bucket,
    Key: config.dataOutKey,
    Body: JSON.stringify(feed.entries),
    ContentType: "application/json"
};
s3.putObjectAsync(params).catch(SyntaxError, function(e) {
    console.log("Error: ", e);
}).catch(function(e) {
    console.log("Catch: ", e);
});
 

Это упрощает добавление новой конфигурации для обработчика lambda, поскольку все, что я добавляю к config.yml таким, myNewVariable теперь доступно для ссылки в обработчике, как config.myNewVariable без какой-либо новой работы.

Это позволяет изменять конфигурацию для каждой среды или перед каждым развертыванием. Затем конфигурация загружается перед обработчиком и сохраняется локально в памяти в течение периода выполнения lambda.

Комментарии:

1. Амит Кумар не беспокойся. Если вы считаете, что это ответ, не стесняйтесь пометить его как ответ.

Ответ №2:

Нет, вы не можете. Lambda не имеет состояния — вы не можете рассчитывать на то, что все, что вы считываете в память при одном вызове, будет доступно для следующего вызова. Вам нужно будет где-то хранить информацию о конфигурации и каждый раз считывать ее обратно.