Thanks a lot.. I enjoy your videos. The theory you do before the hands-on is what I enjoy best. Plus, the scenario of a virtual organization is just wonderful. It really helps me understand what I'm about to do and why I do it.. Thanks again
Great stuff, just a suggestion, if there can be follow up videos on troubleshooting if things are not working as expected because of some mistake while setting up..
At 32:07, you say that "Each tasks are isolated (Okay) and does not share the underlying kernel, CPU or memory with another task.". But later you say that the tasks access a shared pool of resources. I'm confused here, I think the first statement is completely right.
Hi Jay, Sorry for the confusion, but yes, each task is deployed in an isolated environment. When I said a shared pool of resources, what you must remember is that Fargate ECS tasks are likely to run on physical hardware that are shared by other customers or your other applications. However, when you deployed two tasks that belong to a specific application and cluster, those tasks will be isolated on different resources. but ultimately, you are still sharing a pool of backend resources other application stacks or customers. Hope this clarifies the statement.
Thank you for the great content! So much well structured and explained useful info! I'm trying now to write my own backend in node.js, and I have a question: How does the DB credentials rotation is done on the backend side? Is the retrieving the secret from SecretsManager and reestablishing connection to the DB is done for every request?
Also, NAT gateway costs some 0.062 USD per hour, which means that per month that would cost around $44 (not "a couple of dollars"). Just to have the ability to do some apt updates... is there cheaper solutions?
There is a file in the repository called db.php. This file retrieves the secret name from the #Amazon ECS Environmental Variable and then proceeds to dynamically retrieve the credentials from #AWS Secrets Manager. This means that whenever the script is executed, it will query AWS Secrets Manager for the current credentials. This is advantageous because: - It ensures that the script always has access to the latest credentials. - It reduces the risk of hardcoding sensitive information like database credentials directly in the code. Have a look at the db.php file which is included in the zipped file. Hope this helps Thanks
Depending on which updates you need, you could store them in an S3 bucket and retrieve them via a VPC endpoint. This article provides more details - repost.aws/questions/QUmfyiKedjTd225PQS7MlHQQ/vpc-nat-gateway-vs-vpc-endpoint-pricing
Why did you need to specify the ecr repository url in the docker build command? the image is stored locally until you push it to the repo anyway right? thanks!
Hi Harry You are right, you do not need to specify the ECR repository URL during the build command. Howerver, you would then need to at least tag your image so you can push the image to repository. The step shown in the video basically bypasses that step. So if you look at the ECR push commands you will note that you would need to tag it before you push it. So this step in the video just avoids that step. But both options are correct. Hope this helps
What an explanation..!! It's very clear and simple to understand. Thank you.
having a simple website example gave me the courage to dive in
Thanks a lot..
I enjoy your videos. The theory you do before the hands-on is what I enjoy best. Plus, the scenario of a virtual organization is just wonderful.
It really helps me understand what I'm about to do and why I do it.. Thanks again
Thank you for your feedback. I'm glad to hear you found the tutorial useful on Amazon ECS Fargate.
Thank you for comprehensive tutorial
Glad it was helpful!
I really feel like I should be paying to watch this video, it feels wrong not to pay...
AMAZING CONTENT!...
@@sean_reyes Haha… thank you for you kind feedback. All you need to do is like, subscribe and please share! Best wishes
Great tutorial. Very organized and detailed.
Glad it was helpful!
Great stuff, just a suggestion, if there can be follow up videos on troubleshooting if things are not working as expected because of some mistake while setting up..
At 32:07, you say that "Each tasks are isolated (Okay) and does not share the underlying kernel, CPU or memory with another task.". But later you say that the tasks access a shared pool of resources.
I'm confused here, I think the first statement is completely right.
Hi Jay,
Sorry for the confusion, but yes, each task is deployed in an isolated environment. When I said a shared pool of resources, what you must remember is that Fargate ECS tasks are likely to run on physical hardware that are shared by other customers or your other applications. However, when you deployed two tasks that belong to a specific application and cluster, those tasks will be isolated on different resources. but ultimately, you are still sharing a pool of backend resources other application stacks or customers.
Hope this clarifies the statement.
Great commentary ! Excellent!
Glad you liked it!
Thank you! Great tutorial
Thank you for your feedback. Please do share
Thank you for the great content! So much well structured and explained useful info!
I'm trying now to write my own backend in node.js, and I have a question:
How does the DB credentials rotation is done on the backend side? Is the retrieving the secret from SecretsManager and reestablishing connection to the DB is done for every request?
Also, NAT gateway costs some 0.062 USD per hour, which means that per month that would cost around $44 (not "a couple of dollars"). Just to have the ability to do some apt updates... is there cheaper solutions?
There is a file in the repository called db.php. This file retrieves the secret name from the #Amazon ECS Environmental Variable and then proceeds to dynamically retrieve the credentials from #AWS Secrets Manager.
This means that whenever the script is executed, it will query AWS Secrets Manager for the current credentials. This is advantageous because:
- It ensures that the script always has access to the latest credentials.
- It reduces the risk of hardcoding sensitive information like database credentials directly in the code.
Have a look at the db.php file which is included in the zipped file.
Hope this helps
Thanks
Depending on which updates you need, you could store them in an S3 bucket and retrieve them via a VPC endpoint. This article provides more details - repost.aws/questions/QUmfyiKedjTd225PQS7MlHQQ/vpc-nat-gateway-vs-vpc-endpoint-pricing
Why did you need to specify the ecr repository url in the docker build command? the image is stored locally until you push it to the repo anyway right? thanks!
Hi Harry
You are right, you do not need to specify the ECR repository URL during the build command. Howerver, you would then need to at least tag your image so you can push the image to repository. The step shown in the video basically bypasses that step. So if you look at the ECR push commands you will note that you would need to tag it before you push it. So this step in the video just avoids that step. But both options are correct.
Hope this helps
really very helpful
Thank you for your valuable feedback
Please make videos on sqs
how much is that expected cost for this entire setup? for every month.