Published on

Docker overview - A web developer perspective


Docker has gained a lot of popularity and we as a web developer should or shouldn't learn this technology? This question I am sure must have come across your mind.

As a web developer keeping track of all the latest tools around us is very hard, We hear new tools coming in frequently. This may cause fatigue and sometimes imposter syndrome as well with people around us.

In this series of articles I will try to explain docker and why we should use it as a developer in our development cycle.

We’ll discuss what problem it solves and where it can fit into our development workflow.

As it's very challenging to discuss everything related to docker in this series. We’ll try to cover most of the things we are required to understand regarding docker as a web developer.

By the end of this series we’ll be able to get a good understanding on docker & will be able to build and run docker containers with confidence.


  • Docker its overview and Installation
  • Docker terminologies
  • Using existing docker images
  • Creating a custom image
  • Using docker application development workflow

Overview & Installation

As a developer we have been through some classic problems:

  • It works on my machine but not somewhere else (other devs machine/ production)
  • Pain of setting up dependent technologies (Database, Caching etc) before you can write code.
  • Scaling load based on traffic. etc.

Docker can help us resolve the above-mentioned issues and many more which we’ll see once we start using them in our coming articles.

With docker we can differentiate infrastructure & software both so that we as a developer can be more productive by concentrating on building software and let docker do the setting up of required infra across different environments.

As an example say if a new joiner joins our group he would have to put most of the effort on setting up the technologies which he may not be aware of i mean instead of writing Javascript he would have to set up a postgresDB, redis maybe nginx as well and he would also need to make sure they are properly connected with the application. How would he feel on the first day??

With docker we can define everything as IAAS (Infrastructure as a code) all the required Tech and their connectivity related logic in a file which makes it up and running within a few mins.

How docker works under the hood. It's a little advance for what we’ll be exploring but you can read more about here:

Docker architecture

Also we'll be doing hands on in this article. Hence, i would recommend installing docker following instructions mentioned here for your OS.

Docker Terminologies

Before we start diving in the code let's make sure we are on the same page and understand some important terminologies around docker.

Below figure represents important pieces of docker, their roles and how they are used.

docker overview architecture diagram

Docker daemon

It is the brain of docker which does all the heavy lifting. Any command we run is executed inside this daemon (dockerd process).

It in a nutshell listens to the docker API ‘s. Any command we execute on docker cli is sent to docker daemon. It also manages docker objects like creation/updation or deletion of docker images, volumes etc.

Docker client

Or docker CLI (docker process) is where most of us interact with docker. It is basically our portal to interact with the docker daemon. Any command we run docker build OR docker ps is being sent to daemon for execution.

Docker desktop

It is a software provided by docker to install & use on our machines (linux, mac or windows). It enables us in development and publishing docker images. It also has few other tools which we need to enhance the experience of using docker images & containers like docker compose, kubernetes etc.

Docker Objects

(Some we are going to use)


docker images are simple configurations whose main purpose is to create a docker container. They are basically a blueprint of what its instance (a container) is supposed to do.

We can reuse an image created by someone else (via docker registries) or create our own. They are basically like building blocks as we can combine multiple images as per our needs with some customisations on the top to create a new image.

In order to so a Dockerfile is created with all the instructions around what the image is supposed to do.

We will be creating images later in this series in more detail.


Containers are the running instance of an image. They are created by following the instructions we added while creating an image. we can create, start, stop or delete a container.

The beauty of them is by default they run in isolation and once destroyed all its related changes and state gets removed as well which sometimes is what we need when experimenting.

We can always link containers with others via the network and also persist data we need via volumes which we’ll discuss more ahead in coming sections.


As we just read above containers are stateless and hence we need volumes to persist any data which is created by the containers. It sits outside the containers and are managed by docker. They are also independent of any OS or host machines.


As the name suggests, docker networks are used in the cases when we need some interaction across the containers. They too are very powerful and are platform independent.

Example: We need a nodejs container to communicate with database container or a redis container.

Docker registries

So we now know we can build something called an image which can be used to create docker containers. But what is the fun if we cannot share the images we built with others.

This is where registries come into place. It's a repository of docker images from where we can push/pull images which can be used internally or publicly by the outside world.

There are plethora of option where we want to save the images some of the popular ones are:

Hope you got a little understanding around what docker is and some of its terminologies.

Lets take a break here.
Initially all these can seem to be a little overwhelming and harder to digest but we'll get throught it.

In the coming articles of this series we'll dive into code and start playing with docker images.