Сбой развертывания без сервера при проверке прогресса стека

Question

Проблема:

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

Serverless: Updating Stack...
Serverless: Checking Stack update progress...
.........................
Serverless: Operation failed!

  Serverless Error ---------------------------------------

  An error occurred: MyimportfunctionEventsRuleSchedule1 - schedule-full-import already exists in stack Cloudformation_StackId_of_production_lambda_function.

EDIT : Функция полного импорта по расписанию предназначена только для производственной среды, а не для промежуточной среды. Насколько я понимаю, когда я пытаюсь выполнить развертывание, он просто пытается найти триггер для промежуточной среды. В этом случае он не находит его и затем идет к производственной среде.

serverless.yml

schedule_full_import:
    handler: my_handler
    timeout: 6
    events:
      - schedule:
          enabled: true
          name: full-data-import
          rate: rate(10 minutes)
          stageParams:
            stage: prod

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

Answer 1

Я считаю, что проблема в том, что stageParams не делает то, что вы думаете, что он делает. Он не присоединяет лямбду к триггеру Cloudwatch только на стадии разработки. Документы без сервера (https://serverless.com/framework/docs/providers/aws/events/schedule/) имеют сбивающий с толку пример, в котором в качестве входного значения для триггера указывается stageParams. Все это означает, что Cloudwatch будет вызывать лямбду со значением input в качестве данных события.

Невозможно выборочно не развертывать ресурсы, перечисленные в serverless.yml, в зависимости от этапа. То, что вы могли бы сделать, это установить enabled в значение false, когда stage не вызывается с использованием некоторых пользовательских параметров конфигурации. Это позволит развернуть триггер в вашей промежуточной среде, но он не будет вызван.

Ошибка CloudFormation также предполагает наличие конфликта имен. Бессерверный сервер должен генерировать уникальные лямбда-имена на основе стадии, поэтому, если бы мне пришлось угадывать, имя расписания full-data-import не уникально. Я бы попробовал переименовать его в что-то вроде

name: full-data-import-${self:provider.stage}

В зависимости от того, как вы ссылаетесь на ваш параметр сцены.

Вы можете попробовать что-то вроде:

custom:
    importEnabled: <set this by config file, command line argument, environment variable, etc>

functions:
    schedule_full_import:
        handler: my_handler
        timeout: 6
        events:
            - schedule:
                  name: full-data-import-${self:provider.stage}
                  enabled: ${self:custom.importEnabled}
                  rate: rate(10 minutes)

См. https://serverless.com/framework/docs/providers/aws/guide/variables/ о способах установки значения importEnabled

Answer 2

Вы можете удалить существующий стек CloudFormation вручную, если $ sls remove не работает.

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