Introduction to Docker and Container based development.
An overview of container-based development and Docker.
Early on, we used physical servers to deliver our applications. Assume there is a web server, database, and application. For this reason, we used three different actual hardware boxes back then.
Difficulties with those various hardware boxes :-
- Maintaining issues.
- Space needed Issues.
- Separate network issues.
- Separate OS issues.
- Over cost issues.
- More wastage issues.
Then began the generation of Hypervisor.
Hypervisor.
We used to install our application on physical servers even before the generation of hypervisors. However, because of the new technologies, we still utilize that technology, albeit infrequently. In comparison to Hypervisor, it has numerous disadvantages in a variety of domains. Because distinct physical machines are required for the application server, database, and web server while installing an application. As a result, it wastes a lot of resources and requires high maintenance costs. The Hypervisor was primarily developed to address the disadvantages listed above. A hypervisor, put simply, is a software layer that generates and manages numerous separate virtual machines on a single piece of hardware. A hypervisor is a crucial component of virtualization that enables businesses to save costs while speeding up deployment.
There are two types of Hypervisors named as, Type 1 and Type 2 Hypervisor.
Type-01 hypervisor is described here. The hypervisor is placed on a single high processing hardware unit, as seen in the image (physical server). On top of this hypervisor, additional virtual machines are then created. Each of these virtual machines has Windows or Linux as its installed operating system. After all, those operating systems are capable of running our programs. Now, we may refer to this as a legitimate virtual environment. We can tackle the issue of resource waste and cut costs in a realistic amount in this method. However, it still falls short of expectations, and this Hypervisor technique still has a few disadvantages. such as,
- Want to more multiple OS and maintaining those.
- VM’s much slow and take more time to boot.
Containers,
(Containerized Applications.)
Despite the Hypervisor’s disadvantages, we can still use containerized software. The issue of how to get software to run and execute properly when moved from one computing environment to another is, in simplest words, solved by containers. Without starting a separate virtual machine for every app, the OS-level virtualization technique known as containerized applications is used to deploy and operate allocated applications.
It has a single box of powerful hardware (physical server). On top of the hardware, we next deploy a single operating system. If you recall, we must build several virtual computers using the Hypervisor on top of a hardware unit before installing an operating system in each of them. As a result, we can simply fix that problem with containerized apps, which makes this strategy incredibly cost-effective. We create the Container Engine on top of the OS after it has been installed. We are able to build Containers inside the engine as a result. Our apps can now be built on top of each Container.
Note: These containers are so small compared to Hypervisor’s virtual machines.
Docker,
A software platform called Docker is used to create applications based on containers. To guarantee that your application runs flawlessly in every environment, our containerization platform is in charge of combining your application and its dependencies into a docker container. Although the Container technology has been available for a while, Docker is the one responsible for making it more widely used. Although it will be much more difficult, we can still create containers without Docker. Let’s look at some of the elements you need to understand to build Docker containerized applications.
Docker Engine.
The program that is installed on your host computer is just called Docker Engine. The Docker system’s hub integrates all of the platform’s elements in one place, including containers, registries, images, and services.
Docker Image.
A read-only template for building Docker containers is called a Docker Image. Through the use of these Docker images, Docker enables businesses to create and distribute software. It includes all of the installations, dependencies, libraries, and application code required to build a container environment that is completely functional.
Docker Container.
Docker Containers are simply the active instances of Docker Images. It contains the whole set of files required to run the program.
Docker Registry.
You can keep your Docker Images at this location. A user’s local repository on their computer or a public repository like a “Docker Hub” are both examples of the Registry, which enables users to work together on the development of an application. By posting containers to the Docker Hub, for instance, several teams within a company can swap or share containers.
Note: Other public repositories: Red Hat Quay, Amazon ECR, Google Container Registry.
Container Orchestration.
Assume that your application includes many containers for various services, such as HTTP, HTTPS, and authentication. You’ll need a method to configure, scale, and monitor every container throughout the architecture of your application once you’re prepared to deploy it to Docker. You can get assistance with this process from a number of open-source orchestration tools, including Kubernetes, Docker Swarm, and Mesos.
What is Kubernetes,
You can automate the deployment, scaling, and operation of containerized applications using Kubernetes, a well-known open source platform for container orchestration. Kubernetes can be used with any other container, even though Docker is the container of choice for most people. Many aspects of Kubernetes make it easy to deploy containerized applications, including :-
- Container Deployments and Rollout Control.
- Built-in Service Discovery and Autoscaling.
- Resource Bin Packing.
- Persistent Storage.
*The Docker, it is “not persistence”. This means that some people think that if we shut down the Docker, everything will be lost. However, given that Dockers are persistent by nature, that is entirely incorrect. Therefore, wherever you stop, it will be there no matter what you do.
References :-
Krishantha Dinesh, Introduction to Docker and Container based development, Nov 16, 2016),
