Why Containers?

The following list shows the key reasons developers are moving to containers:

• Consistent: Containers include the application and all of its dependencies. The application executes the same code, regardless of computer, environment or cloud.
• Lightweight: Containers start quickly and use a minimal amount of RAM by using a minimal abstraction over the host operating system and sharing common resources across containers.
• Sharing: Container images are easy to share via Docker Hub, the Docker Store, and private Docker registries, such as the Azure Container Registry.
• Simple yet powerful: The DockerFile format (the recipe for container images) is a simple format that enables powerful scenarios: neatly marries operating-system and container-specific commands and also surfaces the creation of Docker image layer.

• Image: A docker image can be considered a unit of deployment. Images are defined by the Docker files and once built are immutable. To customise an image further you can use it as the base image within your next dockerfile. Typically you store built images in a container registry which them makes them available for people to reference and run. From a software development perspective, an Image can be though of as the definition (or “Class”) for the unit of deployment.
• Container: A container is the running instance of a Docker image. From a software development perspective, an container is the instantiation of the defintion (object vs class) for the unit of deployment. As in software, there can be many instantiations of a docker image.
• Dockerfile: A dockerfile is how Docker images are described. Docker images are built up in layers. You choose a base image that contains the elements you need. That image may or may not be based on other images.
• Docker Compose: For more complex deployments, one uses a Docker compose file to orchestrate multiple images/containers. It uses the YML format to specify one or more containers that make up a single system, or part of a system. Within this file you specify the images that need to be started, what they depend on, what ports they should start under on the host etc. Using a single command you can build all of the images. With a second single command you can tell Docker to run all of the containers.
• Host: The host is the underlying OS on which you will run Docker. Docker will utilise shared OS kernel resources to run your containers. The OS can run on Linux and Windows and can run on bare-metal or inside VMs. A Host can run one or multiple containers.