An Introduction to Docker for Novices

Almost every developer today is familiar with the word “Docker” and it is common for beginner developers to get intimidated by it. In this article, we’re gonna break it down to simple terms and understand docker.

Why use Docker?

Before we understand what Docker is, let’s try to understand what are the issues it is trying to solve in the world of software development.

Let’s consider a real world scenario where you’re trying to install a piece of software. You would normally carry out the following sequence of actions :

• Download and run the installer on your machine
• Get an error message
• Google for a solution
• Resolve the issue and re-run the installer
• Get a new error (..and the cycle continues)

This is the problem docker is trying to fix! If the software works on one machine, it should be able to work on other machines too, right? Docker lets you “package” your software as a single unit that runs on this imaginary “working” machine called container, and these containers run on your host operating system. Docker ensures portability of software, so that they can run on any given machine — your desktop, your laptop, cloud servers or VMs, completely hassle free!

Often, setting up certain softwares require you to execute certain number of commands or instructions manually. But “dockerizing” them would completely automate the complex processes of setting up and running the software.

Although containers run on top of the host operating system, processes inside these containers run isolated from the host OS’ processes. That means, no dependency issues! Let’s say, you need to run 2 softwares, and each require different versions of the same external library ( or dependency). Normally, having 2 versions of the same library on the same operating system would give rise to a million issues. But Docker can carry this out smoothly, with zero dependency issues.

tl;dr : Docker makes it really easy install and run softwares, without worrying about dependencies.

What is Docker?

Now that you have understood why we use Docker, let’s try to understand what exactly is Docker. Docker is not just one single library or tool. It is an ecosystem of tools and pieces of software.

Docker is a platform or ecosystem around creating, running and managing containers.

Now, you may ask, what is a container?

To understand what a docker container is, we need first understand what is a Docker image.

Let’s say, I built this software that is extremely complex, and requires you to execute 10 different commands on certain files. A docker image is a pre-configured file-system snapshot.

Let’s understand this with an analogy. Say, my software is initially at stage “A”. After successfully executing these 10 instructions and configuring my software (which otherwise could be painful), my software is at stage “B”. So, stage “A” consists of unconfigured files, and stage “B” consists of configured files. Now, all I have to do is probably start a process by running a particular file from stage “B”.

A Docker image essentially would contain everything that is there in stage “B” — the configured files, and a default command to run the software (a process).

A container is a running instance of an image.

So, to put this very simply — an image is a set of files and configurations to start processes (isolated), and a container is a running instance of the processes derived off these configurations.

A container is a running instance of an image

Container VS Virtual Machine

From everything explained above, you’ve probably inferred that an “image” is essentially a set of files with the right configurations and commands. And a “container” is an isolated process that was derived off these configuration.

Now, you may ask — If I just had to create an isolated environment, why can’t I just use a Virtual Machine?

A Virtual Machine generally requires an OS to run on. Which means, your app is not the only process that will be running on it. There may be several other processes which are required to keep the Virtual OS alive. Other than that, these processes are not even required to run your app. Hence, a VM is going to consume a lot of resources off your host OS just to keep your app running.

On the other hand, a container is very light weight. Why? It needs no OS! In fact, it communicates with the host OS’ Kernel. A container is running only those processes that are required to keep your app running. Yet, these processes are somehow (a linux feature called “namespacing”) isolated from host OS. So, you can think of a container as a VM with no OS of its own. Just a file system, that runs isolated processes through the host OS’ kernel.

https://blogs.bmc.com/wp-content/uploads/2018/07/containers-vs-virtual-machines.jpg

Let’s try this out!

Before we proceed, make sure you have docker installed on your system.

Now that we have a clear picture about containers and images, we shall try and pull a base image from Docker hub, and check out its file system.

What is a base image?

A base image is essentially a docker image with a pre-defined file system, which is used to run the processes. Like how a machine needs an OS to run processes, a container needs some basic file system configurations to run processes.

For example, if I want to containerize a python process (an app), I would take a base image with python installed, copy all my files into the container and then make use of python installed inside the container to run my python app.

While building containers, it is always recommended that you use a base image. I will not go into great detail here.

I’m going to pull the python base image, and execute a shell on it. We’ll use this shell to expore the files on this container.

1. Run the following command to download the python base image

$ docker pull python

To ensure that the image has downloaded successfully, run docker images . You should see “python” under the “repository” column.

2. Now, we need to start a container with this base image. But it needs some processes to run — so we’ll just open up a shell (which will be the process) and use it to check its file system.

docker run -it python sh

While containerizing applications, you’d usually set a default command to start a processes. In that case, you would not have to mention sh like in the above command. However, in this case, we’re not containerizing any applications, so we can manually set a start-up command on our container, in this case, it is sh , which opens up a new shell.

By default, the python base image’s starting command is python3 . This means, running docker run -it python (not overriding the default) would open a Python interpreter on the container. Try it out!

The “-it” flag opens the container in an interactive mode, i.e , we can directly give shell input through the terminal, and get a formatted output on the terminal — directly from the container.

Now, a shell has opened up in the container, and we can interact with it!

In the next part, we shall see how we can use such base images to containerize applications! :)

Thank you.