What is Docker Compose? Multiple Containers & Docker Networking 

I don't know whether this comment should make me happy or sad :D

@@MonisYousuf the one motivate you dude😎 Also how ya make those edits? Seems amazing

Thank you! I use Final Cut Pro with some creativity :)

I use Final Cut Pro

Either one can be used. Both will work.

@@MonisYousuf Great job. Thank you for your work. I'm sure with such cool animations you will have many subscribers

Thank you so much!

Sure :) 1. Docker Compose is more geared towards local development. Where you can make changes (let's say just backend and database). Run docker-compose up and see the results while in development phase. However - in reality, on higher environments you won't usually use docker compose. If we take this example - your backend, frontend and database would most likely be hosted in different types of cloud infrastructure (e.g. you'd have a FE cluster, a BE cluster, a DB cluster and so on). For each of these clusters - you also need to manage versions. Usually your CI/CD pipeline builds an image in one step, tags it with a version and pushes it to a private docker registry. Thereafter, in another step the latest image would be pulled into the server(s) and deployed. And you would have to maintain different docker image versions for frontend, backend (and probably other downstream microservices). Maybe your frontend underwent 20 changes since the time it went live (image version: v0.20) and your backend only underwent 10 (image version: v10). Similarly - it could also get counter-productive in higher environments to intertwine these versions and then run all of them up on the same instance via docker-compose. 2) To your question "I am having hard time figuring out how to setup dev-containers for each segment of an app (frontend, backend, and DB for instance) that can communicate with each other while in the development phase". -- You just need to run the docker compose up. If you need to make changes, change the code, re-run docker compose with --build. This will automatically create the containers and the network for these apps on your local environments. Your colleagues will be able to replicate this in the same way. 3) True, setting up environment variables in the docker-compose file is not the best practice. It was added for the sake of simplicity and for local development. In reality - it depends on the sensitivity of the value of environment variables. Some environment variables and not sensitive (e.g. an environment variable for a public URL which is added for standardisation and making it less error-prone). And depending on where they are used (app or instance level), they can be added in docker's .env files, build pipeline or an orchestration engine like Kubernetes. However - for environment variables that are secret (Database Passwords, Keys and such) and are on higher environments, should never be in cleartext, nor should they be in compose files or environment files. For that, as a best practice we should use a credential store. For the next video - we'll, you'll have to wait for it ;)

@@MonisYousuf ❤Thanks for responding. Can't wait for the next video.

At 13:34 - we specify that the backend app depends on the database on the condition that the service should be started (service_started). This option is the default option simply waits for the container to be "started" and will not check the internal status of the service if the container has successfully started. For this reason, this option doesn't require anything "extra" to be defined in the backend_database. Since our database image is very fast and we're not doing a lot of customisations there - it shouldn't be a problem. I use Final Cut Pro

Got it. Thank you

Thank you!