
Why Would You Use Docker
An Example of When You'd Use Docker
The advantage of Docker is 100% when you set it up for other people to use it, or in other words: when your project is ready to deploy.
So to answer this question, we have to consider how your app will be deployed.
On your machine, you have your app, and your database.
Let's say you have a node server, an index.js file, and a MongoDB instance.
For you, there's no issue. For situations where you are the only user and you're not connected to the Internet, it's great.
Now how do we run this online, for other people to use it?
Let's say we use AWS, Amazon Web Services.
First, we would 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 the API's 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. Now we have to add monitoring...
Isn't there an easier way to do this, that's not such a pain?
There is - with Docker.
How Docker Can Simplify Our Process
One way to simplify things is just to have fewer of them.
Essentially, we can combine the functionality of the EC2 instance and the API. That's what Docker can do for us. (We could even throw in the MongoDB instance too, though I'll keep that separate).
So now we create a Docker container that has the app (node server) and the API (another node server).
It works great. It's easier to keep them as one unit for our team, which now only has to check and update in one place.
To run them both, we just run that Docker container.
How People Use Docker In The Real World
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 as needed.
If we need 10 containers, we scale up. If we don't need that many, we scale down.
Here's an example of an engineer in the field explaining how they use Docker in a situation like this.
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.
Learning to work with containers is its own topic, 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.