Getting Started with Docker
Applications run businesses. They have become so crucial that it is impossible to even imagine a MNC running without applications with all its customers and employees settled in different places.
Applications run on servers. In mid 2000s, we used to run one physical application on one server. So, if the business needs a new application (which is very probable considering all businesses expand), they’d have to buy a new server and must invest in the huge costs associated with it-power, cooling etc. Pre-determining the size and speed of the server is extremely unpredictable, and to be honest, no one knows that.
Let us consider back in 2000s, if a company had to buy a new server for one of its new application that has to be launched, it would obviously never want to upset it’s Clients and the firm’s reputation, and thus, it would not compromise on the server required for the same. But then this would lead to massively overpowered servers only utilizing 5–10% of the server capabilities. This is obviously a waste of the company’s capital!
Thus, the concept of virtualization was introduced. It enabled tones of app to run on the same physical server! So, every time a new application was launched, we would not need a new server! We could put the new app on the existing server. Consider Virtual Machine as a slice of the physical server hardware. So, each has some portion of the CPU, memory and the physical server disk space. Each Virtual Machine will have to be allocated with an Operating System and just to run that, it consumes the same resources mentioned above. With every Operating System, we must incur costs related to licenses of the Operating System, Security, Updates etc.
Containers
As explained, VM hypervisors such as Hyper-V, KVM and Xen are extremely fat in terms of system requirements whereas on the other hand, containers make use of Operating Systems. Thus, they are extremely efficient in system resource terms.
A container is very similar to a Virtual Machine but with a major change! The Host OS. As visible in the above diagram, the resources that the Operating System was “stealing” has now been dealt with. With a perfectly tuned container system, you can have 4–6 times the number of server application instances as you can using Xen or KVM VMs on the same hardware.
It also helps in fast, consistent delivery of your applications as containers are great for continuous integration and continuous delivery workflows. Docker containers can run on a developer’s local desktop, on physical or virtual machines in a data center, on cloud providers, or in a mixture of environments. Woah, no more complaining about version mismatches while running the same code on different setups!
“…but it worked on my machine!” is something that we hear quite often in a development environment. The solution to avoid this when the code breaks is introducing a blue chip solution called “container” which will have all dependencies packaged (thus being platform independent).
Docker
Docker is a software platform for developers and sysadmins to develop, deploy, and run applications with containers (through containerization).
To explain the definition better, we’ll have to consider what a container is. A container provides a lightweight execution environment using shared Operating System but otherwise runs in an isolated environment from all other processes on the host machine. It originates from its blueprint — The Docker image!
Docker image acts as a set of instructions written in a YAML file to build the container. It acts as a starting point when we’re building containers.
The entire process is demonstrated below.
The Docker Client is the primary way that Docker users use to interact with Docker. When a command is run, it gets send to the Docker daemon which is responsible for carrying them out. Docker registries are very similar to GitHub. A docker registry is used to store images that users can pull and run container from. Although we can have our own private registries, Docker hub is a public registry and Docker is configured in such a way that it automatically looks on Docker Hub by default when commands are run.
