Configuration .ebextensions AWS Beanstalk pour les tables DynamoDB

Question

Nous développons une application Java Spring Boot avec DynamoDB. J'essaye de créer quelques tables dans DynamoDB en utilisant .ebextensions. Jusqu'à présent, j'ai réussi à déployer le fichier jar généré avec le dossier .ebextensions inclus dans le cli eb. A l'intérieur, j'ai un fichier database.config avec le contenu suivant:

Resources: 
Book: 
    Type: AWS::DynamoDB::Table 
    Properties: 
    TableName: Book 
    KeySchema: 
     HashKeyElement: {AttributeName: id, AttributeType: S} 
    ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1} 

Subject: 
    Type: AWS::DynamoDB::Table 
    Properties: 
    TableName: Subject 
    KeySchema: 
     HashKeyElement: {AttributeName: id, AttributeType: S} 
    ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1} 

User: 
    Type: AWS::DynamoDB::Table 
    Properties: 
    TableName: User 
    KeySchema: 
     HashKeyElement: {AttributeName: id, AttributeType: S} 
    ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1} 

Pour une raison quelconque, seule la dernière table de la liste (utilisateur) est créé. Une idée de pourquoi les deux autres ne sont pas créés? Si j'en garde seulement un dans le script, celui-ci est créé comme prévu.

Quelqu'un a-t-il une meilleure idée pour créer et mettre à jour des tables DynamoDB sur un nouveau déploiement? Les fichiers de configuration .ebextensions sont utiles, mais nous devons nous assurer qu'ils contiennent les informations correctes avant chaque publication.

Merci, Cristian.

Answer 1

La réponse du support technique AWS:

Je comprends que vous ayez du mal à créer des tables DynamoDB en utilisant la fonction ebextension de Stalk élastique Bean lors du déploiement à travers des outils CLI. Afin de comprendre pourquoi cela est arrivé, il est important de comprendre que Elastic Bean Stalk utilise CloudFormation pour adapter les ressources et la configuration. J'ai remarqué que les tables [User, Book, Subject] ont été créées à l'origine à partir de la précédente pile CloudFormation dans ce cas une pile Beanstalk antérieure. Comme les tables ont été créées dans la pile précédente, la création la plus récente a échoué et a tenté de revenir en arrière. Dans ce processus de rétrogradation, les ressources supprimées de la formation précédente ont été supprimées, car il s'agissait d'un échec et les tables partageaient le même nom. Ce bug a été signalé à notre équipe interne. Pour l'avenir, je comprends que vous êtes en train de tester et de migrer vers AWS. Je recommande de reconstruire la pile Beanstalk [1] liée à cela et redémarrer le déploiement sans partager les noms de ressources pour les tables DynamoDB.