aws-samples / aws-saas-factory-serverless-workshop Goto Github PK

Need to add in Access-Control-Allow-Origin headers to the API Gateway resource to allow DELETE to be processed.

The configuration for the Auto Scaling Group only utilises EC2 Health Checks. When leaving the lab running over for a few days noticed that 502 errors were returned in the HTML site. tracking down the problem the ALB had the two backing EC2 instances marked as 'unhealthy' and therefore were not routing traffic. However they remained in the Autoscale pool as they were marked as Healthy by the EC2 health check (rather than the defined ALB Health Check /health.html).

Suggest updating the Cloudformation to configure the Auto Scaling Groups HealthCheckType to use ELB health checks.

During Lab 2, the React app fails to build because webpack 4.x uses a legacy openssl provider, documented here.

A workaround is to add the following to website-lab2.sh:

export NODE_OPTIONS=--openssl-legacy-provider

Error:

Creating an optimized production build... Error: error:0308010C:digital envelope routines::unsupported at new Hash (node:internal/crypto/hash:67:19) at Object.createHash (node:crypto:130:10) at module.exports (/home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/webpack/lib/util/createHash.js:135:53) at NormalModule._initBuildHash (/home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/webpack/lib/NormalModule.js:417:16) at handleParseError (/home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/webpack/lib/NormalModule.js:471:10) at /home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/webpack/lib/NormalModule.js:503:5 at /home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/webpack/lib/NormalModule.js:358:12 at /home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/loader-runner/lib/LoaderRunner.js:373:3 at iterateNormalLoaders (/home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/loader-runner/lib/LoaderRunner.js:214:10) at iterateNormalLoaders (/home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/loader-runner/lib/LoaderRunner.js:221:10) /home/ec2-user/environment/saas-factory-serverless-workshop/lab2/client/node_modules/react-scripts/scripts/build.js:19 throw err; ^

After completing lab 2 and all the steps successfully, i proceed to try to simulate a second tenant by signing up with a whole different set of fictitious account. However after multiple attempts, the "new" tenant was created but showed 122 orders & products in the dashboard of the app.

After completing lab 4, I was also not able to create a "new" tenant successfully.

Is this by design of the lab ?

Hi,

I created the tenant successfully. I can login to my tenant. On the dashboard I saw that we have 122 products and 122 Orders.
But when I click to create new product as guidance, the page is blank.

Please help to check and advise me.

Thank you!

Recent change by user brtrvn "Changing the name of the default branch to main from master" 9b1ff9b 2 days ago
Appears to have updated the code commit repo default branch to main however the Lab1 template CodePipeline source stage and CloudWatch Event still appear to reverence master.

Will update Lab1.template and submit PR

Following documentation here

"eventSource": "lambda.amazonaws.com",
    "eventName": "CreateFunction20150331",
    "awsRegion": "us-east-2",
    "sourceIPAddress": "cloudformation.amazonaws.com",
    "userAgent": "cloudformation.amazonaws.com",
    "errorCode": "InvalidParameterValueException",
    "errorMessage": "The runtime parameter of java8 is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (java21) while creating or updating functions.",

Following command in README failed.

aws s3 cp s3://aws-saas-factory-serverless-saas-workshop-us-west-2/CopyS3Objects.jar ./
fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden

Git push does commits the changes to CodeCommit but not on the main branch. The pipeline is set to trigger on main branch. Is this by design ?

Mitigated by creating a pull request OR directly committing to the main branch will trigger the Codepipeline to run.

Lab 2 errors out when running "sh website-lab2.sh" throwing a PutObject Access Denied when run with "--acl public-read".

If "Block Public Access" is disabled, the script works. This is not the recommended best practice for S3 buckets.

When you delete the lab1.template, the template is deleting the LogGroup with name /var/log/messages but the EC2 instance has a cloudwatch logs agent which is creating a LogGroup with name /var/log/messages to log messages while EC2 is shutting down. The issue with this is later when you rerun the lab1.template in the same account it will fail saying LogGroup with name /var/log/messages already exists.

Hi Could you share the slide deck from SVS303 here? Thanks.

Tried to start Lab2 again and found that there is an issue on step 2 :
The sed command in website-lab2.sh does not properly replace the API Gateway URL in the client/src/shared/config.jsfile.
There are no visible errors appart that later the call from the React Client to the REST API fails while trying to call the register URL /v1/registration
After fixing this issue and redeploying the React Client with website-lab2.sh I fall into another trap : the registration Lambda is returning an error :
Cannot register new tenant. Hot pool of RDS clusters has been depleted.

The CloudFormation template fails to deploy due to a deprecated PostgreSQL version (13.6). This causes an error during the RDS resource creation, blocking the workshop's setup.

Resource handler returned message: "Cannot find version 13.6 for aurora-postgresql (Service: Rds, Status Code: 400, Request ID: fb96b633-7d68-4ff5-a98c-7c7a60f80e70)" (RequestToken: 22d733e0-1ade-8f69-e1b3-99801b99e611, HandlerErrorCode: InvalidRequest)

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/AuroraPostgreSQL.Updates.html#AuroraPostgreSQL.Updates.20180305.136X

Please update the template to use a supported PostgreSQL version for Aurora RDS.

During step 3 of Lab 2 (deploying the website), the npm package installation fails the audit so nothing gets installed (or built), resulting in no website behind CloudFront.

89 vulnerabilities (38 moderate, 50 high, 1 critical)

Can work-around by modifying website-lab2.sh to reference npm install --audit=false which is subjectively ok for a sample.

I am referring to the instructions for Lab1. It looks like that the instructions in the Readme assumes a lot of steps with the environment setup. Can we verify on what all steps should someone execute while trying the Lab1 in their AWS account and also for the subsequent labs.
As an example, there are multiple bash scripts and CF templates in the resources folder, do we need to run them in any definite order?

The manual assumes the account we are working on already have a pipeline provisioned where adding the repo will directly kick in the pipeline and build the stack, which is the case for people trying to do the workshop on their own.

Is there any document to show the base architect they started from ?