Как реализовать псевдоним для функции шага в Serverless Framework - PullRequest
0 голосов
/ 04 декабря 2018

В моем проекте я использую serverless-aws-alias вместе с serverless для развертывания своего кода и всего в AWS.У меня есть лямбда-функции, которые имеют псевдоним для dev и prod версий.Каждый раз, когда я вносил изменения, я сначала использовал бы серверную утилиту командной строки для развертывания версии dev и проверял, что все в порядке, прежде чем использовать тот же инструмент для развертывания версии prod.

Это прекрасно работает (более или менее), но когда я попытался включить определение пошаговой функции в мой файл serverless.yml, я столкнулся с ограничением.Хотя лямбда-функции могут иметь версии и псевдонимы в AWS, пошаговые функции не имеют такой функциональности.До сих пор я проверял это (что является ошибкой):

stepFunctions:
  stateMachines:
    MyStepFunction:
      name: MyStepFunction-${opt:alias}
      .
      .
      .

Хотя при этом создается пошаговая функция, подобная MyStepFunction-dev, но проблема в том, что, как только я создаю prod версия, она удалит версию dev (сервер не предполагает, что я переименовываю функцию шага).Еще хуже, если я создаю версию dev, она удалит версию prod, что, конечно, недопустимо.

Кто-нибудь знает, как у меня могут быть две пошаговые функции, одна для dev и однадля prod, реализовано с одним определением в моем serverless.yml?

Ответы [ 2 ]

0 голосов
/ 13 декабря 2018

Вот как я реализовал это (не обязательно лучшее решение для всех):

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

Мой файл лямбда-функции yaml будет выглядеть так:

service:                      Lambda-Functions

provider:
  name:                       aws
  stage:                      ${opt:stage, 'dev'}

plugins:
- serverless-aws-alias
- serverless-pseudo-parameters

functions:
  func1:
    name:                     func1
    handler:                  src/func1.handler
    environment:
      STEP_FUNCTIONS_ARN:     arn:aws:states:#{AWS::Region}:#{AWS::AccountId}:stateMachine:MyStepFunction-${opt:alias}

И я разверну его так:

$ sls deploy --stage dev --alias dev
$ sls deploy --stage dev --alias prod

Другой файл yaml (для пошаговых функций) будет выглядеть так:

service:                 Step-Functions

provider:
  name:                  aws
  stage:                 ${opt:stage, 'dev'}

plugins:
- serverless-step-functions
- serverless-pseudo-parameters

stepFunctions:
  stateMachines:
    MyStepFunction:
      name:              MyStepFunction-${opt:stage}
        definition:
          StartAt:       StartState
          States:
            StartState:
              Type:      Task
              Resource:  arn:aws:lambda:#{AWS::Region}:#{AWS::AccountId}:function:some-func:${opt:stage}
              Next:      SomeState

И я разверну его так:

$ sls deploy --stage dev
$ sls deploy --stage prod

Я не говорю, что это безупречно, но это работает.В приведенном выше примере предполагается, что func1 создает экземпляр функции шага MyStepFunction, поэтому для него требуется ARN функции шага.

0 голосов
/ 06 декабря 2018

Вместо использования псевдонимов, подобных этому, я бы предложил использовать «стадии» в Serverless.

provider:
  name: aws
  runtime: nodejs8.10
  stage: ${opt:stage, 'dev'} # Set the default stage used. Default is dev

Тогда, если назвать вашу функцию шага, это будет что-то вроде:

stepFunctions:
  stateMachines:
    MyStepFunction:
      name: MyStepFunction-${opt:stage}

Тогда при развертывании это будет что-то вроде sls deploy --stage dev или sls deploy --stage prod.Это будет использовать два разных стека, и вы не столкнетесь с тем, что материал удаляется, потому что он думает, что вы его переименовали!

...