So what problem does containers solve? In context of virtualization, Containers are a solution to the two problems:-
- With a virtual machine, you have to virtualize an entire operating system as well as the software you want to run. This makes VMs really resource heavy. The operating systems is often the single largest most resource-intensive piece of hardware on your computer and so running multiple OS's on the same computer, just so that you can have separate environments, uses a lot of your resources.
- How to get software to run reliably when moved from one computing environment to another. This could be from a developer's laptop to a test environment, from a staging environment into production, and perhaps from a physical machine in a data center to a virtual machine in a private or public cloud.
To overcome these issues, the Linux operating system began implementing containers. The idea is simple, if you're running a Linux OS on your computer already, why run a new OS for each VM? Instead you can use the core of the OS, called the kernel, for each VM. This way the VMs only run the software that they need to.
The difficulty with this is that it is important that the VMs not be able to affect each other, or the underlying computer they're running on. And containers need to replicate this functionality. So the Linux team had to implement some safety features into the kernel itself.
Features such as being able to block off different parts of the kernel processor and memory for the different containers, so that the code running on one container can't accidentally access another container through the kernel.
Now that these containers were implemented at the kernel level, any amount of software could be run inside of one and it would be like running it in its own VM, or own physical machine. And because all Linux distros share the same fundamental Linux kernel, you can easily run containers with different distros, just as easily as you can run containers using the same distro.
The software that makes each distribution unique all runs on top the kernel and it's only the kernel that is shared across all the containers and the host OS. Once containers are implemented at the most basic fundamental part of the Linux OS, software which made it easier to implement these Linux containers begin to pop up.
One of the first and most successful container software projects is called Docker. Docker makes it easy to define, manage and use Linux containers by simply writing plain text documents to define the software that you want running inside of a particular container.
In addition, Docker and other companies began building software that could link containers together into a single app, as well as orchestrate spinning them up and down in the cloud rapidly. In addition to Docker, there are other container systems.
Let us understand Containerization(Docker's Prospective) with comparision to VM(Virtual Machine)
Figure below shows the various layers in a computer that uses VMs. The bottom layer is the hardware of your computer with the OS sitting on top of it. Next to OS is the hypervisor(software to create and run VMs). Next with using this hypervisor system can host multiple gues Operating Systems like Windows, Server, Linux etc. Each VM can contain seperate set of libraries needed by the application and each VM allocated a specific amount of Hardware that includes Memory, CPU cores, Disk Space. Thus the hardware of your system has direct impact on the amount of VM's one can host on a System and limited by hardware.
Next Figure shows how Docker fits in the picture. Instead of a hypervisor you now have a Docker engine. The Docker engine manages a number of containers, which hosts your application and the libraries that you need. Unlike VMs container does not contains a copy of the OS- Instead it shares the host's operating system.
A Docker container doesn't have any operating system installed and running on it. But it does have a virtual copy of the process table, network interface(s), and the file system mount point(s). These are inherited from the operating system of the host on which the container is hosted and running.
Now before going further lets understand the most important part of Docker, the DOCKER FILE
Dockerfile is used to define a container. This Dockerfile starts with a standard image, usually provided by a software project, such as, a Linux distro or web technology like node.js. From there you can add new pieces to that image in a certain order, usually by running commands telling the image to install and setup new software. Once the file is written and saved, it can be sent in plain text to any two other people and built in just a few seconds on any computer that has Docker installed.
Once the Docker file is built, you can run the image inside a container, or copy it to multiple times, to run it in as many containers as you want. Further software can be used to network containers to each other, the same way VMs or physical machines can be networked together. So that your containers can communicate with each other to create one large system built with many small containers.
But that's just on Linux. What if you want to run containers on another operating system?
While Docker lets you run Linux containers on Mac or Windows by first starting a really lightweight Linux VM that mostly just runs the kernel, and then running all the other containers inside that VM. So this is slower than running Linux containers on the Linux, because you do have a VM, but it's faster than the old paradigm of using a bunch of VMs, because you're only running one, and you get the other benefits of containers along with it. In addition, Microsoft has been working to build Windows containers. These are containers that are built into the Windows operating systems, so that instead of running a Linux distro and a container, you can run Windows in Windows software in a container. Windows has been working really closely with Docker on this project, so they work with Docker. However, running a Windows container on Linux or Mac doesn't really work at this point.
I think this might have given enough knowledge to understand Containers, In second part of this blog series We will understand Dockers by implementing a container,and deploying application using it.
