search

aws-samples / public-file-browser-for-amazon-s3

Sample code to deploy a website and a "public files" S3 bucket which can be loaded with any files an administrator wishes to publish publicly online.
MIT No Attribution
104 stars 17 forks source link

Unable to Deploy - Repeatable - Problem with Custom Resource #8

Closed rpattcorner closed 5 months ago

rpattcorner commented 5 months ago

The application repeatedly won't deploy for me. All goes well until the Custom::SeedS3Data, which fails with the message below. I've checked the lambda, which does indeed exist, but creates no cloudwatch logs to examine.

CREATE_FAILED Custom::SeedS3Data SeedS3Data CloudFormation did not
receive a response from
your Custom Resource.
Please check your logs for requestId [1ed80...02bea0f].
If you are using the
Python cfn-response
module, you may need to
update your Lambda
function code so that
CloudFormation can attach
the updated version.

Other aspects of the deploy appear to have been successful.

  1. Could you please advise me on debugging suggestions?
  2. It appears that there are two stacks in the initial deploy ... an aws-sam-cli-managed-default stack which CREATE_COMPLETE that appears to persist across deploy attempts, and a public-file-browser stack that is created (and must be tediously manually destroyed` with each deploy attempt. In debugging should I remove both stacks between attempts, or just the newly created one?
  3. My understanding is that the fail is on the lambda response that triggers stack completion. It looks like all the lambda work is just to populate the files bucket, which I'm quite happy to do by hand for the research purposes I'm carrying out. Do you have any suggestions for simply eliminating the file upload stage so I can examine a working deploy?
  4. I was surprised that bucket destruction wasn't blocking successive runs, as CFN used to do. Should I be manually destroying the buckets anyway between attempts?

One last note ... I made some efforts to implement, test and research the main.js application, and found that there seemed to be an asynchronous call problem in listing the files bucket, where the creds from the Cognito Identity call arrived after the call to ListBucketsV2. Has that been a problem in past?

ckabalan commented 5 months ago

@rpattcorner, this looks like it might be a duplicate of #5 .

Did you follow the deployment instructions step-by-step, including the prerequisites and notably the "sam build" step? I suspect just like in #5, the issue is the Custom Resource doesn't have the crhelper library to report status back to CloudFormation.

1 - Usually CloudWatch Logs would be the best approach, but... 2 - The default stack is for SAM to upload the templates and Lambda ZIPs, so yes persists across deployments and stacks, it's a staging ground for SAM, non-specific to any deployment. Just delete the public-file-browser stack. 3 - You could comment out the Custom::SeedS3Data resource in the template, but does two things: modifies the website files to be specific to your bucket, and uploads them to S3. You'd have to look at the code and reverse engineer the entries in the index.html file. 4 - Up to you. The buckets are uniquely named based on stack-id (intentionally to prevent this), and persisted even when the stack is deleted because we don't want customers to accidentally lose data.

On your last note, I've never seen this. I'll double check the code again but this should happen in sequence.

If you do still have issues please report back with a full copy-paste of your commands to SAM (start to finish) so I can double check there isn't anything I'm not considering from memory.

rpattcorner commented 5 months ago

Definitely built, but no solution. Rewrote.