Why Use Docker - An Answer
The advantage of docker is 100% when you set it up for other people to use it on the Internet, or in other words: when you deploy it. So to answer this question, we have to consider how your app will be deployed.
On your machine, you have your app - which is, let's pretend, a node server and an index.js file - and you have your database - say, MongoDB. It runs great. For running where you are the only user and you're not connected to the Internet, it's great.
Now how we run this online, for other people to use it?
Let's say we use AWS, we are AWS customers.
First, we create a virtual server on AWS, an EC2 instance; that holds our app. We install MongoDB on this EC2 instance.
But communicating directly with MongoDB ends up being kind of a pain, so we decide to add an API, a natural addition to any app. The app communicates with the API and the API communicates with the database - that's literally its purpose, to be the middleman.
So now our AWS setup has: an EC2 instance running our app (node server), our API (another node server), and our database, MongoDB, installed directly on the container.
But we've had problems with our app, and our EC2 instance, crashing before. (Note: I've never had a long-running EC2 instance not crash on me). Every time it crashes, we have to restart the app; sometimes its offline for a long time. How can we make it better, by making the app more stable?
One way would be to separate things out: to set up our EC2 instance, and then set up our database. We search on AWS and we decide to AWS DynamoDB, which is another NoSQL DB just like MongoDB. Then we use API Gateway on AWS to set up our API.
So now our "app" has three separate components, in 3 different places on AWS: our EC2 instance for the app, API Gateway for the API, and a DynamoDB table for the database.
But... wouldn't it be nice to simplify this, somehow? That's now three different places I have to go to modify my app.
One way would be to combine the EC2 instance and the API. That's what Docker is for! (We could even throw in the MongoDB instance too, though that's not recommended - it's better for that to be separate).
So now we create a Docker container that has the app (node server) and the API (another node server). It works great, and we've now simplified things.
Remember how I said our EC2 instance would crash? That usually happens at the worst moments - when our app experiences heavy load.
We want to avoid this if at all possible. With Docker, we can.
If we get a ton of customers, now we have a simple container with our app and our API that can be scaled up. If we need 10 containers, no problem.
Or, as explained on reddit:
Normally to deploy an application you have to install all the dependencies (MySQL, Node, JRE, ncurses, whatever) on the host system.
With Docker, instead of managing host systems, you just specify a Docker file that lists all the dependencies it needs, even to the exact version if you like. And then that image will work wherever the container is run. This also allows you to check in this Dockerfile in to version control, to keep easy track of it.
Now the only thing you have to install on the host system is Docker. And it can be any host system (sort of). Bonus points if you spin this up in the cloud you can also have that scripted so your whole application can be spun up, torn down, scaled, moved, etc.
So now you have "configuration as code" and fewer sysadmin tasks to do.
Orchestrating containers is its own subject, but the point is, it's better than the solution we were using before, and it's a lot easier to upgrade.
And that's why you use Docker, in a nutshell!