Docker has become a standard in the IT industry when it comes to packaging, deploying, and running distributed applications with ease. The key benefit of Docker is that it allows users to package an application with all of its dependencies into a standardized unit called containers.
Since Docker is a containerization platform, it’s important that you understand the history behind containerization.
History Before Containerization
Before containerization came into the picture, the leading way to isolate, organize applications and their dependencies was to place each and every application in its own virtual machine. These machines run multiple applications on the same physical hardware, and this process is nothing but Virtualization.
But virtualization had few drawbacks such as the virtual machines were bulky in size. Running multiple virtual machines lead to unstable performance. Boot up process would usually take a long time and VM’s would not solve the problems like portability, software updates, or continuous integration and continuous delivery.
These drawbacks led to the emergence of a new technique called Containerization.
Containerization is a type of Virtualization which brings virtualization to the operating system level. While Virtualization brings abstraction to the hardware, Containerization brings abstraction to the operating system.
Containers vs Virtual Machines
Terms “Containers” and “Virtual Machines” are often used interchangeably, however, this is often a misunderstanding. But, both are just different methods to provide Operating System Virtualization.
Virtual machines generally include a full Operating System, OS Packages and if required, few applications. This is made possible by a Hypervisor which provides hardware virtualization to the virtual machine. This allows for a single server to run many standalone operating systems as virtual guests. Generally speaking, a virtual machine is a system which acts exactly like a computer.
Containers are similar to virtual machines except that Containers are not full operating systems. Containers generally only include the necessary OS Packages and Applications. They do not generally contain a full operating system or hardware virtualization, that’s why these are “lightweight”.
Whereas, a Container is generally used to isolate a running process within a single host to ensure that the isolated processes cannot interact with other processes within that same system. Containers sandbox processes from each other. For now, you can think of a container as a lightweight equivalent of a virtual machine.
Docker enables creating and working with Containers as easy as possible.
Reasons to use Containers
- Containers have no guest OS and use the host’s operating system. So, they share relevant libraries & resources as and when needed.
- App isolation: If you want to run multiple applications on one server, keeping the components of each application in separate containers will prevent problems with dependency management.
- Processing and execution of applications are very fast since applications specific binaries and libraries of containers run on the host kernel.
- Booting up a container takes only a fraction of a second.
- Containers are lightweight and faster than Virtual Machines.
What is Docker?
Docker is a platform which packages an application and all its dependencies together in the form of containers. It uses containers to make creation, deployment, and running of application a lot easier. It binds application and its dependencies inside a container.
Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and ship it all out as one package.
Let’s say you need to build an application. To make that application available to the public, you need someplace to host it. In the past, you would need to build your own computer. You would need to set up a dedicated web service called “server,” which is basically a computer dedicated for hosting websites or web services. However, your application may only have an approximated size of 300 Megabytes to start with. So, why would you want a “virtual machine”, which is a virtualized environment resulted from virtualization, that has the size of 1GB+ when your application is much much less than that?
That’s where the concept of “container” comes in to fix that. Docker does it in the following way. Instead of hosting each operating system per each application, some common resources can be shared, and there is something called “docker engine,” which sits on top of an Operating System.
The result from adopting Docker, or container, is that application can be deployed or undeployed faster. Start and stop faster, change to another “image” faster, process and do many things faster.
But you should get to know the most important elements and tools around the Docker ecosystem when getting started.
A Dockerfile is a set of precise instructions, stating how to create a new Docker image. Setting defaults for containers being run based on it and a bit more. It is a text document which contains all the commands that a user can call on the command line to assemble an image. So, Docker can build images automatically by reading the instructions from a Dockerfile.
Docker Image can be compared to a read-only template which is used to create Docker Containers. An image, is a blueprint from which an arbitrary number of brand-new containers can be started. No “currently running commands” are saved in an image. When you start a container it’s a bit like booting up a machine after it was powered down.
It is a running instance of a Docker Image as they hold the entire package needed to run the application.
Imagine you’d like run a command isolated from everything else on the system. It should only access exactly the resources it is allowed to and does not know there is anything else on the machine. The process running inside a container thinks it’s the only one and only sees a barebones Linux distro the stuff which is described in the image.
A machine running the container should not have to care about what’s inside too much, and the dockerized app does not care if it’s on a Kubernetes cluster or a single server – it will be able to run anyway.
A container can run more than a single process at a time. You could package many services into a single container and have them all run side by side.
When a Docker container is deleted, relaunching the image will start a fresh container without any of the changes made in the previously running container – those changes are lost.
Images don’t change. You can create new ones, but that’s it. Containers on the other hand leave nothing behind by default. Any changes made to a container, given that you don’t save it as an image, are lost as soon as it is removed.
In order to be able to save (persist) data and also to share data between containers, Docker came up with the concept of volumes. Quite simply, volumes are directories (or files) that are outside of the default file system and exist as normal directories and files on the host filesystem.
Docker volumes enabled us to persist data and share between containers.
We hope this article helped understanding the basic Docker fundamental of what Docker is and how it’s revolutionized software development. With the knowledge above, you should have a firm grasp of what Docker is about at the core.