Docker By Example | Part 1 | A brief Introduction

By: rahul On: Sat 06 January 2018
In: DevOps
Tags: #devops #docker #containers

Greetings Wanderer! I hope you're having a great New Year so far..

This year, we'll kick things off with container-based technology, primarily Docker.

What are containers?

Let's forget about servers for a moment. Say, you are running several distinctly different applications in different virtual machines on your local machine (workstation or laptop). These applications are isolated from one another by virtue of being in different virtual machines. Actions performed on one VM (virtual machine) does not affect others, except through well defined channels such as network communication.

These individual applications can write, append to or edit whatever files they want and be sure that another application (on a different VM) will not delete or change these files. You can install a specific version of the Operating System within the VM and install any/all the libraries that are needed for each individual application. Thus, these applications, in effect appear to be running on different physical machines (though they're in fact running on the same machine within different VMs).

There is, however, a downside to this approach. Each of these Virtual Machines needs to tun it's own copy of a full-fledged Operating System. In this scenario, if you have 10 applications running on 10 different VMs, your system, in effect, is running 11 full-fledged Operating systems (10 Guest OSes, plus the host OS).

Containers, on the other hand, try to eliminate the need for running multiple Virtual Machines. Containers also attempt to provide isolation between individual applications, but do so without emulating an entire virtual machine, thereby eliminating the need to run a full-fledged guest operating system on the base (host) machine. Containers run on top of the host operating system, so there is only one instance of an operating system running on base (host) machine. The downside to this approach is, you cannot run a specific operating system for each individual application. However, in usual production environments, generally, all the Virtual Machines which are in use essentially run same Operating System and core libraries, and hence using containers can potentially save costs because effectively the host (base) server uses far fewer resources to host the same number of applications.

Traditionally, a Developer builds an application and passes the build to an Operations person with a specific set of instructions that need to be followed to get the application up and running - this involves checking and updating the correct Operating System, getting the application's dependencies (with the exact version number) installed or updated. Any updates to the base system may, at times, result in the application breaking.

With containers, Ops simply needs to redeploy the container that the Develoer shares, which is a self-contained package of everything needed by the application, in one place. In fact, the entire process can be automated so that new builds of the application can be pushed to deployment directly. This makes the usage of containers an attractive proposition due to the ease-of-deployment and potential cost-savings.

In the next post, we'll discuss Docker and go about installing it on our test machine.


If you found the article helpful, please share or cite the article, and spread the word:


For any feedback or corrections, please write in to: rahul [at] muchbits [dot] com