безсерверные - динамо потоки - как настроить destinationConfig? - PullRequest
Новая
       7

безсерверные - динамо потоки - как настроить destinationConfig?

0 голосов
/ 20 апреля 2020

У меня есть следующая лямбда-конфигурация: 

MyFunc:
handler: my_handler
timeout: 60
role: myrole
events:
  - stream:
      type: dynamodb
      arn: <<dynamo_db_stream_arn>
      startingPosition: LATEST
      maximumRetryAttempts: 3
      destinations:
        onFailure: <sqs_queue_arn>
      enabled: True

Тем не менее, при развертывании я не вижу, что onFailure даже отображается в шаблоне облачной информации. я настроил это, как сказано в этой документации: https://serverless.com/framework/docs/providers/aws/events/streams/

Есть идеи, что мне не хватает?

========= =================

Итак, завершая ответ Snickers3192 - я на самом деле не уверен, что не так с конфигурацией выше, так как безсерверный сервер должен ее поддерживать, но в конечном итоге что я создал потоковый обработчик в другом ресурсе, поэтому мой серверный сервер выглядит так: 

functions:
  MyFunc:
  handler: my_handler
  timeout: 60
  role: myrole

resources:
  Resources:
    MySourceMapping:
      Type: AWS::Lambda::EventSourceMapping
      DependsOn: MyFuncLambdaFunction
      Properties:
        EventSourceArn: <dynamo_db_stream_arn>
        FunctionName: MyFunc
        MaximumRetryAttempts: 3
        StartingPosition: LATEST
        DestinationConfig:
          OnFailure:
            Destination: <sqs_queue_qrn>

1 Ответ

0 голосов
/ 21 апреля 2020

Несмотря на то, что мне нравится serverless framework, я не рекомендую использовать его ни для чего, кроме разработки функций Lambda, я бы даже не использовал событие http для создания шлюза API. Придерживайтесь философии unix, делайте одно хорошее, вот как я чувствую, что безсерверный должен придерживаться этого, а не пытаться стать другой терраформой или чем-то еще, это не так. это оно. Делай другие вещи где-нибудь еще. Если ресурс может эффективно управляться в Cloudformation AWS::Lambda::EventSourceMapping, то вы можете использовать это. Если имеет смысл поместить его внизу serverless.yml в resources:, вы можете сделать это, но если нет, то пусть у него будет свой собственный шаблон.

Для этого достаточно много разрешений настраивая вашу лямбду для потоков DynamoDB, я бы не стал доверять serverless, чтобы сделать это для вас. Правильная настройка AWS prod также может не позволить некоторому внешнему инструменту также создавать роли iam.

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

...