I can't understand why your videos have less views... These are by far the best explanation in a short time period. Thank you so much for your dedication.
Thank you Monis. Very cool! A question, though: You said for Production: Avoid docker compose. But how do you specify the networking between containers in production and how do you wire up (depends on:) your containers. It would have been nice if you could explain how to go about deploying your previous application (with a frontend, backend and db) in production. Some advice would be appreciated! Thx.
Good Question. There are different ways to do this on production, but I'll explain you the general concept. 1. Imagine you have a frontend app. It's docker image would be pushed to its own docker registry and deployed to its own server. This server will have a DNS or an IP exactly just like you have for the backend app we saw in this video. Let's call it IP_FRONTEND. 2. For your backend app, the image is pushed to its own docker registry and deployed to its own server. This server will have a DNS or an IP. Let's call it IP_BACKEND. 3. Your Database will probably be non-dockerized. Cloud Providers have their own solutions. Nevertheless, it will also have an IP. Let's call it IP_DATABASE. Now, if you're using a cloud provider like AWS, it gives you a default VPC (Virtual Private Cloud) to control networking. For example, we can define that we want to make our IP_FRONTEND public so that it can receive requests from any IP on port 80. We can restrict the backend server (IP_BACKEND) so that its not accessible to the public and can only receive requests from the IP_FRONTEND. So, whenever some backend action is required, it first reaches your frontend and then it contacts the backend (via REST APIs and such). Similarly, you can do the same for your database. Configure IP_DATABASE, such that it can only receive requests from IP_BACKEND. This can be easily achieved via "Security Groups" in AWS. This ensures both, networking & security. This is the general concept. However, in more complex architectures there might be API Gateways and Load Balancers involved as well. For example, If you have multiple replicas of your backend server - you will have a load balancer. Then, instead of exposing the individual IPs of your multiple backend servers, you would expose the IP of your load balancer to the frontend and then the Load Balancer decides which replica to send the request to. If we make it more complex, you may have multiple backend microservices which talk to each other behind the scenes. It might be possible that each microservice has multiple replicas, meaning each microservice also has a load balancer. Then you have multiple load balancers and the requests are delegated by an API Gateway. Similarly more and more complexity can be added, and so the level of complexity for solutions can increase. Hope that answers your question :)
I can't understand why your videos have less views... These are by far the best explanation in a short time period.
Thank you so much for your dedication.
concise and to the point
Amazing .. cleared every doubt regarding production environment
really good... each and every detail was covered.
Awesome 👏🏻
you are a life saver, cheers mate!!!
Hey Folks 👋
Full Docker Series: th-cam.com/play/PLlrv2-wV8WA1eFpbPSIcLLYqJxZSPrISZ.html&si=ZBu2OsGN6rdfkhE2
💻Code Examples: github.com/monisyousuf/youtube-tutorials/tree/main/CD_011_docker_production
📃Documentation: github.com/monisyousuf/youtube-tutorials/blob/main/CD_011_docker_production/README.md
❗Troubleshooting: github.com/monisyousuf/youtube-tutorials/blob/main/CD_011_docker_production/TROUBLESHOOTING.md
Thank you Monis. Very cool! A question, though: You said for Production: Avoid docker compose. But how do you specify the networking between containers in production and how do you wire up (depends on:) your containers. It would have been nice if you could explain how to go about deploying your previous application (with a frontend, backend and db) in production. Some advice would be appreciated! Thx.
Good Question. There are different ways to do this on production, but I'll explain you the general concept.
1. Imagine you have a frontend app. It's docker image would be pushed to its own docker registry and deployed to its own server. This server will have a DNS or an IP exactly just like you have for the backend app we saw in this video. Let's call it IP_FRONTEND.
2. For your backend app, the image is pushed to its own docker registry and deployed to its own server. This server will have a DNS or an IP. Let's call it IP_BACKEND.
3. Your Database will probably be non-dockerized. Cloud Providers have their own solutions. Nevertheless, it will also have an IP. Let's call it IP_DATABASE.
Now, if you're using a cloud provider like AWS, it gives you a default VPC (Virtual Private Cloud) to control networking. For example, we can define that we want to make our IP_FRONTEND public so that it can receive requests from any IP on port 80. We can restrict the backend server (IP_BACKEND) so that its not accessible to the public and can only receive requests from the IP_FRONTEND. So, whenever some backend action is required, it first reaches your frontend and then it contacts the backend (via REST APIs and such). Similarly, you can do the same for your database. Configure IP_DATABASE, such that it can only receive requests from IP_BACKEND. This can be easily achieved via "Security Groups" in AWS. This ensures both, networking & security. This is the general concept.
However, in more complex architectures there might be API Gateways and Load Balancers involved as well.
For example, If you have multiple replicas of your backend server - you will have a load balancer. Then, instead of exposing the individual IPs of your multiple backend servers, you would expose the IP of your load balancer to the frontend and then the Load Balancer decides which replica to send the request to.
If we make it more complex, you may have multiple backend microservices which talk to each other behind the scenes. It might be possible that each microservice has multiple replicas, meaning each microservice also has a load balancer. Then you have multiple load balancers and the requests are delegated by an API Gateway.
Similarly more and more complexity can be added, and so the level of complexity for solutions can increase. Hope that answers your question :)
Great video! 🎉
This is the content why I pay for the internet.