Introduction
As per the Official Docker Website: A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings.
Different between Docker and Virtual Machine
With virtualization, multiple physical machines can be consolidated into a single physical machine running multiple virtual machines. Each VM provides virtual hardware that the guest OS uses to execute applications. Multiple applications run on a single physical service while still being logically separated and isolated.
A challenge with VMs is that they are usually hundreds of megabytes to gigabytes in size and contain many binaries and libraries that are not relevant to the main application running on them.
With containers, developers take a streamlined base OS file system and layer on only the required binaries and libraries that the application depends on. When a container is run as a process on the container host OS, the container can see its dependencies and base OS packages. Also, the container is isolated from all other processes on the container host OS. The container processes are the only processes running on a minimal system. From the container host OS perspective, the container is just another process that is running, but with a restricted view of the file system and potentially restricted CPU and memory.
Each VM provides virtual hardware that the guest OS uses to execute applications. Multiple applications run on a single physical service while still being logically separated and isolated. With containers, developers take a streamlined base OS file system and layer on only the required binaries and libraries that the application depends on.
Virtual Machines | Containers |
Encapsulation of an entire operating system | Encapsulation of an application and dependent binaries or libraries |
Scheduled by the hypervisor | Scheduled by the container host OS |
Run on the hypervisor | Run on the container host OS |
Starting a VM means starting an operating system (seconds to minutes) | Starting a container means starting the application process (milliseconds to seconds) |
Workflow:
In this example workflow, an image is created from source code files and other dependencies. A container image can be stored in a registry, and the image can be pushed to a container host where it is used to spawn container instances. With this type of workflow, developers write code once. The code works across many different environments.
In the Dockerfile, a key specification is the name of the base OS image that is required for the container. A container can be deployed only on hosts running the OS that matches the one specified in the Dockerfile.
Container Engine:
The container engine runs as a daemon process on the container host OS. When a user requests that a container is run, the container engine gets the container image from an image registry (or locally if already downloaded) and runs the container as a process.
Container engines have the following features and benefits:
- Build container images from source code (for example, Dockerfile)
- Alternatively, load container images from a repository
- Create running containers based on a container image
- Commit a running container to an image
- Save an image and push it to a repository
- Stop and remove containers
- Suspend and restart containers
- Report container status
Image Registry
Container images are stored in a central image registry:
- The image registry maintains multiple versions of container images.
- Container engines can take images from an image registry to run them.
- Docker Hub is the most commonly used public registry.
