From VMs to Containers: The Rise of Docker in Software Development

Docker has revolutionized the Software Industry by its versatile nature of running apps, anywhere a docker engine is present.

What is Docker?

---

It became a main tool used by many companies to ship their apps into a container to solve the famous It works on my machine problem.

The reason why this happens is:

1. Missing tools

2. Different Configuration

3. Hardware Dependencies

There are many tools and software to solve these problems. Configuration Management Tools like Chef, Ansible and Puppet solve it by allowing you to write code in markup languages to describe what machines needs to have in order to run our app. Other tools like Hashicorp Vagrant lets you write code to create an entire virtual machine to run our app in.

But the above solutions came with their own set of problems, Configuration management tools (Chef, Puppet, Ansible) require knowledge about hardware and operating systems. Virtual machines as code (Vagrant) are heavy, slowish and require inconvenient configuration like demanding knowledge of, how much hardware our application needs and which operating system to use.

Docker on the other hand has taken a simple approach, it is a software that allows a developer to package their apps into images that run on containers. Docker uses images and containers to allow apps to run anywhere, consistently. Images are built from lightweight configuration files that describe everything that our app needs to run. Unlike Virtual machines, containers are virtualized operating systems that are configured with just enough to run our app and nothing else.

Containers Vs. Virtual Machines

---

Most of the time containers are known as smaller virtual machines, which is not true. Virtual machines virtualize hardware whereas containers virtualize operating system kernels.

Virtual Machines

1. Use the hypervisor to emulate real hardware

2. Can take up a lot of space

3. Require you to install/configure operating system

4. Can run multiple apps at the same time

5. Cannot interact with their hosts

While Virtual Machines run on hypervisor, docker containers run on container run times. Container run times works with the operating system to allocate hardware and copy files and directories including the parts that container our application in it into something that looks more like any other app running on that system.

Containers

1. Do not emulate any hardware and do not need to boot up

2. Do not require operating system installation

3. Take up much less space

4. Can run only one app at a time (by design)

5. Can interact with their hosts

The anatomy of a container

---

We learnt that container run time actually talks with our operating system kernel to create a container.

A container is composed of two things: a Linux namespace and a Linux control group.

Namespaces

Namespaces are a Linux kernel feature that provides the ability to expose different "views" of our system that is running our application within it. This way an application that it's running as the, let's say root super user with access to entire file system in all sorts of hardware when it's actually running as 154678 with access to a single folder.

Linux kernel provides 8 namespaces

Due to technical limitation, docker don't use TIME namespace, that means you can't change time with in a docker container.

Control Groups

Control groups, another Linux kernel feature, build on this by providing the ability to restrict how much hardware each process can use.

Docker uses control groups for few things:

1. Monitor and restrict CPU usage

2. Monitor and restrict network and disk bandwidth

3. Monitor and restrict memory consumption

Another thing to not is we can't use control groups to assign disk quotas to containers.

Docker Limitations

• Natively only runs on Linux

• Container images are bound to their parent operating systems