The best way to understand how Docker works is to compare how using Docker differs from what we did so far, shown in the following diagram:

The first stack on the left is what we have done so far. Using the EC2 service, we picked an AMI providing AWS Linux and, with the help of the user data field, installed Ansible to configure our system. When Ansible kicks in, it installs and configures the system so that, later, CodeDeploy can deploy our application and run it.

The middle stack represents what it means to use Docker on top of EC2. The process starts the same way with an AMI running AWS Linux, but this time, instead of relying on Ansible and CodeDeploy, we will simply install the Docker server application. After that, we will deploy Docker containers, which will have everything that was previously provided by Ansible and CodeDeploy.

Finally, the big win of that architecture is what we see on the last stack on the right. No matter what the underlying technology is, as long as we can run a Docker server, we can run the exact same container. This means that we can easily test what we will deploy on EC2. Similarly, if an issue happens in a container running on an EC2 instance, we can pull the exact same container and run it locally to possibly troubleshoot the issue.

In order to make that happen, Docker relies on a couple of key concepts as shown in the following diagram:

At its core, Docker runs a daemon that loads images (templates describing the stack of the application, including the operating system, application code, and everything in between) and runs them in self-contained directories called containers. When working in Docker, as a developer, your work mostly consists of building new images by layering new commands on top of pre-existing images. Images are stored in external registries. Those registries can be public or private. Finally, all the interaction is done through a RESTful API, usually using the command-line interface.