Before Containers

Let us dial back the clock. Back when computers were a novelty, and companies wanted to run their applications, they would have had to buy a server for doing so. However, this came with a caveat: you could only run one application per server. If you wanted to run multiple applications, you would have to buy as many servers. As costs would skyrocket, this was a problem, for both the company and the environment on a larger scale

IBM fixed this issue by introducing the concept of virtual machines into the game. With them, we could run multiple applications on the same server. You may have heard of / done dual booting on your PC; like installing windows on your Mac device or Ubuntu on Windows. These are virtual machines. However, they had a problem as well. They needed their own operating system, which tended to take up a lot of memory and storage on your hard disk. This made them slow and not so efficient.

Containerization Advent

Imagine you are moving to Kathmandu from Dharan (or swap those two cities with any two). Would it make sense to send your belongings one by one, or would you rather put them all in one giant box and ship the box directly? Obviously the latter, right?

That big box is, in simple terms, a container.

Let’s say you built a website that works well on your system but your friend runs into some problems with it when they try using it on their computer. To avoid such hassles, you can use a container, which would ship the entire website along with its dependencies, such as the web database, front end, back end, source code, etc. This would ensure that the website runs smoothly.

In computing terms, containerization is an efficient method for running, deploying and scaling applications.

Containers vs. Virtual Machines

Any application which runs on a VM will require a guest OS to run, which would require a hypervisor. A hypervisor manages the virtual machines and is used to create multiple machines on the host operating system. As you can see from the above picture, every OS would require a dedicated amount of space in the hardware, which is virtually divided.

In the case of containers, you need have only one operating system, and on top of that, you have a container engine, on which you run applications. They use the idea of isolating your application from the main operating system.

To sum it up succinctly, virtual machines use multiple operating systems to run multiple applications whereas containers use only the host operating system to run applications via the container engine.

In actuality, however, containers run on top of virtual machines. You can say they are a lightweight alternative.

Okay, but Docker.. ??

Before diving into Docker, let's take a brief tour of some of the cloud-based services that most of us are familiar with. So understanding Docker will be a cakewalk.

You are probably familiar with Google Photos, Google Drive, GitHub, etc. These are examples of cloud-based services. In these services, you can upload your photos and code to the cloud, making them accessible from any device and not just limited to your local device.

Docker, on the other hand, is a platform that allows for the creation, deployment, and management of containers. Simply put, you can understand that Docker is like a ship on which containers are loaded and deployed on the cloud, allowing you to access them from anywhere. The logo of Docker visualizes what I mean.

In recent years, containerization has taken the software development and deployment world by storm, and Docker has emerged as one of the most popular and widely-used containerization platforms. Docker is one among many container platforms that allows you to build such containers to test, build and scale applications rapidly and easily by running them in isolated environments. One of the key perks of containerization with Docker is the ability to achieve consistency and portability across different environments.

There are various terminologies involved in Docker. Some of them are:

• Docker Runtime

  Docker Runtime refers to the environment in which Docker containers are executed. It includes the Docker daemon, the Docker client, and the underlying operating system and system libraries.

• Docker Daemon

  It is the heart of the Docker architecture, which does the crucial work of building, running, and distributing the containers. It also manages the Docker images and the containers.

• Docker Client

  The Docker client is used to interact with the daemon and issue commands to create, start, stop and manage containers.

• Docker CLI

  It allows users to issue commands to the Docker Daemon. Docker uses a client-server architecture.

• Docker Engine

  Docker Engine is the underlying technology that runs the Docker platform. It is the component responsible for creating and managing Docker containers. The Docker Engine is made up of several components, including the Docker daemon, the Docker client, and the Docker API.

• Docker Image

  The file that contains the source code, OS files to run the application along with its other dependencies inside the container is called Docker image. A containerized application is the running instance of an image. Docker images are immutable.

• Dockerfile

  A Dockerfile is a script that contains instructions for building a Docker image. It is used to create an automated build that can be used to create a container image. A Dockerfile is a simple text file that contains a set of commands that are executed to build the image.

Conclusion

In conclusion, containerization with Docker is a game-changer in application development and deployment. It allows for consistency and portability across different environments, increases the utilization of resources, and enables collaboration and automation. If you're not yet using Docker and containers in your development and deployment process, it's definitely worth considering.