Это довольно старый вопрос, но он все еще отображается в топ-5 результатов Google, поэтому вот вам небольшая информация: неплохо разделить бессерверный стек на несколько служб, каждая из которых имеет свой собственный serverless.yml файл. Один для вашего API и лямбда-выражений, один для DynamoDB. Таким образом, вы можете работать с ними отдельно и обновлять свои лямбды, не касаясь своей БД. Вот отличное руководство по этому поводу:

1. https://serverless-stack.com/chapters/organizing-serverless-projects.html
2. https://serverless-stack.com/chapters/dynamodb-as-a-serverless-service.html
3. https://serverless-stack.com/chapters/deploying-multiple-services-in-serverless.html

Сделайте резервную копию таблицы и удалите ее. Восстановите после развертывания.

У меня была такая же проблема, когда я переименовал свой бессерверный проект и попытался развернуть. У меня была таблица tanks, которую снова использовали. Не удалось со следующим

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

 An error occurred: TanksDynamoDbTable - tanks already exists in stack arn:aws:cloudformation:eu-central-1:592235674655:stack/colossal-dev/105693a8-77af-11e9-8f9e-2a86e4085a59.

Я решил эту проблему, сделав резервную копию таблицы баков, а затем удалив ее.

1. Консоль> DynamoDB
2. Слева выберите Резервные копии
3. Создать резервную копию> выберите Таблица из раскрывающегося списка и дайте ей имя> Создать
4. Слева выберите Таблицы
5. Проверить танки> Удалить

После удаления нужно подождать пять минут, потому что кеши очищаются периодически, а не сразу. После этого я попробовал serverless deploy, и это сработало. После этого вам нужно будет восстановить резервную копию базы данных.

1. Слева выберите Резервные копии
2. Проверьте резервную копию таблицы> Восстановить
3. Введите то же имя для таблицы, что и раньше, в качестве имени новой таблицы.
4. Таблица восстановления. Восстановление базы данных занимает некоторое время, поэтому подождите, возможно, пять минут, а может и дольше.

Невозможно банкомат с [email protected].

Я просто открываю вопрос на github: https://github.com/serverless/serverless/issues/3183

Пожалуйста, всем, кому нужна эта функция, присоединяйтесь к обсуждению.

Я буду обновлять здесь новости.

У меня была такая же проблема, и удаление xxxDynamoDbTable в serverless.yml, этот элемент уже существует в вашем Dynamodb, может работать. вам не нужно Resources это снова. : D

боролись с этим в течение 2 недель вместе с другими проблемами развертывания

теперь я бы сказал - таблица уже существует или очередь не существует, и, похоже, все, что вы пытаетесь нарушить `` безопасность '' стека:

• бессерверное приложение полагается на CloudFormation
• если ваше бессерверное развертывание пытается управлять ресурсом, который ему не принадлежит - у вас будет «уже существует ... (но не ваш)»;

так как я повторно развернул все с нуля и восстановил базы данных, у меня почти всегда стабильное развертывание с изменениями в ресурсах, пока кто-то из коллег не сделает что-то вручную)

так что лучше не иметь таких проблем:

• кивнуть добавить удалить изменить ресурсы вручную
• назовите их так, чтобы они не пересекались (например, dev-Table / prod-Table)
• использовать ресурсы как внешние по отношению к ресурсам стека с arns (или экспортированным ручным командам с бессерверными выходами);
• поиграйте с импортом ресурсов (групп ресурсов) в ваш стек

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

Если вам нужен один и тот же лямбда-шлюз API, вы можете добавить apiGateway ниже провайдера в качестве примера ниже.

Например:

• бессерверный A: DynamoDB и общедоступная конечная точка /, API Gateway имеют restApiId:xxxxx, restApiRootResourceId:yyyyyy

• бессерверный B: служба пользователя и общедоступная конечная точка /users

• бессерверный C: служба транспортных средств и общедоступная конечная точка /vehicle

serverless.yml бессерверный A

resources:
  Resources:
    VehiclesDynamoDbTable:
        Type: 'AWS::DynamoDB::Table'
        DeletionPolicy: Retain
        Properties:
          AttributeDefinitions:
            -
              AttributeName: id
              AttributeType: S
          KeySchema:
            -
              AttributeName: id
              KeyType: HASH
          ProvisionedThroughput:
            ReadCapacityUnits: 1
            WriteCapacityUnits: 1
          TableName: ${self:provider.environment.DYNAMODB_VEHICLE_TABLE}

     UsersDynamoDbTable:
        Type: 'AWS::DynamoDB::Table'
        DeletionPolicy: Retain
        Properties:
          AttributeDefinitions:
            -
              AttributeName: id
              AttributeType: S
          KeySchema:
            -
              AttributeName: id
              KeyType: HASH
          ProvisionedThroughput:
            ReadCapacityUnits: 1
            WriteCapacityUnits: 1
          TableName: ${self:provider.environment.DYNAMODB_USER_TABLE}

serverless.yml бессерверный B

provider:
  apiGateway
    restApiId: xxxxx # REST API resource ID. Default is generated by the framework
    restApiRootResourceId: yyyyyy # Root resource, represent as / path
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
        - dynamodb:DescribeTable
        Resource: "*"

serverless.yml бессерверный C

provider:
  apiGateway
    restApiId: xxxxx # REST API resource ID. Default is generated by the framework
    restApiRootResourceId: yyyyyy # Root resource, represent as / path
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
        - dynamodb:DescribeTable
        Resource: "*"

Убедитесь, что вы случайно не создали новый экземпляр стека CloudFormation, возможно, с другим именем. Если вы развертываете с тем же именем, что и уже существующий стек, он должен просто обновлять все.

Однако, если вы случайно создаете новый стек из-за изменения имени, например «my-app-prod» против «my-app-production», этот сбой может произойти из-за того, что ваш «my-app-prod» уже создал таблицы. и «my-app-production» пытается воссоздать те же самые таблицы, которые потерпят неудачу, поскольку они уже существуют.