Docker Definitions and Taxonomy
Docker Definitions and Taxonomy
In this post I am going to talk about Docker Definitions and Taxonomy.
Some of the term, I will co-relate with VM, but please not that VM and Containers are not same.
They have significant differences.
I hope this will help you to easily understand, especially if you are new to Docker.
Docker image is the very first thing that you need. The first question comes in mind what is the image, who provide it and can we create our base image.
Docker images or here we called base images are provide by the vendors. We cannot create the base OS images. We use these base images and modified it to create/ build containers.
These base images are publicly available in Docker Hub.
If you think about VM, in Azure we create VM from VHD files (which is pre-imaged file) from gallery. Once we have VM ready we can install and configure the software and other stuffs. Here VHD is Docker base image, once we have that image we can customize/ modified it with the help of Docker file (we can assume it like configuration management DSC).
Gallery can be considered as Docker Hub or registry from where you can download/ upload the images.
Docker compose is used to support multi container environment. You can think about ARM master template where you define the service and call the nested child template.
Again, please note that above explanation is just to help you to get familiar with some of the term for easy understanding.
I will recommend going through the related post to get familiar with containers
Definition
Docker image:
Docker images are the basis of containers. An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. **An image typically contains a union of layered file systems stacked on top of each other**. An image does not have state and it never changes as it’s deployed to various environments.
In Windows these image layers are available inside C:\ProgramData\docker\containers.
below command will pull image (Windows server with pre-installed IIS) from Docker hub.
docker pull microsoft/iis
Container:
A container is a runtime instance of a Docker image. A Docker container consists of: A Docker image, an execution environment and a standard set of instructions. When scaling a service, you would instance multiple containers from the same image. Or, in a batch job, instance multiple containers from the same image, passing different parameters to each instance. A container “contains” something singular, a single process, like a service or web app. It is a 1:1 relationship.
Tag:
A tag is a label applied to a Docker image in a repository. Tags are how various images in a repository are distinguished from each other. They are commonly used to distinguish between multiple versions of the same image. Dockerfile: A Dockerfile is a text document that contains instructions to build a Docker image.
Build:
Build is the process of building Docker images using a Dockerfile. The build uses a Dockerfile and a “context”. The context is the set of files in the directory in which the image is built. Builds can be done with commands like “docker build” or “docker-compose” which incorporates additional information such as the image name and tag.
Docker build -t <<image tag>> <<dockerfile path>>
Repository:
A collection of related images, differentiated by a tag that would differentiate the historical version of a specific image. Some repos contain multiple variations of a specific image, such as the SDK, runtime/fat, thin tags. As Windows containers become more prevalent, a single repo can contain platform variants, such as a Linux and Windows image.
Registry:
A Registry is a hosted service containing repositories of images which responds to the Registry API. The default registry (from Docker as an organization) can be accessed using a browser at Docker Hub or using the Docker search command. Therefore, a Registry usually contains many Repositories from multiple teams. As companies will want to keep their images private, and network close to their deployment infrastructure, companies will instance private registries in their environment to maintain their apps and control over their base images.
Docker Hub:
The Docker Hub is a centralized public resource for working with Docker and its components. It provides the following services: Docker image hosting, User authentication, Automated image builds plus work-flow tools such as build triggers and web hooks, Integration with GitHub and Bitbucket. Docker Hub is the public instance of a registry. Equivalent to the public GitHub compared to GitHub enterprise where customers store their code in their own environment.
Azure Container Registry:
Centralized public resource for working with Docker Images and its components in Azure, a registry network-close to your deployments with control over access, making possible to use your Azure Active Directory groups and permissions.
Docker Trusted Registry:
Docker Trusted Registry (DTR) is the enterprise-grade image storage solution from Docker. You install it behind your firewall so that you can securely store and manage the Docker images you use in your applications. Docker Trusted Registry is a sub-product included as part of the Docker Datacenter product.
Docker for Windows and Mac:
The local development tools for building, running and testing containers locally. Docker for x, indicates the target developer machine. Docker for Windows provides both Windows and Linux container development environments. “Docker for Windows and Mac” deprecates “Docker Toolbox” which was based on Oracle VirtualBox. Docker for Windows is now based on Hyper-V VMs (Linux or Windows). Docker for Mac is based on Apple Hypervisor framework and xhyve hypervisor which provides a Docker-ready virtual machine on Mac OS X.
Compose:
Compose is a tool for defining and running multi container applications. With compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running. Docker-compose.yml files are used to build and run multi container applications, defining the build information as well the environment information for interconnecting the collection of containers.
Cluster:
A Docker cluster pools together multiple Docker hosts and exposes them as a single virtual Docker host so it is able to scale-up to many hosts very easily. Examples of Docker clusters can be created with Docker Swarm, Mesosphere DC/OS, Google Kubernetes and Azure Service Fabric. If using Docker Swarm you typically call that “a swarm” instead of “a cluster”.
Orchestrator:
A Docker Orchestrator simplifies management of clusters and Docker hosts. These Orchestrators enable users to manage their images, containers and hosts through a user interface, either a CLI or UI. This interface allows users to administer container networking, configurations, load balancing, service discovery, High Availability, Docker host management and a much more. An orchestrator is responsible for running, distributing, scaling and healing workloads across a collection of nodes. Typically, Orchestrator products are the same products providing the cluster infrastructure like Mesosphere DC/OS, Kubernetes, Docker Swarm and Azure Service Fabric.
Taxonomy
As mentioned in the definitions section, a container is one or more runtime instances of a Docker image that usually will contain a single app/service. The container is considered the live artifact being executed in a development machine or the cloud or server.
An image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered filesystems (deltas) stacked on top of each other. An image does not have state and it never changes.
A registry is a service containing repositories of images from one or more development teams. Multiple development teams may also instance multiple registries. The default registry for Docker is the public “Docker Hub” but you will likely have your own private registry network close to your orchestrator to manage and secure your images, and reduce network latency when deploying images.
The beauty of the images and the registry resides on the possibility for you to store static and immutable application bits including all their dependencies at OS and frameworks level so they can be versioned and deployed in multiple environments providing a consistent deployment unit.
You should use a private registry (an example of use of Azure Container Registry) if you want to:
- Tightly control where your images are being stored
- Reduce network latency between the registry and the deployment nodes
- Fully own your images distribution pipeline
- Integrate image storage and distribution tightly into your in-house development workflow
Let’s create Docker Container Do let me know your views/ queries under disqus section.
Please do let me know your thoughts/ suggestions/ question in disqus section.
Related Posts
- My First Docker Container
- Docker Overview
- Container - It’s all about Application
- Setting up Docker on Windows environment
About Ajeet Chouksey
