Updated date:

A Beginners Guide to Containers & Docker

I am technology enthusiast with keen focus on defining high impact Cloud Native solutions. Expert in Scrum & DevOps practices.


As business applications are rapidly being developed, either with a Cloud Native approach or existing workloads are migrating to Cloud, business/product managers to software architects, developers, operation engineers find it hard to ignore two technologies – Docker & Kubernetes.

This is the first post in the series to come. It is intended for beginners who are looking for a conceptual understanding of containers, why & how containers are being used, and Docker’s underlying high level architecture components. In this Docker tutorial I will cover brief history of virtualization & container technology, and look at the Docker component architecture. In upcoming tutorials, a similar coverage will be given to Kubernetes, along with labs showing practical use of Docker Containers and Kubernetes technologies.

Key Terms and Definitions

  • Cloud Computing: On demand availability of computing resources (CPU, memory, storage)/platforms/software.
  • Cloud Native Approach: Technology strategy to consider cloud computing based solutions as the first choice for application development.
  • Hypervisor, Virtual Machine, Containers: Virtualization related terminologies (explained in more detail in the next section).
  • Docker Engine: A container engine technology (explored in detail throughout the tutorial).
  • Kubernetes: A container orchestration technology (explored in the next tutorial).
  • RESTful APIs: Application Programming Interface (API) that uses RESTful protocol.
  • Microservices: An architectural style that structures an application into a set of loosely coupled services.
  • DevOps: Set of practices to break silos between development and IT operations, thereby optimizing overall development life cycle.

Hardware Virtualization & Containers

In simple terms hardware virtualization uses software (a Hypervisor) to create a layer on top of hardware. This layer of hypervisor divides computing resources into multiple virtual computers. These are commonly called Virtual Machines (VMs).

Each VM runs on its own operating system (OS), and to end users it appears as if they are using their own dedicated machine. Hardware virtualization (Figure 1) greatly improves effective utilization of underlying hardware, thus providing organizations with a higher ROI on their hardware investment.

Figure1: Example of a Type 2 Hypervisor

Figure1: Example of a Type 2 Hypervisor

Each VM requires its own full-blown operating system making them heavyweight. Containerization takes this concept a step further. As opposed to a hypervisor, a Container Engine (Figure 2) enables applications running inside a container share resources of the host OS. Thus, making them very lightweight and provide an even better hardware utilization when compared to Virtualization.

Figure2: Containerization Engine

Figure2: Containerization Engine

What is Docker?

There are several container engine technologies that exist in the market, but Docker Engine by far is most popular, so much so that words Docker and Containers are at times used interchangeably.

Docker website defines the Docker container platform as follows:

Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly.

So, without further ado lets deep dive into the components of Docker platform to get a better appreciation for it.

Docker Component Architecture

Docker platform uses a client-server architecture (Figure 3). Docker client talks to Docker server using Docker APIs. Client sends commands to server, and server executes these commands.

Below are some examples of Docker commands.

docker build
docker run 
docker pull 
Figure 3: Docker Components

Figure 3: Docker Components

Let’s look at each of the above architecture components in detail.

Docker Server


Docker server is the host which is running Docker Daemon. The Daemon listens for request commands coming from Docker client and executes them. The Docker client and daemon communicate using Docker APIs, which are nothing but RESTful APIs. In addition, to this the Docker daemon also manages Docker Objects – images, containers etc.

Docker Client


Docker client is what you will use to interact with Docker daemon. The client’s command line interface (CLI) can be installed on your local machine and it interacts with one or more Docker daemons. The docker commands that you type on the CLI are sent to Docker host where Docker daemon listens and executes them.


An image contains set of instructions along with all dependencies that an application requires to run in a container. In this sense, images are templates to create containers and hence one or more containers can be created using the same image. An image is created by building a Dockerfile. A Dockerfile is a text file which contains a set of steps/commands required to assemble an image. The build command builds an image from Dockerfile.

    docker build

You can either create your own image by writing and building a Dockerfile, or can pull an image built and published by others, from the Docker Registry.

Docker Registry


A Docker registry is a store for Docker images. When you run the push or pull commands on CLI, Docker daemon pulls image from, or pushes image to a configured registry. Docker Hub is a public repository of images and Docker by default looks for images on Docker Hub. You can also create and configure your own private registry. Following commands are executed on the CLI to pull or push docker images.

    docker pull
    docker push


A container is nothing but a running instance of an image. Containers are managed by the Docker daemon. You can interact with the containers by running commands on the CLI.

Benefits of Docker Containers

Containers can enable businesses and IT teams to reduce the overall time to market i.e., the time taken from ideation to realization of a software application. Including Docker container technology into your architecture may result into following benefits:


In Conclusion

Introducing Docker containers into your architecture is just like adding any new technology component. Thus, in addition to the benefits one must also be aware of the complexities that it will add to your architecture and the development process. Teams planning to use Docker containers must be prepared to address below mentioned concerns.

  • Given the nature of container technology, number of running Docker containers can grow exponentially very fast. Hence additional tooling will be required for Docker container orchestration, management, monitoring etc. Several tools exist in the market to address these concerns, namely Kubernetes, Apache Mesos, Nomad etc. Adequate planning & research must go into selecting the right tool, and adding it to your deployment and operations architecture.
  • Developing distributed microservice applications deployed on containers will require upskilling of development, testing and operation teams. A training curriculum & investment plan must be put in place to upskill your resources.
  • Strategies have to planned and developed to overcome security risks like –
    1. Prevent or handle the use of insecure Docker images from public Docker registry
    2. Secure yourself from cyber attackers who may abuse Docker containers with elevated access privileges
    3. Secure inter Docker container communication
  • Containerization will be more valuable only if you implement a DevOps mindset. DevOps is a much larger topic and beyond the scope of this tutorial. DevOps practices will require both cultural and technology changes to be introduced within your teams.

This brings us to the end of this post. In the next tutorial I will provide a similar coverage to Kubernetes and additionally we will see how Docker and Kubernetes are leveraged to meet some real-world use cases. Until then happy reading and learning.

Additional Resources

This content is accurate and true to the best of the author’s knowledge and is not meant to substitute for formal and individualized advice from a qualified professional.

© 2021 Manhar Puri

Related Articles