As we've seen, Docker can simplify the entire software build and

deployment process.

Anytime you find your software runs properly on some machines but

not others, Docker can help you get things working consistently.

Here are just a few examples.

Dockers lets you run apps even if you don't know how they work internally.

Suppose your co-worker sends you a link to an internal repo,

and says she needs this app up and running by the end of the day.

But the app's poorly documented, and you struggle for hours to get it working.

Next time, if your co-worker includes a Dockerfile with the app,

all you have to do is ensure the host you're deploying to has Docker installed.

You'll be able to build an image using the Dockerfile, then use that image to run

a container on the host, and the app will immediately be up and running.

Docker also makes it easy to deploy apps to multiple environments.

Suppose you want to load test your project after it's deployed to your staging site.

You can use Docker to package your app, and put it up at a certain URL.

And then have a load tester run automatically once Docker finishes

deploying the container.

And Docker makes it easy to share your apps with others.

Suppose you want to share your apps with other teams in your company, but

sharing Git repos isn't enough.

You want to be able to immediately spin up the apps with no installation required.

You can use a Docker registry, sort of like a GitHub for

Docker to share as many Docker images as you want with your company's other teams.

Then once they use Docker to pull the images they want,

the image can be deployed as a container with one simple command.

Because Dockerfiles make running your files so

easy, Docker can handle these used cases and many more.

Docker fits right in to the DevOps movements,

infrastructure as code philosophy.

You can create containers for any app, website, or service

using a single Dockerfile, which is just the plain text file with some commands.

By now, you're hopefully thinking of adopting Docker for your own projects.

If you do, you'll be in good company.

Even though it was only released in mid-2013, it's already immensely popular.

Docker CEO announced in the 2016 DockerCon keynote that

460,000 Dockerized applications had been made.

That number had grown by a factor of 31 times over two years.

Over 4 billion containers have been pulled so far from the public Docker registry.

And as of 2016, there were 125,000 Docker Meetup members.

Clearly, Docker has a huge following.

And hundreds of thousands, if not millions,

of hours have gone into its development and improvement.

In 2017, it would be hard to name a major tech company that hasn't tried Docker.

And many are using it in production.

Docker can be used for many more purposes beyond those we've already shown.

The versions of libraries and

services that your app depends on may change over time.

Docker can act like a version control system for those dependencies

allowing you to roll back to an old version of a service, if something breaks.

Docker can help you maintain consistency between your developers work stations and

the testing and production environments.

If you bundle all the services your app depends on into a container,

you can be sure that the services your developers are writing code for

are the same services used in testing and production.

And Docker can help you deploy distributed apps.

If your app needs to run on a server cluster consisting of hundreds or

thousands of machines, configuring them manually just isn't an option.

But if you ensure Docker is installed on all those hosts, they'll be able to load

all the services your app requires from a single Docker image.

That's it for stage one.

Now, you should have a general idea of what Docker is, and

what businesses are using it for.

In stage two, we'll look at exactly how Docker works.

Ready?

Let's get to it.