web-dev-qa-db-ja.com

Lambdaエンドポイントを破壊せずにサーバーレス経由で作成されたリソースを破壊する

Serverless.ymlファイルに次のリソースが定義されています。私のさまざまな開発段階すべてのリソースを作成するのに最適です。

resources:
  Resources:
    uploadBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:service}-${self:custom.stage}-uploads
    visitsTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:custom.visitsTable}
        AttributeDefinitions:
          - AttributeName: userId
            AttributeType: S
          - AttributeName: visitId
            AttributeType: S
        KeySchema:
          - AttributeName: userId
            KeyType: HASH
          - AttributeName: visitId
            KeyType: RANGE
        ProvisionedThroughput:
            ReadCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}
            WriteCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}

問題は...私がsls removeデータベースを削除すると、ラムダ関数とそのapiゲートウェイエンドポイントを含む他のすべても削除されます。これらにはポリシーが明示的に設定されているため、そのままにしておく必要があります。 サーバーレスにデータベースまたはS3のみ、またはそれが何であれ、残りは削除しないように指示するにはどうすればよいですか？

私が試したこと：

AWSで手動で削除しましたが、これを実行してslsデプロイを実行しても、データベースは再度作成されません！したがって、これを行う最善の方法がわかりません...

Serverless.ymlファイル全体

service: mydomain-api

# Use serverless-webpack plugin to transpile ES6/ES7
plugins:
  - serverless-webpack
  - serverless-domain-manager

custom:
  webpackIncludeModules: true
  stage: ${opt:stage, self:provider.stage}
  visitsTable: "${self:service}-visits-${self:custom.stage}"
  domains:
    prod: api.mydomain.com
    staging: staging-api.mydomain.com
    dev: dev-api.mydomain.com
  dynamoDbCapacityUnits:
    prod: 5
    staging: 2
    dev: 2
  customDomain:
    basePath: ""
    domainName: ${self:custom.domains.${self:custom.stage}}
    stage: "${self:custom.stage}"
    certificateName: "mydomain.com"
    createRoute53Record: true

provider:
  name: aws
  runtime: nodejs6.10
  stage: prod
  region: us-east-1
  environment:
    VISITS_TABLE: ${self:custom.visitsTable}

  # 'iamRoleStatement' defines the permission policy for the Lambda function.
  # In this case Lambda functions are granted with permissions to access DynamoDB.
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:DescribeTable
        - dynamodb:Query
        - dynamodb:Scan
        - dynamodb:GetItem
        - dynamodb:PutItem
        - dynamodb:UpdateItem
        - dynamodb:DeleteItem
      Resource: "arn:aws:dynamodb:us-east-1:*:*"

functions:
  create:
    handler: src/visits/create.main
    events:
      - http:
          path: visits
          method: post
          cors: true
          authorizer: aws_iam
  get:
    handler: src/visits/get.main
    events:
      - http:
          path: visits/{id}
          method: get
          cors: true
          authorizer: aws_iam
  list:
    handler: src/visits/list.main
    events:
      - http:
          path: visits
          method: get
          cors: true
          authorizer: aws_iam
  update:
    handler: src/visits/update.main
    events:
      - http:
          path: visits/{id}
          method: put
          cors: true
          authorizer: aws_iam
  delete:
    handler: src/visits/delete.main
    events:
      - http:
          path: visits/{id}
          method: delete
          cors: true
          authorizer: aws_iam

resources:
  Resources:
    uploadBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: ${self:service}-${self:custom.stage}-uploads
    visitsTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: ${self:custom.visitsTable}
        AttributeDefinitions:
          - AttributeName: userId
            AttributeType: S
          - AttributeName: visitId
            AttributeType: S
        KeySchema:
          - AttributeName: userId
            KeyType: HASH
          - AttributeName: visitId
            KeyType: RANGE
        ProvisionedThroughput:
            ReadCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}
            WriteCapacityUnits: ${self:custom.dynamoDbCapacityUnits.${self:custom.stage}}
amazon-web-servicesaws-lambdaaws-api-gatewayserverless-frameworkserverless
6
Joseph Astrahan

サーバーレスフレームワークのドキュメント はsls removeについて次のように述べています。

sls removeコマンドは、現在の作業ディレクトリで定義されているデプロイ済みサービスをプロバイダーから削除します。

したがって、sls removeは進むべき道ではありません。 serverless.yamlからvisitsTableリソースを削除し、sls deployを再度実行するだけです。サーバーレスフレームワークは、内部でAWSCloudFormationを使用します。したがって、手動で削除することはお勧めできません。覚えておいてください：AWS CloudFormationスタックの一部として作成されたリソースは、スタックの更新を通じて管理および変更する必要があります。多分これは良い読み物です：- https://virtualbonzo.com/2017/12/11/did-you-manually-delete-a-resource-created-by-aws-cloudformation/

5
dom

スタックの削除時に削除したくないリソースのDeletionPolicyを「保持」に設定すると、sls removeを実行すると残りのリソースが削除されます。

resources:
  Resources:
    uploadBucket:
      Type: AWS::S3::Bucket
      DeletionPolicy: Retain
      ...

https://docs.aws.Amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html

2
Jordan

サーバーレスフレームワークはCloudFormationテンプレートを生成します。

CloudFormationテンプレートを初めて実行すると、すべてのリソースが作成されます。

後で実行すると、新しいバージョンと以前のバージョンが比較され、違いを補うための計画が生成されます。これは、リソースの追加または削除である可能性があります。これにはいくつかの例外があり、通常はS3バケットなどのデータリソースタイプであり、強制的に削除する必要があります。

したがって、質問に答えるには、不要になったリソースをserverless.ymlファイルから削除し、sls deployを再度実行する必要があります。

1
Matt D